@codetreker/daynight 0.25.2 → 0.26.0

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

@@ -17,18 +17,19 @@ with a defined objective and completion conditions: features, bug fixes,
 architecture/design work, actual work items produced by their breakdown, and
 independently scoped [final acceptance](#final-acceptance). 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. The description
-and its actual sources follow the shared [task content standard](references/task-content.md),
-including task-owned confirmation and delivery evidence.
+belong in its session execution plan, not task descriptions or attachments.
+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 a solution, architecture, design, or related
+task result, save the complete current artifact 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 the current artifact, accepted
+decisions, and necessary rationale synchronized there. Discussion and review
+processes remain in the session. Chat summaries and repository or PR links may
+supplement the artifact; they do not replace it. Use the shared
+[task content standard](references/task-content.md) for task definitions, inputs,
+and results, and its boundary between task material and session context.
 
 Confirm the CLI, configured service, and intended project are accessible using
 the handbook's discovery rules. Preserve actual availability or upload failures;
@@ -38,9 +39,11 @@ do not claim materials are ready for review until the saved contents are verifie
 
 Final acceptance determines whether the complete requested task or Goal satisfies
 its confirmed requirements. Define that outcome explicitly when creating or
-breaking down work. Deliver the requirement-based conclusion, supporting evidence,
-defects, and unverified items on the owning task. Record the verification methods,
-tested source and environment, observations, and material limits.
+breaking down work. Deliver the requirement-based conclusion, defects, and
+unverified items on the owning task, with the assessed source, key observations,
+and material limits needed to support that result. Keep verification procedures,
+commands, debugging history, and execution progress in the session unless they
+are themselves a required task deliverable.
 
 Use manual verification, existing checks, or temporary helper scripts as
 appropriate. Keep final-acceptance helpers in the project's temporary area and
@@ -129,11 +132,12 @@ is ready. This skill does not discover and continuously select subsequent tasks.
   task may cover the whole Goal when that is its confirmed scope.
 - Use the shared [task content standard](references/task-content.md) when
   creating, breaking down, handing off, or executing tasks. The description and
-  actual references jointly supply the six content requirements; complete inline
-  content needs no primary attachment. Give confirmations and delivery evidence
-  an explicit location in the owning task. Confirm resources before linking and
-  keep shared sources at their real owner. Each Goal delivery description directly
-  identifies the architecture task and every required source location, including
+  actual references jointly supply the task definition and produced results;
+  complete inline content needs no primary attachment. Keep execution and
+  discussion methods and processes in the session. Confirm resources before
+  linking and keep shared sources at their real owner. Each Goal delivery
+  description directly identifies the architecture task and every required source
+  location, including
   inline description sections and full paths for actual attachment documents,
   even for indirect successors, under the Goal protocol's readback rules. Express
   necessary direct prerequisites through complete `dependsOn` and its

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

@@ -55,7 +55,7 @@ business writes immediately.
 The worker has already claimed and started this task. Do not claim it, set it
 to `in_progress`, select candidates, or rerun automatic candidate qualification.
 Read and apply [shared task execution](task-execution.md) for the complete task
-and stage inputs, current prerequisites, authorized work, evidence, and
+and stage inputs, current prerequisites, authorized work, results, and
 acceptance. A missing required input or unmet prerequisite keeps this assignment
 waiting in `in_progress`; it does not authorize another task.
 
@@ -84,7 +84,9 @@ local planning mechanism. Retain the original assignment identities, supplied
 worktree and branch, existing authorization, confirmed scope and acceptance,
 PR URLs and head SHA, validation and review state, blockers, attributable
 resources, and next action. Identify the invocation configuration without
-copying credentials or secrets into checkpoints, task evidence, or logs.
+copying credentials or secrets into checkpoints, task material, or logs. Keep
+this recovery context out of task descriptions and attachments; task material
+cannot replace missing operational authorization or the original assignment.
 
 Refresh the checkpoint before a long wait or session compaction. On recovery,
 restore it, verify the original active claim, and refresh remote PR state before
@@ -95,8 +97,9 @@ honor explicit pause, stop, and authorization changes without discarding its wor
 ## Deliver the assigned task
 
 1. **Implement and verify.** Read applicable repository instructions and existing
-   mechanisms. Reuse the confirmed task plan and acceptance criteria. Implement
-   the complete agreed behavior in the supplied worktree, synchronize affected
+   mechanisms. Use the task's required design inputs and acceptance criteria;
+   keep the execution plan in this session. Implement the complete agreed behavior
+   in the supplied worktree, synchronize affected
    documents, and run relevant checks and behavioral verification. Collaborating
    agents share this assignment and worktree. Use research and independent review
    agents when available and authorized. Reassess the design when repeated
@@ -138,15 +141,18 @@ honor explicit pause, stop, and authorization changes without discarding its wor
    the platform supports it. A changed head or failed precondition requires a
    fresh decision from current state.
 
-   Confirm the platform reports every necessary delivery PR as merged and record
-   each resulting merge commit. An accepted auto-merge request or merge-queue
+   Confirm the platform reports every necessary delivery PR as merged and retain
+   its merge result in the session. A final revision may identify the task's
+   delivered artifact. An accepted auto-merge request or merge-queue
    entry is not completion. Do not wait for post-merge mainline CI unless the user
    explicitly requires that verification. Continue with required task acceptance
-   and evidence after the platform confirms the merge.
+   and results after the platform confirms the merge.
 
 5. **Record acceptance and close this claim.** Complete the task's confirmed
-   acceptance and save readable evidence at its identified owner, including actual
-   validation and remaining limitations. Release attributable temporary services,
+   acceptance and save its readable results at their actual owners, including the
+   acceptance conclusion and material limitations. Keep verification procedures
+   and CI/review/merge history in the session. Release attributable temporary
+   services,
    probes, and monitoring resources, including those left by failed collaborators,
    while preserving controller-owned resources. Finish that cleanup before
    [original-claim completion](#complete-the-original-claim), because confirmed
@@ -179,7 +185,7 @@ never treat a blocker or ordinary waiting as completion.
 ## Complete the original claim
 
 When [shared acceptance readiness](task-execution.md#confirm-acceptance-readiness)
-is satisfied, all required evidence is readable, and attributable temporary
+is satisfied, all required task results are readable, and attributable temporary
 resources have been released, reread the complete task, verify the same active
 claim, and finish with the original claim ID and the version observed for that
 decision:

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

@@ -23,18 +23,20 @@ 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.
+commands, and routine checks, in the session's execution plan. Do not put these
+steps in task descriptions or attachments or turn them into Daynight tasks
+merely because an agent generated them. A distinct acceptance or validation
+assignment with its own outcome can still be a task.
 For [final acceptance](../SKILL.md#final-acceptance), identify the entire task or
 Goal being assessed and its confirmed requirement sources. Define the deliverable
-as the acceptance conclusion, evidence, defects, and unverified items. Apply the
-shared rule to temporary helpers; do not make their development or repository
+as the requirement-based acceptance conclusion, supporting observations, defects,
+and unverified items. Apply the shared rule to temporary helpers; do not make
+their development or repository
 delivery the acceptance outcome.
 
 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.
+request contains only execution steps for existing work, keep them in that
+work's session 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
@@ -47,8 +49,10 @@ explicit discussion-start request authorizes its start through
 run-task. Creating a Goal covers the later in-scope stages and breakdown only
 at those confirmation gates.
 
-For a single tracked outcome, prepare its solution, acceptance criteria, and
-applicable mock UI before registration, following the artifact rules below.
+For a single tracked outcome, prepare its stage-appropriate task definition,
+actual required inputs, and acceptance criteria before registration. A frontend
+delivery task also needs its applicable mock UI under the artifact rules below.
+A design-producing task does not require its unfinished design as an input.
 
 Look for existing work with the same problem and scope, including completed
 tasks; the default list contains only unfinished work. Inspect full descriptions,
@@ -59,16 +63,16 @@ registration does not justify a duplicate task or chain.
 
 ## Write task-specific content
 
-Use the target repository's document and workspace rules and the shared six-item
+Use the target repository's document and workspace rules and the shared task
 content standard. Give each task an outcome-focused title and a Markdown
 description that identifies its concrete work, responsibility, and actual content
-sources. The description and readable references together provide the objective,
-scope, solution, exchange contracts, acceptance, and sources. Complete inline
-content needs no primary attachment; reference-owned and mixed content are also
-valid without repeating complete documents. State where this task's confirmations,
-acceptance conclusions, and delivery evidence will live in its description or
-attachments. Stage briefs describe work that produces the stage's outputs; do
-not claim unfinished outputs already exist.
+sources. The description and readable references together provide its objective
+and requirements, scope and constraints, inputs and sources, deliverables and
+contracts, and acceptance criteria. Complete inline content needs no primary
+attachment; reference-owned and mixed content are also valid without repeating
+complete documents. Save results as they are produced. Stage briefs describe
+work that produces the stage's outputs; do not claim unfinished outputs already
+exist or require an execution plan, confirmation log, or evidence attachment.
 
 Attach only resources this task needs or owns. Keep shared Goal requirements
 with the requirements task and architecture and breakdown with the solution
@@ -102,7 +106,7 @@ ownership before registering the relationship. A top-level task has no ordinary
 prerequisites; it may still have real external prerequisites that block execution.
 Do not add a Dependencies section or duplicate the relationship lists in task
 prose. Repository specifications and design documents retain their full contracts;
-the current task identifies its specific solution and verifiable acceptance
+the current task identifies its required design inputs and verifiable acceptance
 criteria directly or through their actual owners.
 
 ## Author Markdown
@@ -122,33 +126,30 @@ attachment path, or by an immutable repository URL. A relative link cannot
 identify another task's content.
 
 For example, the following brief applies to a task whose confirmed, readable
-attachments include 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.
+attachments include the complete `mockui/index.html` prototype and its resources.
+Use this path only when those files actually belong to that task; adapt the
+content and references to the actual assignment. A Goal stage that produces a
+prototype links it only after producing and confirming it.
 
 ```markdown
-## 问题与行动
-登录失败后，用户无法判断是否可以重试。实现明确的失败原因和重试入口，保留当前登录表单输入。
+## 问题与要求
+登录失败后，用户无法判断是否可以重试。显示明确的失败原因和重试入口，保留当前登录表单输入。
 
 ## 范围与交付
-更新登录页的错误提示、重试交互和中英文文案；沿用现有认证接口与会话边界。
+交付登录页的错误提示、重试交互和中英文文案；沿用现有认证接口与会话边界。
 
-## 完成条件
-网络失败和凭据错误均显示对应提示；重试成功后进入工作区。桌面与窄屏、两种语言的交互通过验证，表单输入保持正确。
-
-## 资料
+## 输入
+[交互原型](mockui/index.html) 定义相关视觉样式和交互状态；认证接口沿用仓库现有契约，无新增任务间交换。
 
-- [方案与验收](plan.md)
-- [交互原型](mockui/index.html)
+## 完成条件
+网络失败和凭据错误均显示对应提示；重试成功后进入工作区。桌面与窄屏、两种语言的交互正确，表单输入保持。
 ```
 
-This example uses an attachment for the detailed content; the same six-item
-standard also permits complete inline or mixed organization. Its actual `plan.md`
-provides the requirements, solution, applicable exchange contracts, acceptance,
-and task-owned evidence location. The prototype stays with its actual owner when
-shared across a Goal.
+This example defines the task inline and references its actual prototype. Shared
+design inputs retain their real owner under the source rules above. Neither the
+brief nor an attachment needs the session's implementation steps, tool choices,
+or review schedule. A filename such as `plan.md` does not determine whether its
+contents belong to the task.
 
 ## Register and verify
 
@@ -170,8 +171,8 @@ already readable shared inputs at their source. Do not present planned uploads a
 
 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, all six content requirements, the explicit task-owned
-evidence location, real source identities, complete necessary direct prerequisites
+valid links and images, the stage-appropriate task definition, produced results,
+real source identities, complete necessary direct prerequisites
 and their intended external subset, absence of redundant dependencies under the
 handbook's reduction rule, and applicable mock UI resources and interaction. For a
 Goal, verify only the current discussion stage and its brief;

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

@@ -2,8 +2,8 @@
 
 Read this reference when starting or registering a Goal, discussing one of its
 stages, or advancing its authorized scope. Use [create-task](create-task.md) for
-registration, [the task content standard](task-content.md) for the shared six
-content requirements, [shared task execution](task-execution.md) for input,
+registration, [the task content standard](task-content.md) for task definitions
+and results, [shared task execution](task-execution.md) for input,
 delivery, and acceptance rules, and [the handbook](handbook.md) for CLI semantics.
 The selected execution mode owns task lifecycle and return behavior. A Goal uses existing tasks,
 attachments, complete `dependsOn` relationships, their `externalDependsOn`
@@ -15,7 +15,7 @@ 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.
+session's execution plan, not task descriptions or attachments.
 
 Permission to create a Goal covers its requirements discussion, the later solution
 discussion, and the confirmed in-scope delivery breakdown. Create each only at
@@ -38,10 +38,11 @@ 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. The description and actual
-references provide this discussion's solution, acceptance criteria, confirmation
-gate, and task-owned evidence location under the shared content standard;
-finished requirements and prototypes are outputs, not prerequisites to starting.
+questions, and observable completion conditions under the shared content
+standard. Include the intended requirements and applicable prototype deliverables
+and the required human-confirmation completion condition. Finished requirements
+and prototypes are outputs, not prerequisites to starting; the session holds the
+discussion plan and process.
 
 Each task starts in `todo`. For an explicit discussion-start request, read its
 current materials and exact version, use `task set-status <task-id> in_progress`
@@ -53,9 +54,10 @@ 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
-task-specific brief and source entrypoint; detailed requirements have one owner,
-and confirmation, validation, and evidence stay at an identified task-owned location. Before requesting user review, save the complete current material,
-read it back, and provide the task and resource reference.
+task-specific brief and source entrypoint; detailed requirements have one owner.
+Before requesting user review, save the complete current requirements artifact,
+read it back, and provide the task and resource reference. Keep discussion,
+validation, and confirmation processes in the session.
 
 For a UI Goal, produce a final-style interactive frontend-only prototype with
 working relative resources and relevant populated, empty, loading, failure,
@@ -70,9 +72,11 @@ 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,
+Keep the accepted requirements and their effective state in the owning task and
+verify they are readable. Preserve the actual confirmation and transition
+authorization in the session. A material revision after confirmation requires
+renewed user confirmation before advancement. When the discussion's acceptance
+is met,
 reread the task, use `task set-status <task-id> done` with its observed version, and confirm done.
 Do not create the solution discussion until that completion is confirmed; reconcile
 an uncertain completion before another mutation.
@@ -91,8 +95,10 @@ 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.
+breakdown. Keep these current artifacts accessible in its description or
+attachments, verify them before user review, and synchronize accepted decisions
+and necessary rationale. The discussion plan, review handling, and confirmation
+process remain in the session.
 Do not register delivery subtasks before the user confirms the current solution.
 
 A discussion task completes from user-confirmed Daynight material and its stated
@@ -104,8 +110,9 @@ 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
+After explicit user confirmation of the current solution, keep the accepted
+solution and its effective state in the owning task, preserve the confirmation
+in the session, and register the delivery breakdown below. Complete
 the solution discussion only after the accepted solution and actual registered delivery tasks,
 their required materials, and their dependencies are read back
 and verified. Use `task set-status <task-id> done` with the observed version and confirm done.
@@ -116,9 +123,10 @@ either discussion does not establish whole-Goal completion.
 
 Only after user solution confirmation, create or reuse the concrete delivery tasks
 needed for the agreed outcome. Each description and its actual references must
-satisfy the six-item content standard, including task-specific responsibility,
-input/output contracts, observable acceptance, verification, and evidence ownership. Include independently scoped acceptance work when it
-has its own outcome. A [final-acceptance](../SKILL.md#final-acceptance) brief
+satisfy the task content standard, including task-specific responsibility,
+actual required inputs, deliverables and contracts, and observable acceptance.
+Include independently scoped acceptance work when it has its own outcome. A
+[final-acceptance](../SKILL.md#final-acceptance) brief
 identifies the original whole-Goal requirements and confirmed changes, and assesses
 the combined delivery under the shared rule. Do not turn agent-generated execution
 steps into tasks. The combined scope must cover the confirmed Goal, rather than a
@@ -190,8 +198,9 @@ Read these attachments from that task before implementation:
 - `design/architecture.md`: upload flow and component responsibilities.
 - `design/upload-errors.md`: error classification and retry behavior.
 
-## Task plan
-This task's `plan.md` owns its implementation plan and full acceptance criteria.
+## Deliverable
+Upload retry controls in the existing upload UI, using the API's error contract;
+no additional task-to-task exchange is introduced.
 ```
 
 When the shared architecture is inline, the architecture inputs instead identify
@@ -204,9 +213,10 @@ paths only for actual attachment documents that are also required.
 Stage briefs describe the work to produce the stage's outputs; they do not claim
 unfinished results exist. Every stage and delivery task provides a task-specific
 Markdown brief and the complete applicable content, directly or through verified
-references. Complete inline content needs no primary attachment. Identify each
-task's own confirmation and evidence location. Keep shared inputs at their actual
-owner. Do not distribute a duplicate whole packet to every task. An independently
+references. Complete inline content needs no primary attachment. Save produced
+results at their actual owner and make them discoverable from the task. Keep
+shared inputs at their actual owner. Do not distribute a duplicate whole packet
+to every task. An independently
 needed snapshot records its purpose, original source, and source revision or
 content identity. Existing attachment reads support these references; do not
 invent a URL scheme, cross-task relative links, or fixed service host.
@@ -237,13 +247,14 @@ modes preserve their own return boundary when reading this stage protocol.
 
 Delivery tasks satisfy [shared acceptance readiness](task-execution.md#confirm-acceptance-readiness)
 and complete through their selected execution mode: accepted outcomes, required
-review, all necessary authorized PR merges, and readable evidence. To report the
+review, all necessary authorized PR merges, and readable task results. To report
+the
 whole Goal complete, inspect the full confirmed delivery scope, every delivery
 task's completion, all required delivery PR merges, and the original whole-Goal
 requirements with their confirmed changes. Apply
-[Final acceptance](../SKILL.md#final-acceptance) to the combined delivery and its
-evidence; completing or passing temporary helpers does not establish that the
-Goal is complete.
+[Final acceptance](../SKILL.md#final-acceptance) to the combined delivery;
+completing or passing temporary helpers does not establish that the Goal is
+complete.
 
 The requirements task being done means only that requirements discussion is
 complete. The solution task being done means the confirmed solution and verified

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

@@ -255,9 +255,10 @@ unchanged; clearing and option-pairing syntax is in command help.
 
 **Markdown descriptions.** Write task-specific Markdown descriptions following
 [create-task](create-task.md) and [the task content standard](task-content.md).
-The description and actual references jointly supply the six requirements;
-complete inline content needs no primary attachment, and task-owned confirmation
-and evidence locations must be explicit. The Web displays CommonMark/GFM, while
+The description and actual references jointly supply the task definition and
+produced results; complete inline content needs no primary attachment. Execution
+and discussion plans, processes, and operational authorization stay in the
+session under the shared content boundary. The Web displays CommonMark/GFM, while
 API and CLI reads preserve the original string, including line breaks and fenced code. There
 is no format flag. Relative description links and images start at the current
 task's attachment root; Markdown attachment internals start at their containing

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

@@ -21,6 +21,9 @@ required source contents, including referenced source-task descriptions or
 actual attachments, and necessary further references under the content standard.
 Check current-stage sufficiency, responsibility boundaries, relevant
 producer/consumer contracts, and Goal delivery tasks' direct architecture index.
+Check the task definition, actual required inputs, and produced results; do not
+require a session execution plan or record the handoff review process in task
+material.
 
 For a `todo` task with permission false, organize its description or authorized
 source documents only from existing confirmed information. Missing decisions

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

@@ -11,7 +11,7 @@ transition under [the Goal protocol](goal.md).
 Read the complete task with `daynight task show <task-id> --json`. Preserve the
 requested task ID through recovery and waiting. Read and apply
 [shared task execution](task-execution.md) for its required inputs,
-prerequisites, confirmed scope, work, evidence, and acceptance.
+prerequisites, confirmed scope, work, results, and acceptance.
 
 An explicitly user-selected task may use this execution path regardless of
 `allowAgents` or platform compatibility. These conditions gate automatic worker
@@ -47,8 +47,8 @@ its delivery or acceptance is complete.
 
 ## Complete or return waiting
 
-When all task acceptance and delivery conditions are satisfied and its evidence
-is readable, reread the complete in-progress task and use
+When all task acceptance and delivery conditions are satisfied and its required
+results are readable, reread the complete in-progress task and use
 `task set-status <task-id> done --if-version <observed-version>` with its exact
 observed version. Only service confirmation establishes the status update;
 reconcile uncertain results before reporting success. Do not replay an