# 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

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?
