Green is one evidence layer—not the whole transaction.

No. The agent supplies judgment or implementation depending on the workflow. KodeProof owns the transaction: before-state, declaration, isolation, actuator authorization, evidence, verdict, and transfer.

Covered transformations can be applied by deterministic actuators. In other workflows an agent may edit the isolated candidate. The original repository is not the agent’s workspace.

Not in the guarded transaction model. Candidate work occurs in an isolated workspace. Transfer is a separate, verified step. If a harness cannot write to the candidate safely, the workflow must expose that limitation.

No. Tests, typecheck, lint, build, and CI-style commands remain important. KodeProof adds transaction intent, before-state, protected contracts, structural and boundary evidence, causal classification, and transfer control.

No. Green means configured evidence did not find a blocker and the declared transaction satisfied its gates. Evidence strength, coverage gaps, task completeness, and independent evaluation still matter.

A false block occurs when KodeProof rejects a candidate that satisfies the full declared transaction and independent task contract. A candidate that passes hidden behavior but violates a declared public or architecture contract is not automatically a false block.

It can identify source-backed opportunities and present bounded choices. It should refuse to invent semantic ownership merely to make the task mechanically complete.

The current focus is JavaScript/TypeScript-family repositories and the exact capabilities exposed by installed provider versions. KodeProof uses live capability discovery because contracts and coverage continue to change during alpha.

The architecture is designed around model and harness independence, but real compatibility depends on the agent’s ability to follow the workflow, read evidence, write to the candidate, and execute commands.

That is an evaluation question, not a default marketing claim. Bounded packets and deterministic actuators may reduce re-derivation, but the safety workflow also adds evidence and command cost.

No. Any evidence system has coverage limits. KodeProof is designed to make those limits visible, calibrate checks with known-bad changes, and keep safety claims separate.

The original remains unchanged. The candidate and evidence can be retained for repair, inspected, revised where allowed, rerun, or explicitly abandoned.

It can consume security findings and protect transaction policy, but it is not a replacement for security review, vulnerability testing, or secure development practice.

The product is designed for local, isolated, and potentially offline-capable workflows, but exact data handling depends on the agent, model provider, environment, and trial terms.

KodeProof is in private alpha. Kalu Kode is selecting a small number of bounded trials with technical owners who can evaluate the workflow and its failures honestly.