This was the first broad Scarab quieting run against React’s main repository, facebook/react.
Previous field tests were narrow: one issue, one boundary, one repair lane, one patch candidate.
This one was different.
The goal was to test whether a large, real-world compiler/runtime repository could be driven from a noisy diagnostic scorecard to quiet through a sequence of bounded repair passes.
Result
Target:
text facebook/react
Initial diagnostic scorecard:
text 133 findings
Final stepwise scorecard:
text 0 findings quiet
Final full audit:
text clear 0 findings
Repair commits:
text 28 bounded commits
Diagnostic suite mechanics changed during the run:
text no
The target repo was repaired. The diagnostic suite was not changed to make the result pass.
What was actually repaired
This run did not try to make one issue disappear.
It walked through the repo in passes and quieted finding clusters across several major React areas:
- DevTools extension governance
- DevTools fallback behavior
- DevTools storage fallback behavior
- React runtime parity
- React DOM fallback behavior
- Fizz runtime/source-generated boundaries
- React serialization error boundaries
- React Compiler semantic boundaries
- HIR semantic boundaries
- HIR dependency semantics
- Compiler optimization semantics
- Reactive scope semantics
- Compiler validation semantics
- Compiler fixture equivalence
- Compiler runtime equivalence
- Compiler snap equivalence
- Source-map provenance
- Test proof boundaries
- Operational control boundaries
- DevTools cache/control boundaries
- DOM and Fizz control boundaries
- Test renderer control boundaries
- Reconciler control boundaries
- Reconciler test control boundaries
- Flight test control boundaries
- Server control boundaries
- CI workflow authority
Most of the repairs were source-level boundary documentation: comments that made existing behavior, ownership, parity, proof, fallback, or control assumptions explicit at the point where the code already depended on them.
There was one substantive workflow authority change: a CI workflow that did not need contents: write had that permission removed, while artifact-publishing workflows retained the write authority they actually require.
Score movement
The run started with 133 findings.
During the late autonomous section, the score moved like this:
text 48 -> 43 -> 38 -> 33 -> 28 -> 23 -> 18 -> 13 -> 9 -> 3 -> 1 -> 0
The important part is the shape of the run: each pass quieted a bounded cluster, then the repo was rechecked.
This was not one broad rewrite.
It was a sequence of source-side repair slices.
Pass sequence
| Pass | Finding count | Repair slice |
|---|---|---|
| 0 | 133 | Clarified DevTools extension governance boundaries |
| 1 | 131 | Documented React runtime parity boundaries |
| 2 | 129 | Documented DevTools fallback behavior |
| 3 | 124 | Documented DevTools storage fallbacks |
| 4 | 119 | Documented React fallback boundaries |
| 5 | 113 | Documented compiler semantic boundaries |
| 6 | 109 | Documented HIR semantic boundaries |
| 7 | 104 | Documented HIR dependency semantics |
| 8 | 99 | Documented compiler optimization semantics |
| 9 | 94 | Documented reactive scope semantics |
| 10 | 89 | Documented compiler validation semantics |
| 11 | 84 | Documented compiler fixture equivalence |
| 12 | 79 | Documented compiler runtime equivalence |
| 13 | 74 | Documented compiler snap equivalence |
| 14 | 72 | Documented source-map provenance boundaries |
| 15 | 58 | Documented test proof boundaries |
| 16 | 54 | Documented operational control boundaries |
| 17 | 48 | Documented DevTools control boundaries |
| 18 | 43 | Documented DevTools cache control boundaries |
| 19 | 38 | Documented inspected/cache control boundaries |
| 20 | 33 | Documented DOM and Fizz control boundaries |
| 21 | 28 | Documented test renderer control boundaries |
| 22 | 23 | Documented reconciler control boundaries |
| 23 | 18 | Documented reconciler test control boundaries |
| 24 | 13 | Documented Flight test control boundaries |
| 25 | 9 | Documented server control boundaries |
| 26 | 3 | Clarified CI workflow authority |
| 27 | 1 | Committed the final CI/full-repo cleanup |
| 28 | 0 | Final quiet state |
Area notes
DevTools
The early passes mostly quieted DevTools-related surfaces.
These covered extension injection, fallback behavior, shared DevTools storage, renderer/backend behavior, profiler/cache/store control, inspected element cache ownership, hook-name cache ownership, timeline cache ownership, and dynamic import cache behavior.
This was a large early source of findings.
Once those boundaries were documented, the score moved down from 133 to 119.
DOM, Fizz, and fallback behavior
The next stage touched React DOM and Fizz surfaces.
The repairs documented fallback and parity boundaries around DOM component handling, input selection, Fizz runtime source/generated relationships, Fizz server tests, serialization error handling, and inline runtime generation.
This was mostly about making existing fallback behavior explicit, not changing how the runtime behaves.
Compiler and HIR
The compiler section was the largest middle portion of the run.
It moved through HIR build semantics, optional-chain dependency collection, dependency derivation, environment semantics, scope dependency propagation, HIR printing, type schema/visitor behavior, optimization, JSX outlining, reactive-scope build/codegen, reactive-scope inference, invalidation merging, and pruning semantics.
This was the section where the run crossed below 100 findings.
The compiler/HIR passes are important because they touched the kind of source areas where code can remain structurally correct while the intent behind dependency ownership, fixture equivalence, or runtime parity is not explicit enough for future repair work.
Compiler fixtures and runtime equivalence
Several passes focused on compiler fixtures and runtime equivalence.
These repairs documented where tests and fixtures were proving equivalence, where optional-chain behavior was intentionally preserved, and where snap/minimization/evaluation behavior served selection or comparison roles rather than rewriting compiler output.
That distinction matters in compiler code because not every odd-looking fixture or filter is a bug. Some files exist to prove that a transformation preserves a specific semantic boundary.
Source maps
The source-map pass quieted a generated-artifact/provenance cluster.
This covered source-map loading, mocked source-map updates, parsing, metadata, and consumption.
After this pass, the generated-artifact ownership lane dropped out of the scorecard.
Test proof boundaries
The proof pass documented test surfaces that were acting as proof boundaries.
This included legacy JSX runtime tests and DevTools inline e2e test behavior.
After this pass, the proof-ownership lane dropped out of the scorecard.
Operational control
The late run was dominated by operational-control surfaces.
This covered hooks code-path state, cache behavior, Flight client behavior, debug hooks, standalone DevTools, DevTools store/profiler/cache control, inspected element cache control, DOM/Fizz control, renderer test control, reconciler control, reconciler tests, Flight tests, server control, and external-store shared test behavior.
This was the last major high-severity cluster before the repo moved into CI/full-repo cleanup.
CI authority
The final source-side cleanup was in CI workflow authority.
One direct-sync PR-closing workflow carried unnecessary contents: write authority. That was removed. Artifact-publishing workflows retained the write authority they actually need.
The final one-finding state was caused by the CI repair having passed scoped checks but not yet being committed. Once committed, the scorecard reached quiet.
Verification
Final stepwise result:
text finding_count: 0 status: quiet selected_subsystem: none
Final full audit result:
text diagnostic_outcome: clear Findings: 0
Additional source checks passed:
text Governance Intake tests: 60 tests Drift-surface profile tests: 38 tests Diagnostic Suite tests: 247 tests Diagnostic Suite Python compile Diagnostic Suite Node syntax checks
What this does and does not claim
This does not claim that every open GitHub issue in facebook/react was fixed.
GitHub issue trackers contain live bugs, stale reports, feature requests, duplicates, design discussions, version-specific reports, unreproduced cases, and issues outside a local diagnostic surface.
The claim here is narrower and measurable:
A cloned facebook/react target started with 133 Scarab/SDS diagnostic findings and reached 0 findings through 28 bounded repair passes. A final full Scarab audit also completed clear with 0 findings.
Summary: why this matters
This run is different from a normal single-issue field test.
A single-issue test proves that a diagnostic system can find one broken boundary and guide one narrow repair.
This run tested whether a large repository could become quieter pass by pass.
That matters because mature repos do not only fail through isolated bugs. They accumulate hidden boundary pressure: fallback behavior that works but is not source-owned, generated artifacts whose provenance is implicit, tests that prove something without naming the proof boundary, compiler fixtures whose equivalence is obvious only to people who already know the system, caches and control paths that are operationally necessary but underdocumented, and CI workflows whose authority can widen over time.
In this run, Scarab did not flatten the repo into one giant fix. It walked the repo through a sequence of repair slices.
DevTools quieted.
Compiler/HIR quieted.
Generated artifact provenance quieted.
Proof boundaries quieted.
Operational control quieted.
CI authority quieted.
Then the full scorecard quieted.
The result is a source-level proof trail showing facebook/react moving from 133 diagnostic findings to 0 through bounded commits, with a final full audit clear.
That is the point of this field test: not one patch, but a measurable repo quieting run.
Public evidence repo:
https://github.com/scarab-systems/react-stepwise-quieting-report
Public React repair branch:
https://github.com/scarab-systems/react/tree/codex/react-stepwise-source-repair-20260608
Top comments (0)