Conformance review

Why a guardrail, not a reviewer

A post-hoc linter catches what's already written. By the time the flag fires, the pattern is embedded in the shape of the reactor, the signature of the event, the expectation of the downstream fold. Removing it costs a refactor.

A guardrail catches the intent before it crystallizes. Claude Code is about to write a handler that calls repo.Get() inside a HandleFunc; the reviewer stops it and suggests the fold. Claude Code proposes an event with a field string payload; the reviewer counter-proposes one topic per field. The cost of the correction is seconds, not days.

This only works because weave is introspectable: the DSL names every event, the reactor declaration names every role, and the scroll contains every outcome. A language without this surface can't support the same loop.

Static and dynamic

The anti-pattern catalog

Each rule is versioned, documented, and carries a suggested fix. This list is the starting set — extracted from real incidents in production weave deployments. New rules land as new shapes of mistake get observed.

The refactor proposer

Detection is half the value. The other half is the before/after diff. The reviewer emits:

• The .weave change — which events get split, which roles get annotated, which scrolls get renamed.
• The reactor code change — which folds replace which reads, which handlers move from fire-and-forget to consumer groups, which role types replace raw NewReactor.
• The rationale — linked to the rule that triggered, with a one-paragraph explanation.
• The impact estimate — how many callers change, how many tests get invalidated, whether a corpus replay is required to verify.

Claude Code applies the diff, re-runs the reviewer, and sees the finding clear. Or pushes back with context the rule didn't have — and the rule learns.

In-loop and batch

Two modes, different cost profiles.

# In-loop (runs on save or on tool call)
scry review --file internal/tavern/reactor.go --fast
  → returns in < 500ms
  → scope: one file, no scroll access
  → catches: 80% of static anti-patterns

# Batch (runs on a branch + corpus)
scry review --repo . --corpus ./scrolls --out results/
  → runs in ~minutes for a repo-scale sweep
  → scope: cross-file + scroll-aware
  → catches: everything the in-loop version misses
                  + dynamic violations
                  + prompt-version divergence

In-loop runs as a Claude Code hook or editor LSP extension. Batch runs in CI or on demand. Both share the same rule catalog and refactor proposer; only the evidence they see differs.

Example: a signal_accepted race

A live quest-intake pipeline emits signal_accepted before the corresponding gate_checked event on the signals scroll. The grounding gate was bypassed. Static review sees nothing wrong — the reactor code looks fine. Dynamic review, reading the scroll, spots the ordering violation:

sequence 42: quest_proposed       { signalId: s_9 }
sequence 43: signal_accepted     { signalId: s_9 }    ← problem
sequence 44: gate_checked        { signalId: s_9, evidence: … }

Violation: quest-evidence-gate
  signal s_9 accepted at sequence 43 before gate check at 44.
  Invariant: every signal_accepted must be preceded by a
  matching gate_checked on the same signalId.

Root cause (proposed):
  reconcile-quest handler emits signal_accepted directly on
  verdict=accept, without awaiting the gate's output. The gate
  is a separate reactor; its cursor can lag.

Refactor:
  Split the acceptance into two stages:
    1. reconcile-quest emits signal_pending_gate
    2. gate reactor folds, emits gate_checked + signal_accepted
  OR: make the gate a synchronous fold inside reconcile-quest.

Impact: 1 reactor file, 1 .weave file, 2 callers, 0 fixtures
  invalidated. Corpus replay recommended.

Why this is the bootstrap capability

Every other Scry capability — replay, test generation, bisection, corpus analysis — reasons over scroll and code shapes. If those shapes are inconsistent, ambiguous, or drifting, the downstream tools reason over garbage. The conformance reviewer is what keeps the substrate clean enough for everything above it to work.

It's also what makes Claude Code viable as an author of production weave code. Without the reviewer, the implementation guide has to live in every prompt. With it, the rules live in the framework — coached in-loop, enforced at the boundary, refactored automatically when they drift.