diff --git a/.claude/memory/MEMORY.md b/.claude/memory/MEMORY.md
index 897a83b..e910cac 100644
--- a/.claude/memory/MEMORY.md
+++ b/.claude/memory/MEMORY.md
@@ -1 +1 @@
-- [Inter-agent communication schema](todo_inter_agent_schema.md) — YAML frontmatter envelopes implemented via message-schema skill
+- [Inter-agent communication schema](inter_agent_schema.md) — YAML frontmatter envelopes implemented via message-schema skill
diff --git a/.claude/memory/todo_inter_agent_schema.md b/.claude/memory/inter_agent_schema.md
similarity index 100%
rename from .claude/memory/todo_inter_agent_schema.md
rename to .claude/memory/inter_agent_schema.md
diff --git a/agents/architect.md b/agents/architect.md
index 996ae0c..141dc3b 100644
--- a/agents/architect.md
+++ b/agents/architect.md
@@ -2,7 +2,7 @@
 name: architect
 description: Research-first planning agent. Handles triage, research coordination, architecture design, and wave decomposition. Use before any non-trivial implementation task. Produces the implementation blueprint the entire team follows.
 model: opus
-effort: high
+effort: max
 permissionMode: plan
 tools: Read, Glob, Grep, WebFetch, WebSearch, Bash, Write
 disallowedTools: Edit
diff --git a/rules/01-session.md b/rules/01-session.md
index f3db2d6..bbf053a 100644
--- a/rules/01-session.md
+++ b/rules/01-session.md
@@ -1,8 +1,8 @@
 # Session Behavior
 
 - Treat each session as stateless — do not assume context from prior sessions
-- The CLAUDE.md hierarchy is the only source of persistent context
-- If something needs to carry forward across sessions, it belongs in a CLAUDE.md file, not in session memory
+- The CLAUDE.md hierarchy and `.claude/memory/` are the only sources of persistent context
+- If something needs to carry forward across sessions, persist it in the appropriate file — not in session memory
 
 # Project Memory
 
diff --git a/settings.json b/settings.json
index 3e584c6..582b9a2 100644
--- a/settings.json
+++ b/settings.json
@@ -19,18 +19,15 @@
       "Read(~/.ssh/**)",
       "Read(~/.aws/**)",
       "Read(~/.gnupg/**)",
-      "Read(**/.env)",
-      "Read(**/.env.*)",
+      "Read(**/.env*)",
       "Write(~/.ssh/**)",
       "Write(~/.aws/**)",
       "Write(~/.gnupg/**)",
-      "Write(**/.env)",
-      "Write(**/.env.*)",
+      "Write(**/.env*)",
       "Edit(~/.ssh/**)",
       "Edit(~/.aws/**)",
       "Edit(~/.gnupg/**)",
-      "Edit(**/.env)",
-      "Edit(**/.env.*)"
+      "Edit(**/.env*)"
     ],
     "ask": [
       "Bash(rm *)",
diff --git a/skills/orchestrate/SKILL.md b/skills/orchestrate/SKILL.md
index a940ded..9085dde 100644
--- a/skills/orchestrate/SKILL.md
+++ b/skills/orchestrate/SKILL.md
@@ -13,7 +13,7 @@ You (orchestrator)
   ├── worker        (sonnet default — haiku for trivial, opus for architectural)
   ├── debugger      (sonnet) — bug diagnosis and minimal fixes
   ├── documenter    (sonnet) — documentation only, never touches source
-  ├── researcher    (sonnet, background) — one per topic, parallel fact-finding
+  ├── researcher    (sonnet) — one per topic, parallel fact-finding
   ├── architect     (opus, effort: max) — triage, research coordination, architecture, wave decomposition
   ├── reviewer      (sonnet) — code quality + AC verification + claim checking
   └── auditor       (sonnet, background) — security analysis + runtime validation
@@ -104,7 +104,7 @@ For each wave in the plan:
 After each wave, spawn `reviewer` and `auditor` in a single response. They run in parallel.
 
 - **Always spawn `reviewer`**
-- **Spawn `auditor` when:** risk tags include `security`, `auth`, `data-mutation`, or `concurrent` — or any code that can be built and tested
+- **Spawn `auditor` when:** risk tags include `security`, `auth`, `data-mutation`, or `concurrent`
 
 Both receive: worker output, plan file path, acceptance criteria list, risk tags.
 
diff --git a/skills/qa-checklist/SKILL.md b/skills/qa-checklist/SKILL.md
index 844d752..fb4caec 100644
--- a/skills/qa-checklist/SKILL.md
+++ b/skills/qa-checklist/SKILL.md
@@ -44,7 +44,9 @@ Before returning your output, validate against every item below. If you find a v
 - Does the `type` field match your message type?
 - Does the `signal` field use a valid enum value from the message-schema skill?
 - Are all required fields for your message type present?
-- Are hard rules satisfied (e.g., `critical_count > 0` requires `signal: fail`)?
+- Are hard rules satisfied?
+  - `review_verdict`: `critical_count > 0` requires `signal: fail`
+  - `audit_verdict`: `security_findings.critical > 0` or `build_status: fail` or `test_status: fail` requires `signal: fail`
 
 ## After validation