Stop guessing
what’s left to ship.
Closure Engine finds missing requirements, checks what’s proven, and gives your coding agent a focused next task. A clear path from “almost done” to done.
Checkout isn’t open yet.
Runs locally. Works alongside your coding agent.
pnpm closure plan --repo ../subject
closure / subject
- scope
- invitation acceptance
- required
- 5
- proven
- 5
- remaining
- 0
DONE = TRUE
All five requirements have current, admissible evidence.
next task: none
“All tests pass”
isn’t the same
as “it’s done.”
Your agent works on what it sees. Closure helps surface the requirements nobody wrote down.
An expired invitation. A revoked link. A request sent twice. A passing happy-path test doesn’t establish those protections.
Understand the model- Expired linkIs access refused?
- Revoked invitationDoes revocation take effect?
- Repeated requestCan it create a duplicate?
A finite plan.
Not a longer backlog.
Define the requirements. Check the evidence. Give your agent only the work that remains.
Illustrative workflow: invitation acceptance.
Define what’s owed.
Choose capabilities from the catalog. Closure expands them into required behavior, dependencies, and policies.
Teams can invite people.
1 capability · 5 requirementsSee requirements
- Valid invite creates a membership
- Expired links are rejected
- Revoked links cannot be used
- Replays cannot add a second member
- Invites stay inside their organization
Check what’s proven.
Match requirements to repository evidence. Closure checks admissibility and whether proof inputs still match.
3 of 5 proven2 still need proof
Inspect proof
- Valid invite creates a membershipProven
- Expired links are rejectedUnproven
- Revoked links cannot be usedProven
- Replays cannot add a second memberInadmissible
- Invites stay inside their organizationProven
Expiry has no evidence. Replay evidence is inadmissible because its negative control still passes under the declared perturbation.
ProvenUnprovenInadmissible
Work the difference.
Give your agent a bounded task with proof requirements. Reconcile returned proof to update the plan.
Task out. Proof back.Expiry · 1 of 2 remainingEstablish proof that expired invitations are refused.An expiry task is pulled from a plan and handed to the coding agent. Its evidence packet returns for reconciliation, not automatic completion.
Proof required
- Passing expiry test
- Verified negative control
- Matching proof inputs
Reconcile again to update the plan.
Every count has a reason.
Select a requirement. Inspect its proof.
Follow the same invitation flow from missing proof, through changed code that needs fresh verification, to “Verified”: all five requirements proven, zero remaining.
Inspect the exampleInvitation acceptance
Interactive exampleThe behavior is required, but no admissible proof establishes that an expired invitation is refused.
Illustrative data, not a live repository scan.
Would your test catch the failure?
Break the protection in an isolated copy. Run the same test. Check that it fails.
For critical and tier-4 test evidence, Closure requires a negative control: the test must pass before the declared change and fail after it. If it stays green, that control hasn’t demonstrated the protection.
How negative controls workSame test, both runs“Expired links are rejected”
if (invitation.expiresAt < now) {
return reject("INVITE_EXPIRED");
}Expired invitation rejected
Disable only the expiry check
if (false) {
return reject("INVITE_EXPIRED");
}Expired invitation accepted
This test notices when the expiry check disappears.
This establishes sensitivity to the chosen perturbation—not proof of every possible failure.
Done is a verdict.
Not a vibe.
The finish line belongs to a defined scope and a particular repository state. It can move when the facts change—not because the agent thought of one more improvement.
DONE = TRUE5 of 5 proven- Accept
- Expiry
- Revoke
- Replay
- Boundary
All requirements proven in this example’s scope.
The code covered by the expiry proof changes.
DONE = FALSE4 of 5 proven- Accept
- Expiry
- Revoke
- Replay
- Boundary
Expiry evidence is stale. One requirement reopens.
Next taskRe-run expiry verification against the changed inputs.
- Every required capability reaches its target.
- A polished corner cannot hide a missing foundation.
- The proof still matches the code.
- Changed inputs invalidate old evidence and reopen work.
- Unresolved blockers stay visible.
- Gaps and contested requirements don’t disappear into a percentage.
A scoped verdict, not a bug-free guarantee. Unknown requirements and catalog blind spots still need human judgment.
Before you start.
Is Closure another coding agent?
No. It sits above implementation work. The catalog establishes requirements, the engine evaluates evidence and schedules what remains, and a coding agent—or a human—writes the code.
Does it replace my tests or CI?
No. It connects evidence to explicit requirements. Existing test reports can supply evidence; bindings, extractors, and negative controls determine what that evidence actually supports.
What’s available today?
A local TypeScript CLI that builds and installs from a checkout, not a public registry. This site demonstrates the model; it does not scan your repository. The field guide covers setup, supported evidence, and current limitations.
Can it know every requirement my project needs?
No. Coverage is bounded by the catalogs, selections, bindings, and extractors you provide. Closure makes known obligations explicit and verifiable; human review is still needed to find what those inputs don’t describe.
Less “one more thing.”
More finished.
Purchasing isn’t available yet. Explore the setup guide while we finish checkout.