@codetreker/daynight 0.17.2 → 0.17.3

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

@@ -14,11 +14,12 @@ a mainline branch.
 
 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.
+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
@@ -33,6 +34,33 @@ 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.
 
+## Final acceptance
+
+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.
+
+Use manual verification, existing checks, or temporary helper scripts as
+appropriate. Keep final-acceptance helpers in the project's temporary area and
+uncommitted. Do not integrate them into repository tests, fixtures, runners, CI,
+or tooling, or make building a maintained verification system the acceptance
+deliverable. Review findings about a helper do not authorize that change of scope.
+
+Complete acceptance according to the confirmed whole-task or whole-Goal criteria.
+Finishing or passing helper scripts does not establish that the requested work is
+complete. Do not report the underlying task or Goal as accepted while required
+outcomes remain unmet or unverified. Verify necessary implementation deliveries
+and PR merges as inputs; do not create a separate PR requirement for acceptance
+helpers. Handle discovered product defects within the authorized implementation
+scope.
+
+Implementation and authorized defect-fix tasks retain their normal unit,
+integration, and regression tests and required repository checks. A user-requested
+maintained testing or automation capability is a development deliverable governed
+by its own confirmed scope; do not infer it from a final-acceptance assignment.
+
 ## Select a mode
 
 The following are skill modes, not additional CLI commands. Read the selected

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

@@ -25,8 +25,14 @@ 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
+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
+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.
 

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

@@ -114,8 +114,11 @@ Only after user solution confirmation, create or reuse the concrete delivery tas
 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.
+has its own outcome. A [final-acceptance](../SKILL.md#final-acceptance) brief
+identifies the original whole-Goal requirements and confirmed changes, and assesses
+the combined delivery under the shared rule. Do not turn agent-generated execution
+steps into tasks. The combined scope must cover the confirmed Goal, rather than a
+vague placeholder.
 
 Create new delivery tasks in `todo`. Solution confirmation authorizes the
 confirmed breakdown's registration, not implementation, autopilot,
@@ -220,7 +223,12 @@ 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.
+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.
+
 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

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

@@ -79,6 +79,11 @@ Preserve the requested task ID through recovery and waiting.
 
 ## Execute and maintain continuity
 
+Identify [final acceptance](../SKILL.md#final-acceptance) from the task's confirmed
+outcome before applying a development or PR delivery lifecycle. Read the complete
+requirements and actual deliveries for the task or Goal being assessed, and apply
+the shared rule to verification methods, temporary helpers, and result ownership.
+
 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.
@@ -139,8 +144,10 @@ unavailable merge visibility, or an unmet merge check likewise keeps completion
 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 set-status <task-id> done` with its exact
+acceptance. For [final acceptance](../SKILL.md#final-acceptance), also apply the
+shared whole-task or whole-Goal completion rule. In every case, confirm required
+evidence is recorded and readable, then reread the complete in-progress
+task and use `task set-status <task-id> done` with its exact
 observed version. For Goal discussions, use their confirmation gates and verified
 accepted materials; for delivery tasks, use their acceptance and required authorized PR
 merges.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codetreker/daynight",
-  "version": "0.17.2",
+  "version": "0.17.3",
   "description": "A client command toolkit for development workflows",
   "repository": {
     "type": "git",
@@ -47,5 +47,5 @@
     "vite": "8.3.4",
     "vitest": "5.0.5"
   },
-  "gitHead": "4a180560daa419b472855ede25fc7b69d208d1e4"
+  "gitHead": "41080e8c89c23c94d6ec83848bd2b3675c884b04"
 }