the-mindscape-of-bro-tsong/docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md

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.