Publish DevRunbook source

2026-09-03 04:09:17 +02:00
commit cfd2804e27
928 changed files with 161642 additions and 0 deletions
@@ -0,0 +1,55 @@
+# 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.