mosaicstack/stack
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases 14 Wiki Activity

docs: note new-session trigger for mission toolset reload
All checks were successful
ci/woodpecker/push/ci Pipeline was successful
Details
ci/woodpecker/pr/ci Pipeline was successful
Details

Browse Source
This commit is contained in:
Jason Woltje
2026-05-07 13:31:43 -05:00
committed by Mos worker
parent b31699de81
commit 647fd9a835
6 changed files with 175 additions and 165 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/mission-control/PRD.md
View File

@@ -57,6 +57,7 @@ This feature unifies those layers into one durable workflow so a mission can sur
**Description:** As an orchestrator, I want to turn a feature idea into a PRD and mission so that agents can work from a durable spec instead of a chat transcript.
**Acceptance Criteria:**
- [ ] `prdy` can emit a PRD with goals, non-goals, and requirements.
- [ ] The PRD is linked to a mission ID.
- [ ] The mission manifest references the PRD path.
@@ -67,6 +68,7 @@ This feature unifies those layers into one durable workflow so a mission can sur
**Description:** As an orchestrator, I want to split a PRD into board tasks so that work can be assigned to specialists.
**Acceptance Criteria:**
- [ ] Each user story can become one or more tasks.
- [ ] Tasks have assignees, dependencies, and estimates.
- [ ] Tasks are machine-readable and durable.
@@ -77,6 +79,7 @@ This feature unifies those layers into one durable workflow so a mission can sur
**Description:** As a coordinator, I want to restart or rotate a session when it short-cycles so that the mission continues with minimal loss.
**Acceptance Criteria:**
- [ ] The coordinator detects compaction pressure or repeated loops.
- [ ] The coordinator writes a handoff summary before rotation.
- [ ] A new session can resume from the handoff packet.
@@ -87,6 +90,7 @@ This feature unifies those layers into one durable workflow so a mission can sur
**Description:** As a worker agent, I want to read the mission and board at startup so I can do the next useful thing without waiting for a human prompt.
**Acceptance Criteria:**
- [ ] Startup loads the active mission manifest.
- [ ] Startup loads the current board/task row.
- [ ] Startup exposes the next action clearly in the prompt.
@@ -97,6 +101,7 @@ This feature unifies those layers into one durable workflow so a mission can sur
**Description:** As an operator, I want a single view of mission health so that I can see progress, blocked tasks, and session churn.
**Acceptance Criteria:**
- [ ] Mission state shows current phase and progress.
- [ ] Board state shows task status by assignee.
- [ ] Short-cycle/rotation events are visible.
@@ -140,16 +145,16 @@ FR-14. The system must keep durable history for rotation and handoff events.
This is the feature discussion board that should drive the mission design.
| Card | Need | Why it matters | Proposed decision |
| --- | --- | --- | --- |
| Canonical mission record | One source of truth for goal/state | Prevents drift between chat, docs, and queue | Make mission manifest the durable root object |
| PRD → board derivation | Break feature ideas into executable work | Lets the plan be assigned and tracked | Keep PRD as the spec, generate board tasks from user stories |
| Session watchdog | Detect churn/short-cycling | Keeps overnight runs productive | Add short-cycle scoring and forced rotation |
| Structured handoff | Preserve context across session changes | Minimizes restart loss | Use a compact JSON/MD handoff packet |
| Worker auto-read | Let agents resume without human re-prompting | Reduces operator overhead | Load mission + board on session start |
| Status surface | Show progress and blockers clearly | Operators need confidence | Expose mission state via CLI and dashboard |
| Review gate | Keep quality high on autonomous work | Prevents silent regressions | Require review tasks before close |
| Recoverability | Resume after failure or restart | Mission should outlive a process | Persist session and handoff history |
| Card | Need | Why it matters | Proposed decision |
| ------------------------ | -------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------ |
| Canonical mission record | One source of truth for goal/state | Prevents drift between chat, docs, and queue | Make mission manifest the durable root object |
| PRD → board derivation | Break feature ideas into executable work | Lets the plan be assigned and tracked | Keep PRD as the spec, generate board tasks from user stories |
| Session watchdog | Detect churn/short-cycling | Keeps overnight runs productive | Add short-cycle scoring and forced rotation |
| Structured handoff | Preserve context across session changes | Minimizes restart loss | Use a compact JSON/MD handoff packet |
| Worker auto-read | Let agents resume without human re-prompting | Reduces operator overhead | Load mission + board on session start |
| Status surface | Show progress and blockers clearly | Operators need confidence | Expose mission state via CLI and dashboard |
| Review gate | Keep quality high on autonomous work | Prevents silent regressions | Require review tasks before close |
| Recoverability | Resume after failure or restart | Mission should outlive a process | Persist session and handoff history |
---