Engifoundry Review

EngiFoundry Review

Reviewer Selection And PAK Review Chain

This section applies only to the controlling Agent arranging Review. A session that received engifoundry.reviewer-task/v1 is already the Reviewer Worker; it skips selection and must not invoke or select another Reviewer.

Read the complete project-owned Executor configuration and the complete schema referenced by its schemaRef. Use the configured reviewer; never replace it with a host-native subagent or another available CLI merely because that mechanism has lower overhead.

For a package PAK, the first Planning, Job, or rework Review establishes one PAK Review chain by invoking the configured Reviewer in a genuinely fresh context through its verified CLI usage. Later Reviews for the same PAK default to continuing the same Reviewer session, across Planning, different Jobs, and rework. This continuity lets the Reviewer retain its prior findings and observe whether corrections converge; it does not authorize implementation or controlling work.

The chain is eligible only while the Reviewer can inspect the complete primary subject and evidence, perform every required check with verified available tools, did not perform or repair the reviewed work, and has not been contaminated by implementation discussion or an intended conclusion. The same model as the producer is acceptable because independence comes from the clean chain boundary and separation from implementation, not a different model.

Start a new genuinely fresh Reviewer context when the PAK's authorized contract, design, scope, acceptance boundary, or authority changes materially; the Reviewer performed or repaired implementation; continuation is unavailable or cannot be trusted; or the user explicitly requests an independent opinion. The new context receives the prior immutable Review records for that PAK as evidence so it can recover the finding history without receiving implementation discussion. A continuation or session handle is transient host state: never write it to project records, task envelopes, or handbacks.

When direct Review is arranged, use one genuinely fresh Reviewer context for that bounded Review. Direct work does not establish a reusable Package PAK Review chain.

Read the configured Reviewer's recorded input capabilities and construct protocol engifoundry.reviewer-task/v1 exactly as defined in the reference contract. Its handback member always embeds the complete handback schema; a format-only reference is invalid because the Worker must not discover that schema elsewhere. Prefer verified native structured input and a separate system/instruction role channel when recorded; otherwise use the canonical plain-text wrapper. The identity fields, handback schema, and zero-delegation rules are identical in both forms and are never optional. A legacy Reviewer configuration without capability facts uses the text wrapper.

A session receiving this protocol task is already the Reviewer Worker. It must not arrange another Review, invoke an Executor, subagent, or Agent CLI, repair the subject, route project work, or write control records. It inspects only the declared subject and returns one engifoundry.reviewer-handback/v1 object.

Apply the reference contract's strict production and tolerant consumption rules to normalize raw Reviewer output. Do not retry merely because one semantically valid handback has surrounding prose or unknown fields.

Validate normalized identity before accepting a conclusion. A wrong role, delegated: true, non-empty controlActions, further Agent or worker invocation, control-record writes, repair, or controlling behavior is reviewer-role-violation; reject the handback even when its conclusion appears usable. Retry only for missing or ambiguous required semantics or another safely correctable invalid handback; never repair the prompt ad hoc or accept recursively delegated Review.

Objective unavailability before a conclusion makes Review unavailable; record the factual blocker and do not silently substitute another Reviewer. pass and rework-required are conclusions, not selection failures; never repeat Review to seek a preferred result. A new Review requires a changed subject, an invalid prior attempt, or an explicit multiple-Review requirement.

When no eligible clean chain establishment or trustworthy continuation mechanism is actually available after inspecting host capabilities, first attempt the permitted clean-context fallback with prior PAK Review records. If that is also unavailable, Review is unavailable. Record that objective fact in the subject state; do not fabricate a Review attempt or reuse the producing context.

The controlling Agent reads ./engifoundry.config.json, the project-owned workspace guide, contracts.md, and reviewer-task.template.json in full. The Reviewer Worker uses the complete schema already embedded in its task and does not read the task template. Review the complete subject, applicable requirements, and evidence; do not rely on handback summaries when primary evidence is available.

Direct Review Profile

For a direct PAK, Review is optional and the controlling Agent alone decides whether its concrete risk or evidence uncertainty justifies the overhead. When arranged, keep Review bounded to the authorized requirement, actual changed subject, task-appropriate evidence, obvious correctness failures, and reachable material risk. The first priority is whether the requested result is satisfied and suitable for final Verify.

Do not impose Package planning completeness, broad quality uplift, TDD, extra Test matrices, preferred implementation, style cleanup, optional refactoring, or speculative scenarios on direct work. Record the minimum useful conclusion and evidence. A direct Review may identify correctable work before Verify, but its absence never blocks direct closure; Verify remains mandatory.

Review

Inspect applicable contract and material-risk concerns:

• requirement and contract compliance;
• scope, dependencies, allowed and forbidden areas;
• correctness required by the recorded acceptance criteria;
• tests and verification evidence supporting the claimed result;
• record and reference consistency;
• material security, data, compatibility, destructive, or delivery risk.

Review pursues higher quality within the recorded operating assumptions, required project checks such as configured lint, and the material-risk floor. It may record and encourage bounded quality refinements, but they remain non-blocking unless they meet the blocking threshold below. Review does not enlarge the goal, require a preferred implementation, or block on style, optional refactoring, unrequested enhancement, unsupported speculation, or unrelated pre-existing defects.

Every finding states blocking. A blocking finding requires evidence of an acceptance or scope breach, failed required baseline check, missing required output, regression or dependency incompatibility reachable under the recorded operating assumptions, or material risk reachable inside that boundary. Other findings are non-blocking. A material risk is reachable only when evidence connects the actual implementation and declared operating boundary to material impact; generic possibility is insufficient. Scale, concurrency, threat, availability, or usage assumptions outside the recorded boundary cannot block unless evidence proves the recorded assumption false. Order findings by impact and tie blocking findings to contractRefs and evidence. blocking: true does not itself mean blocked; the in-contract correctability boundary below selects rework-required or blocked.

The Reviewer Worker returns exactly one conclusion:

• pass: contract acceptance and required baseline checks are satisfied and no unresolved reachable material risk remains; non-blocking quality findings may remain recorded.
• rework-required: at least one unresolved blocking finding can be corrected within the current authorized contract, design, scope, and allowed areas.
• blocked: an objective condition prevents Review from reaching a conclusion, or evidence proves that no safe correction can satisfy the current authorized contract without a user-authorized contract, design, scope, or authority change.

A blocking missing output, failed required check, implementation defect, or insufficient required evidence is rework-required while it remains correctable within the current contract. A contract conflict is blocked only when evidence shows why no safe in-contract correction exists and identifies the exact user decision required. Without that proof, an unresolved blocking breach remains rework-required even when its correction is not yet known. Never use blocked for uncertainty, difficulty, preference, a correctable failure, or repeated failed attempts alone.

Convergence

The first Review establishes the blocking finding set. After correction, inspect the complete current subject for regression, but add a new blocking finding only when it was introduced by the correction or new evidence of a blocking contract breach became available. Other newly noticed issues are non-blocking.

Continue correction, investigation, and Review in the same PAK Review chain while observed reality can still be reconciled with the current contract through permitted work. Follow a stable, evidenced correction path immediately when one exists; keep investigating or debugging when one is not yet known. Conclude pass as soon as the blocking threshold is clear; no Review count or identifier limits correction. Non-blocking refinements may still be pursued within the current execution, but they never justify rework-required or another Review on their own. Each new Review requires an actual relevant change and fresh evidence. When the relevant subject has not changed, continue implementation or debugging rather than issuing another Review. Conclude blocked only from objective evidence that the contract cannot be reconciled or a contract-required input is unavailable.

Record And State

For every valid actual Review attempt, the controlling Agent writes one new immutable Review record from the validated handback and updates the subject's reviewRef when it has one. Never overwrite an earlier attempt. Raw Reviewer output is transient and is never the canonical record.

• Planning ready means the current planning subject has a valid PAK-chain pass and no newer invalidating fact. rework-required means a correctable current finding remains. blocked means Review is factually unavailable or safe planning requires a user-authorized contract decision.
• Job pending-review with a pass reviewRef means Review is complete but Exec completion or approval facts are not yet recorded. rework-required and blocked carry the matching current Review evidence.
• Other durable outputs use the immutable Review record without an invented control state.

The Reviewer Worker reports findings and applicable state facts in its handback. The controlling Agent writes the canonical Review record and state changes. The Reviewer does not repair the reviewed subject, change its contract, accept delivery, or continue unrelated work.

Blocking, advisory, and convergence examples are in examples.md.