@codetreker/daynight 0.13.1 → 0.17.2

package/dist/commands/skill/refresh-installed.js

@@ -0,0 +1,17 @@
+import { readFile } from "node:fs/promises";
+import { fileURLToPath } from "node:url";
+import { withCliCancellation } from "../../cli/cancellation.js";
+import { createCliContext } from "../../cli/context.js";
+import { formatError } from "../../platform/diagnostics.js";
+import { refreshInstalledSkills } from "./refresh.js";
+try {
+    const packageDirectory = fileURLToPath(new URL("../../../", import.meta.url));
+    const manifest = JSON.parse(await readFile(new URL("../../../package.json", import.meta.url), "utf8"));
+    const context = createCliContext(manifest.version, packageDirectory);
+    await withCliCancellation(context, (signal) => refreshInstalledSkills(context, signal, { processGroup: "inherit" }));
+}
+catch (cause) {
+    process.stderr.write(`${formatError(cause)}\n`);
+    process.exitCode = 1;
+}
+//# sourceMappingURL=refresh-installed.js.map

package/dist/commands/skill/refresh-installed.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"refresh-installed.js","sourceRoot":"","sources":["../../../src/commands/skill/refresh-installed.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,MAAM,kBAAkB,CAAC;AAC5C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AACzC,OAAO,EAAE,mBAAmB,EAAE,MAAM,2BAA2B,CAAC;AAChE,OAAO,EAAE,gBAAgB,EAAE,MAAM,sBAAsB,CAAC;AACxD,OAAO,EAAE,WAAW,EAAE,MAAM,+BAA+B,CAAC;AAC5D,OAAO,EAAE,sBAAsB,EAAE,MAAM,cAAc,CAAC;AAEtD,IAAI,CAAC;IACH,MAAM,gBAAgB,GAAG,aAAa,CAAC,IAAI,GAAG,CAAC,WAAW,EAAE,OAAO,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;IAC9E,MAAM,QAAQ,GAAG,IAAI,CAAC,KAAK,CAAC,MAAM,QAAQ,CAAC,IAAI,GAAG,CAAC,uBAAuB,EAAE,OAAO,IAAI,CAAC,GAAG,CAAC,EAAE,MAAM,CAAC,CAAwB,CAAC;IAC9H,MAAM,OAAO,GAAG,gBAAgB,CAAC,QAAQ,CAAC,OAAO,EAAE,gBAAgB,CAAC,CAAC;IACrE,MAAM,mBAAmB,CAAC,OAAO,EAAE,CAAC,MAAM,EAAE,EAAE,CAAC,sBAAsB,CAAC,OAAO,EAAE,MAAM,EAAE,EAAE,YAAY,EAAE,SAAS,EAAE,CAAC,CAAC,CAAC;AACvH,CAAC;AAAC,OAAO,KAAK,EAAE,CAAC;IACf,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,GAAG,WAAW,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;IAChD,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;AACvB,CAAC"}

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

@@ -0,0 +1,4 @@
+import type { CliContext } from "../../cli/context.js";
+import type { RepositoryGitOptions } from "../../repository/git.js";
+export declare const findSkillProjectRoot: (cwd: string, signal: AbortSignal, gitOptions?: Pick<RepositoryGitOptions, "processGroup">) => Promise<string | undefined>;
+export declare const refreshInstalledSkills: (context: CliContext, signal: AbortSignal, gitOptions?: Pick<RepositoryGitOptions, "processGroup">) => Promise<void>;

package/dist/commands/skill/refresh.js

@@ -0,0 +1,87 @@
+import { lstat } from "node:fs/promises";
+import path from "node:path";
+import { createOperation } from "../../api/operation.js";
+import { discoverWorktreeRoot } from "../../repository/git.js";
+import { skillAgents } from "./agents.js";
+import { captureInstalledSkill, installSkillTargets, SkillInstallationError } from "./install.js";
+import { mergeSkillTargets, planSkillTargets } from "./targets.js";
+const isMissing = (cause) => cause instanceof Error && "code" in cause && cause.code === "ENOENT";
+export const findSkillProjectRoot = async (cwd, signal, gitOptions = {}) => {
+    let directory = path.resolve(cwd);
+    while (true) {
+        signal.throwIfAborted();
+        let marker = false;
+        try {
+            await lstat(path.join(directory, ".git"));
+            marker = true;
+        }
+        catch (cause) {
+            if (!isMissing(cause))
+                throw cause;
+        }
+        if (marker) {
+            const operation = createOperation({ signal, limits: { totalMs: 30_000 } });
+            try {
+                return await discoverWorktreeRoot(cwd, operation, gitOptions);
+            }
+            finally {
+                operation.dispose();
+            }
+        }
+        const parent = path.dirname(directory);
+        if (parent === directory)
+            return undefined;
+        directory = parent;
+    }
+};
+const scopeName = (scope) => scope === "user" ? "User" : "Project";
+const comparisonPath = (value) => process.platform === "win32" ? value.toLowerCase() : value;
+export const refreshInstalledSkills = async (context, signal, gitOptions = {}) => {
+    signal.throwIfAborted();
+    const bases = [{ base: context.homeDirectory(), scope: "user" }];
+    const projectRoot = await findSkillProjectRoot(context.workingDirectory(), signal, gitOptions);
+    if (projectRoot !== undefined)
+        bases.push({ base: projectRoot, scope: "project" });
+    const existing = [];
+    for (const { base, scope } of bases) {
+        for (const agent of skillAgents) {
+            const target = (await planSkillTargets(base, [agent]))[0];
+            signal.throwIfAborted();
+            let entry;
+            try {
+                entry = await lstat(target.path);
+            }
+            catch (cause) {
+                if (isMissing(cause))
+                    continue;
+                throw cause;
+            }
+            if (!entry.isDirectory() && !entry.isSymbolicLink())
+                throw new Error(`Cannot refresh using-daynight skill at ${target.path}: the installed target must be a directory or symbolic link.`);
+            existing.push({ target, scope });
+        }
+    }
+    const targets = mergeSkillTargets(existing.map(({ target }) => target));
+    if (targets.length === 0)
+        return;
+    const bundle = await captureInstalledSkill(context.packageDirectory);
+    const report = (target, status, output, detail = "") => {
+        for (const entry of existing.filter((entry) => comparisonPath(entry.target.path) === comparisonPath(target.path))) {
+            for (const agent of entry.target.agents)
+                output(`${status} ${agent.name}: ${scopeName(entry.scope)} using-daynight skill at ${target.path} (package ${context.version}).${detail}\n${status === "Updated" ? `${agent.reload}\n` : ""}`);
+        }
+    };
+    try {
+        await installSkillTargets(targets, bundle, signal, (target) => report(target, "Updated", context.stdout));
+    }
+    catch (cause) {
+        if (cause instanceof SkillInstallationError) {
+            if (cause.failed !== undefined)
+                report(cause.failed, cause.installedAtFailedTarget ? "Updated" : "Failed", context.stderr, cause.installedAtFailedTarget ? ` Legacy daynight cleanup failed at ${cause.failed.legacyPath}.` : "");
+            for (const target of cause.unattempted)
+                report(target, "Not attempted", context.stderr);
+        }
+        throw cause;
+    }
+};
+//# sourceMappingURL=refresh.js.map

package/dist/commands/skill/refresh.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"refresh.js","sourceRoot":"","sources":["../../../src/commands/skill/refresh.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,EAAE,MAAM,kBAAkB,CAAC;AACzC,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,EAAE,eAAe,EAAE,MAAM,wBAAwB,CAAC;AAEzD,OAAO,EAAE,oBAAoB,EAAE,MAAM,yBAAyB,CAAC;AAE/D,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAC1C,OAAO,EAAE,qBAAqB,EAAE,mBAAmB,EAAE,sBAAsB,EAAE,MAAM,cAAc,CAAC;AAClG,OAAO,EAAE,iBAAiB,EAAE,gBAAgB,EAAE,MAAM,cAAc,CAAC;AAGnE,MAAM,SAAS,GAAG,CAAC,KAAc,EAAW,EAAE,CAAC,KAAK,YAAY,KAAK,IAAI,MAAM,IAAI,KAAK,IAAI,KAAK,CAAC,IAAI,KAAK,QAAQ,CAAC;AAEpH,MAAM,CAAC,MAAM,oBAAoB,GAAG,KAAK,EAAE,GAAW,EAAE,MAAmB,EAAE,UAAU,GAA+C,EAAE,EAA+B,EAAE;IACvK,IAAI,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC;IAClC,OAAO,IAAI,EAAE,CAAC;QACZ,MAAM,CAAC,cAAc,EAAE,CAAC;QACxB,IAAI,MAAM,GAAG,KAAK,CAAC;QACnB,IAAI,CAAC;YAAC,MAAM,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,SAAS,EAAE,MAAM,CAAC,CAAC,CAAC;YAAC,MAAM,GAAG,IAAI,CAAC;QAAC,CAAC;QACjE,OAAO,KAAK,EAAE,CAAC;YAAC,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC;gBAAE,MAAM,KAAK,CAAC;QAAC,CAAC;QACrD,IAAI,MAAM,EAAE,CAAC;YACX,MAAM,SAAS,GAAG,eAAe,CAAC,EAAE,MAAM,EAAE,MAAM,EAAE,EAAE,OAAO,EAAE,MAAM,EAAE,EAAE,CAAC,CAAC;YAC3E,IAAI,CAAC;gBAAC,OAAO,MAAM,oBAAoB,CAAC,GAAG,EAAE,SAAS,EAAE,UAAU,CAAC,CAAC;YAAC,CAAC;oBAC9D,CAAC;gBAAC,SAAS,CAAC,OAAO,EAAE,CAAC;YAAC,CAAC;QAClC,CAAC;QACD,MAAM,MAAM,GAAG,IAAI,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;QACvC,IAAI,MAAM,KAAK,SAAS;YAAE,OAAO,SAAS,CAAC;QAC3C,SAAS,GAAG,MAAM,CAAC;IACrB,CAAC;AACH,CAAC,CAAC;AAGF,MAAM,SAAS,GAAG,CAAC,KAAiB,EAAU,EAAE,CAAC,KAAK,KAAK,MAAM,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,SAAS,CAAC;AACvF,MAAM,cAAc,GAAG,CAAC,KAAa,EAAU,EAAE,CAAC,OAAO,CAAC,QAAQ,KAAK,OAAO,CAAC,CAAC,CAAC,KAAK,CAAC,WAAW,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC;AAE7G,MAAM,CAAC,MAAM,sBAAsB,GAAG,KAAK,EAAE,OAAmB,EAAE,MAAmB,EAAE,UAAU,GAA+C,EAAE,EAAiB,EAAE;IACnK,MAAM,CAAC,cAAc,EAAE,CAAC;IACxB,MAAM,KAAK,GAA0C,CAAC,EAAE,IAAI,EAAE,OAAO,CAAC,aAAa,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,CAAC,CAAC;IACxG,MAAM,WAAW,GAAG,MAAM,oBAAoB,CAAC,OAAO,CAAC,gBAAgB,EAAE,EAAE,MAAM,EAAE,UAAU,CAAC,CAAC;IAC/F,IAAI,WAAW,KAAK,SAAS;QAAE,KAAK,CAAC,IAAI,CAAC,EAAE,IAAI,EAAE,WAAW,EAAE,KAAK,EAAE,SAAS,EAAE,CAAC,CAAC;IACnF,MAAM,QAAQ,GAAmB,EAAE,CAAC;IACpC,KAAK,MAAM,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,KAAK,EAAE,CAAC;QACpC,KAAK,MAAM,KAAK,IAAI,WAAW,EAAE,CAAC;YAChC,MAAM,MAAM,GAAG,CAAC,MAAM,gBAAgB,CAAC,IAAI,EAAE,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAE,CAAC;YAC3D,MAAM,CAAC,cAAc,EAAE,CAAC;YACxB,IAAI,KAAK,CAAC;YACV,IAAI,CAAC;gBAAC,KAAK,GAAG,MAAM,KAAK,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC;YAAC,CAAC;YACzC,OAAO,KAAK,EAAE,CAAC;gBAAC,IAAI,SAAS,CAAC,KAAK,CAAC;oBAAE,SAAS;gBAAC,MAAM,KAAK,CAAC;YAAC,CAAC;YAC9D,IAAI,CAAC,KAAK,CAAC,WAAW,EAAE,IAAI,CAAC,KAAK,CAAC,cAAc,EAAE;gBAAE,MAAM,IAAI,KAAK,CAAC,0CAA0C,MAAM,CAAC,IAAI,8DAA8D,CAAC,CAAC;YAC1L,QAAQ,CAAC,IAAI,CAAC,EAAE,MAAM,EAAE,KAAK,EAAE,CAAC,CAAC;QACnC,CAAC;IACH,CAAC;IACD,MAAM,OAAO,GAAG,iBAAiB,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,EAAE,MAAM,EAAE,EAAE,EAAE,CAAC,MAAM,CAAC,CAAC,CAAC;IACxE,IAAI,OAAO,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO;IACjC,MAAM,MAAM,GAAG,MAAM,qBAAqB,CAAC,OAAO,CAAC,gBAAgB,CAAC,CAAC;IACrE,MAAM,MAAM,GAAG,CAAC,MAAmB,EAAE,MAAc,EAAE,MAA8B,EAAE,MAAM,GAAG,EAAE,EAAQ,EAAE;QACxG,KAAK,MAAM,KAAK,IAAI,QAAQ,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,cAAc,CAAC,KAAK,CAAC,MAAM,CAAC,IAAI,CAAC,KAAK,cAAc,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,EAAE,CAAC;YAClH,KAAK,MAAM,KAAK,IAAI,KAAK,CAAC,MAAM,CAAC,MAAM;gBAAE,MAAM,CAAC,GAAG,MAAM,IAAI,KAAK,CAAC,IAAI,KAAK,SAAS,CAAC,KAAK,CAAC,KAAK,CAAC,4BAA4B,MAAM,CAAC,IAAI,aAAa,OAAO,CAAC,OAAO,KAAK,MAAM,KAAK,MAAM,KAAK,SAAS,CAAC,CAAC,CAAC,GAAG,KAAK,CAAC,MAAM,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;QAC1O,CAAC;IACH,CAAC,CAAC;IACF,IAAI,CAAC;QACH,MAAM,mBAAmB,CAAC,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,CAAC,MAAM,EAAE,EAAE,CAAC,MAAM,CAAC,MAAM,EAAE,SAAS,EAAE,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC;IAC5G,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,IAAI,KAAK,YAAY,sBAAsB,EAAE,CAAC;YAC5C,IAAI,KAAK,CAAC,MAAM,KAAK,SAAS;gBAAE,MAAM,CAAC,KAAK,CAAC,MAAM,EAAE,KAAK,CAAC,uBAAuB,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,QAAQ,EAAE,OAAO,CAAC,MAAM,EACvH,KAAK,CAAC,uBAAuB,CAAC,CAAC,CAAC,sCAAsC,KAAK,CAAC,MAAM,CAAC,UAAU,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;YACzG,KAAK,MAAM,MAAM,IAAI,KAAK,CAAC,WAAW;gBAAE,MAAM,CAAC,MAAM,EAAE,eAAe,EAAE,OAAO,CAAC,MAAM,CAAC,CAAC;QAC1F,CAAC;QACD,MAAM,KAAK,CAAC;IACd,CAAC;AACH,CAAC,CAAC"}

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

@@ -6,7 +6,7 @@ description: Manage concrete work (features, bug fixes, architecture, and their
 # 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.
 
@@ -67,14 +67,13 @@ and completing `run-task` never activate it.
   Permission to create a Goal covers its discussion stages and confirmed
   in-scope breakdown, created only at the user-confirmation gates in the Goal
   protocol; unrelated work needs separate permission.
-- Creation produces `proposed` for every normal task and Goal stage. Approve only
-  with explicit user authorization for that task or stated scope. A request to
-  start a Goal discussion authorizes approval and claim of that discussion only;
-  a user-confirmed transition authorizes the next discussion under the Goal
-  protocol. Registration alone, complete plans, stage completion, implementation
-  permission, `run-task` and autopilot never imply delivery approval. Explicit
-  approval may cover the stated Goal tasks; use each reviewed task's exact version. The user can approve through CLI
-  or Web. Approval grants no execution or delivery permission.
+- 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)
@@ -90,17 +89,25 @@ and completing `run-task` never activate it.
   acceptance criteria, and evidence. Confirm resources before linking them;
   description-relative links start at this task's attachment root. Attach resources
   according to actual ownership and need; reference shared inputs at their verified
-  source. Express all prerequisites through `dependsOn` and their explicit external
-  subset through `externalDependsOn`. Ordinary edges connect confirmed work in
-  the same chain; mark a verified prerequisite from another chain as external.
+  source. Each Goal delivery task's description directly identifies the architecture
+  task and required architecture documents, including indirect successors; follow
+  the Goal protocol's reference and readback rules. Express all prerequisites through
+  `dependsOn` and their explicit external subset through `externalDependsOn`.
+  Ordinary edges connect confirmed work in 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.

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.
 
@@ -85,6 +84,10 @@ breakdown stay with the design task. Consumers identify the source task ID and
 attachment path and confirm the contents using the installed CLI's attachment
 read command. For repository inputs, use verified immutable references. Do not
 assume a `task://` scheme, cross-task relative links, or a fixed service host.
+For every Goal delivery task, list the architecture task ID and all required
+architecture document references directly in its description, including indirect
+successors. Use the Goal protocol's full attachment paths or immutable repository
+references; keep these input references separate from execution dependencies.
 Do not upload the same whole packet to every task. Create a separate snapshot
 only when the task needs an independent copy, recording its purpose, original
 source, and source revision or content identity.
@@ -154,10 +157,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
@@ -170,19 +177,19 @@ 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 only the current discussion stage and its brief;
 verify later stages and delivery tasks when their confirmation gate permits
-registration.
+registration. When registering delivery work, check every task's description,
+including indirect successors, for its architecture task ID and required document
+references, and read the referenced contents under the Goal protocol.
 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.
@@ -135,11 +134,48 @@ replacement semantics. Do not create dependencies merely to group cards.
 Upload each task's own primary Markdown and needed resources. Keep shared
 requirements with the requirements task and the solution and breakdown with the
 solution task. Consumers reference the verified source task ID and attachment
-path, or an immutable repository source. Read back every task, required attachment,
-shared input, and dependency before reporting the breakdown registered. Keep the
-solution discussion `in_progress` when registration is incomplete. If the accepted
-solution materially changes, obtain renewed user confirmation before registering
-or advancing the changed work.
+path, or an immutable repository source. Every delivery task's description must
+directly list the architecture task ID and every architecture document required
+for that task, using its full attachment path under the source task. For a
+repository document, retain the architecture task ID and use a verified immutable
+repository reference. Include applicable sections when they clarify what to read.
+This applies to indirect successors as well as delivery roots; a reference only
+in another task or the delivery task's own primary Markdown is insufficient.
+These input references do not add execution dependencies or duplicate shared
+documents.
+
+Read back every task, required attachment, shared input, and dependency before
+reporting the breakdown registered. Check each delivery task's description,
+including indirect successors, for the architecture task ID and every required
+document reference; confirm that each reference resolves to the intended readable
+content. Keep the solution discussion `in_progress` when registration is incomplete.
+If the accepted solution materially changes, obtain renewed user confirmation
+before registering or advancing the changed work.
+
+For an illustrative `architecture → A → B` chain, A delivers the upload API and B
+delivers its retry controls. B depends on A and directly names the architecture
+inputs in its description. The following task ID and paths are hypothetical;
+replace them with verified sources when registering real work:
+
+```markdown
+## Objective and scope
+Implement upload retry controls using the delivered upload API. Preserve the
+selected files and show the confirmed error-specific retry actions.
+
+## Completion conditions
+Retryable failures offer retry; permanent failures explain the required action.
+Successful retry clears the error without losing the selected files.
+
+## Architecture inputs
+Architecture task: `11111111-1111-4111-8111-111111111111`.
+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.
+```
 
 ## Preserve ownership and recover partial registration
 
@@ -158,7 +194,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 +202,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