@skrr-ai/cli 0.1.42 → 0.1.44

package/dist/lib/harness-provider-input.js

@@ -2,20 +2,25 @@
 /**
  * Harness-valued INPUT, normalised at the edge.
  *
- * The first-party harness has more than one accepted spelling while a rename is
- * in flight (`FIRST_PARTY_HARNESS.aliases`). Every flag, setting and filter that
- * takes a harness name must accept all of them — a script written against either
- * spelling keeps working — and must hand the rest of the CLI ONE value, so no
- * comparison downstream has to know there were two
- * (`docs/architecture/skrr-code-identifier-rename-2026-09-13.md` §2).
+ * INGRESS: every flag, setting and filter that takes a harness name accepts
+ * exactly the identity's ACCEPTED spellings (`firstPartyHarnessSpellings`) and
+ * hands the rest of the CLI ONE value, so no comparison downstream has to know
+ * whether there were several (`docs/architecture/skrr-code-identifier-rename-2026-09-13.md`
+ * §2). During a rename's alias window that is the canonical spelling plus
+ * `FIRST_PARTY_HARNESS.aliases`, so a script written against either keeps
+ * working; outside one it is the canonical spelling alone. A FORMER spelling is
+ * accepted on no input — it is passed through unchanged, so a flag offering only
+ * the accepted spellings rejects it — even though the CLI still recognises it on
+ * an engine binary already on disk (`first-party-harness.ts`).
  *
  * Two destinations, two spellings, and the difference is the point:
  *
  *   - to the SERVER (HTTP bodies, query params) and to the terminal: CANONICAL,
  *     which is what the platform stores and returns;
- *   - to the local DAEMON binary: the WIRE spelling, which every daemon version
- *     already installed on a user's machine understands. A daemon that predates
- *     the rename cannot be taught a new spelling by the CLI that talks to it.
+ *   - to the local DAEMON binary: the WIRE spelling (`wireProvider`). It sits on
+ *     the old spelling from a rename's flip until its wire phase, because a daemon
+ *     that predates the rename cannot be taught a new spelling by the CLI that
+ *     talks to it, and is canonical otherwise.
  *
  * Every other harness name passes through unchanged — this normalises one
  * harness's spellings, it is not a general lower-caser, and silently rewriting a
@@ -48,9 +53,10 @@ function daemonHarnessArgument(value) {
 }
 /**
  * The `options` list for an oclif flag that enumerates harness names: the given
- * names with every spelling of the first-party harness in place of its canonical
- * one, so oclif's own validation accepts an alias instead of rejecting it before
- * the command ever runs.
+ * names with every ACCEPTED spelling of the first-party harness in place of its
+ * canonical one, so oclif's own validation accepts an alias instead of rejecting
+ * it before the command ever runs — and rejects a former spelling, which no
+ * ingress accepts.
  */
 function harnessFlagOptions(names) {
     return canonicalHarnessInputs(names).flatMap((name) => (0, auth_core_1.isFirstPartyHarnessProvider)(name) ? [...(0, auth_core_1.firstPartyHarnessSpellings)()] : [name]);

package/dist/lib/harness-tiers.d.ts

@@ -47,9 +47,10 @@ export declare const HARNESS_TIER_AUTHORITY = "daemon/src/harness-trust.ts";
 /**
  * The tier the shared table records for a harness, or `null` for an unknown name.
  *
- * Canonicalised first, so no spelling of the first-party harness can reach the
- * lookup as an unknown name — the shared table also carries every spelling, and
- * this keeps the answer right even for one written in a different case.
+ * Canonicalised first, so no accepted spelling of the first-party harness can reach
+ * the lookup as an unknown name — the shared table also carries every accepted
+ * spelling, and this keeps the answer right even for one written in a different
+ * case. A retired spelling is an unknown name here, as everywhere trust is decided.
  */
 export declare function mirroredTier(harness: string): HarnessTrustTier | null;
 export interface TierDescription {

package/dist/lib/harness-tiers.js

@@ -52,9 +52,10 @@ exports.HARNESS_TIER_AUTHORITY = 'daemon/src/harness-trust.ts';
 /**
  * The tier the shared table records for a harness, or `null` for an unknown name.
  *
- * Canonicalised first, so no spelling of the first-party harness can reach the
- * lookup as an unknown name — the shared table also carries every spelling, and
- * this keeps the answer right even for one written in a different case.
+ * Canonicalised first, so no accepted spelling of the first-party harness can reach
+ * the lookup as an unknown name — the shared table also carries every accepted
+ * spelling, and this keeps the answer right even for one written in a different
+ * case. A retired spelling is an unknown name here, as everywhere trust is decided.
  */
 function mirroredTier(harness) {
     const key = String((0, auth_core_1.canonicalHarnessProvider)(harness));

package/dist/lib/harnesses.d.ts

@@ -101,6 +101,12 @@ export interface HarnessLease {
     machineProduct?: string;
     machineProductLabel?: string;
     displayName?: string;
+    /**
+     * Who pays: the workspace whose account the lease bills, or `null` for the
+     * owner's personal account (`MachineLease.toSafeJSON`). Absent from a server
+     * that predates it, which is not the same as personal.
+     */
+    workspaceId?: string | null;
     state?: string;
     stateReason?: string;
     lifecycleSemantics?: string;

package/dist/lib/html-text.js

@@ -19,10 +19,35 @@ exports.htmlToDisplayText = htmlToDisplayText;
 function looksLikeHtml(value) {
     return /<\/?[a-z][^>]*>/i.test(value);
 }
+/** Pull one attribute out of a tag body — `src="…"`, `src='…'`, `src=…`. */
+function tagAttr(tag, name) {
+    const m = new RegExp(`${name}\\s*=\\s*(?:"([^"]*)"|'([^']*)'|([^\\s>]+))`, 'i').exec(tag);
+    return m ? (m[1] ?? m[2] ?? m[3] ?? '') : '';
+}
 function htmlToDisplayText(value) {
     if (!looksLikeHtml(value))
         return value;
     return (value
+        // A <video> is the same kind of meaning as an <img>, and the tag strip
+        // would erase it the same way, leaving a terminal reader no sign the
+        // description holds a recording at all. Markdown has no video syntax, so
+        // it becomes a labelled link to the stable reference. The element's
+        // children — `<source>` and fallback text — go with it; a `<source>` src
+        // is used when the element itself carries none (OSK-10129).
+        .replace(/<video\b([^>]*)>([\s\S]*?)<\/video\s*>|<video\b([^>]*)\/?>/gi, (_m, open, inner, bare) => {
+        const tag = String(open ?? bare ?? '');
+        const src = tagAttr(tag, 'src') || tagAttr(/<source\b[^>]*>/i.exec(inner ?? '')?.[0] ?? '', 'src');
+        const title = tagAttr(tag, 'title');
+        return src ? `[video: ${title || 'recording'}](${src})\n` : '';
+    })
+        // An <img> carries meaning — the asset reference or URL — that the
+        // generic tag strip below would erase entirely. Keep it as a markdown
+        // image so `task-asset:<id>` refs stay legible in a terminal (OSK-9856).
+        .replace(/<img\b[^>]*>/gi, (tag) => {
+        const src = tagAttr(tag, 'src');
+        const alt = tagAttr(tag, 'alt');
+        return src ? `![${alt || 'image'}](${src})` : '';
+    })
         .replace(/<br\s*\/?>/gi, '\n')
         .replace(/<\/(p|div|li|h[1-6])>/gi, '\n')
         .replace(/<li[^>]*>/gi, '  - ')

package/dist/lib/instruction-input.d.ts

@@ -76,6 +76,27 @@ export declare function describeTargetSync(target: {
     updatedAt?: string;
     driftCount?: number;
 }, now?: number, liveDaemonIds?: string[]): string;
+/**
+ * The whole error of every failed target, and what to do about it.
+ *
+ * The STATUS column caps at 78 characters, so a daemon error that names a path
+ * was cut mid-path — "must be inside a Git repository: /private/…" — and the
+ * table offered nothing past it: no remedy, and no way to learn that
+ * `instructions remove` was the way out (OSK-4626). The column keeps its cap;
+ * the full sentence and the next step go below the table, the way the re-bind
+ * commands do.
+ *
+ * The daemon retries a failed target on its next sync (every five minutes, or
+ * sooner on any change), so fixing the cause is itself a remedy and needs no
+ * command. A failed REMOVAL is the other case: it can only be abandoned when
+ * its daemon is gone, which is the one place `purge-target --force` belongs.
+ */
+export declare function failedTargetLines(targets: Array<{
+    id: string;
+    status?: string;
+    desiredState?: string;
+    lastError?: string;
+}>, bin?: string): string[];
 /**
  * The command that re-binds a stalled target to the daemon now running on its
  * machine, or null when no such daemon is live.

package/dist/lib/instruction-input.js

@@ -7,6 +7,7 @@ exports.resolveBundleLabel = resolveBundleLabel;
 exports.parseDaemonId = parseDaemonId;
 exports.sameMachineDaemon = sameMachineDaemon;
 exports.describeTargetSync = describeTargetSync;
+exports.failedTargetLines = failedTargetLines;
 exports.rebindCommandFor = rebindCommandFor;
 const promises_1 = require("node:fs/promises");
 async function readStdin() {
@@ -188,6 +189,35 @@ function describeTargetSync(target, now = Date.now(), liveDaemonIds = []) {
     }
     return `${base} — stalled ${days}d; daemon may be gone: remove, then purge-target --force`;
 }
+/**
+ * The whole error of every failed target, and what to do about it.
+ *
+ * The STATUS column caps at 78 characters, so a daemon error that names a path
+ * was cut mid-path — "must be inside a Git repository: /private/…" — and the
+ * table offered nothing past it: no remedy, and no way to learn that
+ * `instructions remove` was the way out (OSK-4626). The column keeps its cap;
+ * the full sentence and the next step go below the table, the way the re-bind
+ * commands do.
+ *
+ * The daemon retries a failed target on its next sync (every five minutes, or
+ * sooner on any change), so fixing the cause is itself a remedy and needs no
+ * command. A failed REMOVAL is the other case: it can only be abandoned when
+ * its daemon is gone, which is the one place `purge-target --force` belongs.
+ */
+function failedTargetLines(targets, bin = 'skrr') {
+    const failed = targets.filter((target) => target.status === 'error');
+    if (failed.length === 0)
+        return [];
+    const lines = ['', 'Failed targets:'];
+    for (const target of failed) {
+        const removing = target.desiredState === 'removed';
+        lines.push(`  ${target.id} — ${removing ? 'removal failed' : 'install failed'}: ${target.lastError || 'no reason reported'}`);
+        lines.push(removing
+            ? `    Fix the cause and its daemon retries on the next sync. If that daemon is gone for good: \`${bin} instructions purge-target ${target.id} --force\``
+            : `    Fix the cause and its daemon retries on the next sync, or drop the target: \`${bin} instructions remove ${target.id}\``);
+    }
+    return lines;
+}
 /**
  * The command that re-binds a stalled target to the daemon now running on its
  * machine, or null when no such daemon is live.

package/dist/lib/instruction-provenance.d.ts

@@ -0,0 +1,54 @@
+/**
+ * instruction-provenance.ts — tell a prompt's two version counters apart.
+ *
+ * A managed instruction prompt has its OWN version counter (1, 2, 3 — every
+ * saved body), and a prompt installed from a built-in template also carries
+ * the TEMPLATE release each body came from (1, 2, 5, 17 — skipping whatever an
+ * install never received). Every table labelled both `v`, and they agree only
+ * by coincidence: bundle v3 was built-in v5 on the installation that found this
+ * (dogfood OSK-4647), so "the preset went to v5" read as two versions behind.
+ * The provenance that settles it (`sourceTemplateKey`/`sourceTemplateVersion`)
+ * was reachable through `--json` alone.
+ *
+ * So the prompt's counter stays `v<n>`, and a template release is always
+ * written `built-in v<n>` — never a bare `v` that could be either.
+ */
+export interface TemplateProvenance {
+    sourceTemplateKey?: string;
+    sourceTemplateVersion?: number;
+}
+/**
+ * `built-in v5` for a body taken from a built-in template, `built-in` when the
+ * row is recognised as one but its release was never derivable (the provenance
+ * backfill stamps the key without inventing a number), and `` for a body that
+ * was not taken from a template at all.
+ */
+export declare function builtInLabel(version: TemplateProvenance | null | undefined): string;
+interface VersionLike extends TemplateProvenance {
+    versionNumber?: number;
+}
+interface BundleLike extends TemplateProvenance {
+    currentVersionNumber?: number;
+    currentVersion?: VersionLike | null;
+}
+/**
+ * The APPLIED cell of `instructions status`: `v3 (built-in v5)` when the
+ * applied body is the prompt's current one and that one came from a template.
+ * Only then is the release known without fetching the version history, so any
+ * other case says `v3` and nothing it cannot back.
+ */
+export declare function appliedVersionLabel(appliedVersionNumber: number | undefined, bundle: BundleLike | undefined): string;
+/**
+ * One sentence for `instructions show`: which built-in template a prompt comes
+ * from, whether its current body IS a built-in release, and whether a newer
+ * release exists — the question no command answered before. `STATUS: available`
+ * on a version row means "not archived", not "newer than yours".
+ *
+ * `latestTemplateVersion` is the release this server would install today;
+ * undefined when it could not be read, in which case nothing is claimed about
+ * it. Returns null for a prompt that was not installed from a template.
+ */
+export declare function describeTemplateProvenance(bundle: BundleLike & {
+    currentVersionNumber: number;
+}, latestTemplateVersion?: number): string | null;
+export {};

package/dist/lib/instruction-provenance.js

@@ -0,0 +1,84 @@
+"use strict";
+/**
+ * instruction-provenance.ts — tell a prompt's two version counters apart.
+ *
+ * A managed instruction prompt has its OWN version counter (1, 2, 3 — every
+ * saved body), and a prompt installed from a built-in template also carries
+ * the TEMPLATE release each body came from (1, 2, 5, 17 — skipping whatever an
+ * install never received). Every table labelled both `v`, and they agree only
+ * by coincidence: bundle v3 was built-in v5 on the installation that found this
+ * (dogfood OSK-4647), so "the preset went to v5" read as two versions behind.
+ * The provenance that settles it (`sourceTemplateKey`/`sourceTemplateVersion`)
+ * was reachable through `--json` alone.
+ *
+ * So the prompt's counter stays `v<n>`, and a template release is always
+ * written `built-in v<n>` — never a bare `v` that could be either.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.builtInLabel = builtInLabel;
+exports.appliedVersionLabel = appliedVersionLabel;
+exports.describeTemplateProvenance = describeTemplateProvenance;
+/**
+ * `built-in v5` for a body taken from a built-in template, `built-in` when the
+ * row is recognised as one but its release was never derivable (the provenance
+ * backfill stamps the key without inventing a number), and `` for a body that
+ * was not taken from a template at all.
+ */
+function builtInLabel(version) {
+    if (!version?.sourceTemplateKey)
+        return '';
+    const release = version.sourceTemplateVersion;
+    return Number.isInteger(release) && Number(release) > 0 ? `built-in v${release}` : 'built-in';
+}
+/**
+ * The APPLIED cell of `instructions status`: `v3 (built-in v5)` when the
+ * applied body is the prompt's current one and that one came from a template.
+ * Only then is the release known without fetching the version history, so any
+ * other case says `v3` and nothing it cannot back.
+ */
+function appliedVersionLabel(appliedVersionNumber, bundle) {
+    if (!appliedVersionNumber)
+        return '-';
+    const base = `v${appliedVersionNumber}`;
+    const current = bundle?.currentVersion;
+    if (!current || current.versionNumber !== appliedVersionNumber)
+        return base;
+    const builtIn = builtInLabel(current);
+    return builtIn ? `${base} (${builtIn})` : base;
+}
+/**
+ * One sentence for `instructions show`: which built-in template a prompt comes
+ * from, whether its current body IS a built-in release, and whether a newer
+ * release exists — the question no command answered before. `STATUS: available`
+ * on a version row means "not archived", not "newer than yours".
+ *
+ * `latestTemplateVersion` is the release this server would install today;
+ * undefined when it could not be read, in which case nothing is claimed about
+ * it. Returns null for a prompt that was not installed from a template.
+ */
+function describeTemplateProvenance(bundle, latestTemplateVersion) {
+    if (!bundle.sourceTemplateKey)
+        return null;
+    const current = bundle.currentVersion;
+    const head = `From built-in template ${bundle.sourceTemplateKey}.`;
+    if (!current)
+        return head;
+    const release = current.sourceTemplateKey ? current.sourceTemplateVersion : undefined;
+    const version = `v${bundle.currentVersionNumber}`;
+    const latestKnown = Number.isInteger(latestTemplateVersion);
+    if (current.sourceTemplateKey) {
+        const builtIn = builtInLabel(current);
+        if (!latestKnown || !Number.isInteger(release))
+            return `${head} ${version} is ${builtIn}.`;
+        if (Number(latestTemplateVersion) > Number(release)) {
+            return `${head} ${version} is ${builtIn}; built-in v${latestTemplateVersion} is newer.`;
+        }
+        return `${head} ${version} is ${builtIn}, the latest.`;
+    }
+    // Newer releases are promoted only onto a prompt whose body is still a
+    // built-in one, so an edit is exactly when "is there a newer one" matters.
+    const edited = `${head} ${version} is your own edit, so newer built-in releases are not applied to it`;
+    return latestKnown
+        ? `${edited}; the latest is built-in v${latestTemplateVersion}.`
+        : `${edited}.`;
+}

package/dist/lib/session-task-endpoints.d.ts

@@ -7,7 +7,7 @@
  * is no `task-read` and adding one to make the table tidy would name a resource
  * after an access mode.
  */
-export type SessionTaskOperation = 'completion' | 'move' | 'comment' | 'event' | 'update' | 'result' | 'resume' | 'resumeRead' | 'deliverable' | 'review' | 'assessment' | 'read';
+export type SessionTaskOperation = 'completion' | 'move' | 'comment' | 'event' | 'update' | 'result' | 'resume' | 'resumeRead' | 'deliverable' | 'review' | 'assessment' | 'attachment' | 'attachmentIntent' | 'attachmentComplete' | 'read';
 /** Path suffix per operation. Exported for the parity test, not for callers. */
 export declare const SESSION_TASK_PATH_SUFFIX: Record<SessionTaskOperation, string>;
 /**

package/dist/lib/session-task-endpoints.js

@@ -47,6 +47,9 @@ exports.SESSION_TASK_PATH_SUFFIX = {
     deliverable: 'task-deliverables',
     review: 'task-review',
     assessment: 'task-expectation-assessment',
+    attachment: 'task-attachments',
+    attachmentIntent: 'task-attachments/intent',
+    attachmentComplete: 'task-attachments/complete',
     read: 'task',
 };
 /**

package/dist/lib/task-asset-upload.d.ts

@@ -0,0 +1,84 @@
+export type TaskAssetRole = 'input' | 'evidence' | 'deliverable';
+export interface UploadedTaskAsset {
+    id: string;
+    /**
+     * sha256 (hex) of the bytes the server STORED, as the server recorded them.
+     * Absent when the server did not report one — never back-filled from the
+     * local file, which is a different version for any canonicalized image.
+     */
+    digest?: string;
+    filename: string;
+    mimeType: string;
+    /** True when the server returned an existing row for the same sha256. */
+    deduplicated: boolean;
+}
+/** The citation an Update or Result appends to `evidenceRefs`. */
+export interface TaskAssetEvidenceRef {
+    kind: 'task_attachment';
+    id: string;
+    /** `sha256:<hex>` of the stored bytes; omitted when the server named none. */
+    digest?: string;
+}
+/**
+ * Read the Task an upload targets, through the same credential the upload
+ * will use. In a session the task comes from the claim, so the read is the
+ * bound task and `taskId` is only reconciled against it — a scoped credential
+ * refuses to act on any other task before a byte leaves the machine.
+ */
+export declare function readTaskForUpload(taskId: string): Promise<Record<string, unknown>>;
+/**
+ * Upload `filePath` as a Task asset. In a session the task comes from the
+ * claim — `taskId` is only reconciled against the binding, never sent.
+ * Throws a plain Error; callers decide how to surface it.
+ */
+export declare function uploadTaskAssetFile(opts: {
+    taskId: string;
+    filePath: string;
+    role?: TaskAssetRole;
+}): Promise<UploadedTaskAsset>;
+/**
+ * Upload every `--attach` file and return the reference objects an Update or
+ * Result appends to `evidenceRefs`. Serial: half a dozen files is the
+ * realistic case and parallel uploads would race the session rate limiter.
+ */
+export declare function attachTaskAssetFiles(opts: {
+    taskId: string;
+    files: string[];
+    role: TaskAssetRole;
+}): Promise<TaskAssetEvidenceRef[]>;
+/**
+ * The markdown image a comment body carries for an asset. The alt text is the
+ * filename, so its brackets are escaped: `shot [final].png` would otherwise
+ * close the alt early and break the reference.
+ */
+export declare function taskAssetMarkdownRef(asset: {
+    id: string;
+    filename: string;
+}): string;
+/** sha256 of a file, read as a stream: a 250MB recording never sits in memory. */
+export declare function sha256OfFile(filePath: string): Promise<string>;
+/**
+ * POST the file to the presigned URL as multipart/form-data, streamed from
+ * disk.
+ *
+ * Built by hand rather than with `FormData` + `fetch` for two reasons, both
+ * about large files. `FormData` needs a `Blob`, which here means the whole
+ * file in memory — the double buffering this replaced read up to 250MB and
+ * then copied it again. And storage refuses a POST without a Content-Length
+ * (it does not take chunked uploads), which a streamed `fetch` body cannot
+ * promise; the exact length is known here, because every part except the file
+ * is a small in-memory string and the file's size came from `stat`.
+ *
+ * `file` goes LAST — S3 presigned POST evaluates fields in order and ignores
+ * anything after it. The fields carry `x-amz-checksum-sha256`, so storage
+ * itself rejects bytes that do not match the digest the intent declared,
+ * including a file that changed between hashing and upload.
+ */
+export declare function postFileToStorage(p: {
+    uploadUrl: string;
+    uploadFields: Record<string, string>;
+    filePath: string;
+    size: number;
+    filename: string;
+    mimeType: string;
+}): Promise<void>;