@codetreker/daynight 0.13.1 → 0.16.0

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

@@ -26,54 +26,76 @@ 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 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
-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.
+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. 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). 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
-of the flag; preserve all approval, prerequisite and authorization checks.
+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
 
@@ -83,12 +105,11 @@ separate task. Ordinary CI, review, and merge waits keep that target. After
 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.
+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

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

@@ -2,7 +2,7 @@
 
 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; registration alone does not authorize approval, execution or
+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.
 
@@ -12,8 +12,7 @@ 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 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.
+permission already granted for the scope. Creation does not authorize execution or delivery.
 
 ## Choose the tracked outcome
 
@@ -37,8 +36,8 @@ 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
+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.
 
@@ -154,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.
 
-Reuse the established project and suitable tasks. Create new tasks in `proposed`,
+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 `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
@@ -172,17 +175,15 @@ 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. 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`.
+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

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

@@ -24,11 +24,10 @@ 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
+A request to start a Goal discussion authorizes creating and starting
 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.
+creates only the current discussion task in `todo` and returns without execution. A generic run request, Goal registration, or autopilot
+activation does not supply discussion-start or delivery execution authorization.
 
 ## Start requirements discussion
 
@@ -40,9 +39,9 @@ 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`.
+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`
+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.
@@ -70,15 +69,15 @@ 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.
+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.
 
 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
+provides its scoped execution authorization. Prepare its stage brief,
+read its current version, set in_progress 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.
 
@@ -105,8 +104,8 @@ After explicit user confirmation of the current solution, record that confirmati
 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
+and verified. Use `task set-status <task-id> done` with the observed version and confirm done.
+Completion satisfies dependencies and grants no delivery execution permission. Completing
 either discussion does not establish whole-Goal completion.
 
 ## Register the confirmed delivery breakdown
@@ -118,8 +117,8 @@ 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,
+Create new delivery tasks in `todo`. Solution confirmation authorizes the
+confirmed breakdown's registration, not 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.
@@ -158,7 +157,7 @@ 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
+Bind metadata updates and status changes 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
@@ -166,12 +165,19 @@ new decision. Readiness and `in_progress` provide no ownership lock or lease.
 
 ## Advance and accept the whole Goal
 
+Automatic delivery discovery requires actual-runtime platform compatibility.
+Use autopilot's platform-filtered queries and preserve automatic-selection context
+for run-task's full-task recheck before setting in_progress. A user-specified fixed
+Goal queue keeps its manual path and existing execution scope across ready successors;
+it does not enable automatic discovery permission or bypass stage confirmation.
+
 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
+active autopilot selects later delivery work, and only with the existing readiness, input, and execution requirements. Automatic discovery
+requires `allowAgents=true`; an explicitly selected task or fixed Goal queue
+uses the manual execution path regardless of that flag. CI, review, and merge
 waits stay with the current delivery task.
 
 Delivery tasks follow normal run-task completion: accepted outcomes, required

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

@@ -13,15 +13,12 @@ needed to use them correctly.
 | `project create` | Register a repository as a project or find its existing project. |
 | `project list` | Find projects on the configured service. |
 | `project show` | Inspect a project's details. |
-| `task create` | Register a proposed task with its metadata and dependencies. |
-| `task ready` | Read a bounded candidate page of approved todo tasks with completed prerequisites. |
+| `task create` | Register a todo task with its metadata and dependencies. |
+| `task ready` | Read a bounded candidate page of todo tasks with completed prerequisites. |
 | `task list` | Read every matching page; defaults to unfinished tasks. |
 | `task show` | Read one task's complete details and exact version. |
-| `task update` | Change metadata, automatic-execution permission, dependencies, or PR references; status is not writable. |
-| `task approve` | Change proposed to todo using an observed version and explicit approval authorization. |
-| `task unapprove` | Withdraw approval of todo work, returning it to proposed using an observed version. |
-| `task claim` | Change ready todo to in_progress using an observed version. |
-| `task complete` | Change in_progress to done after acceptance and required authorized delivery. |
+| `task update` | Change metadata, automatic-execution permission, platform requirements, dependencies, or PR references; status is not writable. |
+| `task set-status` | Set todo, in_progress, or done using an observed exact version. |
 | `task graph` | Inspect the project's dependency graph and summary. |
 | `task attachment put` | Upload or replace one attachment file. |
 | `task attachment list` | Read a task's attachment inventory and metadata. |
@@ -48,12 +45,11 @@ service. An explicit project overrides discovery for that invocation. Resolve
 missing or ambiguous matches rather than guessing an ID or creating a project
 to make a query succeed.
 
-**Read scope.** Ready is a candidate page of approved todo tasks, ordered by
-creation rather than relevance. An empty page does not rule out proposed,
-in-progress or dependency-blocked work. List traverses every matching page but
+**Read scope.** Ready is a candidate page of todo tasks, ordered by
+creation rather than relevance. An empty page does not rule out in-progress or dependency-blocked work. List traverses every matching page but
 excludes `done` by default; include completed tasks explicitly when checking the
 full backlog or prior registrations. Its grouping is in-progress, ready todo,
-blocked todo, proposed, then done when included; this does not rank relevance.
+blocked todo, then done when included; this does not rank relevance.
 Human lists are summaries; JSON lists omit only `description` and preserve every
 other task field. Use show when a description is needed; ready, details and write
 results retain full tasks. Graph provides compact dependency context without
@@ -61,49 +57,68 @@ full descriptions, PR properties, or versions. Read the selected task's details
 before acting. A graph-limit error still permits bounded candidate and
 individual task reads.
 
-**Lifecycle and approval.** Creation starts in `proposed`. Explicit approval
-moves proposed to todo; unapprove returns only unstarted todo work to proposed;
-claim moves ready todo to in_progress; complete moves in_progress to done.
-Approval and withdrawal allow unfinished prerequisites. Claim and completion
-require every direct prerequisite to be done. Proposed is never ready, even
-with no prerequisites. Withdrawal preserves task materials, dependencies,
-execution timestamps and attachments; it does not change successor states.
-Repeated actions and wrong predecessor states fail. There is no reopening of
-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 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.
+**Task status.** Creation starts in `todo` with no task approval stage and does
+not start execution. `task set-status <task-id> <status> --if-version <version>`
+sets any of `todo`, `in_progress`, or `done`. The service checks the exact version
+before a same-status no-op; it preserves all fields for a current-version no-op
+and refuses stale versions. A real change increments the version once. Generic
+metadata updates cannot write status. Status, materials, and readiness grant no
+implementation, publication, deployment, or merge permission.
+
+Entering in_progress or done requires every direct prerequisite done. Reopening
+done to todo or in_progress is refused when a direct successor is in_progress or
+done; successors are never changed automatically. Entering in_progress starts a
+new execution interval and clears completion; returning to todo clears both
+endpoints. In_progress to done retains the nullable start and records completion.
+Todo to done records only completion, with unknown duration. Same-status and
+metadata updates preserve timing. State changes provide no process ownership,
+release, transfer, stop, or lease semantics. The Web confirms every status choice,
+including the current status; cancel and Escape submit no request.
 
 **Automatic execution permission.** Tasks expose the required boolean
-`allowAgents`, independent of status approval and dependency readiness. New tasks
+`allowAgents`, independent of status and dependency readiness. New tasks
 start false; public creation cannot set it. Existing tasks receive true through
 the database migration. Use `task update <task-id> --allow-agents true|false --if-version <version>` only
 for an explicitly authorized permission change.
 Omission preserves the current value, including explicit false. Actual changes
 are locked during in_progress; exact-version same-value requests keep the
-version and timestamps, while stale versions still conflict. Approve, unapprove,
-claim, complete and other metadata updates preserve the flag.
+version and timestamps, while stale versions still conflict. Status changes and other metadata updates preserve the flag.
 
 `task list` and `task ready` accept `--allow-agents true|false`. The server
 combines that condition with other filters before pagination and the ready limit;
 an unfiltered ready page may contain tasks without automatic-execution permission.
 Automatic selection requires true and automated workflows must not enable it
-themselves. An explicitly user-selected task may still use manual claim regardless
+themselves. An explicitly user-selected task may still use manual execution regardless
 of the flag. Permission does not grant execution, publication or merge authority.
 A lost permission PATCH response is an unconfirmed write: read actual task state
 before reconsidering the operation, without resubmitting automatically.
 
-**Task concurrency.** Bind each metadata update, approve, unapprove, claim and complete to
+**Execution platform.** Complete tasks, inventory items and graph nodes expose
+`requiredPlatform` as `null`, `windows`, `linux` or `macos`; null means unrestricted.
+Set a requirement with `task create --required-platform <platform>` or
+`task update <task-id> --required-platform <platform> --if-version <version>`.
+Clear it with `task update <task-id> --clear-required-platform --if-version <version>`;
+setting and clearing in one command is invalid. Omitting both update options
+preserves the requirement. Existing and new tasks without a requirement are
+unrestricted. Actual changes are locked during in_progress; an exact-version
+same-value request keeps version and timestamps, while stale versions conflict.
+Explicitly user-selected tasks and fixed queues retain their manual execution
+path independently of platform compatibility. Automatic selections keep their
+actual-platform context and recheck full-task eligibility before set-status.
+
+`task list` and `task ready` accept `--compatible-platform <platform>`. The
+server includes unrestricted tasks and exact matches, combining this condition
+with status, readiness and `--allow-agents` before pagination or the ready limit.
+Platform compatibility does not change readiness or enable automatic execution.
+Preserve the filter when requesting additional candidate inventory; do not filter
+a bounded unfiltered ready page locally. A query option selects a candidate
+platform and does not establish the actual execution environment. Worker runtime
+must identify its own platform; a Linux runtime in WSL is Linux.
+
+**Task concurrency.** Bind each metadata update and status change to
 the exact version read for that decision using `--if-version`; the CLI's default
 pre-submit read cannot protect an earlier decision. Preserve full int64 decimal
-digits without numeric rounding. A claim is a versioned transition, not an
+digits without numeric rounding. Entering in_progress is a versioned transition, not an
 assignee lock, renewable lease or proof that existing work belongs to this
 session. On a conflict, reread and reconsider; a new action needs a fresh
 decision, not merely a newer version. Never retry a mutation automatically.
@@ -111,7 +126,7 @@ decision, not merely a newer version. Never retry a mutation automatically.
 **Dependency classification.** `dependsOn` contains every direct prerequisite;
 `externalDependsOn` is its explicit external subset. Ordinary prerequisites are
 `dependsOn` minus that subset. Both are canonical, duplicate-free UUID sets,
-not insertion order. Every prerequisite must be done before claim or completion,
+not insertion order. Every prerequisite must be done before entering in_progress or done,
 including external ones; cycle checks and project access rules use all edges.
 External means cross-chain within the same project, not a cross-project
 reference. It separates chain ownership, not blocking or authorization. Use
@@ -174,5 +189,7 @@ resource IDs rather than reporting success or blindly resending a write.
 Task registration, execution, and selection follow [create-task](create-task.md),
 [run-task](run-task.md), and [autopilot](autopilot.md), respectively. For a chain
 of independently tracked delivery stages, use [the Goal protocol](goal.md).
-Goal scope grants no implicit approval: every stage and delivery task follows the
-same proposed/approve/unapprove/claim/complete lifecycle.
+Every stage and delivery task follows the same todo/in_progress/done contract.
+A fixed Goal queue may use existing scoped execution authorization for its ready
+successors; registration and discussion confirmation grant no delivery execution
+permission.

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

@@ -29,15 +29,26 @@ applicable prototype. When a prototype is a required input, view and exercise it
 with its resources. An unfinished output of the current stage is not a missing
 input.
 
-An explicitly user-selected task may use the manual claim path regardless of
-`allowAgents`; this flag gates automatic selection, not explicit task assignment.
-Automated task selection requires true and must not enable the flag itself.
+An explicitly user-selected task may use the manual execution path regardless of
+`allowAgents` or platform compatibility; a fixed queue explicitly selected by the
+user has the same manual path. These conditions gate automatic selection, not
+explicit assignment. Automated task selection requires true and must not enable
+the flag itself. An automatically selected ID passed here remains automatic
+selection, even though run-task receives a concrete ID. Carry its actual runtime
+platform from autopilot and wait if unsupported or unknown. Immediately before
+setting in_progress, reread the full task and recheck `todo`, ready,
+`allowAgents=true`, and `requiredPlatform` either null or equal to that 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. Use the exact version from this full-task
+recheck with `--if-version`; an earlier candidate page does not authorize the
+manual exception after automatic eligibility changes.
 
 Check state, every direct prerequisite, authorized scope, and required stage
 inputs. Read `dependsOn` and its `externalDependsOn` subset: ordinary edges
 express same-chain prerequisites, external marks distinguish verified cross-chain
-ownership. Both kinds must be done for claim and completion. Classification
-never grants permission to execute a prerequisite, approve it, enable automatic
+ownership. Both kinds must be done before entering in_progress or done. Classification
+never grants permission to execute a prerequisite, enable automatic
 execution, or remove a blocker.
 A missing or unreadable primary Markdown, missing Solution or Acceptance criteria,
 or absent required input leaves execution unready. Resolve it within the
@@ -46,27 +57,20 @@ from a title, silently invent acceptance criteria, or move detailed plans into
 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 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
-not expand implementation or delivery authorization.
-
-If approval is withdrawn before claim, the task is proposed again and waits for
-new explicit approval. Do not infer approval from its earlier todo state or
-retry a failed claim with a newer version.
+Creation leaves a task `todo` and does not execute it. An explicit request to
+start the current Goal discussion, or the user-directed transition that starts
+solution discussion, authorizes entering in_progress for that discussion under
+the Goal protocol; registration alone does not. Existing execution authorization
+may cover the stated task or fixed Goal queue and its ready successors. Task
+status never expands implementation or delivery authorization.
 
 For ready `todo`, begin only when dependencies are done, required stage inputs are complete
-and the work is authorized. Use `task claim` with the exact version observed for
+and the work is authorized. Use `task set-status <task-id> in_progress` with the exact version observed for
 that decision and confirm in_progress before starting. A stale version or
 changed prerequisite requires rereading and reconsidering, with no automatic
-claim retry. For `in_progress`, recover existing work and coordinate using the
+mutation retry. For `in_progress`, recover existing work and coordinate using the
 project's established mechanisms; the state is not an assignee lock or lease.
-A task already `done` is reported as such; there is no reopening operation.
+A task already `done` is reported as such unless reopening is within the explicit requested scope; use the same versioned status setter and dependency protection.
 Preserve the requested task ID through recovery and waiting.
 
 ## Execute and maintain continuity
@@ -132,7 +136,7 @@ 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
+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.
@@ -144,8 +148,7 @@ actual verified breakdown are delivered. Neither establishes whole-Goal completi
 Continue ordinary CI and review waits as this task. When progress requires
 external intervention, preserve the target, actual state, concrete blocker,
 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
+Unstarted work stays `todo`; active work stays `in_progress`. Do not declare
 completion or select other work to bypass a wait. After completion, return
 without selecting a successor, except for an explicit user-directed discussion
 transition under the Goal protocol. That transition does not activate autopilot

package/dist/commands/skill/targets.d.ts

@@ -8,4 +8,5 @@ export type SkillTarget = {
     missingParents: readonly string[];
     agents: SkillAgent[];
 };
+export declare const mergeSkillTargets: (candidates: readonly SkillTarget[]) => SkillTarget[];
 export declare const planSkillTargets: (base: string, agents: readonly SkillAgent[]) => Promise<SkillTarget[]>;

package/dist/commands/skill/targets.js

@@ -5,17 +5,16 @@ const contains = (parent, child) => {
     const relative = path.relative(comparisonPath(parent), comparisonPath(child));
     return relative !== "" && relative !== ".." && !relative.startsWith(`..${path.sep}`) && !path.isAbsolute(relative);
 };
-export const planSkillTargets = async (base, agents) => {
+export const mergeSkillTargets = (candidates) => {
     const targets = [];
-    for (const agent of agents) {
-        const parent = await resolvePhysicalDirectory(path.join(base, agent.directory, "skills"));
-        const physicalParent = path.join(parent.ancestorPath, ...parent.missingComponents);
-        const targetPath = path.join(physicalParent, "using-daynight");
-        const existing = targets.find((target) => comparisonPath(target.path) === comparisonPath(targetPath));
-        if (existing !== undefined)
-            existing.agents.push(agent);
+    for (const candidate of candidates) {
+        const existing = targets.find((target) => comparisonPath(target.path) === comparisonPath(candidate.path));
+        if (existing === undefined)
+            targets.push({ ...candidate, agents: [...candidate.agents] });
         else
-            targets.push({ path: targetPath, legacyPath: path.join(physicalParent, "daynight"), parent: physicalParent, ancestor: parent.ancestorPath, missingParents: parent.missingComponents, agents: [agent] });
+            for (const agent of candidate.agents)
+                if (!existing.agents.some(({ id }) => id === agent.id))
+                    existing.agents.push(agent);
     }
     for (const [index, first] of targets.entries()) {
         for (const second of targets.slice(index + 1)) {
@@ -33,4 +32,13 @@ export const planSkillTargets = async (base, agents) => {
     }
     return targets;
 };
+export const planSkillTargets = async (base, agents) => {
+    const targets = [];
+    for (const agent of agents) {
+        const parent = await resolvePhysicalDirectory(path.join(base, agent.directory, "skills"));
+        const physicalParent = path.join(parent.ancestorPath, ...parent.missingComponents);
+        targets.push({ path: path.join(physicalParent, "using-daynight"), legacyPath: path.join(physicalParent, "daynight"), parent: physicalParent, ancestor: parent.ancestorPath, missingParents: parent.missingComponents, agents: [agent] });
+    }
+    return mergeSkillTargets(targets);
+};
 //# sourceMappingURL=targets.js.map