--- 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 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 workflow-role registry. Every dispatch binds the selected host's closed role-capability declaration. Do not call prose enforcement: a non-native restriction is `advisory` or `unavailable` and must name the next authoritative detection boundary, limitation, and recovery route. `enforced` requires all shipped write-capable routes to be constrained. OpenCode retained `bash`, Copilot retained `execute`, and Codex instructions are therefore advisory. Dispatch binds one version 3 report per degraded action, emits `capability.enforcement.degraded`, and return import checks it against authenticated actor/evidence. ### Exact implementation dispatch Before one Engineer implementation delegation, the orchestrator emits one read-only `agenticloop.role-preparation` packet from the current task. It binds the parser-controlled activation identity, trusted task and contract digests, current mechanically reevaluated readiness/base/dependency evidence, committed Maintainer-attributed decomposition provenance, scope, checks, role and invocation IDs, canonical references, selected host and exact host-role capability declaration, branch/worktree, attribution, liveness, and cancellation boundary. Its activation capture is verified by a target-scoped Ed25519 public key from the fixed host-owned operator registry; repository-local or caller-selected external adapter/key data cannot authorize it. The packet references canonical role, skill, and backend documents; it does not copy their procedures or select a solution. The Engineer invokes the read-only packet verifier before its first mutation. The result is raw `agenticloop.role-return` JSON from that role, bound to the exact packet digest. A successful result uses canonical `disposition: proceed` with a separate non-authoritative implementation outcome, never a fake review receipt or completion claim. The orchestrator validates/reroutes invalid returns; it does not rewrite, summarize, or reconstruct them. Authenticated host producer provenance bound to the target repository, adapter/key identity, invocation, packet, return, liveness, and exact repository evidence is mandatory at the handoff edge. The verifier selects the adapter/key from the verified packet, not the receipt; replayed, unsigned, or repository-self-attested receipts fail closed. The receipt's host-observed producer must equal both the assigned `roleId` and the raw return's producer. Cooperative commit or comment trailers cannot repair a mismatch. `task verify-return` / `role_return_receive` also gates blocked resume and recovery before state change. Normal resume uses the authenticated producer; owner transfer needs an exact version 2 redelegation signed by a pinned Orchestrator/human authority, and destructive/scope/host-state recovery needs an exact version 2 disposition signed by the pinned human authority. Digests, labels, trailers, caller-selected keys, and self-minted records cannot substitute; human work stays human-attributed. Work-unit certification is auditor-owned and is a fresh, separate invocation every time; see [[work-unit-audit]]. The auditor never implements, never accepts a task, and never accepts a limitation or risk. A non-certifying report routes back through the ordinary maintainer/engineer remediation flow, not back to the auditor. Scoped implementation and ordinary revision remain engineer-owned. The single exception is a bounded Maintainer Review Fixup: during an active eligible review the maintainer already executing the review may apply one fully understood correction under [[review-and-accept]] and accept the result. A successful fixup requires no engineer invocation and is not a `needs_revision` round; an unsuccessful, ineligible, expanded, or independent-review finding returns to the normal engineer handoff. No extra single-agent role-assumption ceremony is needed beyond the maintainer's existing execution – the delegation-mode of the role invocation and the final `review_mode` are distinct, so a maintainer invoked via `host_subagent` still records `single_agent_fallback` when it accepts its own fixup. ## Slice sizing Default: one independently verifiable task, the smallest useful slice. For a larger authorized bounded run, prefer the largest safe slice that stays bounded, reversible, and independently verifiable. Broad authorization isn't permission to create one oversized record; task sets still decompose. ## Host Delegation Mechanism Real delegation starts a separate role, task, named-agent, or subagent execution for maintainer, engineer, or auditor. Describing that role's actions in prose 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 and is not an independent audit. If no real delegation mechanism is available, record the blocked condition instead of auditing inline. ## Delegation Capability Check Before single-agent fallback, explicitly check for a host task, subagent, role, agent, type, mode, or `subagent_type` mechanism. If one exists, use it. Otherwise record how absence was verified, or the attempted mechanism and failure reason, in the delegation output. ## Concurrency Policy Delegation is serial by default. Mutation governs concurrency safety, and knowledge coupling governs it alongside mutation: parallel write execution requires mutation independence plus knowledge independence. Every authorized multi-task unit carries a current Parallel Opportunity Scan after decomposition: with fewer than two ready tasks it records not-currently-eligible status and a rescan trigger; with two or more it loads [[parallel-delegation]] before routing implementation work. Planning, reviewing, and joining parallel lanes also load that skill. Role-delegation keeps the delegation prompt contract: the `Concurrency:` line is required for delegated work and must be either `serial -- reason: ` or `parallel batch -- lanes: /; join: `. The `Lease:` line carries observable-step checkpoint cadence, no-progress budget, and any relevant duration or milestone. Parallel plans, backend-specific lane rules, join behavior, and parallel liveness details live in [[parallel-delegation]]. ## Event Logging Event logging is off by default. When enabled, follow [[event-logging]] and emit `role.invoked` only after real maintainer/engineer execution or bounded fallback begins, never for hypothetical routing. The orchestrator is the emitter: top-level `role` is `orchestrator`, and a maintainer or engineer must not emit a self-invocation event targeting itself. Record `target_role`, `delegation_mode` (`host_subagent`, `explicit_agent_invocation`, or `single_agent_fallback`), a boolean `fallback`, `adapter`, known `model`, and `reason` as applicable. For `single_agent_fallback`, also record `fallback: true`, a structured `fallback_cause` (`mechanism_absent` or `invocation_failed`), and a non-empty `reason`. Non-fallback modes record `fallback: false` and no fallback cause. The strict producer path rejects a new `role.invoked` that violates these rules. ## Two Meanings of single_agent_fallback Keep the delegation mode and the review mode distinct: - `delegation_mode: single_agent_fallback` on `role.invoked` means real role delegation was unavailable or a concrete attempt failed. It requires a structured `fallback_cause` and reason. - `review_mode: single_agent_fallback` on the review means the review happened in the acting session and is not independent. It is legal for ordinary tasks even when the role was delegated for real (for example a self-accepted Maintainer Review Fixup by a `host_subagent` maintainer). A `review_mode: single_agent_fallback` does not by itself prove a delegation failure or a fixup; only the durable fixup subsection and maintainer attribution identify a fixup. ## Single-Agent Fallback Single-agent fallback is legal only when the delegation capability check found no relevant mechanism (`fallback_cause: mechanism_absent`), or a named mechanism was attempted and concretely failed (`fallback_cause: invocation_failed`). A request such as "re-review round 2" is not a fallback cause. If allowed, the current agent may assume the requested role for one bounded role step only. When using fallback: - announce it in output and record the capability-check result, `fallback_cause`, and reason, - follow the assumed role's boundaries and required skills, - stop at the role's normal stop condition, bounded to that one role step, - emit `role.invoked` with `fallback: true`, the `fallback_cause`, and the reason when event logging is enabled, - do not claim host delegation happened. If neither host delegation nor single-agent role assumption is allowed, use [[blocked-state]] with category `contract` and stop. ## Re-Review and Continuation Every orchestrator-routed implementation or review role step receives a fresh delegation decision, and every orchestrator-routed re-review round passes through delegation routing again. When host delegation is available, the orchestrator uses it for the new round instead of continuing the prior maintainer session for convenience. A new review round is not a reason to record `delegation_mode: single_agent_fallback`. A human may directly continue an already-active maintainer session for ordinary tasks, but that continuation: - 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 a concise `continuation_reason` on `review.started` and/or `review.result` and uses `review_mode: single_agent_fallback`; - stops with a clear status instead of accepting when the task record requires independent review. A successful Maintainer Review Fixup does not alter the original role invocation's delegation mode; the final fixup review still 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 ` 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: PR: Linked task issue: Task contract digest: Expected artifact: Expected review outcome protocol: accepted | needs_revision Independent review: required | not required Review workspace: | 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: ```text ## 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 and cause. `targeted_revision` requires `Target`; the others require `Reference`. A `targeted_revision` checkpoint binds artifact A and authorizes one Engineer revision B. After B's review, require a new checkpoint before another revision. Never erase review history. Reject missing, stale, malformed, or replayed checkpoint authorization. Do not delete or supersede a trusted malformed checkpoint. The same-author `checkpoint_repair` carrier names its source, fills only derivable versioned `Corrected fields`, cannot change artifact, count, direction, cause, target, outcome, or authority, is never selected or counted, and needs reissuance for underivable actor identity. Declared fields must match source/replacement differences, including a restored `review_role_carrier`. `github-checkpoint repair-plan` renders but never posts it. For GitHub, append the checkpoint to the PR conversation with the marker, full SHA, authenticated Orchestrator field, and final role trailer. For files-backed, append the same semantic fields under `## Review History` / `### Review Round Checkpoint`; it uses the files `implementation_artifact` form and no HTML marker. Use `github-preflight` as the GitHub fail-closed backstop before over-budget work returns to review. The files task validation/status provides the equivalent backstop. Orchestrator's delegation contract still requires the checkpoint before implementation begins; the later preflight is not permission to start an unauthorized revision. 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: Backend: Delegation mode: host_subagent | explicit_agent_invocation | single_agent_fallback Fallback cause: mechanism_absent | invocation_failed (required only for single_agent_fallback) Fallback reason: (required only for single_agent_fallback) Source docs: Operating facts: Scratch directory: Event logging: Payload mechanism: Adapter constraints: Verification observations: (facts only; no strategy approval) Scope: Out of scope: Expected output: Routed findings: none | Parallel scan: `completed - ` | `not currently eligible - ` (required for multi-task implementation delegation) Stop condition: Budgets: ; attempt_budget=; review_budget=; context_overflow_risk=` for non-default task-record constraints> Concurrency: `serial -- reason: `, or `parallel batch -- lanes: /; join: ` Lease: ``` `Delegation mode` is always required and names the exact mechanism used. `Fallback cause` and `Fallback reason` are required only for `single_agent_fallback`: the cause is `mechanism_absent` (the capability check found no relevant mechanism) or `invocation_failed` (a named mechanism was attempted and concretely failed), and the reason states the mechanism checked and its concrete result. "Re-review requested" or "round 2" is never a fallback cause. Non-fallback modes omit both fallback fields. The receiving role uses the supplied `Delegation mode` when it records review provenance and event data; `Operating facts` remains required for real delegation but never substitutes for the explicit mode. 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. For every multi-task implementation delegation, `Parallel scan:` is required. The `completed` form points to the current durable scan; the `not currently eligible` form names the truthful reason and rescan trigger. A source plan or maintainer recommendation does not substitute for this line. 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. The role may also read the task record, project map for backend/document selection, matching backend projection, and files explicitly named by the human or task record. Engineer reads stepped `## Implementation Notes` first; the orchestrator points to, rather than copies, that plan. 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 #` 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: - Host delegation check: - Host delegation used: - Concurrency: <`serial -- reason: ` | `parallel batch -- lanes: /; join: `> - Parallel scan: <`completed - ` | `not currently eligible - ` for multi-task implementation> - Lease: - Fallback: - Consequence: - Task record reference: ## 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:`, or serial is chosen with no concrete reason and rescan trigger. - 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.