134 lines
4.9 KiB
Markdown
134 lines
4.9 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, AM, CM,
|
|
SM, and OM discipline, durable evidence, and milestone execution.
|
|
|
|
## Current Status
|
|
|
|
- collaboration baseline imported
|
|
- operator onboarding checklist not yet started
|
|
- mailbox coordination not yet initialized
|
|
- PM daily summary thread not yet created
|
|
- milestone 0 planning not yet started
|
|
|
|
## Immediate Startup Sequence
|
|
|
|
1. Establish a filtered vendored template snapshot and perform the first controlled export using [docs/downstream-onboarding-playbook.md](docs/downstream-onboarding-playbook.md).
|
|
2. Run and complete [docs/operator-onboarding-checklist.md](docs/operator-onboarding-checklist.md) with the Operator.
|
|
3. Finalize project-specific sections in [MEMORY.md](MEMORY.md):
|
|
- project purpose
|
|
- architecture
|
|
- environments
|
|
- safety constraints
|
|
4. Open first milestone plan in [minions/plans](minions/plans).
|
|
5. Bootstrap mailbox coordination:
|
|
- read [MEMORY.md](MEMORY.md)
|
|
- read [docs/project/mailbox-collaboration-model.md](docs/project/mailbox-collaboration-model.md)
|
|
- read [minions/mail/README.md](minions/mail/README.md)
|
|
- read [minions/mail/packet-template.md](minions/mail/packet-template.md)
|
|
- use [minions/mail/](minions/mail/) for new actionable packets
|
|
- use [minions/chat/](minions/chat/) for PM daily summaries
|
|
6. Keep [ROADMAP.md](ROADMAP.md), [TODO.md](TODO.md), and [CHANGELOG.md](CHANGELOG.md) updated during execution.
|
|
7. Use [docs/downstream-upgrade-playbook.md](docs/downstream-upgrade-playbook.md) for later template updates.
|
|
|
|
## Roles and Handoff
|
|
|
|
- AM owns architecture truth and design direction
|
|
- 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`, `AM.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 workflow state, implementation state, or decision-ready
|
|
work to another minion or the Operator until at least one local commit
|
|
captures the current change set
|
|
- a local commit is the minimum handoff checkpoint for every minion role
|
|
- if the next owner is operating on a different computer, handoff requires both
|
|
a commit and a push so the work is actually available to them
|
|
- the Operator decides the default handoff sync mode for each role:
|
|
`commit-only` or `commit-and-push`
|
|
- the default may differ by role, but `commit-and-push` is mandatory whenever
|
|
the next owner is on a different computer
|
|
- if remote-visible handoff is required, follow the repo's PR/push policy
|
|
|
|
Default flow when the work changes architecture, system boundaries, data flow,
|
|
major dependencies, or overall design direction:
|
|
|
|
1. PM
|
|
2. AM
|
|
3. SM
|
|
4. CM
|
|
5. OM-Test / OM
|
|
6. PM
|
|
7. Operator
|
|
|
|
Implementation-to-runtime flow inside an approved architecture:
|
|
|
|
1. CM
|
|
2. SM
|
|
3. OM-Test / OM
|
|
4. PM
|
|
5. 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 on the active packet
|
|
surface. Default: `minions/mail/`. During staged rollout, `PM` may allow an
|
|
already-open legacy chat packet to close where it started.
|
|
|
|
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, AM, CM, SM, 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 hand off work without meeting the active commit/push rule set
|
|
by the Operator for that role and handoff.
|
|
- 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
|
|
- mailbox packets are being used for new actionable work
|
|
- PM daily summary thread is being used for same-day durable recap
|
|
- rollback posture expectations are explicitly documented
|