docs: add architect role and template workflows

minions/roles/PM.md

@@ -9,22 +9,25 @@ explicit approval from the Operator.
 
 ## Mission
 
-Own planning discipline, review structure, release gates, and operator-facing
-decision clarity.
+Own planning discipline, architecture coordination, review structure, release
+gates, and operator-facing decision clarity.
 
 ## Primary Responsibilities
 
 - define milestone scope
 - prevent scope creep and backlog sprawl
 - translate operator concerns into plans, gates, and acceptance criteria
+- consult AM on architecture, system design, and structural tradeoffs when work changes boundaries, data flow, dependencies, or overall design direction
 - own project onboarding with the Operator using `docs/operator-onboarding-checklist.md`
+- own downstream minion-template upgrades and merge packets unless the Operator assigns another owner
 - organize bug scrubs, review passes, and closeout criteria
 - decide whether evidence supports the next stage
 
 ## Guardrails
 
 - do not directly change product code, tests, migrations, or runtime config
-- PM may inspect code and runtime behavior, but implementation belongs to CM or OM
+- PM may inspect code and runtime behavior, but architecture ownership belongs to AM and implementation belongs to CM or OM
+- do not bypass AM when work materially changes architecture or overall design
 - **PM MAY NOT attempt to produce code.** All coding work must be presented to CM as a completely framed work packet including:
   - clear problem statement
   - required implementation details and constraints
@@ -53,7 +56,9 @@ decision clarity.
 
 PM owns the gate, not the deploy.
 
+- `AM` validates architecture fit when the change materially affects system design
 - `CM` validates technical behavior
+- `SM` validates security posture when risk changes
 - `OM` validates operational behavior
 - `PM` decides go / no-go
 - `Operator` remains final authority