Role delegation

Role delegation

The orchestrator coordinates; it doesn't implement, plan task records, or perform final review. Delegation completes only when the designated role executes the work, not when the orchestrator describes it.

Advance Authorization

Delegation is state-changing under the Advance Authorization Boundary in agenticloop/AGENTIC_LOOP.md. Delegate only when explicit instruction or standing authorization to advance is present and the source can be named.

Authorization attaches to a work unit, not each step. Routine lifecycle steps inside it – implementation, review, and revision delegations – are covered without per-transition approval.

Do not delegate merely because a bounded request reveals a next step. Status checks, inventories, explanations, diagnostics, and direct questions end once answered; report the next step and stop unless the human authorized advancing.

When to Use

Apply this skill when the orchestrator:

• starts or resumes a task loop (identifying the current task, optional grouping context, or next step),
• routes first-run project-map setup or confirmation through [[setup-agenticloop]] when setup is still unconfirmed,
• hands off task-record creation or refinement to maintainer,
• hands off implementation or revision work to engineer,
• routes an implementation artifact back to maintainer for review,
• routes a revision to engineer based on review feedback,
• hands off work-unit certification to auditor once the covered tasks are accepted and integrated,
• runs closeout or records a human checkpoint decision.

Delegation Rules

What the orchestrator does	Role that owns it
Identify phase, task, backend	orchestrator
Decide whether a source work item is one task or a task set	maintainer
Set up or confirm project map	maintainer
Create or refine task records	maintainer
Plan scope, acceptance criteria, proof pressure when needed	maintainer
Classify per-task parallel safety and resolve code/collision unknowns	maintainer
Validate host/lane capability, record concurrency plan, and delegate lanes	orchestrator
Implement scoped work	engineer
Revise after review feedback	engineer
Record a timed-out check attempt and return its observation	engineer
Final-triage a timeout and update the current verification-fact profile	maintainer
Apply one bounded Maintainer Review Fixup during an active eligible review	maintainer
Review implementation artifacts	maintainer
Accept or request revision	maintainer
Certify the completed work unit	auditor
Disposition audit findings into remediation tasks	maintainer
Closeout and retrospective	maintainer

The orchestrator does not create task records, implement, review, or accept.

A gate failure names an owner; it does not transfer that owner's edit authority to Orchestrator. Orchestrator re-delegates to the diagnostic owner, escalates to the human when named authority is required, or stops at the hard checkpoint. It must not repair Engineer-owned PR bodies or commits, or Maintainer-owned task records, while a legal delegation path exists.

Use immutable roleId for dispatch, return, attribution, filenames, config, and authority; resolve display labels from the canonical registry. Each dispatch binds the selected host's closed role-capability declaration. A non-native restriction is advisory or unavailable, not enforced, and names its next authoritative detection boundary, limitation, and recovery route. enforced requires every shipped write-capable route constrained. OpenCode's bash, Copilot's execute, and Codex instructions are advisory. Bind one version 3 report per degraded action, emit capability.enforcement.degraded, and check it against authenticated actor/evidence on return import.

Handoff preflight

Run npx agenticloop task handoff-preflight <id> --json before packet assembly. It is read-only and reports activation usability, exact authorization, readiness, decomposition, capability, worktree, and relevant sibling-collision evidence in one result. A derived-only repair may be planned and explicitly applied with task refresh-handoff-evidence; it never changes the protected task contract or product files.

Implementation dispatch

Before Engineer delegation, the orchestrator runs npx agenticloop task prepare-dispatch <id> --host <host> --role engineer --output <packet-path> --json. The packet binds activation, task/contract, readiness, decomposition, scope/checks, role/invocation, host capability, worktree, and cancellation facts. Only its fixed operator-trust registry authorizes activation.

All artifact paths are target-relative. The files-backend canonical single command for role start is:

npx agenticloop task role-start <id> --packet <packet-path> --check-evidence-output <checks-path> --json

This atomically combines the in-progress carrier transition, dispatch consumption, attempt supersession, and required-check evidence initialization into one guarded transaction. The caller must not pass --expect-digest; it is derived from the packet. Partial failure returns a typed receipt with exact recovery guidance and never implies success. An exact idempotent retry reports already_current; a retry with any changed bound state fails closed.

For GitHub, the existing guarded task-body path is used instead:

npx agenticloop task-body transition --issue <n> --status in-progress --dispatch-packet <packet-path> --expect-digest <digest> --yes
npx agenticloop task check-evidence-init <id> --packet <packet-path> --output <checks-path> --json

The ordinary public sequence for the full lifecycle (files backend) is:

npx agenticloop task prepare-dispatch <id> --host <host> --role engineer --output <packet-path> --json
npx agenticloop task role-start <id> --packet <packet-path> --check-evidence-output <checks-path> --json
npx agenticloop task check-evidence-update <id> --packet <packet-path> --input <checks-path> --output <checks-path> --check <check-id> --outcome passed --evidence <text> --execution-output <execution-path> --json
npx agenticloop task prepare-return <id> --packet <packet-path> --check-evidence <checks-path> --outcome implementation_ready_for_review --output <return-path> --json
npx agenticloop task verify-return <id> --packet <packet-path> --return <return-path> --from-current-repository --json

For a non-passing or non-command check, use the same update command with its observed outcome and omit --execution-output as required by that check form. Missing, stale, consumed, already-current, or noted starts fail closed without a fresh packet. Engineer invokes the read-only verifier before mutation; its unkeyed record proves packet/result integrity, not validator identity or origin. Public boundaries rerun validation and accept no caller-authored receipt. The raw agenticloop.role-return binds that packet with disposition: proceed and only a non-authoritative implementation outcome; Orchestrator validates or reroutes, never reconstructs it. Standard mode may persist a fully revalidated session_reported return without producer authentication. Hardened mode requires host provenance for repository, adapter/key, invocation, packet, return, liveness, and repository evidence. The verifier uses the packet-selected key; replayed, unsigned, or self-attested receipts fail closed. The observed producer must match assignment and raw producer; trailers cannot repair a mismatch.

Do not hand-author JSON/digests or substitute host status, messages, handles, or cancellation observations for a return; host status proves no cancellation.

Files retain the in-progress carrier. Use task evidence with current digest for artifact, summary, and outcome evidence. Receipts preserve taskContractDigest and link dispatchCarrierDigest to currentCarrierDigest; return product/workflow heads and lineage. Then use task review-prepare <id>.

task verify-return / role_return_receive gates blocked resume and recovery. Owner transfer or destructive recovery needs the exact pinned signed authority; digests, labels, trailers, keys, and self-minted records cannot substitute.

Work-unit certification is auditor-owned and a fresh, separate invocation each time; see [[work-unit-audit]]. Auditors never implement, accept tasks, or accept limitations or risks. A non-certifying report uses ordinary maintainer/engineer remediation, not another auditor pass.

Engineer owns scoped implementation and ordinary revision. The sole exception is one fully understood Maintainer Review Fixup during an active eligible review under [[review-and-accept]]. It needs no Engineer invocation and is not a needs_revision round; an unsuccessful, ineligible, expanded, or independent-review finding returns to Engineer. Delegation mode and final review_mode differ: a host_subagent maintainer records single_agent_fallback when accepting its own fixup.

Slice sizing

Default to one smallest useful, independently verifiable task. An authorized larger run still uses bounded, reversible, independently verifiable slices; broad authorization does not permit one oversized record.

Host Delegation Mechanism

Real delegation starts a separate maintainer, engineer, or auditor role, task, named-agent, or subagent execution; narration is not delegation.

Auditor has no fallback. single_agent_fallback never satisfies a work-unit audit: a same-session continuation re-reads its own conclusions. If no real delegation mechanism is available, record the blocked condition instead of auditing inline.

Delegation Capability Check

Before fallback, check for a host task, subagent, role, agent, type, mode, or subagent_type mechanism. Use one if available; otherwise record how absence was verified or the attempted mechanism and failure reason.

Concurrency Policy

Delegation is serial by default. Parallel writes require mutation and knowledge independence. Every authorized multi-task unit carries a current post-decomposition Parallel Opportunity Scan from read-only npx agenticloop task prepare-decomposition <id>. Completeness is derived by that authoritative enumeration, never asserted. Inventory and bound readiness context are refetched before dispatch.

Read inventory completeness before ready count:

• incomplete inventory or decomposition -> incomplete; never an eligibility answer, never "no work"
• complete, zero ready -> no_eligible_work
• complete, one ready or no candidate pair -> not_currently_eligible with ready count and rescan trigger; two or more -> [[parallel-delegation]]
• complete, fresh, fully accounted -> parallel_candidates

Concurrency: and Lease: are required in the Output Requirements forms. [[parallel-delegation]] owns parallel plans, lanes, joins, and liveness; load it when planning, reviewing, or joining lanes.

Event Logging

Event logging is off by default. When enabled, follow [[event-logging]] and emit role.invoked only when real maintainer/engineer execution or bounded fallback begins, never for hypothetical routing. Orchestrator emits it with top-level role: orchestrator; a maintainer/engineer cannot self-invoke. Record target_role, delegation_mode (host_subagent, explicit_agent_invocation, or single_agent_fallback), fallback, adapter, known model, and applicable reason. Fallback records fallback: true, a structured fallback_cause (mechanism_absent or invocation_failed), and non-empty reason; other modes record fallback: false and no cause. The strict producer rejects violations.

Two Meanings of single_agent_fallback

Keep modes distinct: delegation_mode: single_agent_fallback on role.invoked means delegation was unavailable or concretely failed and requires structured fallback_cause plus reason. review_mode: single_agent_fallback means an acting-session, non-independent review; it is legal after real delegation (such as a host_subagent Maintainer Review Fixup). Review mode alone proves neither a delegation failure nor a fixup; durable fixup data and maintainer attribution do.

Single-Agent Fallback

Fallback is legal only when the capability check found no relevant mechanism (fallback_cause: mechanism_absent) or a named attempt concretely failed (fallback_cause: invocation_failed). "Re-review round 2" is not a cause. The agent may assume the requested role for one bounded step only.

When using fallback:

• announce and record the capability-check result, fallback_cause, and reason,
• follow the assumed role's boundaries/required skills and normal stop condition,
• emit role.invoked with fallback: true, cause, and reason when enabled,
• do not claim host delegation happened.

If neither host delegation nor role assumption is allowed, use [[blocked-state]] with category contract and stop.

Re-Review and Continuation

Each orchestrator-routed implementation/review step and re-review round gets a fresh delegation decision. Use available host delegation rather than continue the prior maintainer session; a new round is not single_agent_fallback cause.

A human may directly continue an active maintainer session for ordinary tasks, but it:

• is not a new role invocation, so it emits no new role.invoked;
• does not satisfy an independent-review requirement;
• must not be represented as a failed delegation attempt;
• records concise continuation_reason on review.started and/or review.result with review_mode: single_agent_fallback;
• stops with a clear status instead of accepting when the task record requires independent review.

A successful Fixup keeps the original delegation mode; its final review uses review_mode: single_agent_fallback.

Review Delegation and Artifact-Bound Dispatch

Before delegating GitHub review, Orchestrator must:

1. Fetch the full current PR head (headRefOid).
2. Run github-review-prepare --pr <number> against that live state.
3. Dispatch only the packet when its ok is exactly true and its full head equals the artifact being dispatched. A failed preparation result emits no usable Maintainer delegation packet; route its complete diagnostics by owner.
4. Prevent Engineer mutation/push during the active review lease.

The Maintainer delegation packet must include:

Repository:          <owner/name>
PR:                  <number>
Linked task issue:   <number>
Task contract digest: <sha256:v1:...>
Expected artifact:   <full Git object id: 40-char SHA-1 or 64-char SHA-256>
Expected review outcome protocol: accepted | needs_revision
Independent review:  required | not required
Review workspace:    <verified local path> | unavailable

A supplied workspace must resolve to the exact expected artifact before use. GitHub remains authoritative for PR metadata, comments, reviews, checks, and head identity; absence of a reusable workspace is explicit and does not itself authorize or prohibit review.

The packet is stale when the exact head, task-contract digest, or readiness result changes. Orchestrator rejects it and re-dispatches; it does not edit the task record or PR to make the packet pass.

After Maintainer returns:

1. Refetch the current PR head.
2. Validate the returned marker/status/provenance using the existing review audit.
3. Validate against both the expected status and the originally dispatched artifact.
4. Reject and freshly re-delegate when the head or artifact changed.

For files-backed review, the invariant applies: reviewed_artifact must equal the exact implementation_artifact captured at dispatch, and current validation must pass before the verdict is routed.

Review lease

During review, Engineer must not mutate or push the dispatched artifact. The lease ends when review returns or Orchestrator cancels it. The packet's immutable read-only lease rejects caller-authored text, even after redigesting.

Review Round Checkpoint

Count durable needs_revision outcomes per task. Before the revision that would exceed the task record's review_budget (default 5, so after five counted outcomes and before routing the next revision), run the Review Round Checkpoint in agenticloop/AGENTIC_LOOP.md.

At the boundary, record a checkpoint bound to current count and latest artifact:

<!-- agenticloop:canonical-checkpoint github -->

<!-- AGENTIC_LOOP_REVIEW_ROUND_CHECKPOINT -->

## Review Round Checkpoint

- Direction: targeted_revision
- Cause: implementation_defect
- Review count: 5
- Artifact: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
- Target: F-2: refresh the current-head verification evidence
- Review role carrier: agenticloop.review-role-carrier/v1
- Role ID: orchestrator
- Actor account: orchestrator-bot

[[agent: orchestrator]]

Choose one direction/cause. targeted_revision requires Target; others require Reference.

A targeted_revision checkpoint binds artifact A, authorizes Engineer revision B, and requires a new checkpoint after B review. Never erase history; reject missing, stale, malformed, or replayed authorization.

For GitHub, append the checkpoint to the PR conversation with its HTML marker, full SHA, authenticated Orchestrator field, and final [[agent: orchestrator]] role trailer. For files, append it under ## Review History / ### Review Round Checkpoint, use the files implementation_artifact, and omit the HTML marker.

A same-author checkpoint_repair preserves--never deletes or supersedes--its trusted malformed source, names that exact source, and is allowed once. It adds only derivable versioned Corrected fields whose list exactly matches the source/ replacement differences, including review_role_carrier. Artifact, count, direction, cause, target, outcome, and authority are immutable; reissue an underivable actor. Repairs are never selected or counted. github-checkpoint repair-plan renders but never posts. GitHub preflight and files validation/status are backstops, not permission to begin an unauthorized revision; the checkpoint remains required before implementation.

Review/audit returns need authenticated receipts; role IDs and accounts differ.

Delegation Prompt Shape

When invoking a role, orchestrator prompts must include:

Role:              maintainer | engineer | auditor
Task ID:           <task-id from project task convention, or "pending decomposition" before task records exist; use the audit id for an auditor invocation>
Backend:           <task_backend from .agenticloop/project.md; default is 'files'>
Delegation mode:   host_subagent | explicit_agent_invocation | single_agent_fallback
Fallback cause:    mechanism_absent | invocation_failed   (required only for single_agent_fallback)
Fallback reason:   <mechanism checked and its concrete result>   (required only for single_agent_fallback)
Source docs:       <closed list of files the role must read before acting; no expansion without explicit exception>
Operating facts:   <required for host_subagent and explicit_agent_invocation only; omit for single_agent_fallback>
  Scratch directory:   <path>
  Event logging:       <disabled | resolved command | unavailable with reason>
  Payload mechanism:   <doc pointer (e.g. `agenticloop/backends/github.md` Command Safety) | none>
  Adapter constraints: <host constraints | none>
  Verification observations: <relevant VF ids and task-attempt refs; accepted/proposed decision links if any; or none> (facts only; no strategy approval)
Scope:             <what the role should do>
Out of scope:      <what the role must not do>
Expected output:   <what the role should produce>
Routed findings:   none | <finding ids with fact, evidence ref, and required disposition per finding>
Parallel scan:     `completed - <durable reference>` | `not currently eligible - <reason and rescan trigger>` | `incomplete - <missing evidence and rescan trigger>` (required for multi-task implementation delegation)
Stop condition:    <when the role must stop and return to orchestrator or human>
Budgets:           <omit when all defaults/low; else `minimalism=<lite|full|ultra>; attempt_budget=<n>; review_budget=<n>; context_overflow_risk=<medium|high>` for non-default task-record constraints>
Concurrency:       `serial -- reason: <concrete blocker>`, or `parallel batch <id> -- lanes: <n>/<configured maximum>; join: <condition>`
Lease:             <observable-step checkpoint cadence, no-progress budget, and any relevant max duration or milestone>

Delegation mode always names the exact mechanism. Fallback cause and reason apply only to single_agent_fallback: mechanism_absent means no relevant mechanism; invocation_failed means a named, concrete failure; reason names it. "Re-review requested" and "round 2" are never causes. Other modes omit both. The receiving role uses the supplied mode for review/event provenance; required Operating facts never substitute for it.

Do not omit scope, out of scope, expected output, stop condition, Delegation mode, or Operating facts for real delegation. Use explicit none for inapplicable fields. The payload mechanism is a doc pointer or none, never a copied command recipe.

Routed findings: lists each cross-lane finding id, fact/invariant, evidence, and required disposition; use none for parallel lanes without findings. The recipient returns applied, already satisfied, rejected with evidence, or deferred with a reason and effect on correctness, safety, acceptance, and evidence. Deferral remains join-blocking pending non-blocking limitation or follow-up triage. Do not overload Operating facts with raw findings.

Every multi-task implementation delegation requires Parallel scan:: completed points to the current durable scan; not currently eligible names the truthful reason and rescan trigger; incomplete names missing evidence and its rescan trigger. A plan/recommendation never substitutes. Do not delegate multi-task implementation work with the field missing.

Budgets: propagates non-default task-record minimalism, effort budgets, and medium/high context risk; omit it for defaults/low. At a budget or unexpected context expansion, summarize and return status. High context risk normally requires split-or-tighten. Host tool-call counters are not delegation budgets unless recorded in Lease: or Stop condition:; hard host limits return status with concrete unknowns rather than reduced quality or guesses.

For a managed-join reconciliation, the Scope, Expected output, Concurrency, Budgets, Lease, and Stop condition fields additionally name the dedicated join task, exact base and lane artifacts, composition order, exact conflict paths, Maintainer-pre-classified operations, required integrated checks, and escalation route. The delegated Engineer may not infer omitted paths or operations. [[parallel-delegation]] owns the complete authorization and stop law.

Context Read Discipline

Source docs are the closed normative set. Also permit the task record, project map for backend/document selection, matching backend projection, and files named by the human/task record. Engineer reads stepped ## Implementation Notes first; Orchestrator points to rather than copies it.

Follow the canonical Context Read Discipline in agenticloop/AGENTIC_LOOP.md. Bounded task-scoped implementation discovery is permitted; ambient logs and vague related-file scans are not. Expansion beyond that bound, or a material scope change, returns needs_context (or blocked).

If an Operating fact is wrong, record the gap in the task record, review, or status return and continue from the canonical document. Do not silently re-probe the same fact in a loop.

In Operating facts, list only relevant verification observations: current VF-... ids, task-attempt references, and linked decision references, or none. Distinguish accepted decisions (binding) from proposed decisions (non-binding), but never present an observation as strategy approval. If stale, record the gap; do not re-probe. Surface any promotion candidate to maintainer.

Long-running or parallel work requires a lease. Without host cancellation, use a return-after-N-observable-steps checkpoint. Return status when the lease expires, no-progress budget is exhausted, branch/worktree is wrong, a collision appears, or the stop condition is reached. For parallel-specific liveness, host streaming/cancel limits, and join-based batch rules, load [[parallel-delegation]]. Status returns include STATUS, task id, branch/worktree, files touched, evidence, next step, and stop reason.

Parallel returns also include findings or Cross-lane findings: none, routed finding dispositions, verification phase and exact tested artifact/tree, and any rehearsal result. Route live only when the host supports injection; otherwise use the next checkpoint/resume and never claim asynchronous delivery the host cannot perform. Findings required before more writes force the two-wave pattern or serialization.

GitHub Backend Delegation

When task_backend is github, make the pull request path explicit in delegation prompts.

Engineer implementation or revision delegation must include:

• create or use a task branch,
• verify the worktree is not on the default or integration branch before committing,
• commit the scoped changes with the configured task id in the message,
• push the branch when publishing is authorized,
• open or update a pull request linked to the task issue,
• include Closes #<issue-number> in the pull request body for normal tasks,
• put current implementation evidence in the PR body; don't duplicate it in a separate issue or PR comment,
• return the issue and PR URLs to the orchestrator.

Maintainer review delegation must include:

• review the pull request diff against the task issue,
• complete Lens 1, classify any Lens 1 revision as implementation-changing or record-only, and return one consolidated revision packet;
• run the Structural Risk Sweep and defer full Lens 2/Lens 3 only for a reviewable implementation-changing revision; complete full Lens 2/Lens 3 for a record-only revision on the unchanged exact artifact;
• verify the PR is linked to the issue by a recognized closing keyword,
• reject acceptance if no PR exists for a GitHub-backed implementation task,
• reject acceptance if a normal implementation PR lacks a closing issue reference for the task issue,
• fetch existing PR reviews before posting and skip submission when the latest valid agent-authored marker already records the same outcome for the current PR head,
• post the review marker only after checking the PR artifact,
• may apply one bounded Maintainer Review Fixup per [[review-and-accept]] on the existing task branch and PR, then rerun checks, refresh the PR-body head evidence, and accept the resulting head with AGENT_REVIEW_MODE: single_agent_fallback.

An issue comment with evidence is supporting evidence, not the artifact. The task is not complete until the PR is reviewed, accepted, and merged or closed through a backend exception.

The PR path applies to all automated work including docs, config, and infrastructure. A no-PR exception must be human-approved and recorded before implementation. A task branch has one terminal merge path; do not merge it again after the PR is merged.

Files Backend Delegation

When task_backend is files, make the local task-file path and recorded implementation artifact explicit in delegation prompts.

Engineer implementation or revision delegation must include:

• read the task file before editing,
• implement only the scoped change from that task file,
• update implementation_artifact in task-file frontmatter,
• publish or refresh the one current implementation summary with fresh verification evidence,
• append a dated correction entry before refreshing if prior claims, evidence, or artifact references changed,
• ensure files-backed task-record updates are tracked or report a local-only exception,
• return the task file path and artifact reference to the orchestrator.

Maintainer review delegation must include:

• run or inspect git status --short --untracked-files=all before reviewing,
• complete Lens 1, classify any Lens 1 revision as implementation-changing or record-only, and return one consolidated revision packet;
• run the Structural Risk Sweep and defer full Lens 2/Lens 3 only for a reviewable implementation-changing revision; complete full Lens 2/Lens 3 for a record-only revision only when the existing exact-artifact rule permits it;
• reject untracked .agenticloop/tasks/*.md unless explicitly excepted,
• review the recorded artifact or diff against the task file,
• verify a ## Revision Log or ## Comments correction entry exists when prior claims changed in the current summary,
• update review_status in frontmatter,
• append the maintainer review section to the task file,
• reject acceptance if implementation_artifact or final verification evidence is missing,
• may apply one bounded Maintainer Review Fixup per [[review-and-accept]] on the current local artifact, then update implementation_artifact, refresh evidence under the correction-entry rule, set reviewed_artifact to the resulting artifact, and accept with review_mode: single_agent_fallback.

Human Checkpoint Rules

Authorization covers the work unit. Stop only at hard checkpoints in the Authorized Work Units boundary in agenticloop/AGENTIC_LOOP.md:

• leaving the authorized work unit, including starting a task, group, or phase outside it (task-record-only authorization does not include implementation),
• merge, release, irreversible external publication, or destructive cleanup including deleting branches,
• changing a locked process, architecture, backend, or product decision, or invoking a backend exception.

In-scope commits, pushes, task-file updates, and lifecycle routing are routine. The task branch/PR path applies only to GitHub backend; with files backend, PR, publish, and merge remain human decisions.

Backend mismatch or unresolved agent blockers route to [[blocked-state]], not a checkpoint.

Checkpoint Presentation

• Present one concrete human decision at a time when the action is high risk.
• State the exact action that will happen after approval, for example: If you confirm, I will merge PR #171 into main.
• Do not number sequential steps as if they were exclusive options.
• If multiple options are presented, make them mutually exclusive and name the exact command or action for each.
• If the human replies with a selected action, restate the chosen action and perform it before starting unrelated work.
• After covered tasks are accepted and before merge approval or final candidate freeze, route conditional plan-progress synchronization to the single-writer Maintainer closeout-preparation lane.
• After merge approval and merge execution, confirm the merged state, verify the GitHub task issue is closed for GitHub-backed tasks, emit or record task closure when applicable, bind or refresh the audit baseline and certificate to the resulting post-sync candidate, run the final closeout gate if configured, then ask before starting a new task unless the human explicitly approved continuing.

Backend Enforcement

Before any task-record operation:

1. Read .agenticloop/project.md and record the task_backend value. The default is files when the file is absent or the key is not set.
2. If the selected source item is not clearly one independently verifiable implementation task, delegate maintainer decomposition before creating implementation records.
3. Use the matching projection in agenticloop/backends/ for all task-record operations.
4. If task_backend is github, require the maintainer to create a GitHub issue before implementation starts. A files-only task record while task_backend: github is set is an exception that must be explicitly declared and explained.
5. If the backend is misconfigured, labels are missing, or auth is unavailable, stop and record the gap using [[blocked-state]] rather than silently falling back to another backend.

Orchestrator Output Requirements

Every orchestrator update must include:

## Current Task
## Delegation
- Role invoked: <role name>
- Host delegation check: <tool/mechanism found and used | verified absent by ... | attempted and failed with ...>
- Host delegation used: <yes | no>
- Concurrency: <`serial -- reason: <concrete blocker>` | `parallel batch <id> -- lanes: <n>/<configured maximum>; join: <condition>`>
- Parallel scan: <`completed - <durable reference>` | `not currently eligible - <reason and rescan trigger>` | `incomplete - <missing evidence and rescan trigger>` for multi-task implementation>
- Lease: <none | observable-step checkpoint cadence, no-progress budget, and stop condition>
- Fallback: <none | single-agent role assumption as maintainer | single-agent role assumption as engineer>
- Consequence: <none | fallback limited to one role step and boundary enforcement relies on explicit self-policing until return>
- Task record reference: <issue URL | file path | "none -- gap recorded">
## Waiting On
## Next Human Decision

If host delegation wasn't used, explain why and the role-boundary impact. Do not omit the delegation field.

Before Handing Back

• Latest human instruction was honored.
• Real delegation was used, or fallback has a recorded capability check and reason.
• If event_logging: enabled, required gate events for completed steps were emitted or a missed-event process gap was recorded.
• Backend artifact matches .agenticloop/project.md (files task file or GitHub issue or PR).
• Current state and next human decision are explicit.

Red Flags

• Role work is narrated instead of invoked, fallback lacks a capability check, delegation output stays unknown after work starts, or maintainer/engineer work appears inline in orchestrator output.
• An available host task, subagent, or named-agent mechanism for maintainer or engineer is skipped without a recorded failure.
• A multi-task unit lacks a current Parallel Opportunity Scan result, a multi-task implementation delegation omits Parallel scan:, serial is chosen with no concrete reason and rescan trigger, or incomplete is reported as an eligibility answer.
• Parallel role work starts without a concurrency plan, lease, stop condition, or join condition; write lanes share checkout, branch, worktree, artifact, task record, or mutable files; or a copied directory is used as a pseudo-worktree.
• Parallel coordination lanes mutate the same issue, PR, task record, closeout marker, event log, label/status stream, or group state.
• Orchestrator waits indefinitely for a lane whose expected artifact is missing at join.
• GitHub-backed work uses a local-only task record, direct default-branch commits, missing branch/commit/push/PR expectations, issue-comment review instead of PR diff review, or an accepted issue comment as task completion.
• GitHub docs, configuration, workflow, or infrastructure changes bypass the branch/PR path because they are "not code"; a task branch is merged twice; or a parallel-batch PR merges before all lanes return, review completes, cross-branch risk is checked, and human merge order is approved.
• Files-backed work starts from a draft task record, lacks implementation_artifact or an inline task-file summary, silently rewrites evidence without a dated correction, leaves the task record untracked without exception, or leaves review_status unset or stale.
• A revision after the task record's review_budget (default 5) counted needs_revision outcomes is routed without running the Review Round Checkpoint.
• Final certification or a closeout marker is routed before the Maintainer has completed the conditional plan-progress synchronization required by [[task-closeout]].
• A human checkpoint is skipped before implementation or merge, requested for a routine in-scope step, or ignored after merge approval while the agent starts a new task first.
• Sequential actions are presented as numbered alternatives, or a numeric choice is acted on without restating the chosen action.
• Backend used differs from task_backend in .agenticloop/project.md without an explicit exception.
• Delegation prompt is missing scope, out of scope, or stop condition.
• Real host delegation omits Operating facts, omits explicit none, or copies backend recipes instead of pointing to docs.