Phase 1-3: Add memory, skills, and improvement systems

- memory/: cross-session project memory with decisions, lessons, failures,
  architecture, and sessions categories. Each has format templates and
  lifecycle documentation.
- skills/: 12 reusable specialized methodologies (tdd, systematic-debugging,
  architecture-design, code-review, security-review, repository-analysis,
  failure-analysis, refactoring, test-analysis, incident-investigation,
  browser-automation, research). Each has frontmatter and methodology sections.
- improvements/: proposal-based improvement system requiring human approval.
- scripts/memory-lifecycle.sh: deterministic memory operations (recall, store,
  list, search, sessions, cleanup).
- scripts/test-memory-system.sh: 12 structural tests for all new systems.
- orchestrator.md: added Memory Recall stage, Learning and Memory Storage
  stage, Improvement Proposals workflow, memory/skills rules, and 3 new
  actions (A23-A27) to the action catalog. Updated behavioral acceptance test
  and state separation model.
- All 12 subagents: added Memory & Skills Awareness sections with recall
  and store instructions.
- docs/AGENT_ARCHITECTURE.md: documented memory, skills, and improvements
  systems (sections 12-14). Updated action count (27), state model, and
  remaining weaknesses.
- README.md: documented new systems, updated repository layout, added
  test-memory-system.sh documentation.

All 39 tests pass (16 architecture + 12 memory + 11 bootstrap).

skills/systematic-debugging/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: systematic-debugging
+description: Systematic debugging methodology — hypothesis-driven root cause investigation
+version: "1.0"
+owner: Detective
+prerequisites: symptom observed, reproducible failure available
+---
+
+# Systematic Debugging
+
+## When to use this skill
+
+- A test fails, a feature breaks, or behavior diverges from expectation
+- The root cause is not immediately obvious
+- Multiple possible causes exist
+
+## Core methodology
+
+```text
+SYMPTOM → OBSERVE → HYPOTHESIZE → TEST → TRACE → ELIMINATE → ROOT CAUSE
+```
+
+## Step-by-step procedure
+
+### 1. Reproduce the symptom
+- Confirm you can trigger the failure reliably
+- Record the exact command, input, and output
+- Note the environment (OS, versions, state)
+
+### 2. Observe the evidence
+- Read error messages carefully (every word matters)
+- Check logs, stack traces, and output
+- Note what changed since the last working state
+
+### 3. Form hypotheses
+- List possible causes (aim for 3-5)
+- Rank by likelihood based on evidence
+- For each hypothesis: what would be true if this were the cause?
+
+### 4. Test hypotheses
+- Design the cheapest test for the most likely hypothesis
+- Use binary elimination: each test should rule out at least one hypothesis
+- Record what you actually observed vs. what you expected
+
+### 5. Trace the failure
+- Follow the execution path from symptom to cause
+- Add strategic print/log statements if needed
+- Narrow down: which component, which function, which line?
+
+### 6. Eliminate alternatives
+- Explicitly state why other hypotheses are ruled out
+- Document the evidence for each elimination
+
+### 7. Establish root cause
+- State the root cause with confidence level (high/medium/low)
+- Provide supporting evidence (file:line, command output)
+- Identify what conditions make this cause trigger
+
+## Common pitfalls
+
+- Fixing the symptom without understanding the cause
+- Jumping to the most obvious hypothesis without testing it
+- Changing multiple things at once (can't isolate what fixed it)
+- Accepting "it works now" without understanding why
+- Not recording what was eliminated
+
+## Evidence requirements
+
+- Reproduction steps
+- Hypotheses with evidence for/against
+- Root cause statement with confidence level
+- Eliminated alternatives with reasoning
+
+## Exit criteria
+
+- Root cause identified with evidence
+- Alternative hypotheses eliminated with reasoning
+- Confidence level stated (high/medium/low)
+- Report handed off to appropriate agent for resolution