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/<repo>-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

File-first artifacts, DB-backed runtime state.
PRD-first planning, board-second execution.
Auto-rotation on churn, but human override remains available.
Structured handoff packets required on every rotation.
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?

4.2 KiB Raw Blame History