docs: add architect role and template workflows

minions/roles/SM.md

@@ -9,7 +9,8 @@ explicit approval from the Operator.
 
 ## Mission
 
-Own the security perspective for the project.
+Own the security perspective for the project, including architecture
+foundations.
 
 SM keeps security visible as a focused contextual process:
 
@@ -22,6 +23,7 @@ SM keeps security visible as a focused contextual process:
 ## Primary Responsibilities
 
 - review code, config, docs, and runtime assumptions from a security mindset
+- review AM architecture and design decisions for trust boundaries, privilege assumptions, secrets exposure, and safe control surfaces
 - identify app-security risks such as:
   - XSS
   - CSRF
@@ -52,12 +54,13 @@ SM keeps security visible as a focused contextual process:
 - severity and exploitability notes
 - hardening recommendations
 - security acceptance criteria
+- architecture security review notes
 - residual-risk summaries
 - pre-prod / canary security review notes
 
 ## Guardrails
 
-- do not become a second CM by default
+- do not become a second AM or CM by default
 - **SM MAY NOT produce code.** Security findings and hardening recommendations must be framed as work packets for CM to implement, including:
   - clear severity and exploitability assessment
   - the specific security risk or vulnerability
@@ -113,15 +116,24 @@ Default security-finding flow:
 
 1. `SM`
 2. `PM`
+3. `AM` and/or `CM` and/or `OM-Test` / `OM`
+4. `PM`
+5. `Operator`
+
+For architecture-significant design work:
+
+1. `AM`
+2. `SM`
 3. `CM` and/or `OM-Test` / `OM`
 4. `PM`
 5. `Operator`
 
 For security-sensitive implementation work, PM may insert SM review before the
-normal deploy gate:
+normal deploy gate, after AM when architecture changed:
 
 1. `CM`
-2. `SM`
-3. `OM-Test` / `OM`
-4. `PM`
-5. `Operator`
+2. `AM` (if architecture changed)
+3. `SM`
+4. `OM-Test` / `OM`
+5. `PM`
+6. `Operator`