@codetreker/daynight 0.13.0 → 0.16.0

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

@@ -1,15 +1,38 @@
 ---
 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
 
 Use the installed `daynight` CLI to keep persistent tasks aligned with the
-user's authorized work. Task content, approval and readiness describe work; they grant no
+user's authorized work. Task content, status and readiness describe work; they grant no
 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,22 +60,29 @@ 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.
-- 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
-  or Web. Approval grants no execution or delivery 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 `todo` for every normal task and Goal stage and does not
+  start execution. A request to start a Goal discussion authorizes entering
+  `in_progress` for that discussion only; a user-confirmed transition authorizes
+  the next discussion under the Goal protocol. Registration and discussion
+  confirmation grant no delivery execution permission. Existing explicit
+  authorization may cover a stated task or fixed Goal queue and its ready
+  successors without another per-task authorization.
 - 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.
+  `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,
@@ -64,15 +94,22 @@ and completing `run-task` never activate it.
   the same chain; mark a verified prerequisite from another chain as external.
   Both kinds block execution. CLI dependency options replace the full relationship
   set; preserve needed ordinary and external edges as the handbook requires.
-- Automatic task selection requires `allowAgents=true` as well as readiness.
+- Automatic task selection requires `allowAgents=true`, readiness, and
+  `requiredPlatform` compatibility with the actual current execution environment.
+  Follow autopilot's runtime mapping, filter both ready and supplemental inventory
+  before pagination, and carry automatic selection and its platform into run-task
+  for a full-task recheck before version-bound `set-status in_progress`.
   Automated workers and agent workflows must not enable this permission themselves.
-  An explicitly user-selected task may follow the manual claim path regardless
-  of the flag; approval, dependency and execution authorization still apply.
+  Only an explicitly user-selected task or fixed Goal queue may follow the manual
+  execution path regardless of the flag or platform compatibility; dependency,
+  stage inputs and execution authorization still apply.
 - Preserve the exact version observed when deciding a metadata update or
-  approve/unapprove/claim/complete action. Generic updates cannot change status. Confirm writes,
+  `task set-status` change. Generic updates cannot change status. 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 `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

@@ -26,63 +26,94 @@ possible. Do not select another task because CI, review, or merge is pending.
 
 ## Select one related task
 
-When there is no current task, query:
+When the user explicitly supplies a task or fixed Goal queue, inspect its next
+unfinished task by ID and use the manual execution path regardless of
+`allowAgents` or platform compatibility. Preserve readiness, stage inputs, and
+the existing execution scope; a fixed queue does not authorize unrelated discovery.
+Existing scoped authorization covers its ready successors without per-task reauthorization.
+
+Otherwise, when there is no current task, identify the actual runtime in the
+environment where task commands and implementation will execute:
+
+```bash
+node -p "process.platform"
+```
+
+Map `win32` to `windows`, `darwin` to `macos`, and `linux` to `linux`.
+A Linux runtime in WSL is `linux`, regardless of its outer Windows host.
+Unsupported or unknown runtime platforms leave selection waiting with the concrete
+reason. Do not substitute a configured platform, remote host OS, or requested task
+platform for the observed runtime. Query platform-compatible candidates:
 
 ```bash
-daynight task ready --allow-agents true --json
+daynight task ready --allow-agents true --compatible-platform <actual-platform> --json
 ```
 
-Pick exactly one approved ready `todo` task with `allowAgents=true` 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. Inspect complete `dependsOn` and the
-`externalDependsOn` subset. External prerequisites still block readiness, and
-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.
-
-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 `daynight task list --allow-agents true --json` as described in the handbook. Distinguish
-completed scope, work awaiting explicit approval, prerequisite-blocked work, other
-ongoing work, and insufficient
-candidates. Do not take unrelated work to stay busy or report completion from an
-empty or unrelated bounded page.
-
-Autopilot permission covers execution of existing tasks, not creation of new
-ones. If the confirmed Goal requires missing tracked work, 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.
-
-Automatic selection never enables `allowAgents` on a task. If the user explicitly
-selects a task for execution, its manual claim path remains available regardless
-of the flag; preserve all approval, prerequisite and authorization checks.
+Pick exactly one ready `todo` task with `allowAgents=true` and `requiredPlatform`
+either null or equal to the actual platform, most relevant to the confirmed Goal
+and authorized work. Compare 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. Inspect complete `dependsOn` and its `externalDependsOn` subset.
+External prerequisites still block readiness, and 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, automatic-selection mode and actual platform to `run-task`.
+Immediately before setting in_progress, reread the full task with
+`daynight task show <task-id> --json` and recheck `todo`, ready, `allowAgents=true`,
+and `requiredPlatform` either null or equal to the same actual platform. A changed
+or incompatible requirement prevents starting and requires a new selection decision;
+a changed execution environment requires fresh runtime identification and candidate
+queries. Run-task enters in_progress using the version observed for that decision
+before starting, using the exact version from this full-task recheck with
+`--if-version`. An earlier compatible page does not authorize bypassing changed
+eligibility. Autopilot cannot supply user confirmation of requirements or solution;
+an explicit discussion-start request uses the Goal protocol's scoped manual path.
+
+Ready returns at most 10 candidates by default or the requested bounded `--limit`;
+it is not a complete backlog. Supplement an empty or unmatched page only with
+needed selected reads, the graph, or
+`daynight task list --allow-agents true --compatible-platform <actual-platform> --json`.
+Both ready and supplemental list queries retain the actual-platform filter before
+pagination and permission=true; do not filter a bounded unfiltered page locally.
+Distinguish completed scope, missing execution authorization, prerequisite blockers,
+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 alone covers execution of existing tasks, not creation of
+new ones. Explicit user or repository tracking/review requirements supply standing
+creation permission within the confirmed scope. Use existing creation permission
+or obtain it before [create-task](create-task.md). Goal permission covers discussion
+stages and the confirmed breakdown at user-confirmation gates; do not precreate
+architecture placeholders or delivery tasks. Delivery registration leaves todo
+without execution; complete solution discussion only after accepted material and
+the real breakdown are verified. Existing explicit execution scope continues to
+cover its ready successors without another per-task authorization.
+
+Automatic selection never enables `allowAgents`. An explicitly selected task or
+fixed Goal queue's manual execution path remains available regardless of the flag
+or platform compatibility; preserve prerequisite, stage-input and authorization
+checks. An automatically selected ID passed to run-task remains automatic
+selection and does not acquire this manual exception.
 
 ## Advance serially and accept the scope
 
 Run one task at a time. Subagents collaborate on it; they do not each choose a
 separate task. Ordinary CI, review, and merge waits keep that target. After
 `run-task` confirms `done`, refresh readiness and select at most one next related
-task within the same authorized scope. Description completion permits design
-selection, and design completion permits delivery selection, only when the next
-task is approved ready todo, its stage inputs are complete, this mode is explicitly
-active and execution is authorized. Stage completion satisfies a dependency; it
-never approves a successor. Explicit scoped user approval may cover stated Goal
-tasks, but the Goal-creation permission itself does not.
+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 todo delivery registration. Later delivery selection
+requires a ready todo with complete inputs, explicit autopilot activation, and
+execution authorization. Discussion completion satisfies a dependency and grants
+no delivery execution permission. Existing scoped execution authorization
+continues to apply to its stated ready successors.
 
 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,44 @@
 
 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 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 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 todo and returns; an
+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.
@@ -137,10 +153,14 @@ evidence. The prototype remains with its actual owner when shared across a Goal.
 ## Register and verify
 
 New tasks have `allowAgents=false`; creation cannot enable the permission.
-Automatic workers and agent workflows must not turn it on themselves. Approval
-and automatic-execution permission remain separate explicit decisions.
+Automatic workers and agent workflows must not turn it on themselves. Execution
+authorization and automatic-discovery permission remain separate decisions.
+
+Tasks without `--required-platform` are unrestricted. Set windows, linux or macos
+only when the confirmed task needs that execution environment. Platform requirements
+do not start tasks or enable automatic execution; they survive all status changes.
 
-Reuse the established project and suitable tasks. Create new tasks in `proposed`,
+Reuse the established project and suitable tasks. Create new tasks in `todo`,
 retaining each confirmed ID. Set concrete descriptions and actual ordinary and
 external prerequisites using the handbook's full CLI replacement rule. Upload each task's own primary Markdown and required
 resources; add actual attachment references to the complete description using
@@ -151,18 +171,22 @@ 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
-task's exact version through `task approve`.
+confirmed readable. Registration leaves work todo and does not execute it. A Goal
+discussion-start request is scoped execution authorization for that discussion,
+as the Goal protocol specifies. User solution confirmation permits registration
+of todo delivery tasks and grants no delivery execution permission. Apply any
+existing explicit execution authorization only within its stated task or Goal
+scope; ready successors in an authorized fixed queue need no per-task authorization.
 
 If creation succeeds but a later operation fails, retain the confirmed IDs and
-resume missing operations there. Tasks remain `proposed`. Reconcile uncertain results through the handbook before another
+resume missing operations there. Tasks remain `todo`. 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.
+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.