@codetreker/daynight 0.8.15 → 0.8.19

package/dist/commands/setup/definition.js

@@ -3,10 +3,11 @@ export const setupDefinition = {
     description: "Configure the server connection or review repositories",
     options: [
         { names: ["--server-url"], description: "HTTP(S) server origin", value: { name: "url", kind: "text" } },
+        { names: ["--server-token-stdin"], description: "Read one personal access token from piped stdin" },
         { names: ["--review-repo"], description: "HTTPS or SSH GitHub repository address", value: { name: "remote", kind: "text" } },
         { names: ["--review-path"], description: "Dedicated review clone path (requires --review-repo)", value: { name: "path", kind: "directory" } },
         { names: ["-h", "--help"], description: "Show this help", action: "help" },
     ],
-    details: "Without options, choose server, review, or both interactively.\nExplicit options configure only the selected capabilities without prompting.\nReview clone paths default to repositoryRoot (default: ~/daynights).",
+    details: "Without options, choose server, review, or both interactively; server tokens use hidden terminal input.\nExplicit options configure only the selected capabilities without prompting.\n--server-token-stdin reads one nonempty line and uses --server-url or the configured server origin.\nChanging the server origin clears its token unless a replacement is supplied.\nReview clone paths default to repositoryRoot (default: ~/daynights).",
 };
 //# sourceMappingURL=definition.js.map

package/dist/commands/setup/definition.js.map

@@ -1 +1 @@
-{"version":3,"file":"definition.js","sourceRoot":"","sources":["../../../src/commands/setup/definition.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,eAAe,GAAsB;IAChD,IAAI,EAAE,OAAO;IACb,WAAW,EAAE,wDAAwD;IACrE,OAAO,EAAE;QACP,EAAE,KAAK,EAAE,CAAC,cAAc,CAAC,EAAE,WAAW,EAAE,uBAAuB,EAAE,KAAK,EAAE,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE;QACvG,EAAE,KAAK,EAAE,CAAC,eAAe,CAAC,EAAE,WAAW,EAAE,wCAAwC,EAAE,KAAK,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE;QAC5H,EAAE,KAAK,EAAE,CAAC,eAAe,CAAC,EAAE,WAAW,EAAE,sDAAsD,EAAE,KAAK,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,WAAW,EAAE,EAAE;QAC7I,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,QAAQ,CAAC,EAAE,WAAW,EAAE,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE;KAC3E;IACD,OAAO,EAAE,oNAAoN;CAC9N,CAAC"}
+{"version":3,"file":"definition.js","sourceRoot":"","sources":["../../../src/commands/setup/definition.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,eAAe,GAAsB;IAChD,IAAI,EAAE,OAAO;IACb,WAAW,EAAE,wDAAwD;IACrE,OAAO,EAAE;QACP,EAAE,KAAK,EAAE,CAAC,cAAc,CAAC,EAAE,WAAW,EAAE,uBAAuB,EAAE,KAAK,EAAE,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE;QACvG,EAAE,KAAK,EAAE,CAAC,sBAAsB,CAAC,EAAE,WAAW,EAAE,iDAAiD,EAAE;QACnG,EAAE,KAAK,EAAE,CAAC,eAAe,CAAC,EAAE,WAAW,EAAE,wCAAwC,EAAE,KAAK,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE;QAC5H,EAAE,KAAK,EAAE,CAAC,eAAe,CAAC,EAAE,WAAW,EAAE,sDAAsD,EAAE,KAAK,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,WAAW,EAAE,EAAE;QAC7I,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,QAAQ,CAAC,EAAE,WAAW,EAAE,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE;KAC3E;IACD,OAAO,EAAE,ibAAib;CAC3b,CAAC"}

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

@@ -19,7 +19,7 @@ requires. Do not load every mode by default.
 | Mode | Use when | Reference |
 |---|---|---|
 | `handbook` | Answering usage questions or performing requested task-management operations | [Handbook](references/handbook.md) |
-| `create-task <request>` | Preparing or registering a persistent task explicitly requested by the user | [Create task](references/create-task.md) |
+| `create-task <request>` | Preparing or registering persistent work explicitly requested by the user | [Create task](references/create-task.md) |
 | `run-task <task-id>` | Executing one specified task | [Run task](references/run-task.md) |
 | `autopilot <goal or scope>` | The user explicitly requests automatic execution of Daynight tasks | [Autopilot](references/autopilot.md) |
 
@@ -30,27 +30,32 @@ to `handbook` or select a task merely because one is ready.
 
 Enter `autopilot` only after an explicit user request for automatic Daynight task
 execution. A bare invocation may resume it when the conversation establishes
-that it is already active. Loading this skill, discovering tasks, creating a
-task, and completing `run-task` never activate it.
+that it is already active. Loading this skill, discovering tasks, creating work,
+and completing `run-task` never activate it.
 
 ## Shared constraints
 
-- Never create a task without the user's explicit permission to create tasks.
-  A direct creation request or existing explicit permission covers its stated
-  scope; do not ask again within it. Implementation requests, tracking needs,
-  inferred mode selection, and autopilot activation do not grant this permission.
-  If a new task is needed outside that permission, ask before creating it.
+- Create tasks only with explicit permission for their scope. Implementation
+  requests, tracking needs, inferred mode selection, and autopilot activation
+  do not grant creation permission. Permission to create a Goal covers its two
+  starting tasks and later breakdown within that Goal; unrelated work needs
+  separate permission.
+- Use a normal task for one independently tracked outcome. Work requiring
+  multiple independently tracked delivery stages is a Goal, expressed through
+  existing tasks and `dependsOn`. Read [the Goal protocol](references/goal.md)
+  when creating, executing, or advancing such a chain.
 - Advance one task at a time, including CI, review, and merge waits. Subagents
   collaborate on the same task. `autopilot` owns selection of subsequent work;
   `run-task` and `create-task` return when their own work ends.
-- Keep the problem and real attachment references in the task description. One
-  primary Markdown attachment owns the solution and acceptance criteria.
-  Frontend tasks also require an interactive mock UI with final visual styling.
-  Express prerequisites only through `dependsOn`.
-- Preserve the exact version observed when deciding a task update. Confirm
-  writes, reconcile uncertain results before further mutations, and preserve
-  actual failures. The handbook indexes commands and explains operational
-  context; the installed CLI help owns command usage.
-- Follow the target repository's execution and delivery rules and the user's
-  current authorization. In particular, an explicit request to leave a PR for
-  user review keeps that task pending; completion rules grant no merge authority.
+- Each task description states its concrete work, scope, deliverables,
+  constraints, observable completion summary, and real input references. Its own
+  primary Markdown owns the detailed solution, acceptance criteria, and evidence.
+  Attach resources according to actual task ownership and need; reference shared
+  inputs at their verified source. Express prerequisites only through `dependsOn`.
+- Preserve the exact version observed when deciding an update. Confirm writes,
+  reconcile uncertain results before further mutations, and preserve actual
+  failures. The handbook explains operational context; installed CLI help owns
+  command usage.
+- Follow the target repository's delivery rules and the user's authorization.
+  A request to leave a PR for user review keeps that task pending; completion
+  rules grant no merge authority.

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,52 @@ 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 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`.
 
 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, 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 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 while this
+mode is explicitly active and the next task is authorized.
 
 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,109 @@
 
 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 execution or activate 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:
-
-```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
+Give each task an outcome-focused title and a self-contained 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 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. Upload required CSS, JavaScript, images, and
+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.
+styling does not satisfy this requirement. For a UI Goal, this prototype is
+produced by the Goal description stage and referenced by later tasks.
 
-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.
+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.
 
 ## 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 `todo`,
+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 task-specific descriptions, the two
+required Markdown 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.
+
+If creation succeeds but a later operation fails, retain the confirmed IDs and
+resume missing operations there. Tasks remain `todo`; there is no additional
+draft state. 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,148 @@
+# 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.
+
+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 `todo` with its own self-contained 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`.
+
+## Execute the appropriate 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. Set only this task to `done`
+after verification; this unlocks design and does not establish whole-Goal delivery.
+
+### 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.
+
+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 concrete description and detailed
+primary Markdown. 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 and complete-field replacement rules to task
+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.
+
+## 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.

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

@@ -26,6 +26,17 @@ needed to use them correctly.
 
 ## Operational context
 
+**Service credentials.** Read the installed `daynight setup --help` for credential
+configuration. Use setup's hidden interactive token prompt or its explicit
+stdin option; never put a token in command arguments, chat, task descriptions,
+checkpoints or attachments. A configured token is bound to the normalized service
+origin: changing the origin removes the previous token. Tokens require HTTPS
+except for literal localhost or loopback HTTP addresses. Project discovery and
+explicit project IDs grant no access; the service decides from current
+membership. A 401 points to setup and does not permit an anonymous retry or a
+blind repeat of a mutation. Reconcile an unconfirmed write before another
+mutation. Setup only saves configuration and performs no login or network check.
+
 **Project discovery.** Inside a Git worktree, task commands can omit `--project`:
 the CLI matches the origin repository URL to a project on the configured
 service. An explicit project overrides discovery for that invocation. Resolve
@@ -44,9 +55,11 @@ properties, or versions. Read
 the selected task's details before acting. A graph-limit error still permits
 bounded candidate and individual task reads.
 
-**Task concurrency.** The states are `todo`, `in_progress`, and `done`; ready
-means todo with completed direct prerequisites. These facts grant no ownership
-or lock. Bind each update to the exact version read for that decision using
+**Task concurrency.** New tasks start in `todo`; execution uses `todo`,
+`in_progress`, and `done`. Reads may also return `proposed`, which is outside
+this skill's executable task flow. Preserve its actual state and resolve the
+authorized process before execution; do not implicitly promote it. Ready means
+`todo` with completed direct prerequisites. These facts grant no ownership or lock. Bind each update to the exact version read for that decision using
 `--if-version`; the CLI's default pre-submit read cannot protect an earlier
 decision. Preserve full int64 decimal digits without numeric rounding. On a
 conflict, reread and reconsider rather than merely swapping in a newer version.
@@ -71,4 +84,5 @@ actual errors and resource IDs rather than reporting success or blindly
 resending a write.
 
 Task registration, execution, and selection follow [create-task](create-task.md),
-[run-task](run-task.md), and [autopilot](autopilot.md), respectively.
+[run-task](run-task.md), and [autopilot](autopilot.md), respectively. For a chain
+of independently tracked delivery stages, use [the Goal protocol](goal.md).