@codetreker/daynight 0.21.2 → 0.21.8

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

@@ -3,8 +3,9 @@
 Read this reference when starting or registering a Goal, discussing one of its
 stages, or advancing its authorized scope. Use [create-task](create-task.md) for
 registration, [the task content standard](task-content.md) for the shared six
-content requirements, [run-task](run-task.md) for task execution, and
-[the handbook](handbook.md) for CLI semantics. A Goal uses existing tasks,
+content requirements, [shared task execution](task-execution.md) for input,
+delivery, and acceptance rules, and [the handbook](handbook.md) for CLI semantics.
+The selected execution mode owns task lifecycle and return behavior. A Goal uses existing tasks,
 attachments, complete `dependsOn` relationships, their `externalDependsOn`
 classification, and PR properties. It adds no resource, command, or status.
 
@@ -27,8 +28,9 @@ permission.
 
 A request to start a Goal discussion authorizes creating and starting
 that discussion task so it becomes `in_progress`. A registration-only request
-creates only the current discussion task in `todo` and returns without execution. A generic run request, Goal registration, or autopilot
-activation does not supply discussion-start or delivery execution authorization.
+creates only the current discussion task in `todo` and returns without execution.
+Goal registration alone does not supply discussion-start or delivery execution
+authorization.
 
 ## Start requirements discussion
 
@@ -80,8 +82,8 @@ such as `Architecture discussion: <outcome>`, and an ordinary prerequisite on th
 completed requirements task. The user's direction to start this discussion
 provides its scoped execution authorization. Prepare its stage brief,
 read its current version, set in_progress through the same lifecycle, and
-confirm `in_progress`. This user-directed transition does not require autopilot
-and does not authorize selection of another unrelated task.
+confirm `in_progress`. This user-directed transition is available to ordinary
+execution only; it does not authorize selection of another unrelated task.
 
 ## Execute the appropriate stage
 
@@ -123,8 +125,8 @@ steps into tasks. The combined scope must cover the confirmed Goal, rather than
 vague placeholder.
 
 Create new delivery tasks in `todo`. Solution confirmation authorizes the
-confirmed breakdown's registration, not implementation, autopilot,
-automatic-execution permission, publishing, deployment, or merge. Apply any
+confirmed breakdown's registration, not implementation, automatic-execution
+permission, publishing, deployment, or merge. Apply any
 separate explicit authorization only within its stated scope. New tasks have
 `allowAgents=false`; registration does not enable it. Only a separately explicit
 [handoff](handoff.md) may review and enable permission; it does not supply delivery
@@ -135,8 +137,11 @@ without another ordinary implementation prerequisite depends directly on the
 solution discussion, so each delivery path includes confirmed design completion.
 Mark verified prerequisites owned by another same-project chain as external;
 external prerequisites remain real blockers and do not replace that ordinary
-design gate. Preserve the complete relationship sets under the handbook's CLI
-replacement semantics. Do not create dependencies merely to group cards.
+design gate. Apply [the handbook's dependency reduction rule](handbook.md#dependency-reduction)
+before registering the breakdown: successors inherit prerequisites through
+retained paths and do not repeat those direct edges. Preserve the complete
+necessary relationship sets under the handbook's CLI replacement semantics.
+Do not create dependencies merely to group cards.
 
 Upload needed task-owned resources when their content uses attachments. Keep
 shared requirements with the requirements task and the solution and breakdown with the
@@ -155,16 +160,18 @@ These input references do not add execution dependencies or duplicate shared
 documents.
 
 Read back every task, required attachment, shared input, and dependency before
-reporting the breakdown registered. Check each delivery task's description,
-including indirect successors, for the architecture task ID and every required
+reporting the breakdown registered. Verify required paths and the absence of
+redundant direct edges under the handbook's reduction rule. Check each delivery
+task's description, including indirect successors, for the architecture task ID and every required
 document reference; confirm that each reference resolves to the intended readable
 content. Keep the solution discussion `in_progress` when registration is incomplete.
 If the accepted solution materially changes, obtain renewed user confirmation
 before registering or advancing the changed work.
 
 For an illustrative `architecture → A → B` chain, A delivers the upload API and B
-delivers its retry controls. B depends on A and directly names the architecture
-inputs in its description. The following task ID and paths are hypothetical;
+delivers its retry controls. B depends only on A, inherits the architecture
+prerequisite through A, and directly names the architecture inputs in its
+description. The following task ID and paths are hypothetical;
 replace them with verified sources when registering real work:
 
 ```markdown
@@ -219,26 +226,21 @@ new decision. Readiness and `in_progress` provide no ownership lock or lease.
 
 ## Advance and accept the whole Goal
 
-Automatic delivery discovery requires actual-runtime platform compatibility.
-Use autopilot's platform-filtered queries and preserve automatic-selection context
-for run-task's full-task recheck before setting in_progress. A user-specified fixed
-Goal queue keeps its manual path and existing execution scope across ready successors;
-it does not enable automatic discovery permission or bypass stage confirmation.
-
-A user-directed requirements-to-solution transition follows the confirmation
-protocol above. Ordinary `run-task` otherwise returns after its specified task
-completes or needs external intervention. Neither discussion completion nor
-breakdown registration activates autopilot or starts delivery. Only explicitly
-active autopilot selects later delivery work, and only with the existing readiness, input, and execution requirements. Automatic discovery
-requires `allowAgents=true`; an explicitly selected task or fixed Goal queue
-uses the manual execution path regardless of that flag. CI, review, and merge
-waits stay with the current delivery task.
-
-Delivery tasks follow normal run-task completion: accepted outcomes, required
+Ordinary execution processes one specified task and returns after completion or
+external wait. A user-directed requirements-to-solution transition follows the
+confirmation protocol above and the ordinary execution mode. Neither discussion
+completion nor breakdown registration starts delivery or selects later work.
+Existing execution authorization for a fixed Goal scope remains within that
+scope, but does not make the skill discover or continuously select successors.
+CI, review, and merge waits stay with the current delivery task. Other execution
+modes preserve their own return boundary when reading this stage protocol.
+
+Delivery tasks satisfy [shared acceptance readiness](task-execution.md#confirm-acceptance-readiness)
+and complete through their selected execution mode: accepted outcomes, required
 review, all necessary authorized PR merges, and readable evidence. To report the
 whole Goal complete, inspect the full confirmed delivery scope, every delivery
-task's completion, all required delivery PR merges, and the original
-whole-Goal requirements with their confirmed changes. Apply
+task's completion, all required delivery PR merges, and the original whole-Goal
+requirements with their confirmed changes. Apply
 [Final acceptance](../SKILL.md#final-acceptance) to the combined delivery and its
 evidence; completing or passing temporary helpers does not establish that the
 Goal is complete.

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

@@ -80,7 +80,20 @@ individual task reads.
 
 **Task status.** Creation starts in `todo` with no task approval stage and does
 not start execution. `task set-status <task-id> <status> --if-version <version>`
-sets any of `todo`, `in_progress`, or `done`. The service checks the exact version
+sets any of `todo`, `in_progress`, or `done` through ordinary status setting.
+To finish an explicitly supplied active worker claim, use
+`task set-status <task-id> done --claim-id <claim-id> --if-version <version>`.
+The claim ID must be a UUID and is valid only with `done`; the CLI never infers
+it from task data or the environment. This path uses the existing worker
+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
+startup prompt explicitly selects that mode; ordinary status operations do not
+load its execution rules.
+
+The service checks the exact version
 before a same-status no-op; it preserves all fields for a current-version no-op
 and refuses stale versions. A real change increments the version once. Generic
 metadata updates cannot write status. Status, materials, and readiness grant no
@@ -92,7 +105,7 @@ done; successors are never changed automatically. Entering in_progress starts a
 new execution interval and clears completion; returning to todo clears both
 endpoints. In_progress to done retains the nullable start and records completion.
 Todo to done records only completion, with unknown duration. Same-status and
-metadata updates preserve timing. State changes provide no process ownership,
+metadata updates preserve timing. Ordinary status changes provide no process ownership,
 release, transfer, stop, or lease semantics. The Web confirms every status choice,
 including the current status; cancel and Escape submit no request.
 
@@ -191,6 +204,25 @@ for verified prerequisites owned by another chain. Confirm task content and
 ownership; done status, a similar title, current graph roots or the displayed
 component do not establish the classification.
 
+### Dependency reduction
+
+When creating tasks or registering a Goal breakdown, keep only necessary direct
+prerequisites. Read the relevant dependency paths before writing. In
+`A → B → C`, arrows run from prerequisite to successor: C declares B, not both A
+and B. Omit `A → C` because the retained path already supplies A. Keep independent
+prerequisites that have no alternative path.
+
+An ordinary edge is redundant only when another path made entirely of ordinary
+edges supplies the same prerequisite; this preserves chain ownership and the
+Goal's ordinary design gate. An external edge may be supplied by an alternative
+path containing either kind. Preserve the classification of every retained edge.
+Check the retained graph as a whole, and read it back after registration to verify
+that required paths remain and no redundant direct edges were added. Source
+references do not require additional execution dependencies. This registration
+rule does not authorize cleanup of unrelated existing relationships.
+
+### Relationship and content writes
+
 **CLI relationship replacement.** `--depends-on` declares ordinary prerequisites;
 `--external-depends-on` declares external ones. Supplying either option compiles
 their full union as `dependsOn` and the exact external set as `externalDependsOn`.
@@ -248,11 +280,10 @@ create, establish identity from complete fields and operation context; a matchin
 title or an empty lookup alone is insufficient. Preserve actual errors and
 resource IDs rather than reporting success or blindly resending a write.
 
-Task registration, execution, selection, and requested handoff follow
-[create-task](create-task.md), [run-task](run-task.md), [autopilot](autopilot.md),
-and [handoff](handoff.md), respectively. For a chain of independently tracked
-delivery stages, use [the Goal protocol](goal.md).
-Every stage and delivery task follows the same todo/in_progress/done contract.
-A fixed Goal queue may use existing scoped execution authorization for its ready
-successors; registration and discussion confirmation grant no delivery execution
-permission.
+Task registration, ordinary execution, and requested handoff follow
+[create-task](create-task.md), [run-task](run-task.md), and [handoff](handoff.md),
+respectively. For a chain of independently tracked delivery stages, use
+[the Goal protocol](goal.md). Every stage and delivery task follows the same
+todo/in_progress/done contract. Registration and discussion confirmation grant
+no delivery execution permission. Each execution remains on its specified task;
+listing ready work does not select or start it.

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

@@ -8,7 +8,7 @@ not authorize permission changes. Read [the handbook](handbook.md) for CLI
 operations and [the task content standard](task-content.md) for sufficiency.
 
 Handoff ends after review, any authorized permission update, and reconciliation.
-It does not start this session's run-task or autopilot, change status,
+It does not start this session's task execution, change status,
 dependencies or platform, or grant independent implementation, merge, mainline
 push, deployment, or external-communication authority. Existing execution and
 delivery authorization remains applicable to later scheduling.

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

@@ -2,174 +2,65 @@
 
 Execute exactly one specified task ID within the user's authorized scope. Read
 [the handbook](handbook.md) for CLI operations, data semantics, and failures.
-This mode owns execution and completion; it returns without choosing a successor
-or activating autopilot. An explicit user-directed requirements-to-solution
-discussion transition follows the Goal protocol after current-task completion;
-it is not automatic backlog selection.
+This mode owns the ordinary task lifecycle. It returns without choosing a
+successor, except for the explicit user-directed requirements-to-solution
+transition under [the Goal protocol](goal.md).
 
-## Establish the task and stage
+## Establish the task
 
-Read the complete task with `daynight task show <task-id> --json`. Its Markdown
-description must identify the concrete current work, responsibility, and content
-sources. Read it and its actual required references under
-[the task content standard](task-content.md), including the solution, acceptance
-criteria, and explicit task-owned confirmation/evidence location. Complete inline
-content needs no primary attachment; document-owned and mixed organization are
-valid when the combined contents satisfy the same six requirements.
-Resolve description-relative links and images from the current task's attachment
-root; links inside a Markdown attachment use its own directory. Resolve real
-shared input references using the owning task ID and description/sections,
-complete paths for actual attachments, or a verified immutable repository
-reference. Read source descriptions through `task show --json` and actual
-attachment contents through the attachment commands; a task read does not load
-attachment inventory or bytes.
+Read the complete task with `daynight task show <task-id> --json`. Preserve the
+requested task ID through recovery and waiting. Read and apply
+[shared task execution](task-execution.md) for its required inputs,
+prerequisites, confirmed scope, work, evidence, and acceptance.
 
-For a Goal stage or delivery task, read [the Goal protocol](goal.md) and identify
-its role from the actual task content and context. Apply that stage's input and
-output requirements. Requirements and solution discussions start from their stage briefs;
-the completed requirements, applicable UI prototype, and architecture are outputs
-of the stages that produce them. Delivery tasks require the delivered design and
-applicable prototype. Before implementation, read every required architecture
-source listed in the delivery task's description: the owning architecture task's
-inline description and applicable sections, full paths for actual attachment
-documents, or verified immutable repository references. This also applies when
-the architecture task is only an indirect prerequisite. Confirm the
-description's references satisfy the Goal protocol. When a prototype is a required
-input, view and exercise it with its resources. An unfinished output of the current
-stage is not a missing input.
-
-An explicitly user-selected task may use the manual execution path regardless of
-`allowAgents` or platform compatibility; a fixed queue explicitly selected by the
-user has the same manual path. These conditions gate automatic selection, not
-explicit assignment. Automated task selection requires true and must not enable
-the flag itself. An automatically selected ID passed here remains automatic
-selection, even though run-task receives a concrete ID. Carry its actual runtime
-platform from autopilot and wait if unsupported or unknown. Immediately before
-setting in_progress, reread the full task and recheck `todo`, ready,
-`allowAgents=true`, and `requiredPlatform` either null or equal to that same actual
-platform. A changed or incompatible requirement prevents starting and requires a
-new selection decision; a changed execution environment requires fresh runtime
-identification and candidate queries. Use the exact version from this full-task
-recheck with `--if-version`; an earlier candidate page does not authorize the
-manual exception after automatic eligibility changes.
-
-Check state, every direct prerequisite, authorized scope, and required stage
-inputs. Read `dependsOn` and its `externalDependsOn` subset: ordinary edges
-express same-chain prerequisites, external marks distinguish verified cross-chain
-ownership. Both kinds must be done before entering in_progress or done. Classification
-never grants permission to execute a prerequisite, enable automatic
-execution, or remove a blocker.
-Missing required content, an unreadable required source, or a missing required
-architecture reference or input leaves execution unready. Resolve it within
-existing authorization or return the concrete issue. Do not infer requirements
-from a title or silently invent acceptance criteria. Do not execute prerequisites
-as an implicit expansion of the requested task.
+An explicitly user-selected task may use this execution path regardless of
+`allowAgents` or platform compatibility. These conditions gate automatic worker
+selection, not an explicit task assignment. They do not remove dependencies,
+stage inputs, or execution and delivery authorization. This mode does not select
+candidates or automatically advance a fixed task queue.
 
 Creation leaves a task `todo` and does not execute it. An explicit request to
 start the current Goal discussion, or the user-directed transition that starts
-solution discussion, authorizes entering in_progress for that discussion under
+solution discussion, authorizes entering `in_progress` for that discussion under
 the Goal protocol; registration alone does not. Existing execution authorization
-may cover the stated task or fixed Goal queue and its ready successors. Task
-status never expands implementation or delivery authorization.
-
-For ready `todo`, begin only when dependencies are done, required stage inputs are complete
-and the work is authorized. Use `task set-status <task-id> in_progress` with the exact version observed for
-that decision and confirm in_progress before starting. A stale version or
-changed prerequisite requires rereading and reconsidering, with no automatic
-mutation retry. For `in_progress`, recover existing work and coordinate using the
-project's established mechanisms; the state is not an assignee lock or lease.
-A task already `done` is reported as such unless reopening is within the explicit requested scope; use the same versioned status setter and dependency protection.
-Preserve the requested task ID through recovery and waiting.
-
-## Execute and maintain continuity
-
-Before analysis, questions, or proposals, establish this task's confirmed scope
-and acceptance criteria and apply the [shared scope constraint](../SKILL.md#shared-constraints)
-to execution and discussion.
-
-Identify [final acceptance](../SKILL.md#final-acceptance) from the task's confirmed
-outcome before applying a development or PR delivery lifecycle. Read the complete
-requirements and actual deliveries for the task or Goal being assessed, and apply
-the shared rule to verification methods, temporary helpers, and result ownership.
-
-Follow the target repository's instructions for worktrees, implementation,
-review, validation, and delivery. Use the task's stage-appropriate solution and
-acceptance criteria, including applicable final-style prototype interactions.
-Requirements discussion defines the problem without architecture decisions or
-production implementation. Only user-confirmed requirements and direction to
-continue permit completing that discussion and starting solution discussion.
-Solution discussion keeps the draft architecture and breakdown in its owning
-task. Only explicit user confirmation of the current solution permits registering
-and verifying the actual delivery tasks. Do not start delivery from either
-discussion. Keep the discussion in_progress while its user-confirmation gate is
-unmet; a material revision after confirmation needs renewed user confirmation.
-
-Resolve material changes to the agreed solution or acceptance within the current
-authorization. Rewrite the owning artifact and affected task summaries and input
-references coherently. Preserve requirements; do not silently weaken acceptance.
-Descriptions remain self-contained Markdown task summaries. Preserve valid
-syntax, original content, and actual resource references during full-field
-updates; confirm new or replaced resources before linking them. Dependency edits
-must follow the handbook's CLI replacement contract: read full D/E, retain needed
-ordinary D−E and external E declarations, submit their intended complete sets
-with the observed version, and read back both. Omit all dependency options for
-unrelated metadata updates. Keep detailed content at its identified owner and
-confirmations and evidence at their explicit task-owned location; shared inputs
-remain at their verified source.
-
-Advance only this task. Subagents collaborate on it, and waiting for CI, review,
-approval, or merge remains part of it. Keep all required delivery PR URLs and
-titles in the complete `properties.pullRequests` list, preserving existing
-entries. Record acceptance results and necessary delivery evidence, including
-merge commits, at this task's identified evidence location against the
-corresponding acceptance criteria.
-Rewrite current evidence coherently rather than accumulating an execution log.
-Keep operational progress, blockers, waiting items, and next action in the
-conversation or existing execution checkpoint, retaining the task ID and needed
-PR and workspace references.
-
-## Confirm completion or return waiting
-
-Goal requirements and solution discussion tasks use the user-confirmed material
-and stage acceptance in the Goal protocol. A generic repository PR rule does not
-add a PR-merge prerequisite to these Daynight discussions. If particular
-repository artifacts or PR delivery are explicitly part of that discussion
-task's acceptance, honor that requirement under the delivery rules below.
-Unconfirmed discussion material keeps its discussion task in_progress.
-
-Development tasks and design or documentation delivery tasks with PRs remain
-`in_progress` until the hosting platform confirms **every necessary delivery PR
-is merged** and all stage acceptance criteria are satisfied. Code completion,
-passing CI, approved review, and an open PR do not satisfy this condition. Verify
-actual merge state through the host's native client or API; do not assume a
-particular host.
-
-Completion rules grant no merge, deployment, external communication, or mainline
-push permission. Follow existing authorization without asking again for actions
-it covers. If the user requests an open PR for review or forbids merging, deliver
-the reviewable PR, preserve `in_progress` and the waiting checkpoint, and return
-its URL and required user action. Do not enable auto-merge. Missing permission,
-unavailable merge visibility, or an unmet merge check likewise keeps completion
-pending and successors blocked.
-
-For tasks without a development or PR delivery path, use their stated stage
-acceptance. For [final acceptance](../SKILL.md#final-acceptance), also apply the
-shared whole-task or whole-Goal completion rule. In every case, confirm required
-evidence is recorded and readable, then reread the complete in-progress
-task and use `task set-status <task-id> done` with its exact
-observed version. For Goal discussions, use their confirmation gates and verified
-accepted materials; for delivery tasks, use their acceptance and required authorized PR
-merges.
-Only service confirmation establishes the status update; reconcile uncertain
-results before reporting success. A Goal requirements discussion task's completion
-means requirements are confirmed; solution discussion completion means the user-confirmed solution and
-actual verified breakdown are delivered. Neither establishes whole-Goal completion.
-
-Continue ordinary CI and review waits as this task. When progress requires
-external intervention, preserve the target, actual state, concrete blocker,
-existing work, and next action in the checkpoint, then return the waiting result.
-Unstarted work stays `todo`; active work stays `in_progress`. Do not declare
-completion or select other work to bypass a wait. After completion, return
-without selecting a successor, except for an explicit user-directed discussion
-transition under the Goal protocol. That transition does not activate autopilot
-or authorize delivery. Whole-Goal acceptance follows the Goal protocol.
+remains limited to its stated scope. Task status never expands implementation
+or delivery authorization.
+
+## Start or resume the task
+
+For ready `todo`, begin only when dependencies are done, required stage inputs
+are complete, and the work is authorized. Use
+`task set-status <task-id> in_progress --if-version <observed-version>` with the
+exact version observed for that decision and confirm `in_progress` before
+starting. A stale version or changed prerequisite requires rereading and
+reconsidering, with no automatic mutation retry.
+
+For `in_progress`, recover existing work and coordinate using the project's
+established mechanisms; the state is not an assignee lock or lease. A task
+already `done` is reported as such unless reopening is within the explicit
+requested scope. An authorized reopening uses the same versioned status setter
+and dependency protection.
+
+Perform the authorized work and establish acceptance readiness under
+[shared task execution](task-execution.md). Starting a task is not evidence that
+its delivery or acceptance is complete.
+
+## Complete or return waiting
+
+When all task acceptance and delivery conditions are satisfied and its evidence
+is readable, reread the complete in-progress task and use
+`task set-status <task-id> done --if-version <observed-version>` with its exact
+observed version. Only service confirmation establishes the status update;
+reconcile uncertain results before reporting success. Do not replay an
+unconfirmed mutation automatically.
+
+For Goal discussions, completion follows the confirmation gates and accepted
+materials in the Goal protocol. After requirements completion is confirmed, an
+explicit user direction can start the specified solution discussion under that
+protocol. It grants no automatic successor selection or delivery authorization.
+Whole-Goal acceptance follows the Goal protocol.
+
+Otherwise return after this task completes or needs external intervention.
+Unstarted work stays `todo`; active work stays `in_progress`. Keep the target and
+waiting checkpoint when necessary PR merges, human confirmation, permission, or
+acceptance remain pending; do not select another task to bypass the wait.

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

@@ -94,10 +94,12 @@ For example, an upload protocol may define a required multipart `file`, a
 that permits user-initiated retry. Provider and consumer tasks reference the same
 protocol and state their own delivery locations and availability.
 
-Actual prerequisites remain in the complete `dependsOn` set and its
-`externalDependsOn` subset. Contract source identities do not form a second
-complete dependency list, and a source reference does not create an execution
-dependency. Use [the handbook](handbook.md) for relationship semantics.
+Necessary direct prerequisites remain in the complete `dependsOn` set and its
+`externalDependsOn` subset, following
+[the handbook's dependency reduction rule](handbook.md#dependency-reduction).
+Contract source identities do not form a second complete dependency list, and a
+source reference does not create an execution dependency. Use
+[the handbook](handbook.md) for relationship semantics.
 
 ## Apply the current stage
 

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

@@ -0,0 +1,136 @@
+# Shared task execution
+
+Read this reference after the selected execution mode establishes the task's
+identity. It owns required inputs, authorized work, delivery, evidence, and
+acceptance readiness. The execution mode owns starting or resuming the task,
+its final status operation, and returning to its caller.
+
+## Read the task and stage inputs
+
+Read the complete task and its actual required references under
+[the task content standard](task-content.md), including the solution, acceptance
+criteria, and explicit task-owned confirmation/evidence location. Its Markdown
+description must identify the concrete current work, responsibility, and content
+sources. Complete inline content needs no primary attachment; document-owned
+and mixed organization are valid when their combined contents satisfy the same
+six requirements.
+
+Resolve description-relative links and images from the current task's attachment
+root; links inside a Markdown attachment use its own directory. Resolve real
+shared input references using the owning task ID and description/sections,
+complete paths for actual attachments, or a verified immutable repository
+reference. Read source descriptions through `task show --json` and actual
+attachment contents through the attachment commands; a task read does not load
+attachment inventory or bytes.
+
+For a Goal stage or delivery task, read [the Goal protocol](goal.md) and identify
+its role from the actual task content and context. Apply that stage's input and
+output requirements. Requirements and solution discussions start from their
+stage briefs; the completed requirements, applicable UI prototype, and
+architecture are outputs of the stages that produce them. Delivery tasks
+require the delivered design and applicable prototype. Before implementation,
+read every required architecture source listed in the delivery task's
+description: the owning architecture task's inline description and applicable
+sections, full paths for actual attachment documents, or verified immutable
+repository references. This also applies when the architecture task is only an
+indirect prerequisite. Confirm that the description's references satisfy the
+Goal protocol. When a prototype is a required input, view and exercise it with
+its resources. An unfinished output of the current stage is not a missing input.
+
+## Verify prerequisites and scope
+
+Check state, every direct prerequisite, authorized scope, and required stage
+inputs. Read `dependsOn` and its `externalDependsOn` subset: ordinary edges
+express same-chain prerequisites, and external marks distinguish verified
+cross-chain ownership. Both kinds must be done before starting or completing
+work. Classification never grants permission to execute a prerequisite, enable
+automatic execution, or remove a blocker.
+
+Missing required content, an unreadable required source, or a missing required
+architecture reference or input leaves execution unready. Resolve it within
+existing authorization or return the concrete issue. Do not infer requirements
+from a title or silently invent acceptance criteria. Do not execute prerequisites
+as an implicit expansion of the requested task.
+
+Before analysis, questions, or proposals, establish this task's confirmed scope
+and acceptance criteria and apply the [shared scope constraint](../SKILL.md#shared-constraints)
+to execution and discussion.
+
+## Execute and maintain continuity
+
+Identify [final acceptance](../SKILL.md#final-acceptance) from the task's confirmed
+outcome before applying a development or PR delivery lifecycle. Read the complete
+requirements and actual deliveries for the task or Goal being assessed, and
+apply the shared rule to verification methods, temporary helpers, and result
+ownership.
+
+Follow the target repository's instructions for worktrees, implementation,
+review, validation, and delivery. Use the task's stage-appropriate solution and
+acceptance criteria, including applicable final-style prototype interactions.
+Requirements discussion defines the problem without architecture decisions or
+production implementation. Solution discussion keeps its draft architecture and
+breakdown in its owning task. Preserve the Goal's user-confirmation gates:
+completed text, a review result, or successful checks cannot replace the user's
+confirmation or authorize delivery. Keep an unconfirmed discussion in progress;
+a material revision after confirmation needs renewed user confirmation.
+
+Resolve material changes to the agreed solution or acceptance within the current
+authorization. Rewrite the owning artifact and affected task summaries and input
+references coherently. Preserve requirements; do not silently weaken acceptance.
+Descriptions remain self-contained Markdown task summaries. Preserve valid
+syntax, original content, and actual resource references during full-field
+updates; confirm new or replaced resources before linking them. Dependency edits
+must follow the handbook's CLI replacement contract: read full D/E, retain needed
+ordinary D−E and external E declarations, submit their intended complete sets
+with the observed version, and read back both. Omit all dependency options for
+unrelated metadata updates. Keep detailed content at its identified owner and
+confirmations and evidence at their explicit task-owned location; shared inputs
+remain at their verified source.
+
+Advance only this task. Subagents collaborate on it, and waiting for CI, review,
+approval, or merge remains part of it. Keep all required delivery PR URLs and
+titles in the complete `properties.pullRequests` list, preserving existing
+entries. Record acceptance results and necessary delivery evidence, including
+merge commits, at this task's identified evidence location against the
+corresponding acceptance criteria. Rewrite current evidence coherently rather
+than accumulating an execution log. Keep operational progress, blockers, waiting
+items, and next action in the conversation or existing execution checkpoint,
+retaining the task ID and needed PR and workspace references.
+
+## Confirm acceptance readiness
+
+Goal requirements and solution discussion tasks use the user-confirmed material
+and stage acceptance in the Goal protocol. A generic repository PR rule does not
+add a PR-merge prerequisite to these Daynight discussions. If particular
+repository artifacts or PR delivery are explicitly part of that discussion
+task's acceptance, honor that requirement under its delivery rules.
+Unconfirmed discussion material keeps its discussion task in progress.
+
+Development tasks and design or documentation delivery tasks with PRs remain
+in progress until the hosting platform confirms **every necessary delivery PR
+is merged** and all stage acceptance criteria are satisfied. Code completion,
+passing CI, approved review, and an open PR do not satisfy this condition. Verify
+actual merge state through the host's native client or API; do not assume a
+particular host.
+
+Completion rules grant no merge, deployment, external communication, or mainline
+push permission. Follow existing authorization without asking again for actions
+it covers. If the user requests an open PR for review or forbids merging, deliver
+the reviewable PR and preserve the waiting checkpoint. Do not enable auto-merge.
+Missing permission, unavailable merge visibility, or an unmet merge check keeps
+completion pending and successors blocked.
+
+For tasks without a development or PR delivery path, use their stated stage
+acceptance. For [final acceptance](../SKILL.md#final-acceptance), also apply the
+shared whole-task or whole-Goal completion rule. In every case, confirm required
+evidence is recorded and readable before returning to the execution mode's
+completion operation. Discussion completion establishes that stage's accepted
+output; it does not establish whole-Goal completion.
+
+## Preserve waiting context
+
+Continue CI and review waits as this task. When progress requires external
+intervention, preserve the target, actual state, concrete blocker, existing work,
+and next action in the checkpoint, then return the waiting result through the
+selected execution mode. Do not declare completion or select other work to
+bypass a wait. Preserve the task ID through recovery and waiting.