61 lines
2.9 KiB
Markdown
61 lines
2.9 KiB
Markdown
# Start DevRunbook in Codex
|
|
|
|
This file is the operator entry point. The build pack is designed so Codex can begin from the extracted directory without the operator manually rearranging files.
|
|
|
|
## Recommended start
|
|
|
|
1. Extract the ZIP completely.
|
|
2. Open the extracted `DevRunbook_Build_Pack_v1_2` directory as a project in the Codex app, CLI or IDE extension.
|
|
3. Ensure Git is initialized in this directory. When it is not, Codex may initialize it during Milestone 0.
|
|
4. Start one lead Codex thread in the project root.
|
|
5. Paste the complete contents of `CODEX_MASTER_PROMPT.md` as the first task.
|
|
6. Allow Codex to inspect the repository and run the offline specification validator.
|
|
7. Review only genuine blockers, security-sensitive approvals or final release evidence. Routine implementation choices are already governed by the specification.
|
|
|
|
Do not copy only the master prompt into another empty project. The prompt depends on the schemas, content packages, API contract, database reference, golden prompt fixtures and milestone documents included here.
|
|
|
|
## Codex app mode
|
|
|
|
A local project thread is the simplest starting mode. A Codex-managed worktree is also acceptable when the full build-pack directory is visible inside it. The lead thread owns the canonical implementation branch and the state files. Independent worktrees or subagents may be used only according to `CODEX_EXECUTION_PROTOCOL.md`.
|
|
|
|
Select the strongest current coding model available to the account and use a high reasoning setting for architecture, security, migration and release-gate work. Do not hard-code a historical model name into the repository.
|
|
|
|
## First command evidence
|
|
|
|
Codex must begin with:
|
|
|
|
```bash
|
|
python3 scripts/validate_pack.py
|
|
python3 scripts/reference_compose.py --check
|
|
```
|
|
|
|
On Windows, `py -3` may replace `python3`. If Python dependencies are missing, create an isolated virtual environment and install `scripts/requirements-validate.txt` before continuing.
|
|
|
|
Expected specification baseline:
|
|
|
|
- 28 publishable P0 Playbook Packages;
|
|
- six normative example packages;
|
|
- 72 catalog entries;
|
|
- nine valid JSON Schemas;
|
|
- 28 byte-stable golden rendered prompts;
|
|
- a pre-populated 68-requirement release evidence template.
|
|
|
|
## Resume after an interruption
|
|
|
|
Open the same project and tell Codex:
|
|
|
|
> Resume DevRunbook from `CURRENT_STATE.md`. Re-read `AGENTS.md`, `CODEX_EXECUTION_PROTOCOL.md` and the active milestone. Verify the current Git diff and quality gates before continuing. Do not restart completed work or trust an unverified status claim.
|
|
|
|
## Completion evidence
|
|
|
|
The build is complete only when Codex has produced:
|
|
|
|
- the implemented application and migration history;
|
|
- all milestone evidence in `CURRENT_STATE.md`;
|
|
- a machine-readable final requirement matrix;
|
|
- production container artifacts;
|
|
- clean-room installation evidence;
|
|
- backup and restore evidence;
|
|
- critical browser-flow evidence;
|
|
- `FINAL_HANDOFF.md` based on the supplied template.
|