Add Oracle AI Database Vector Search LangChain example

Author: annikab-oai

.github/registry_schema.json

@@ -10,6 +10,12 @@
       "path": {
         "type": "string"
       },
+      "slug": {
+        "type": "string"
+      },
+      "description": {
+        "type": "string"
+      },
       "redirects": {
         "type": "array",
         "items": {
@@ -36,7 +42,7 @@
         "type": "boolean"
       }
     },
-    "required": ["title", "path", "tags", "authors"],
+    "required": ["title", "path", "slug", "tags", "authors"],
     "additionalProperties": false
   }
 }

articles/codex_exec_plans.md

@@ -1,6 +1,6 @@
 # Using PLANS.md for multi-hour problem solving
 
-Codex and the `gpt-5-codex` model can be used to implement complex tasks that take significant time to research, design, and implement. The approach described here is one way to prompt the model to implement these tasks and to steer it towards successful completion of a project.
+Codex and the `gpt-5.2-codex` model (recommended) can be used to implement complex tasks that take significant time to research, design, and implement. The approach described here is one way to prompt the model to implement these tasks and to steer it towards successful completion of a project.
 
 These plans are thorough design documents, and "living documents". As a user of Codex, you can use these documents to verify the approach that Codex will take before it begins a long implementation process. The particular `PLANS.md` included below is very similar to one that has enabled Codex to work for more than seven hours from a single prompt.
 
@@ -22,7 +22,7 @@ When writing complex features or significant refactors, use an ExecPlan (as desc
 
 Below is the entire document. The prompting in this document was carefully chosen to provide significant amounts of feedback to users and to guide the model to implement precisely what a plan specifies. Users may find that they benefit from customizing the file to meet their needs, or to add or remove required sections.
 
-````md
+~~~md
 # Codex Execution Plans (ExecPlans):
 
 This document describes the requirements for an execution plan ("ExecPlan"), a design document that a coding agent can follow to deliver a working feature or system change. Treat the reader as a complete beginner to this repository: they have only the current working tree and the single ExecPlan file you provide. There is no memory of prior plans and no external context.
@@ -97,82 +97,80 @@ Prefer additive code changes followed by subtractions that keep tests passing. P
 
 ## Skeleton of a Good ExecPlan
 
-```md
-# <Short, action-oriented description>
+    # <Short, action-oriented description>
 
-This ExecPlan is a living document. The sections `Progress`, `Surprises & Discoveries`, `Decision Log`, and `Outcomes & Retrospective` must be kept up to date as work proceeds.
+    This ExecPlan is a living document. The sections `Progress`, `Surprises & Discoveries`, `Decision Log`, and `Outcomes & Retrospective` must be kept up to date as work proceeds.
 
-If PLANS.md file is checked into the repo, reference the path to that file here from the repository root and note that this document must be maintained in accordance with PLANS.md.
+    If PLANS.md file is checked into the repo, reference the path to that file here from the repository root and note that this document must be maintained in accordance with PLANS.md.
 
-## Purpose / Big Picture
+    ## Purpose / Big Picture
 
-Explain in a few sentences what someone gains after this change and how they can see it working. State the user-visible behavior you will enable.
+    Explain in a few sentences what someone gains after this change and how they can see it working. State the user-visible behavior you will enable.
 
-## Progress
+    ## Progress
 
-Use a list with checkboxes to summarize granular steps. Every stopping point must be documented here, even if it requires splitting a partially completed task into two (“done” vs. “remaining”). This section must always reflect the actual current state of the work.
+    Use a list with checkboxes to summarize granular steps. Every stopping point must be documented here, even if it requires splitting a partially completed task into two (“done” vs. “remaining”). This section must always reflect the actual current state of the work.
 
-- [x] (2025-10-01 13:00Z) Example completed step.
-- [ ] Example incomplete step.
-- [ ] Example partially completed step (completed: X; remaining: Y).
+    - [x] (2025-10-01 13:00Z) Example completed step.
+    - [ ] Example incomplete step.
+    - [ ] Example partially completed step (completed: X; remaining: Y).
 
-Use timestamps to measure rates of progress.
+    Use timestamps to measure rates of progress.
 
-## Surprises & Discoveries
+    ## Surprises & Discoveries
 
-Document unexpected behaviors, bugs, optimizations, or insights discovered during implementation. Provide concise evidence.
+    Document unexpected behaviors, bugs, optimizations, or insights discovered during implementation. Provide concise evidence.
 
-- Observation: …
-  Evidence: …
+    - Observation: …
+      Evidence: …
 
-## Decision Log
+    ## Decision Log
 
-Record every decision made while working on the plan in the format:
+    Record every decision made while working on the plan in the format:
 
-- Decision: …
-  Rationale: …
-  Date/Author: …
+    - Decision: …
+      Rationale: …
+      Date/Author: …
 
-## Outcomes & Retrospective
+    ## Outcomes & Retrospective
 
-Summarize outcomes, gaps, and lessons learned at major milestones or at completion. Compare the result against the original purpose.
+    Summarize outcomes, gaps, and lessons learned at major milestones or at completion. Compare the result against the original purpose.
 
-## Context and Orientation
+    ## Context and Orientation
 
-Describe the current state relevant to this task as if the reader knows nothing. Name the key files and modules by full path. Define any non-obvious term you will use. Do not refer to prior plans.
+    Describe the current state relevant to this task as if the reader knows nothing. Name the key files and modules by full path. Define any non-obvious term you will use. Do not refer to prior plans.
 
-## Plan of Work
+    ## Plan of Work
 
-Describe, in prose, the sequence of edits and additions. For each edit, name the file and location (function, module) and what to insert or change. Keep it concrete and minimal.
+    Describe, in prose, the sequence of edits and additions. For each edit, name the file and location (function, module) and what to insert or change. Keep it concrete and minimal.
 
-## Concrete Steps
+    ## Concrete Steps
 
-State the exact commands to run and where to run them (working directory). When a command generates output, show a short expected transcript so the reader can compare. This section must be updated as work proceeds.
+    State the exact commands to run and where to run them (working directory). When a command generates output, show a short expected transcript so the reader can compare. This section must be updated as work proceeds.
 
-## Validation and Acceptance
+    ## Validation and Acceptance
 
-Describe how to start or exercise the system and what to observe. Phrase acceptance as behavior, with specific inputs and outputs. If tests are involved, say "run <project’s test command> and expect <N> passed; the new test <name> fails before the change and passes after>".
+    Describe how to start or exercise the system and what to observe. Phrase acceptance as behavior, with specific inputs and outputs. If tests are involved, say "run <project’s test command> and expect <N> passed; the new test <name> fails before the change and passes after>".
 
-## Idempotence and Recovery
+    ## Idempotence and Recovery
 
-If steps can be repeated safely, say so. If a step is risky, provide a safe retry or rollback path. Keep the environment clean after completion.
+    If steps can be repeated safely, say so. If a step is risky, provide a safe retry or rollback path. Keep the environment clean after completion.
 
-## Artifacts and Notes
+    ## Artifacts and Notes
 
-Include the most important transcripts, diffs, or snippets as indented examples. Keep them concise and focused on what proves success.
+    Include the most important transcripts, diffs, or snippets as indented examples. Keep them concise and focused on what proves success.
 
-## Interfaces and Dependencies
+    ## Interfaces and Dependencies
 
-Be prescriptive. Name the libraries, modules, and services to use and why. Specify the types, traits/interfaces, and function signatures that must exist at the end of the milestone. Prefer stable names and paths such as `crate::module::function` or `package.submodule.Interface`. E.g.:
+    Be prescriptive. Name the libraries, modules, and services to use and why. Specify the types, traits/interfaces, and function signatures that must exist at the end of the milestone. Prefer stable names and paths such as `crate::module::function` or `package.submodule.Interface`. E.g.:
 
-In crates/foo/planner.rs, define:
+    In crates/foo/planner.rs, define:
 
-    pub trait Planner {
-        fn plan(&self, observed: &Observed) -> Vec<Action>;
-    }
-```
+        pub trait Planner {
+            fn plan(&self, observed: &Observed) -> Vec<Action>;
+        }
 
 If you follow the guidance above, a single, stateless agent -- or a human novice -- can read your ExecPlan from top to bottom and produce a working, observable result. That is the bar: SELF-CONTAINED, SELF-SUFFICIENT, NOVICE-GUIDING, OUTCOME-FOCUSED.
 
 When you revise a plan, you must ensure your changes are comprehensively reflected across all sections, including the living document sections, and you must write a note at the bottom of the plan describing the change and the reason why. ExecPlans must describe not just the what but the why for almost everything.
-````
+~~~