chore: initialize minions template repository
This commit is contained in:
40
docs/collaboration-playbook.md
Normal file
40
docs/collaboration-playbook.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# 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
|
||||
53
docs/operator-onboarding-checklist.md
Normal file
53
docs/operator-onboarding-checklist.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# Operator Onboarding Checklist
|
||||
|
||||
Owner: PM
|
||||
Status: not started
|
||||
Date: YYYY-MM-DD
|
||||
|
||||
## 1. Project Framing
|
||||
|
||||
- project name:
|
||||
- objective:
|
||||
- key constraints:
|
||||
- environments in scope:
|
||||
|
||||
## 2. Roles and Boundaries
|
||||
|
||||
- PM assigned: pending Operator confirmation
|
||||
- CM assigned: pending Operator confirmation
|
||||
- SM assigned: pending Operator confirmation
|
||||
- OM-Test assigned: pending Operator confirmation
|
||||
- OM assigned: pending Operator confirmation
|
||||
- any role exceptions approved by Operator: none currently
|
||||
|
||||
## 3. Required Artifacts
|
||||
|
||||
- `MEMORY.md` reviewed and accepted by Operator
|
||||
- `CHANGELOG.md` initialized and owner set
|
||||
- `ROADMAP.md` initialized and owner set
|
||||
- `TODO.md` initialized and owner set
|
||||
- `minion-version.md` reviewed and downstream version format confirmed
|
||||
|
||||
## 4. Escalation Policy (Operator Optional)
|
||||
|
||||
Enabled by Operator: yes/no
|
||||
|
||||
If enabled:
|
||||
|
||||
- production blocker response expectation:
|
||||
- non-critical blocker response expectation:
|
||||
- incident communication expectation:
|
||||
|
||||
## 5. Guardrail Confirmation
|
||||
|
||||
- base guardrails accepted
|
||||
- project-specific guardrails added:
|
||||
- secret and personal-data handling confirmed
|
||||
- machine-specific metadata hygiene confirmed (example: .DS_Store stays untracked)
|
||||
- rollback posture expectation confirmed
|
||||
|
||||
## 6. Sign-Off
|
||||
|
||||
Operator decision: pending
|
||||
|
||||
Notes:
|
||||
Reference in New Issue
Block a user