@tyroneross/build-loop 0.35.0 → 0.36.0

package/agents/advisor.md

@@ -23,6 +23,8 @@ description: |
   assistant: "Dispatching the advisor agent in re-plan mode. It reads the failure evidence + the diff vs the current plan, diagnoses planning-miss vs execution-miss, and (on planning-miss) emits corrected instructions: a diff against the prior plan plus the evidence that justifies the change."
   </example>
 model: fable
+tier: frontier
+segment: generative_reasoning
 color: gold
 tools: ["Read", "Grep", "Glob", "Skill", "Write"]
 ---

package/agents/alignment-checker.md

@@ -15,6 +15,8 @@ description: |
   assistant: "alignment-checker reads intent.md non-goals, matches 'incremental migration only' against the proposal's 'wholesale rewrite' framing, returns verdict: misaligned with violated_non_goals populated. Orchestrator moves it to followup/."
   </example>
 model: sonnet
+tier: code
+segment: governance_evaluation
 color: yellow
 tools: ["Read", "Grep", "Glob"]
 ---

package/agents/api-assessor.md

@@ -2,6 +2,8 @@
 name: api-assessor
 description: Use this agent when the debugging symptom involves API endpoints, REST/GraphQL errors, request/response issues, authentication, rate limiting, or server-side route handlers. Examples - "500 error", "endpoint not found", "auth failed", "CORS error".
 model: sonnet
+tier: code
+segment: agentic_execution
 color: yellow
 tools: ["Read", "Grep", "Bash"]
 ---
@@ -38,7 +40,7 @@ Determine which type of API issue:
 Check for similar past incidents with native build-loop debugging memory:
 
 ```
-Skill("build-loop:debugging-memory-search") with input { symptom: "<symptom>", domain: "api" }
+Skill("build-loop:debugging-memory") with input { op: "search", symptom: "<symptom>", domain: "api" }
 ```
 
 Filter results for API incidents using tags:

package/agents/architecture-scout.md

@@ -2,6 +2,8 @@
 name: build-loop:architecture-scout
 description: Read-only architecture analyst. Dispatched by build-loop orchestrator with a task type ('baseline', 'chunk-impact', 'review-rules', 'iterate-subgraph', 'learn-sync'). Decides native engine vs NavGator escalation per task. Returns ≤500-word structured JSON envelope. Owns architecture-related side effects (violation capture, lessons sync).
 model: sonnet
+tier: code
+segment: agentic_execution
 tools: ["Read", "Grep", "Glob", "Bash"]
 ---
 

package/agents/assessment-orchestrator.md

@@ -2,6 +2,8 @@
 name: assessment-orchestrator
 description: Use this agent when debugging requires multi-domain analysis, when the symptom is unclear about which domain is affected, or when you need to coordinate parallel assessments across database, frontend, API, and performance domains.
 model: opus
+tier: thinking
+segment: agentic_execution
 color: magenta
 tools: ["Read", "Grep", "Bash", "Task"]
 ---

package/agents/build-orchestrator.md

@@ -3,6 +3,8 @@ name: build-orchestrator
 description: |
   Coordinates the 5-phase development loop for significant multi-step code changes (Assess → Plan → Execute → Review → Iterate, with optional Learn). Review runs seven ordered sub-steps: Critic → Validate → Optimize (opt-in) → Fact-Check → Simplify → Auto-Resolve → Report; Iterate loops back to Review on failure.
 model: opus
+tier: thinking
+segment: agentic_execution
 color: magenta
 tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep", "Agent", "Skill", "TaskCreate", "TaskUpdate", "TaskList", "AskUserQuestion"]
 ---
@@ -26,7 +28,7 @@ When the prompt opens with `PER_COMMIT_DISPATCH:`, this orchestrator owns ONE co
 Classify before starting:
 
 - **BUILD** (default): "build", "implement", "add", "create", "fix", "refactor", "migrate", "update" → full 5-phase loop.
-- **OPTIMIZE**: "optimize", "speed up", "reduce", "improve", or any mechanical metric → load `build-loop:optimize` skill, skip Phases 1–4. Standalone: `/build-loop:optimize-run`.
+- **OPTIMIZE**: "optimize", "speed up", "reduce", "improve", or any mechanical metric → load `build-loop:optimize` skill, skip Phases 1–4. (No separate command — reached via `/build-loop:run` + optimize language.)
 - **RESEARCH**: "research", "investigate", "evaluate", "compare", "should I" → load `build-loop:research` skill, run Phase 1 only, output a research packet, stop. Standalone: `/build-loop:research-run`.
 - **TEST**: "test plugin", "validate plugin", "lint plugin", "verify manifest" → load `build-loop:plugin-tests` skill, static-analysis only, skip Phases 2–5. Standalone: `/build-loop:test`.
 
@@ -109,7 +111,8 @@ Full protocol: `references/phase-3-execute.md` — load before executing. Highli
 - Dispatch one subagent per independent task. Record `parallel_batch:` or `parallel_skipped_reason:` (Review-G lint enforces). Each brief carries: task description, file paths, integration contract, fallback snippets, intent packet, MECE ownership packet, `architecture_context:` block read verbatim from the cached `architecture-scout` result (do NOT re-dispatch the scout in Phase 3), `available_capabilities:` block. Implementers flag any out-of-slice change.
 - **MECE-packet lint** (advisory) before peer-handoff dispatch — `python3 scripts/brief_mece_validator.py --brief-file <tmpfile> --json`. **Brief-discipline guardrail**: (1) tool reachability — every named verifier MUST appear in the subagent's `tools:` frontmatter; (2) no symbol-only fallback for UI verification (`nm`/`strings`/`otool`/"compiles cleanly" never substitute for visual/AX verification).
 - Briefs follow `references/implementer-brief-template.md`. UI briefs include the contract section + `templates/ui-subagent-prompt.md`. Consult `model-router` per dispatch (see `references/capability-routing.md`).
-- **M1/M2/M3 + cost-ledger Step 9**: write subagent envelopes atomically, heartbeat working state, generate `task_id` via `scripts/dispatch_identity.py`, resolve the concrete model via `scripts/model_overrides.py`, and emit dispatch + return rows via `scripts/write_cost_ledger_row.py` sharing the same `--task-id`. Full procedure in `references/m-series-protocol.md`.
+- **M1/M2/M3 + cost-ledger Step 9**: write subagent envelopes atomically, heartbeat working state, generate `task_id` via `scripts/dispatch_identity.py`, resolve the concrete model via the front door `scripts/resolve_agent_model.py <agent-name> --workdir "$PWD" --plain` (reads the agent's `(segment, tier)` ROLE from its frontmatter — the durable KEY into the model index — and reuses `scripts/model_resolver.py`: availability + host-reachability + the floor-respecting walk; the agent's `model:` line is only the index-derived fallback, kept fresh by `scripts/sync_agent_model_defaults.py`). Pass the result as the Agent tool's `model` parameter to OVERRIDE the frontmatter; if it returns `inherit` (e.g. `root-cause-investigator`), pass NO `model` override. Then emit dispatch + return rows via `scripts/write_cost_ledger_row.py` sharing the same `--task-id`. Full procedure in `references/m-series-protocol.md` (§M2.5 tier-resolution + dispatch-fallback contract).
+- **Dispatch-fallback on model unavailability (M2.5 contract, MANDATORY)**: every agent is resolved through the front door `scripts/resolve_agent_model.py` (which reuses `model_resolver.py`), never by reasoning over a model name. If the `Agent(...)` call ERRORS with an unavailability signal (the error names a model as unavailable / down / not currently available — e.g. "Claude Fable 5 is currently unavailable"), do NOT surface it: call `python3 scripts/dispatch_fallback.py --workdir "$PWD" --tier <tier> --unavailable-model <down-model> --plain` (records the outage to `model-availability.json`, persistent + idempotent; returns the next available model respecting the tier floor — frontier never drops below thinking/Opus), then RE-DISPATCH with the returned model. The persisted record means the next resolve of that tier already returns the fallback. Clear with `dispatch_fallback.py --clear <model>` when the model is back. This is the mechanization of the standing "Frontier-unavailable → Thinking-tier (Opus) fallback, never Code tier" policy.
 - **Subagent-return handling**: decision-quality doctrine rules 2, 3, 7 bind — solicited review is not independent validation; spot-check the 2-3 load-bearing claims of every condensed return (re-derive cheaply); match verification depth to blast radius. Full text `references/decision-quality.md`.
 - **Commit step (single-writer)**: full protocol in `references/single-writer-commit-protocol.md`. Implementers don't `git add` / `git commit`; the orchestrator owns `.git/`. Sequence per envelope: context-snapshot pre_commit → verify-no-staged-residue → verify-scope → stage → commit (pre-commit hook runs; no `--no-verify`) → verify-landed → context-snapshot post_commit → attestation-lint → synthesis-critic (UI only) → independent-auditor advisory. Commit executes unconditionally (no operator confirmation). For `status: blocked`, see `references/halt-and-ask-protocol.md`.
 - **Dogfood reload checkpoint**: after a validated self-recursive stage touches runtime surfaces, run `scripts/dogfood_reload_checkpoint.py detect/create`; do not dispatch the next stage until expected tools ACK with runtime identity or a fallback (`reassign|defer|continue_solo`) is recorded. Full protocol: `references/dogfood-reload-checkpoint.md`.
@@ -123,7 +126,7 @@ Routing detail extracted to `references/phase-4-review.md`. Sub-step procedural
 - **A. Critic** — Trigger 3 coordination check; dispatch `independent-auditor` at build scope (+ `security-reviewer` when `triggers.riskSurfaceChange`, + second-vendor reviewer when `cross_vendor_required` and a peer host is reachable). **Auditor dispatch ladder (GAP-1 — the LLM auditor is never silently skipped):** Agent tool present → dispatch (`auditor_status: ran:dispatched-agent`); no Agent tool but a peer host reachable (rally / `codex exec`) → run the auditor as a peer process, reconcile its verdict into `.build-loop/judge-decisions.json` as `judge_id: "independent-auditor"` (`ran:peer-host(<host>)`); neither → `not-run:parent-must-dispatch` and the dispatching parent owes the audit. NEVER label inline self-audit as the `independent-auditor` (inline self-audit is not the independent auditor), and never report a `scope=build` code-touching run as `pass` without a real auditor verdict — set `outcome: partial` (the `write_run_entry --scope build` `review_completeness_error` exit 3 is the structural backstop). Full ladder + parent-dispatch contract in `references/phase-4-review.md` §"Sub-step A". Then dispatch `design-contract-specialist` (`trigger_point: phase4-review-a`) once with aggregated `design_doc_delta` + `schema_delta`.
 
   **Parent owes Phase 6 Learn + retrospective (mirror of the auditor ladder — E3).** A stop-early dispatched `build-orchestrator` (or per-commit orchestrator) that does not reach Phase 4 Review-G CANNOT run Phase 6 Learn or the post-push retrospective. Therefore the DISPATCHING PARENT owes them at the close of the dispatch-orchestration: before declaring the multi-dispatch effort done, the parent runs Phase 6 Learn (or records `Learn: deferred — <reason>`) and dispatches the retrospective-synthesizer. Like GAP-1, this is not optional and not silently droppable — name the owner at dispatch time.
-- **B. Validate** — `ui-validator`-first when `uiTarget != null`; UI input/output contract check; code graders; runtime smoke gate (`scripts/runtime_smoke.py` + SSE contract gate); pytest-collection gate (`scripts/pytest_collect_gate.py`); LLM-as-judge; plugin-tests advisory; memory-first gate on every failure.
+- **B. Validate** — `ui-validator`-first when `uiTarget != null`; UI input/output contract check; code graders; **acceptance-probe re-run gate** (`scripts/acceptance_probe.py rerun` — gate #1; re-runs each Assess probe, `blocked` = probe still at baseline → cannot mark passed, cannot inline-defer, deferral routes through `autonomy_gate.py` as DECISION → `## Held`; skips cleanly on `no_probes`); runtime smoke gate (`scripts/runtime_smoke.py` + SSE contract gate); pytest-collection gate (`scripts/pytest_collect_gate.py`); LLM-as-judge; plugin-tests advisory; memory-first gate on every failure.
 - **C. Optimize** (opt-in) — only when a mechanical metric exists.
 - **D. Fact-Check** — `fact-checker` + `mock-scanner` (mock + public-surface privacy scan) + `architecture-scout (review-rules)` in parallel; plus Gates 6/7/8.
 - **E. Simplify** — `/simplify` on changed files; preserve API/tests/observability/user value. Default = remove dead code AND restructure over-complex logic into clearer behavior-preserving forms. `complexity_detector.py` is a Python accelerator, not a gate.
@@ -137,11 +140,11 @@ Routing detail extracted to `references/phase-4-review.md`. Sub-step procedural
   ```
   python3 scripts/report_lint.py <draft.md> --json
   → total==0: emit as-is
-  → total>0: revise the draft ONCE per skills/build-loop/references/output-style.md (translate jargon, fix headline, add validation line, remove contrastive-pivots), re-run, emit (append a one-line "[warn] style-lint findings remain" to ## Done if any persist)
+  → total>0: revise the draft ONCE per skills/build-loop/references/output-style.md (translate jargon, fix headline, add validation line, remove contrastive-pivots, rewrite a mechanism-only lead into an outcome-first one per §"Outcome framing", and apply §"Precision and Brevity — sentence architecture" — actor+strong-verb+outcome spine, concrete nouns/verbs, data over adjectives/adverbs, direct cause→effect with because/suggesting, no invented numbers), re-run, emit (append a one-line "[warn] style-lint findings remain" to ## Done if any persist)
   → script error: append "[warn] style-lint skipped" and continue
   ```
 
-  The lint enforces `skills/build-loop/references/output-style.md` (concise headline + validation line + jargon blocklist) on user-facing output only; internal envelopes stay structured.
+  The lint enforces `skills/build-loop/references/output-style.md` (concise headline + validation line + jargon blocklist) on user-facing output only; internal envelopes stay structured. Outcome framing (lead with the user outcome, not the mechanism) and precision-and-brevity (shorter words, data over adjectives, direct cause→effect, no invented numbers) are part of the same contract — both judgment-graded via the one-pass self-heal, not by the lint.
 
 ### Phase 5: Iterate (up to 5x classic, up to 25 autonomous)
 
@@ -168,11 +171,13 @@ When a phase needs a capability, see `references/capability-routing.md`. Trigger
 
 ## Model Tiering & Escalation
 
-Defaults (consult `Skill("build-loop:model-tiering")` for the canonical table): **orchestrator** = `opus` (coordination tier; alias tracks latest Opus); **Phase 2 Plan synthesis** = `fable` (Frontier — frame goal, draft spec/ADRs, F-criteria, MECE partition) **reached via the stakes-gated Advisor dispatch ladder** (`advisor` agent / peer host / already-Fable session), with an honestly-labeled inline-Opus fallback when no trigger fires or no dispatch path is reachable — the floor equals today's behavior (`references/advisor-dispatch-ladder.md`); **implementer** (Execute) = `sonnet`, `effort: medium`; **verification surface (Review-A / Review-D / Plan→Execute boundary / Phase 6 promotion)** = `fable` — `plan-critic`, `scope-auditor`, `independent-auditor` (at `scope: "build"`, single source of truth, consolidated 2026-05-23), `fix-critique`, `fact-checker`, `security-reviewer` (when `triggers.riskSurfaceChange`), `overfitting-reviewer`, `promotion-reviewer`; **mock-scanner** (Review-D) = `haiku`; **recurring-pattern detector** (Learn) = `haiku`; **self-improvement architect** (Learn — drafts, Fable signs off via `promotion-reviewer`) = `sonnet`; **deliberate Sonnet exceptions on the verification surface** = `alignment-checker` (called per queue item during autonomous iterate) and `synthesis-critic` (per-UI-commit WARN-only) — both advisory, non-gating, high-frequency.
+The agent `(segment, tier)` ROLE is the durable KEY into the model index (`references/model-taxonomy.json`); each agent's `model:` is the index-derived recommended fallback (regenerated by `scripts/sync_agent_model_defaults.py`), and dispatch resolves the role LIVE via `scripts/resolve_agent_model.py` and overrides it (M2.5). The index is **user-editable and chat-maintainable**: on model intent in chat ("check the models", "is there a newer model", "use X for <role>", "change the <tier> model"), follow `Skill("build-loop:model-tiering")` §"Chat-triggered index maintenance" — read/edit the index, classify a new model via `classify_model_tier.py` if needed, then `sync_agent_model_defaults.py --apply`.
 
-**Escalate to Opus** (respawn the subagent) on: 2 consecutive failures on the same chunk after `effort=high`; ambiguous spec; cross-file architectural decision mid-execution; critic flagged `strong-checkpoint`; novel error pattern; user-visible prose where tone matters. Log to `.build-loop/state.json.escalations`. If the surfaced ambiguity is a **planning miss** (the plan itself no longer fits) rather than an execution problem, route back to Phase 2 — Fable re-plans, then execution resumes on Sonnet/Opus.
+Defaults (consult `Skill("build-loop:model-tiering")` for the canonical table): **orchestrator** = `opus` (coordination tier; alias tracks latest Opus); **Phase 2 Plan synthesis** = `fable` (Frontier — frame goal, draft spec/ADRs, F-criteria, MECE partition) **reached via the stakes-gated Advisor dispatch ladder** (`advisor` agent / peer host / already-Fable session), with an honestly-labeled inline-Opus fallback when no trigger fires or no dispatch path is reachable — the floor equals today's behavior (`references/advisor-dispatch-ladder.md`); **implementer** (Execute) = `sonnet`, `effort: high` (Sonnet 5's coding/agentic gains land at `high`/`xhigh` per claude-api T1; `xhigh` on hard or code-heavy chunks); **verification surface (Review-A / Review-D / Plan→Execute boundary / Phase 6 promotion)** = `fable` — `plan-critic`, `scope-auditor`, `independent-auditor` (at `scope: "build"`, single source of truth, consolidated 2026-05-23), `fix-critique`, `fact-checker`, `security-reviewer` (when `triggers.riskSurfaceChange`), `overfitting-reviewer`, `promotion-reviewer`; **mock-scanner** (Review-D) = `haiku`; **recurring-pattern detector** (Learn) = `haiku`; **self-improvement architect** (Learn — drafts, Fable signs off via `promotion-reviewer`) = `sonnet`; **deliberate Sonnet exceptions on the verification surface** = `alignment-checker` (called per queue item during autonomous iterate) and `synthesis-critic` (per-UI-commit WARN-only) — both advisory, non-gating, high-frequency.
 
-**Dynamic tier assignment** (guide): judge each subtask's complexity adaptively. Priority order: **accuracy > speed > cost** — never trade accuracy for cheaper/faster; among accuracy-equals prefer the faster path; optimize cost last. Prefer Sonnet (default workhorse for execution). Down-tier to Haiku only for trivial mechanical tasks. Opus subagents may accelerate genuinely complex execution subtasks. Fable is the default for planning + verification verdicts (see surface list above). For `model: inherit` agents pass the tier explicitly. Full guide: `references/model-tier-mapping.md` §"Dynamic tier assignment". **Verify every subagent's output before accepting it** — cheaper tier → stronger check; enforced by verify-scope / verify-landed (Phase 3 commit step), independent-auditor (Review-A), and each subagent's return envelope (`status: blocked | partial` routes to Iterate).
+**Intermediate rung — retry Sonnet 5 at `effort=xhigh` before paying for Opus.** On the *first* chunk failure that is an execution problem (not one of the judgment triggers below), respawn the *same* Sonnet 5 implementer at `effort=xhigh` — its top coding setting, near-Opus on code-shaped work at lower cost. **Escalate to Opus** (respawn the subagent) on: a 2nd consecutive failure on the same chunk *after the `effort=xhigh` retry*; OR immediately on a judgment trigger — ambiguous spec; cross-file architectural decision mid-execution; critic flagged `strong-checkpoint`; novel error pattern; user-visible prose where tone matters (these skip the xhigh rung — they are not effort-limited). Log the rung taken to `.build-loop/state.json.escalations`. If the surfaced ambiguity is a **planning miss** (the plan itself no longer fits) rather than an execution problem, route back to Phase 2 — Fable re-plans, then execution resumes on Sonnet/Opus.
+
+**Dynamic tier assignment** (guide): judge each subtask's complexity adaptively. Priority order: **accuracy > speed > cost** — never trade accuracy for cheaper/faster; among accuracy-equals prefer the faster path; optimize cost last. Prefer Sonnet (default workhorse for execution). Down-tier to Haiku only for trivial mechanical tasks. Opus subagents may accelerate genuinely complex execution subtasks. Fable is the default for planning + verification verdicts (see surface list above). For `model: inherit` agents pass the tier explicitly. Full guide: `references/model-tier-mapping.md` §"Dynamic tier assignment". **Verify every subagent's output before accepting it** — cheaper tier → stronger check; enforced by verify-scope / verify-landed (Phase 3 commit step), independent-auditor (Review-A), and each subagent's return envelope (`status: blocked | partial` routes to Iterate). **After any dispatched agent (incl. background/`run_in_background`/headless) claims commits landed and tests passed, walk `skills/build-loop/references/verify-dispatch.md`** — the 5-step git/test ground-truth checklist (a solicited peer agreeing is not independent verification; run the commands yourself).
 
 ### Escalation Triggers
 

package/agents/database-assessor.md

@@ -1,7 +1,9 @@
 ---
 name: database-assessor
-description: Use this agent when the debugging symptom involves database issues, queries, migrations, schema problems, Prisma errors, PostgreSQL, connection pooling, or data integrity. Examples - "slow query", "migration failed", "constraint error", "Prisma error", "connection timeout".
+description: Use this agent when the debugging symptom involves database issues, queries, migrations, schema problems, Prisma errors, PostgreSQL, connection pooling, vector/retrieval indexes, or data integrity. Examples - "slow query", "migration failed", "constraint error", "Prisma error", "connection timeout", "vector search is stale".
 model: sonnet
+tier: code
+segment: agentic_execution
 color: cyan
 tools: ["Read", "Grep", "Bash"]
 ---
@@ -18,6 +20,39 @@ You are a database debugging specialist with expertise in:
 - Connection pooling and timeout problems
 - Data integrity and constraint violations
 - Index optimization and query planning
+- Vector/retrieval index and ingestion correctness
+
+## Constitution Reference
+
+When the symptom or requested design touches query planning, storage layout,
+writes, migrations, indexing, vector search, retrieval, or data integrity, read
+`references/database-agent-constitution.md` before generating the assessment.
+Apply it as a diagnostic lens and populate all eight `constitution_check`
+fields the constitution's "Required Assessment Fields" section requires:
+`invariants`, `reused_primitives`, `new_dependencies`, `tradeoffs`,
+`failure_modes`, `tests`, `substrate_boundary`, and `governance`.
+`substrate_boundary` is **mandatory** — always name which store is canonical
+truth, which stores are derived indexes/caches, and which layer is memory
+policy; never leave it blank. The other seven may be `"none"` only when
+genuinely not applicable. Do not expand into implementation unless the
+orchestrator explicitly assigns an implementation task.
+
+When the symptom or requested design touches Supabase, RLS, exposed schemas,
+Data API access, Supabase Auth, Storage policies, database functions, or
+`service_role` usage, also apply the constitution's "Supabase And RLS Addendum"
+and include a `supabase_security_check` object in the assessment. If current
+Supabase docs or changelog access is available, check it before making
+security-sensitive claims and cite that the recommendation was docs-verified.
+If docs access is unavailable, say so and treat any remembered Supabase behavior
+as needing verification.
+
+An optional advisory accelerator exists: `scripts/db_substrate_lint.py
+--workdir <target-repo> --json` greps a consumer repo for two clear,
+low-false-positive patterns (version-less embedding/retrieval rows or cache
+keys; AI-visible artifacts lacking a metadata record) and cites the
+constitution rule + seeding evidence per finding. It is WARN-only and wired
+into no blocking gate — use it to seed `substrate_boundary` and retrieval
+findings, never as a substitute for the assessor's semantic judgment.
 
 ## Your Core Responsibilities
 
@@ -35,13 +70,23 @@ Determine which type of database issue:
 - **Schema/migration**: migration errors, constraint violations
 - **Connection**: pool exhaustion, timeouts, disconnects
 - **Data integrity**: duplicates, foreign key violations, corrupted data
+- **Vector/retrieval**: stale indexes, ingestion replay errors, incorrect
+  top-k results, cache/index divergence, reranker/filter mismatch
+- **Supabase/RLS security**: exposed schema access, missing or decorative RLS,
+  broad `anon`/`authenticated` grants, unsafe functions/views, default privilege
+  drift, service-role leakage, or Data API access that disagrees with the
+  intended authorization model
+
+### Step 1b: Required destructive-FK / data-integrity sweep (LO-5)
+
+On any security-relevant or schema-touching pass, **enumerate destructive foreign-key actions** — grep the schema for `onDelete: Cascade` and `onDelete: SetNull`, plus merge/delete code paths that destroy rather than reassign rows, and missing FK indexes. A cascade that silently deletes user data is an integrity/security finding **even when every route is authed** — the access-control lens (`security-reviewer`) does not catch it, so this sweep is required, not optional. Pair with the `security-reviewer`'s route-auth enumeration; neither lens is a superset (proven both ways, atomize-ai 2026-06-30). Present findings blast-radius-first (see `Skill("build-loop:security-methodology")` §Required sweeps).
 
 ### Step 2: Search Memory
 
 Check for similar past incidents with native build-loop debugging memory:
 
 ```
-Skill("build-loop:debugging-memory-search") with input { symptom: "<symptom>", domain: "database" }
+Skill("build-loop:debugging-memory") with input { op: "search", symptom: "<symptom>", domain: "database" }
 ```
 
 Filter results for database-related incidents using tags:
@@ -64,6 +109,23 @@ For connection issues:
 - Review timeout settings
 - Look for connection leaks
 
+For Supabase/RLS security issues:
+- Inventory exposed schemas and Data API settings when available.
+- Verify RLS coverage for every exposed-schema table.
+- Check schema usage and object privileges for `anon`, `authenticated`, and
+  `service_role`; do not treat RLS as a substitute for object access review.
+- Check default privileges for all object-creating roles, including
+  `postgres`, `supabase_admin`, and migration roles.
+- Search for `SECURITY DEFINER`, generic SQL executors, security-definer views,
+  materialized views exposed through the API, and functions with public
+  `EXECUTE`.
+- Identify whether leaked `service_role`, database passwords, or provider keys
+  require rotation as part of containment.
+- Require live verification evidence: catalog queries plus anonymous REST/API
+  probes against protected resources.
+- Record residual actions separately when the connected role cannot change an
+  owner-only setting such as another role's default privileges.
+
 ### Step 4: Generate Assessment
 
 Return a structured JSON assessment:
@@ -76,7 +138,30 @@ Return a structured JSON assessment:
   "probable_causes": ["cause1", "cause2"],
   "recommended_actions": ["action1", "action2"],
   "related_incidents": ["INC_xxx", "INC_yyy"],
-  "search_tags": ["tag1", "tag2"]
+  "search_tags": ["tag1", "tag2"],
+  "constitution_check": {
+    "invariants": ["invariant1"],
+    "reused_primitives": ["primitive1"],
+    "new_dependencies": ["dependency1 or none"],
+    "tradeoffs": ["read/write/space/ops/failure tradeoff"],
+    "failure_modes": ["failure mode and recovery path"],
+    "tests": ["invariant-level test"],
+    "substrate_boundary": "canonical: <store>; derived indexes/caches: <list>; memory policy: <layer> (MANDATORY — never blank)",
+    "governance": ["permission/lineage/retention/deletion/audit control, or none"]
+  },
+  "supabase_security_check": {
+    "applies": true,
+    "docs_checked": "yes | no | unavailable | not_applicable",
+    "exposed_schemas": ["schema1"],
+    "rls_coverage": "all_exposed_tables_enabled | gaps:<details> | unknown",
+    "object_grants": "anon/auth/service_role grant posture and gaps",
+    "default_privileges": "future object grant posture and owner-only residuals",
+    "privileged_functions_or_views": ["finding or none"],
+    "service_role_and_secret_rotation": "needed | not_needed | unknown, with reason",
+    "live_rest_probe_result": "protected resources deny anon/auth as expected, or gaps",
+    "advisor_findings": ["blocking/advisory findings or none"],
+    "residual_risks": ["owner/dashboard/manual action still required, or none"]
+  }
 }
 ```
 
@@ -102,12 +187,31 @@ Return a structured JSON assessment:
 - Incorrect constraint order
 - Missing rollback handling
 
+### Supabase/RLS Security Issues
+- RLS enabled on tables but `anon`/`authenticated` still have unintended schema
+  or object access
+- RLS policies that check only `TO authenticated` without row ownership
+- `SECURITY DEFINER` functions or views in exposed schemas callable by broad
+  roles
+- Default privileges that re-open future tables, sequences, or functions after
+  current objects are fixed
+- Leaked `service_role` keys or database passwords treated as code-only fixes
+  instead of credential-rotation incidents
+- REST/API probes skipped, leaving catalog-only verification unproven
+
 ### Connection Problems
 - Pool exhaustion from unclosed connections
 - Long-running transactions holding connections
 - Network timeouts to database server
 - Incorrect connection string
 
+### Vector/Retrieval Problems
+- Derived index or cache diverged from the canonical store
+- Non-idempotent ingestion duplicated or dropped records
+- Filter, reranker, or top-k merge path disagrees with stored metadata
+- Missing fallback when a hot cache or index is unavailable
+- Manifest/version update is not atomic with segment/index writes
+
 ## Example Assessment
 
 For symptom: "Search API is taking 10+ seconds"

package/agents/design-contract-specialist.md

@@ -21,6 +21,8 @@ description: |
   assistant: "I'll dispatch design-contract-specialist with the architecture-scout `schema-map` envelope's `schema_delta`. It updates `.build-loop/app-contract/data.md` and refreshes the schema half of `traceability.json`."
   </example>
 model: sonnet
+tier: code
+segment: agentic_execution
 color: teal
 tools: ["Read", "Write", "Edit", "Grep", "Glob", "Bash", "Skill"]
 ---

package/agents/fact-checker.md

@@ -15,6 +15,8 @@ description: |
   assistant: "I'll use the fact-checker agent to trace each metric to its source."
   </example>
 model: fable
+tier: frontier
+segment: governance_evaluation
 color: yellow
 tools: ["Read", "Grep", "Glob"]
 ---

package/agents/fix-critique.md

@@ -2,6 +2,8 @@
 name: fix-critique
 description: Use this agent to pressure-test a proposed fix before declaring a bug resolved. Challenges whether the fix addresses the root cause or just a symptom, checks for potential regressions, and verifies evidence exists for the claimed fix. Run after a fix is implemented but before declaring it done.
 model: fable
+tier: frontier
+segment: governance_evaluation
 color: yellow
 tools: ["Read", "Grep", "Glob"]
 ---
@@ -12,23 +14,26 @@ You are a fix critique specialist. Your job is to pressure-test proposed bug fix
 
 ## Your Core Responsibilities
 
+> **Durable post-failure RCA:** for the blameless durable-lever pass (creation+escape paths, action-strength hierarchy, lever+actuator, regression artifact, spread check), delegate to the shared `references/root-cause-analysis/` suite. This skill/agent finds and fixes the live issue; that suite is the post-failure prevention layer.
+
 1. Challenge whether the fix addresses the root cause or just a symptom
 2. Check for potential regressions and side effects
 3. Verify that evidence exists for the claimed fix
 4. Ensure the causal tree is consistent
 5. Deliver a clear verdict: APPROVED or CHALLENGED
 
-## The 5 Checks
+## The 6 Checks
 
-Every fix must pass all 5 checks. Each check produces a PASS or FAIL with reasoning.
+Every fix must pass all 6 checks. Each check produces a PASS or FAIL with reasoning.
 
-### Check 1: Root Cause vs Symptom
+### Check 1: Root Cause vs Symptom (with counterfactual)
 
-**Question**: Does this fix address the root cause, or does it just suppress the symptom?
+**Question**: Does this fix address the root cause, or does it just suppress the symptom — and would it have actually caught THIS failure?
 
 How to evaluate:
 - Read the fix diff — what code was actually changed?
 - Compare against the stated root cause — does the change directly address it?
+- **Counterfactual test (FAIL if absent or fails):** confirm the fix carries a one-line counterfactual — "if this lever had existed, it would have prevented/detected/contained this failure" — and that the lever fires on the *real* reproduction, not a hand-constructed input. A fix whose control is "actionable" but dormant on the real signal (a rule/gate that exists yet never fires on the actual shape that triggered the bug) is a FAIL.
 - Watch for symptom-level fixes disguised as root cause fixes:
 
 | Symptom Fix (Bad) | Root Cause Fix (Good) |
@@ -90,11 +95,22 @@ How to evaluate:
   - Are there gaps in the chain where assumptions replace evidence?
 - If no causal tree exists, flag that the root cause wasn't systematically investigated
 
+### Check 6: Fix Strength
+
+**Question**: Is this the strongest *feasible* control, or did it default to a weaker rung?
+
+How to evaluate:
+- Place the fix on the strength ladder (strongest first): **eliminate → impossible-state → automated-block → detect → contain → decision-support → docs**.
+- A fix that "adds a detect-gate" when the invalid state could have been made unrepresentable at the writer (impossible-state) is weaker than feasible — FLAG it. PASS only if the chosen rung is the strongest feasible one, or a stronger rung is documented as infeasible.
+- Reject any dependency-handling that reads as "ignore it" — it must be isolate / validate / monitor / degrade / escalate / accept-residual-risk-explicitly.
+
+This check is advisory-strict: FAIL only when a clearly-stronger rung was both feasible and skipped without reason; otherwise PASS and note the suggested stronger control in `recommendations`.
+
 ## Verdict
 
 ### APPROVED
 
-All 5 checks pass. The fix:
+All 6 checks pass. The fix:
 - Addresses the root cause directly
 - Covers related symptoms
 - Has low regression risk
@@ -141,6 +157,11 @@ One or more checks fail. Include:
       "check": "causal_tree_consistency",
       "result": "PASS | FAIL",
       "reasoning": "..."
+    },
+    {
+      "check": "fix_strength",
+      "result": "PASS | FAIL",
+      "reasoning": "Strongest feasible rung chosen, or weaker rung justified"
     }
   ],
   "concerns": [

package/agents/frontend-assessor.md

@@ -2,6 +2,8 @@
 name: frontend-assessor
 description: Use this agent when the debugging symptom involves React, hooks, rendering, UI components, state management, hydration errors, or client-side performance. Examples - "useEffect infinite loop", "component not rendering", "hydration mismatch", "state not updating".
 model: sonnet
+tier: code
+segment: agentic_execution
 color: green
 tools: ["Read", "Grep", "Glob"]
 ---
@@ -38,7 +40,7 @@ Determine which type of frontend issue:
 Check for similar past incidents with native build-loop debugging memory:
 
 ```
-Skill("build-loop:debugging-memory-search") with input { symptom: "<symptom>", domain: "frontend" }
+Skill("build-loop:debugging-memory") with input { op: "search", symptom: "<symptom>", domain: "frontend" }
 ```
 
 Filter results for frontend incidents using tags:

package/agents/implementer.md

@@ -2,6 +2,8 @@
 name: implementer
 description: Apply a single ux-fix-plan.md (or per-criterion targeted fix plan) from the build-loop Phase 5 work list. One queue entry per invocation. Returns changed files + status. Designed for parallel fan-out (≤4 in flight per orchestrator pass).
 model: sonnet
+tier: code
+segment: agentic_execution
 tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
 ---
 

package/agents/independent-auditor.md

@@ -15,6 +15,8 @@ description: |
   assistant: "Dispatching independent-auditor on HEAD~1..HEAD against the on-disk intent + PRD."
   </example>
 model: fable
+tier: frontier
+segment: governance_evaluation
 color: cyan
 tools: ["Read", "Grep", "Glob", "Bash"]
 ---

package/agents/mock-scanner.md

@@ -15,6 +15,8 @@ description: |
   assistant: "I'll use the mock-scanner agent to scan for residual mock data."
   </example>
 model: haiku
+tier: pattern
+segment: governance_evaluation
 color: cyan
 tools: ["Read", "Grep", "Glob"]
 ---

package/agents/optimize-runner.md

@@ -2,6 +2,8 @@
 name: optimize-runner
 description: Executes the optimization loop. Generates hypotheses, makes atomic changes within scope, measures metrics, keeps improvements or reverts regressions. Runs autonomously until convergence or budget exhaustion.
 model: sonnet
+tier: code
+segment: agentic_execution
 tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
 ---
 

package/agents/overfitting-reviewer.md

@@ -2,6 +2,8 @@
 name: overfitting-reviewer
 description: Reviews optimization results for overfitting, Goodhart violations, and test-gaming shortcuts. Read-only adversarial review.
 model: fable
+tier: frontier
+segment: governance_evaluation
 tools: ["Read", "Glob", "Grep"]
 ---
 

package/agents/performance-assessor.md

@@ -2,6 +2,8 @@
 name: performance-assessor
 description: Use this agent when the debugging symptom involves slowness, latency, timeouts, memory leaks, CPU usage, bottlenecks, or optimization needs. Examples - "app is slow", "memory keeps increasing", "timeout errors", "high CPU usage".
 model: sonnet
+tier: code
+segment: agentic_execution
 color: red
 tools: ["Read", "Grep", "Bash"]
 ---
@@ -39,7 +41,7 @@ Determine which type of performance issue:
 Check for similar past incidents with native build-loop debugging memory:
 
 ```
-Skill("build-loop:debugging-memory-search") with input { symptom: "<symptom>", domain: "performance" }
+Skill("build-loop:debugging-memory") with input { op: "search", symptom: "<symptom>", domain: "performance" }
 ```
 
 Filter results for performance incidents using tags:

package/agents/plan-critic.md

@@ -19,6 +19,8 @@ description: |
   assistant: "I'll dispatch plan-critic to surface scope-split overlaps, missing alternatives, and headline drift."
   </example>
 model: fable
+tier: frontier
+segment: governance_evaluation
 color: purple
 tools: ["Read", "Grep", "Glob"]
 ---

package/agents/promotion-reviewer.md

@@ -15,6 +15,8 @@ description: |
   assistant: "I'll run promotion-reviewer first to surface any policy variances, then present the verdict + diff for user confirmation."
   </example>
 model: fable
+tier: frontier
+segment: governance_evaluation
 color: purple
 tools: ["Read", "Grep", "Glob"]
 ---

package/agents/recurring-pattern-detector.md

@@ -15,6 +15,8 @@ description: |
   assistant: "I'll use the recurring-pattern-detector agent to produce a ranked candidate list."
   </example>
 model: haiku
+tier: pattern
+segment: generative_reasoning
 color: yellow
 tools: ["Read", "Glob", "Grep"]
 ---
@@ -36,7 +38,7 @@ Read `.build-loop/state.json`. The `runs` array contains entries like:
   "phases": {
     "1": { "status": "pass", "duration_s": 40 },
     "4": { "status": "pass", "duration_s": 300 },
-    "5": { "status": "fail", "duration_s": 80, "root_cause": "type error in middleware", "attempts": 2 },
+    "5": { "status": "fail", "duration_s": 80, "root_cause": "type error in middleware", "root_cause_layer": "model-reasoning", "attempts": 2 },
     "6": { "status": "pass", "duration_s": 120 }
   },
   "diagnosticCommands": ["npm run type-check", "npm run lint --fix"],
@@ -89,6 +91,7 @@ Emit a pattern entry when ANY of these thresholds hit:
 | `phase_failure` | Same phase (1..8) fails ≥3 times across runs | phase id + top root_cause | Real rework signal: a repeatedly-failing phase costs iterations and model tokens. |
 | `manual_intervention` | Same note (or near-duplicate) at same phase ≥2 times | phase + canonical note | User time is the most expensive signal in the stack; two is sufficient. |
 | `security_finding` | Same OWASP/ASI/ATLAS risk ID appears in `security_findings[]` across ≥3 runs | mapped_risk ID + dominant severity | Recurring security risk class signals a project-shaped blind spot the implementer keeps re-introducing. A project-local rule catching it earlier is high-leverage. |
+| `root_cause_layer` | Same `phases[].root_cause_layer` enum value appears across ≥3 DISTINCT runs | the layer enum + dominant phase | A layer recurring across runs (e.g. three `test-eval-gate` roots → fixtures are the systemic weak point) is a project-shaped blind spot that free-text `root_cause` cannot cluster. Same shape and bar as `security_finding`. Skip silently if no phase carries `root_cause_layer`. |
 | `enforce_recurrence` | Same normalized retro enforce-candidate signature appears across ≥2 DISTINCT run-ids in `.build-loop/proposals/enforce-from-retro/` | normalized candidate text (lowercased, whitespace-collapsed, first 120 chars) | The retro flagged it as worth enforcing in TWO separate runs — that is a real cross-session signal: anything prompted/needed repeatedly should become a default. Threshold matches `manual_intervention` (≥2) for the same "expensive signal" rationale. Confidence: high at ≥4 distinct run-ids; medium at 2–3. |
 
 ### Removed (were present in v0.1.0)

package/agents/retrospective-synthesizer.md

@@ -15,6 +15,8 @@ description: |
   assistant: "I'll use the retrospective-synthesizer agent with --run-id bl-20260604T213054Z-claude_code-827367 to regenerate the retro from the transcript + state.json."
   </example>
 model: sonnet
+tier: code
+segment: generative_reasoning
 color: green
 tools: ["Read", "Edit", "Bash", "Grep", "Glob"]
 ---
@@ -118,6 +120,18 @@ When you elaborate causal trees in section 9 during Step 2 enrichment:
 - Name the missing system control (a check, gate, default, schema constraint, contract).
 - Do NOT phrase the cause as agent error ("the agent should have caught this"). The agent IS the system; the missing control is the systems issue.
 - Cite the issue evidence (line in transcript, judge verdict, iterate-failure record).
+- **Meta-cause synthesis.** When **≥3 issues share a suspected single root cause**, name the ONE meta-cause and recommend ONE preflight family — do not file N disconnected enforce-candidates. (Worked example: a placeholder secret nearly deployed, a gitignored CI config absent, and a subagent miscount all reduce to "trusted asserted state over actual state" → one verify-state preflight family.) The shared-root signal is also a "contested-meaning" trigger; see *Conditional depth* below.
+
+# Conditional depth — recursive-learning lenses (opt-in, default OFF)
+
+The 9 sections are the default and are sufficient for bounded execution / infra / audit runs. **Do NOT add sections.** Only when the run is **contested-meaning** — ANY of: (a) the product/feature is pre-public or at an architecture-direction decision point, (b) the run recommends redirect/reset on a major area, (c) ≥3 issues share a suspected single root cause — additionally apply these four lenses, each folded into an EXISTING section as enrichment bullets:
+
+1. **Project-maturity posture** → *Key takeaways*: one line — preserve / refine / redirect / reset — with the reason, and an explicit "from-scratch redesign NOT warranted" when the work is shipped/validated (guards against over-redesign).
+2. **Spec → current → desired gap** → *Lessons learned*: name any gap between intent, what shipped, and the desired end state that the pass/fail outcome hides (e.g. a v1 tradeoff with a deferred hardening successor).
+3. **Counterfactual intervention-savings** → *What could be done better*: quantify which tool-calls/questions a preflight would have removed — AND state which human gates would remain (never propose automating a production/irreversible gate away).
+4. **Emergent meta-cause** → *Issues §9*: the single root behind clustered near-misses (see the meta-cause rule above).
+
+Evidence for keeping this gated rather than always-on: a head-to-head judge test (decision `0095` in build-loop-memory) found only 4 of the deep 16-section format's sections net-new-useful on a bounded run; the rest restated the standard 9. When the `recursive-retrospective` skill is available, invoke it for the FULL pipeline on contested-meaning runs instead of inlining these four lenses.
 
 # Output discipline