A+C Project Governance — Pre-Planned + Supervised Execution
A+C Project Governance — Pre Planned + Supervised Execution Date: 2026 04 28 Status: Design approved — pending implementation plan Problem The platform's claim mechanism is proven. Atomic HCS claims, dep graph dispatch, and per task verification all work. The failure point is between a locked Plan and a completed Build: no one governs execution. Mindy receiv...
Date: 2026-04-28 Status: Design approved — pending implementation plan
---
The platform's claim mechanism is proven. Atomic HCS claims, dep-graph dispatch, and per-task verification all work. The failure point is between a locked Plan and a completed Build: no one governs execution. Mindy receives a brief and interprets it — sometimes producing 3 tasks instead of 9, sometimes building in the wrong repository. Manual intervention becomes routine. The infrastructure is correct; the orchestration layer above it is not.
---
1. Front-load intelligence. By the time Build starts, every task is fully specified. No agent makes structural decisions during execution. 2. Lock the plan. PLAN.json is approved by Justin before Build starts. It is immutable once Build begins. Engine dispatches from it. Mindy enforces it. 3. Supervisors govern, workers execute. Workers (Quinn, Vikram, Priya, Zara) never touch project structure. Mindy never creates tasks during Build — she validates them. 4. Targeted correction, not retry. When output fails, the supervisor diagnoses the specific gap and writes a surgical correction brief. Same input never produces different output. 5. Checkpoints are reports, not gates. Phase boundaries produce a health report to Justin. Not a blocker — a signal. Justin can intervene if something looks wrong. By default, execution continues.
---
Select a recipe → pre-built PLAN.json loaded → Engine dispatches → Mindy supervises.
A recipe is a pre-built PLAN.json template for a known project type (new agent, DB migration, content campaign, etc.). The Build stage runs identically to Track B — same Engine dispatch, same Mindy supervision. Recipes eliminate the Design + Planning stages for well-understood work.
Recipe library is a follow-on. Build Track B governance first. Recipes emerge naturally as PLAN.json templates from completed real projects.
Full lifecycle with governed execution:
``
Intake → Design → Plan → Build → QA
``
Each stage is a stage on the workflow instance. Exec gates exist between Design→Plan and Plan→Build. QA closes with an exec gate.
---
The workflow instance (Project → Stage → Phase → Task) is already the right container. No new infrastructure needed.
``
Project (workflow_instance, HCS topic 0.0.XXXXX)
Stage: Intake
Stage: Design
Stage: Plan
Stage: Build ← governed by A+C
Stage: QA
``
The Atlas+Justin planning session is a task on roles.architect. The output of that task — and the output of the Plan stage broadly — is PLAN.json. Justin approves the Plan exec gate. PLAN.json is locked. Build starts.
---
Owner: Justin + Atlas
Mechanism: Task dispatched to roles.architect. Atlas runs an interactive session — conversational intake, can include wireframes, analysis, structured brief output.
Output: Locked project brief on HCS (title, problem statement, success criteria, constraints, anti-requirements, scope).
Gate: Justin approves before Design starts.
Agents: Priya (PRD), Vikram (Architecture), Zara (UX Spec) — parallel Output: Three documents. Each agent reads the project brief. Priya owns the coherence check at the end. Gate: Justin reviews all three outputs. Approves before Planning starts.
Owner: Priya (generates), Atlas + Justin (review and correct) Mechanism: 1. Priya reads all three Design outputs and produces a PLAN.json draft. 2. Atlas reviews the PLAN.json with Justin in an interactive session — correcting task scope, dep-graph structure, output contracts, brief quality. 3. The reviewed PLAN.json is the exec gate artifact.
Gate: Justin approves PLAN.json. Once approved, it is immutable. Engine and Mindy both treat it as ground truth.
See *Build Stage Governance* section below.
Gate: Mindy posts a Build completion report when all phases pass. Justin approves before QA starts.
Agent: Luna Mechanism: Luna validates the Build outputs against the spec (PRD + UX Spec + Architecture). Automated checks where possible. Gate: Justin reviews QA report. Final approval.
---
PLAN.json is the complete, executable description of a Build stage. It is produced during Planning and immutable once the Plan exec gate is approved.
```json { "version": "1", "project_id": "0.0.XXXXX", "stage_id": "0.0.XXXXX", "client_id": "dreamborn", "repo_url": "https://github.com/org/repo.git", "worktree_path": "/opt/redk3y/apps/project-name", "phases": [ { "id": "phase-1", "name": "Foundation", "tasks": [ { "local_id": "1.1", "title": "Short descriptive title", "role": "developer", "brief": "Full task brief text...", "output_path": "relative/path/to/output/file", "completion": { "type": "file", "min_length": 500, "evaluate": "Human-readable description of what correct output looks like" }, "depends_on": [] }, { "local_id": "1.2", "title": "...", "role": "developer", "brief": "...", "output_path": "...", "completion": { "type": "file", "min_length": 1000, "evaluate": "..." }, "depends_on": ["1.1"] } ] }, { "id": "phase-2", "name": "Core Pages", "tasks": [ { "local_id": "2.1", "title": "...", "role": "devel
depends_on uses local_id references. Engine translates these to HCS topic IDs when ingesting. local_id values are stable identifiers within a PLAN.json — e.g., "1.1", "2.3".
completion contract is required on every task. It is what the Build Supervisor validates against after each task.complete.
---