Open-source foundation analysis — dual-run parity harness

2026-07-18 · Author: Fable · Template §8 (open-source foundation research), reinterpreted internally per 00-context-brief.md. Source material: D1 (OSS/commercial landscape, ~30 repos verified via live gh api + primary docs), D3 (legacy-runtime lab feasibility). No new research performed in this document — synthesis and decision only. Every claim below traces to D1/D3; repeated URLs are omitted here, see those notes for the full citation list.

Internal reinterpretation of template concepts used throughout: “commercial-use fit” = would Groupon legal/security sign off on shipping this inside the harness, not a SaaS pricing question. “Production foundation” = foundation for the harness itself (a Robert-lane internal tool), not a customer-facing product.

1. Method

Every candidate scored against the parity kernel’s five stages — record → normalize → replay → diff → verdict — spanning a legacy/candidate boundary that is cross-language (EOL Ruby/JRuby vs. Encore.ts), includes a message bus (JMS/STOMP + some Kafka), and must produce an auditable PARITY/DIVERGED/UNVERIFIABLE verdict with evidence bundle. A tool that nails one stage still scores low on fit % if it does nothing for the rest — fit % is against the whole kernel, not the leg it’s good at.

Classification bands, defined once and applied consistently:

Strong foundation — adopt as the substrate for a kernel stage; mature, healthy, license-clean, architecture matches.
Useful component — adopt narrowly for one sub-problem, not the whole stage; do not overinvest in learning its full surface.
Prototype only — worth a hands-on spike, not a commitment; architecture or evidence too thin to commit engineering weeks against.
High-risk dependency — real and maintained, but a property (license, hosting model, vendor lock, unverified compatibility) makes it a liability to build the kernel on top of.
Not recommended — do not spend more research or engineering time here.

2. Candidate-by-candidate

2.1 Scientist (github/scientist) + ports (Scientist.NET, laboratory, tzientist, scientist.js forks)


Repo/license	github/scientist MIT, last push 2025-11-24, 7,735★, 15 open issues — healthy. tzientist (TS port) MIT, last push 2026-07-03, small (84★) but genuinely current. scientist.js community forks: Unlicense, stale since 2018-10-25 (8 years).
Architecture	Wraps a function call — invokes candidate and control in the same process, same request, same language, synchronously, then returns control’s result.
Docs / health	Scientist and Scientist.NET well documented, active issue triage. tzientist small but zero open issues. scientist.js forks abandoned.
Deployment complexity	Trivial where it fits (library import) — but it doesn’t fit here.
Maintenance/fork risk	Low for the maintained ports; scientist.js forks are dead code if anyone reaches for them.
Kernel fit	~10%.
Classification	Prototype only (vocabulary/pattern value; tzientist worth remembering for a possible future in-process guardrail inside the new Encore.ts services, not for legacy-vs-candidate).

Why it doesn’t transplant: legacy is a separate EOL process in a different language behind a pinned Docker image; candidate is Encore.ts. Scientist requires one runtime calling both. Forcing it means either touching legacy’s request path (audit doctrine forbids: “legacy code is never ported”) or calling candidate synchronously from inside legacy handling — a mutating-call-to-candidate shape the DoD explicitly keeps OFF until M4. Verdict: not the recorder, not the differ. Keep only the control/candidate vocabulary and the “always return what control returns” safety discipline as prior art.

2.2 Diffy lineage (twitter-archive/diffy, opendiffy/diffy)


twitter-archive/diffy	Apache-2.0, archived, last push 2020-07-01, 3,815★. Own README: “Twitter has decided to archive this project, as it was built on our outdated tech stack… we are reinventing in this space internally.”
opendiffy/diffy	CC BY-NC-ND 4.0 — confirmed by reading LICENSE, not the GitHub badge (`NOASSERTION`). Forbids commercial use and derivative works. Last functional commits none since the 2023-09-11 tagged release (`23.09.11.00`); commits since then are dependency bumps only, most recent checked 2026-05-18.
Architecture	Live triple-fan-out proxy: candidate + primary + secondary, all running and reachable simultaneously. Noise model: primary-vs-secondary disagreement rate is the noise floor; candidate-vs-primary is judged against that floor, not a per-field allowlist. Mutating verbs (POST/PUT/DELETE) ignored by default — flag required to enable.
Kernel fit	~15% as code (blocked outright), ~40% as a design pattern.
Classification	opendiffy/diffy: not recommended — CC BY-NC-ND is a hard legal blocker for a commercial entity, full stop, not a judgment call. twitter-archive/diffy: high-risk dependency if used as code (Apache-2.0 so legally fine, but archived + its own inventor calls the architecture obsolete + zero support) — strong foundation as a design reference only. Cite, don’t fork.

Two ideas worth stealing outright: (1) the relative-disagreement-rate noise floor — instead of (or alongside) a normalization ledger of allowlisted fields, replay the same recorded request twice against the legacy lab (or against two lab instances) to measure legacy’s own natural non-determinism, then judge legacy-vs-candidate divergence against that floor, not zero; (2) mutating verbs off by default — directly corroborates the initial recommendation’s recorded-replay-first, write-ramp-gated stance; even Diffy’s own authors didn’t trust live triplication of writes.

Also structurally disqualified regardless of license: Diffy assumes live, always-on, horizontally-scalable, same-language, HTTP-only services. Our legacy estate is none of these — EOL Docker images that cannot be casually kept “always on,” cross-language by definition, and MBUS is out-of-band from HTTP entirely.

2.3 Hoverfly (diff mode)

Apache-2.0, last push 2026-07-14 (this week), 2,505★, 33 open issues — healthy ratio. Go. Diff mode forwards a live request to a real service and compares it against a stored simulation (recorded fixture) — a two-way live-vs-recorded comparison, not Diffy’s three-live-instance model. No MBUS concept, no verdict/severity model, no normalization ledger. Go-native — a new-language runtime dependency for a TypeScript-centric harness, workable only as an external process.

Kernel fit: ~25%. Classification: useful component — architecturally the closest match in the whole survey to “compare recorded fixture vs. fresh response,” worth a hands-on spike specifically for the diff-mode shape, not for adoption of the tool wholesale.

2.4 GoReplay

LGPLv3 core (Pro tier for binary-protocol/keep-alive-session replay is separately licensed, commercial) — verified by reading LICENSE.txt, not the GitHub badge. Ownership transferred buger/goreplay → probelabs/goreplay, same history, 19,294★, last push 2026-01-27, 341 open issues (high for repo size — soft signal of support strain despite recent pushes). Captures live HTTP traffic and replays it, explicitly marketed for legacy-migration validation, no application changes required — matches the “no legacy-code modification” constraint. PII masking is a Pro (paid) feature, not in the free tier.

Kernel fit: ~30-40% for the HTTP capture/replay leg only, ~0% for MBUS (binary-protocol replay is Pro-gated, which is exactly the capability MBUS shadow-taps would need). Classification: useful component with a license caveat — fine as a capture/replay substrate for HTTP fixtures in the legacy lab; not a foundation for the MBUS leg or for masking.

2.5 Keploy

Apache-2.0, extremely active (releases multiple times a week, v3.6.1 on 2026-07-17 the day before this research). eBPF hooks on syscalls (accept/read/write/sendto/recvfrom) capture traffic transparently at the kernel level, generate YAML fixtures + auto-mocks, replay by serving mocks back. Docs claim Kafka/RabbitMQ streaming support; JMS and STOMP are not mentioned anywhere in Keploy’s own materials. eBPF hooking has no evidence of validation against JRuby 1.7 on old JVMs or Ruby 1.9.3’s threading model — a real unknown, not confirmed either way. Also: Keploy’s actual product purpose is “capture a service’s own traffic to auto-generate that service’s tests” — a test-generation tool that shares the record/replay substrate, not a two-system diff tool by design.

Kernel fit: ~25-30%. Classification: useful component to pilot — worth a cheap spike specifically to answer “does eBPF capture even attach to a JRuby-1.7-era process,” not a committed dependency until that spike runs. D1’s own flagged open question, unresolved.

2.6 mitmproxy

MIT, last push 2026-07-18 (today), 44,365★ — by a wide margin the most mature and active tool in the entire survey. Interactive TLS-capable proxy, Python addon system, native client-side and server-side replay (serve a previously recorded response for a matching request). No diff/verdict layer — pure capture+replay substrate, fully scriptable. HTTP/HTTPS-centric, no native MBUS support, no built-in masking (would need a custom addon, same gap as GoReplay’s free tier).

Kernel fit: ~30% (capture/replay substrate). Classification: strong foundation for the recorder’s HTTP leg specifically — most defensible pick in the whole survey on maturity, license, and activity grounds. D3 independently reaches the same conclusion for the legacy-lab recording problem (outside-in, no legacy-code touch).

2.7 VCR + WebMock

VCR: custom permissive MIT-style license (confirmed by reading LICENSE.txt), last release v6.4.0 (2025-12-22). WebMock: MIT, last release v3.26.2 (2026-03-18), 4,051★. Both Ruby-native, language-matched to 702k LOC of the legacy estate. Records a Ruby process’s own outbound HTTP calls to “cassette” fixtures.

Wrong shape for the candidate-vs-legacy diff (in-process, requires adding the gem to the legacy Gemfile/test harness — a legacy-code change the audit doctrine and the “no legacy-code modification” constraint both rule out). D3 separately documents a real compatibility wrinkle: VCR 6.x needs Ruby ≥2.6, so Rails-3.2-era stacks (Ruby 1.9.3) would need the 2015-era VCR 3.0.1 line, and Rails 3 misinterprets VCR cassette YAML under test/fixtures as ActiveRecord fixtures — a named, documented footgun, not hypothetical.

Kernel fit: ~10% overall; ~40% for a narrower sub-problem — isolating the legacy-runtime lab’s own outbound dependencies (payment gateways, other legacy services legacy calls out to) so the lab boots deterministically without every transitive dependency also being pinned and running. Classification: useful component, scoped strictly to lab-dependency stubbing, not to the recorder.

2.8 Envoy / Istio / nginx mirror / AWS VPC Traffic Mirroring

All actively maintained (Envoy: Apache-2.0, last push 2026-07-18, 28,594★ — no health concern for the project itself). All are fire-and-forget live traffic mirroring — none compares or diffs responses; the mirrored response is discarded by design. Wrong layer entirely: even if adopted, 100% of the diff/verdict engine still has to be built. Also assumes a live-shadow model the initial recommendation already de-prioritizes behind recorded-fixture replay, and assumes infrastructure (Kubernetes/service mesh/AWS EC2) that D1 could not confirm the legacy estate runs on.

Kernel fit: ~5% each. Classification: not recommended for v1 on three independent grounds (wrong layer, wrong traffic model, unverified infra fit). If live-shadow is ever required for the write-ramp specifically (open question below), this category re-enters the conversation — but as Zaruba’s production-infra lane, not the harness’s.

2.9 WireMock / Mountebank (service virtualization)

WireMock: Apache-2.0, last push 2026-07-17, 7,298★, genuine record/playback + proxy-snapshotting mode. HTTP-only. Mountebank: MIT, last push 2026-07-11, 2,104★, multi-protocol “imposters” including raw TCP — conceptually adjacent to JMS/STOMP stubbing, but no evidence anyone has built a JMS/STOMP imposter with it; would be net-new work.

Neither diffs anything — they stand up canned responses. Relevant only as components inside the legacy-runtime lab, isolating legacy’s own downstream dependencies (payment gateways, other services) so the lab boots deterministically.

Kernel fit: ~15-20%. Classification: useful component, scoped to lab dependency isolation, same bucket as VCR/WebMock.

2.10 tcpcopy

License field NOASSERTION on GitHub — no clearly recognized OSS license found, treat as a blocker until confirmed. Raw TCP-level live traffic duplication, historically Chinese web-ops ecosystem, sparse/dated English docs, requires kernel-level packet capture (operationally heavy). Duplicates live traffic only, no recorded-replay mode.

Kernel fit: ~15%. Classification: prototype only — license risk alone is disqualifying pending clarification; operational weight and live-only model make it a poor fit regardless.

2.11 Speedscale / proxymock

Closed-source core; free local CLI records/mocks/replays for local dev; cluster-scale capture+replay+diff and CI integration require Speedscale Enterprise (paid). Has a documented Kafka integration guide — closest thing found to commercial message-broker replay tooling — but Enterprise-gated, and no JMS/STOMP guide found. Vendor-claimed Apache-2.0 for CLI/UI could not be verified at the actual source repo — flag as unverified.

Kernel fit: ~30%. Classification: high-risk dependency — Enterprise-gated for anything beyond local dev, and the QSA/SOX evidence requirement (DoD row 9) is easier to reason about with a fully-owned tool than a paid vendor’s closed control plane sitting in the audit trail.

2.12 Signadot

No public core-engine repo (confirmed by enumerating the public org — everything public is CLI/SDK/demo tooling, ≤22★ each); the sandbox/routing control plane is closed-source SaaS. Live-shadow, Kubernetes-native model: isolated K8s “sandboxes,” a slice of live traffic routed via a routing key, compared in real time against baseline. Assumes the target runtime is Kubernetes with a service mesh or Signadot’s own routing layer — the legacy estate (pinned EOL Docker images booted ad hoc) does not fit this model.

Kernel fit: ~10-15%. Classification: high-risk dependency — real, maintained product, wrong substrate assumption, closed-source core, paid.

2.13 datafold/data-diff

Confirmed dead: archived by owner 2024-05-17, per Datafold’s own sunset blog post; the company repositioned entirely toward its commercial cloud product and, per its own 2026 positioning, toward AI-migration tooling rather than classical diffing. Out of scope anyway — DB-state diffing beyond the merchant-accounting oracle pattern is explicitly excluded from MVP per the initial recommendation.

Kernel fit: n/a. Classification: not recommended. Noted only so nobody re-proposes reviving an 18-months-deliberately-sunsetted project.

2.14 Pact

pact-js/pact-jvm/pact_broker — MIT/Apache-2.0, all pushed within the last day of this research (2026-07-17/18), very actively maintained. Consumer-driven contract testing — design-time API-shape agreement between consumer and provider, verified at build time. Does not record real legacy behavior, does not replay real traffic, does not produce a PARITY/DIVERGED verdict.

Kernel fit: ~5%. Classification: not recommended for the kernel — a fundamentally different testing philosophy, not a lesser version of ours. Flagged as a mature, healthy tool for a different problem (guaranteeing API-shape stability between services during the transition) if the program wants that separately — out of scope for this document’s question.

2.15 ApprovalTests family

ApprovalTests.Java/.Net/.cpp — mostly Apache-2.0, active (pushes from 2025-10 through 2026-07-14). Pattern: capture an output, a human approves it as the new known-good baseline (committed to source control), future runs fail on divergence until re-approved.

No HTTP capture, no bus support, no legacy-vs-candidate concept — not a kernel-stage tool at all. But its data model is the closest existing pattern to our human-decision step: a builder opens the evidence bundle, sees the counterexample, decides real-regression/acceptable-difference/add-normalization-rule, and that decision is recorded as a versioned, auditable artifact — exactly the “normalization rules are themselves auditable scope decisions” principle already committed to in the initial recommendation.

Kernel fit: ~15%. Classification: useful component — study the approval-workflow data model for the evidence-bundle/normalization-ledger UX, not for capture or diff.

2.16 MBUS (JMS/STOMP/Kafka) parity tooling — the confirmed gap

D1 searched specifically for OSS that diffs message-bus events between two systems (not one system’s own bus testing) and found none. What exists solves an adjacent problem only: Kafka’s own TopologyTestDriver/Trogdor, Testcontainers Kafka modules (all single-system testing frameworks); Keploy and Speedscale both claim partial Kafka capture/mock support but neither documents STOMP or JMS and neither is a two-system diff tool by design.

Kernel fit: 0%. Classification: confirmed gap — custom build, no candidate to evaluate. This is not “no strong option was found,” it is “nothing exists to evaluate.” Budget it as net-new engineering and treat it as the single highest-uncertainty leg of the whole kernel — HTTP record/replay tooling is mature and plentiful (§2.3-2.9); message-bus parity tooling is empty.

3. Legacy-runtime lab — supporting tooling (from D3, not a “candidate to adopt” in the same sense, but load-bearing infrastructure)

The lab isn’t a comparison tool — it’s the substrate the recorder points at. D3’s tool-relevant findings, folded in because the lab’s feasibility gates whether any recorder/differ choice above even has legacy traffic to work with:

apache/activemq-classic — current, actively maintained official-vendor image (updated 5 months ago per D3). Not actually EOL software; Apache still ships 5.x. Lowest-risk piece of the whole lab. Classification: strong foundation for the MBUS side of the lab, contingent on an unverified assumption (JMS/STOMP wire-protocol back-compat across 2013–2017-era clients — plausible, not confirmed).
cytopia/mysql-5.6 (third-party, community-maintained) fills the gap left by Docker Hub’s stale official MySQL 5.x images. Useful component, moderate risk (supply-chain trust in a non-official maintainer), well-trodden pattern.
Ruby 1.9.3/2.4/2.6, Rails 3.2/4.1/5.2, JRuby 1.7, Java 7 images: highest-risk tier, not confirmed infeasible but thin-evidence. A live, unresolved Docker manifest-v1 deprecation issue (docker-library/ruby#452, hit on Docker CE v26.0.2 pulling ruby:2.2.4) directly threatens pullability of images this old; workaround exists (rescue-pull on an older engine, re-push to an internal registry) but is a manual step, not something lab automation can assume works unattended.
RubyGems’ TLS 1.2 floor (since 2018-02-24) blocks fresh bundle install on old interpreters unless gems are vendored or mirrored internally — a known, well-documented mechanism, must be built into lab automation from day one.
Native-extension builds (mysql2, nokogiri, eventmachine) need exact base-OS/OpenSSL pairing plus archived Debian apt sources; the one closest, most current analog found (useo.tech, 2026-04-09, Ruby 2.3.8) solves this for a single stack combination with a multi-step chained fix — no source demonstrates this solved end-to-end across the full 1.9.3→2.6 range, a genuine evidence gap, not a confirmed failure.
No OSS tool does PII masking of recorded HTTP fixtures (as opposed to DB rows) — GoReplay Pro’s masking feature is the only tool found aimed at that exact surface, and it’s paid.

Per-repo lab setup cost: MODELED at ~2-5 engineer-days for the first repo on a given stack combination, dropping to well under a day for follow-on repos reusing a solved combination (inference by analogy to general DevOps “solve once, reuse” practice — not sourced from a matching case study, label it interpretation).

4. Composition recommendation

Adopt as substrate (write code against it, take the dependency):

Component	Tool	Why
Recorder — HTTP leg	mitmproxy	Strong foundation: MIT, most active/mature tool in the survey, native replay both directions, scriptable addon system covers the custom PII-masking gap nobody sells for free.
Recorder — MySQL image (lab)	`cytopia/mysql-5.6` (fallback to stale official if it disappears)	Moderate risk, well-trodden.
Recorder — MBUS image (lab)	`apache/activemq-classic`	Lowest-risk lab component; not actually EOL.
Lab dependency isolation	VCR/WebMock (for Ruby legacy’s own outbound calls) + WireMock/Mountebank (for non-Ruby legacy dependencies)	Stub what legacy calls out to, so the lab boots deterministically without every transitive dependency also pinned and running. Narrow, well-scoped use — not the recorder itself.

Take patterns from only — do not adopt the code:

Source	Pattern taken	Not taken
Diffy	Relative-disagreement-rate noise floor (replay-twice-against-legacy to measure natural non-determinism, judge candidate against that floor); mutating-verbs-off-by-default	The codebase (license-blocked for opendiffy; archived/abandoned for twitter-archive)
Scientist	Control/candidate vocabulary; “always return what control returns”; publish/observe separation	The in-process, same-runtime execution model (structurally wrong shape here)
ApprovalTests	Versioned, auditable approved-baseline data model for the normalization ledger / human-decision step	The tool itself (no capture/diff/MBUS capability)
Hoverfly diff mode	The “live-vs-recorded-fixture” comparison shape (closest architectural match found)	The Go runtime / the tool as a dependency (new-language footprint for a TS-centric harness, evaluate hands-on before committing)

Not recommended, full stop: opendiffy/diffy (license), datafold/data-diff (dead + out of scope), Pact (different problem), tcpcopy (unclear license + ops weight), Envoy/Istio/nginx-mirror/AWS-VPC-mirroring (wrong layer, wrong traffic model, unverified infra fit), Signadot (closed-source core, wrong substrate), Speedscale Enterprise beyond a possible scoped spike (paid, closed control plane in an audit trail).

5. Would building from scratch be strategically irrational? — answered per layer

Recorder: no, buying/adopting is right — a custom build would be irrational. mitmproxy is mature, MIT-licensed, extremely active (pushed the same day this research ran), and already solves the hard parts of an HTTP recording/replay substrate (TLS interception, scriptable capture, both replay directions). Writing a bespoke HTTP proxy from scratch to duplicate what mitmproxy already does well would burn weeks of the Robert-lane budget for no differentiated value — the differentiation the program actually needs (normalization, verdicts, evidence bundles) sits entirely on top of the recorder, not in it. Verdict: adopt mitmproxy, do not build a recorder. Caveat: MBUS is a different story — no recorder exists for JMS/STOMP parity capture at all (§2.16), so the MBUS shadow-tap is unavoidably custom regardless of what’s adopted for HTTP.

Differ: yes, custom is correct — no honest buy option exists. No tool in the survey diffs a recorded legacy fixture against a fresh candidate response with a normalization ledger, a PARITY/DIVERGED/UNVERIFIABLE verdict, and MBUS event comparison. Hoverfly’s diff mode is the closest shape (~25% fit) and is worth a hands-on spike for its comparison logic, but it has no verdict model, no normalization ledger, and no bus support — adopting it wholesale would mean building 75%+ of the differ around a borrowed 25% anyway, plus carrying a new-language (Go) runtime dependency for marginal benefit. Verdict: build the differ; steal Diffy’s noise-floor pattern and Hoverfly’s live-vs-recorded shape as design input, adopt neither as code.

Legacy-runtime lab: no full off-the-shelf lab exists, but the pieces are mostly buy/reuse, not build. This is not really a “differ-style” build-vs-buy question — it’s an infrastructure-assembly question. ActiveMQ and MySQL images are adopt-as-is (§3). The EOL Ruby/JRuby image chain is the one place where “build” is unavoidable, but what’s being built is Dockerfiles and gem-vendoring automation, not a tool — there is no product category to buy here at all, so the build-vs-buy framing doesn’t apply; it’s operational engineering work with a MODELED 2-5 engineer-day cost per first-of-a-kind stack combination. Verdict: not a build-vs-buy decision — assemble from existing images plus custom Dockerfile/vendoring work; the highest-risk items (manifest-v1 pull risk, TLS floor, native-ext builds) need a spike before committing lab automation to run unattended.

Verdict/evidence layer: yes, custom is correct, and there is barely a market to check against. ApprovalTests contributes a data-model pattern (versioned, human-approved baselines) but is not a verdict engine — it has no legacy-vs-candidate concept, no counterexample-minimization, no work-ledger integration. Nothing in the survey produces a machine-checked PARITY/DIVERGED/UNVERIFIABLE verdict with a replayable counterexample, wired to an internal work-ledger claim system. This is the harness’s actual product (per the initial recommendation §1 — “an evidence machine for turning legacy OFF”) and by definition cannot be bought, because no other organization has this program’s exact audit obligations (QSA/SOX sign-off, Zaruba’s source+window+confidence discipline) wired to this shape of work-ledger. Verdict: build the verdict/evidence layer entirely; it is the one layer where “build vs buy” was never a real question — there is no buy option and the layer IS the differentiated deliverable.

Summary in one line per layer: Recorder = buy (mitmproxy) + unavoidable custom MBUS tap. Differ = build, informed by two borrowed patterns. Lab = assemble existing images + custom Dockerfile/vendoring engineering (not a build-vs-buy question). Verdict/evidence = build, no buy option exists.

6. What this changes or confirms in the initial recommendation

Confirms assumption #1 (initial-recommendation §13): no tool covers >40% of the kernel; the ceiling found was Diffy at ~40% as a design pattern only, ~15% as usable code. The “build, not buy” premise holds.
Sharpens the noise-normalization design (§10/§13-5 of the initial recommendation): Diffy’s relative-disagreement-rate noise floor is a concrete, source-backed alternative/supplement to a hand-written normalization allowlist — replay-twice-against-legacy to measure the estate’s own non-determinism before judging candidate divergence. Worth prototyping in the “days not weeks” spike (initial recommendation §11).
Confirms MBUS shadow-taps are unavoidably custom-build (context brief, already decided) — D1 found zero candidates, not merely weak ones.
Surfaces a tension, not a resolution: the market’s dominant commercial pattern for this problem class (Diffy, Hoverfly diff mode, Signadot, Speedscale Enterprise) is live-shadow, not recorded-replay. Our constraints (pinned EOL images that can’t be casually kept always-on, write-ramp safety, MBUS being out-of-band from HTTP) push toward recorded-replay-first, and that choice is well-reasoned — but it means the harness is deliberately building against the industry’s minority pattern for this problem, which is worth stating plainly to whoever finalizes the PRD rather than treating as a footnote.

Open questions

Does the ledger-reconciliation ≥99.999% proof (M2→M3 write ramp) require live dual-run machinery at some point, or does recorded-replay-plus-periodic-refresh satisfy it? Neither D1 nor D3 resolves this; it determines whether §2.8/§2.11/§2.12 (live-shadow infra) ever re-enters scope, and if so, whether that’s harness lane or Zaruba’s production-infra lane. Carried forward unresolved from the initial recommendation.
Is there internal precedent inside repos/monorepo-development/ or Zaruba’s existing oracle code for message-bus comparison that this research should have found but didn’t? D1 found none externally; an internal check has not been done.
Does the legacy estate run on infrastructure (Kubernetes, AWS EC2/VPC, a service mesh) that would make Envoy/Istio/AWS-Traffic-Mirroring/Signadot’s routing model even physically applicable? Unverified either way — moot if the answer is no, but not assumed.
eBPF-based capture (Keploy) against JRuby 1.7 / Ruby 1.9.3-era syscall patterns is untested territory. Worth a cheap spike given how active and capable Keploy otherwise is (multiple releases/week) — but do not commit to it before that spike runs.
Whether openjdk:7/jruby:1.7 tags are actually pullable on a current Docker Engine — not conclusively confirmed by D3; gates the highest-risk tier of the lab.
Whether GoReplay Pro’s paid fixture-masking is worth buying versus building a custom mitmproxy-addon scrubber for PII in recorded HTTP fixtures — unresearched; no OSS tool solves fixture-level (as opposed to DB-row-level) masking for free.
No published false-positive-rate data exists anywhere for Diffy-class deployments (D1 §13, actively searched for). This is a real gap for calibrating how aggressively the noise-floor approach can be trusted before a human reviews every DIVERGED verdict — treat as unknown, not as evidence the problem is small.