Scry

Why a separate service

Scroll and runner are the hot path. Appends fast, reads fast, replays fast. Anything that slows that path is a tax on production. But production is only half the job — the other half is understanding production: diagnosing the incident, replaying a proposed fix, bisecting a prompt change, generating a regression test, sweeping a corpus nightly.

All of that is computationally heavy, LLM-backed, and wants its own indexes, caches, and spawned sandboxes. Scry owns it. Scroll and runner stay lean; Scry scales independently.

Two load-bearing properties

Capabilities

Each capability is a weave application built on the scroll substrate. They compose: conformance finds the anti-pattern, replay verifies the refactor, test-gen captures the regression, bisect minimizes the prompt fix, sandbox validates at corpus scale.

The canonical use case: porting a live pipeline

The shape to have in mind while reading these docs: a quest-intake pipeline running on the tavern's back wall — thousands of lines of Go, a dozen reactors, a hand-rolled rate limiter, a projection layer glued together with catch-up barriers. It needs to move from in-process weave to the service-based weave ecosystem — networked scroll-server, runner service, distributed consumer groups — without regressing behavior.

Claude Code is the one doing the refactor. Scry is what makes it safe.

1. Baseline capture. Save the last N production scrolls as a corpus. Conformance review reads the code + .weave files + scrolls and emits a punch list: every projection-read-in-reactor, every payload discriminator, every catch-up barrier. Each finding is annotated with a proposed refactor.
2. Refactor in-place. Each change — folding where a projection read used to be, splitting a stringly-typed event, declaring a reactor's role — is replayed against the baseline corpus. Corpus replay reports pass / unchanged / diverged with per-case diffs. A divergence without explanation blocks the step.
3. Graduate patterns into weave. Hand-rolled rate limiters, producer/consumer wrappers, feedback-fold helpers move into framework primitives. The application drops its hand-rolls. Conformance re-verifies that the upgrade didn't change behavior.
4. Service migration. Scroll becomes networked. Reactors register as consumer-group subscribers. Sandboxed replay runs the same scroll through the in-process and service-based pipelines and diffs. Divergences surface before any cutover traffic.
5. Regression harvest. Every historical incident becomes a generated test. Every prompt change gets a bisection report. The corpus grows; the regression suite grows with it.

None of the five steps is hypothetical. Each maps to a refactor shape real weave apps already pay for with commit-diff-shaped fixes. Scry is the shape of the tool that would have made those commits smaller, safer, and verifiable.

Operation

Scry is designed to be driven by Claude Code, not a human clicking a GUI. Every capability is reachable from a bash command with --json output. Long-running operations write progressive results to an output directory with a done.json marker. Failed runs are --resume-able. Stale recorded externals hard-fail rather than silently diverge.

The CLI surface looks like:

scry narrate <scroll-id>                            — plain-English summary
scry review <repo> [--scroll <id>]                   — conformance punch list
scry fork <scroll-id> [--at <seq>]                   — clone for experimentation
scry substitute <fork> --event ai.response --value ...
scry replay <scroll-or-fork>                         — re-derive the workflow
scry diff <scroll-a> <scroll-b>                      — per-event divergence
scry test-gen <scroll-id> [--target <reactor>]       — synthesize regression test
scry replay-corpus <dir> --out results/              — batch; resumable
scry bisect --failing <scroll> --prompt <path>       — minimum prompt edit
scry sandbox spawn <corpus>                          — isolated scroll+runner