@codetreker/daynight 0.26.0 → 0.29.0

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: `daynight 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 `daynight task 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.

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

@@ -1,198 +1,43 @@
-# Create a task
+# Create task
 
-Use this mode to prepare and register work that needs persistent tracking. Read
-[the handbook](handbook.md) before discovery, queries, or writes and
-[the task content standard](task-content.md) for content preparation. Return after
-registration; registration alone does not authorize execution. An explicit request to start a Goal discussion routes the registered
-current stage to run-task under the Goal protocol.
+Prepare and register authorized work, then return without automatic execution.
+Apply [authorization and scope](authorization.md) first, find commands in the [CLI handbook](handbook.md), and prepare content under the [task content standard](task-content.md).
 
-Create tasks only with the user's explicit permission for the relevant scope.
-An explicit user or applicable repository instruction requiring Daynight tracking
-or review supplies standing creation permission for necessary tasks within the
-confirmed scope. Reuse suitable tasks and do not ask for that permission again.
-Loading this mode, needing durable tracking, or permission to implement alone
-does not grant creation permission. Ask when it is missing; reuse
-permission already granted for the scope. Creation does not authorize execution or delivery.
+## Select and check for duplicates
 
-## Choose the tracked outcome
+Use one task per independently tracked result. For multi-stage objectives, follow the [Goal protocol](goal.md) and register only the currently permitted stage.
+See [final acceptance](final-acceptance.md) for the scope and results of independent acceptance tasks. Do not register routine execution steps as separate tasks.
 
-With creation permission, register or reuse a task for concrete work such as a
-feature, bug fix, architecture/design assignment, or actual work item produced by
-its breakdown. Each task has its own objective, scope, and observable completion
-conditions. Solution, architecture, and design reviews use their owning task
-under the entrypoint's required tracking and review rules.
+Confirm the [target project](project-management.md) and search for existing work on the same problem and scope, including completed tasks.
+Read full descriptions, actual sources, dependencies, and acceptance criteria before deciding to reuse a task; similar titles do not establish identity.
+After an interruption, verify existing resources before creating anything again.
 
-Keep an agent's transient execution steps, such as reading files, running
-commands, and routine checks, in the session's execution plan. Do not put these
-steps in task descriptions or attachments or turn them into Daynight tasks
-merely because an agent generated them. A distinct acceptance or validation
-assignment with its own outcome can still be a task.
-For [final acceptance](../SKILL.md#final-acceptance), identify the entire task or
-Goal being assessed and its confirmed requirement sources. Define the deliverable
-as the requirement-based acceptance conclusion, supporting observations, defects,
-and unverified items. Apply the shared rule to temporary helpers; do not make
-their development or repository
-delivery the acceptance outcome.
+## Prepare content
 
-Running a check while delivering an existing task is an execution step. If the
-request contains only execution steps for existing work, keep them in that
-work's session and return without registering additional tasks.
+Write an outcome-oriented title and a task-specific Markdown description that meet the content standard and current stage requirements.
+Genuinely required sources must be readable, and future outputs must be explicitly assigned to prerequisite tasks.
+Keep shared inputs in their owning tasks; do not copy the full set of material.
 
-For a multi-stage Goal, follow [the Goal protocol](goal.md). Register only the
-current requirements discussion task; do not create an architecture placeholder
-or delivery tasks upfront. Its stage brief describes the discussion and its
-user-confirmation gate; finished requirements and applicable prototypes are
-outputs. User-confirmed requirements permit creation and start of solution
-discussion. Only user-confirmed solution permits actual delivery registration.
-A registration-only request leaves the current stage todo and returns; an
-explicit discussion-start request authorizes its start through
-run-task. Creating a Goal covers the later in-scope stages and breakdown only
-at those confirmation gates.
+Frontend delivery requires an interactive prototype that runs entirely on the frontend and matches the final visual style, covering applicable populated, empty, loading, failure, disabled, long-content, and narrow-screen states.
+Include all resources with valid references, and view and actually interact with the prototype. Static sketches or simplified styling do not satisfy the requirement.
+A discussion task that produces a prototype treats it as a result, not a prerequisite for starting.
 
-For a single tracked outcome, prepare its stage-appropriate task definition,
-actual required inputs, and acceptance criteria before registration. A frontend
-delivery task also needs its applicable mock UI under the artifact rules below.
-A design-producing task does not require its unfinished design as an input.
+Mock UI data and interaction state must remain only in the current page's memory.
+Do not use storage mechanisms such as `localStorage`, `sessionStorage`, Cookie, or IndexedDB, or perform other operations that persistently change local state; dependency libraries must not perform these operations indirectly either.
+Reloading or reopening the prototype must restore its initial state.
 
-Look for existing work with the same problem and scope, including completed
-tasks; the default list contains only unfinished work. Inspect full descriptions,
-actual dependencies, content sources, and acceptance criteria. For a Goal,
-inspect the existing chain and its owning inputs. Titles alone do not establish
-identity. Reuse suitable work and preserve valid requirements; interrupted
-registration does not justify a duplicate task or chain.
+Select necessary direct prerequisites under [dependency classification and reduction](task-management.md#dependency-classification), verifying whether they belong to the same chain or another chain.
+Platform requirements must come only from confirmed task needs. Do not add dependencies for visual grouping or duplicate the full relationship list in the body.
 
-## Write task-specific content
+## Register and read back
 
-Use the target repository's document and workspace rules and the shared task
-content standard. Give each task an outcome-focused title and a Markdown
-description that identifies its concrete work, responsibility, and actual content
-sources. The description and readable references together provide its objective
-and requirements, scope and constraints, inputs and sources, deliverables and
-contracts, and acceptance criteria. Complete inline content needs no primary
-attachment; reference-owned and mixed content are also valid without repeating
-complete documents. Save results as they are produced. Stage briefs describe
-work that produces the stage's outputs; do not claim unfinished outputs already
-exist or require an execution plan, confirmation log, or evidence attachment.
+1. Register with `task create` and retain the returned ID. New task status and permissions follow [task management](task-management.md).
+2. If the task owns attachments, upload and verify their content before adding actual references to the description. Follow [write safety](write-safety.md) for all writes.
+3. Read back the full task, required attachments, and shared inputs to verify sufficient content and valid resources.
+   Check dependencies through [post-change verification](task-management.md#verify-dependency-changes).
+   For Goal delivery items, also check the [architecture source index](goal.md#register-the-delivery-breakdown).
+4. Report the task ID, registration result, and specific gaps.
+   After partial success, retain existing IDs and resume unfinished operations; unreadable required sources still mean failure.
 
-Attach only resources this task needs or owns. Keep shared Goal requirements
-with the requirements task and architecture and breakdown with the solution
-task. Reference the owning task ID and its description with applicable sections
-for inline content, full paths for actual attachments, or verified immutable
-repository sources. Read source descriptions through `task show --json` and
-attachment bytes through the attachment commands. For every Goal delivery task,
-list the architecture task ID and all required architecture source locations
-directly in its description, including indirect successors, as
-[the Goal protocol](goal.md) requires. Do not copy the whole shared packet
-into every task. An independently needed snapshot records its purpose, original
-source, and source revision or content identity.
-
-A frontend delivery task requires an interactive mock UI that runs with frontend code
-alone, matches final visual styling, and represents relevant data and interaction
-states. Include applicable populated, empty, loading, failure, disabled, long
-content, and narrow-screen cases. Provide required CSS, JavaScript, images, and
-other resources with working relative references. A static sketch or simplified
-styling does not satisfy this requirement. For a UI Goal, this prototype is
-produced by the Goal description stage and referenced by later tasks.
-
-Use established task IDs for necessary direct prerequisites. Before registration,
-apply [the handbook's dependency reduction rule](handbook.md#dependency-reduction)
-to omit relationships already supplied by another retained path. Confirmed
-same-chain stages use `--depends-on`; a verified prerequisite owned by another
-same-project chain uses `--external-depends-on`. The CLI sends their complete
-union and explicit external subset. Do not infer ownership from status, title,
-graph roots or array order, and do not add a dependency only to make tasks appear
-together. Resolve unclear
-ownership before registering the relationship. A top-level task has no ordinary
-prerequisites; it may still have real external prerequisites that block execution.
-Do not add a Dependencies section or duplicate the relationship lists in task
-prose. Repository specifications and design documents retain their full contracts;
-the current task identifies its required design inputs and verifiable acceptance
-criteria directly or through their actual owners.
-
-## Author Markdown
-
-Use headings, paragraphs, lists, quotes, fenced code, tables, links, and images
-when they help readers understand the assignment. The Web renders CommonMark
-and GFM; raw HTML appears as text. API and CLI reads retain the original Markdown
-string, with no separate format field. Preserve its syntax, whitespace, code,
-and valid references when replacing the complete description.
-
-A relative link or image in a description starts at this task's attachment root.
-A link inside a Markdown attachment starts at that file's directory. Keep paths
-inside the task root and preserve the actual case and resource identity. Confirm
-an upload and read back its contents before adding its link. Reference shared
-inputs by their verified owning task ID and description/sections or actual
-attachment path, or by an immutable repository URL. A relative link cannot
-identify another task's content.
-
-For example, the following brief applies to a task whose confirmed, readable
-attachments include the complete `mockui/index.html` prototype and its resources.
-Use this path only when those files actually belong to that task; adapt the
-content and references to the actual assignment. A Goal stage that produces a
-prototype links it only after producing and confirming it.
-
-```markdown
-## 问题与要求
-登录失败后，用户无法判断是否可以重试。显示明确的失败原因和重试入口，保留当前登录表单输入。
-
-## 范围与交付
-交付登录页的错误提示、重试交互和中英文文案；沿用现有认证接口与会话边界。
-
-## 输入
-[交互原型](mockui/index.html) 定义相关视觉样式和交互状态；认证接口沿用仓库现有契约，无新增任务间交换。
-
-## 完成条件
-网络失败和凭据错误均显示对应提示；重试成功后进入工作区。桌面与窄屏、两种语言的交互正确，表单输入保持。
-```
-
-This example defines the task inline and references its actual prototype. Shared
-design inputs retain their real owner under the source rules above. Neither the
-brief nor an attachment needs the session's implementation steps, tool choices,
-or review schedule. A filename such as `plan.md` does not determine whether its
-contents belong to the task.
-
-## Register and verify
-
-New tasks have `allowAgents=false`; creation cannot enable the permission.
-Creation and breakdown do not enable it. A separate, explicitly requested
-[handoff](handoff.md) reviews each task before enabling permission. Execution
-authorization and automatic-discovery permission remain separate decisions.
-
-Tasks without `--required-platform` are unrestricted. Set windows, linux or macos
-only when the confirmed task needs that execution environment. Platform requirements
-do not start tasks or enable automatic execution; they survive all status changes.
-
-Reuse the established project and suitable tasks. Create new tasks in `todo`,
-retaining each confirmed ID. Set concrete descriptions and actual ordinary and
-external prerequisites using the handbook's full CLI replacement rule. Upload
-required task-owned resources when the content uses attachments; add actual
-references to the complete description using the observed task version. Reference
-already readable shared inputs at their source. Do not present planned uploads as existing attachments.
-
-Read back each complete task, its attachment inventory and required contents,
-and its referenced shared inputs. Verify self-contained Markdown descriptions,
-valid links and images, the stage-appropriate task definition, produced results,
-real source identities, complete necessary direct prerequisites
-and their intended external subset, absence of redundant dependencies under the
-handbook's reduction rule, and applicable mock UI resources and interaction. For a
-Goal, verify only the current discussion stage and its brief;
-verify later stages and delivery tasks when their confirmation gate permits
-registration. When registering delivery work, check every task's description,
-including indirect successors, for its architecture task ID and required document
-references, and read the referenced contents under the Goal protocol.
-Registration is complete only when required artifacts and associations are
-confirmed readable. Registration leaves work todo and does not execute it. A Goal
-discussion-start request is scoped execution authorization for that discussion,
-as the Goal protocol specifies. User solution confirmation permits registration
-of todo delivery tasks and grants no delivery execution permission. Apply any
-existing explicit execution authorization only within its stated task or Goal
-scope. Registration does not select or start a later task.
-
-If creation succeeds but a later operation fails, retain the confirmed IDs and
-resume missing operations there. Tasks remain `todo`. Reconcile uncertain results through the handbook before another
-mutation. Report incomplete registration with the exact missing operation or
-artifact and next step. An unreadable required source is still a failure; do
-not silently replace it with invented or weaker content. Return after verified
-registration without selecting or executing a task for registration-only requests. If the user explicitly requested
-the current Goal discussion to start, pass its confirmed ID to run-task under
-the Goal protocol.
+A registration-only request ends here, with the task remaining `todo`.
+When explicitly asked to start the current Goal discussion, pass the confirmed ID to [ordinary task execution](run-task.md) under the Goal protocol.

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

@@ -0,0 +1,25 @@
+# Final acceptance
+
+Use to determine whether the complete task or Goal requested by the user meets confirmed requirements.
+Define the acceptance scope, requirement sources, actual delivery inputs, and observable completion conditions during creation or breakdown; do not limit acceptance to an implementation fragment or helper script.
+
+## Verify complete outcomes
+
+Read the complete confirmed requirements and changes, actual deliverables, and acceptance criteria.
+Use manual verification, existing checks, or temporary helpers as needed to verify required implementation and actual PR merges.
+Conclusions must cover the entire agreed scope; do not report the original task or Goal as having passed when required outcomes are unmet or unverified.
+
+Deliver requirement-based conclusions, defects, unverified items, and the evaluated sources, key observations, and material limitations needed to support those conclusions in the owning task.
+Content ownership follows the [task content standard](task-content.md); managed acceptance must also meet the evidence attachment requirements of the [complete delivery standard](autopilot-managed-task.md#complete-delivery-standard).
+Keep verification commands, debugging history, and progress in the session unless they are themselves required deliverables.
+
+## Helper boundaries
+
+Keep temporary acceptance scripts in the project's temporary area.
+Do not commit them, integrate them into repository tests, fixtures, runners, CI, or tooling, or make an ongoing verification system an acceptance deliverable.
+Completing or passing a helper script does not prove that user requirements are met and does not create a separate PR requirement for it.
+Review findings in helpers do not authorize scope expansion.
+
+Implementation and authorized defect fixes still retain normal unit, integration, and regression tests and required repository checks.
+User-requested persistent tests or automation are separately confirmed development deliverables, not something inferred from an acceptance task.
+Fix product defects only within the authorized implementation scope; handle the rest under [authorization and scope](authorization.md).