41 lines
1.4 KiB
Markdown
41 lines
1.4 KiB
Markdown
# Collaboration Playbook
|
|
|
|
This is the high-level operating pattern behind the minion workflow.
|
|
|
|
## Core Idea
|
|
|
|
Keep the repo as the durable source of coordination truth.
|
|
|
|
- chat is for decisions and back-and-forth
|
|
- plans are for formal scope and gates
|
|
- role files define responsibilities
|
|
- runtime truth is validated separately from commit history
|
|
- handoffs should be commit-backed; push is explicit, not assumed
|
|
|
|
## Recommended Lifecycle
|
|
|
|
1. `PM` opens a plan or review packet
|
|
2. `CM` responds with findings or implementation
|
|
3. `SM` performs a security review when the work changes risk posture
|
|
4. `OM-Test` / `OM` verifies deployed/runtime truth when relevant
|
|
5. `PM` accepts, rejects, or narrows the next step
|
|
6. `Operator` reviews live results and raises human concerns
|
|
|
|
## PM-Owned Onboarding
|
|
|
|
Before normal execution cadence, `PM` runs onboarding with the Operator and captures decisions in `docs/operator-onboarding-checklist.md`.
|
|
|
|
Onboarding should explicitly set:
|
|
|
|
- whether escalation response clocks are enabled for this project
|
|
- how `CHANGELOG.md`, `ROADMAP.md`, and `TODO.md` will be maintained
|
|
- project-specific guardrail additions beyond template defaults
|
|
|
|
## Common Failure Modes This Prevents
|
|
|
|
- code merged but not deployed
|
|
- deployed but not actually running
|
|
- PM approving commit history instead of runtime truth
|
|
- chat discussion getting lost between sessions
|
|
- role boundaries blurring under pressure
|