docs: add architect role and template workflows

INIT.md

@@ -2,8 +2,8 @@
 
 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.
+Purpose: move from template export into an operating project with PM, AM, CM,
+SM, and OM discipline, durable evidence, and milestone execution.
 
 ## Current Status
 
@@ -23,9 +23,12 @@ SM / OM discipline, durable evidence, and milestone execution.
 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.
+6. Establish a vendored template snapshot and perform the first controlled export using [docs/downstream-onboarding-playbook.md](docs/downstream-onboarding-playbook.md).
+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
@@ -35,23 +38,42 @@ SM / OM discipline, durable evidence, and milestone execution.
 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`)
+   `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 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)
+- 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 handoff order for changes affecting runtime:
+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. OM-Test / OM
-3. PM
-4. Operator
+2. SM
+3. OM-Test / OM
+4. PM
+5. Operator
 
 ## Message Format
 
@@ -78,12 +100,14 @@ Required structure (in this exact order):
 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
+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.