Role Delegation

---
name: role-delegation
description: Use when the orchestrator starts or resumes a task loop, routes first-run project-map confirmation, creates a task record handoff, hands off implementation, routes review, or runs closeout. Ensures real host delegation happens when available, or an explicit bounded single-agent role assumption is used when it is not, while files-backed and GitHub-backed delegation rules plus human checkpoints are followed.
metadata:
  area: orchestration
  side_effects: writes-tmp
  credentials: none
  runs_scripts: none
---

# Role delegation

Orchestrator coordinates but does not implement, plan task records, or perform
final review. Delegation exists only when the designated role executes.

## Advance Authorization

Delegation is state-changing under the Advance Authorization Boundary in
`agenticloop/AGENTIC_LOOP.md`; require named explicit instruction or standing
authorization. Work-unit authorization covers its routine implementation,
review, and revision delegations without per-transition approval. A status,
inventory, explanation, diagnostic, or direct question does not authorize its
revealed next step; answer, report that step, and stop.

## When to Use

Apply when Orchestrator starts/resumes a task loop; routes unconfirmed first-run
setup through [[setup-agenticloop]]; delegates task-record creation/refinement to
Maintainer or implementation/revision to Engineer; routes artifacts for
Maintainer review and revisions back to Engineer; delegates accepted, integrated
work-unit certification to Auditor; or runs closeout/human checkpoints.

## 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 |

A gate failure names an owner; it does not transfer that owner's edit authority
to Orchestrator. Re-delegate to that owner, escalate when human authority is
named, or stop at the checkpoint. Never repair Engineer PRs/commits or
Maintainer task records while legal delegation exists.

Use immutable `roleId` for dispatch, return, attribution, filenames, config, and
authority; registry labels are display-only. Dispatch binds the host's closed
capability declaration. A non-native restriction is `advisory`/`unavailable`,
names its detection boundary, limitation, and recovery, and is never
`enforced` unless every shipped write route is constrained. OpenCode `bash`,
Copilot `execute`, and Codex instructions are advisory. Bind one version 3
report per degraded action, emit `capability.enforcement.degraded`, and verify
it against authenticated actor/evidence on 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 all dispatch facts. Only its fixed operator-trust
registry authorizes activation.

Files-backend role start uses target-relative artifacts:

```text
npx agenticloop task role-start <id> --packet <packet-path> --json
npx agenticloop task prepare-product-commit <id> --packet <packet-path> --subject <subject> --message-output .agenticloop/tmp/<id>-product-commit.txt --json
```

Role start derives the digest from the packet and atomically records status,
consumption, disposition, and `.agenticloop/tmp/<id>-checks.json`. This aggregate
is uncommitted scratch; command execution artifacts under
`.agenticloop/checks/<id>/` are durable. Changed or partial retries fail closed;
an exact retry is `already_current`. Missing, stale, consumed, already-current, or noted starts fail closed without
a fresh packet. Never run `task prepare-dispatch --packet`
afterward: it is pre-start diagnostics, while `role-start` performs authoritative
final revalidation. An unkeyed dispatch digest provides integrity only; it does not authenticate
validator identity.

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

```text
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
```

Files lifecycle:

```text
npx agenticloop task prepare-dispatch <id> --host <host> --role engineer --output <packet-path> --json
npx agenticloop task role-start <id> --packet <packet-path> --json
npx agenticloop task evidence <id> --class implementation_artifact_evidence --expect-digest <digest> --product-head <commit> --json
npx agenticloop task evidence <id> --class implementation_summary_evidence --expect-digest <refetched-digest> --summary <text> --check-evidence <text> --json
npx agenticloop task evidence <id> --class implementation_outcome_evidence --expect-digest <refetched-digest> --outcome implementation_ready_for_review --json
npx agenticloop task check-evidence-update <id> --packet <packet-path> --check <check-id> --outcome passed --evidence <text> --json
npx agenticloop task prepare-return <id> --packet <packet-path> --check-evidence .agenticloop/tmp/<id>-checks.json --outcome implementation_ready_for_review --output <return-path> --json
```

Engineer ends at `prepare-return`; Maintainer starts with:

```text
npx agenticloop task verify-return <id> --packet <packet-path> --return <return-path> --from-current-repository --json
```

Follow the typed first-safe repair once. If the same stable refusal signature
recurs, or preflight and its first downstream command contradict each other on
unchanged facts, stop mutations. Preserve the live attempt when safe, do not
mint or consume another packet, and route one bounded validator/source
diagnosis. Precedent is a hypothesis, not authority.

For non-passing/manual checks, record the observed outcome and omit required
`--execution-output`. Retry an in-lease usage refusal only when `safeToRetry:
true` and `mutationOccurred: false`, using its corrected command. Before one
identical tooling retry, run `task record-tooling-failure`; two total observations
allow one retry and only bounded provenance persists. Authority, lifecycle,
binding, ambiguity, evidence, and partial-mutation failures stop immediately.
Public boundaries revalidate and reject caller-authored receipts. The raw return
binds the packet and non-authoritative outcome; Orchestrator never reconstructs
it. Standard mode permits revalidated `session_reported`; hardened mode requires
host provenance for every identity. Replay, self-attestation, and producer
mismatch fail closed.

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

Files retain the `in-progress` carrier. `task evidence` records artifact,
summary, and outcome against the current digest; receipts preserve
`taskContractDigest`, link `dispatchCarrierDigest` to `currentCarrierDigest`,
and return product/workflow heads and lineage. Then use `task review-prepare`.

`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 a fresh separate Auditor invocation each time; see
[[work-unit-audit]]. Auditors never implement, accept tasks, limitations, or
risks. Non-certification routes ordinary Maintainer/Engineer remediation, not
another audit.

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 the smallest useful independently verifiable task. Larger authorized
runs remain bounded, reversible slices, never 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 host task, subagent, role, agent, type, mode, and
`subagent_type` mechanisms. Use one if available; otherwise record verified
absence or the attempted mechanism and failure.

## 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, [[event-logging]] emits
`role.invoked` only when real maintainer/engineer execution or bounded fallback
begins, never for hypothetical routing or self-invocation. Orchestrator records
top-level `role: orchestrator`, `target_role`, `delegation_mode`
(`host_subagent`, `explicit_agent_invocation`, or `single_agent_fallback`),
`fallback`, `adapter`, known `model`, and applicable `reason`. Fallback requires
`fallback: true`, `fallback_cause: mechanism_absent | invocation_failed`, and a
non-empty reason; other modes require `fallback: false` and no cause. The strict
producer rejects violations.

## Two Meanings of single_agent_fallback

Keep modes distinct. `delegation_mode: single_agent_fallback` means delegation
was absent or failed and requires cause plus reason. `review_mode:
single_agent_fallback` means acting-session, non-independent review and may
follow real delegation (for example, a `host_subagent` Maintainer Review Fixup).
Review mode alone proves neither delegation failure nor 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 routed implementation/review step and re-review round gets a fresh
delegation decision. Prefer available host delegation over continuing the prior
Maintainer session; a new round is not a `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:

```text
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 -->
```text
<!-- 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:

```text
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, plus the task record, project map
needed for backend/document selection, matching backend projection, and files
named by the human or record. Engineer reads stepped `## Implementation Notes`
first; Orchestrator points to it instead of copying it. Follow the canonical Context Read Discipline in
`agenticloop/AGENTIC_LOOP.md`. Bounded task-scoped implementation discovery is
permitted, not ambient logs or vague related-file scans; expansion or material
scope change returns `needs_context` (or `blocked`).

If an Operating fact is wrong or stale, record the gap in the task record,
review, or status return; continue from canonical docs and do not repeatedly
probe it. List only relevant current `VF-...` ids, task-attempt and linked
decision references, or `none`; distinguish binding accepted decisions from
non-binding proposals, never make an observation strategy authority, and route
promotion candidates to Maintainer.

Long-running or parallel work requires a lease. Without host cancellation, use
a return-after-N-observable-steps checkpoint. Return status on expiry, exhausted
no-progress budget, wrong branch/worktree, collision, or stop condition, with
`STATUS`, task id, branch/worktree, files touched, evidence, next step, and stop
reason. [[parallel-delegation]] owns parallel liveness and join-based batches.

Select exactly one checkpoint cadence in the prompt: `return after every
record`, or `return after each batch of N records`. N is explicit; do not also
say "after every record" or "at most one consolidated return." Every tool-using
delegation also declares a small diagnostic budget for unexpected command or
host failures. Once exhausted, return `tooling_failure`, `needs_context`, or the
applicable blocked category with the failing command, observed output, attempted
repairs, and untouched remaining work. Tool transport completion is not command
success; inspect the child exit status or structured CLI disposition.

On a host without streaming and cancellation, do not delegate work whose bounded
return is expected to take an extended period. Prefer one-record returns for
high-context task materialization. These leases are cooperative return contracts,
not host-enforced kill switches.

### Coordinator-response reconciliation

If a child completed but the coordinator response failed, resume idempotently:

1. acknowledge any queued pause; it prevents further implementation or activation;
2. refetch durable task/backend artifacts and Git refs/commits before consulting session state;
3. match the returned artifact/commit to the outstanding coordinator-owned action;
4. use available host session metadata only as `session_reported` evidence, never authenticated host evidence;
5. persist only a compact checkpoint (task, child outcome/ref, outstanding action, pause state), never a raw transcript;
6. perform only the still-outstanding coordinator action. A second reconciliation over unchanged state is a no-op.

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:

```md
## 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.