@codetreker/daynight 0.25.4 → 0.27.2

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).

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

@@ -1,262 +1,65 @@
 # Goal protocol
 
-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 task definitions
-and results, [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.
+A Goal expresses a multi-stage objective through ordinary tasks, attachments, dependencies, and PR properties without adding resources, commands, or statuses.
+Follow [create task](create-task.md) for creation, the [task content standard](task-content.md) for material, and [authorization and scope](authorization.md) for operational permissions.
+This file covers only stage progression and Goal-specific requirements.
 
-## Identify the current discussion
+## Stages and confirmation
 
-Use a Goal when a concrete outcome needs requirements discussion, solution or
-architecture discussion, and actual delivery work. Independently understandable
-features, bug fixes, architecture/design assignments, and real breakdown items
-are tasks. Agent-generated commands, file reads, and routine checks stay in the
-session's execution plan, not task descriptions or attachments.
+| Stage | Starting content | Results and completion gate |
+| --- | --- | --- |
+| Requirements discussion | Known problem, expected outcome, scope, constraints, open questions, and completion conditions | Complete requirements and applicable interactive prototypes; the user explicitly confirms the current requirements and directs progression to solution discussion. |
+| Solution discussion | Confirmed requirements and applicable prototypes, design questions, and completion conditions | Architecture, key decisions, and breakdown; the user confirms the solution, and actual delivery tasks have been registered and read back. |
+| Delivery tasks | Defined responsibilities, required designs and prototypes, contracts, and acceptance criteria | Actual results meeting the [shared delivery conditions](task-execution.md#completion-conditions). |
+| Final acceptance | Complete confirmed requirements, actual combined results, and acceptance criteria | A conclusion for the whole Goal under [final acceptance](final-acceptance.md). |
 
-Permission to create a Goal covers its requirements discussion, the later solution
-discussion, and the confirmed in-scope delivery breakdown. Create each only at
-its stage below. Reuse suitable existing tasks after reading their full problem,
-scope, materials, acceptance, and actual context; a title alone is not identity.
-An explicit user or applicable repository tracking/review instruction supplies
-standing creation permission within the confirmed scope. It grants no unrelated
-work, implementation, external communication, deployment, merge, or mainline push
-permission.
+Discussions remain `in_progress` without user confirmation; completed prose, agent confidence, successful reviews, and passing CI cannot replace confirmation.
+Substantive revisions after confirmation require renewed confirmation.
+Discussion acceptance does not automatically add repository PR merge requirements; only repository artifacts or PR delivery explicitly included in that task are subject to the corresponding delivery conditions.
 
-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.
-Goal registration alone does not supply discussion-start or delivery execution
-authorization.
+## From requirements to solution
 
-## Start requirements discussion
+First create or reuse the single requirements-discussion task, titled `[Goal]<outcome>`.
+Register only the current stage; do not create architecture placeholders or delivery items in advance.
+Return for registration-only requests; when explicitly asked to start the discussion, start or resume through [ordinary execution](run-task.md).
 
-Create or reuse only the requirements discussion task, titled `[Goal]<outcome>`.
-The marker is followed directly by the outcome. Do not create an architecture
-placeholder or delivery tasks at this point. Give the task a self-contained Markdown description
-for the known problem, intended outcome, scope, constraints, open
-questions, and observable completion conditions under the shared content
-standard. Include the intended requirements and applicable prototype deliverables
-and the required human-confirmation completion condition. Finished requirements
-and prototypes are outputs, not prerequisites to starting; the session holds the
-discussion plan and process.
+Requirements discussion defines the problem and behavior without deciding architecture or implementing production code.
+This stage produces applicable interactive prototypes for UI Goals under the [prototype requirements for task creation](create-task.md#prepare-content).
+Save and read back current artifacts under the authorization rules before requesting review.
 
-Each task starts in `todo`. For an explicit discussion-start request, read its
-current materials and exact version, use `task set-status <task-id> in_progress`
-with the version observed for that decision and confirm `in_progress`.
-All direct prerequisites must be done. Preserve real external blockers rather
-than removing dependencies to make a discussion ready. An already in-progress
-task is resumed after checking its actual work and context.
+After the user confirms requirements and directs progression to solution discussion, save the accepted requirements, complete the requirements task and verify it is done, then create or reuse the solution-discussion task.
+Use the requirements task as an ordinary prerequisite, prepare the stage brief, and start through ordinary execution.
+If completion is uncertain, reconcile it first; do not create the next stage in advance.
 
-Discuss requirements with the user: the whole problem, desired behavior, scope,
-constraints, exclusions, and whole-Goal acceptance. Keep current material and open
-questions in this task's description or attachments. The description remains a
-task-specific brief and source entrypoint; detailed requirements have one owner.
-Before requesting user review, save the complete current requirements artifact,
-read it back, and provide the task and resource reference. Keep discussion,
-validation, and confirmation processes in the session.
+Solution discussion explains responsibilities, data flow, control flow, interfaces, error behavior, key decisions, verification, and the proposed breakdown.
+Keep the current solution and breakdown in this stage's own material; do not register delivery items before confirmation.
+After the user confirms the solution, perform the registration checks below before completing the solution task.
 
-For a UI Goal, produce a final-style interactive frontend-only prototype with
-working relative resources and relevant populated, empty, loading, failure,
-disabled, long-content, and narrow-screen states. View and exercise it. Prototype
-code is a requirements artifact; this discussion does not implement production
-code or decide the architecture.
+## Register the delivery breakdown
 
-## Confirm requirements and start solution discussion
+The breakdown must collectively cover the confirmed Goal, with independent responsibilities, inputs, deliverables, and observable acceptance criteria for each task.
+Include acceptance in the breakdown when it has an independent result; do not substitute vague placeholders or session execution steps for actual work.
 
-Keep the requirements task `in_progress` until the user explicitly confirms the
-current requirements and directs the next discussion, for example, "Requirements
-are settled; move to architecture discussion." Agent confidence, completed text,
-a review result, or elapsed time does not satisfy this gate.
+Every root delivery task without another ordinary implementation prerequisite must directly depend on the solution task through an ordinary dependency, so all delivery paths inherit the confirmed design's completion conditions.
+Verify cross-chain dependencies and follow [classification and reduction](task-management.md#dependency-classification); external prerequisites cannot replace ordinary design prerequisites.
 
-Keep the accepted requirements and their effective state in the owning task and
-verify they are readable. Preserve the actual confirmation and transition
-authorization in the session. A material revision after confirmation requires
-renewed user confirmation before advancement. When the discussion's acceptance
-is met,
-reread the task, use `task set-status <task-id> done` with its observed version, and confirm done.
-Do not create the solution discussion until that completion is confirmed; reconcile
-an uncertain completion before another mutation.
+**Every delivery task's description must directly identify the architecture task ID and all required architecture source locations, including for indirect successors.**
+Identify the description and applicable sections for inline architecture, list full paths for actual attachments, and retain the owning task ID and verified immutable references for repository sources.
+An index only in an upstream task or inside an attachment is insufficient.
+Read actual sources under the content standard; do not invent attachments or copy the full set of shared material.
 
-Then create or reuse the solution discussion task, with a purpose-specific title
-such as `Architecture discussion: <outcome>`, and an ordinary prerequisite on the
-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 is available to ordinary
-execution only; it does not authorize selection of another unrelated task.
+For example, in `architecture -> A -> B`, B declares only A as a direct dependency and inherits the architecture prerequisite through A, but B's description still directly lists the required architecture sources.
+Source indexes do not create additional execution dependencies.
 
-## Execute the appropriate stage
+Read back every delivery task and its required inputs, checking responsibility coverage, architecture indexes, and source readability.
+Check dependencies through [post-change verification](task-management.md#verify-dependency-changes).
+Keep the solution task in progress while gaps remain; recover partial registration under [write safety](write-safety.md).
+Registration and solution completion do not start delivery or enable automatic-execution permission.
 
-During solution discussion, consume the confirmed requirements and applicable
-prototype. Discuss how to achieve the outcome: responsibilities, data and control
-flow, interfaces, error behavior, key decisions, verification, and the proposed
-breakdown. The solution task owns the current architecture, proposal, and draft
-breakdown. Keep these current artifacts accessible in its description or
-attachments, verify them before user review, and synchronize accepted decisions
-and necessary rationale. The discussion plan, review handling, and confirmation
-process remain in the session.
-Do not register delivery subtasks before the user confirms the current solution.
+## Whole-Goal completion
 
-A discussion task completes from user-confirmed Daynight material and its stated
-stage acceptance. Repository document/code delivery still follows normal PR and
-merge rules, but a generic repository PR rule does not add a merge prerequisite
-to a Daynight discussion. If the user explicitly makes particular repository
-artifacts or PR delivery part of that discussion's acceptance, honor that
-requirement and its delivery permissions. An unresolved user review keeps the
-current discussion `in_progress`. Successful CI or a design review cannot replace
-the user's confirmation.
+Complete each task through the selected execution workflow; reading the Goal protocol does not change the return boundaries of ordinary or managed workflows.
+A single done task, an empty ready page, completed requirements, or a completed solution does not mean the whole Goal has been delivered.
 
-After explicit user confirmation of the current solution, keep the accepted
-solution and its effective state in the owning task, preserve the confirmation
-in the session, and register the delivery breakdown below. Complete
-the solution discussion only after the accepted solution and actual registered delivery tasks,
-their required materials, and their dependencies are read back
-and verified. Use `task set-status <task-id> done` with the observed version and confirm done.
-Completion satisfies dependencies and grants no delivery execution permission. Completing
-either discussion does not establish whole-Goal completion.
-
-## Register the confirmed delivery breakdown
-
-Only after user solution confirmation, create or reuse the concrete delivery tasks
-needed for the agreed outcome. Each description and its actual references must
-satisfy the task content standard, including task-specific responsibility,
-actual required inputs, deliverables and contracts, and observable acceptance.
-Include independently scoped acceptance work when it has its own outcome. A
-[final-acceptance](../SKILL.md#final-acceptance) brief
-identifies the original whole-Goal requirements and confirmed changes, and assesses
-the combined delivery under the shared rule. Do not turn agent-generated execution
-steps into tasks. The combined scope must cover the confirmed Goal, rather than a
-vague placeholder.
-
-Create new delivery tasks in `todo`. Solution confirmation authorizes the
-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
-execution authorization or advance the discussion gate.
-
-Use ordinary dependencies for real within-Goal prerequisites. Every delivery root
-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. 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
-solution task. Consumers reference the owning task ID and the source description
-with applicable sections for inline content, full paths for actual attachments,
-or immutable repository sources. Use `task show --json` for source descriptions
-and the attachment commands for actual attachment contents. Every delivery
-task's description must directly list the architecture task ID and all required
-architecture source locations: description and applicable sections for inline
-design, full paths under the source task for each actual required attachment
-document, and verified immutable repository references for repository documents.
-Do not fabricate an attachment path or copy or relocate inline architecture to
-fit this index. This applies to indirect successors as well as delivery roots;
-a reference only in another task or inside an attachment is insufficient.
-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. 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 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
-## Objective and scope
-Implement upload retry controls using the delivered upload API. Preserve the
-selected files and show the confirmed error-specific retry actions.
-
-## Completion conditions
-Retryable failures offer retry; permanent failures explain the required action.
-Successful retry clears the error without losing the selected files.
-
-## Architecture inputs
-Architecture task: `11111111-1111-4111-8111-111111111111`.
-Read these attachments from that task before implementation:
-
-- `design/architecture.md`: upload flow and component responsibilities.
-- `design/upload-errors.md`: error classification and retry behavior.
-
-## Deliverable
-Upload retry controls in the existing upload UI, using the API's error contract;
-no additional task-to-task exchange is introduced.
-```
-
-When the shared architecture is inline, the architecture inputs instead identify
-the same source task ID and its description sections, such as "Upload flow" and
-"Error classification". Read those sections with `task show --json`; list full
-paths only for actual attachment documents that are also required.
-
-## Preserve ownership and recover partial registration
-
-Stage briefs describe the work to produce the stage's outputs; they do not claim
-unfinished results exist. Every stage and delivery task provides a task-specific
-Markdown brief and the complete applicable content, directly or through verified
-references. Complete inline content needs no primary attachment. Save produced
-results at their actual owner and make them discoverable from the task. Keep
-shared inputs at their actual owner. Do not distribute a duplicate whole packet
-to every task. An independently
-needed snapshot records its purpose, original source, and source revision or
-content identity. Existing attachment reads support these references; do not
-invent a URL scheme, cross-task relative links, or fixed service host.
-
-Creation, uploads, metadata changes, and lifecycle actions are independent writes.
-Retain confirmed IDs and resume missing operations after partial success. Read
-actual task fields and attachment contents before retrying an uncertain write;
-a matching title or lost response does not establish success or failure. If the
-identity cannot be established uniquely, preserve the failure and information
-needed to reconcile it rather than creating a duplicate chain.
-
-Bind metadata updates and status changes to the exact version
-observed for that decision. Attachment bytes have independent concurrency and
-must be verified separately; task versions cannot prove the reviewed content is
-unchanged. Generic updates cannot write status. A version conflict requires a
-new decision. Readiness and `in_progress` provide no ownership lock or lease.
-
-## Advance and accept the whole Goal
-
-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 task results. 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
-[Final acceptance](../SKILL.md#final-acceptance) to the combined delivery;
-completing or passing temporary helpers does not establish that the Goal is
-complete.
-
-The requirements task being done means only that requirements discussion is
-complete. The solution task being done means the confirmed solution and verified
-breakdown are delivered. An empty ready page or a single delivery result proves
-neither the whole outcome nor completion of all its work.
+Before reporting the whole Goal complete, verify the full confirmed scope, every delivery result, and the actual merge status of all required PRs, and perform final acceptance on the combined results.
+Discussion confirmation, registration, and prerequisite completion do not automatically select successor work.