@codetreker/daynight 0.25.4 → 0.27.2

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

@@ -1,168 +1,58 @@
 ---
 name: using-daynight
-description: Manage concrete work and design reviews in Daynight; register tasks, execute one specified task, or review an explicitly requested handoff.
+description: Manage projects, tasks, attachments, and Goals with the Daynight CLI; create tasks, execute a specified task, or review a handoff. Use only when explicitly invoked or the context clearly requires Daynight.
 ---
 
 # Using Daynight
 
-Use the installed `daynight` CLI to keep persistent tasks aligned with the
-user's authorized work. Task content, status and readiness describe work; they grant no
-permission to implement, publish, deploy, communicate externally, merge, or push
-a mainline branch.
-
-## Required tracking and review
-
-When this skill and Daynight are available, use Daynight to manage concrete work
-with a defined objective and completion conditions: features, bug fixes,
-architecture/design work, actual work items produced by their breakdown, and
-independently scoped [final acceptance](#final-acceptance). An agent's transient
-execution steps, such as reading files, running commands, and routine checks,
-belong in its session execution plan, not task descriptions or attachments.
-Their presence in a plan does not make them Daynight tasks. Use the owning
-Daynight task for every solution, architecture, and design review.
-
-Before asking the user to review a solution, architecture, design, or related
-task result, save the complete current artifact in the owning task's description
-or attachments. Read it back to confirm it is accessible, then provide the task
-ID or verified URL and any attachment paths. Keep the current artifact, accepted
-decisions, and necessary rationale synchronized there. Discussion and review
-processes remain in the session. Chat summaries and repository or PR links may
-supplement the artifact; they do not replace it. Use the shared
-[task content standard](references/task-content.md) for task definitions, inputs,
-and results, and its boundary between task material and session context.
-
-Confirm the CLI, configured service, and intended project are accessible using
-the handbook's discovery rules. Preserve actual availability or upload failures;
-do not claim materials are ready for review until the saved contents are verified.
-
-## Final acceptance
-
-Final acceptance determines whether the complete requested task or Goal satisfies
-its confirmed requirements. Define that outcome explicitly when creating or
-breaking down work. Deliver the requirement-based conclusion, defects, and
-unverified items on the owning task, with the assessed source, key observations,
-and material limits needed to support that result. Keep verification procedures,
-commands, debugging history, and execution progress in the session unless they
-are themselves a required task deliverable.
-
-Use manual verification, existing checks, or temporary helper scripts as
-appropriate. Keep final-acceptance helpers in the project's temporary area and
-uncommitted. Do not integrate them into repository tests, fixtures, runners, CI,
-or tooling, or make building a maintained verification system the acceptance
-deliverable. Review findings about a helper do not authorize that change of scope.
-
-Complete acceptance according to the confirmed whole-task or whole-Goal criteria.
-Finishing or passing helper scripts does not establish that the requested work is
-complete. Do not report the underlying task or Goal as accepted while required
-outcomes remain unmet or unverified. Verify necessary implementation deliveries
-and PR merges as inputs; do not create a separate PR requirement for acceptance
-helpers. Handle discovered product defects within the authorized implementation
-scope.
-
-Implementation and authorized defect-fix tasks retain their normal unit,
-integration, and regression tests and required repository checks. A user-requested
-maintained testing or automation capability is a development deliverable governed
-by its own confirmed scope; do not infer it from a final-acceptance assignment.
-
-## Select a mode
-
-The following are skill modes, not additional CLI commands. Read only the
-selected reference, then use [the handbook](references/handbook.md) for the
-operations it requires. Do not load every mode by default.
-
-| Mode | Use when | Reference |
-|---|---|---|
-| `handbook` | Answering usage questions or performing requested task-management operations | [Handbook](references/handbook.md) |
-| `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) |
-| `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
-request and conversation. If context is insufficient or ambiguous, ask what the
-user intends. Do not default to `handbook` or select a task merely because one
-is ready. This skill does not discover and continuously select subsequent tasks.
-
-## Shared constraints
-
-- Create tasks only with explicit permission for their scope. Implementation
-  requests, tracking needs, and inferred mode selection alone do not grant
-  creation permission. An explicit user or applicable repository instruction
-  requiring Daynight tracking or review is standing creation permission for the
-  necessary tasks within the user's confirmed scope; reuse suitable existing
-  tasks and do not ask for that permission again. Permission to create a Goal
-  covers its discussion stages and confirmed in-scope breakdown, created only at
-  the user-confirmation gates in the Goal protocol; unrelated work needs
-  separate permission.
-- Creation produces `todo` for every normal task and Goal stage and does not
-  start execution. A request to start a Goal discussion authorizes entering
-  `in_progress` for that discussion only; a user-confirmed transition authorizes
-  the next discussion under the Goal protocol. Registration and discussion
-  confirmation grant no delivery execution permission. Existing explicit
-  execution authorization remains limited to its stated task or Goal scope.
-- Use a normal task for one independently tracked outcome. Work requiring
-  multiple independently tracked delivery stages is a Goal, expressed through
-  existing tasks and `dependsOn`. Read [the Goal protocol](references/goal.md)
-  when creating, executing, or advancing such a chain.
-- Advance one specified task at a time, including CI, review, and merge waits.
-  Subagents collaborate on that task. Execution returns after its task completes
-  or requires external intervention; only ordinary execution may follow an
-  explicit user-directed discussion transition under the Goal protocol. Task
-  registration, completion, and discussion confirmation never select later
-  delivery work.
-- Keep execution, analysis, questions, proposals, and task discussions within the
-  current task's confirmed objective, scope, deliverables, and acceptance criteria.
-  Apply this boundary to subagents. Read parent Goal materials, shared architecture,
-  and sibling or successor tasks as needed to understand this task's required
-  inputs, interfaces, and constraints; reading them does not expand its scope.
-  Report cross-task blockers and follow-up proposals without treating them as
-  authorization to create or execute other tasks. Expanding the current task's
-  scope requires explicit user confirmation. A Goal discussion or final-acceptance
-  task may cover the whole Goal when that is its confirmed scope.
-- Use the shared [task content standard](references/task-content.md) when
-  creating, breaking down, handing off, or executing tasks. The description and
-  actual references jointly supply the task definition and produced results;
-  complete inline content needs no primary attachment. Keep execution and
-  discussion methods and processes in the session. Confirm resources before
-  linking and keep shared sources at their real owner. Each Goal delivery
-  description directly identifies the architecture task and every required source
-  location, including
-  inline description sections and full paths for actual attachment documents,
-  even for indirect successors, under the Goal protocol's readback rules. Express
-  necessary direct prerequisites through complete `dependsOn` and its
-  `externalDependsOn` subset. Omit redundant transitive dependencies under
-  [the handbook's reduction rule](references/handbook.md#dependency-reduction).
-  Same-chain prerequisites are ordinary; verified cross-chain prerequisites are
-  external. Both block execution. CLI dependency options replace the full sets;
-  preserve required relationships as the handbook requires.
-- Task creation and execution do not enable `allowAgents`. Only an explicitly
-  authorized [handoff](references/handoff.md) may enable it after content review;
-  handoff does not start execution or replace other authority. Ordinary explicit
-  task execution does not require automatic-selection permission or platform
-  compatibility; dependencies, stage inputs, and execution authorization still
-  apply. Automatic worker eligibility remains governed by the service and worker.
-- Preserve the exact version observed when deciding a metadata update,
-  `task set-status` change, or authorized `task delete`. Deletion retains stored
-  data and attachments and requires explicit authorization for the target task.
-  Add `--remove-depends` only when explicitly authorized to remove other tasks'
-  ordinary and external dependencies on that task; omission keeps strict deletion.
-  Generic updates cannot change status. Confirm writes,
-  reconcile uncertain results before further mutations, and preserve actual
-  failures. The handbook explains operational context; installed CLI help owns
-  command usage.
-- Follow the target repository's delivery rules and the user's authorization.
-  When task acceptance includes PR delivery, a request to leave that PR for user
-  review keeps the task `in_progress`. A Daynight discussion uses its own
-  user-confirmation gate unless PR delivery is explicitly part of its acceptance.
-  Completion rules grant no merge authority.
+Daynight manages and schedules projects and tasks for people and agents.
+Use the `daynight` CLI to operate it and [Daynight](https://daynight.cc) to browse projects, tasks, and delivery materials.
+
+## Capabilities and concepts
+
+| Concept | Meaning and capabilities |
+| --- | --- |
+| Project | A project associated with a Git repository, organizing tasks and project access. |
+| Task | An independently tracked work item with a description, status, dependencies, execution requirements, and PR references. In this skill, "task" means this object. |
+| Goal | A complete objective expressed through tasks and their dependencies, including requirements discussion, solution discussion, and delivery work; not a separate resource. |
+| Attachment | A task's independent attachment area for inputs and results such as documents, prototypes, and images. |
+| worker-managed | An execution environment assigned and managed by `daynight worker`; the agent executes only its explicit assignment. |
+
+The CLI supports project registration and lookup, task creation and filtering, status and dependency management, attachment reads and writes, and worker-managed execution.
+Creation, execution, and handoff are separate operations; see [authorization and scope](references/authorization.md).
+
+## Setup and CLI
+
+Read [setup](references/setup.md) when first connecting or switching repositories.
+If the CLI is missing, obtain user authorization and follow the [installation guide](https://daynight.cc/setup).
+
+See the [CLI handbook](references/handbook.md) for command entry points.
+Use `daynight --help` and the relevant subcommand's `--help` for arguments and option combinations.
+
+## Read by purpose
+
+Read only the files and required references for the current operation, not every document by default.
+
+| Purpose | Reference and responsibility |
+| --- | --- |
+| Determine permitted work and required authorization | [Authorization and scope](references/authorization.md): tracking obligations, operational authorization, and task boundaries |
+| Connect the current repository | [Setup](references/setup.md): CLI, sign-in, project, and repository-instruction setup |
+| Find commands | [CLI handbook](references/handbook.md): command map and help discovery |
+| Discover, select, or register projects | [Project management](references/project-management.md): project identity and reuse |
+| Query tasks, edit metadata, status, or dependencies, or delete tasks | [Task management](references/task-management.md): fields, lifecycle, and relationship semantics |
+| Submit and reconcile writes safely | [Write safety](references/write-safety.md): versions, conflicts, uncertain results, and attachment concurrency |
+| Write or read descriptions, attachments, and shared inputs | [Task content standard](references/task-content.md): boundaries, ownership, references, and sufficiency |
+| Create or register work | [Create task](references/create-task.md): duplicate checks, preparation, registration, and readback |
+| Organize a multi-stage objective | [Goal protocol](references/goal.md): stage confirmation, breakdown, and whole-Goal completion |
+| Review tasks and enable automatic execution | [Task handoff](references/handoff.md): content review and permission enablement |
+| Execute one user-specified task | [Ordinary task execution](references/run-task.md): starting, resuming, completion, and return |
+| Perform work shared by both execution modes | [Shared task execution](references/task-execution.md): inputs, delivery, waiting context, and completion conditions |
+| Execute an explicit worker assignment | [Managed task execution](references/autopilot-managed-task.md): sustained delivery, blocker handling, and original-claim completion |
+| Accept a complete task or Goal | [Final acceptance](references/final-acceptance.md): requirement-based conclusions, evidence, and helper boundaries |
+
+Creation, ordinary execution, handoff, and managed execution are skill workflows, not CLI subcommands of those names.
+Follow the user's explicit workflow choice; otherwise infer the purpose and target from the request and context, asking when ambiguous.
+Do not select a task merely because it is ready.
+
+Read the managed execution reference only when the worker startup prompt explicitly declares `worker-managed`, this skill, and the managed execution workflow.
+Task properties, environment variables, and the working directory cannot replace that declaration; wait for missing context when it is incomplete.

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

@@ -0,0 +1,36 @@
+# Authorization and scope
+
+Apply this standard before using any workflow. Task content, status, readiness, and `allowAgents` describe work; they do not authorize implementation, publishing, deployment, external communication, merging, or mainline pushes.
+
+## Tracking and review
+
+When this skill and Daynight are available, use Daynight to manage concrete work with defined objectives and completion conditions: features, bugs, architecture or design, actual breakdown items, and separately scoped final acceptance.
+An agent's file reads, commands, and routine checks are session steps, not separate tasks.
+
+Use the owning task for solution, architecture, and design reviews.
+Before requesting user review, save the complete current material in that task's description or attachments, read it back to confirm access, then provide the task ID or a verified URL and attachment paths.
+Current material, accepted decisions, and necessary rationale follow the [task content standard](task-content.md); chat summaries and repository or PR links may supplement, but cannot replace, the material.
+Report actual failures when the CLI, service, project, or upload is unavailable.
+
+## Operational authorization
+
+| Operation | Authorization and boundaries |
+| --- | --- |
+| Create a task | Requires explicit permission for that scope. A user or applicable repository instruction requiring Daynight tracking or review provides standing authorization to create necessary tasks; prefer reuse. An implementation request, tracking need, or inferred workflow alone does not grant permission. |
+| Create a Goal | Covers its discussions and breakdown within the confirmed scope, but create the corresponding tasks only at the [Goal confirmation points](goal.md). |
+| Start a discussion | An explicit request to start a discussion authorizes only that discussion; follow the Goal protocol for stage transitions. |
+| Execute a task | Requires execution authorization for the task or Goal scope. Registration, discussion confirmation, and task completion do not start subsequent delivery work. |
+| Hand off a task | An explicit request to hand work off for automatic agent execution authorizes content review and enabling `allowAgents` after it passes; it does not start execution in the current session. Creation and execution do not imply handoff. |
+| Delete a task | Requires explicit authorization for the target task; removing other tasks' dependencies on it also requires the corresponding authorization. |
+| Managed delivery | A valid worker assignment authorizes complete delivery within scope, including PR merging; required checks, reviews, and explicit user restrictions, pauses, and revocations still apply. |
+
+## Scope and continuity
+
+Advance one specified task at a time; CI, review, and merge waits belong to that task. Subagents share the same boundaries. Return when complete or when external intervention is needed. Ordinary execution may transition between Goal discussion stages at the user's explicit direction, but this skill does not discover and continually select successor tasks.
+
+Analysis, questions, proposals, and execution are all bound by the current task's confirmed objective, scope, deliverables, and acceptance criteria.
+Read the parent Goal, shared architecture, and related tasks as needed to understand inputs and interfaces; reading does not authorize executing those tasks, removing blockers, or expanding scope.
+Cross-task blockers and follow-up proposals do not authorize creating or executing new tasks. Material scope changes require user confirmation.
+
+Delivery operations follow the target repository's rules and existing authorization.
+Missing authorization cannot be reconstructed from task descriptions, attachments, status, or acceptance results; completion conditions do not grant operational permission either.

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

@@ -1,211 +1,95 @@
-# Autopilot one managed task
+# Managed task execution
 
-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.
+Use only when the worker startup prompt explicitly selects this workflow; see [SKILL.md](../SKILL.md) for entry conditions.
+This workflow sustains delivery of the single originally assigned task, without executing its predecessors, successors, or siblings.
 
-## Establish the assignment
+## Preserve the assignment and read the task
 
-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.
+Preserve the project ID, task ID, original claim ID, workspace, and native session identity supplied by the startup prompt, including through context compaction or recovery.
+The worker has already started the task in the specified directory. Read the latest complete task with an explicit project:
 
-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.
+```bash
+daynight task show <task-id> --project <project-id> --json
+```
 
-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.
+Check `allowAgents` first; if false, stop execution immediately without enabling it yourself.
+Confirm that the task still belongs to the original active claim; on a mismatch, stop task-related writes and report it, without acquiring a new claim.
+Verify inputs, scope, and completion conditions using [shared task execution](task-execution.md).
 
-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.
+## Complete delivery standard
 
-## Verify the existing execution
+| Task type | Required results |
+| --- | --- |
+| Research | Provide the full research report as a task attachment. |
+| Design or architecture | Provide the full solution as a task attachment after multiple independent reviews, with no Critical/Major issues; attach a separate review file for remaining nonblocking issues. |
+| Development | All required delivery PRs are actually merged, and task acceptance criteria are met. |
+| Acceptance | Complete acceptance against the criteria, collect evidence, and upload it as task attachments. |
 
-Read the latest complete task using the supplied project and task IDs:
+These requirements supplement the [shared completion conditions](task-execution.md#completion-conditions).
+Task descriptions and source organization follow the [task content standard](task-content.md); inline content cannot replace attachments explicitly required by this table.
+Goal confirmation points still require human confirmation; the assignment does not authorize executing other stages.
 
-```bash
-daynight task show <task-id> --project <project-id> --json
-```
+## Sustain complete delivery
+
+A valid assignment includes the authorization needed for complete delivery of this task; see [authorization and scope](authorization.md) for the boundaries.
+Keep advancing the task proactively; occasional user interaction does not authorize stopping, while explicit pauses, restrictions, and revocations still apply.
+Continue while useful, authorized actions remain available.
+
+Implement, synchronize related documents, and verify in the assigned workspace; collaborating agents share the task scope.
+Use research and independent review agents when available and authorized; reassess the design when repeated failures expose structural problems.
+For tasks without PR delivery, apply the complete delivery standard directly rather than inventing a PR workflow.
+
+For PR delivery, sustain the following workflow:
 
-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, results, 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 material, or logs. Keep
-this recovery context out of task descriptions and attachments; task material
-cannot replace missing operational authorization or the original assignment.
-
-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. Use the task's required design inputs and acceptance criteria;
-   keep the execution plan in this session. 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 retain
-   its merge result in the session. A final revision may identify the task's
-   delivered artifact. 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 results after the platform confirms the merge.
-
-5. **Record acceptance and close this claim.** Complete the task's confirmed
-   acceptance and save its readable results at their actual owners, including the
-   acceptance conclusion and material limitations. Keep verification procedures
-   and CI/review/merge history in the session. 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.
+1. Commit, push, and create or update focused PRs promptly under repository conventions; use the default Git identity and omit AI co-author attribution.
+   Integrate necessary mainline updates, resolve conflicts, and verify in that workspace.
+2. Actively monitor remote HEAD, CI, reviews, and conflicts.
+   Diagnose failures; rerun an unchanged failure only after confirming a transient infrastructure cause.
+   Refresh checks and reviews after every push.
+   Fix Critical/Major issues in the current change and defects that would make delivery incorrect; defer smaller or unrelated improvements under project rules, without creating tasks on your own.
+   Respond in each thread with the fix, deferral, or reason for not adopting the finding, identify the agent, and resolve threads under repository rules.
+   Continue until the final round has no new Critical/Major issues and remote review requirements are met.
+3. Immediately before merging, refresh HEAD, required checks, blocking threads, mergeability, and approvals for the current HEAD.
+   Once all requirements are met, merge using a linear method permitted by the repository; bind the operation to the verified HEAD when the platform supports it.
+   Do not infer approval from silence, self-approve, bypass protections, or weaken checks.
+   Reassess if HEAD or conditions change.
+4. Verify that every required PR is actually merged, then complete task acceptance and save the results.
+   Do not additionally wait for post-merge mainline CI unless the user explicitly requires it.
+
+## Ongoing waits
+
+Pending CI and reviews are part of continued execution.
+Use bounded listeners or reasonable polling that yields execution; one wait timing out does not end the task.
+Prefer the worker's existing continuation mechanism, without creating another scheduling service or claiming continued monitoring after it has stopped.
+Inspect new results and handle failures, feedback, and conflicts; ordinary waits do not end the task.
+
+## Request user interaction
+
+Request user intervention when a goal, architecture, execution plan, or acceptance criteria necessary to complete the task are missing, when a problem is not covered by the design, or when another blocker arises.
+Do not invent missing decisions or treat the problem as completion.
+
+1. Record the specific issue on the current task: `set-property <task-id> worker.signaling "<reason>"`.
+2. Also print the issue to the terminal, preserve the [waiting context](task-execution.md#waiting-context), exit the execution loop, and wait for the user to address it; keep the task `in_progress` and do not select other work.
+3. After receiving feedback, verify the original assignment and confirm that the problem is solved, then clear the signal with `remove-property <task-id> worker.signaling`.
+4. Confirm the removal before resuming automatic execution of the current task. If the problem remains unresolved, retain the signal and keep waiting.
+
+Signal writes and removal also follow [write safety](write-safety.md).
+Recording a signal does not complete the task; do not resume blocked operations until the problem is solved.
 
 ## Complete the original claim
 
-When [shared acceptance readiness](task-execution.md#confirm-acceptance-readiness)
-is satisfied, all required task results are 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:
+Once shared completion conditions are met and required results are readable, clean up this task's temporary services, probes, and monitoring, including resources left by failed collaborators; preserve controller-owned resources. Clean up before completing, because the worker may stop the agent and remove the workspace after confirming completion.
+
+Read back the complete task, verify the same original active claim, and use the version observed at that point:
 
 ```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.
+The claim ID must be the UUID explicitly supplied in the startup assignment, used only for done, never inferred from the environment or task data.
+This is the final task write. Confirm that the response is done, `properties.worker.state=completed`, and the original claim ID is retained.
+
+If rejected or the response is uncertain, follow [write safety](write-safety.md) to reconcile the original claim read-only; do not automatically replay the operation or fall back to ordinary completion.
+An unreadable result remains unconfirmed; stop task-related writes immediately if the claim has changed.
+Return to the controller after completion; when user intervention is needed, enter the wait defined under [Request user interaction](#request-user-interaction).
+The worker manages subsequent work and system resources.