@codetreker/daynight 0.13.0 → 0.13.1

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

@@ -1,6 +1,6 @@
 ---
 name: using-daynight
-description: Use Daynight for task management, task creation, execution of a specified task, or explicitly requested automatic execution of related tasks in a Daynight-linked repository.
+description: Manage concrete work (features, bug fixes, architecture, and their breakdown) and design reviews in Daynight; create or execute tasks, and automatically execute related tasks only when explicitly requested.
 ---
 
 # Using Daynight
@@ -10,6 +10,29 @@ user's authorized work. Task content, approval and readiness describe work; they
 permission to implement, publish, deploy, communicate externally, merge, or push
 a mainline branch.
 
+## Required tracking and review
+
+When this skill and Daynight are available, use Daynight to manage concrete work
+with a defined objective and completion conditions: features, bug fixes,
+architecture/design work, and actual work items produced by their breakdown.
+An agent's transient execution steps, such as reading files, running commands,
+and routine checks, belong in its execution plan; their presence in a plan does
+not make them Daynight tasks. Use the owning Daynight task for every solution,
+architecture, and design review.
+
+Before asking the user to review any solution, architecture, design, or related
+discussion, save the complete current review material in the owning task's
+description or attachments. Read it back to confirm it is accessible, then
+provide the task ID or verified URL and any attachment paths. Keep revisions and
+review decisions synchronized with that task. Chat summaries and repository or
+PR links may supplement the material; they do not replace it. A short review
+proposal may live in the description; detailed task plans retain their primary
+Markdown ownership under the shared constraints.
+
+Confirm the CLI, configured service, and intended project are accessible using
+the handbook's discovery rules. Preserve actual availability or upload failures;
+do not claim materials are ready for review until the saved contents are verified.
+
 ## Select a mode
 
 The following are skill modes, not additional CLI commands. Read the selected
@@ -37,14 +60,20 @@ and completing `run-task` never activate 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.
+  alone do not grant creation permission. An explicit user or applicable
+  repository instruction requiring Daynight tracking or review is standing
+  creation permission for the necessary tasks within the user's confirmed scope;
+  reuse suitable existing tasks and do not ask for that permission again.
+  Permission to create a Goal covers its discussion stages and confirmed
+  in-scope breakdown, created only at the user-confirmation gates in the Goal
+  protocol; unrelated work needs separate permission.
 - Creation produces `proposed` for every normal task and Goal stage. Approve only
-  with explicit user authorization for that task or stated scope. Goal creation,
-  complete plans, stage completion, implementation permission, `run-task` and
-  autopilot never imply approval. Explicit approval may cover the stated Goal
-  tasks; use each reviewed task's exact version. The user can approve through CLI
+  with explicit user authorization for that task or stated scope. A request to
+  start a Goal discussion authorizes approval and claim of that discussion only;
+  a user-confirmed transition authorizes the next discussion under the Goal
+  protocol. Registration alone, complete plans, stage completion, implementation
+  permission, `run-task` and autopilot never imply delivery approval. Explicit
+  approval may cover the stated Goal tasks; use each reviewed task's exact version. The user can approve through CLI
   or Web. Approval grants no execution or delivery permission.
 - Use a normal task for one independently tracked outcome. Work requiring
   multiple independently tracked delivery stages is a Goal, expressed through
@@ -52,7 +81,9 @@ and completing `run-task` never activate it.
   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.
+  `run-task` and `create-task` return when their own work ends, except for the
+  explicit user-directed discussion transition in the Goal protocol. Discussion
+  confirmation does not activate autopilot or start delivery.
 - Write each task description in Markdown as a self-contained brief: concrete
   problem, actions, scope, deliverables, constraints, observable completion summary,
   and real input references. Its own primary Markdown owns the detailed solution,
@@ -74,5 +105,7 @@ and completing `run-task` never activate it.
   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 `in_progress`; completion
-  rules grant no merge authority.
+  When task acceptance includes PR delivery, a request to leave that PR for user
+  review keeps the task `in_progress`. A Daynight discussion uses its own
+  user-confirmation gate unless PR delivery is explicitly part of its acceptance.
+  Completion rules grant no merge authority.

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

@@ -42,8 +42,12 @@ cross-chain classification does not authorize executing them or expand the
 confirmed scope. Readiness checks all 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.
+Autopilot never auto-approves proposed work. Goal registration, completed
+discussions, and permission to execute do not authorize task approval for delivery.
+An explicit user request to start a Goal discussion or direct its next discussion
+uses the Goal protocol's scoped approval and manual claim path, not automatic
+approval or backlog selection. Autopilot cannot supply user confirmation of
+requirements or solution.
 
 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
@@ -54,15 +58,18 @@ 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, use explicit creation
+Autopilot permission alone covers execution of existing tasks, not creation of
+new ones. An explicit user or applicable repository instruction requiring
+Daynight tracking or review supplies standing creation permission within the
+confirmed scope. 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.
+[create-task](create-task.md). Goal permission covers its discussion stages and
+confirmed in-scope breakdown at the Goal protocol's user-confirmation gates.
+Do not create architecture placeholders or delivery tasks before their gate.
+Delivery registration follows explicit user solution confirmation, and leaves
+proposed tasks pending separate explicit approval. Complete the solution
+discussion only after the accepted solution and actual breakdown are verified;
+its completion does not start delivery.
 
 Automatic selection never enables `allowAgents` on a task. If the user explicitly
 selects a task for execution, its manual claim path remains available regardless
@@ -73,16 +80,19 @@ of the flag; preserve all approval, prerequisite and authorization checks.
 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.
+task within the same authorized scope. For Goal discussions, stop at each user
+confirmation gate; completing requirements and starting solution discussion
+requires the user's explicit confirmation and direction under the Goal protocol.
+Solution confirmation permits proposed delivery registration, not delivery
+execution. Later delivery selection requires an approved ready todo with complete
+inputs, explicit autopilot activation, and execution authorization. Discussion
+completion satisfies a dependency; it never approves delivery tasks. Explicit
+scoped user approval may cover stated delivery tasks; Goal registration and
+discussion confirmation do 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
+explicit no-merge or user-review requirement on a delivery task is such a wait; it never permits
 auto-merge or marking the task done. An unfinished external prerequisite outside
 the authorized scope is also an external blocker: preserve its ID and reason,
 without dropping or reclassifying it to manufacture readiness. Return without replacing the target.

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

@@ -2,28 +2,45 @@
 
 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 work does not authorize approval, execution or autopilot.
+registration; registration alone does not authorize approval, execution or
+autopilot. An explicit request to start a Goal discussion routes the registered
+current stage to run-task under the Goal protocol.
 
 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 or run
-autopilot does not grant creation permission. Ask when it is missing; reuse
-permission already granted for the scope.
+autopilot alone does not grant creation permission. Ask when it is missing; reuse
+permission already granted for the scope. Creation does not authorize approval,
+execution, or delivery.
 
 ## Choose the tracked outcome
 
-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.
-
-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.
+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.
+
+Keep an agent's transient execution steps, such as reading files, running
+commands, and routine checks, in the existing execution plan. Do not turn these
+steps into Daynight tasks merely because an agent generated them. A distinct
+acceptance or validation assignment with its own outcome can still be a task;
+running a check while delivering an existing task is an execution step. If the
+request contains only execution steps for existing work, keep them with that
+work and return without registering additional tasks.
+
+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 proposed and returns; an
+explicit discussion-start request authorizes its approval and claim through
+run-task. Creating a Goal covers the later in-scope stages and breakdown only
+at those confirmation gates.
 
 For a single tracked outcome, prepare its solution, acceptance criteria, and
 applicable mock UI before registration, following the artifact rules below.
@@ -151,13 +168,17 @@ 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, complete prerequisites and their intended external subset, and applicable mock UI resources and
-interaction. For a Goal, verify both starting tasks and their stage briefs.
+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.
 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
+registered work proposed and report that approval is pending. A Goal
+discussion-start request is scoped approval and claim authorization for that
+discussion, as the Goal protocol specifies; registration alone grants none.
+User solution confirmation permits registration of proposed delivery tasks,
+without granting their approval or execution. 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
@@ -165,4 +186,6 @@ resume missing operations there. Tasks remain `proposed`. Reconcile uncertain re
 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.
+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.

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

@@ -1,186 +1,184 @@
 # 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
+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
+content and registration, [run-task](run-task.md) for task execution, and
 [the handbook](handbook.md) for CLI semantics. A Goal uses existing tasks,
 attachments, complete `dependsOn` relationships, their `externalDependsOn`
-classification and PR properties; it adds no Goal-specific 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 ordinary `--depends-on` to the Goal description task.
-Confirmed within-Goal stages and delivery prerequisites stay ordinary. Verified
-prerequisites owned by other same-project chains use `--external-depends-on`; even a Goal's
-top-level task may have such external predecessors. They remain real blockers.
-Preserve both kinds through the handbook's complete CLI replacement semantics,
-not by inferring classification from done status or the current rendered graph.
-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.
+classification, and PR properties. It adds no resource, command, or status.
+
+## Identify the current discussion
+
+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
+owning task's execution plan.
+
+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.
+
+A request to start a Goal discussion authorizes creating, approving, and claiming
+that discussion task so it becomes `in_progress`. A registration-only request
+creates only the current discussion task in `proposed` and returns without
+approval or execution. A generic run request, Goal registration, or autopilot
+activation does not supply discussion-start or delivery approval authorization.
+
+## Start requirements discussion
+
+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. Its primary Markdown's Solution
+and Acceptance criteria describe this discussion and its user-confirmation gate;
+finished requirements and prototypes are outputs, not prerequisites to starting.
+
+Each task starts in `proposed`. For an explicit discussion-start request, read its
+current materials and exact version, use `task approve`, confirm todo, then use
+`task claim` 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.
+
+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
+self-contained brief; its primary Markdown owns detailed requirements, validation,
+and evidence. Before requesting user review, save the complete current material,
+read it back, and provide the task and resource reference.
+
+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.
+
+## Confirm requirements and start solution discussion
+
+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.
+
+Record the user's confirmation with the accepted material in the owning task and
+verify it is readable. A material revision after confirmation requires renewed
+user confirmation before advancement. When the discussion's acceptance is met,
+reread the task, use `task complete` 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.
+
+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 approval and execution authorization. Prepare its stage brief,
+read its current version, approve and claim through the same lifecycle, and
+confirm `in_progress`. This user-directed transition does not require autopilot
+and does not authorize selection of another unrelated task.
 
 ## Execute the appropriate stage
 
-New Goal stages and delivery tasks start with `allowAgents=false`. Creation and
-approval do not enable automatic execution. Automated workflows must not enable
-the flag themselves; explicit user-selected execution may use manual claim
-regardless of it while retaining all authorization and prerequisite checks.
-
-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.
-Unstarted todo work can return to proposed through explicitly authorized
-unapprove; it then waits for a new approval before claim.
-
-| 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 ordinary edges for actual within-Goal prerequisites. Every delivery root
-with no other ordinary implementation prerequisite depends directly on the
-design task, so every within-Goal delivery path passes through design completion.
-External prerequisites keep their verified source ownership and do not replace
-that ordinary design gate; they also must be done before execution. 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.
+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 discussion material accessible in its description or attachments,
+verify it before user review, and synchronize revisions and review decisions.
+Do not register delivery subtasks before the user confirms the current solution.
+
+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.
+
+After explicit user confirmation of the current solution, record that confirmation
+with the accepted material 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 complete` with the observed version and confirm done.
+Completion satisfies dependencies but never approves delivery tasks. 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 needs its own problem, objective, scope,
+deliverables, constraints, solution, observable acceptance, verification methods,
+and real input references. Include independently scoped acceptance work when it
+has its own outcome; 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 `proposed`. Solution confirmation authorizes the
+confirmed breakdown's registration, not approval, implementation, autopilot,
+automatic-execution permission, publishing, deployment, or merge. Apply any
+separate explicit authorization only within its stated scope. New tasks have
+`allowAgents=false`; automated workflows must not enable it themselves.
+
+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. Preserve the complete relationship sets under the handbook's CLI
+replacement semantics. Do not create dependencies merely to group cards.
+
+Upload each task's own primary Markdown and needed resources. Keep shared
+requirements with the requirements task and the solution and breakdown with the
+solution task. Consumers reference the verified source task ID and attachment
+path, or an immutable repository source. Read back every task, required attachment,
+shared input, and dependency before reporting the breakdown registered. 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.
 
 ## 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,
-withdrawal, 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.
+Stage briefs describe the work to produce the stage's outputs; they do not claim
+unfinished results exist. Every stage and delivery task has its own self-contained
+Markdown brief and detailed primary Markdown. 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, approve, unapprove, claim, and complete 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
 
-`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.
+A user-directed requirements-to-solution transition follows the confirmation
+protocol above. Ordinary `run-task` otherwise returns after its specified task
+completes or needs external intervention. Neither discussion completion nor
+breakdown registration activates autopilot or starts delivery. Only explicitly
+active autopilot selects later delivery work, and only with the existing approval,
+`allowAgents`, readiness, input, and execution requirements. CI, review, and merge
+waits stay with the current delivery task.
+
+Delivery tasks follow normal run-task completion: accepted outcomes, required
+review, all necessary authorized PR merges, and readable evidence. To report the
+whole Goal complete, inspect the full confirmed delivery scope, every delivery
+task's completion, all required PR merges, and the original whole-Goal acceptance.
+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.

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

@@ -73,7 +73,10 @@ in-progress or done work, execution release, or direct todo-to-done transition.
 Metadata, attachments and PR references cannot approve, withdraw approval or
 claim work. Approve or unapprove only when the user explicitly authorizes that
 action for the task or stated scope; creation, execution requests, `run-task`
-and autopilot grant none. In the Web, the title-row entry opens a confirmation;
+and autopilot alone grant none. The Goal protocol treats an explicit request
+to start a requirements or solution discussion as scoped authorization to approve
+and claim that discussion task. Its user-confirmed transitions do not authorize
+approval or execution of delivery tasks. In the Web, the title-row entry opens a confirmation;
 only deliberate confirmation is the user's approval or withdrawal instruction.
 Cancel and Escape submit no action. Task approval itself grants no implementation,
 publication, deployment or merge permission.

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

@@ -3,7 +3,9 @@
 Execute exactly one specified task ID within the user's authorized scope. Read
 [the handbook](handbook.md) for CLI operations, data semantics, and failures.
 This mode owns execution and completion; it returns without choosing a successor
-or activating autopilot.
+or activating autopilot. An explicit user-directed requirements-to-solution
+discussion transition follows the Goal protocol after current-task completion;
+it is not automatic backlog selection.
 
 ## Establish the task and stage
 
@@ -20,7 +22,7 @@ task read loads attachment inventory or bytes.
 
 For a Goal stage or delivery task, read [the Goal protocol](goal.md) and identify
 its role from the actual task content and context. Apply that stage's input and
-output requirements. Goal description and design start from their stage briefs;
+output requirements. Requirements and solution discussions start from their stage briefs;
 the completed requirements, applicable UI prototype, and architecture are outputs
 of the stages that produce them. Delivery tasks require the delivered design and
 applicable prototype. When a prototype is a required input, view and exercise it
@@ -45,7 +47,10 @@ the description. Do not execute prerequisites as an implicit expansion of the
 requested task.
 
 For `proposed`, keep execution pending approval. A run request or autopilot
-activation does not authorize approval. Only if the user explicitly authorized
+activation does not authorize approval of ordinary or delivery tasks. An explicit
+request to start the current Goal discussion, or the user-directed transition
+that starts solution discussion, authorizes approval and claim of that discussion
+under the Goal protocol; registration alone does not. Only if the user explicitly authorized
 approval of this task or stated scope, review its current content and use
 `task approve` with that exact observed version, then confirm the resulting todo
 state. The user can also approve directly through the CLI or Web. Approval does
@@ -69,10 +74,14 @@ Preserve the requested task ID through recovery and waiting.
 Follow the target repository's instructions for worktrees, implementation,
 review, validation, and delivery. Use the task's stage-appropriate solution and
 acceptance criteria, including applicable final-style prototype interactions.
-Goal description defines the problem without architecture decisions or production
-implementation. Design completes architecture and actually registers and verifies
-the entire delivery breakdown before design PR handover. Do not start a successor
-while running either stage.
+Requirements discussion defines the problem without architecture decisions or
+production implementation. Only user-confirmed requirements and direction to
+continue permit completing that discussion and starting solution discussion.
+Solution discussion keeps the draft architecture and breakdown in its owning
+task. Only explicit user confirmation of the current solution permits registering
+and verifying the actual delivery tasks. Do not start delivery from either
+discussion. Keep the discussion in_progress while its user-confirmation gate is
+unmet; a material revision after confirmation needs renewed user confirmation.
 
 Resolve material changes to the agreed solution or acceptance within the current
 authorization. Rewrite the owning artifact and affected task summaries and input
@@ -99,7 +108,14 @@ PR and workspace references.
 
 ## Confirm completion or return waiting
 
-Development tasks and design or documentation tasks delivered through PRs remain
+Goal requirements and solution discussion tasks use the user-confirmed material
+and stage acceptance in the Goal protocol. A generic repository PR rule does not
+add a PR-merge prerequisite to these Daynight discussions. If particular
+repository artifacts or PR delivery are explicitly part of that discussion
+task's acceptance, honor that requirement under the delivery rules below.
+Unconfirmed discussion material keeps its discussion task in_progress.
+
+Development tasks and design or documentation delivery tasks with PRs remain
 `in_progress` until the hosting platform confirms **every necessary delivery PR
 is merged** and all stage acceptance criteria are satisfied. Code completion,
 passing CI, approved review, and an open PR do not satisfy this condition. Verify
@@ -117,12 +133,13 @@ pending and successors blocked.
 For tasks without a development or PR delivery path, use their stated stage
 acceptance. In every case, confirm required evidence is recorded and readable,
 then reread the complete in-progress task and use `task complete` with its exact
-observed version. This applies to Goal description, design and every delivery
-task, using their own stage acceptance and required authorized PR merges.
+observed version. For Goal discussions, use their confirmation gates and verified
+accepted materials; for delivery tasks, use their acceptance and required authorized PR
+merges.
 Only service confirmation establishes the status update; reconcile uncertain
-results before reporting success. A Goal description task's completion means
-problem definition is complete; design completion means architecture and actual
-breakdown are delivered. Neither establishes whole-Goal completion.
+results before reporting success. A Goal requirements discussion task's completion
+means requirements are confirmed; solution discussion completion means the user-confirmed solution and
+actual verified breakdown are delivered. Neither establishes whole-Goal completion.
 
 Continue ordinary CI and review waits as this task. When progress requires
 external intervention, preserve the target, actual state, concrete blocker,
@@ -130,4 +147,6 @@ existing work, and next action in the checkpoint, then return the waiting result
 Unapproved work stays `proposed`; approved unstarted work stays `todo`; claimed
 work stays `in_progress`. Do not declare
 completion or select other work to bypass a wait. After completion, return
-without selecting a successor. Whole-Goal acceptance follows the Goal protocol.
+without selecting a successor, except for an explicit user-directed discussion
+transition under the Goal protocol. That transition does not activate autopilot
+or authorize delivery. Whole-Goal acceptance follows the Goal protocol.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codetreker/daynight",
-  "version": "0.13.0",
+  "version": "0.13.1",
   "description": "A client command toolkit for development workflows",
   "repository": {
     "type": "git",
@@ -47,5 +47,5 @@
     "vite": "8.3.4",
     "vitest": "5.0.5"
   },
-  "gitHead": "7b426bc0b632e57bb80dea0d5aca35b1e8f71a6e"
+  "gitHead": "de527e4f423eeff4e54f06c1944f44b665343941"
 }