minions-template/INIT.md

[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.
2. Run and complete docs/operator-onboarding-checklist.md with the Operator.
3. Finalize project-specific sections in MEMORY.md:
   • project purpose
   • architecture
   • environments
   • safety constraints
4. Open first milestone plan in minions/plans.
5. Bootstrap mailbox coordination:
   • read MEMORY.md
   • read docs/project/mailbox-collaboration-model.md
   • read minions/mail/README.md
   • read minions/mail/packet-template.md
   • use minions/mail/ for new actionable packets
   • use minions/chat/ for PM daily summaries
6. Keep ROADMAP.md, TODO.md, and CHANGELOG.md updated during execution.
7. Use 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:

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