# [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