Engifoundry Orch

EngiFoundry Orch

<project-root> is the root of the target project. It normally contains engifoundry.config.json; the Router-authorized unconfigured fallback direct path is the only exception. <orch-skill-root> is the directory containing this SKILL.md. These are independent locations: never infer the project root from the Skill installation path, and never look for bundled Orch resources under the project root.

For configured work, read <project-root>/engifoundry.config.json, the project-owned workspace guide, the Workflow config, and <orch-skill-root>/references/contracts.md before writing records. For package, also read the complete Executor/Reviewer config and schema. Every Planning Review uses the configured Reviewer under engifoundry-review.

For the Router-authorized unconfigured fallback direct path, read only <orch-skill-root>/references/contracts.md. Use .engifoundry/packages/, create or reuse PHASE-001, and create only a direct PAK with one concise Job. Do not run Audit or create project configuration, workspace, Workflow, Executor, Reviewer, Package, or delivery records. These sparse paths are compatible with later Init adoption. Inline fallback never reads Orch.

Boundary

The Agent applies this contract to turn a classified task goal into execution input. While doing so, it does not select an Executor, edit implementation, perform delivery verification, or close delivery.

For configured new work, Router reads engifoundry-audit before selecting Orch:

• direct: create the minimal PAK and one Job requirement contract, then the controlling Agent implements it under Router Group Rules and closes it through Verify.
• package: the Agent applies this contract to create execution input.

inline and blocked do not read Orch. Do not re-audit a supplied classification or explicit continuation of an existing PAK or Job.

executionMode is authoritative and is never inferred from files or field count. migration, or a missing mode with confirmed migration provenance, is preserved without Review, challenge, or runtime activation.

Direct Record

For direct, allocate one PAK and JOB-001, write the authorized requirement and overall acceptance boundary in job.md, and record only current status, evidence references, and execution.verificationRef in package.config.json. The narrative may contain the ordered actions, approvals, checkpoints, and controls needed for one atomic goal; these do not become separate Jobs without independent outcomes. The controlling Agent performs the work without Executor delegation, selects task-appropriate evidence, and may arrange bounded Review when it has concrete value. After implementation, set the Job to completed and execution to verifying; Verify is mandatory. Only a direct Verify result of verified permits execution status completed. The sparse structure is complete for its mode and does not trigger Planning Review, Exec delegation, Package verification extensions, or Deliver.

Package Orchestration

Before allocation, confirm the classification facts identify independent outcomes or a responsibility, acceptance, delegation, or handoff boundary that direct cannot represent. State that orchestration value in the existing summary.md; do not add a control field for it. Steps, files, risk, or publication activity alone are insufficient.

1. Resolve the relevant Phase from phase.index.json, Phase status, and Roadmaps. Use PHASE-001 when the project has no meaningful period model.
2. Allocate Phase, PAK, and Job identifiers monotonically. Never reuse or renumber identifiers.
3. Write human narrative in Markdown and machine control in JSON using the reference contract.
4. Keep planning.status: draft while content is incomplete.
5. Before Review, simulate the Job sequence against its dependencies, outputs, shared areas, interfaces, versions, compatibility duties, and acceptance evidence. Set reviewRequired true only where scope or impact gives independent Review concrete value; keep it false for bounded work sufficiently controlled by required evidence. Record these facts in existing narrative and contract fields rather than inventing implementation detail.
6. When the PAK and every Job are internally consistent, record planning.status: pending-review. The configured Reviewer Worker reads engifoundry-review, examines the complete planning subject including dependency simulation and each Review decision, and returns its identity-locked handback. The first Review establishes the clean PAK Review chain; later Planning, Job, and rework Reviews default to the same Reviewer session unless the Review contract requires a reset. The controlling Agent validates the handback and records the conclusion.
7. Planning is ready only while a current valid PAK-chain Review pass exists and no newer blocking fact invalidates the contract.
8. Planning is rework-required only for an unresolved blocking Review finding whose facts can still be reconciled with the user's authorized goal, design, scope, and authority through permitted planning work. Continue correction or investigation until the contract passes or objective evidence establishes blocked; non-blocking findings do not delay readiness.
9. Planning is blocked while an objective fact prevents a usable Review conclusion or safe planning requires a user decision that changes the authorized goal, design, scope, or authority.

draft, pending-review, and rework-required do not describe executable planning. Correction requires an actual relevant change and fresh evidence, continues independently of Review count, and ends only with ready or factual blocked. Quality refinement remains welcome within planning, but only blocking facts defined by Review delay ready.

Blocked Contract Revision

When Exec or Planning Review proves that safe continuation requires a contract, design, scope, or authority change, preserve the blocker evidence and prepare the complete minimum revision proposal without changing the current contracts. Pause for the user's decision. After authorization, revise only the affected contracts, reset to a new clean PAK Review chain when the change is material under the Review contract, obtain Planning Review, and resume Exec from the resulting recorded facts.

Verification Extension

For one current extension-required record, convert its complete extension specification into exactly one appended Job with extensionRef. Preserve every completed Job and its evidence. A PAK that already records an extension Job cannot append another. Review only the appended contract and its dependency effect, not the unchanged original planning.

Output

Write execution input only under the configured package root. The controlling Agent writes validated Reviewer evidence under the configured artifact review directory. Never store raw model output, credentials, cache state, or transient sessions in either location.

Commands

• macOS/Linux: sh <orch-skill-root>/scripts/orch.sh create-phase|create-direct|create-package|append-job|check --project-root <project-root> [options]
• Windows: powershell -ExecutionPolicy Bypass -File <orch-skill-root>/scripts/orch.ps1 -Action create-phase|create-direct|create-package|append-job|check -ProjectRoot <project-root> [options]
• Unconfigured direct fallback adds --unconfigured-direct or -UnconfiguredDirect to create-phase, create-direct, and check. The flag never authorizes create-package or append-job.

Resolve the bundled script from <orch-skill-root>/scripts/ and always pass <project-root> explicitly. Use the action matching the recorded mode or extension fact. Only when the correctly resolved script remains unavailable may the Agent use the complete reference contract manually.

The helpers handle only allocation and skeleton creation. Fill every semantic field and require check before recording pending-review; when the helper itself is non-runnable, perform the equivalent contract checks manually. The Agent writes Review evidence, reviewRef, and conclusion state directly from the applicable contracts.

Continuation

For direct, the recorded minimal PAK lets the controlling Agent act, and completed implementation evidence lets it read Verify for mandatory closure. For a package endpoint that includes implementation or delivery, a ready PAK is the fact that lets the Agent read Exec. A recorded appended Job also lets Exec continue. A bounded orchestration request ends with its recorded fact.

Mode-selection and dependency-simulation examples are in examples.md.