extra pt2

.config/opencode/.memory/knowledge/patterns/error-handling.md

@@ -0,0 +1,21 @@
+# Error Handling Patterns
+
+## Agent-Level Error Handling
+
+Agents follow the retry circuit breaker pattern defined in `agents/lead.md`:
+
+- After 3 coder rejections on the same task: revisit design, simplify, or consult SME
+- After 5 total failures: escalate to user (Tier-3 escalation)
+
+## Memory Write Errors
+
+Agents with memory-only edit access should:
+1. Write to `.memory/*` files for their recording duties
+2. If write fails, report to lead for escalation
+3. Never attempt to modify non-memory files as a workaround
+
+## Quality Gate Failures
+
+- Reviewer `CHANGES-REQUESTED` is a hard block — do not advance to tester
+- Reviewer `REJECTED` requires redesign — do not retry same approach
+- Tester `PARTIAL` is not a pass — either fix blocker or escalate to user

.config/opencode/.memory/knowledge/patterns/logging.md

@@ -0,0 +1,27 @@
+# Logging Patterns
+
+## Agent Output Standards
+
+Subagents must return actionable results, not status recaps:
+
+| Agent | Expected Output |
+|-------|-----------------|
+| Explorer | File maps, edit points, dependency chains |
+| Researcher | Specific findings, code patterns, API details |
+| Tester | Test results with pass/fail counts and specific failures |
+| Reviewer | Structured verdict with findings and resolution status |
+
+## Recording Discipline
+
+Memory files preserve *knowledge*, not *activity logs*:
+
+- ✅ Record: outcomes, decisions, discoveries, patterns
+- ❌ Don't record: phase transitions, status changes, ceremony checkpoints
+
+## Verdict Tracking
+
+All reviewer/tester findings must be tracked to resolution:
+
+- Status flow: `OPEN → ASSIGNED → RESOLVED | WONTFIX`
+- Findings must not be silently dropped
+- Include unresolved findings in coder re-dispatch

.config/opencode/.memory/knowledge/patterns/testing.md

@@ -0,0 +1,25 @@
+# Testing Patterns
+
+## Verification Tiers
+
+| Tier | Scope | Pipeline |
+|------|-------|----------|
+| Tier 1 | New features, security-sensitive, multi-file refactors | coder → reviewer:correctness → reviewer:security → tester:standard → tester:adversarial |
+| Tier 2 | Moderate changes, UI updates, bug fixes | coder → reviewer:correctness → tester:standard |
+| Tier 3 | Single-file fixes, config tweaks, copy changes | coder → reviewer:correctness |
+
+## Functional Verification Requirements
+
+Static analysis is NOT verification. Every feature must be functionally verified:
+
+- **API endpoints**: Real HTTP requests with response verification
+- **Frontend**: Browser-based or test-suite verification
+- **Full-stack**: End-to-end UI → API → DB → response cycle
+- **Bug fixes**: Reproduce bug, verify it no longer occurs
+
+## What Does NOT Count as Verification
+
+- ❌ Type checks (`tsc`, `bun run check`)
+- ❌ Linting (`eslint`, `ruff`)
+- ❌ Build succeeding
+- ❌ Reading code and concluding "this looks correct"