.png&w=256&q=75)
🤓 Latest Submissions
FutureFork
Developers choose between competing designs using evidence that only covers the present: today's tests pass, static review looks fine, and an experienced reviewer can *imagine* how the design might hold up later. But imagining future maintenance is not the same as doing it, and doing it by hand for every candidate design is too expensive to try before committing. The result is that architectural bets are usually made on informed guesswork, and the actual cost of a design shows up only after the team is already living with it. FutureFork turns "how will this design respond to a future change?" into a bounded, reproducible experiment instead of a guess. The developer supplies two Git refs that implement the same current behavior and picks a frozen, plausible future requirement. FutureFork's CLI (`futurefork prepare`) resolves the candidate to its exact commit, creates an isolated, detached Git worktree for it — never touching the source ref — and writes a task packet containing the requirement, the public acceptance criteria, and the exact public HTTP interface the change must expose. It deliberately withholds the acceptance tests themselves. The developer opens that worktree in IBM Bob IDE and runs the task packet; Bob does the actual implementation work. Once Bob's task ends, `futurefork finalize` takes over deterministically: it freezes Bob's patch, verifies the evaluator-owned protected test pack against a hash frozen before the run, mounts it into the worktree only now, runs the project's existing regression suite and then the protected acceptance tests, and re-verifies the protected pack's hash again afterward. Every result — the patch, the test outcomes, the changed files, the timings, and the pack hashes before and after — is written into one immutable, schema-validated run manifest. If the protected pack no longer matches its frozen hash, the run is marked `oracle_tampered`, never a candidate result; if FutureFork's own tooling fails, that is `runner_error`, never counted against the candidate. This means the demo can show is not "an AI's opinion," but a real Git worktree, a real Bob task ID, a real diff, and a real pass/fail result an engineer can open and re-check by hand. The current build proves this end to end on one frozen scenario — partial refunds must allocate a historical discount deterministically across items — run against two PocketCart candidates that implement discounts differently (`coupled`: logic embedded across checkout/refund/persistence; `modular`: a discount-policy interface). Both candidates pass the same 68–70 regression tests and the same 34 hidden acceptance tests for that scenario, each with a distinct real Bob task and Bobcoin spend, viewable in `docs/evidence-dashboard.html`. Two more frozen scenarios exist as contracts, not yet run. FutureFork does not claim to predict which future will happen, does not produce a maintainability score, and does not merge anything automatically — it gives developers one thing they don't currently have: a real, inspectable rehearsal of the future change they were only able to imagine before.
27 Sep 2026
