Reaktor Shadow

Shadow makes development production-shaped and verification repeatable through a shared graph, approved state and declared execution policies. A moving materializer publishes validated immutable bases; isolated workspaces fork a base; a controlled run pins pre-state and artifacts. Capture/replay complements this state system rather than replacing it.

Direction, 1 October 2026: dev and prod are trust tiers; Shadow workspaces are dev execution instances. ClickHouse continues to serve product analytics and Measure. Shadow shares the existing observability infrastructure, with proposed WAE hot comparisons and R2/Iceberg historical evidence. Application resources and effects remain isolated.

Capture scope, 3 October 2026: acquire everything each supported runtime and infrastructure layer exposes. This includes deep JVM recording, eBPF/kernel evidence, JavaScript capture through proxies and stronger instrumentation, Worker handlers/bindings/durable events, Kubernetes execution context, state and clients. The Capture fabric owns this extension beyond the textbook. Capture breadth and replay fidelity are reported separately.

Current state

The repository has dev/prod configuration and seed/provisioning building blocks, graph/Service instrumentation, Keploy recording, R2 archive/pull and local replay scripts. Those are useful adapters, not a complete moving Shadow. The proposed publication, workspace lifecycle, semantic operation journal and paired comparator still require implementation and qualification.

The Keploy archive does not pin the complete artifact/base vector; the local runner defaults to a mutable image unless overridden. Framework span export is bounded and lossy, and its current JSON omits events/links. Neither cassette portability nor archived telemetry proves replay completeness. See Backends and Shared observability.

The full capture fabric remains a design target. Existing OTel instrumentation and Keploy integration do not yet implement a deep method/value/state recorder or complete cross-layer evidence acquisition.

Read the textbook as pages

The chapter and source register maps all sixteen chapters of the 25 September design edition. Type names and worked failures remain proposed contracts and illustrations.

Minimum safe development substrate

A dev client chooses its configuration at the composition root before services initialize. Its backend, data, principals, notification destinations and service-binding peers must resolve to verified dev resources. A trusted workspace manifest determines those resources; a request header cannot select a privileged production connection.

Coexisting dev/prod app builds, dev auth and isolated stores are the first useful slice. Shared expensive resources require a verified access scope and an explicit contention/authority limitation. Production fixes and private security findings have their own runbooks; this page is not an instruction to reprovision or rotate anything merely because an earlier design named it.

Corrections to the earlier direction

• A recent traffic window does not define complete state: required old rows, relations and configuration remain in the base.
• Materialization advances the moving base; it does not apply CDC into a running replay and then execute the captured write again.
• Baseline/candidate runs use equivalent pre-state and declared inputs. Today's base plus yesterday's traffic is production-shaped, not automatically historical reproduction.
• Store isolation is implemented per resource. A Postgres overlay schema and search_path are not a transparent copy-on-write database.
• Missing objects do not read through to production. Unknown replay matches fail rather than fall back to live effects.
• Determinism is a qualified fidelity vector; a visitor/proxy does not control all async scheduling or raw-reference operations.
• Pinned capsules obey privacy, access and deletion policy; they are not permanent exceptions to retention.

First end-to-end gate

Publish one sanitized validated base, prepare two isolated copies, run send/retry/reconnect with fixed assertions, prove a deliberately introduced regression fails, retain a reconstructible capsule and verify cleanup. Then expand backend coverage, continuous publication and representative load. Delivery gates define the evidence required at each step.

Observability and graph integration

Capture policy is selected through graph identities and installed at supported runtime boundaries. Architecture, telemetry overlay and execution history stay distinct. The paired observation links baseline/candidate traces and evidence with exact release/base/assertion identity; it does not merge experimental spans into a production trace. Graph evidence owns the correlation and truth contract.

The earlier merged proposal is retained in Shadow design history. Historical Claude/Codex research is background, while these textbook pages own the current direction.

Earlier section links

Earlier section anchors remain available here. Their dated source text is in the archive; the reading map above points to the current topic pages.

• Earlier mvp-current section.
• Earlier mvp-phase0 section.
• Earlier mvp-spine section.
• Earlier mvp-build section.
• Earlier mvp-deploy section.
• Earlier mvp-checklist section.
• Earlier mvp-to-shadow section.
• Earlier summary section.
• Earlier current-keploy section.
• Earlier current-edge section.
• Earlier why section.
• Earlier inspiration section.
• Earlier surfaces section.
• Earlier environments section.
• Earlier sideeffects section.
• Earlier arch section.
• Earlier capture section.
• Earlier capture-edge section.
• Earlier capture-edge-middleware section.
• Earlier capture-edge-deep section.
• Earlier capture-edge-boundary section.
• Earlier capture-edge-layers section.
• Earlier capture-edge-ceiling section.
• Earlier capture-edge-cost section.
• Earlier envelope section.
• Earlier data section.
• Earlier capsules section.
• Earlier window section.
• Earlier materialization section.
• Earlier replay section.
• Earlier replay-keploy-r2 section.
• Earlier replay-edge section.
• Earlier stack section.
• Earlier replay-frontier section.
• Earlier frontier-omniscient section.
• Earlier frontier-differential section.
• Earlier frontier-shadow section.
• Earlier frontier-fuzz section.
• Earlier frontier-distributed section.
• Earlier frontier-do section.
• Earlier frontier-corpus section.
• Earlier frontier-privacy section.
• Earlier comparison section.
• Earlier stubs section.
• Earlier anomaly section.
• Earlier privacy section.
• Earlier access section.
• Earlier tenant section.
• Earlier timetravel section.
• Earlier load section.
• Earlier observability section.
• Earlier cli section.
• Earlier workbench section.
• Earlier ci section.
• Earlier bestbuds section.
• Earlier risks section.
• Earlier references section.