@skrr-ai/cli 0.1.22 → 0.1.23

package/dist/lib/task-extras.js

@@ -42,11 +42,7 @@ exports.taskLookupApi = {
      */
     followUp: (id, body) => data_provider_1.request.post(`${base(id)}/follow-up`, body),
     cancelFollowUp: (id) => data_provider_1.request.post(`${base(id)}/follow-up/cancel`, {}),
-    /**
-     * Atomic completion: moves the task AND writes the TASK_OUTPUT comment in one
-     * request, so a crash between the two cannot leave a done task with no record
-     * of what it produced.
-     */
+    /** Result-first closeout: submit one immutable Result, then project status. */
     complete: (id, body) => data_provider_1.request.post(`${base(id)}/complete`, body),
     treePosition: (id, body) => data_provider_1.request.patch(`${base(id)}/tree-position`, body),
     createAndStart: (body) => data_provider_1.request.post(`${MOUNT}/create-and-start`, body),

package/dist/lib/task-transcript.d.ts

@@ -13,7 +13,7 @@ export type ParsedTaskOutput = {
     verdict: string;
 };
 /**
- * Parsed `---TASK_OUTPUT---` block plus the comment it came from.
+ * Parsed historical `---TASK_OUTPUT---` block plus the Comment it came from.
  */
 export type TaskOutputComment = {
     commentId: string;
@@ -36,9 +36,9 @@ export type TaskOutputComment = {
 /**
  * Mirror of `api/server/services/taskCompletionFormatting.js:parseTaskOutputBlock`.
  * Kept as a CLI-local copy on purpose — the CLI cannot import from `api/`, and
- * the block format is a wire contract (`skrr tasks complete` writes it, the
- * server responders read it), not an implementation detail. Keep the two in
- * lockstep, including the single-line field semantics: the `m` flag makes `$`
+ * the block format is a historical wire contract, not an implementation
+ * detail. Keep the two compatibility readers in lockstep, including the
+ * single-line field semantics: the `m` flag makes `$`
  * match at each line end, so a value stops at its own newline. That is correct
  * by construction — `tasks complete` collapses `[\r\n]+` to spaces before
  * writing — but a hand-authored block CAN carry continuation lines, which this
@@ -63,9 +63,7 @@ export declare function normalizeMessage(message: Record<string, unknown>): Tran
 export declare function selectWindow<T>(items: T[], limit: number | null, head?: boolean): T[];
 export declare function fetchTranscript(conversationId: string): Promise<TranscriptMessage[]>;
 /**
- * Newest `---TASK_OUTPUT---` comment on a task, or null when the agent never
- * posted one (still running, failed before finalization, or completed by a path
- * that skipped the canonical block).
+ * Newest historical `---TASK_OUTPUT---` Comment, or null when none exists.
  */
 export declare function fetchLatestTaskOutputComment(taskId: string, limit?: number): Promise<TaskOutputComment | null>;
 /** Last message the agent (not the user) produced in the execution conversation. */

package/dist/lib/task-transcript.js

@@ -14,25 +14,19 @@ exports.unverifiedOutcomeNote = unverifiedOutcomeNote;
 /**
  * Task → agent-response plumbing for the `skrr` CLI.
  *
- * A task's real output is spread across three surfaces:
- *   1. `task.conversationId` → the execution conversation, i.e. the messages the
- *      agent actually produced (`skrr tasks transcript`).
- *   2. A `---TASK_OUTPUT---` comment posted by `skrr tasks complete` / the
- *      TasksMCP completion path — the structured verdict.
- *   3. The run rows (`tasks runs` / `execution-summary`) — did it even finish.
- *
- * Nothing tied those together, so "what did the agent produce for this task?"
- * meant three commands plus a jq hop. This module is the shared read layer for
- * `tasks transcript` and `tasks output`.
+ * Shared transcript normalization plus read-only parsing of historical
+ * TASK_OUTPUT Comments. Canonical output now lives in TaskResult, TaskReview,
+ * TaskResourceLink, and TaskExecutionRun; no writer may call the compatibility
+ * functions below.
  */
 const data_provider_1 = require("@skrr-ai/data-provider");
 const TASK_OUTPUT_FIELDS = ['status', 'summary', 'artifacts', 'verdict'];
 /**
  * Mirror of `api/server/services/taskCompletionFormatting.js:parseTaskOutputBlock`.
  * Kept as a CLI-local copy on purpose — the CLI cannot import from `api/`, and
- * the block format is a wire contract (`skrr tasks complete` writes it, the
- * server responders read it), not an implementation detail. Keep the two in
- * lockstep, including the single-line field semantics: the `m` flag makes `$`
+ * the block format is a historical wire contract, not an implementation
+ * detail. Keep the two compatibility readers in lockstep, including the
+ * single-line field semantics: the `m` flag makes `$`
  * match at each line end, so a value stops at its own newline. That is correct
  * by construction — `tasks complete` collapses `[\r\n]+` to spaces before
  * writing — but a hand-authored block CAN carry continuation lines, which this
@@ -121,9 +115,7 @@ async function fetchTranscript(conversationId) {
     return list.map(normalizeMessage);
 }
 /**
- * Newest `---TASK_OUTPUT---` comment on a task, or null when the agent never
- * posted one (still running, failed before finalization, or completed by a path
- * that skipped the canonical block).
+ * Newest historical `---TASK_OUTPUT---` Comment, or null when none exists.
  */
 async function fetchLatestTaskOutputComment(taskId, limit = 50) {
     const response = (await data_provider_1.dataService.listTaskComments(taskId, { limit }));

package/dist/lib/tasks.d.ts

@@ -111,7 +111,7 @@ export declare function parseDeliverableCoordinate(spec: string): {
     error: string;
 };
 /** Lifecycle values a caller may assert, for flag validation. */
-export declare const DELIVERABLE_LIFECYCLE_VALUES: readonly ["local", "in_review", "durable", "blocked", "superseded"];
+export declare const DELIVERABLE_LIFECYCLE_VALUES: readonly ["local", "in_review", "available", "unavailable", "superseded"];
 export declare function buildTaskCreatePayload(body: TaskRecord, flags?: TaskCreateFlagValues): TaskRecord;
 /**
  * The Agent this CLI process is running AS, if any.
@@ -245,27 +245,13 @@ export declare function normalizeBulkUpdateInput(input: unknown): Array<{
     patch: TaskRecord;
 }>;
 /**
- * Verdict strings the server recognises on a task completion.
+ * Historical workflow-verdict strings recognised while parsing legacy task
+ * output. Canonical completion has no `--verdict`; domain conclusions live on
+ * TaskResult and acceptance lives on TaskReview.
  *
- * `--verdict` is free text: `skrr tasks complete <id> --verdict banana`
- * succeeds and the value is permanently recorded, while `--status` beside it
- * is enumerated and rejects a typo. So `--verdict aproved` closes a task with
- * a verdict nothing matches, quietly.
- *
- * It cannot simply be enumerated, and that is the point worth recording:
- *
- *  - A REVIEWER task legitimately passes a JSON object
- *    (`{"posture":"request_changes","confidence":0.82,"criteria":[…]}`) —
- *    documented in the task-execution prompt and consumed by
- *    `normalizeReviewPosture`. `options:` on the flag would refuse it.
- *  - That normaliser accepts synonyms, and when it recognises NOTHING it does
- *    not fail — it derives the posture from the criteria instead. So a typo
- *    silently becomes whatever the criteria imply.
- *
- * Hence a warning, not a refusal, over the set the server actually matches.
- * Mirrored from `normalizeReviewPosture` in
- * `api/server/services/TasksMCP/taskExecutionHelpers.js` and pinned against it
- * by `task-verdict-parity.spec.ts`, the same way TASK_WORK_EVENT_KINDS is.
+ * Kept only so old `TASK_OUTPUT`/TaskWorkEvent readers can classify stored
+ * values consistently with `normalizeReviewPosture`. New commands must not
+ * import this vocabulary for authoring.
  */
 export declare const RECOGNIZED_TASK_VERDICTS: readonly ["request_changes", "changes_requested", "needs_changes", "needs_revision", "approved", "approve", "pass", "passed", "blocked"];
 /** The server's own normalisation, so the same spellings match here. */

package/dist/lib/tasks.js

@@ -538,8 +538,18 @@ async function applyDefaultAgentToPayload(payload, defaultAgent, opts = {}) {
     }
     if (hasExplicitTaskAssignee(payload)) {
         return {
+            // `applied` is about the DEFAULT, not about the assignment. It reads the
+            // other way: a caller who named `--assignee-agent` and got back
+            // `{applied: false, source: 'explicit-assignee'}` stopped and went to
+            // verify with `tasks show`, where the assignment was perfectly correct —
+            // on the one output a scripted caller would check before `tasks start`
+            // (OSK-7712). The two subfields together assert the opposite of what they
+            // mean. Renaming the field would break every existing reader, so the
+            // note — which exists for exactly this, "an explanation for the operator,
+            // not an error" — says it instead.
             applied: false,
             source: 'explicit-assignee',
+            note: 'You named the assignee, so no default was applied. The assignment is in place.',
             agentIds: stringArray(payload.assigneeAgentIds),
             userIds: stringArray(payload.assigneeUserIds),
         };
@@ -548,6 +558,7 @@ async function applyDefaultAgentToPayload(payload, defaultAgent, opts = {}) {
         return {
             applied: false,
             source: 'existing-assignee',
+            note: 'The task already had an assignee, so no default was applied. It is unchanged.',
             agentIds: stringArray(opts.existingTask?.assigneeAgentIds),
             userIds: stringArray(opts.existingTask?.assigneeUserIds),
         };
@@ -809,27 +820,13 @@ function formatApiError(err) {
     return String(err);
 }
 /**
- * Verdict strings the server recognises on a task completion.
+ * Historical workflow-verdict strings recognised while parsing legacy task
+ * output. Canonical completion has no `--verdict`; domain conclusions live on
+ * TaskResult and acceptance lives on TaskReview.
  *
- * `--verdict` is free text: `skrr tasks complete <id> --verdict banana`
- * succeeds and the value is permanently recorded, while `--status` beside it
- * is enumerated and rejects a typo. So `--verdict aproved` closes a task with
- * a verdict nothing matches, quietly.
- *
- * It cannot simply be enumerated, and that is the point worth recording:
- *
- *  - A REVIEWER task legitimately passes a JSON object
- *    (`{"posture":"request_changes","confidence":0.82,"criteria":[…]}`) —
- *    documented in the task-execution prompt and consumed by
- *    `normalizeReviewPosture`. `options:` on the flag would refuse it.
- *  - That normaliser accepts synonyms, and when it recognises NOTHING it does
- *    not fail — it derives the posture from the criteria instead. So a typo
- *    silently becomes whatever the criteria imply.
- *
- * Hence a warning, not a refusal, over the set the server actually matches.
- * Mirrored from `normalizeReviewPosture` in
- * `api/server/services/TasksMCP/taskExecutionHelpers.js` and pinned against it
- * by `task-verdict-parity.spec.ts`, the same way TASK_WORK_EVENT_KINDS is.
+ * Kept only so old `TASK_OUTPUT`/TaskWorkEvent readers can classify stored
+ * values consistently with `normalizeReviewPosture`. New commands must not
+ * import this vocabulary for authoring.
  */
 exports.RECOGNIZED_TASK_VERDICTS = [
     'request_changes',

package/dist/lib/triggers.d.ts

@@ -93,8 +93,27 @@ export interface TriggerDefinition {
     selfScheduled?: Record<string, unknown>;
     form?: Record<string, unknown>;
     chatMessage?: Record<string, unknown>;
-    audit?: Record<string, unknown>;
+    /**
+     * Fire outcomes. Typed rather than `Record<string, unknown>` for the fields
+     * the summary prints, so a reader cannot be shown a count the compiler never
+     * checked — `fireCount` is SUCCESSES and `failureCount` is failures, and
+     * conflating them is the confusion this shape exists to prevent (OSK-7842).
+     */
+    audit?: {
+        fireCount?: number;
+        failureCount?: number;
+        lastResult?: string;
+        lastError?: string;
+        lastFiredAt?: string;
+        [key: string]: unknown;
+    };
     webhook?: Record<string, unknown>;
+    /** Whether the SCHEDULER has actually heard of this trigger. See `armedLabel`. */
+    scheduleSync?: {
+        status?: string;
+        lastError?: string;
+        lastErrorAt?: string;
+    };
     /**
      * Server-DERIVED: maintained by a managed producer, so the mutation routes
      * refuse to edit or remove it. Optional because a server predating the field
@@ -303,6 +322,25 @@ export declare class AgentTriggerScopeError extends Error {
 export declare function fetchAgentScopedTrigger(agentId: string, triggerId: string): Promise<TriggerDefinition>;
 export declare function scopeLabel(trigger: TriggerDefinition): string;
 export declare function nextRunLabel(trigger: TriggerDefinition): string;
+/**
+ * Whether a trigger will actually fire — not merely whether someone left it on.
+ *
+ * `enabled` means "not manually disabled", and two states diverge from it
+ * permanently:
+ *
+ *   `!sync`  — `enabled: true` with `scheduleSync.status` not `ok`. The row is
+ *     on to every read surface and the scheduler has never heard of it. Twenty
+ *     triggers were left in exactly this state in ninety minutes of production,
+ *     and nothing on the agent, trigger or schedule surfaces reported it — so
+ *     an operator looking at an enabled trigger had no reason to doubt it
+ *     (OSK-7727).
+ *   `spent`  — a `once` trigger that has fired. It has no next occurrence, so
+ *     `enabled` and "will fire again" diverge forever after the single fire; an
+ *     agent that has been used for a while accumulates a growing list of
+ *     `enabled: true` rows whose obvious reading is "these are armed"
+ *     (OSK-7711).
+ */
+export declare function armedLabel(trigger: TriggerDefinition): string;
 export declare function renderTriggerList(triggers: TriggerDefinition[], log: (line: string) => void): void;
 /**
  * The `duplicate_subscription` warning a create response may carry, as the

package/dist/lib/triggers.js

@@ -28,6 +28,7 @@ exports.agentRefEntity = agentRefEntity;
 exports.fetchAgentScopedTrigger = fetchAgentScopedTrigger;
 exports.scopeLabel = scopeLabel;
 exports.nextRunLabel = nextRunLabel;
+exports.armedLabel = armedLabel;
 exports.renderTriggerList = renderTriggerList;
 exports.formatDuplicateSubscriptionWarning = formatDuplicateSubscriptionWarning;
 exports.armedStateLabel = armedStateLabel;
@@ -711,6 +712,35 @@ function nextRunLabel(trigger) {
         '';
     return next ? String(next) : '-';
 }
+/**
+ * Whether a trigger will actually fire — not merely whether someone left it on.
+ *
+ * `enabled` means "not manually disabled", and two states diverge from it
+ * permanently:
+ *
+ *   `!sync`  — `enabled: true` with `scheduleSync.status` not `ok`. The row is
+ *     on to every read surface and the scheduler has never heard of it. Twenty
+ *     triggers were left in exactly this state in ninety minutes of production,
+ *     and nothing on the agent, trigger or schedule surfaces reported it — so
+ *     an operator looking at an enabled trigger had no reason to doubt it
+ *     (OSK-7727).
+ *   `spent`  — a `once` trigger that has fired. It has no next occurrence, so
+ *     `enabled` and "will fire again" diverge forever after the single fire; an
+ *     agent that has been used for a while accumulates a growing list of
+ *     `enabled: true` rows whose obvious reading is "these are armed"
+ *     (OSK-7711).
+ */
+function armedLabel(trigger) {
+    if (trigger.enabled === false)
+        return 'no';
+    const sync = trigger.scheduleSync?.status;
+    if (sync && sync !== 'ok')
+        return `!${sync}`;
+    if (trigger.kind === 'once' && trigger.once && trigger.once.firedAt) {
+        return 'spent';
+    }
+    return 'yes';
+}
 function renderTriggerList(triggers, log) {
     if (triggers.length === 0) {
         log('No triggers.');
@@ -719,18 +749,25 @@ function renderTriggerList(triggers, log) {
     (0, format_1.renderTable)(triggers.map((trigger) => ({
         id: trigger.id ?? '-',
         kind: trigger.kind ?? '-',
-        enabled: trigger.enabled === false ? 'no' : 'yes',
+        enabled: armedLabel(trigger),
         scope: scopeLabel(trigger),
         next: nextRunLabel(trigger),
         label: trigger.label ?? '',
     })), [
         { key: 'id', header: 'ID', verbatim: true },
         { key: 'kind', header: 'KIND', maxWidth: 14 },
-        { key: 'enabled', header: 'ON' },
+        { key: 'enabled', header: 'ARMED' },
         { key: 'scope', header: 'SCOPE', maxWidth: 42 },
         { key: 'next', header: 'NEXT/LAST', maxWidth: 24 },
         { key: 'label', header: 'LABEL', maxWidth: 32 },
     ], log);
+    const unsynced = triggers.filter((t) => armedLabel(t).startsWith('!'));
+    if (unsynced.length > 0) {
+        log('');
+        log(`${unsynced.length} trigger(s) are enabled but the scheduler has not registered them — ` +
+            'they will not fire until the orphan reconciler succeeds. ' +
+            'See `scheduleSync.lastError` in `triggers show <id> --json`.');
+    }
 }
 /**
  * The `duplicate_subscription` warning a create response may carry, as the
@@ -841,6 +878,37 @@ function renderTriggerSummary(trigger, log, options = {}) {
     const next = nextRunLabel(trigger);
     if (next !== '-')
         log(`Next/last:${next.length > 0 ? ` ${next}` : ''}`);
+    /*
+     * What actually happened when it fired.
+     *
+     * This summary printed nothing about outcomes at all: two one-shot runs
+     * fired, died, and the only surface that held the reason was `audit.lastError`
+     * in raw `--json` (OSK-7842). And the count alone misleads in the same
+     * direction, because `fireCount` counts SUCCESSES — so a trigger that fails
+     * every single time reads `fires 0` next to a recent fire time, which is what
+     * a trigger that has never run looks like too.
+     *
+     * Both numbers are therefore printed together, and only when there is
+     * something to say. `failureCount` is absent on rows last written before it
+     * existed, so it is reported only when present rather than defaulted to 0 —
+     * "not counted" must not render as "never failed".
+     */
+    const audit = trigger.audit;
+    if (audit) {
+        const fires = audit.fireCount ?? 0;
+        const failures = audit.failureCount;
+        if (fires > 0 || failures !== undefined || audit.lastResult || audit.lastError) {
+            const parts = [`${fires} succeeded`];
+            if (failures !== undefined)
+                parts.push(`${failures} failed`);
+            if (audit.lastResult)
+                parts.push(`last ${audit.lastResult}`);
+            log(`Fires:    ${parts.join(', ')}`);
+        }
+        // The reason, at the surface a reader reaches for — not only in `--json`.
+        if (audit.lastError)
+            log(`Last error: ${audit.lastError}`);
+    }
     if (trigger.webhook?.configured !== undefined) {
         log(`Webhook:  ${trigger.webhook.configured ? 'configured' : 'not configured'}`);
     }

package/dist/lib/usage-discovery.d.ts

@@ -6,7 +6,23 @@ import type { CommandManifest } from './command-manifest';
  * domain. These smaller views are derived from that same manifest; there is no
  * second, hand-maintained command catalogue to drift from the binary.
  */
-export declare const USAGE_OVERVIEW_TOKEN_BUDGET = 200;
+/**
+ * A bound on an agent's FIRST read, not an inventory of today's topics.
+ *
+ * The overview is one header line plus every domain name, so its cost grows
+ * linearly with the topic count — and it had reached exactly 200, meaning the
+ * next legitimate domain anyone added failed the hygiene audit no matter how
+ * small it was. Adding four commands under `api-keys` measured 201. A guard
+ * pinned to the current total stops expressing "keep the first read cheap" and
+ * starts expressing "do not add topics", which is not what it is for.
+ *
+ * Raised with headroom rather than to exactly fit, so the next person does not
+ * have to make this same judgment for one token. If it is reached again, the
+ * better question is whether the new commands have a natural home in an
+ * existing domain — folding is preferable to a new topic when one exists — and
+ * only then whether the bound is still the right size.
+ */
+export declare const USAGE_OVERVIEW_TOKEN_BUDGET = 240;
 export declare const USAGE_DOMAIN_TOKEN_BUDGET = 500;
 export type UsageCommand = {
     command: string;

package/dist/lib/usage-discovery.js

@@ -17,7 +17,23 @@ const command_manifest_1 = require("./command-manifest");
  * domain. These smaller views are derived from that same manifest; there is no
  * second, hand-maintained command catalogue to drift from the binary.
  */
-exports.USAGE_OVERVIEW_TOKEN_BUDGET = 200;
+/**
+ * A bound on an agent's FIRST read, not an inventory of today's topics.
+ *
+ * The overview is one header line plus every domain name, so its cost grows
+ * linearly with the topic count — and it had reached exactly 200, meaning the
+ * next legitimate domain anyone added failed the hygiene audit no matter how
+ * small it was. Adding four commands under `api-keys` measured 201. A guard
+ * pinned to the current total stops expressing "keep the first read cheap" and
+ * starts expressing "do not add topics", which is not what it is for.
+ *
+ * Raised with headroom rather than to exactly fit, so the next person does not
+ * have to make this same judgment for one token. If it is reached again, the
+ * better question is whether the new commands have a natural home in an
+ * existing domain — folding is preferable to a new topic when one exists — and
+ * only then whether the bound is still the right size.
+ */
+exports.USAGE_OVERVIEW_TOKEN_BUDGET = 240;
 exports.USAGE_DOMAIN_TOKEN_BUDGET = 500;
 const GENERIC_FLAGS = new Set(['bare', 'help', 'json', 'token', 'workspace']);
 /**