@skrr-ai/cli 0.1.109 → 0.1.111

package/dist/commands/triggers/fire-detail.js

@@ -1,8 +1,36 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.describeFireAuditDetail = describeFireAuditDetail;
 const core_1 = require("@oclif/core");
 const base_command_1 = require("../../base-command");
 const triggers_1 = require("../../lib/triggers");
+/**
+ * The text rendering of one fire. `reason` is the typed code and `errorMessage` the sentence a
+ * person reads; the view printed whichever came first, so a fire that resolved nothing showed
+ * only `Reason: no_waiting_step` and its sentence ("No step in this Space was waiting on that
+ * event key.") was JSON-only (OSK-16474). Both are shown now when both exist.
+ */
+function describeFireAuditDetail(detail, fireId, triggerId) {
+    const text = (value) => (typeof value === 'string' && value.trim() ? value.trim() : '');
+    const lines = [
+        `Fire:         ${String(detail._id ?? fireId)}`,
+        `Trigger:      ${String(detail.triggerId ?? triggerId)}`,
+        `Fired at:     ${String(detail.firedAt ?? '-')}`,
+        `Outcome:      ${String(detail.outcome ?? '-')}`,
+        `Source:       ${String(detail.source ?? '-')}`,
+    ];
+    const reason = text(detail.reason);
+    const message = text(detail.errorMessage);
+    if (reason)
+        lines.push(`Reason:       ${reason}`);
+    if (message && message !== reason)
+        lines.push(`${reason ? 'Detail:' : 'Reason:'}       ${message}`);
+    if (detail.durationMs !== undefined)
+        lines.push(`Duration:     ${String(detail.durationMs)}ms`);
+    if (detail.conversationId)
+        lines.push(`Conversation: ${String(detail.conversationId)}`);
+    return lines;
+}
 class TriggersFireDetail extends base_command_1.BaseCommand {
     static description = 'Show full detail for one trigger fire record';
     static examples = [
@@ -34,18 +62,8 @@ class TriggersFireDetail extends base_command_1.BaseCommand {
             this.log(JSON.stringify(detail, null, 2));
             return;
         }
-        this.log(`Fire:         ${detail._id ?? args.fireId}`);
-        this.log(`Trigger:      ${detail.triggerId ?? args.id}`);
-        this.log(`Fired at:     ${detail.firedAt ?? '-'}`);
-        this.log(`Outcome:      ${detail.outcome ?? '-'}`);
-        this.log(`Source:       ${detail.source ?? '-'}`);
-        if (detail.reason || detail.errorMessage) {
-            this.log(`Reason:       ${detail.reason ?? detail.errorMessage}`);
-        }
-        if (detail.durationMs !== undefined)
-            this.log(`Duration:     ${detail.durationMs}ms`);
-        if (detail.conversationId)
-            this.log(`Conversation: ${detail.conversationId}`);
+        for (const line of describeFireAuditDetail(detail, args.fireId, args.id))
+            this.log(line);
     }
 }
 exports.default = TriggersFireDetail;

package/dist/commands/triggers/fire.js

@@ -46,9 +46,17 @@ class TriggersFire extends base_command_1.BaseCommand {
         }
         const accepted = (0, triggers_1.fireWasAccepted)(result);
         if (flags.json) {
-            this.log(JSON.stringify(result, null, 2));
-            if (flags.strict && !accepted)
+            // `ok` and the exit status are one answer: a strict refusal prints `ok: false` and why,
+            // never the server's transport-level `ok: true` beside exit 1 (OSK-16494).
+            const refused = flags.strict && !accepted;
+            this.log(JSON.stringify(refused
+                ? { ...result, ok: false, strictRefusal: (0, triggers_1.describeStrictFireRefusal)(result) }
+                : result, null, 2));
+            if (refused) {
+                // stdout stays the one JSON document; the reason goes to stderr.
+                process.stderr.write(`${(0, triggers_1.describeStrictFireRefusal)(result)}\n`);
                 this.exit(1);
+            }
             return;
         }
         this.log(`Fire requested: outcome=${String(result.outcome ?? '-')} reason=${String(result.reason ?? '-')}`);
@@ -57,8 +65,10 @@ class TriggersFire extends base_command_1.BaseCommand {
         const note = (0, triggers_1.describeScheduledFire)(result);
         if (note)
             this.log(note);
-        if (flags.strict && !accepted)
+        if (flags.strict && !accepted) {
+            process.stderr.write(`${(0, triggers_1.describeStrictFireRefusal)(result)}\n`);
             this.exit(1);
+        }
     }
 }
 exports.default = TriggersFire;

package/dist/commands/triggers/list.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+const list_output_1 = require("../../lib/list-output");
 const core_1 = require("@oclif/core");
 const base_command_1 = require("../../base-command");
 const triggers_1 = require("../../lib/triggers");
@@ -41,7 +42,7 @@ class TriggersList extends base_command_1.BaseCommand {
             this.handleApiError(err);
         }
         if (flags.json) {
-            this.log(JSON.stringify(response, null, 2));
+            this.printJsonResult((0, list_output_1.listResult)(response, 'triggers'));
             return;
         }
         (0, triggers_1.renderTriggerList)(response.triggers ?? [], (line) => this.log(line));

package/dist/commands/triggers/parse-intent.js

@@ -26,7 +26,7 @@ class TriggersParseIntent extends base_command_1.BaseCommand {
             multiple: true,
         }),
         'history-json': core_1.Flags.string({
-            description: 'Parser history JSON array of {role:"user"|"assistant",content:string} objects. To answer a clarifying question, pass the `history` a previous --json run returned and add your reply with --message',
+            description: 'Parser history: an inline JSON array of {role:"user"|"assistant",content:string} objects, or @file / a path to a file holding it. To answer a clarifying question, pass the `history` a previous --json run returned and add your reply with --message',
         }),
         timezone: core_1.Flags.string({ description: 'IANA timezone used for relative times' }),
         now: core_1.Flags.string({ description: 'Override current ISO timestamp used for relative times' }),

package/dist/commands/triggers/update.js

@@ -56,7 +56,7 @@ class TriggersUpdate extends base_command_1.BaseCommand {
             description: 'ISO-8601 datetime after which a schedule stops firing',
         }),
         'stale-catchup-ms': core_1.Flags.integer({
-            description: 'How late a missed occurrence may still run, in ms (a positive number). After downtime, an occurrence more than this overdue is skipped rather than run late, and the schedule moves to its next future slot. Unset: 3600000 (1 hour).',
+            description: 'How late a missed occurrence may still run, in ms, from 1000 (1 second) to 31622400000 (366 days). After downtime, an occurrence more than this overdue is skipped rather than run late, and the schedule moves to its next future slot. Unset: 3600000 (1 hour).',
         }),
         at: core_1.Flags.string({ description: 'ISO-8601 datetime for once triggers' }),
         entity: core_1.Flags.string({

package/dist/commands/views/list.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+const list_output_1 = require("../../lib/list-output");
 const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const base_command_1 = require("../../base-command");
@@ -24,7 +25,7 @@ class ViewsList extends base_command_1.BaseCommand {
             url: (0, web_url_1.taskViewUrl)(this.cliConfig.baseURL, view.id),
         }));
         if (flags.json)
-            return void this.log(JSON.stringify({ ...response, data }, null, 2));
+            return void this.printJsonResult((0, list_output_1.listResult)({ ...response, data }));
         if (!data.length)
             return void this.log('No personalized Task Views.');
         (0, format_1.renderTable)(data.map((view) => ({

package/dist/commands/webhooks/list.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+const list_output_1 = require("../../lib/list-output");
 const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const base_command_1 = require("../../base-command");
@@ -23,7 +24,7 @@ class WebhooksList extends base_command_1.BaseCommand {
                 retryable: false,
             });
         try {
-            this.log(JSON.stringify(await data_provider_1.dataService.listTaskWebhooks(scope, id), null, 2));
+            this.printJsonResult((0, list_output_1.listResult)(await data_provider_1.dataService.listTaskWebhooks(scope, id)));
         }
         catch (error) {
             this.handleApiError(error);

package/dist/commands/whoami.js

@@ -118,7 +118,7 @@ class Whoami extends base_command_1.BaseCommand {
             atRestEncryption,
         };
         if (flags.json) {
-            this.log(JSON.stringify(payload, null, 2));
+            this.printJsonResult(payload);
             return;
         }
         this.log(`Account:        ${user.email}`);

package/dist/commands/widgets/list.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+const list_output_1 = require("../../lib/list-output");
 const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const base_command_1 = require("../../base-command");
@@ -25,7 +26,7 @@ class WidgetsList extends base_command_1.BaseCommand {
             this.handleApiError(err);
         }
         if (flags.json) {
-            this.log(this.agentJson(flags.agent, response));
+            this.printJsonResult((0, list_output_1.listResult)(JSON.parse(this.agentJson(flags.agent, response)), 'widgets'));
             return;
         }
         let items;

package/dist/commands/widgets/save-as-app.d.ts

@@ -0,0 +1,13 @@
+import { AppsCommand } from '../../lib/apps-command';
+export default class WidgetsSaveAsApp extends AppsCommand {
+    static description: string;
+    static examples: string[];
+    static args: {
+        id: import("@oclif/core/lib/interfaces").Arg<string, Record<string, unknown>>;
+    };
+    static flags: {
+        agent: import("@oclif/core/lib/interfaces").OptionFlag<string, import("@oclif/core/lib/interfaces").CustomOptions>;
+        json: import("@oclif/core/lib/interfaces").BooleanFlag<boolean>;
+    };
+    run(): Promise<void>;
+}

package/dist/commands/widgets/save-as-app.js

@@ -0,0 +1,65 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+const core_1 = require("@oclif/core");
+const data_provider_1 = require("@skrr-ai/data-provider");
+const apps_1 = require("../../lib/apps");
+const apps_command_1 = require("../../lib/apps-command");
+const appsCheck_1 = require("../../lib/appsCheck");
+const widgetApps_1 = require("../../lib/widgetApps");
+class WidgetsSaveAsApp extends apps_command_1.AppsCommand {
+    static description = 'Keep an agent widget as an app: a new private draft that starts as a copy of the widget (the widget itself is not changed). Only html widgets can be saved today. Saving the same widget twice answers the app that is already there. Check it afterwards with `apps check-draft`.';
+    static examples = [
+        '<%= config.bin %> widgets save-as-app <widget-id> --agent <agent-id>',
+        '<%= config.bin %> widgets save-as-app <widget-id> --agent <agent-id> --json',
+    ];
+    static args = {
+        id: core_1.Args.string({ description: 'Widget ID', required: true, ignoreStdin: true }),
+    };
+    static flags = {
+        agent: core_1.Flags.string({ description: 'Agent ID', required: true }),
+        json: core_1.Flags.boolean({ description: 'Output { created, app, draft, check?, lossy } as JSON' }),
+    };
+    async run() {
+        this.requireAuth();
+        const { args, flags } = await this.parse(WidgetsSaveAsApp);
+        let saved;
+        try {
+            saved = await data_provider_1.dataService.saveAgentWidgetAsApp(flags.agent, args.id);
+        }
+        catch (error) {
+            const refusal = (0, apps_1.readAppsRefusal)(error);
+            if (refusal && (0, widgetApps_1.isProjectionRefusal)(refusal.error)) {
+                return this.failWithCliError({
+                    message: (0, widgetApps_1.describeWidgetAppRefusal)(refusal),
+                    code: (0, widgetApps_1.projectionRefusalCode)(refusal.error),
+                    ...(refusal.status === undefined ? {} : { status: refusal.status }),
+                    exit: 1,
+                    retryable: false,
+                });
+            }
+            return this.failApps(error, { subject: `widget ${args.id}` });
+        }
+        if (flags.json) {
+            this.printJsonResult(saved);
+            return;
+        }
+        this.log(saved.created
+            ? `saved ${saved.app.id} (${saved.app.slug}) from widget ${args.id}`
+            : `widget ${args.id} is already saved as ${saved.app.id} (${saved.app.slug})`);
+        if (saved.draft) {
+            this.log(`rev: ${saved.draft.rev}, files: ${saved.draft.files.count}`);
+        }
+        if (saved.lossy.length > 0) {
+            this.log('not carried over:');
+            for (const loss of saved.lossy) {
+                this.log(`  - ${(0, widgetApps_1.describeProjectionLoss)(loss)}`);
+            }
+        }
+        if (saved.check) {
+            for (const line of (0, appsCheck_1.formatAppCheckReport)(saved.check))
+                this.log(line);
+        }
+        this.log(`next: \`${this.config.bin} apps check-draft ${saved.app.id}\``);
+    }
+}
+exports.default = WidgetsSaveAsApp;

package/dist/commands/work-views/list.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+const list_output_1 = require("../../lib/list-output");
 const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const base_command_1 = require("../../base-command");
@@ -19,7 +20,7 @@ class WorkViewsList extends base_command_1.BaseCommand {
             this.handleApiError(error);
         }
         if (flags.json)
-            return void this.log(JSON.stringify(result, null, 2));
+            return void this.printJsonResult((0, list_output_1.listResult)(result));
         if (result.defaultCreated)
             this.log('Created default Work View: Recent active work.');
         for (const view of result.data)

package/dist/commands/worklog/list.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+const list_output_1 = require("../../lib/list-output");
 const core_1 = require("@oclif/core");
 const base_command_1 = require("../../base-command");
 const worklogs_1 = require("../../lib/worklogs");
@@ -44,7 +45,7 @@ class WorklogList extends base_command_1.BaseCommand {
             this.handleApiError(err);
         }
         if (flags.json) {
-            this.log(JSON.stringify(response, null, 2));
+            this.printJsonResult((0, list_output_1.listResult)(response));
             return;
         }
         (0, worklogs_1.renderWorklogList)(response?.data ?? [], (line) => this.log(line));

package/dist/commands/workspaces/grants.js

@@ -39,10 +39,7 @@ async function memberNames(workspaceId) {
     try {
         const members = await (0, workspaces_1.listWorkspaceMembers)(workspaceId);
         return new Map(members
-            .map((member) => [
-            String(member.userId),
-            member.user?.name || member.user?.username || member.user?.email || '',
-        ])
+            .map((member) => [member.userId, member.name ?? member.email ?? ''])
             .filter(([, name]) => name));
     }
     catch {

package/dist/commands/workspaces/list.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+const list_output_1 = require("../../lib/list-output");
 const core_1 = require("@oclif/core");
 const base_command_1 = require("../../base-command");
 const format_1 = require("../../lib/format");
@@ -28,11 +29,11 @@ class WorkspacesList extends base_command_1.BaseCommand {
         const rows = listing.rows;
         const current = (0, config_1.selectedWorkspaceId)();
         if (flags.json) {
-            this.log(JSON.stringify({
+            this.printJsonResult((0, list_output_1.listResult)({
                 selected: current ?? null,
                 defaultWorkspaceId: listing.defaultWorkspaceId,
                 workspaces: rows.map((r) => ({ ...r, inUse: r.id === current })),
-            }, null, 2));
+            }, 'workspaces'));
             return;
         }
         if (rows.length === 0) {

package/dist/commands/workspaces/members.d.ts

@@ -14,6 +14,7 @@ export default class WorkspacesMembers extends BaseCommand {
         workspaceId: import("@oclif/core/lib/interfaces").Arg<string, Record<string, unknown>>;
     };
     static flags: {
+        'include-images': import("@oclif/core/lib/interfaces").BooleanFlag<boolean>;
         json: import("@oclif/core/lib/interfaces").BooleanFlag<boolean>;
     };
     run(): Promise<void>;

package/dist/commands/workspaces/members.js

@@ -3,6 +3,8 @@ Object.defineProperty(exports, "__esModule", { value: true });
 const core_1 = require("@oclif/core");
 const base_command_1 = require("../../base-command");
 const format_1 = require("../../lib/format");
+const list_output_1 = require("../../lib/list-output");
+const member_output_1 = require("../../lib/member-output");
 const workspaces_1 = require("../../lib/workspaces");
 /**
  * `skrr workspaces members` — who is in a workspace, with the user id the
@@ -23,20 +25,21 @@ class WorkspacesMembers extends base_command_1.BaseCommand {
     };
     static flags = {
         json: core_1.Flags.boolean({ description: 'Output as JSON' }),
+        ...member_output_1.memberImageFlags,
     };
     async run() {
         this.requireAuth();
         const { args, flags } = await this.parse(WorkspacesMembers);
         let members;
         try {
-            members = await (0, workspaces_1.listWorkspaceMembers)(args.workspaceId);
+            members = await (0, workspaces_1.listWorkspaceMembers)(args.workspaceId, { includeImages: flags['include-images'] });
         }
         catch (error) {
             this.handleApiError(error);
             return;
         }
         if (flags.json) {
-            this.log(JSON.stringify(members, null, 2));
+            this.printJsonResult((0, list_output_1.listResult)(members));
             return;
         }
         if (members.length === 0) {
@@ -44,11 +47,11 @@ class WorkspacesMembers extends base_command_1.BaseCommand {
             return;
         }
         (0, format_1.renderTable)(members.map((member) => ({
-            userId: String(member.userId),
-            name: member.user?.name || member.user?.username || '—',
-            email: member.user?.email || '—',
-            role: member.role || '—',
-            joined: member.joinedAt || '—',
+            userId: member.userId,
+            name: member.name ?? '—',
+            email: member.email ?? '—',
+            role: member.role ?? '—',
+            joined: member.joinedAt ?? '—',
         })), [
             { key: 'userId', header: 'USER ID', verbatim: true },
             { key: 'name', header: 'NAME', maxWidth: 28 },

package/dist/generated/managed-instruction-guides.json

@@ -3,7 +3,7 @@
         "key": "oversky-task-management",
         "name": "skrr Task Management",
         "templateVersion": 20,
-        "body": "## OverSky Task Management\n\nUse `skrr` as the durable record for work that must outlive this conversation.\n\n### One concept, one record\n\n- **Task** says what is owed and where it stands.\n- **Expectation** says what must be true before the Task can close.\n- **Update** says what meaningfully changed during execution.\n- **Resume Point** says where one Run can safely continue after interruption.\n- **Result** says what the work concluded or returned.\n- **Deliverable** identifies a concrete Resource version produced by the work.\n- **Review** says whether another actor accepted one exact Result.\n- **Comment** is replyable collaboration.\n- **Activity** is the immutable audit projection. A Run transcript is detailed telemetry, not Activity.\n\nDo not put a Result in a Comment, use an Update as a transcript, or use review words such as\n“approved” for a domain conclusion such as NO-SHIP.\n\nThe platform derives Human, Agent, Run, session, and recording provenance from the authenticated\nruntime. Never supply or invent an Agent identity. An Update has one author; a multi-Agent summary\nmay cite contributors and their source Runs or Updates.\n\n### During execution: write Updates at meaningful boundaries\n\nDo not log routine reads, tool calls, heartbeats, token counts, or repeated “still working” narration.\nRecord an Update only when a future reader or replacement Run needs to know that shared state changed:\n\nEach type has a REQUIRED `--data` shape, and the array fields are required even when empty.\nOptional fields are marked `?`. The server rejects a missing required field, so guessing from the\nprose costs a round trip:\n\n- `progress`: a material part is complete.\n  `{completedSinceLast: string[], nextActions: string[], currentFocus?}`\n- `finding`: a newly discovered fact. `impact` is optional; the evidence references are not.\n  `{finding, evidenceRefs: [], impact?, severity?}`\n- `decision`: a choice now constrains the work.\n  `{decision, rationale, alternativesConsidered?: string[]}`\n- `blocker`: work cannot continue. `nextOwner` is a principal OBJECT, not a name.\n  `{cause, requiredAction, nextOwner: {kind: \"human\", userId}}`\n- `verification`: a claim was checked. `result` is one of `passed`, `failed`, `inconclusive`.\n  `{claim, result, evidenceRefs: []}`\n- `ready_for_review`: created by Result submission; do not author it separately.\n\n`--reference <kind>:<id>` sets the Update's OWN references. It does not populate\n`data.evidenceRefs`, which belongs inside `--data`.\n\nUse one stable idempotency key only for retries of the identical write. Reusing it for different\ncontent is rejected.\n\nExample:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type progress \\\n  --summary \"Migration review complete\" \\\n  --data '{\"completedSinceLast\":[\"Checked migrations 001-014\"],\"currentFocus\":\"Authorization review\",\"nextActions\":[\"Inspect legacy adapters\"]}' \\\n  --idempotency-key \"<task-id>:migration-review\"\n```\n\nFor a decision:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type decision \\\n  --summary \"Use a first-class Resource identity\" \\\n  --data '{\"decision\":\"Use WorkResource plus immutable versions\",\"rationale\":\"A URL can move and cannot identify the version a reviewer accepted\"}' \\\n  --idempotency-key \"<task-id>:resource-model\"\n```\n\nFor a finding — `evidenceRefs` is required and may be empty:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type finding \\\n  --summary \"The closure gate reads assessments by exact specVersion\" \\\n  --data '{\"finding\":\"A cosmetic title edit bumps specVersion, so every prior assessment stops counting\",\"impact\":\"A task with expectations cannot be closed after a rename\",\"evidenceRefs\":[{\"kind\":\"code\",\"uri\":\"api/server/services/TaskClosurePolicy/index.js\"}]}' \\\n  --idempotency-key \"<task-id>:spec-bump-revocation\"\n```\n\nFor a blocker — `nextOwner` is a principal object:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type blocker \\\n  --summary \"Waiting on production database credentials\" \\\n  --data '{\"cause\":\"The migration needs write access to the prod cluster\",\"requiredAction\":\"Grant the deploy role write access, or run the migration yourself\",\"nextOwner\":{\"kind\":\"human\",\"userId\":\"<user-id>\"}}' \\\n  --idempotency-key \"<task-id>:needs-prod-credentials\"\n```\n\nFor a verification:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type verification \\\n  --summary \"Re-ran the closure flow end to end after the fix\" \\\n  --data '{\"claim\":\"A renamed task with one assessed expectation can close\",\"result\":\"passed\",\"evidenceRefs\":[{\"kind\":\"task\",\"id\":\"<task-id>\"}]}' \\\n  --idempotency-key \"<task-id>:closure-reverify\"\n```\n\n### Media: screenshots and recordings\n\n`--attach <path>` (repeatable) on `updates add`, `result submit`, `complete`, or `comments add`\nuploads a file as a Task asset and cites it; identical bytes dedupe. In-run proof goes on a\n`verification` or `progress` Update, the final before/after on the Result, never the description.\nAn upload is `self_reported` evidence and counts toward the storage quota. Images keep full\nresolution minus metadata (Runs get a model-sized copy); undecodable bytes get 422, a type the bytes\ncontradict 415, and SVG downloads as a file. An agent uploads evidence (the default) or\n`--role deliverable`; `input` is refused (403): ask a person to run `attachments set-role`. Cite a\ndeliverable as `--evidence task_attachment:<asset-id>` when you assess its Expectation.\n\n### Recovery: Update delta and Resume Point snapshot\n\nWhen a semantic boundary should also be resumable, add `--run-id` and `--resume` to the same Update\ncommand. The server commits the visible Update and the Run-bound Resume Point together. The snapshot\nmust be self-contained enough for another capable Agent to continue without replaying the transcript:\ncompleted work, current focus, next actions, open questions, and references to decisions, evidence,\nDeliverables, and durable workspace state.\n\nThe runtime may save a silent crash-safety snapshot with:\n\n```bash\nskrr tasks resume save <task-id> --run-id <run-id> --snapshot '<resume-json>'\n```\n\nNever put credentials, secrets, permission grants, bearer tokens, or leases in a Resume Point. A\nresumed Run reloads the current Task Revision, re-authorizes, validates referenced files/commits, and\nreads Updates recorded after the snapshot:\n\n```bash\nskrr tasks resume show <task-id> --run-id <run-id>\n```\n\n### Deliverables: lightweight input, first-class identity\n\nA user may provide one coordinate, but the platform records a WorkResource, its exact version, the\nTask relationship, and an evidence-backed availability observation. External reference is the\ndefault; OverSky-managed content is used only when retention, stable access, preview/search, or\npolicy requires a copy.\n\n```bash\nskrr tasks deliverable add <task-id> \\\n  file/markdown:docs/reviews/report.md@docs/reviews/report.md \\\n  --status in_review\n```\n\nA recording made by its producer is always self-reported; the caller cannot promote itself to a\nHuman confirmation, system observation, or provider receipt. A local path is only local availability. A commit, provider revision, digest, or managed object\nfreezes the exact version. Do not call “in the conversation” a Deliverable.\n\nA Human confirms the exact linked version, not a retyped URL or name:\n\n```bash\nskrr tasks deliverable confirm <task-id> <task-resource-link-id> --reason \"Opened and checked this exact version\"\n```\n\n### Result and Review are separate\n\nSubmit the finished answer once:\n\n```bash\nskrr tasks result submit <task-id> \\\n  --summary \"NO-SHIP until remediation Gates A-D pass\" \\\n  --conclusion-type release_recommendation \\\n  --conclusion-json '{\"posture\":\"no_ship\"}' \\\n  --deliverable <task-resource-link-id>\n```\n\nAn amendment creates a new Result version and explicitly supersedes the previous one. There is one\ncurrent Result; old versions remain in Activity and are not ordinary Updates.\n\nOnly another actor records acceptance, against that exact Result:\n\n```bash\nskrr tasks review <task-id> --result-id <result-id> --decision accepted --rationale \"Evidence checked\"\n```\n\n“Accepted” means the submitted work was accepted. NO-SHIP, BUY, REJECT, root cause, experiment\ndecision, and similar subject-matter conclusions belong in `Result.conclusion`, never in Review.\n\nUse `skrr tasks complete` only when submitting the Result and advancing workflow in one closeout.\nDo not call `tasks report` before or after it; `tasks complete` already creates the canonical Result.\n\nSubmitting a Result is not the same as closing the Task, and being an Agent is not by itself a\nreason to stop. Closing is always the closer's call — unmet Expectations or a Changes-requested\nReview do not prevent it; they are RECORDED on the close (`resolution.closure`), so closing over\nthem hides nothing and settles nothing. The one exception is an owner-declared required Review\n(`--review-policy required`): a non-owner cannot close without it — unless they close with\n`--force`, which records the override on the resolution — and the owner always can.\n\nSo do not predict the outcome. `result submit` reports where the Task stands after the write —\nread that, and if you need to ask again later:\n\n```bash\nskrr tasks expectations <task-id>     # what is owed, and why the Result cannot be accepted yet\n```\n\nSay “ready for review” only when something you read actually said so.\n\n### Expectations\n\nExpectations are free text first. A typed check explains how the statement can be assessed; it never\nreplaces the sentence.\n\nAn Expectation is an obligation, not a lock: it does not stop a close, it is recorded on one — and\nclosing over it settles nothing. Write each one so it can\nbe judged — say what would satisfy it and how that could be checked — because an Expectation authored\nwithout a thought about verification is one you will later be unable to settle honestly. When you\ncreate several across several Tasks, say how many you created and who they fall to; a set of gates\nnobody was told about is work assigned by accident. A Deliverable requirement is one typed Expectation, not a second\n`requiredDeliverables` list. Actual Deliverables are recorded only after something exists.\n\nRead what is owed, then settle it — never rewrite the declaration to make it settleable:\n\n```bash\nskrr tasks expectations <task-id>                       # what is owed, and how far each one got\nskrr tasks expectations assess <task-id> <expectation-id> \\\n  --decision met \\\n  --reason \"Ran the suite named in the statement; 49/49 pass\" \\\n  --evidence code:<commit>\nskrr tasks expectations assess <task-id> --all \\\n  --decision met --reason \"...\"                         # every one still awaiting a judgement\n```\n\n**You may assess any Expectation that takes a judgement.** A `deliverable` Expectation is not one —\nit settles through its linked Resource and evidence, so record the Deliverable rather than\nassessing it. The assessment is recorded as YOURS — every surface shows `met (agent)` against\n`met (person)` — and a human can override it. The control is attribution, not permission, so what\nyou owe is not restraint but evidence: cite what you actually checked, and prefer `--evidence` and\n`--resource-link-id` over prose.\n\nAssess what you VERIFIED. Not what you intended, not what you inferred from having finished the\nwork. “I could not check this” is a real and useful answer — record it `unmet` with the reason\nrather than leaving it silent, because an unassessed Expectation and one you tried and failed to\nverify send the next reader to different places.\n\nA waiver is a judgement about scope — that this is no longer owed — and it stays a person's call:\nif the honest answer is \"this should be waived,\" say so in an Update or Comment and let a person\nrecord it. Do not delete the Expectation to hide that it was owed.\n\nChanging an Expectation's wording advances the Task specification and **revokes every assessment\nalready recorded** — fix the statement before people start settling it, not after.\n\n### Labels — say what PROGRAM this belongs to\n\nA label is cross-cutting classification: which recurring program a Space or Task\nbelongs to (`dogfood`, `incident`, `experiment`, `migration`), not what state it\nis in. Status, priority and assignee are first-class fields and already answer\ntheir own questions — a label that restates one is noise that will drift out of\nsync with the field it copies.\n\nThe vocabulary is DECLARED, not invented. Read it before you use it:\n\n```bash\nskrr labels list\n```\n\nAttach from that list, never a name you made up. A second spelling of an\nexisting label (`dog-food` beside `dogfood`) is worse than no label at all,\nbecause the whole value of one is that filtering on it returns everything:\n\n```bash\nskrr spaces labels add <space-id> --label <label-id>\nskrr tasks labels attach <task-id> --label <label-id>\n```\n\nCreate a label only when the program it names is real and recurring, and say\nwhich entities it applies to — a label created without `--applicable-to space`\ncannot be attached to a Space, which is how a vocabulary comes to exist that\nnothing can use:\n\n```bash\nskrr labels create --name <name> --applicable-to space --applicable-to task\n```\n\nWhen you create a Space or Task for a recurring program, label it as you create\nit (`--label <id>` on `spaces`, `tasks` and `goals create`). The create\nresponse carries a `_labelGuidance` hint naming the applicable vocabulary WITH\nITS IDS when you attached none — read it, and attach in one follow-up call if\none of them fits. It may also carry `suggested` — a proposal, not a decision;\nattach is your call. `skrr tasks labels suggest <task-id>` asks it of a Task.\n\nIf nothing in the vocabulary fits, attach nothing. \"No label\" is a correct\nanswer and a wrong label is not.\n\n### Comments and blockers\n\nUse a Comment only for a question, answer, or review discussion where a reply is useful. For a\nblocker, first record the typed blocker Update, then move the Task to blocked. Add a Comment only if\nsomeone actually needs to respond.\n\n### Creating and placing Tasks\n\nCreate a Task without asking when work needs tracking across meaningful steps, sessions, or\nfollow-up. Avoid duplicates and do not create Tasks for trivial actions that finish immediately.\n\n```bash\nskrr tasks list --q \"<relevant title>\"\nskrr tasks create --title \"<concise requested result>\" --description \"<scope and constraints>\" --json\nskrr tasks move <task-id> --status in_progress\n```\n\nA Space is a durable ownership, collaboration, and authorization boundary. Use an identified Space\nwhen the work clearly belongs there; otherwise create the Task unscoped. Ask before creating a new\nSpace. An Agent works a Task in a Space only as a Space member, or when it is shared with no one\nelse and its owner assigns and starts it; anything else is refused. Do not widen Agent membership\nmerely to force one task assignment.\n\n### Closing a Task out\n\nThe model above says what each record IS. This is the order they go in, and what each step can\nrefuse:\n\n1. **Record what exists** — `skrr tasks deliverable add`, binding it to the Expectation it answers\n   with `--expectation <id>` whenever one applies. Evidence that arrives bound is evidence the next\n   reader does not have to reconstruct.\n2. **Submit the answer** — `skrr tasks result submit`. This does not close the Task. Read what it\n   reports back.\n3. **Read what is still owed** — `skrr tasks expectations <task-id>`.\n4. **Settle what you verified** — `skrr tasks expectations assess`, citing evidence. `--all` covers\n   every Expectation still awaiting a judgement.\n5. **Read the Task state again and report THAT** — not what you intended it to be.\n\nTwo things still matter regardless of how complete the work is: an unmet Expectation, and a\n`changes_requested` Review. Neither blocks a close — but both are stamped onto it\n(`resolution.closure`), so closing over them is a recorded choice, not a clean finish. Neither is\na failure state; both are somebody's turn.\n\nStep 5 is the one that goes wrong quietly, and not only here: before reporting a check as passed,\nconfirm you measured what you think you measured. A pipeline's exit status is the LAST command's, so\n`cmd | tail` reports on `tail`. A filter may match something other than what you meant — a path\npattern can match the directory you are working in. When a result will be reported to a person as\nfact, re-run it in the simplest form that can only mean one thing.\n\nAcross a whole Space, `skrr tasks review-queue --space <space-id>` names every outstanding\njudgement at once, with its evidence and the command that settles it.\n\n### Share readable links and close the loop\n\nShare clickable Task, Space, Goal, and Commitment URLs, never bare IDs. Use the URL returned by the\nCLI; do not construct one. If needed:\n\n```bash\nskrr tasks show <task-id> --json\nskrr spaces show <space-id> --json\nskrr goals show <goal-id> --json\nskrr commitments show <commitment-id> --json\n```\n\nBefore your final response, verify every Task you created or touched reflects reality. If work is\nready for independent review, leave it in review. If blocked, record the blocker and required action.\nIf genuinely complete and accepted under the Task's policy, close it. Include the Task URL in the\nfinal handoff. Never claim a write succeeded unless the CLI returned success.\n\n### Coming back later\n\nYou can arrange to return to something. Four shapes, and picking the right one\nmatters more than the wording:\n\n**Reminder** — the user asked to be reminded. Keep their words; a reminder you\nhave rephrased into your own voice is no longer the thing they asked for.\n\n**Watch** — something has an asynchronous tail: CI, a review, an approval, a\nlong job, a metric. If the condition is machine-checkable (an endpoint plus a\npredicate), say so — that costs nothing and is guaranteed to terminate. Only\nwrite a prose check recipe when the check genuinely needs your judgement or your\ntools, because that one burns a full turn every time it runs. Always give it an\nabort condition: a watch that cannot stop is a leak.\n\n**Check-in** — you decided the conversation is worth returning to. This is\npermission AND restraint. Come back when you will have something worth saying —\na result that will have arrived, a decision that will be ripe, a thread you left\ngenuinely open. When you see one, arrange the return yourself and say in one\nline when you will look again. Do not ask whether you should: that hands the\nperson a decision they did not come to make. Do not come back to ask how it is\ngoing. One conversation holds at most one pending check-in, and when you wake,\nsaying nothing is a legitimate outcome and often the right one.\n\n**Act** — a specific action you already know how to take and the user has already\nagreed to. Not for anything you would still need to ask about.\n\nSettle what you arranged. When you wake and the thing resolved, say so and close\nit out; when it did not, either come back once more with a reason or hand it to\nthe person. Leaving one armed forever is the failure mode here.\n\nFrom a local session, arrange these with `skrr followups` —\n`remind`, `watch`, `checkin`, `act` — and settle them with\n`skrr followups resolve <id> --outcome resolved`.\n\n## OverSky Identity\n\n{{OVERSKY_AGENT_IDENTITY}}\n",
-        "hash": "516df90a15e3ced2bcdb9976aec9f9b433478f2886df7cc04276d6ad44ffcde2"
+        "body": "## OverSky Task Management\n\nUse `skrr` as the durable record for work that must outlive this conversation.\n\n### One concept, one record\n\n- **Task** says what is owed and where it stands.\n- **Expectation** says what must be true before the Task can close.\n- **Update** says what meaningfully changed during execution.\n- **Resume Point** says where one Run can safely continue after interruption.\n- **Result** says what the work concluded or returned.\n- **Deliverable** identifies a concrete Resource version produced by the work.\n- **Review** says whether another actor accepted one exact Result.\n- **Comment** is replyable collaboration.\n- **Activity** is the immutable audit projection. A Run transcript is detailed telemetry, not Activity.\n\nDo not put a Result in a Comment, use an Update as a transcript, or use review words such as\n“approved” for a domain conclusion such as NO-SHIP.\n\nThe platform derives Human, Agent, Run, session, and recording provenance from the authenticated\nruntime. Never supply or invent an Agent identity. An Update has one author; a multi-Agent summary\nmay cite contributors and their source Runs or Updates.\n\n### During execution: write Updates at meaningful boundaries\n\nDo not log routine reads, tool calls, heartbeats, token counts, or repeated “still working” narration.\nRecord an Update only when a future reader or replacement Run needs to know that shared state changed:\n\nEach type has a REQUIRED `--data` shape, and the array fields are required even when empty.\nOptional fields are marked `?`. The server rejects a missing required field, so guessing from the\nprose costs a round trip:\n\n- `progress`: a material part is complete.\n  `{completedSinceLast: string[], nextActions: string[], currentFocus?}`\n- `finding`: a newly discovered fact. `impact` is optional; the evidence references are not.\n  `{finding, evidenceRefs: [], impact?, severity?}`\n- `decision`: a choice now constrains the work.\n  `{decision, rationale, alternativesConsidered?: string[]}`\n- `blocker`: work cannot continue. `nextOwner` is a principal OBJECT, not a name.\n  `{cause, requiredAction, nextOwner: {kind: \"human\", userId}}`\n- `verification`: a claim was checked. `result` is one of `passed`, `failed`, `inconclusive`.\n  `{claim, result, evidenceRefs: []}`\n- `ready_for_review`: created by Result submission; do not author it separately.\n\n`--reference <kind>:<id>` sets the Update's OWN references. It does not populate\n`data.evidenceRefs`, which belongs inside `--data`.\n\nUse one stable idempotency key only for retries of the identical write. Reusing it for different\ncontent is rejected.\n\nExample:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type progress \\\n  --summary \"Migration review complete\" \\\n  --data '{\"completedSinceLast\":[\"Checked migrations 001-014\"],\"currentFocus\":\"Authorization review\",\"nextActions\":[\"Inspect legacy adapters\"]}' \\\n  --idempotency-key \"<task-id>:migration-review\"\n```\n\nFor a decision:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type decision \\\n  --summary \"Use a first-class Resource identity\" \\\n  --data '{\"decision\":\"Use WorkResource plus immutable versions\",\"rationale\":\"A URL can move and cannot identify the version a reviewer accepted\"}' \\\n  --idempotency-key \"<task-id>:resource-model\"\n```\n\nFor a finding — `evidenceRefs` is required and may be empty:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type finding \\\n  --summary \"The closure gate reads assessments by exact specVersion\" \\\n  --data '{\"finding\":\"A cosmetic title edit bumps specVersion, so every prior assessment stops counting\",\"impact\":\"A task with expectations cannot be closed after a rename\",\"evidenceRefs\":[{\"kind\":\"code\",\"uri\":\"api/server/services/TaskClosurePolicy/index.js\"}]}' \\\n  --idempotency-key \"<task-id>:spec-bump-revocation\"\n```\n\nFor a blocker — `nextOwner` is a principal object:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type blocker \\\n  --summary \"Waiting on production database credentials\" \\\n  --data '{\"cause\":\"The migration needs write access to the prod cluster\",\"requiredAction\":\"Grant the deploy role write access, or run the migration yourself\",\"nextOwner\":{\"kind\":\"human\",\"userId\":\"<user-id>\"}}' \\\n  --idempotency-key \"<task-id>:needs-prod-credentials\"\n```\n\nFor a verification:\n\n```bash\nskrr tasks updates add <task-id> \\\n  --type verification \\\n  --summary \"Re-ran the closure flow end to end after the fix\" \\\n  --data '{\"claim\":\"A renamed task with one assessed expectation can close\",\"result\":\"passed\",\"evidenceRefs\":[{\"kind\":\"task\",\"id\":\"<task-id>\"}]}' \\\n  --idempotency-key \"<task-id>:closure-reverify\"\n```\n\n### Media: screenshots and recordings\n\n`--attach <path>` (repeatable) on `updates add`, `result submit`, `complete`, or `comments add`\nuploads a file as a Task asset and cites it; identical bytes dedupe. In-run proof goes on a\n`verification` or `progress` Update, the final before/after on the Result, never the description.\nAn upload is `self_reported` evidence and counts toward the storage quota. Images keep full\nresolution minus metadata (Runs get a model-sized copy); undecodable bytes get 422, a type the bytes\ncontradict 415, and SVG downloads as a file. An agent uploads evidence (the default) or\n`--role deliverable`; `input` is refused (403): ask a person to run `attachments set-role`. Cite a\ndeliverable as `--evidence task_attachment:<asset-id>` when you assess its Expectation.\n\n### Recovery: Update delta and Resume Point snapshot\n\nWhen a semantic boundary should also be resumable, add `--run-id` and `--resume` to the same Update\ncommand. The server commits the visible Update and the Run-bound Resume Point together. The snapshot\nmust be self-contained enough for another capable Agent to continue without replaying the transcript:\ncompleted work, current focus, next actions, open questions, and references to decisions, evidence,\nDeliverables, and durable workspace state.\n\nThe runtime may save a silent crash-safety snapshot with:\n\n```bash\nskrr tasks resume save <task-id> --run-id <run-id> --snapshot '<resume-json>'\n```\n\nNever put credentials, secrets, permission grants, bearer tokens, or leases in a Resume Point. A\nresumed Run reloads the current Task Revision, re-authorizes, validates referenced files/commits, and\nreads Updates recorded after the snapshot:\n\n```bash\nskrr tasks resume show <task-id> --run-id <run-id>\n```\n\n### Deliverables: lightweight input, first-class identity\n\nA user may provide one coordinate, but the platform records a WorkResource, its exact version, the\nTask relationship, and an evidence-backed availability observation. External reference is the\ndefault; OverSky-managed content is used only when retention, stable access, preview/search, or\npolicy requires a copy.\n\n```bash\nskrr tasks deliverable add <task-id> \\\n  file/markdown:docs/reviews/report.md@docs/reviews/report.md \\\n  --status in_review\n```\n\nA recording made by its producer is always self-reported; the caller cannot promote itself to a\nHuman confirmation, system observation, or provider receipt. A local path is only local availability. A commit, provider revision, digest, or managed object\nfreezes the exact version. Do not call “in the conversation” a Deliverable.\n\nA Human confirms the exact linked version, not a retyped URL or name:\n\n```bash\nskrr tasks deliverable confirm <task-id> <task-resource-link-id> --reason \"Opened and checked this exact version\"\n```\n\n### Result and Review are separate\n\nSubmit the finished answer once:\n\n```bash\nskrr tasks result submit <task-id> \\\n  --summary \"NO-SHIP until remediation Gates A-D pass\" \\\n  --conclusion-type release_recommendation \\\n  --conclusion-json '{\"posture\":\"no_ship\"}' \\\n  --deliverable <task-resource-link-id>\n```\n\nAn amendment creates a new Result version and explicitly supersedes the previous one. There is one\ncurrent Result; old versions remain in Activity and are not ordinary Updates.\n\nOnly another actor records acceptance, against that exact Result:\n\n```bash\nskrr tasks review <task-id> --result-id <result-id> --decision accepted --rationale \"Evidence checked\"\n```\n\n“Accepted” means the submitted work was accepted. NO-SHIP, BUY, REJECT, root cause, experiment\ndecision, and similar subject-matter conclusions belong in `Result.conclusion`, never in Review.\n\nUse `skrr tasks complete` only when submitting the Result and advancing workflow in one closeout.\nDo not call `tasks report` before or after it; `tasks complete` already creates the canonical Result.\n\nSubmitting a Result is not the same as closing the Task, and being an Agent is not by itself a\nreason to stop. Closing is always the closer's call — unmet Expectations or a Changes-requested\nReview do not prevent it; they are RECORDED on the close (`resolution.closure`), so closing over\nthem hides nothing and settles nothing. The one exception is an owner-declared required Review\n(`--review-policy required`): a non-owner cannot close without it — unless they close with\n`--force`, which records the override on the resolution — and the owner always can.\n\nSo do not predict the outcome. `result submit` reports where the Task stands after the write —\nread that, and if you need to ask again later:\n\n```bash\nskrr tasks expectations <task-id>     # what is owed, and why the Result cannot be accepted yet\n```\n\nSay “ready for review” only when something you read actually said so.\n\n### Expectations\n\nExpectations are free text first. A typed check explains how the statement can be assessed; it never\nreplaces the sentence.\n\nAn Expectation is an obligation, not a lock: it does not stop a close, it is recorded on one — and\nclosing over it settles nothing. Write each one so it can\nbe judged — say what would satisfy it and how that could be checked — because an Expectation authored\nwithout a thought about verification is one you will later be unable to settle honestly. When you\ncreate several across several Tasks, say how many you created and who they fall to; a set of gates\nnobody was told about is work assigned by accident. A Deliverable requirement is one typed Expectation, not a second\n`requiredDeliverables` list. Actual Deliverables are recorded only after something exists.\n\nRead what is owed, then settle it — never rewrite the declaration to make it settleable:\n\n```bash\nskrr tasks expectations <task-id>                       # what is owed, and how far each one got\nskrr tasks expectations assess <task-id> <expectation-id> \\\n  --decision met \\\n  --reason \"Ran the suite named in the statement; 49/49 pass\" \\\n  --evidence code:<commit>\nskrr tasks expectations assess <task-id> --all \\\n  --decision met --reason \"...\"                         # every one still awaiting a judgement\n```\n\n**You may assess any Expectation that takes a judgement.** A `deliverable` Expectation is not one —\nit settles through its linked Resource and evidence, so record the Deliverable rather than\nassessing it. The assessment is recorded as YOURS — every surface shows `met (agent)` against\n`met (person)` — and a human can override it. The control is attribution, not permission, so what\nyou owe is not restraint but evidence: cite what you actually checked, and prefer `--evidence` and\n`--resource-link-id` over prose.\n\nAssess what you VERIFIED. Not what you intended, not what you inferred from having finished the\nwork. “I could not check this” is a real and useful answer — record it `unmet` with the reason\nrather than leaving it silent, because an unassessed Expectation and one you tried and failed to\nverify send the next reader to different places.\n\nA waiver is a judgement about scope — that this is no longer owed — and it stays a person's call:\nif the honest answer is \"this should be waived,\" say so in an Update or Comment and let a person\nrecord it. Do not delete the Expectation to hide that it was owed.\n\nChanging an Expectation's wording advances the Task specification and **revokes every assessment\nalready recorded** — fix the statement before people start settling it, not after.\n\n### Labels — say what PROGRAM this belongs to\n\nA label is cross-cutting classification: which recurring program a Space or Task\nbelongs to (`dogfood`, `incident`, `experiment`, `migration`), not what state it\nis in. Status, priority and assignee are first-class fields and already answer\ntheir own questions — a label that restates one is noise that will drift out of\nsync with the field it copies.\n\nThe vocabulary is DECLARED, not invented. Read it before you use it:\n\n```bash\nskrr labels list\n```\n\nAttach from that list, never a name you made up. A second spelling of an\nexisting label (`dog-food` beside `dogfood`) is worse than no label at all,\nbecause the whole value of one is that filtering on it returns everything:\n\n```bash\nskrr spaces labels add <space-id> --label <label-id>\nskrr tasks labels attach <task-id> --label <label-id>\n```\n\nCreate a label only when the program it names is real and recurring, and say\nwhich entities it applies to — a label created without `--applicable-to space`\ncannot be attached to a Space, which is how a vocabulary comes to exist that\nnothing can use:\n\n```bash\nskrr labels create --name <name> --applicable-to space --applicable-to task\n```\n\nWhen you create a Space or Task for a recurring program, label it as you create\nit (`--label <id>` on `spaces`, `tasks` and `goals create`). The create\nresponse carries a `_labelGuidance` hint naming the applicable vocabulary WITH\nITS IDS when you attached none — read it, and attach in one follow-up call if\none of them fits. It may also carry `suggested` — a proposal, not a decision;\nattach is your call. `skrr tasks labels suggest <task-id>` asks it of a Task.\n\nIf nothing in the vocabulary fits, attach nothing. \"No label\" is a correct\nanswer and a wrong label is not.\n\n### Comments and blockers\n\nUse a Comment only for a question, answer, or review discussion where a reply is useful. For a\nblocker, first record the typed blocker Update, then move the Task to blocked. Add a Comment only if\nsomeone actually needs to respond.\n\n### Creating and placing Tasks\n\nCreate a Task without asking when work needs tracking across meaningful steps, sessions, or\nfollow-up. Avoid duplicates and do not create Tasks for trivial actions that finish immediately.\n\n```bash\nskrr tasks list --q \"<relevant title>\"\nskrr tasks create --title \"<concise requested result>\" --description \"<scope and constraints>\" --json\nskrr tasks move <task-id> --status in_progress\n```\n\nA Space is a durable ownership, collaboration, and authorization boundary. Use an identified Space\nwhen the work clearly belongs there; otherwise create the Task unscoped. Ask before creating a new\nSpace. An Agent works a Task in a Space only as a Space member, or when it is shared with no one\nelse and its owner assigns and starts it; anything else is refused. Do not widen Agent membership\nmerely to force one task assignment.\n\n### Closing a Task out\n\nThe model above says what each record IS. This is the order they go in, and what each step can\nrefuse:\n\n1. **Record what exists** — `skrr tasks deliverable add`, binding it to the Expectation it answers\n   with `--expectation <id>` whenever one applies. Evidence that arrives bound is evidence the next\n   reader does not have to reconstruct.\n2. **Submit the answer** — `skrr tasks result submit`. This does not close the Task. Read what it\n   reports back.\n3. **Read what is still owed** — `skrr tasks expectations <task-id>`.\n4. **Settle what you verified** — `skrr tasks expectations assess`, citing evidence. `--all` covers\n   every Expectation still awaiting a judgement.\n5. **Read the Task state again and report THAT** — not what you intended it to be.\n\nTwo things still matter regardless of how complete the work is: an unmet Expectation, and a\n`changes_requested` Review. Neither blocks a close — but both are stamped onto it\n(`resolution.closure`), so closing over them is a recorded choice, not a clean finish. Neither is\na failure state; both are somebody's turn.\n\nStep 5 is the one that goes wrong quietly, and not only here: before reporting a check as passed,\nconfirm you measured what you think you measured. A pipeline's exit status is the LAST command's, so\n`cmd | tail` reports on `tail`. A filter may match something other than what you meant — a path\npattern can match the directory you are working in. When a result will be reported to a person as\nfact, re-run it in the simplest form that can only mean one thing.\n\nAcross a whole Space, `skrr tasks review-queue --space <space-id>` names every outstanding\njudgement at once, with its evidence and the command that settles it.\n\n### Share readable links and close the loop\n\nShare clickable Task, Space, Goal, and Commitment URLs, never bare IDs. Use the URL returned by the\nCLI; do not construct one. If needed:\n\n```bash\nskrr tasks show <task-id> --json\nskrr spaces show <space-id> --json\nskrr goals show <goal-id> --json\nskrr commitments show <commitment-id> --json\n```\n\nBefore your final response, verify every Task you created or touched reflects reality. If work is\nready for independent review, leave it in review. If blocked, record the blocker and required action.\nIf genuinely complete and accepted under the Task's policy, close it. Include the Task URL in the\nfinal handoff. Never claim a write succeeded unless the CLI returned success.\n\n### Coming back later\n\nYou can arrange to return to something. Four shapes, and picking the right one\nmatters more than the wording:\n\n**Reminder** — the user asked to be reminded. Keep their words; a reminder you\nhave rephrased into your own voice is no longer the thing they asked for.\n\n**Watch** — something has an asynchronous tail: CI, a review, an approval, a\nlong job, a metric. If the condition is machine-checkable (an endpoint plus a\npredicate), say so — that costs nothing and is guaranteed to terminate. Only\nwrite a prose check recipe when the check genuinely needs your judgement or your\ntools, because that one burns a full turn every time it runs. Always give it an\nabort condition: a watch that cannot stop is a leak.\n\n**Check-in** — you decided the conversation is worth returning to. This is\npermission AND restraint. Come back when you will have something worth saying —\na result that will have arrived, a decision that will be ripe, a thread you left\ngenuinely open. When you see one, arrange the return yourself and say in one\nline when you will look again. Do not ask whether you should: that hands the\nperson a decision they did not come to make. Do not come back to ask how it is\ngoing. A legacy check-in holds one pending return per conversation. For a sequence\nof checks, use one scheduled lookback plan with 1–10 lifetime steps. When you\nwake, read the original goal, current state and earlier outcomes. Saying\nnothing is a legitimate outcome and often the right one. Stop or cancel\nremaining checks when the work resolves, becomes obsolete or the person cancels.\n\n**Act** — a specific action you already know how to take and the user has already\nagreed to. Not for anything you would still need to ask about.\n\nSettle what you arranged. When you wake and the thing resolved, say so and close\nit out; when it did not, either come back once more with a reason or hand it to\nthe person. Leaving one armed forever is the failure mode here.\n\nFrom a local session, arrange these with `skrr followups` —\n`remind`, `watch`, `checkin`, `act` — and settle them with\n`skrr followups resolve <id> --outcome resolved`.\nFor a bounded lookback plan, use `skrr followups plans create --from-json plan.json`\nand inspect, revise or cancel it with `skrr followups plans` (read `--help`).\nUse 1–10 concrete checks, relative offsets from the completed reply or explicit\nabsolute/local times, and a stop condition. Omit a plan when none is useful.\nA saved plan is not necessarily armed; read the returned receipt before promising a return.\n\n## OverSky Identity\n\n{{OVERSKY_AGENT_IDENTITY}}\n",
+        "hash": "fbcf9890668d5534321ccabafc5fc1ef82b79b3de86f3f097ff82f11c7ac5e34"
     }
 }

package/dist/help.js

@@ -75,6 +75,13 @@ class SkrrHelp extends core_1.Help {
             }
             throw new Error((0, command_miss_1.describeCommandMiss)(lookup, id));
         }
+        if (id === 'tasks' && this.config.findCommand('tasks:guide')) {
+            this.log('TASK OPERATIONS');
+            this.log(`  ${this.config.bin} tasks guide              Find planning, dependencies, execution, and result commands.`);
+            if (this.config.findCommand('tasks:preflight'))
+                this.log(`  ${this.config.bin} tasks preflight <task>   Inspect blockers and execution prerequisites without starting work.`);
+            this.log('');
+        }
         return super.showHelp(argv);
     }
 }

package/dist/lib/agent-proactive-baseline.d.ts

@@ -0,0 +1,9 @@
+import type { AgentCreationDisposition, AgentProactiveBaseline } from '@skrr-ai/data-provider';
+/**
+ * Human lines for the read-only proactive baseline an Always-On status carries
+ * (`proactiveBaseline`) and for a creation receipt (`proactive`). The server
+ * owns every fact and every repair command; this only lays them out. An
+ * unreadable fact prints as `unknown`, never as missing.
+ */
+export declare function proactiveBaselineLines(b?: AgentProactiveBaseline | null): string[];
+export declare function creationDispositionLines(p?: AgentCreationDisposition | null): string[];

package/dist/lib/agent-proactive-baseline.js

@@ -0,0 +1,44 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.proactiveBaselineLines = proactiveBaselineLines;
+exports.creationDispositionLines = creationDispositionLines;
+/**
+ * Human lines for the read-only proactive baseline an Always-On status carries
+ * (`proactiveBaseline`) and for a creation receipt (`proactive`). The server
+ * owns every fact and every repair command; this only lays them out. An
+ * unreadable fact prints as `unknown`, never as missing.
+ */
+function proactiveBaselineLines(b) {
+    if (!b)
+        return [];
+    const ARMED_WORD = { true: 'on', false: 'off', null: 'unknown' };
+    const armed = ARMED_WORD[String(b.armed)] ?? 'unknown';
+    const loops = b.systemLoops.status === 'unknown'
+        ? 'unknown'
+        : `${b.systemLoops.present.length}/${b.systemLoops.expected.length}` +
+            (b.systemLoops.paused.length ? ` (paused: ${b.systemLoops.paused.join(', ')})` : '') +
+            (b.systemLoops.missing.length ? ` (missing: ${b.systemLoops.missing.join(', ')})` : '');
+    const watchers = b.watchers.status === 'unknown'
+        ? 'unknown'
+        : `${b.watchers.total} (${b.watchers.enabled} enabled; separate from Always-On)`;
+    const lines = [
+        `Baseline:         Always-On ${armed}; policy ${b.policy.source}; Compass ${b.compass.source}`,
+    ];
+    const quiet = b.policy.quietHours;
+    if (quiet) {
+        lines.push(`Quiet hours:      ${quiet.enabled
+            ? `${quiet.start ?? '?'}-${quiet.end ?? '?'} ${quiet.timezone ?? '(no zone recorded)'}`
+            : 'disabled'}`);
+    }
+    lines.push(`System loops:     ${loops}`);
+    lines.push(`Watchers:         ${watchers}`);
+    lines.push(`Model-run ceiling: ${b.dailyModelRunCeiling}/day (declared by the system loops)`);
+    for (const gap of b.gaps)
+        lines.push(`  ${gap.code}: ${gap.fix}`);
+    return lines;
+}
+function creationDispositionLines(p) {
+    if (!p)
+        return [];
+    return [p.reason, ...(p.enable ? [`  ${p.enable.cli}`] : [])];
+}

package/dist/lib/agentic-stream.d.ts

@@ -1,3 +1,4 @@
+import { type AssistantTextJoiner } from '@skrr-ai/data-provider';
 /**
  * Why a question was dismissed when no terminal exists to ask it on. It is the
  * REASON for a dismissal, never an answer: it travels as the value of the
@@ -256,7 +257,7 @@ export declare function describePermissionTarget(toolInput: unknown): string | n
  * word.SECOND" as its answer, and `run.result.text` kept it, because the
  * stream then held the final result as a suffix and the longer text won.
  */
-export declare function envelopesText(event: AgenticStreamEvent): string;
+export declare function envelopesText(event: AgenticStreamEvent, joiner?: AssistantTextJoiner, accumulated?: string): string;
 /**
  * Stable identity of one `session:output` envelope, for deduping re-delivered
  * frames (OSK-4834).
@@ -507,6 +508,8 @@ export declare class AgenticStreamClient {
     private settled;
     private closed;
     private accumulated;
+    /** Where a tool call fell in the envelopes folded into `accumulated` (OSK-16934). */
+    private readonly textJoiner;
     /** Highest envelope `__seq` folded into `accumulated`, for gap detection. */
     private highestSeq;
     private readonly pendingEnvelopes;