Forkscope

• 

  Six finished changes reviewed together before merge.

• 

  Controlled candidate preview with six-change provenance.

• 

  Payment blocked after Fraud Check is removed; stale success is invalidated.

Inspiration

A pull request can pass every test on its own while the combined product still breaks. Frontend, API, platform, and security updates often meet for the first time after merge—when discovering an interaction bug is most expensive.

Forkscope was built around a simple idea: make the temporary combined product, rather than an isolated pull request, the primary object of team review.

What it does

Forkscope lets software teams review combined pull requests together before merge.

For a connected repository, Forkscope inspects open pull requests and plans combinations of up to twenty pull requests sharing a common base version. The original branches and pull requests are never altered, merged, or deployed.

The user experience follows four clear stages: Review → Compose → Preview → Evaluate, demonstrated in a sample workspace. Combining six completed updates reveals a coupon code mismatch that remains invisible when each update is reviewed alone. Applying a temporary coupon field match links the two code changes without modifying either pull request. Testing the workspace shows the store before the updates, the combined store preview, interactive checkout behavior, and recorded test results.

The failure path is equally clear. Removing the Fraud Check update invalidates previous passing results immediately, blocks payment in the store, and drops the evaluation status to two out of three passed steps.

How I built it

The application is built with TypeScript, React, and Vinext. A selected-repository GitHub App handles pull-request metadata, while a Cloudflare Worker, D1 database, and Queues manage workflow state and test records.

I also built an isolated Docker runner and verified it in GitHub Actions. The test environment receives no GitHub, OpenAI, or Cloudflare credentials, and Playwright observes browser behavior from outside the container. Live execution for connected repositories remains disabled in this release candidate.

How I used Codex and GPT-5.6

Codex acted as an engineering partner throughout development—from early interaction prototypes to the signed release candidate. It helped design security boundaries, implement background workflows, generate test suites, and debug build failures from logs.

Forkscope also includes optional AI assistance, off by default and powered by the gpt-5.6-sol model. Before calling the model, Forkscope rechecks and locks the test results and next steps. The model receives structured formatting rules and operates with storage disabled (store: false). The AI explains recorded results; it cannot alter pass/fail, edit code, or replace automated checks.

Challenges

The hardest work began after the interface was built. Running tests on GitHub-hosted Ubuntu exposed four separate environment issues: Chromium sandbox behavior, an npm cache space limit, Vite write permissions under read-only mounts, and an expected unauthenticated response initially mistaken for a UI failure.

Each issue was fixed at its source. The final browser test accepts only the expected authentication response; an unexpected error, console failure, or network failure stops the run instead of producing a questionable result.

Accomplishments

The private release candidate is GPG-signed on branch agent/release-parity. Automated checks passed the site, backend workflow, and isolated container tests on the same signed version.

The test pipeline verified package installation, independent build, detached serving, browser isolation, screenshot and log capture, and resource cleanup. The 2:05 English demo also passed its audio sync, visual framing, caption, and language checks.

Current boundary

Forkscope is a private Build Week release candidate, not a public commercial launch.

The public judge link exposes an explicitly labeled sample workspace with no live repository connection or execution authority. Connected repository inspection and combined plan generation are implemented, but live container execution remains disabled. The owner staging site remains private and is not presented as a public demo account. Two private-repository invitations were sent to the designated judging accounts and remain pending acceptance.

What's next

The next step is a limited private test: keep access restricted to selected repositories, enable one connected-repository run, and verify result retention and cleanup before considering broader access.

Built With

• cloudflare-d1
• cloudflare-queues
• cloudflare-workers
• codex
• docker
• github-actions
• gpt-5.6
• playwright
• react
• typescript
• vinext