# Mission Control Plane — Feature Board > Discussion board for the combined PRD / mission / Kanban workflow. > Use this to decide scope before implementation. ## Board Legend - **Must-have** — required for the first usable version - **Should-have** — strongly preferred, but can ship after the core path - **Could-have** — valuable later if time permits - **Won't-have** — explicitly deferred --- ## Feature Board | Feature Card | Need | Priority | Decision / Notes | | --- | --- | --- | --- | | Canonical mission manifest | One durable root object for goal, PRD, board, session | Must-have | Mission manifest becomes the anchor for all downstream state | | PRD generator integration | PRD should be generated from a feature idea and saved in docs | Must-have | Use Mosaic PRDy format and keep the file human-reviewable | | Board atomization | Break PRD into assignable tasks with dependencies | Must-have | Each user story should map to one or more tasks | | Short-cycle detector | Detect compaction churn and repeated tool loops | Must-have | Coordinator should track churn score per session | | Handoff packet | Preserve actionable context across rotations | Must-have | Use a compact structured summary, not a raw transcript | | Auto-resume workers | Let new sessions read mission + board on start | Should-have | Makes overnight autonomy realistic | | Mission status view | Show current phase, blockers, and active session | Should-have | Expose through CLI first, dashboard later | | Worktree root convention | Keep worktrees off `/tmp` and on the larger persistent drive | Should-have | Prefer `/src/-worktrees` for repo worktrees and long-lived agent work | | Review gate | Prevent autonomous work from shipping unreviewed | Should-have | Use reviewer tasks before mission close | | Rotation policy config | Configure thresholds per mission/profile | Could-have | Keep v1 simple, add tuning later | | Goal decomposition suggestions | Suggest sub-goals from the PRD | Could-have | Good for planning, not necessary for core path | | Cross-channel continuity | Continue a mission across CLI/gateway/remote channels | Could-have | Important later, not required for MVP | | Automatic board sync | Mirror git docs into DB and back | Could-have | Nice-to-have after the file-first flow stabilizes | | Fully autonomous closeout | Let mission finish without human intervention | Won't-have | Keep an operator-visible review step | --- ## Needs Discussion ### 1) Canonical source of truth **Question:** Should the PRD, mission manifest, and board all live in git, or should one be the database source of truth? **Proposed answer:** Keep the human-readable artifacts in git and sync the mission runtime state to the database. ### 2) Scope of automation **Question:** Should the first version auto-create the board from the PRD, or require a human/orchestrator to approve the split? **Proposed answer:** Auto-create a draft board, then let the orchestrator approve or adjust it. ### 3) Rotation triggers **Question:** What should trigger a forced session rotation? **Candidate signals:** - repeated compaction - repeated prompts for permission - identical tool loops - no new file/task state after several turns - task blocked on a missing prerequisite **Proposed answer:** Use a weighted churn score with a small hard cap on repeated compactions. ### 4) Handoff format **Question:** What should the next session receive? **Proposed answer:** - Mission ID - PRD path - Active board task - Completed work - Blockers - Next 3 actions - Non-negotiable constraints ### 5) Operator control **Question:** Should the operator be able to force a rotation or pause the mission? **Proposed answer:** Yes. Human override should win. --- ## Draft Decisions 1. File-first artifacts, DB-backed runtime state. 2. PRD-first planning, board-second execution. 3. Auto-rotation on churn, but human override remains available. 4. Structured handoff packets required on every rotation. 5. Mission close requires a reviewer task. --- ## Open Questions - What exact data fields belong in the mission manifest? - Should rotation thresholds vary by agent profile? - What is the minimum viable status surface for v1? - Should the board support milestones in addition to tasks?