@codetreker/daynight 0.8.17 → 0.9.1

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

@@ -1,23 +1,24 @@
 # Autopilot
 
 Enter this mode only when the user explicitly requests automatic execution of
-Daynight tasks. Use the confirmed goal and work scope. Loading the skill, a
-ready task, or a completed `run-task` does not activate autopilot. A bare
+Daynight tasks. Use the confirmed Goal or work scope. Loading the skill, a ready
+task, or a completed `run-task` does not activate autopilot. A bare
 `using-daynight` invocation can resume it only when the conversation establishes
 that the user already activated it.
 
-Read [the handbook](handbook.md) for discovery and query semantics. Delegate
-execution and completion to [run-task](run-task.md); do not maintain a separate
-delivery lifecycle here.
+Read [the handbook](handbook.md) for discovery and query semantics. For a Goal
+chain, read [the Goal protocol](goal.md) for stage requirements, breakdown, and
+whole-Goal acceptance. Delegate execution and completion to
+[run-task](run-task.md); do not maintain a separate delivery lifecycle here.
 
 ## Restore the current target
 
-Resume this session's current task before selecting new work. Read the task ID
-from the conversation or the project's existing execution checkpoint, then
-refresh it with `daynight task show <task-id> --json`. If identity is unknown,
-query `daynight task list --status in_progress --json` as needed and establish
-which task belongs to the current work. An arbitrary `in_progress` task is not
-automatically this session's target.
+Resume this session's current task before selecting new work. Read its ID from
+the conversation or existing execution checkpoint, then refresh it with
+`daynight task show <task-id> --json`. If identity is unknown, query
+`daynight task list --status in_progress --json` as needed and establish which
+task belongs to the current work. An arbitrary `in_progress` task is not
+this session's target.
 
 A waiting checkpoint retains its task until that task is confirmed done or the
 user explicitly changes the target. Resume the required next action when
@@ -31,41 +32,59 @@ When there is no current task, query:
 daynight task ready --json
 ```
 
-Pick exactly one ready `todo` task most relevant to the confirmed goal and
-authorized work. Compare problem, scope, solution, acceptance criteria, and
-dependencies; creation order does not establish relevance. Read full details
-and actual referenced attachments for plausible candidates before committing to
-a target. Readiness checks prerequisites, not required artifact completeness or
-execution authorization. Pass the selected task ID to `run-task`.
+Pick exactly one approved ready `todo` task most relevant to the confirmed Goal and
+authorized work. Compare concrete actions, scope, deliverables, solution,
+acceptance criteria, and actual dependencies; creation order does not establish
+relevance. Read full details and actual task-specific and shared inputs for
+plausible candidates before choosing. Readiness checks prerequisites, not stage
+artifact completeness or execution authorization. Pass the selected ID to
+`run-task`, which claims the version observed for that decision before starting.
+Autopilot never auto-approves proposed work. Goal creation, completed description
+or design, and permission to execute do not authorize task approval.
 
 Ready returns at most 10 candidates by default, or the requested bounded
 `--limit`; it is not a complete backlog. If this page is empty or no candidate
 matches, obtain the additional context actually needed through selected reads,
 the graph, or a complete filtered list as described in the handbook. Distinguish
-completed scope, remaining work blocked by prerequisites, other ongoing work,
-and insufficient candidates. Do not report the scope complete from an empty or
-unrelated bounded page, or take unrelated work to stay busy.
+completed scope, work awaiting explicit approval, prerequisite-blocked work, other
+ongoing work, and insufficient
+candidates. Do not take unrelated work to stay busy or report completion from an
+empty or unrelated bounded page.
 
 Autopilot permission covers execution of existing tasks, not creation of new
-ones. If the confirmed goal requires missing tracked work, obtain explicit task
-creation permission unless the user already granted it for that scope, then use
-[create-task](create-task.md). Its return does not itself start execution;
-selection and execution still follow this mode's rules.
+ones. If the confirmed Goal requires missing tracked work, use explicit creation
+permission already granted for that scope or obtain it, then use
+[create-task](create-task.md). Permission to create a Goal already covers both
+starting tasks and its later in-scope breakdown; do not ask again for each one.
+Creation leaves proposed tasks pending separate explicit approval and returns
+to this mode without starting execution. The design stage must
+actually register and verify the complete delivery breakdown before handing over
+its required PR; successor execution waits for design completion.
 
-## Advance serially
+## Advance serially and accept the scope
 
-Run one task at a time. Subagents collaborate on the same task; they do not each
-choose a separate task. Ordinary CI, review, and merge waits keep that target.
-After `run-task` confirms `done`, refresh readiness and select at most one next
-related task within the same authorized scope.
+Run one task at a time. Subagents collaborate on it; they do not each choose a
+separate task. Ordinary CI, review, and merge waits keep that target. After
+`run-task` confirms `done`, refresh readiness and select at most one next related
+task within the same authorized scope. Description completion permits design
+selection, and design completion permits delivery selection, only when the next
+task is approved ready todo, its stage inputs are complete, this mode is explicitly
+active and execution is authorized. Stage completion satisfies a dependency; it
+never approves a successor. Explicit scoped user approval may cover stated Goal
+tasks, but the Goal-creation permission itself does not.
 
 If `run-task` returns a wait requiring external intervention, preserve its
 current-task checkpoint and report the blocker and required next action. An
 explicit no-merge or user-review requirement is such a wait; it never permits
 auto-merge or marking the task done. Return without replacing the target.
 
+Before reporting a Goal complete, apply the Goal protocol's whole-Goal acceptance:
+verify the full registered scope, every delivery task's completion, all necessary
+PR merges, and the original overall acceptance evidence. A completed description
+or design is only a stage result. For other scopes, verify their confirmed
+completion conditions against the actual work.
+
 Stop when the confirmed scope is complete, the user requests a stop, or progress
-needs external intervention. Report the observed state and checkpoint; do not
-equate an absence of selectable tasks with complete delivery. Automatic task
-selection does not expand permission to merge, deploy, communicate externally,
-or push mainline.
+needs external intervention. Report observed results, remaining blockers, and
+the checkpoint. Automatic task selection does not expand permission to merge,
+deploy, communicate externally, or push mainline.

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

@@ -2,102 +2,157 @@
 
 Use this mode to prepare and register work that needs persistent tracking. Read
 [the handbook](handbook.md) before discovery, queries, or writes. Return after
-registration; creating a task does not authorize implementation or activate
-autopilot.
+registration; creating work does not authorize approval, execution or autopilot.
 
-Create a task only with the user's explicit permission to create tasks, whether
-requested directly or already granted for the relevant scope.
-Loading this mode, needing durable tracking, or having permission to implement
-or run autopilot does not grant creation permission. If it is missing, ask
-before creating a task; do not repeat a request already covered by explicit
-permission.
+Create tasks only with the user's explicit permission for the relevant scope.
+Loading this mode, needing durable tracking, or permission to implement or run
+autopilot does not grant creation permission. Ask when it is missing; reuse
+permission already granted for the scope.
 
-## Decide whether to register
+## Choose the tracked outcome
 
-One-off operations and trivial work do not need a task. Keep transient command
-steps in the existing execution plan. With creation permission, register an
-independently understandable outcome when its delivery needs continued tracking,
-cross-session continuity, handoff, or dependency coordination. If the request does not merit a task,
-explain that conclusion without creating one or starting unrequested work.
+One-off operations and trivial work do not need a task. Keep transient commands,
+tests, and execution steps in the existing plan. With creation permission,
+register an independently understandable outcome when delivery needs continued
+tracking, cross-session continuity, handoff, or dependency coordination. If the
+request does not merit a task, explain that conclusion and return.
 
-Look for an existing task that solves the same problem within the same scope,
-including completed tasks when checking prior registrations; the default list
-contains only unfinished work.
-Inspect its full description, dependencies, primary Markdown, and acceptance
-criteria; matching titles alone do not establish equivalence. Reuse a suitable
-task and preserve its valid requirements. Do not create another task because
-registration of a known task was interrupted.
+For multiple independently tracked delivery stages, follow
+[the Goal protocol](goal.md). Register its Goal description task and dependent
+architecture-and-breakdown placeholder together. Their own stage briefs are
+required at registration; the finished Goal, UI prototype, architecture, and
+breakdown are outputs of the stages that produce them. Creating a Goal covers
+both starting tasks and its later in-scope breakdown within the granted creation
+permission. Do not execute a stage in this mode.
 
-## Prepare the required artifacts
+For a single tracked outcome, prepare its solution, acceptance criteria, and
+applicable mock UI before registration, following the artifact rules below.
 
-Prepare the solution, acceptance criteria, and required mock UI before creating
-the task. Use the target repository's document and workspace rules.
+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, primary Markdown, 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.
+
+## Write task-specific content
+
+Use the target repository's document and workspace rules.
 
 | Content | Owner |
 |---|---|
-| Problem and actual attachment references | Task `description` |
-| Solution and acceptance criteria | One primary Markdown attachment |
-| Frontend visual and interaction design | Interactive mock UI attachment and its resources |
+| Concrete problem, current actions and scope, deliverables, constraints, completion summary, and real input references | Task `description` |
+| Detailed solution, full acceptance criteria, verification methods, and completion evidence | This task's primary Markdown attachment |
+| Applicable visual and interaction design | Owning task's interactive mock UI and resources, referenced by consumers |
 | Prerequisite tasks | `dependsOn` only |
 | Delivery PR URLs and titles | `properties.pullRequests` |
 
-Give the task an outcome-focused title. Its description explains what problem
-the task solves and why, then references the actual primary Markdown and, for
-frontend work, the mock UI. The primary Markdown must contain sections for
-**Solution** and **Acceptance criteria**, with equivalent headings in the task's
-language allowed. The solution defines the approach, scope, and necessary
-behavioral constraints. Acceptance criteria state observable completion
-conditions and how to verify them. Link any supporting resources from this
-primary document.
-
-For example, the Markdown may contain:
+Give each task an outcome-focused title and a self-contained Markdown
+description: a reader must understand what this specific task will do, deliver,
+and verify without opening attachments. Summarize the approach and observable
+completion conditions, then reference the real detailed sources. A generic
+problem sentence and a link list are insufficient. Keep the summary consistent
+with its primary Markdown without maintaining a second complete plan in the
+description.
+
+The primary Markdown must contain **Solution** and **Acceptance criteria**
+sections; equivalent headings in the task's language are valid. Define the
+current task's approach, scope, behavioral constraints, observable completion
+conditions, and how to verify them. Stage briefs describe the work that will
+produce that stage's results. They do not claim unfinished outputs already exist.
+Link supporting resources from the primary document.
+
+Attach only this task's detailed plan, needed resources, and outputs. Shared
+Goal requirements stay with the Goal description task; architecture and
+breakdown stay with the design task. Consumers identify the source task ID and
+attachment path and confirm the contents using the installed CLI's attachment
+read command. For repository inputs, use verified immutable references. Do not
+assume a `task://` scheme, cross-task relative links, or a fixed service host.
+Do not upload the same whole packet to every task. Create a separate snapshot
+only when the task needs an independent copy, recording 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 in `dependsOn` for real prerequisites. Do not add a
+Dependencies section or duplicate the dependency list in the description or
+Markdown. A top-level task has no dependencies. Repository specifications and
+design documents retain their full contracts; the task's own primary attachment
+must still provide a specific solution and verifiable acceptance criteria.
+
+## 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 source task ID and attachment path or immutable
+repository URL; a relative link cannot identify another task's attachment.
+
+For example, the following brief applies to a task whose confirmed, readable
+attachments include its own `plan.md` and the complete `mockui/index.html`
+prototype with its resources. Use these paths 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
-## Solution
+## 问题与行动
+登录失败后，用户无法判断是否可以重试。实现明确的失败原因和重试入口，保留当前登录表单输入。
 
-Provide state filters in the task list. The interactive design is the
-mock UI attachment at `../mockui/index.html`.
+## 范围与交付
+更新登录页的错误提示、重试交互和中英文文案；沿用现有认证接口与会话边界。
 
-## Acceptance criteria
+## 完成条件
+网络失败和凭据错误均显示对应提示；重试成功后进入工作区。桌面与窄屏、两种语言的交互通过验证，表单输入保持正确。
 
-- Selecting a state shows only matching tasks.
-- Clearing the filter restores the complete list.
-- Verify filtering, empty results, and narrow-screen interaction against the mock UI.
-```
+## 资料
 
-A frontend task requires a mock UI that runs interactively 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. Upload required CSS, JavaScript, images, and
-other resources with working relative references. A static sketch or simplified
-styling does not satisfy this requirement.
+- [方案与验收](plan.md)
+- [交互原型](mockui/index.html)
+```
 
-Express real prerequisites through `dependsOn`, using established task IDs. Do
-not add a Dependencies section or duplicate the dependency list in the
-description or Markdown. A top-level task simply has no dependencies. Repository
-specifications and design documents retain ownership of their full contracts;
-the primary attachment must still give the executor a clear solution and
-verifiable acceptance criteria.
+This remains a concise assignment. Its own primary Markdown still contains the
+specific **Solution** and **Acceptance criteria**, verification methods, and
+evidence. The prototype remains with its actual owner when shared across a Goal.
 
 ## Register and verify
 
-Reuse the established project and task when applicable. For a new task, create
-it in `todo` with its problem and actual dependencies, retaining the confirmed
-task ID. Upload the primary Markdown, frontend mock UI, and all required
-resources under that same ID. Add their actual paths to the complete task
-description using the observed task version. Do not present planned paths as
-confirmed uploads.
-
-Read back the complete task, attachment metadata, and required contents. Confirm
-that references resolve, the two required Markdown sections are present,
-dependencies match the intended prerequisites, and the frontend mock UI and its
-resources are available and work together. Registration is complete only after
-all required artifacts and their associations are confirmed readable.
-
-If creation succeeds but an upload or description update fails, preserve the
-task ID and resume registration on that task. It remains `todo`; there is no
-additional draft state. If a write result is uncertain, follow the handbook's
-reconciliation rules before another mutation. Report incomplete registration
-with the exact missing artifact or operation and next step. Do not inline the
-solution or acceptance criteria into the description to bypass an attachment
-failure.
+Reuse the established project and suitable tasks. Create new tasks in `proposed`,
+retaining each confirmed ID. Set their concrete descriptions and actual
+`dependsOn` prerequisites. Upload each task's own primary Markdown and required
+resources; add actual attachment 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 two required primary-document sections, real source
+identities, intended dependencies, and applicable mock UI resources and
+interaction. For a Goal, verify both starting tasks and their stage briefs.
+Registration is complete only when required artifacts and associations are
+confirmed readable. Without separate explicit approval authorization, leave
+registered work proposed and report that approval is pending. Goal-creation
+permission covers the two starting tasks and later in-scope breakdown, but never
+their approval. A user can explicitly approve a stated task or Goal-task scope,
+or approve directly through CLI/Web; an authorized Agent uses each reviewed
+task's exact version through `task approve`.
+
+If creation succeeds but a later operation fails, retain the confirmed IDs and
+resume missing operations there. Tasks remain `proposed`. Reconcile uncertain results through the handbook before another
+mutation. Report incomplete registration with the exact missing operation or
+artifact and next step. Do not move detailed plans into descriptions to bypass
+an attachment failure. Return after verified registration without selecting or
+executing a task.

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

@@ -0,0 +1,170 @@
+# Goal protocol
+
+Read this reference when creating a multi-stage Goal, running one of its tasks,
+or advancing its authorized scope. Use [create-task](create-task.md) for content
+and registration rules, [run-task](run-task.md) for one task's lifecycle, and
+[the handbook](handbook.md) for CLI semantics. A Goal uses existing tasks,
+attachments, `dependsOn`, and PR properties; it adds no CLI command, task type,
+status, or execution authority.
+
+## Identify and register a Goal
+
+Use a Goal when completing the request requires multiple independently tracked
+delivery stages. One independently tracked outcome remains a normal task;
+commands, tests, and temporary execution steps do not each need persistent tasks.
+The user need not use the word Goal.
+
+Explicit permission to create a Goal covers its two starting tasks and the later
+breakdown within that Goal. It covers no unrelated tasks and grants no execution,
+publication, deployment, external communication, merge, or mainline push
+permission. Existing explicit authorization continues to apply within its scope.
+Implementation or autopilot permission alone does not grant creation permission.
+Goal-creation permission does not authorize approval. Approve only tasks or a
+Goal-task scope explicitly approved by the user, using each reviewed task's exact
+version; CLI and Web approval are available. Goal creation, requirements/prototype
+completion, design completion and autopilot never imply that instruction. Approval
+itself grants no execution or delivery permission.
+
+During registration, create or reuse both starting tasks:
+
+| Task | Title | Initial content |
+|---|---|---|
+| Goal description | `[Goal]<outcome>` | The known overall problem, intended results, scope, constraints, UI applicability, exclusions, and observable acceptance summary; a stage brief for resolving open requirements and producing the complete Goal. |
+| Architecture design and task breakdown | `Architecture design and task breakdown: <outcome>` | Its concrete work: consume the completed Goal, design the architecture, register the complete delivery breakdown, verify its artifacts and dependencies, and deliver any required design PR. Its own stage brief defines the approach and acceptance. |
+
+The `[Goal]` marker is followed directly by the outcome. Goal description names
+the stage; it is not the title prefix. Titles communicate purpose but do not
+establish stable identity. Preserve confirmed IDs and inspect full content when
+reusing an existing chain.
+
+Set the design task's `dependsOn` to the Goal description task. Each task starts
+in `proposed` with its own self-contained Markdown description and primary Markdown
+containing Solution and Acceptance criteria. State unanswered questions honestly.
+Complete requirements, prototypes, architecture, and breakdown are produced by their
+respective stages; they are not prerequisites for registering the chain or
+starting the stage that produces them. Confirm both tasks, stage briefs,
+references, and dependency through real reads, then return from `create-task`.
+Registration completeness leaves approval pending unless the user separately
+authorized approval for those tasks. Metadata and attachment writes do not approve.
+
+## Execute the appropriate stage
+
+Every stage uses the same explicit task lifecycle. Proposed work waits for the
+user's scoped approval; an authorized `task approve` moves it to todo even with
+unfinished prerequisites. Begin only from approved ready todo with complete
+stage inputs and execution authorization: use `task claim` with the exact version
+observed for that decision and confirm in_progress. Resume existing in-progress
+work after checking its actual checkpoint. After the stage acceptance and every
+required authorized PR merge, reread and use `task complete` with the observed
+version. Completion satisfies dependencies but never approves the next stage.
+
+| Stage | Required inputs to start | Outputs and completion |
+|---|---|---|
+| Goal description | Its stage brief, current problem and scope, and available background. | Complete overall requirements, applicable final-style interactive UI prototype, verified stage acceptance, and repository-required delivery. Finishing this task completes problem definition. |
+| Architecture design and task breakdown | Completed Goal description, its full requirements and applicable prototype, and the design stage brief. | Complete architecture and the actual registered delivery tasks, verified task-specific artifacts and dependencies, satisfied stage acceptance, and platform-confirmed merge of every required design PR. |
+| Delivery task | Completed design prerequisite, delivered architecture, its own solution and acceptance criteria, and applicable prototype and resources. | This task's deliverable, verification, required review and PR merges, and readable acceptance evidence under the normal run-task rules. |
+
+### Goal description
+
+Explain the whole problem and why it matters, the final observable results,
+required behavior and constraints, scope, explicit exclusions, and how the whole
+Goal will be accepted. The task description itself must communicate this complete
+overall brief and a concise acceptance summary. Its primary Markdown owns the
+full requirements, verification methods, and stage evidence. Resolve blocking
+ambiguities without making architecture decisions or changing production
+implementation code.
+
+For a UI Goal, specify final layout, visual styling, interactions, representative
+data, and relevant states. Produce an interactive prototype that runs with
+frontend code alone, with final styling and all necessary resources. Cover
+applicable populated, empty, loading, failure, disabled, long-content, and
+narrow-screen states; explain exclusions when a relevant-looking state does not
+apply. Prototype code is an allowed problem-definition artifact. View and
+exercise the result when verifying this stage.
+
+Confirm the full requirements are clear, the applicable prototype is usable,
+and this stage's acceptance and repository delivery rules are satisfied. If
+repository rules require a PR for these artifacts, use the existing PR completion
+rules. Otherwise use the stated stage acceptance. Complete only this in-progress
+task through `task complete` with its observed version after verification. This
+satisfies design's dependency; design still needs its own approval and claim, and
+whole-Goal delivery remains unverified.
+
+### Architecture design and actual task breakdown
+
+Consume the completed Goal and prototype. Design the responsibilities, boundaries,
+data and control flow, contracts, error behavior, key decisions, and validation
+approach required by the target repository and Goal.
+
+During this task, register the complete set of persistent delivery tasks needed
+to satisfy the Goal. Each represents a concrete outcome with its own actions,
+scope, deliverables, constraints, solution, acceptance criteria, verification
+methods, and real input references. Their combined scope must cover the complete
+Goal. A future registration list or a vague implementation placeholder does not
+satisfy task breakdown.
+
+Use `dependsOn` for actual prerequisites. Every delivery root with no other
+implementation prerequisite depends directly on the design task; all delivery
+paths must therefore pass through design completion. Keep delivery tasks blocked
+while design is unfinished. This stage registers and verifies them; it does not
+execute them. New successors are proposed; approval requires a separate explicit
+user instruction covering them, even when Goal creation already permits their
+registration. Approved successors still wait for completed design prerequisites.
+
+Upload each successor's own primary Markdown and needed resources, referencing
+shared Goal and design inputs at their verified source. The design task owns its
+architecture and breakdown outputs. Read back every registered task, required
+attachment, source reference, and dependency. Verify the full breakdown before
+handing over the design PR. When review changes the design, update its owning
+artifacts and affected task summaries, plans, and references coherently, then
+reread them before completion.
+
+Follow repository document and independent review requirements. When a design
+PR is required, create it and maintain the full `properties.pullRequests` list.
+Keep this task `in_progress` until every necessary PR is platform-confirmed merged
+and stage acceptance is satisfied. An open PR, successful CI, or approval does
+not complete design. A user-review or no-merge instruction preserves this task
+and its blocking dependency while waiting; it grants no merge authority.
+
+## Preserve ownership and recover partial registration
+
+Every stage and delivery task needs its own self-contained Markdown description
+and detailed primary Markdown. Follow create-task's Markdown and verified-resource
+rules without claiming unfinished stage outputs are already available. Keep shared
+requirements on the Goal description task and shared architecture and breakdown on the design task. Later tasks reference
+verified source task IDs and attachment paths, read through the installed CLI,
+or verified immutable repository references. Do not distribute a duplicate whole
+packet to all tasks. Only copy a snapshot when the consuming task needs it,
+recording the purpose, original source, and source revision or content identity.
+
+Registration comprises independent writes, not a transaction. Reuse confirmed
+IDs if creating the second starting task, uploading an artifact, updating a
+reference, or registering part of the breakdown fails. Before retrying an
+uncertain write, read the complete actual resource and operation context as the
+handbook requires. A similar title does not prove success, and a lost response
+does not prove failure. If identity cannot be established uniquely, preserve the
+specific error and request the information needed to reconcile it; do not create
+another chain.
+
+Apply the handbook's exact-version rules to metadata updates, approval, claim
+and completion, and preserve complete-field replacement semantics for updates. Attachments are independent of task versions, status, and timestamps;
+verify actual file contents and metadata separately. Do not unlock delivery by
+marking incomplete registration or unfinished design complete. Readiness and
+`in_progress` provide no ownership lock; claim is a versioned transition, not an
+assignee lease. Generic updates cannot write status or bypass stages.
+
+## Advance and accept the whole Goal
+
+`run-task` returns after its specified task completes or requires external
+intervention. Completing registration, Goal description, or design never activates
+autopilot. Only explicitly active `autopilot` may select the next related task
+after confirming the current task `done`, within the user's authorized scope.
+CI, review, and merge waits remain with the current task.
+
+To report the whole Goal complete, inspect the full registered delivery scope,
+confirm every delivery task completed and every necessary PR actually merged,
+and verify the original Goal's overall acceptance criteria with recorded
+evidence. Description completion, design completion, one delivery PR, or an empty
+ready page is insufficient. Distinguish verified partial results and remaining
+blockers from whole-Goal completion. This check does not create a new Goal status
+or reopen the completed problem-definition task.