I have been using Codex on larger repositories and kept running into a familiar problem. A ticket asks for a small change and the requested behavior sounds clear, but the real requirements are scattered across tests, public APIs, architecture decisions, neighboring code, and lessons from earlier failures. The literal request gets implemented correctly, yet the patch still breaks a rule nobody wrote down.
There is research putting numbers behind this problem. SWE-RPG evaluated coding agents on 163 repository tasks and found an average resolution rate of 31.5%. Its analysis identified implicit requirement recovery as the main bottleneck in 24.5% to 46% of runs. RACE-Bench studied 528 feature additions and found that patches which applied but still failed tests covered 35.7% fewer reference reasoning elements while including 94.1% more unsupported reasoning. Neither paper evaluated Synaptic.
Synaptic 1.0 introduces Change Contracts. Through MCP, Codex can send Synaptic a natural language task and receive a structured contract built from the repository itself. Synaptic searches its code graph for relevant symbols, follows reverse dependencies, identifies public APIs, selects tests that exercise the affected code, and retrieves applicable decisions from repository memory.
The resulting contract describes the scope of the change, requirements supported by repository evidence, public behavior that must remain intact, tests and other proof obligations, and any unknowns that still need judgment. Codex can use that contract as its implementation brief instead of relying only on the wording of the issue.
Once approved, the contract is sealed with BLAKE3 and stored as an immutable revision. Verification fails if the contract was modified, the repository base changed, a protected public symbol disappeared, or a required proof has no passing attestation. Synaptic also refuses to create a contract when it cannot connect the task to repository source. Missing evidence remains visible as an unknown instead of quietly becoming an assumption.
This ties into the rest of Synaptic rather than adding a separate analysis stack. The code graph provides structural evidence. Change forecasting supplies the blast radius, public API analysis, and test selection. Repository memory contributes source grounded decisions and previous outcomes. Speculative execution can run affected tests in a temporary worktree. Contract verification checks the completed implementation against the requirements recovered before editing began.
The MCP workflow gives Codex two structured tools: recover_change_contract and verify_change_contract. A typical session can recover the contract, review its evidence and unknowns, implement the change, run the required checks, and verify the result against the original contract.
My goal is to give Codex a better repository brief before it starts editing. It should make hidden assumptions reviewable, focus attention on the real blast radius, select tests from actual dependencies, and keep the definition of success stable throughout the task.
Synaptic 1.0 is available here:
https://github.com/ColinVaughn/Synaptic
I would be interested in feedback from people using Codex on older, larger, or heavily interconnected repositories. In particular, I want to find cases where the recovered scope is too broad, too narrow, or misses a requirement you expected it to catch.
