@skrr-ai/cli 0.1.22 → 0.1.24

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-legacy.d.ts

@@ -0,0 +1,24 @@
+/**
+ * Tell a reader when an empty canonical view means "nothing happened" and when
+ * it means "this Task predates the records this view reads".
+ *
+ * Canonical Task Model v1 shipped with an explicit decision not to migrate
+ * legacy data, so a Task created before 2026-09-11 has no TaskUpdate, TaskResult
+ * or TaskActivityEvent rows — its history is in `activityLog`, `TaskWorkEvent`
+ * and TASK_OUTPUT comments. Every canonical read surface therefore answered
+ * "No activity." / "Result: none submitted" / nothing at all for Tasks with
+ * years of history, stating absence as fact.
+ *
+ * The marker is that `specVersion` is ABSENT — a field the caller can only
+ * notice by its own missingness, which is why this belongs in one helper rather
+ * than in each command.
+ */
+export declare function isLegacyTask(taskId: string): Promise<boolean>;
+/**
+ * The sentence to print instead of claiming emptiness. `surface` names what the
+ * reader just asked for, so the message says which view is empty rather than
+ * implying the Task is.
+ */
+export declare function legacyEmptyStateMessage(surface: string): string;
+/** Render the right empty state for a canonical view that came back empty. */
+export declare function emptyCanonicalView(taskId: string, surface: string): Promise<string>;

package/dist/lib/task-legacy.js

@@ -0,0 +1,48 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.isLegacyTask = isLegacyTask;
+exports.legacyEmptyStateMessage = legacyEmptyStateMessage;
+exports.emptyCanonicalView = emptyCanonicalView;
+const data_provider_1 = require("@skrr-ai/data-provider");
+/**
+ * Tell a reader when an empty canonical view means "nothing happened" and when
+ * it means "this Task predates the records this view reads".
+ *
+ * Canonical Task Model v1 shipped with an explicit decision not to migrate
+ * legacy data, so a Task created before 2026-09-11 has no TaskUpdate, TaskResult
+ * or TaskActivityEvent rows — its history is in `activityLog`, `TaskWorkEvent`
+ * and TASK_OUTPUT comments. Every canonical read surface therefore answered
+ * "No activity." / "Result: none submitted" / nothing at all for Tasks with
+ * years of history, stating absence as fact.
+ *
+ * The marker is that `specVersion` is ABSENT — a field the caller can only
+ * notice by its own missingness, which is why this belongs in one helper rather
+ * than in each command.
+ */
+async function isLegacyTask(taskId) {
+    try {
+        const task = (await data_provider_1.dataService.getTask(taskId));
+        return task !== undefined && task !== null && task.specVersion === undefined;
+    }
+    catch {
+        // Never turn a diagnostic into a failure: the caller is rendering an empty
+        // state, not making a decision.
+        return false;
+    }
+}
+/**
+ * The sentence to print instead of claiming emptiness. `surface` names what the
+ * reader just asked for, so the message says which view is empty rather than
+ * implying the Task is.
+ */
+function legacyEmptyStateMessage(surface) {
+    return (`No ${surface} recorded under the canonical Task model.\n` +
+        'This Task predates it, so its history was never migrated — read it with ' +
+        '`skrr tasks show`, `skrr tasks comments list`, or `skrr tasks transcript`.');
+}
+/** Render the right empty state for a canonical view that came back empty. */
+async function emptyCanonicalView(taskId, surface) {
+    return (await isLegacyTask(taskId))
+        ? legacyEmptyStateMessage(surface)
+        : `No ${surface} recorded yet.`;
+}

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

@@ -59,6 +59,7 @@ export type TaskCreateFlagValues = {
         description?: string;
         presetKey?: string;
     }>;
+    'review-policy'?: string;
     'start-date'?: string;
     'due-date'?: string;
     estimate?: number;
@@ -98,6 +99,37 @@ export declare function parseExpectations(specs: string[] | undefined): {
     error: string;
 };
 export declare const EXPECT_FLAG_HELP: string;
+/**
+ * What `--default-expect` means, as a value rather than a side effect.
+ *
+ * `clear` REMOVES the Space default, and it has to exist. Every Expectation gates
+ * closure and a Space default is inherited by every task created afterwards, so a
+ * default set by mistake — or one that outlived its project — gated the whole
+ * board with no way back. `tasks update --expect` already had this sentinel; the
+ * Space flag, the one the design calls "configured once and then holds", did not.
+ * The only exit was to waive the expectation on every task, which writes `dropped`
+ * into the ledger about a requirement that was never real. That is a false record,
+ * not a workaround.
+ *
+ * `null` rather than `[]`: the route declares the field `.nullable()` and the API
+ * turns null into an `$unset`, so the Space stops carrying a default instead of
+ * carrying an empty one. `undefined` means the flag was not passed and the
+ * existing default must be left exactly as it is.
+ *
+ * `clear` must be the SOLE value. Combined with an expectation it is two
+ * contradictory instructions, and honouring one of them silently is how a caller
+ * ends up with a contract they did not ask for.
+ *
+ * Extracted so the three outcomes can be tested without a command harness — the
+ * bug being fixed was in this decision, not in the HTTP call after it.
+ */
+export declare function resolveDefaultExpectations(values: string[] | undefined): {
+    ok: true;
+    value: Array<Record<string, unknown>> | null | undefined;
+} | {
+    ok: false;
+    error: string;
+};
 /**
  * Parse a deliverable coordinate. Also delegated — `:` and `@` and now `/` all
  * mean different things, and a second implementation of that grammar is how the
@@ -111,7 +143,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 +277,13 @@ export declare function normalizeBulkUpdateInput(input: unknown): Array<{
     patch: TaskRecord;
 }>;
 /**
- * Verdict strings the server recognises on a task completion.
- *
- * `--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.
+ * 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.
  *
- * 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

@@ -6,6 +6,7 @@ exports.taskUpdateMutationGuard = taskUpdateMutationGuard;
 exports.executionIsolationFromWorktreeFlag = executionIsolationFromWorktreeFlag;
 exports.parseExpectation = parseExpectation;
 exports.parseExpectations = parseExpectations;
+exports.resolveDefaultExpectations = resolveDefaultExpectations;
 exports.parseDeliverableCoordinate = parseDeliverableCoordinate;
 exports.buildTaskCreatePayload = buildTaskCreatePayload;
 exports.boundSessionAgentId = boundSessionAgentId;
@@ -156,10 +157,54 @@ const kindsForHelp = Array.isArray(data_provider_1.TASK_OUTCOME_KINDS)
 const presetsForHelp = Array.isArray(data_provider_1.EXPECTATION_PRESETS)
     ? data_provider_1.EXPECTATION_PRESETS.map((preset) => `@${preset.key}`).join(', ')
     : '@merged-to-main, @pdf-delivered';
-exports.EXPECT_FLAG_HELP = 'What this task must produce, as <kind>[/<format>][:<target>] or @<preset> — ' +
+exports.EXPECT_FLAG_HELP = 'What this task must produce. Each one GATES closure: the Task cannot enter a ' +
+    'completed state until every Expectation is assessed met or waived ' +
+    '(`tasks expectations assess`). Form: <kind>[/<format>][:<target>] or @<preset> — ' +
     `e.g. 'code:origin/main', 'file/pdf:Drive/Reports', '@merged-to-main'. ` +
     `Kinds: ${kindsForHelp}. Presets: ${presetsForHelp}. ` +
     'Anything else is stored as a plain-language expectation a person settles. Repeatable.';
+/**
+ * What `--default-expect` means, as a value rather than a side effect.
+ *
+ * `clear` REMOVES the Space default, and it has to exist. Every Expectation gates
+ * closure and a Space default is inherited by every task created afterwards, so a
+ * default set by mistake — or one that outlived its project — gated the whole
+ * board with no way back. `tasks update --expect` already had this sentinel; the
+ * Space flag, the one the design calls "configured once and then holds", did not.
+ * The only exit was to waive the expectation on every task, which writes `dropped`
+ * into the ledger about a requirement that was never real. That is a false record,
+ * not a workaround.
+ *
+ * `null` rather than `[]`: the route declares the field `.nullable()` and the API
+ * turns null into an `$unset`, so the Space stops carrying a default instead of
+ * carrying an empty one. `undefined` means the flag was not passed and the
+ * existing default must be left exactly as it is.
+ *
+ * `clear` must be the SOLE value. Combined with an expectation it is two
+ * contradictory instructions, and honouring one of them silently is how a caller
+ * ends up with a contract they did not ask for.
+ *
+ * Extracted so the three outcomes can be tested without a command harness — the
+ * bug being fixed was in this decision, not in the HTTP call after it.
+ */
+function resolveDefaultExpectations(values) {
+    if (values === undefined || values.length === 0)
+        return { ok: true, value: undefined };
+    const clears = values.filter((value) => value.trim().toLowerCase() === 'clear');
+    if (clears.length > 0 && values.length > 1) {
+        return {
+            ok: false,
+            error: '--default-expect clear removes the space default and cannot be combined with an ' +
+                'expectation. Run it alone, then set the new default.',
+        };
+    }
+    if (clears.length > 0)
+        return { ok: true, value: null };
+    const parsed = parseExpectations(values);
+    if (!parsed.ok)
+        return { ok: false, error: parsed.error };
+    return { ok: true, value: parsed.value };
+}
 /**
  * Parse a deliverable coordinate. Also delegated — `:` and `@` and now `/` all
  * mean different things, and a second implementation of that grammar is how the
@@ -214,6 +259,7 @@ function buildTaskCreatePayload(body, flags = {}) {
         assigneeUserIds: flags['assignee-user'],
         executionMode: flags['execution-mode'],
         expectations: flags.expectations,
+        reviewPolicy: flags['review-policy'],
         startDate: flags['start-date'],
         dueDate: flags['due-date'],
         estimate: flags.estimate,
@@ -538,8 +584,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 +604,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 +866,13 @@ function formatApiError(err) {
     return String(err);
 }
 /**
- * Verdict strings the server recognises on a task completion.
- *
- * `--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.
+ * 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.
  *
- * 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']);
 /**