@skrr-ai/cli 0.1.10 → 0.1.11

package/dist/commands/tasks/events/list.js

@@ -4,17 +4,33 @@ const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const base_command_1 = require("../../../base-command");
 const task_resolver_1 = require("../../../lib/task-resolver");
+const format_1 = require("../../../lib/format");
+const tasks_1 = require("../../../lib/tasks");
 class TasksEventsList extends base_command_1.BaseCommand {
     static description = 'List durable task events';
-    static args = { id: core_1.Args.string({ required: false, ignoreStdin: true }) };
+    static args = {
+        id: core_1.Args.string({
+            required: false,
+            ignoreStdin: true,
+            description: 'Task ID. Optional inside a task runtime, which supplies it',
+        }),
+    };
     static flags = {
-        task: core_1.Flags.string(),
-        json: core_1.Flags.boolean(),
-        limit: core_1.Flags.integer({ default: 50 }),
-        cursor: core_1.Flags.string(),
-        kind: core_1.Flags.string(),
-        run: core_1.Flags.string(),
-        actor: core_1.Flags.string(),
+        task: core_1.Flags.string({
+            description: 'Task ID; overrides the runtime context and the positional',
+        }),
+        json: core_1.Flags.boolean({ description: 'Output the raw event list as JSON' }),
+        limit: core_1.Flags.integer({ default: 50, description: 'Maximum events to return' }),
+        cursor: core_1.Flags.string({ description: 'Continue a previous page, from its next_cursor' }),
+        kind: core_1.Flags.string({
+            description: 'Show only events of this kind',
+            options: [...tasks_1.TASK_WORK_EVENT_KINDS],
+        }),
+        run: core_1.Flags.string({ description: 'Show only events from this execution run' }),
+        actor: core_1.Flags.string({
+            description: 'Show only events from this actor kind',
+            options: ['user', 'agent', 'system'],
+        }),
     };
     async run() {
         this.requireAuth();
@@ -33,7 +49,42 @@ class TasksEventsList extends base_command_1.BaseCommand {
         catch (error) {
             this.handleApiError(error);
         }
-        this.log(JSON.stringify(result, null, 2));
+        // This printed raw Mongo documents — `_id` and `__v` included — regardless
+        // of `--json`, which was a byte-identical no-op: the flag advertised a mode
+        // the command did not have. Its two siblings, `tasks timeline` and `tasks
+        // activity`, both render tables, so the one command an agent is pointed at
+        // for the durable ledger was the one that made you read storage internals.
+        if (flags.json) {
+            this.log(JSON.stringify(result, null, 2));
+            return;
+        }
+        const rows = (result?.data ?? []);
+        if (rows.length === 0) {
+            this.log('No events.');
+            return;
+        }
+        (0, format_1.renderTable)(rows.map((event) => ({
+            time: String(event.occurredAt ?? '-')
+                .replace('T', ' ')
+                .slice(0, 19),
+            kind: String(event.kind ?? '-'),
+            actor: String(event.actor?.kind ?? '-'),
+            summary: (0, format_1.truncate)(String(event.summary ?? '-'), 80),
+            run: String(event.executionRunId ?? '-'),
+        })), [
+            { key: 'time', header: 'TIME' },
+            { key: 'kind', header: 'KIND' },
+            { key: 'actor', header: 'ACTOR' },
+            { key: 'summary', header: 'SUMMARY', maxWidth: 80 },
+            { key: 'run', header: 'RUN', maxWidth: 24 },
+        ], (line) => this.log(line));
+        // The fuller fields (changed / next / evidence / artifacts) are on the rows
+        // and deliberately not columns — five of them would not fit a terminal.
+        // Point at the flag that has them rather than truncating them into noise.
+        this.log('');
+        this.log('Full event bodies (changed, next, evidence, artifacts): --json');
+        if (result?.next_cursor)
+            this.log(`Next page: --cursor ${result.next_cursor}`);
     }
 }
 exports.default = TasksEventsList;

package/dist/commands/tasks/output.js

@@ -94,6 +94,9 @@ class TasksOutput extends base_command_1.BaseCommand {
                     ? { report: latestReport, occurredAt: latestReportEvent?.occurredAt }
                     : null,
                 taskOutput: outputComment,
+                // Present in JSON as well, so a script can detect a task closed
+                // more than once without diffing comment bodies.
+                completionCount: outputComment ? outputComment.supersededCount + 1 : 0,
                 finalMessage,
                 messageCount: messages.length,
             }, null, 2));
@@ -104,12 +107,13 @@ class TasksOutput extends base_command_1.BaseCommand {
             conversationId,
             latestRun,
             latestReport,
+            latestReportAt: latestReportEvent?.occurredAt ? String(latestReportEvent.occurredAt) : null,
             outputComment,
             finalMessage,
             full: flags.full,
         });
     }
-    renderHuman({ task, conversationId, latestRun, latestReport, outputComment, finalMessage, full, }) {
+    renderHuman({ task, conversationId, latestRun, latestReport, latestReportAt, outputComment, finalMessage, full, }) {
         const ref = String(task.identifier ?? task.id ?? '-');
         const agents = Array.isArray(task.assigneeAgentIds) ? task.assigneeAgentIds : [];
         this.log(`Task:     ${ref} — ${task.title ?? '-'}`);
@@ -120,7 +124,13 @@ class TasksOutput extends base_command_1.BaseCommand {
             : 'never executed'}`);
         this.log('');
         if (latestReport) {
-            this.log('Outcome (task report):');
+            // Timestamped like the Verdict below it. These two blocks are selected
+            // independently — the newest task-report work event and the newest
+            // TASK_OUTPUT comment — so on a task completed more than once they can
+            // come from different completions and disagree. Undated, that was
+            // invisible.
+            const reportAt = latestReportAt ? ` · ${(0, task_transcript_1.formatTime)(latestReportAt)}` : '';
+            this.log(`Outcome (task report${reportAt}):`);
             this.log(`  ${latestReport.outcome}`);
             this.log('  findings:');
             for (const finding of latestReport.findings)
@@ -156,6 +166,16 @@ class TasksOutput extends base_command_1.BaseCommand {
             // Reconcile the three signals a parked run shows — `completed`,
             // `UNVERIFIED`, and `Last run: failed` — which otherwise read as a
             // contradiction. (OSK-4945)
+            if (outputComment.supersededCount > 0) {
+                // `tasks complete` succeeds on an already-done task and posts another
+                // block, so the canonical-looking screen can be assembled from several
+                // closeouts. Say so rather than presenting it as one record.
+                const total = outputComment.supersededCount + 1;
+                const earlier = outputComment.supersededCount === 1 ? 'block' : 'blocks';
+                this.log(`  note:      completed ${total} times — ${outputComment.supersededCount} earlier TASK_OUTPUT ${earlier} exist.`);
+                this.log('             The Outcome above may come from a different completion than this');
+                this.log('             Verdict. `skrr tasks comments list` shows every one.');
+            }
             const note = (0, task_transcript_1.unverifiedOutcomeNote)(parsed.verdict);
             if (note)
                 this.log(`  note:      ${note}`);

package/dist/commands/tasks/ready.d.ts

@@ -1,4 +1,27 @@
 import { BaseCommand } from '../../base-command';
+/**
+ * Repair oclif's required-flag copy for a flag named after a preposition. (S4 dogfood finding)
+ *
+ * oclif builds the reason as `Missing required flag ${name}` — bare, unquoted —
+ * and wraps it in `The following error occurred:`. For almost every flag that
+ * reads fine (`Missing required flag idempotency-key`). For `--for` it produces
+ *
+ *     Missing required flag for
+ *
+ * which reads as a sentence cut off mid-clause: missing a required flag FOR
+ * WHAT? The reader has to already know `for` is the flag's name to parse it,
+ * and the one reader who does not is exactly the one getting this error.
+ *
+ * Restoring the `--` makes the name unmistakably a name. The rewrite is
+ * deliberately narrow — it matches the whole reason line and leaves anything
+ * else untouched — so an oclif that changes this template degrades to today's
+ * wording rather than mangling a different message.
+ *
+ * The general form of this belongs in `BaseCommand.catch`, where it would cover
+ * every command; this is the local fix for the one flag where the ambiguity is
+ * actually harmful.
+ */
+export declare function clarifyMissingRequiredFlag(message: string): string;
 export default class TasksReady extends BaseCommand {
     static description: string;
     static examples: string[];
@@ -11,5 +34,20 @@ export default class TasksReady extends BaseCommand {
         limit: import("@oclif/core/lib/interfaces").OptionFlag<number, import("@oclif/core/lib/interfaces").CustomOptions>;
         cursor: import("@oclif/core/lib/interfaces").OptionFlag<string | undefined, import("@oclif/core/lib/interfaces").CustomOptions>;
     };
+    /**
+     * Rewrite the parse-error copy on the way out, then hand the error back
+     * unchanged in every other respect — same class, same `oclif.exit`, same
+     * `--json` envelope from `BaseCommand.catch`. Only the sentence changes.
+     */
+    protected catch(err: Error & {
+        code?: string;
+        exitCode?: number;
+        oclif?: {
+            exit?: number;
+        };
+        parse?: unknown;
+        suggestions?: unknown;
+        retryable?: boolean;
+    }): Promise<unknown>;
     run(): Promise<void>;
 }

package/dist/commands/tasks/ready.js

@@ -1,10 +1,36 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.clarifyMissingRequiredFlag = clarifyMissingRequiredFlag;
 const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const base_command_1 = require("../../base-command");
 const format_1 = require("../../lib/format");
 const web_url_1 = require("../../lib/web-url");
+/**
+ * Repair oclif's required-flag copy for a flag named after a preposition. (S4 dogfood finding)
+ *
+ * oclif builds the reason as `Missing required flag ${name}` — bare, unquoted —
+ * and wraps it in `The following error occurred:`. For almost every flag that
+ * reads fine (`Missing required flag idempotency-key`). For `--for` it produces
+ *
+ *     Missing required flag for
+ *
+ * which reads as a sentence cut off mid-clause: missing a required flag FOR
+ * WHAT? The reader has to already know `for` is the flag's name to parse it,
+ * and the one reader who does not is exactly the one getting this error.
+ *
+ * Restoring the `--` makes the name unmistakably a name. The rewrite is
+ * deliberately narrow — it matches the whole reason line and leaves anything
+ * else untouched — so an oclif that changes this template degrades to today's
+ * wording rather than mangling a different message.
+ *
+ * The general form of this belongs in `BaseCommand.catch`, where it would cover
+ * every command; this is the local fix for the one flag where the ambiguity is
+ * actually harmful.
+ */
+function clarifyMissingRequiredFlag(message) {
+    return message.replace(/Missing required flag ([A-Za-z0-9][\w-]*)$/gm, (_full, name) => `Missing required flag --${name}`);
+}
 class TasksReady extends base_command_1.BaseCommand {
     static description = 'List tasks ready for a Human or Agent, using server-owned readiness';
     static examples = [
@@ -24,6 +50,17 @@ class TasksReady extends base_command_1.BaseCommand {
         limit: core_1.Flags.integer({ description: 'Max results', default: 50 }),
         cursor: core_1.Flags.string({ description: 'Pagination cursor from a previous page' }),
     };
+    /**
+     * Rewrite the parse-error copy on the way out, then hand the error back
+     * unchanged in every other respect — same class, same `oclif.exit`, same
+     * `--json` envelope from `BaseCommand.catch`. Only the sentence changes.
+     */
+    async catch(err) {
+        if (typeof err?.message === 'string') {
+            err.message = clarifyMissingRequiredFlag(err.message);
+        }
+        return super.catch(err);
+    }
     async run() {
         this.requireAuth();
         const { flags } = await this.parse(TasksReady);

package/dist/commands/tasks/runs.d.ts

@@ -1,10 +1,32 @@
 import { BaseCommand } from '../../base-command';
+import { type RunFailure } from './activity';
 /**
  * OSK-4836 — say WHERE a run executed. A named daemon wins over the environment
  * label; an environment with no daemon is the cloud worker (or a runtime whose
  * daemon id was not recorded). `-` when the row predates executor stamping.
  */
 export declare function formatRunExecutor(run: Record<string, unknown>): string;
+/**
+ * Whether this run row is one whose reason the caller cannot see. (S3 dogfood finding)
+ *
+ * `{ status: 'failed', errors: 1 }` and nothing else — a count of errors with
+ * no error. The row is complete as far as the projection goes, so the only way
+ * to tell a caller why is to go and read it from somewhere the CLI can reach.
+ * This decides when that lookup is worth a round trip: never for a healthy
+ * list, always once something failed.
+ */
+export declare function runNeedsFailureReason(run: Record<string, unknown>): boolean;
+/**
+ * The run's OWN failure fields, when the server carries them.
+ *
+ * The projection now derives `failureReason` / `failureCode` / `failureClass`
+ * from the terminal event it already had in hand, so the reason travels with
+ * the run rather than having to be reassembled from the activity log by runId.
+ * Exported for `runs.spec.ts`.
+ */
+export declare function failureFromRun(run: Record<string, unknown>): RunFailure | null;
+/** The reason block printed under the table — one entry per run we could explain. */
+export declare function renderRunFailures(runs: Array<Record<string, unknown>>, failures: Map<string, RunFailure>, bin?: string, taskRef?: string): string[];
 export default class TasksRuns extends BaseCommand {
     static description: string;
     static examples: string[];

package/dist/commands/tasks/runs.js

@@ -1,10 +1,14 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.formatRunExecutor = formatRunExecutor;
+exports.runNeedsFailureReason = runNeedsFailureReason;
+exports.failureFromRun = failureFromRun;
+exports.renderRunFailures = renderRunFailures;
 const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const base_command_1 = require("../../base-command");
 const format_1 = require("../../lib/format");
+const activity_1 = require("./activity");
 function formatTime(value) {
     try {
         return new Date(String(value)).toISOString().slice(0, 19).replace('T', ' ');
@@ -29,6 +33,79 @@ function formatRunExecutor(run) {
     }
     return '-';
 }
+/**
+ * Whether this run row is one whose reason the caller cannot see. (S3 dogfood finding)
+ *
+ * `{ status: 'failed', errors: 1 }` and nothing else — a count of errors with
+ * no error. The row is complete as far as the projection goes, so the only way
+ * to tell a caller why is to go and read it from somewhere the CLI can reach.
+ * This decides when that lookup is worth a round trip: never for a healthy
+ * list, always once something failed.
+ */
+function runNeedsFailureReason(run) {
+    if (run.status === 'failed' || run.outcome === 'failed')
+        return true;
+    return typeof run.errors === 'number' && run.errors > 0;
+}
+/**
+ * The run's OWN failure fields, when the server carries them.
+ *
+ * The projection now derives `failureReason` / `failureCode` / `failureClass`
+ * from the terminal event it already had in hand, so the reason travels with
+ * the run rather than having to be reassembled from the activity log by runId.
+ * Exported for `runs.spec.ts`.
+ */
+function failureFromRun(run) {
+    const message = typeof run.failureReason === 'string' ? run.failureReason.trim() : '';
+    if (!message)
+        return null;
+    return {
+        runId: String(run.runId ?? run.id ?? run._id ?? '-'),
+        message,
+        code: typeof run.failureCode === 'string' ? run.failureCode : null,
+        causeClass: typeof run.failureClass === 'string' ? run.failureClass : null,
+    };
+}
+/** The reason block printed under the table — one entry per run we could explain. */
+function renderRunFailures(runs, failures, bin = 'skrr', taskRef = '<task-id>') {
+    const needing = runs.filter(runNeedsFailureReason);
+    if (needing.length === 0)
+        return [];
+    const lines = ['', 'Why they failed:'];
+    let explained = 0;
+    let usedActivity = false;
+    for (const run of needing) {
+        const runId = String(run.runId ?? run.id ?? run._id ?? '-');
+        // The run's own field first. The activity join stays as the fallback
+        // because a CLI talks to whatever server it is pointed at, and one that
+        // predates the projection field still has the activity log — dropping the
+        // fallback would make this command worse against an older deployment than
+        // it was before the field existed.
+        const own = failureFromRun(run);
+        const failure = own ?? failures.get(runId);
+        if (!failure) {
+            // No invented reason. Saying "unknown" is the honest row, and it is
+            // materially different from the row above it.
+            lines.push(`  ${runId}  no reason recorded in the activity log.`);
+            continue;
+        }
+        explained += 1;
+        if (!own)
+            usedActivity = true;
+        const tags = [failure.code, failure.causeClass].filter(Boolean).join(' · ');
+        lines.push(`  ${runId}${tags ? `  ${tags}` : ''}`);
+        lines.push(`    ${failure.message}`);
+    }
+    // Name the SOURCE only when it is not the run itself: a reason that came with
+    // the row needs no directions to somewhere else.
+    if (explained === 0) {
+        lines.push(`  (the run projection carries no message; try \`${bin} tasks show ${taskRef}\` → executionError)`);
+    }
+    else if (usedActivity) {
+        lines.push(`  (from the activity log — \`${bin} tasks activity ${taskRef} --json\` → details.error)`);
+    }
+    return lines;
+}
 class TasksRuns extends base_command_1.BaseCommand {
     static description = 'List execution runs for a task';
     static examples = [
@@ -51,12 +128,26 @@ class TasksRuns extends base_command_1.BaseCommand {
         catch (err) {
             this.handleApiError(err);
         }
+        const r = response;
+        const items = r?.data ?? [];
+        // A failed run whose reason the ROW does not carry. Split from "failed" so
+        // the note below cannot keep asserting the projection has no reason field
+        // once the server started sending one — a warning that outlives its cause
+        // is just a false statement with a warning icon.
+        const unexplained = items.filter(runNeedsFailureReason).some((run) => !failureFromRun(run));
         if (flags.json) {
+            // The server payload goes out byte-identical — enriching it would put a
+            // CLI-derived reason under a key a caller would read as the server's.
+            // The pointer goes to STDERR instead, so `--json` stays parseable and a
+            // scripted caller still learns where the message actually lives.
+            if (unexplained) {
+                this.warn('A failed run here carries `errors` but no `failureReason` — this server predates that ' +
+                    `field. Read it from \`${this.config.bin} tasks show ${args.id} --json\` (executionError) or ` +
+                    `\`${this.config.bin} tasks activity ${args.id} --json\` (details.error, keyed by runId).`);
+            }
             this.log(JSON.stringify(response, null, 2));
             return;
         }
-        const r = response;
-        const items = r?.data ?? [];
         if (items.length === 0) {
             this.log('No runs.');
             return;
@@ -77,6 +168,23 @@ class TasksRuns extends base_command_1.BaseCommand {
             { key: 'duration', header: 'DURATION' },
             { key: 'tokens', header: 'TOKENS' },
         ], (line) => this.log(line));
+        // Only once something failed: a healthy list pays nothing for this.
+        if (!unexplained)
+            return;
+        let failures = new Map();
+        try {
+            const activity = (await data_provider_1.dataService.getTaskActivity(args.id, 200));
+            failures = (0, activity_1.runFailuresFromActivity)(activity?.data);
+        }
+        catch {
+            // Best effort by design. The runs listing already succeeded, and a second
+            // read that fails must not turn a working command into an error — the
+            // block below then says "no reason recorded", which is true of what we
+            // can see.
+        }
+        for (const line of renderRunFailures(items, failures, this.config.bin, args.id)) {
+            this.log(line);
+        }
     }
 }
 exports.default = TasksRuns;

package/dist/commands/tasks/show.d.ts

@@ -1,4 +1,32 @@
 import { BaseCommand } from '../../base-command';
+/**
+ * The failure rows of `tasks show`, when there are any. (S3 dogfood finding)
+ *
+ * The report behind this said a failed task reports `lastError: null` with no
+ * message anywhere a program looks. Half of that is true and half is a naming
+ * accident worth separating, because they need different fixes:
+ *
+ *  - `lastError` is not a field. `jq .lastError` on a key that does not exist
+ *    answers `null`, which is indistinguishable from a field that exists and is
+ *    empty. The reason IS in `--json`, under `executionError`, alongside
+ *    `lastFailedAt` and `executionAttempts`.
+ *  - Nothing in the human view ever printed it. `tasks show` rendered `Status:
+ *    failed` and then twenty rows that say nothing about why, so there was no
+ *    way to LEARN the field's name short of dumping the whole object — which is
+ *    exactly how the reader ended up guessing `lastError`.
+ *
+ * So the fix is discoverability, not a new field: print what the payload
+ * already carries, under a label that names the key a script should read.
+ *
+ * The rules this function will not break:
+ *  - Never assert a reason we do not have. A task that failed with no
+ *    `executionError` gets the pointer and no invented text.
+ *  - Never claim a failure that is not one. Absent both a failure marker and a
+ *    failed status, this renders nothing at all.
+ *
+ * Pure and exported so the wording is testable without an oclif runtime.
+ */
+export declare function taskFailureLines(t: Record<string, unknown>, bin?: string): string[];
 export default class TasksShow extends BaseCommand {
     static description: string;
     static examples: string[];

package/dist/commands/tasks/show.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.taskFailureLines = taskFailureLines;
 const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const api_fetch_1 = require("../../lib/api-fetch");
@@ -8,6 +9,62 @@ const base_command_1 = require("../../base-command");
 const task_resolver_1 = require("../../lib/task-resolver");
 const web_url_1 = require("../../lib/web-url");
 const html_text_1 = require("../../lib/html-text");
+/**
+ * The failure rows of `tasks show`, when there are any. (S3 dogfood finding)
+ *
+ * The report behind this said a failed task reports `lastError: null` with no
+ * message anywhere a program looks. Half of that is true and half is a naming
+ * accident worth separating, because they need different fixes:
+ *
+ *  - `lastError` is not a field. `jq .lastError` on a key that does not exist
+ *    answers `null`, which is indistinguishable from a field that exists and is
+ *    empty. The reason IS in `--json`, under `executionError`, alongside
+ *    `lastFailedAt` and `executionAttempts`.
+ *  - Nothing in the human view ever printed it. `tasks show` rendered `Status:
+ *    failed` and then twenty rows that say nothing about why, so there was no
+ *    way to LEARN the field's name short of dumping the whole object — which is
+ *    exactly how the reader ended up guessing `lastError`.
+ *
+ * So the fix is discoverability, not a new field: print what the payload
+ * already carries, under a label that names the key a script should read.
+ *
+ * The rules this function will not break:
+ *  - Never assert a reason we do not have. A task that failed with no
+ *    `executionError` gets the pointer and no invented text.
+ *  - Never claim a failure that is not one. Absent both a failure marker and a
+ *    failed status, this renders nothing at all.
+ *
+ * Pure and exported so the wording is testable without an oclif runtime.
+ */
+function taskFailureLines(t, bin = 'skrr') {
+    const error = typeof t.executionError === 'string' ? t.executionError.trim() : '';
+    const failedAt = t.lastFailedAt ? formatTime(t.lastFailedAt) : null;
+    const isFailed = t.status === 'failed';
+    if (!error && !failedAt && !isFailed)
+        return [];
+    const lines = [];
+    const attempts = typeof t.executionAttempts === 'number' ? t.executionAttempts : null;
+    const runId = typeof t.lastFinalizedRunId === 'string' ? t.lastFinalizedRunId : null;
+    const facts = [
+        failedAt,
+        attempts != null ? `attempt ${attempts}` : null,
+        runId ? `run ${runId}` : null,
+    ].filter(Boolean);
+    if (facts.length > 0)
+        lines.push(`Failed:      ${facts.join(' · ')}`);
+    if (error) {
+        // Labelled with the JSON key, because a reader who needs this in a script
+        // needs the key more than they need the prose.
+        lines.push(`Error:       ${error}`);
+        lines.push('             (`executionError` in --json)');
+    }
+    else if (isFailed) {
+        lines.push('Error:       none recorded on the task.');
+    }
+    const ref = String(t.identifier ?? t.id ?? t._id ?? '<task-id>');
+    lines.push(`Per-run why: ${bin} tasks activity ${ref} --json   (details.error, keyed by runId)`);
+    return lines;
+}
 class TasksShow extends base_command_1.BaseCommand {
     static description = 'Show details for a single task (enriched)';
     static examples = [
@@ -112,6 +169,10 @@ class TasksShow extends base_command_1.BaseCommand {
         if (url)
             this.log(`URL:         ${url}`);
         this.log(`Status:      ${t.status ?? '-'}`);
+        // Immediately under Status, because "failed" is the row that raises the
+        // question and this is the answer to it.
+        for (const line of taskFailureLines(t, this.config.bin))
+            this.log(line);
         this.log(`Executor:    ${t.executionMode ?? 'legacy / inferred'}`);
         this.log(`Priority:    ${t.priority ?? '-'}`);
         this.log(`Parent:      ${t.parentId ?? '-'}`);

package/dist/commands/tasks/timeline.d.ts

@@ -1,4 +1,11 @@
 import { BaseCommand } from '../../base-command';
+/**
+ * `<action> (<k=v ...>)`, or just the preview when there is nothing to add.
+ *
+ * Exported for `timeline.spec.ts`. `formatCell` is what `tasks activity`
+ * renders `details` with, so the two surfaces describe one entry the same way.
+ */
+export declare function withDetails(item: Record<string, unknown>): string;
 export default class TasksTimeline extends BaseCommand {
     static description: string;
     static args: {

package/dist/commands/tasks/timeline.js

@@ -1,9 +1,22 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.withDetails = withDetails;
 const core_1 = require("@oclif/core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const base_command_1 = require("../../base-command");
 const format_1 = require("../../lib/format");
+const tasks_1 = require("../../lib/tasks");
+/**
+ * `<action> (<k=v ...>)`, or just the preview when there is nothing to add.
+ *
+ * Exported for `timeline.spec.ts`. `formatCell` is what `tasks activity`
+ * renders `details` with, so the two surfaces describe one entry the same way.
+ */
+function withDetails(item) {
+    const preview = String(item.preview ?? '-');
+    const details = (0, format_1.formatCell)(item.details, '');
+    return details ? `${preview} (${details})` : preview;
+}
 class TasksTimeline extends base_command_1.BaseCommand {
     static description = 'Show the unified task timeline: work log, comments, lifecycle, and execution';
     static args = {
@@ -13,7 +26,14 @@ class TasksTimeline extends base_command_1.BaseCommand {
         json: core_1.Flags.boolean({ description: 'Output JSON' }),
         limit: core_1.Flags.integer({ default: 50 }),
         cursor: core_1.Flags.string(),
-        kind: core_1.Flags.string(),
+        // `--kind` names a typed WORK-EVENT kind, not one of the timeline's four
+        // sources. Undeclared and undescribed, it read like a source filter and
+        // silently accepted anything; the server now refuses an unknown kind, and
+        // declaring the options here refuses a typo before it costs a round trip.
+        kind: core_1.Flags.string({
+            description: 'Show only work events of this kind (excludes comments, lifecycle, execution)',
+            options: [...tasks_1.TASK_WORK_EVENT_KINDS],
+        }),
         run: core_1.Flags.string(),
         actor: core_1.Flags.string({ options: ['user', 'agent', 'system'] }),
     };
@@ -41,9 +61,20 @@ class TasksTimeline extends base_command_1.BaseCommand {
             time: String(item.occurredAt ?? '-')
                 .replace('T', ' ')
                 .slice(0, 19),
-            source: String(item.kind ?? '-'),
+            // A work event's own kind is the thing you came to see. Showing the
+            // source alone collapsed blocker, decision, checkpoint and evidence
+            // into one indistinguishable `work_event`.
+            source: item.eventKind
+                ? `${String(item.kind ?? '-')}:${String(item.eventKind)}`
+                : String(item.kind ?? '-'),
             actor: String(item.actor?.kind ?? '-'),
-            detail: (0, format_1.truncate)(String(item.preview ?? '-'), 90),
+            // A lifecycle row's preview is the bare action, so `status_changed`
+            // appeared three times in a row without ever naming a status. The
+            // answer is in `details` (`status=blocked`), which `tasks activity`
+            // has always shown off the same entries. Appended rather than
+            // substituted: the action is still what happened, `details` is what
+            // it happened to.
+            detail: (0, format_1.truncate)(withDetails(item), 90),
             run: String(item.runId ?? '-'),
         })), [
             { key: 'time', header: 'TIME' },

package/dist/commands/tasks/update.d.ts

@@ -16,6 +16,26 @@ export default class TasksUpdate extends BaseCommand {
         'start-date': import("@oclif/core/lib/interfaces").OptionFlag<string | undefined, import("@oclif/core/lib/interfaces").CustomOptions>;
         'due-date': import("@oclif/core/lib/interfaces").OptionFlag<string | undefined, import("@oclif/core/lib/interfaces").CustomOptions>;
         estimate: import("@oclif/core/lib/interfaces").OptionFlag<number | undefined, import("@oclif/core/lib/interfaces").CustomOptions>;
+        /**
+         * Declared, hidden, and refused — on purpose. (S4 dogfood finding)
+         *
+         * `--status` is the single most likely flag a person types at `tasks
+         * update`, and undeclared it produced oclif's `Nonexistent flag: --status`
+         * followed by a ~160-line dump of this command's help. The answer is in
+         * that dump — this command's own description says status changes go through
+         * `tasks move` — buried under thirty other flags.
+         *
+         * Declaring it routes `--status` past the parser and into
+         * `taskUpdateMutationGuard`, which already refuses a `status` key arriving
+         * via `--from-json` with the exact sentence naming `tasks move`. So the two
+         * ways of asking for the same wrong thing now get the same right answer,
+         * the same `TASK_STATUS_REQUIRES_MOVE` code in `--json`, and no help dump —
+         * and the copy has ONE home rather than a second parallel string.
+         *
+         * `hidden` because it is not a capability: help must not advertise a flag
+         * whose only behaviour is to explain itself.
+         */
+        status: import("@oclif/core/lib/interfaces").OptionFlag<string | undefined, import("@oclif/core/lib/interfaces").CustomOptions>;
         'duplicate-of': import("@oclif/core/lib/interfaces").OptionFlag<string | undefined, import("@oclif/core/lib/interfaces").CustomOptions>;
         goal: import("@oclif/core/lib/interfaces").OptionFlag<string | undefined, import("@oclif/core/lib/interfaces").CustomOptions>;
         cycle: import("@oclif/core/lib/interfaces").OptionFlag<string | undefined, import("@oclif/core/lib/interfaces").CustomOptions>;