100 lines
3.2 KiB
Markdown
100 lines
3.2 KiB
Markdown
# [Project Name] Onboarding
|
|
|
|
This repository is now in active downstream onboarding mode.
|
|
|
|
Purpose: move from template export into an operating project with PM / CM /
|
|
SM / OM discipline, durable evidence, and milestone execution.
|
|
|
|
## Current Status
|
|
|
|
- collaboration baseline imported
|
|
- operator onboarding checklist not yet started
|
|
- daily minion thread not yet created
|
|
- milestone 0 planning not yet started
|
|
|
|
## Immediate Startup Sequence
|
|
|
|
1. Run and complete [docs/operator-onboarding-checklist.md](docs/operator-onboarding-checklist.md) with the Operator.
|
|
2. Finalize project-specific sections in [MEMORY.md](MEMORY.md):
|
|
- project purpose
|
|
- architecture
|
|
- environments
|
|
- safety constraints
|
|
3. Open first milestone plan in [minions/plans](minions/plans).
|
|
4. Track decisions and handoffs in the active daily thread under [minions/chat/](minions/chat/).
|
|
5. Keep [ROADMAP.md](ROADMAP.md), [TODO.md](TODO.md), and [CHANGELOG.md](CHANGELOG.md) updated during execution.
|
|
|
|
## Roles and Handoff
|
|
|
|
- CM owns implementation truth
|
|
- SM owns security truth and risk framing
|
|
- OM-Test / OM owns runtime truth
|
|
- PM owns gates and acceptance
|
|
- Operator is final authority
|
|
|
|
Role context policy:
|
|
|
|
- each minion may maintain role-specific context in its own file under
|
|
`minions/roles/` (for example: `PM.md`, `CM.md`, `SM.md`, `OM.md`)
|
|
- no minion may alter existing base guardrails/rules without explicit Operator
|
|
approval
|
|
|
|
Git handoff policy:
|
|
|
|
- no minion may hand off implementation work to another minion or the Operator
|
|
until at least one local commit is complete
|
|
- pushing to remote should be explicitly requested/approved by the Operator (or
|
|
follow the repo's PR policy)
|
|
|
|
Default handoff order for changes affecting runtime:
|
|
|
|
1. CM
|
|
2. OM-Test / OM
|
|
3. PM
|
|
4. Operator
|
|
|
|
## Message Format
|
|
|
|
Use this structure for actions requiring a decision or handoff:
|
|
|
|
```text
|
|
DECISION:
|
|
RATIONALE:
|
|
ACTION NEEDED:
|
|
```
|
|
|
|
Optional sections when needed: RISK, BLOCKER, DEADLINE.
|
|
|
|
## Completion Handoff Contract (ADHD-Friendly)
|
|
|
|
All minions must close work with a clear handoff packet in the active daily thread.
|
|
|
|
Required structure (in this exact order):
|
|
|
|
1. `DECISION:` what is now true
|
|
2. `RATIONALE:` why this is the right state
|
|
3. `SCOPE COMPLETED:` what was done
|
|
4. `OUT OF SCOPE:` what was not done
|
|
5. `EVIDENCE:` files, commands, runtime outputs, timestamps as applicable
|
|
6. `BLOCKERS/RISKS:` anything that could stop the next step
|
|
7. `ACTION NEEDED:` explicit next steps with owner labels
|
|
8. `NEXT OWNER:` exactly one of PM, CM, OM-Test, OM, Operator
|
|
9. `READY CHECK:` pass/fail statement for handoff readiness
|
|
|
|
Hard rules:
|
|
|
|
- No minion may mark work complete without naming the `NEXT OWNER`.
|
|
- No minion may accept handoff with ambiguous ownership.
|
|
- If blocked, handoff is still required with a blocker packet and explicit owner for unblock.
|
|
- PM must reject handoffs that do not include evidence and clear next-owner assignment.
|
|
|
|
## Definition of "Onboarded"
|
|
|
|
This project is considered fully onboarded when all are true:
|
|
|
|
- operator onboarding checklist status is approved
|
|
- project-specific MEMORY sections are complete
|
|
- first milestone plan is active
|
|
- daily thread is being used for same-day durable updates
|
|
- rollback posture expectations are explicitly documented
|