@codetreker/daynight 0.24.3 → 0.25.0

package/README.md

@@ -22,6 +22,7 @@ GitHub CLI and Copilot CLI on `PATH`.
 - [Task deletion](#task-deletion)
 - [Task attachments](#task-attachments)
 - [Worker configuration and startup](#worker-configuration-and-startup)
+- [Worker workspace upgrade](#worker-workspace-upgrade)
 - [Worker manual management](#worker-manual-management)
 - [Review configuration and startup](#review-configuration-and-startup)
 - [Review status listing](#review-status-listing)
@@ -101,6 +102,7 @@ daynight worker                     # Show worker help
 daynight worker setup               # Check prerequisites and choose an agent and Projects
 daynight worker run                 # Run until interrupted
 daynight worker attach              # Open the worker Herdr session
+daynight worker migrate-workspaces [--rollback]
 daynight worker repo list [--json]
 daynight worker repo add [--project <project-id>]
 daynight worker repo remove [--project <project-id>]
@@ -152,13 +154,24 @@ records module ownership and the preserved data layout.
 
 The public `using-daynight` skill provides task creation, handoff review and
 execution of one specified task. Ordinary execution reads `run-task.md`.
-Worker-started agents use `execute-task-in-managed` only when their startup
+Worker-started agents use `autopilot-managed-task` only when their startup
 prompt explicitly names the `worker-managed` environment, the `using-daynight`
 skill and that mode, together with their assignment. `SKILL.md` routes to the
 selected instructions; ordinary execution does not load managed task rules.
 Shared task inputs, delivery and acceptance rules retain one owner in the bundle.
 The [foreground worker](#worker-configuration-and-startup) constructs that
 explicit assignment and loads the installed managed entry before launch.
+Managed execution follows one assignment through implementation, validation,
+focused PR delivery, CI and review repair, and merge. A valid worker-managed
+assignment already has sufficient authorization for that delivery and PR merge;
+merge as soon as the checks and review conditions are satisfied without asking
+for additional confirmation. Explicit user restrictions, pauses and revocation
+remain binding. Pending CI or
+review stays in execution; demonstrated external blockers return to the worker
+with a checkpoint. Merge requires current-head approval and required checks,
+and platform confirmation; mainline CI after merge is awaited only on explicit
+request. The mode preserves the assigned scope, the original claim and the
+controller's ownership of worktree, branch and workspace cleanup.
 
 Install the skill through an interactive terminal:
 
@@ -830,14 +843,47 @@ worker state or acquire tasks. Unconfirmed probe-process cleanup is a failure,
 including during cancellation.
 
 Install Git, Herdr 0.9.5 or newer with protocol 22 capabilities, and the selected
-native agent on PATH. Configure native/provider credentials and the current
-official Herdr SessionStart integration explicitly. Codex must be 0.135 or newer
-and support hooks, `--no-daemon` and the fixed full-access/hook-trust flags;
-Unix hooks need bash and python3, while Windows hooks need
-PowerShell. Inspect official integration with `herdr integration status`. Missing
-capabilities and native launch failures remain visible;
-the worker does not install or change global native configuration. Git transport
-and task tools, such as authenticated GitHub CLI for PR delivery, must be ready.
+native agent on PATH and configure native/provider credentials. Before each
+fresh or resumed native launch, runtime preflight reads the selected agent's
+official integration through the private daemon. A `current` integration causes
+no installation write. Only `not_installed` or `outdated` triggers the official
+`integration.install` RPC with `{target: agent}`; preflight then reads the state
+again and requires `current`. Missing, duplicate, malformed or unknown integration
+metadata fails without repair. Each launch makes its own integration requests to
+the private daemon, whose official handler performs the installation.
+
+The official installer can update native configuration and hook assets in the
+provider home used by the private daemon. Codex repair requires a live private
+daemon started by the current worker, so its native environment matches the
+configuration being checked. An adopted daemon's environment cannot be verified
+through the API; stop and restart the worker normally before attempting Codex
+repair in that case. Repair also requires the audited Herdr 0.9.5 installer and
+checks its projected TOML edit without writing files.
+The original and projected configurations must parse and differ only by enabling
+`features.hooks` and removing the deprecated integration key
+`features.codex_hooks`. Configurations containing date/time values or parser
+constructs whose exact semantics cannot be compared are refused. Inline, dotted
+or quoted feature layouts and multiline strings that this installer would damage
+fail before `integration.install`;
+reformat the affected configuration or use an integration installed safely by
+its owner before retrying. Unknown installer versions also fail before repair;
+already-current integrations keep their ordinary verification path. The check
+compares configuration values; it does not preserve comments or lock out external
+configuration edits between inspection and installation.
+
+Preflight still verifies effective hooks and the SessionStart command in the
+actual task directory before launch; installation success alone is insufficient. Installation, verification and
+cancellation failures remain visible and prevent that native launch. An uncertain
+installation outcome is not automatically replayed; a later attempt first reads
+current state. Setup retains its read-only inspection and repair instructions.
+Inspect shell-side integration with `herdr integration status`; its environment
+can differ from the running private daemon's.
+
+Codex must be 0.135 or newer and support hooks, `--no-daemon` and the fixed
+full-access/hook-trust flags. Unix hooks need bash and python3, while Windows
+hooks need PowerShell. Native capability and launch failures remain visible.
+Git transport and task tools, such as authenticated GitHub CLI for PR delivery,
+must be ready.
 
 Manage individual Project registrations with:
 
@@ -956,6 +1002,31 @@ private Herdr. Each task uses branch `daynight/<task-id>` and directory
 `<repository>/.worktrees/daynight/<task-id>`. Valid claims retain their dirty
 worktree; task branches and commits remain after terminal cleanup.
 
+A workspace label starts with the task title and ends with its full stable owner:
+
+```text
+Fix worker startup | daynight:{"projectId":"…","taskId":"…","claimId":"…","worktreeId":"…"}
+```
+
+The title is display text. Ownership checks and the managed agent name use only
+those four canonical UUIDs; renaming a task does not change its claim, worktree,
+agent name or native conversation. Herdr and Git ownership markers share that
+four-field identity. The configured service address remains available to API
+requests and the managed assignment, outside resource identity. One retained
+worker state directory belongs to one configured service.
+
+The next successful complete claim inventory supplies the latest task title.
+Changed names are synchronized through Herdr in the task's existing serialized
+operation, including when execution recovery has reached its limit. An unchanged
+name sends no rename request. A naming RPC failure reports `workspace-name-error`
+without spending execution recovery budget or restarting a healthy agent; an
+unknown result is observed again before a later decision. Ownership, binding and
+cancellation failures retain their lifecycle semantics. Titles may contain the
+label delimiter because parsing uses the final owner suffix. Control characters,
+line separators and bidirectional display controls are escaped as visible text;
+Unicode titles and emoji remain readable. Full titles and owner IDs are retained,
+with Herdr responsible for fitting the label into its current terminal width.
+
 The local database has exactly these business fields:
 
 ```text
@@ -1009,7 +1080,7 @@ Native recovery uses current resources and the recorded session ID:
 |---|---|
 | Matching agent is alive | Reconnect and observe without resending the startup prompt. |
 | Agent needs starting, session_id is present | Resume that native session using the recorded agent type. |
-| Agent needs starting, session_id is NULL | Emit Warning, start a fresh native conversation, and save its ID in the same row. |
+| Agent needs starting, session_id is NULL | Emit `info`, start a fresh native conversation, and save its ID in the same row. |
 
 When a native process must restart, the worker stops/closes an existing
 inactive workspace and creates a new one with the current native environment
@@ -1085,10 +1156,10 @@ integration failures and launch errors stay visible. Use attach for business
 input. Reconnecting an already alive agent does not promise to resend an input
 lost across a process interruption.
 
-When the original claim is absent from a successful complete inventory, the
-worker asks its agent to release attributable temporary files, services and
-processes outside the worktree. It waits at most ten minutes for this cleanup
-attempt, stops the agent, closes its workspace, removes the matching worktree
+During normal reconciliation, when the original claim is absent from a
+successful complete inventory, the worker asks its agent to release attributable
+temporary files, services and processes outside the worktree. It waits at most
+ten minutes for this cleanup attempt, stops the agent, closes its workspace, removes the matching worktree
 and marks the local row done. Done, release and force withdrawal have the same terminal
 resource rule. Failed stop or deletion retains responsibility and the error.
 
@@ -1103,8 +1174,8 @@ close its workspace. Sequence counters and interactive readiness are not
 required. A pre-notification observation or the submission receipt itself
 cannot finish cleanup. Failed or unknown notification results retain their error
 and the current bounded wait, without automatic replay. Reaching the deadline
-still proceeds through actual stop confirmation. Idle in this exit phase does
-not complete the business task.
+still proceeds through actual stop confirmation. Idle in this terminal cleanup
+phase does not complete the business task.
 
 Cleanup timing and progress are in memory. Polls do not extend the current
 attempt's deadline; after a crash, the next successful reconciliation observes
@@ -1113,15 +1184,32 @@ may repeat. Separate tasks have independent bounded jobs, so one held RPC does
 not postpone another task's cleanup. A cleanup already selected in the current
 process can continue during later service-read failures.
 
-Ctrl+C stops acquisition and ordinary scheduling, then gives agents bounded
-outside-worktree cleanup, stops them and closes their workspaces. Valid claims,
-worktrees, session IDs and active/pending rows remain for the next run. The
-private instance stops last; exit failures remain visible.
+Ctrl+C stops acquisition and scheduling, cancels all running jobs including
+terminal cleanup, and joins them before directly stopping agents and closing
+their workspaces. Process exit sends no cleanup prompt and does not wait for a
+cleanup turn. It preserves claims, worktrees, native session IDs and all
+unfinished active/pending rows, including those whose ownership has ended. The
+next run uses normal inventory reconciliation to re-enter terminal cleanup for
+ended claims. External temporary resources may remain after direct interruption.
+Normal completion, release, withdrawal and manual-control cleanup retain their
+notification and removal sequence. Pending stop confirmations must settle before the private
+Herdr instance stops; stop errors remain visible, and uncertain stopping retains
+that instance and the affected resources. Before closing a verified orphan
+workspace with no local task row, cleanup and exit save its observed native
+agent and any live session ID in the existing pending claim index. Restart can
+then remove its retained worktree and unblock a later claim for the same task.
+An unknown original agent type retains the workspace with a visible error;
+current configuration does not establish that historical type. Unproven Git-only
+resources remain untouched.
 
 stderr and JSONL logs identify worker, platform, Project/task/claim, agent and
-known session ID. Startup prints the log location and attach guidance. Routine
-observations report the first connection and changes to a claim’s waiting or
-executing phase, terminal or native session. Unchanged polls stay quiet, including
+known session ID. After credential redaction, the terminal renderer shortens each
+full hyphenated GUID in context, messages and error chains to its first eight
+hexadecimal characters, preserving case. Other text stays unchanged. JSONL keeps
+complete IDs in fields, messages and errors for precise lookup. Startup prints
+the log location and attach guidance. Routine observations report the first
+connection and changes to a claim’s waiting or executing phase, terminal or native
+session. Unchanged polls stay quiet, including
 the first poll after a successful start. Claims are tracked independently.
 Resource-preservation warnings appear once while continuously observed and
 appear again if they clear and return. Actual starts, recoveries, cleanup, manual
@@ -1131,6 +1219,68 @@ recovery ledger. The
 [worker requirements](../../docs/spec/daynight-worker.md) and
 [design](../../docs/design/daynight-worker.md) own full behavior and validation.
 
+## Worker workspace upgrade
+
+Stop `daynight worker run` and confirm that its private Herdr and native agents
+have stopped before changing an existing workspace identity format. Normal
+execution accepts the current four-ID format and reports old labels or Git
+markers with a migration instruction. It does not interpret legacy ownership
+while running tasks.
+
+```bash
+daynight worker migrate-workspaces
+```
+
+This explicit local operation uses the worker instance lock. It validates the old
+service identity against the configured service, canonical owner IDs, task and
+native-session records, actual workspace directories and Git administrative
+ownership fingerprints. Configured project paths keep their logical spelling;
+ancestor-directory aliases are accepted when Git registration pointers and saved
+and restored pane working directories resolve to the same physical task path,
+while the worktree leaf must remain an ordinary directory with matching physical
+fingerprints. It preserves the SQLite claim/session index, task
+branches, dirty worktrees and original native conversations. An unfinished
+execution with legacy resources must have its recorded native session ID;
+a fresh pending claim without resources does not block migration. Unknown
+formats, conflicting identities and missing original resources are errors,
+with the original resources retained. A current-format or resource-free state
+needs no conversion, and the command returns without starting a daemon.
+
+Before mutation, migration backs up its affected files below
+`~/.daynight/worker/workspace-migration-backups/<UUID>/` and persists
+`~/.daynight/worker/workspace-migration.json`. Run and manual management refuse
+to proceed while that blocking manifest remains. The backup retains its original
+manifest, file hashes, private Herdr tree and completion outcome.
+A maintenance Herdr keeps automatic native-agent restoration disabled and closes
+only verified legacy task workspaces. Migration waits for its shutdown and reads
+back the saved layout before rewriting the Git administration `locked` markers
+with four IDs and their original physical fingerprints. Old automatic recovery
+snapshots stay with the migration backup so they cannot restore legacy labels.
+Herdr owns its snapshot and terminal-history writes; the operation does not edit
+its history fingerprint.
+
+After successful migration, start `daynight worker run`. It creates task-title
+workspaces and resumes the original SQLite native session IDs. Workspace/pane
+IDs and the closed Herdr terminal scrollback are replaced; the native conversation
+history and task work remain. The operation changes local resource representation,
+not remote claims or business task status.
+
+A failed or interrupted migration keeps normal startup blocked. Restore and verify
+the complete saved state through the same command before retrying the migration:
+
+```bash
+daynight worker migrate-workspaces --rollback
+```
+
+Rollback requires an incomplete blocking manifest; it cannot revert a completed
+migration or later execution state. It restores the backed-up Herdr state,
+database and Git markers as one verified old-format set. It leaves an error and
+the startup block when restoration cannot be verified. A normal migration request
+with an incomplete manifest directs the operator to rollback before retrying.
+Resume an old-format runner only after a successful rollback;
+use the new runner after migration completes. The [workspace naming decision](../../.agents/notes/implemented/architecture/2026-10-28-worker-workspace-names.md)
+records the format and the costs of rebuilding the Herdr workspace.
+
 ## Worker manual management
 
 Stop `daynight worker run` before retry, release or resume. Each command
@@ -1144,10 +1294,10 @@ Retry performs one attempt for an active claim still owned by this worker:
 daynight worker retry <task-id> --claim-id <claim-id> --project <project-id>
 ```
 
-It connects the live agent or resumes its recorded native session. NULL emits
-Warning and starts a fresh conversation in the same task worktree. The claim
-and agent type remain; pending rows are started through normal run scheduling.
-After the attempt, run connects to the actual surviving resource. Retry does not
+It connects the live agent or resumes its recorded native session. A NULL ID
+starts a fresh conversation in the same task worktree with an `info` event. The
+claim and agent type remain; pending rows are started through normal run
+scheduling. After the attempt, run connects to the actual surviving resource. Retry does not
 persist a permit or a cumulative cross-restart budget.
 
 Release validates current Project access, source owner/admin, original claim

package/dist/commands/skill/skills/using-daynight/SKILL.md

@@ -73,12 +73,17 @@ operations it requires. Do not load every mode by default.
 | `create-task <request>` | Preparing or registering persistent work explicitly requested by the user | [Create task](references/create-task.md) |
 | `run-task <task-id>` | Executing one specified ordinary task | [Run task](references/run-task.md) |
 | `handoff <task-id>` | Reviewing an explicitly requested task for handoff and enabling permission after it passes | [Handoff](references/handoff.md) |
-| `execute-task-in-managed <task-id>` | The worker startup prompt explicitly declares the `worker-managed` environment, this skill, and this mode | [Managed execution](references/execute-task-in-managed.md) |
+| `autopilot-managed-task <task-id>` | The worker startup prompt explicitly declares the `worker-managed` environment, this skill, and this mode | [Managed autopilot](references/autopilot-managed-task.md) |
 
 The managed execution reference is loaded only for that explicit worker launch;
 ordinary calls do not read it. Task properties, the working directory, and
 environment variables do not select the managed mode. An invocation presented
 as managed with an incomplete launch declaration waits for the missing context.
+A valid worker-managed assignment already carries sufficient authorization for
+its in-scope delivery, including PR merge; deliver it without additional permission
+requests once the required conditions are met. Explicit user restrictions, pause,
+and revocation still apply. The mode executes only that original assignment;
+reading its name does not authorize work or successor selection.
 
 For ordinary calls, honor the explicitly selected mode. For `using-daynight`
 without further input, infer the ordinary mode and target from the current

package/dist/commands/skill/skills/using-daynight/references/autopilot-managed-task.md

@@ -0,0 +1,205 @@
+# Autopilot one managed task
+
+Use this mode only when the worker's startup prompt explicitly declares the
+`worker-managed` environment, the `using-daynight` skill, and the
+`autopilot-managed-task` mode. It delivers one already-claimed assignment through
+its authorized implementation, validation, PR review, merge, and acceptance.
+Read [the handbook](handbook.md) for CLI operations and failure semantics.
+
+## Establish the assignment
+
+The startup prompt supplies `projectId`, `taskId`, the original `claimId`,
+`worktreeId`, the actual worktree path and branch, and the configuration selected
+for this invocation. Use that explicit assignment throughout execution and recovery.
+Task properties, the working directory, environment variables, and an ordinary
+conversation request do not establish this managed context.
+
+If a call is presented as managed but its launch declaration or assignment is
+missing, incomplete, or mismatched, return waiting without task or business
+writes. Do not infer replacement values or fall back to ordinary execution,
+claiming, starting, or selecting another task.
+
+A valid worker-managed assignment already carries sufficient authorization for
+its in-scope delivery, including PR merge. Do not request additional permission
+for those steps. Honor explicit user restrictions, pause requests, and
+revocation. The assignment does not authorize unrelated backlog work, production
+deployment, destructive data operations, or changes to permissions or protections.
+Reading, editing, or mentioning this mode does not establish a managed assignment
+or activate the separately installed `autopilot` skill, which is not a runtime
+dependency.
+
+The worker produces the launch prompt and decides subsequent scheduling. A new
+agent started to recover the same claim receives the original mode and
+assignment again. Reconnecting an existing live agent does not imply that the
+startup prompt should be submitted again.
+
+## Verify the existing execution
+
+Read the latest complete task using the supplied project and task IDs:
+
+```bash
+daynight task show <task-id> --project <project-id> --json
+```
+
+Verify its `projectId` and `id`, `status=in_progress`, and
+`properties.worker.state=active` with the supplied `claimId` and `worktreeId`.
+Verify the actual working directory and Git branch match the supplied worktree.
+Use the configuration supplied for this invocation. The controller selects the
+current settings appropriate to the recorded agent when it launches or resumes
+a native process; an executor does not independently replace that assignment.
+If the same claim is already `completed` and the task is `done`, report the
+existing completion and return without reexecuting it. Any other state or
+identity mismatch leaves execution waiting; an observed claim change stops
+business writes immediately.
+
+The worker has already claimed and started this task. Do not claim it, set it
+to `in_progress`, select candidates, or rerun automatic candidate qualification.
+Read and apply [shared task execution](task-execution.md) for the complete task
+and stage inputs, current prerequisites, authorized work, evidence, and
+acceptance. A missing required input or unmet prerequisite keeps this assignment
+waiting in `in_progress`; it does not authorize another task.
+
+Before resuming interrupted work or making task writes, refresh the complete
+task using the supplied project and task IDs and verify the same active claim.
+Retain the original claim ID through recovery and uncertain-write
+reconciliation; never substitute a claim read from the task.
+
+## Execute within controller-owned resources
+
+Use the supplied worktree and branch for authorized edits, commits, pushes, and
+merges. Do not create, switch, or remove the system-managed worktree or branch.
+Avoid merge options such as `gh pr merge --delete-branch` that may switch the
+checkout or delete its branch. The worker owns resource cleanup after execution;
+do not delete its worktree or close its workspace. Follow a cleanup request for
+attributable temporary resources outside the worktree within its stated scope.
+
+Use the Goal protocol for this task's required inputs and stage acceptance.
+This mode never advances a Goal stage or executes a successor. The shared
+execution and acceptance rules do not change that boundary.
+
+## Preserve execution continuity
+
+Keep a compact checkpoint in the host's session state or the project's existing
+local planning mechanism. Retain the original assignment identities, supplied
+worktree and branch, existing authorization, confirmed scope and acceptance,
+PR URLs and head SHA, validation and review state, blockers, attributable
+resources, and next action. Identify the invocation configuration without
+copying credentials or secrets into checkpoints, task evidence, or logs.
+
+Refresh the checkpoint before a long wait or session compaction. On recovery,
+restore it, verify the original active claim, and refresh remote PR state before
+resuming mutations. Reconcile interrupted business work and uncertain writes
+before deciding the next action. A status question does not cancel the assignment;
+honor explicit pause, stop, and authorization changes without discarding its work.
+
+## Deliver the assigned task
+
+1. **Implement and verify.** Read applicable repository instructions and existing
+   mechanisms. Reuse the confirmed task plan and acceptance criteria. Implement
+   the complete agreed behavior in the supplied worktree, synchronize affected
+   documents, and run relevant checks and behavioral verification. Collaborating
+   agents share this assignment and worktree. Use research and independent review
+   agents when available and authorized. Reassess the design when repeated
+   failures expose a structural problem.
+
+2. **Publish the focused change.** For a PR delivery, commit and push authorized
+   work promptly using repository conventions, default Git identity, and no AI
+   co-author attribution. Create or update the task's focused PR and preserve its
+   complete PR list as required by shared execution. Integrate necessary mainline
+   updates according to the repository's work-branch rules, resolve conflicts in
+   the supplied worktree, and revalidate.
+
+3. **Follow CI and review through repair.** Inspect the actual remote PR head,
+   checks, review requests, comments, and approvals. Request review through the
+   repository's established mechanism. Diagnose failed checks from their logs
+   and repair the cause without weakening acceptance. Rerun an
+   unchanged failure only after confirming a transient infrastructure cause.
+   Each push requires refreshed checks and review for the resulting head.
+
+   Assess findings against the original scope. Fix introduced Critical/Major
+   issues and defects that would make the agreed delivery incorrect. Defer smaller
+   or unrelated improvements under the project's tracking rules without executing
+   them or creating unauthorized tasks. Use fix, defer, and reject dispositions.
+   Reply in each finding's own thread, identify the agent, and resolve handled
+   threads according to repository rules. Repeat review and repair until the
+   final round has no new Critical/Major findings and remote review requirements
+   are satisfied.
+
+4. **Merge and confirm.** The assignment already authorizes its in-scope PR
+   merge. Immediately before merging, refresh the head SHA, required checks,
+   review threads, mergeability, and approvals. Require successful required
+   checks, handled blocking review threads, and actual reviewer approval for the
+   current head. When required checks, current-head approvals, blocking-thread
+   resolution, and mergeability all satisfy the repository's rules, merge
+   immediately without requesting additional permission. Never infer approval
+   from silence, approve your own PR, weaken checks or protections, or use an
+   administrative override. Use the repository's
+   permitted linear-history method and bind the merge to the verified head when
+   the platform supports it. A changed head or failed precondition requires a
+   fresh decision from current state.
+
+   Confirm the platform reports every necessary delivery PR as merged and record
+   each resulting merge commit. An accepted auto-merge request or merge-queue
+   entry is not completion. Do not wait for post-merge mainline CI unless the user
+   explicitly requires that verification. Continue with required task acceptance
+   and evidence after the platform confirms the merge.
+
+5. **Record acceptance and close this claim.** Complete the task's confirmed
+   acceptance and save readable evidence at its identified owner, including actual
+   validation and remaining limitations. Release attributable temporary services,
+   probes, and monitoring resources, including those left by failed collaborators,
+   while preserving controller-owned resources. Finish that cleanup before
+   [original-claim completion](#complete-the-original-claim), because confirmed
+   completion allows the worker to stop the agent and remove its workspace.
+
+For tasks without a PR delivery path, verify the actual artifact against their
+confirmed acceptance criteria. Do not invent a PR or reviewer gate for those
+tasks. Goal discussion confirmation gates remain mandatory; this assignment
+never authorizes execution of a later Goal stage.
+
+## Wait for delivery results
+
+Pending PR CI or review is ongoing execution, not external intervention. Use
+bounded watches or yielding polls at reasonable intervals, inspect new results,
+and act on failures and feedback. A polling timeout ends only that poll; keep
+waiting and inspecting results. Do not return merely because a required PR
+remains unmerged while its CI or review is pending. Use the worker's existing
+continuation mechanism; do not claim monitoring continues without one or start
+an independent scheduling service.
+
+Continue while useful authorized actions remain. A demonstrated blocker such as
+missing credentials, an unavailable required reviewer, a material unresolved
+decision, an unmet human confirmation gate, or an explicit user restriction or
+revocation that prevents delivery requires external intervention. This is a
+background task: do not ask the user questions. Preserve the concrete blocker, actual task and PR state,
+completed work, minimum needed intervention, and next action in the checkpoint,
+then return waiting to the controller. Preserve the assignment in `in_progress`;
+never treat a blocker or ordinary waiting as completion.
+
+## Complete the original claim
+
+When [shared acceptance readiness](task-execution.md#confirm-acceptance-readiness)
+is satisfied, all required evidence is readable, and attributable temporary
+resources have been released, reread the complete task, verify the same active
+claim, and finish with the original claim ID and the version observed for that
+decision:
+
+```bash
+daynight task set-status <task-id> done --project <project-id> --claim-id <claim-id> --if-version <observed-version>
+```
+
+This is the final task mutation. Confirm `done`,
+`properties.worker.state=completed`, and the original claim ID in the service
+result. A refused or unconfirmed write never falls back to ordinary completion
+or automatic replay: read the actual task using the supplied project and task
+IDs and reconcile only the original claim. An unreadable result remains
+unconfirmed; an observed claim change stops further business writes.
+
+## Return to the controller
+
+Return after this task completes or requires demonstrated external intervention.
+Preserve the assignment and waiting checkpoint when a human gate, an explicit
+user restriction or revocation, or unmet acceptance requires that intervention.
+A required PR with pending CI or review follows the ongoing wait above. The worker decides subsequent work
+and owns system-resource cleanup; this mode does not select a successor or advance
+a Goal stage.

package/dist/commands/skill/skills/using-daynight/references/handbook.md

@@ -89,9 +89,13 @@ completion operation: a real completion requires the current owner, active
 claim, in-progress task, and exact version, and retains worker history with
 `state=completed`. Omit `--claim-id` for ordinary status setting; refusal never
 causes fallback between these operations. Read the
-[managed execution reference](execute-task-in-managed.md) only when the worker
+[managed autopilot reference](autopilot-managed-task.md) only when the worker
 startup prompt explicitly selects that mode; ordinary status operations do not
-load its execution rules.
+load its execution rules. A valid worker-managed assignment already has sufficient
+authorization for its in-scope delivery and PR merge. Its executor merges once the
+required checks, current-head approvals, blocking-thread resolution, and
+mergeability conditions are met without requesting additional permission, while
+honoring explicit user restrictions, pause, and revocation.
 
 The service checks the exact version
 before a same-status no-op; it preserves all fields for a current-version no-op

package/dist/commands/skill/skills/using-daynight/references/task-content.md

@@ -6,6 +6,9 @@ private worktree, temporary files, or session-only authorization. The descriptio
 and its readable references must together explain the current task completely.
 Use the target repository's document and language rules.
 
+Distinguish task requirements from session-only constraints, and record only
+task-specific information in the task.
+
 ## Six content requirements
 
 These are content requirements, not six mandatory headings. Provide each item