66 lines
3.1 KiB
Markdown
66 lines
3.1 KiB
Markdown
# GPT Plan Localization Protocol
|
|
|
|
## Purpose
|
|
|
|
GPT planning documents are upstream planning inputs. They are not directly executable repository rules.
|
|
|
|
Before Codex implements content from a GPT plan, Codex must convert the plan into local rules, schemas, workflow steps, tools, indexes, and validation criteria.
|
|
|
|
## Required Intake Steps
|
|
|
|
1. Read the GPT planning document completely enough to extract fields, tasks, non-goals, workflow requirements, tooling expectations, index expectations, and acceptance criteria.
|
|
2. Compare the GPT plan against local repository rules in `AGENTS.md`, `README.md`, `docs/DATA_CONTRACT.md`, `docs/WORKFLOW.md`, `docs/DECISIONS.md`, and `PROJECTS.md`.
|
|
3. Identify conflicts, missing local contracts, missing schemas, missing validators, missing indexes, missing workflow gates, and missing owner-confirmation points.
|
|
4. Write a local execution plan before changing content.
|
|
5. Ask the project owner to review the local execution plan.
|
|
6. Only after owner approval, implement local rules, schemas, indexes, workflow, and tooling.
|
|
7. Validate the foundation.
|
|
8. Ask the project owner to review the foundation before content extraction or content repair begins.
|
|
|
|
## Required Local Plan
|
|
|
|
Each local plan must state:
|
|
|
|
- Which parts of the GPT plan become repository rules.
|
|
- Which parts become schemas.
|
|
- Which parts become workflow gates.
|
|
- Which parts become validation or selector tools.
|
|
- Which parts are deferred.
|
|
- Which parts conflict with existing local rules.
|
|
- What the project owner must confirm before implementation.
|
|
|
|
## Prohibited Shortcut
|
|
|
|
Do not directly create or repair model content from a GPT planning document before local rules, schemas, indexes, workflow, and validation expectations are confirmed.
|
|
|
|
Do not treat a GPT plan as a substitute for local schema, local workflow, local index definitions, or local validation tools.
|
|
|
|
Do not silently narrow a GPT plan to the current repository minimum field set. If the GPT plan has a richer contract, record the difference and ask for confirmation or implement the richer local contract first.
|
|
|
|
## Dual-Track Rule
|
|
|
|
Model extraction must keep two tracks separate:
|
|
|
|
1. Workflow/tooling track: rules, schemas, indexes, validators, selector demo, audit reports, and supplier requests.
|
|
2. Content extraction track: source records, evidence excerpts, model JSON, Markdown cards, regression cases, and selector examples.
|
|
|
|
The content extraction track must not absorb missing workflow or tooling work. If a missing capability blocks reliable extraction, create a local plan item or a supplier request before continuing.
|
|
|
|
## Required Report
|
|
|
|
Each localization pass must produce a report under `reports/` that lists:
|
|
|
|
- GPT plan source path.
|
|
- Local files created or modified.
|
|
- Fields adopted.
|
|
- Fields rejected or deferred.
|
|
- Workflow gates added.
|
|
- Indexes required.
|
|
- Tooling needs identified.
|
|
- Differences from current repository state.
|
|
- Open owner questions.
|
|
|
|
## Owner Review Gate
|
|
|
|
After local rules, schemas, indexes, workflow, and validation expectations are implemented, Codex must stop for project owner review unless the owner explicitly authorizes continuing into content extraction.
|