Building a Cross-Repository AI Workflow with Switch

One green repository isn’t done. Here is how CrossRepoRepair connects SDK/UI handoffs, actual browser checks and exact-bundle human review.

The UI looked fixed. The HTTP request was still wrong.

That is the kind of integration failure a repository-by-repository AI coding workflow can miss. A component can pass its checks while the application using it still violates the shared requirement.

For Flip the Switch 2026, I built CrossRepoRepair: a working, Switch-coordinated workflow that repairs two connected repositories, checks their combined behaviour and leaves approval to an explicitly enrolled person. The point is not to produce more agent messages. It is to make “finished” mean something observable.

Figure 1. The actual both-fixed browser execution. The server receives a and b separately. This is a cropped capture, not a mockup or a hosted production service.

The short version: Switch carries shared context, handoffs and commands. One AI coding session performs the two repository roles sequentially. A separate deterministic verifier not another model checks source, the consumed SDK artifact, real HTTP and browser outcomes. Green checks produce a reviewable bundle, not automatic approval.

Watch the 96-second narrated demo · Read the source and reproduce the workflow

What you will learn

• How to connect a coding session and a deterministic verifier through a real Switch room.
• Why SDK-only and UI-only repairs can both be insufficient.
• How to tie checks and human review to the inputs that actually ran.
• What the recorded tests establish and which security and reproducibility claims they do not establish.

Jump to: the bug · Switch setup · browser results · human review · local reproduction

The Swagger bug behind the workflow

This is an adapted historical Swagger replay, not a newly discovered open bug. The SDK reference fix and UI reference fix already existed upstream. The work here is the demonstrated Switch workflow, combined verification and review handling not an accepted new upstream contribution or the original WideSWE execution.

The selected versions are swagger-client 3.34.2 and Swagger UI 5.20.0. That UI declares an SDK range compatible with the selected SDK; substituting an arbitrary later UI would change the experiment.

The contract is deliberately small:

On the original source, independent acceptance checks found four SDK failures and one UI failure, while the selected upstream tests were green. Real loopback HTTP also exposed the encoded-array request bug. The original failure evidence was retained before either repair.

That distinction matters: a familiar unit suite can pass without covering the behaviour shared by two repositories.

How to connect the workflow through Switch

The recorded setup used Switch Console 0.40.1, native server 0.31.0 and local Mattermost 11.9.0. No employer workspace, customer code or production access was involved.

Figure 2. One simplified repair-and-review cycle. This is an original explanatory diagram, not a screenshot or a claim that two independent model workers ran.

First prepare the local checkout and dependencies below. Then follow the repository’s Switch setup instructions to connect your own room:

1. Create the room and registration key in the owner’s Console. Use a room dedicated to the shared change.
2. Configure your own local connection. Copy switch.local.example.json to the ignored switch.local.json; supply your actual server and room. Keep keys and generated credentials private.
3. Register and invite both identities. Set SWITCH_URL and SWITCH_REGISTRATION_KEY, then run npm run switch:register and npm run session:register. Invite the verifier and coding-session agent through the owner’s Console.
4. Configure owner-controlled addressing and start one verifier listener. Use npm run switch:listen; do not start competing clients for the same identity.
5. Give the coding session room tools. It can read the shared context and send a real check request:

npm run session:context
printf '%s\n' '@crossrepo-verifier check' | npm run session:post

The listener runs a fixed local pipeline. status reevaluates freshness without calling a model, and parsed commands never become arbitrary shell input. Agent posts do not impersonate the enrolled person.

Figure 3. An actual Switch thread captured on November 6. The verifier’s recorded result distinguishes passing checks from pending human review. The crop does not change message text.

The SDK-only state was checked and explicitly blocked before the UI work continued. Switch kept that partial result, the handoff and later decisions in the room instead of reducing the workflow to a final success notification.

Switch supplies coordination. CrossRepoRepair supplies the verifier and review policy. The latter are project logic, not security guarantees automatically provided by Switch.

Testing SDK-only, UI-only and both-fixed states

A source-level green result was not enough. The real browser exercised four combinations:

Figure 4. Two actual executions, with explanatory labels outside the screenshot crops. A successful HTTP 200 response alone is not proof of correct serialization: the response body must contain the intended values.

The matrix verifies 20 outcomes, including five deliberately broken-state observations. It does not mean all four variants are healthy. The seven-second loader observation is finite evidence, not proof of infinite loading.

Actual Chrome text entry and Execute clicks also found a missing case: JSON array text in a required nullable-array editor could be reported as missing. The additional UI repair validates that narrow array/null case locally, while retaining the stored representation for the SDK to serialize.

Figure 5. The fixed UI surfaces an error for invalid array input. The original hash-pinned acceptance files were not weakened; additional regression and browser coverage made the target stricter.

The recorded coverage is specific:

These are different evidence types, not interchangeable counts of product features or a broad model benchmark.

Bind green checks to the SDK the UI actually consumes

The UI imports deep SDK paths. Building a tarball does not establish that the UI consumed that tarball.

CrossRepoRepair therefore checks the SDK archive, complete unpacked package bytes and executable modes, dependency-link target and resolved UI modules. Readiness also binds source fingerprints, acceptance and checker versions, browser bundles, styles and screenshots.

Controlled source, unpacked-package and browser-byte drift were rejected. Changing the execution profile also made readiness stale. Exact restoration recovered matching readiness; it did not manufacture a new approval receipt.

Two reproducibility failures were particularly useful:

• Same archive, different permissions. Inherited umask settings caused different executable bits after extraction. The cache guard correctly blocked this. Extraction now pins restrictive 077 permissions and restores the caller’s mask, without relaxing byte/mode checks or changing vendor lockfiles.
• A probe that only worked after a previous run. Fresh-checkout testing exposed an assumption that the evidence directory already existed. The probe now creates it before writing its report; the complete rehearsal was rerun afterward.

Neither failure would be fixed by asking the model for a more confident summary.

Hashes are not a sandbox

The historical repairs were performed by trusted operator tooling. Later fingerprints did not retroactively isolate that work.

Canonical and selected upstream Jest now run in pinned non-root, read-only, no-network containers. Source snapshots, original canonical tests and public dependency mounts are read-only. Host credentials, reviewer policy, receipts and Docker sockets are not exposed to the test process. Actual synthetic canaries check denied access and writable scratch; missing runtime infrastructure fails closed, without a host-Jest fallback.

This is a scoped Jest boundary. Builds, HTTP/browser control, project unit tests and the coordinator remain trusted-host execution. It is not complete worker containment, immutable storage, protection against kernel compromise or proof that malicious JavaScript cannot interfere with its own test runtime. See the execution boundary and remaining trust.

Human approval must not survive changed inputs

The review policy uses an explicitly enrolled person’s server-origin opaque sender identity, the room, authorised contract and full fresh bundle hash. A display name or a message claiming to be human is insufficient. Missing policy denies review.

An actual coding-agent approval attempt was rejected. A genuine human command approving the November 4 bundle was accepted and retained.

Figure 6. Genuine historical approval not approval of the revised checker. The image was captured November 6; the command and reply refer to November 4’s bundle. The changed runtime/checker still needs its own review.

At this writing, the revised checker bundle remains reviewable but unapproved. The old receipt cannot transfer to it. A fresh clone also cannot inherit the original operator’s private review policy.

A local receipt is not permission to merge, deploy, spend, publish or submit an entry. This mechanism trusts Switch and the local verifier/storage; it does not defeat a privileged host attacker.

Reproduce CrossRepoRepair locally

Use an owned clean checkout, not a working copy containing unrelated changes. The recorded platform is Apple-silicon macOS, host Node 22.14.0, local Docker and already-installed Chrome 156.0.8078.80. The Jest image is Linux/ARM64 Node 24.10.0. x86, Windows and other browsers are not established by this run. Bootstrap refuses to continue below 8 GiB free.

git clone https://github.com/atomdbc/CrossRepoRepair.git
cd CrossRepoRepair

# Start local Docker. Explicitly install the pinned image on a compatible ARM64 host.
# Verification itself never downloads an image silently.
docker pull node@sha256:b8d2197aff9129d16c801a3e3e1b2a873c4946480f5a310f38056df2268c38d9

npm ci --ignore-scripts --no-audit --no-fund
npm run bootstrap
npm test
npm run isolation:probe

# Here, success means the expected original bugs were reproduced.
npm run baseline
npm run link-sdk
npm run http:baseline

# Apply both recorded repairs; retain the original vendor lockfiles.
git -C reference-repos/swagger-client apply ../../patches/swagger-client.patch
git -C reference-repos/swagger-ui apply ../../patches/swagger-ui.patch

npm run verify
npm run link-sdk
npm run http:verify
npm run regressions
npm run browser:build
npm run browser:verify
npm run readiness

The last command should produce a new local reviewable bundle, not an approved one. For the definitive requirements and any subsequent changes, use the public reproduction instructions.

A fresh exported checkout passed all 16 rehearsal steps on November 5, using the same Mac, npm cache and pre-existing image. No private keys or reviewer policy were copied; it correctly finished unapproved. The recorded reproduction receipt identifies the tested code/configuration. This is same-host reproduction, not a fresh OS or independently reprovisioned Switch installation.

Setup lessons and frequently asked questions

Do I need access to an employer’s chat workspace?

No. This run used a dedicated local Mattermost room through Switch. Use your own deployment and identities; do not involve private company or customer material just to reproduce the workflow.

What if the room is missing or the protocol numbers differ?

A room whose server map had not hydrated was restored through Admin → Rooms → Retry. Compatibility also required range-aware handling: the recorded server advertised protocol 9 while accepting client 6. Simple version equality would have rejected that compatible connection. These are observations from this deployment, not universal fixes for every Switch version.

Does this demonstrate multiple independent AI agents outperforming one?

No. One existing AI coding session performed both repair roles sequentially. The verifier executes deterministic code. Three standalone Codex CLI model requests failed without edits and are not counted as workers. No measured productivity gain, customer result or broad benchmark advantage is claimed.

The useful definition of finished

The next engineering work is stronger worker/build/browser containment, additional independently specified cases and broader platform validation.

The lesson from this build is more immediate: shared work needs a shared completion contract. Switch made handoffs and decisions visible. The verifier required observable behaviour from identified inputs. A person not a green badge or a confident agent message retained the review decision.

Start with the CrossRepoRepair source and setup guide, or watch the owner-narrated demo with captions.

Build record as of November 6, 2026. Drafted by an AI coding assistant from actual project evidence, with entrant review and publication approval; the entrant supplied the demonstration narration and genuine historical review. Screenshot crops retain original UI/result text; the workflow diagram and comparison labels are explanatory illustrations. No deployment or event-submission confirmation is claimed. Swagger-derived material retains its Apache notices; no additional project-wide original-code licence has been selected.