Inspiration
A control can look perfectly usable and still leave someone stranded. An accessibility report identifies a problem, but a developer must still understand the intended task, repair the right code, and protect that behavior in the next release. Passage connects those steps.
What it does
The demonstration starts with a concrete problem in TodoMVC: a keyboard user cannot enter editing mode. Passage records the actual attempt and turns it into a reviewable contract. Observed behavior and inferred requirements are shown separately. The contract is frozen before repair, so the model cannot change its acceptance criteria to make a patch pass.
NVIDIA Nemotron on Nebius inspected bounded React source and proposed changes to two files. The candidate supports keyboard entry, preserves the title when an edit is canceled, and saves a deliberate change. Three frozen checks pass for that exact candidate. Checks that the original attempt never reached remain unrun.
The result is a portable guard containing the contract, source identities, locked dependencies and replay code. A developer can check a later revision without model credentials or the original database.
How I built it
React and TypeScript sit above a Node service, SQLite and actual Playwright execution. The external React adapter uses a disposable Linux worker with fixed dependencies. It runs no repository package scripts and receives no provider credentials. Source inspection, exact citations, cumulative patches and independent replay are separate stages with retained receipts.
The demonstrated repair used nvidia/Nemotron-3-Ultra-550b-a55b through Nebius Token Factory. Its October 28 request and patch are retained. The video opens that recorded result and demonstrates the original and repaired interaction; it does not imply a fresh model call.
Challenges and what I learned
The difficult part was defining what success must preserve. Enabling editing is not enough if canceling loses the original value. Freezing expectations and executing exact outcomes proved more useful than asking a model whether its own patch looked correct. I am proud that the result can leave the workbench as a check the next developer can run.
What comes next
The evidence is automated development evidence for bounded tasks, not a participant study or accessibility certification. Next steps are independent keyboard and screen-reader testing, more external applications, and maintainer review. The aim is to make a person's blocked task a durable part of how software is tested.
Log in or sign up for Devpost to join the conversation.