56 lines
4.3 KiB
Markdown
56 lines
4.3 KiB
Markdown
# Master implementation prompt for Codex
|
|
|
|
You are responsible for building **DevRunbook** from the specification contained in this repository.
|
|
|
|
DevRunbook is a premium, self-hostable platform that turns development intent, repository context, risk constraints, validation requirements and a selected autonomy level into a deterministic Codex prompt or multi-file Run Pack. It must not degrade into a static collection of prompt cards.
|
|
|
|
## Operating mode
|
|
|
|
Work autonomously through the milestones in `IMPLEMENTATION_PLAN.md`, while respecting `AGENTS.md`. Begin by reading `START_HERE_CODEX.md`, `AGENTS.md`, `CODEX_EXECUTION_PROTOCOL.md` and the required documents in their stated order, then inspect the repository. If the repository contains an existing implementation, preserve sound work and produce a gap analysis rather than restarting blindly.
|
|
|
|
Do not ask for routine implementation choices that are resolved by the specification. Make conservative, documented decisions where minor details are open. Stop only for a genuine external blocker, an irreversible product decision not covered by the specification, unavailable credentials required for a live integration, or a safety concern.
|
|
|
|
## Required process
|
|
|
|
1. Read `PACK_REVIEW.md` so the v1.0 gaps are not reintroduced.
|
|
2. Run `python3 scripts/validate_pack.py` and `python3 scripts/reference_compose.py --check`; do not begin implementation unless all 28 P0 packages, six normative examples, 72 catalog entries, nine schemas and 28 golden prompt fixtures validate.
|
|
3. Establish the current Git, toolchain and specification baseline and update `CURRENT_STATE.md`.
|
|
4. Follow `docs/40-bootstrap-repository-contract.md` and prove the first vertical slice before broad feature work.
|
|
5. Implement one milestone at a time using the lead-thread, worktree and subagent rules in `CODEX_EXECUTION_PROTOCOL.md`.
|
|
6. Add tests with each capability, not after the entire product is built.
|
|
7. Run all milestone quality gates and repair failures before continuing.
|
|
8. Update documentation, decisions and current state continuously.
|
|
9. Preserve a clean setup path for a fresh clone.
|
|
10. Keep the application usable without a Gitea connection.
|
|
11. Use explicit degraded states when integrations are unavailable.
|
|
12. Finish with production-build, clean-room, migration, backup/restore, performance/security evidence and core browser-flow verification.
|
|
|
|
## Non-negotiable product requirements
|
|
|
|
- all 28 P0 built-in Playbook Packages imported and validated against the v1.2 schema;
|
|
- searchable library with filters and lifecycle badges;
|
|
- guided composer with live deterministic preview;
|
|
- autonomy levels from Observe through Repair;
|
|
- repository profiles with commands, protected paths and constraints;
|
|
- prompt linting before export;
|
|
- byte-identical production rendering for all 28 supplied golden prompt fixtures;
|
|
- exports for plain prompt, Markdown and Run Pack ZIP;
|
|
- import and export of playbook packages;
|
|
- immutable generated-run snapshot and content digest;
|
|
- read-only Gitea integration in its first implementation;
|
|
- secure local authentication, workspace authorization, first-run ownership, secret handling and redacted logs;
|
|
- premium responsive interface with light/dark mode, keyboard support and reduced-motion behavior;
|
|
- self-hosted Docker/Unraid deployment;
|
|
- no arbitrary code execution in the MVP.
|
|
|
|
## Definition of done
|
|
|
|
The product is not complete until the acceptance matrix in `docs/19-acceptance-criteria.md` passes, representative browser flows are verified, all 28 P0 runtime packages import without errors and the 72-entry roadmap catalog validates, all 28 golden examples render byte-identically through the production composer, exports can be re-imported, database migrations work on a fresh database, backup/restore is documented and tested, and a new operator can launch the platform using the documented Docker workflow.
|
|
|
|
When a milestone is complete, proceed to the next without waiting for confirmation unless a genuine blocker exists.
|
|
|
|
|
|
## Final handoff requirement
|
|
|
|
Create `release-evidence.json` from the supplied template and validate it against its schema. Create `FINAL_HANDOFF.md` from the supplied template. Include exact setup, upgrade, backup/restore, validation, browser, security, performance, release and known-limitation evidence. Do not declare the application complete while any mandatory acceptance item lacks actual proof.
|