Files
DevRunbook-Public/CODEX_MASTER_PROMPT.md
DevRunbook release export cfd2804e27
Managed validation / full (push) Successful in 3m18s
Publish DevRunbook source
2026-09-03 04:09:17 +02:00

4.3 KiB

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.