Engifoundry Verify

EngiFoundry Verify

For configured work, read ./engifoundry.config.json, the project-owned workspace guide, and contracts.md. For the Router-authorized unconfigured fallback direct path, read only contracts.md, use the default .engifoundry/packages/ PAK and write verification under .engifoundry/artifacts/verification/; do not require configuration or create preference files. Then read the Phase context and PAK. For direct, read its concise Job requirement contract, implementation outputs, current evidence, and any actual Review. For package, read every Job result and Review, every required artifact, and any prior Verify extension.

Boundary

For direct, the Agent reads this contract after the controlling Agent has completed implementation and set execution.status: verifying. Verify is the mandatory final requirement-contract acceptance gate. It does not implement corrections or enlarge the requirement; a correctable failure returns bounded work to the controlling Agent.

For package, the Agent reads this contract only with planning.status: ready and execution.status: jobs-completed, and verifies the complete PAK goal rather than individual Job steps. It does not implement, revise contracts, repeat Job Review, accept verification, deliver, or reopen or rewrite completed Job states.

Automation preferences never weaken verification evidence. Package evidence is an input fact for Deliver; direct verification is itself the final acceptance and does not enter Deliver.

Direct Closure

Keep direct Verify as small as the task permits, but never omit it. Map the authorized requirement and acceptance boundary to the actual output and fresh evidence. Confirm all three closure facts:

1. Qualified: the requested result works and no known failure invalidates delivery.
2. No drift: changes and conclusions remain inside the authorized requirement and scope.
3. Acceptable: evidence is sufficient for a reasonable recipient to accept this specific task.

Test is evidence, not a mandatory ritual. The Agent chooses whether a focused unit test, existing suite, static check, real runtime, emulator, device, visual inspection, or another concise method best proves the requirement. UI and interaction work commonly need actual runtime or device evidence; a deterministic path or boundary bug commonly benefits from a focused unit or regression test. TDD is not a direct Verify requirement.

Reuse valid current evidence and run only missing checks needed for closure. An optional direct Review is relevant evidence when it occurred, but Review absence is never a gap by itself. Write one immutable concise verification record and attach it as execution.verificationRef.

Direct Verify records exactly one result:

• verified: every requirement is satisfied, scope has not drifted, and evidence is sufficient. Set direct execution to completed; this is final acceptance.
• rework-required: a concrete failure or evidence gap is correctable within the concise requirement. Return execution to in-progress for bounded controlling-Agent correction, then create a new Verify record.
• blocked: an objective unavailable input or environment prevents acceptance and no valid alternative evidence exists.

Direct Verify never produces a Package extension, invokes Executor, or enters Deliver. Being a light task can reduce the breadth of checks, never the closure threshold.

Package Verification

1. Record execution.status: verifying while evidence is synthesized.
2. Map every PAK criterion to Job conclusions and current valid evidence.
3. Synthesize every Job conclusion, blocking and non-blocking Review finding, accepted risk rationale, dependency obligation, required artifact, and closeout fact.
4. Reuse current valid evidence. Run only the minimum missing PAK-level check when coverage is absent, contradictory, or invalidated, or when integration cannot be shown by Job evidence.
5. Judge prior risk acceptance against the contract, its recorded operating assumptions, required baseline checks, and the material-risk floor. Expanded scale, concurrency, threat, availability, or usage scenarios apply only when evidence invalidates a recorded assumption or makes the risk reachable inside its boundary; a preferred implementation or newly expanded goal does not.
6. Write one immutable verification record and attach it as execution.verificationRef.

The completed verification record has exactly one result whose meaning matches the evidence:

1. If every criterion and required baseline check is satisfied and remaining risks have sufficient non-blocking rationale under the recorded operating assumptions, write verified-available.
2. If one complete, bounded addition can close every remaining contract or evidence gap, and no extension was used, write extension-required with one complete extension specification for exactly one appended Job.
3. If a major evidenced contract breach makes the execution chain unacceptable, or the appended Job completed without closing its specified gap, write rejected.
4. If a required conclusion cannot be reached because of an objective external condition and no valid alternative evidence exists, write blocked.

For Package verification, never write pass or rework-required. verified-available means evidence is available; it is not acceptance. Ordinary disagreement with a non-blocking technical choice cannot produce an extension or rejection.

An extension specification states all gaps, contract references, dependencies, protected completed Jobs, required outcome, acceptance criteria, verification plan, and why one appended Job is sufficient. Orch materializes it without reopening prior Jobs. Once extensionUsed is true, Verify must not return extension-required again. A later new user goal belongs to a new PAK.

rejected rejects the execution chain rather than scheduling rework. It requires a major evidenced contract breach and an explanation of why the single extension cannot or did not close it. Completed Job records remain historical facts.

Continuation

• Direct verified is terminal and permits direct execution completed.
• Direct rework-required lets the controlling Agent make the minimum in-scope correction and Verify again.
• For an endpoint that includes delivery, verified-available lets the Agent read Deliver and continue with the PAK and verification record.
• extension-required lets the Agent read Orch for the one appended Job.
• rejected is terminal for the execution chain.
• blocked is terminal while its objective fact remains.

Never continue without the required record or without loading the destination Skill first.

Evidence synthesis and one-extension examples are in examples.md.