@skrr-ai/cli 0.1.8

package/dist/lib/group-chat-message.d.ts

@@ -0,0 +1,142 @@
+/**
+ * Shared helpers for the group-chat message surface — used by both the
+ * chat-addressed commands (`skrr chats send` / `skrr chats messages`) and the
+ * space-addressed Room commands (`skrr spaces room send` / `... messages`).
+ *
+ * The two entry points differ only in how they resolve the group chat id, so
+ * everything downstream of that (mention parsing, row shaping) lives here to
+ * keep the two surfaces from drifting.
+ */
+import type { EntityEmbed } from '@skrr-ai/data-provider';
+/**
+ * A mention as `POST /api/group-chats/:id/messages` expects it.
+ *
+ * Mirrors the server's normalizer (`api/server/utils/groupChatMentions.js`):
+ * `all` carries no id, `user`/`agent` require one, and the server rejects any
+ * principal that is not already in the chat.
+ */
+export type GroupChatMention = {
+    type: 'all';
+} | {
+    type: 'agent';
+    id: string;
+} | {
+    type: 'user';
+    id: string;
+};
+/**
+ * Server-side cap (`MAX_GROUP_CHAT_MENTIONS`). Enforced here too so an
+ * over-long `--mention` list fails locally with a readable message instead of
+ * a 400 from the API.
+ */
+export declare const MAX_GROUP_CHAT_MENTIONS = 20;
+/** Thrown for a malformed `--mention` value. Callers surface `.message` verbatim. */
+export declare class MentionParseError extends Error {
+    constructor(message: string);
+}
+/**
+ * Parse one `--mention` value into the server's mention shape.
+ *
+ * Accepted forms, in precedence order:
+ *   - `all` / `everyone`      → `{ type: 'all' }`
+ *   - `agent:<id>`            → `{ type: 'agent', id }`
+ *   - `user:<id>`             → `{ type: 'user', id }`
+ *   - bare `agent_…`          → agent (skrr agent ids are prefix-tagged)
+ *   - bare 24-hex ObjectId    → user
+ *
+ * A bare value that matches neither id shape is rejected rather than guessed:
+ * mis-targeting a mention silently addresses the wrong principal, and the
+ * server would reject it anyway with a less actionable message.
+ */
+export declare function parseMention(raw: string): GroupChatMention;
+/**
+ * Parse the repeatable `--mention` flag. Returns `undefined` when the flag was
+ * not supplied at all, so the request body omits `mentions` entirely rather
+ * than sending an empty array (the server treats absent and empty differently
+ * only in that absent skips normalization — but omitting keeps the payload
+ * honest about what the caller asked for).
+ */
+export declare function parseMentions(values: string[] | undefined): GroupChatMention[] | undefined;
+/** Request body for `POST /api/group-chats/:id/messages`. */
+export type SendGroupChatMessageBody = {
+    text: string;
+    mentions?: GroupChatMention[];
+    threadId?: string;
+    replyToMessageId?: string;
+    embeds?: EntityEmbed[];
+};
+/**
+ * Build the send-message request body from parsed flags.
+ *
+ * Absent options are omitted rather than sent as `undefined`: the server reads
+ * `threadId` / `replyToMessageId` straight through to `saveGroupChatMessage`,
+ * so an explicit undefined would persist an empty threading field on a message
+ * that was never a reply.
+ */
+export declare function buildSendMessageBody({ text, mentions, threadId, replyToMessageId, embeds, }: {
+    text: string;
+    mentions?: GroupChatMention[];
+    threadId?: string;
+    replyToMessageId?: string;
+    embeds?: EntityEmbed[];
+}): SendGroupChatMessageBody;
+/** One rendered row of a group-chat transcript. */
+export type GroupChatMessageRow = {
+    id: string;
+    sender: string;
+    content: string;
+    createdAt: string;
+};
+/** Column layout shared by every transcript-printing command. */
+export declare const GROUP_CHAT_MESSAGE_COLUMNS: Array<{
+    key: keyof GroupChatMessageRow;
+    header: string;
+    maxWidth?: number;
+}>;
+/**
+ * Shape raw message records into table rows.
+ *
+ * Agent messages carry `senderName` with no `sender` object, so the display
+ * name is resolved across every shape the API emits rather than assuming the
+ * enriched-participant form.
+ */
+export declare function toMessageRows(messages: Array<Record<string, unknown>>): GroupChatMessageRow[];
+/** The terminal state of one mentioned agent's turn, from its placeholder row. */
+export type AgentReplyOutcome = {
+    messageId: string;
+    sender: string;
+    /** `pending` while the placeholder still reads `sending`; terminal otherwise. */
+    status: 'ok' | 'failed' | 'pending';
+    text: string;
+    /** Failure reason from `agentMetadata.error`, when the turn failed. */
+    error: string | null;
+};
+/** Result of inspecting a transcript page for the replies a send triggered. */
+export type AgentRepliesSummary = {
+    replies: AgentReplyOutcome[];
+    /** At least one reply exists AND none is still `pending`. */
+    settled: boolean;
+    /** Any settled reply failed. */
+    anyFailed: boolean;
+};
+/**
+ * Inspect a transcript page for the agent replies a just-sent message
+ * triggered, and decide whether they have settled (dogfood OSK-4909).
+ *
+ * `skrr chats send` is fire-and-forget: it posts the message and exits, so a
+ * mentioned agent that fails (`Unsupported agentic model: …`) is invisible
+ * unless the caller thinks to poll. `--wait` polls for the placeholder rows
+ * the send spawns — an agent reply is persisted as an empty `status: 'sending'`
+ * row and filled in (or marked `failed`) as it streams — and this pure helper
+ * turns one page snapshot into the settled/failed verdict the flag reports.
+ *
+ * A reply is one the send triggered when it is an agent message strictly newer
+ * than the sent row (the user's own message is `senderType: 'user'`, so it is
+ * excluded regardless). `settled` requires at least one such reply with no
+ * `sending` placeholder left, so a caller keeps polling until every mentioned
+ * agent has answered or a timeout intervenes.
+ */
+export declare function summarizeAgentReplies(messages: Array<Record<string, unknown>>, sent: {
+    messageId: string;
+    createdAt: string;
+}): AgentRepliesSummary;

package/dist/lib/group-chat-message.js

@@ -0,0 +1,262 @@
+"use strict";
+/**
+ * Shared helpers for the group-chat message surface — used by both the
+ * chat-addressed commands (`skrr chats send` / `skrr chats messages`) and the
+ * space-addressed Room commands (`skrr spaces room send` / `... messages`).
+ *
+ * The two entry points differ only in how they resolve the group chat id, so
+ * everything downstream of that (mention parsing, row shaping) lives here to
+ * keep the two surfaces from drifting.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.GROUP_CHAT_MESSAGE_COLUMNS = exports.MentionParseError = exports.MAX_GROUP_CHAT_MENTIONS = void 0;
+exports.parseMention = parseMention;
+exports.parseMentions = parseMentions;
+exports.buildSendMessageBody = buildSendMessageBody;
+exports.toMessageRows = toMessageRows;
+exports.summarizeAgentReplies = summarizeAgentReplies;
+const data_provider_1 = require("@skrr-ai/data-provider");
+const format_1 = require("./format");
+/**
+ * Server-side cap (`MAX_GROUP_CHAT_MENTIONS`). Enforced here too so an
+ * over-long `--mention` list fails locally with a readable message instead of
+ * a 400 from the API.
+ */
+exports.MAX_GROUP_CHAT_MENTIONS = 20;
+/** Thrown for a malformed `--mention` value. Callers surface `.message` verbatim. */
+class MentionParseError extends Error {
+    constructor(message) {
+        super(message);
+        this.name = 'MentionParseError';
+    }
+}
+exports.MentionParseError = MentionParseError;
+const AGENT_ID_PREFIX = 'agent_';
+const OBJECT_ID_RE = /^[0-9a-f]{24}$/i;
+/**
+ * Parse one `--mention` value into the server's mention shape.
+ *
+ * Accepted forms, in precedence order:
+ *   - `all` / `everyone`      → `{ type: 'all' }`
+ *   - `agent:<id>`            → `{ type: 'agent', id }`
+ *   - `user:<id>`             → `{ type: 'user', id }`
+ *   - bare `agent_…`          → agent (skrr agent ids are prefix-tagged)
+ *   - bare 24-hex ObjectId    → user
+ *
+ * A bare value that matches neither id shape is rejected rather than guessed:
+ * mis-targeting a mention silently addresses the wrong principal, and the
+ * server would reject it anyway with a less actionable message.
+ */
+function parseMention(raw) {
+    const value = raw.trim();
+    if (!value) {
+        throw new MentionParseError('Empty --mention value.');
+    }
+    const lower = value.toLowerCase();
+    if (lower === 'all' || lower === 'everyone') {
+        return { type: 'all' };
+    }
+    const separator = value.indexOf(':');
+    if (separator > 0) {
+        const kind = value.slice(0, separator).trim().toLowerCase();
+        const id = value.slice(separator + 1).trim();
+        if (kind === 'agent' || kind === 'user') {
+            if (!id) {
+                throw new MentionParseError(`--mention ${kind}: is missing an id (expected ${kind}:<id>).`);
+            }
+            return { type: kind, id };
+        }
+        if (kind === 'all' || kind === 'everyone') {
+            return { type: 'all' };
+        }
+        throw new MentionParseError(`Unknown mention type "${kind}" in --mention ${value}. Use agent:<id>, user:<id>, or all.`);
+    }
+    if (value.startsWith(AGENT_ID_PREFIX)) {
+        return { type: 'agent', id: value };
+    }
+    if (OBJECT_ID_RE.test(value)) {
+        return { type: 'user', id: value };
+    }
+    throw new MentionParseError(`Ambiguous --mention "${value}". Qualify it as agent:<id> or user:<id> (or use "all").`);
+}
+/**
+ * Parse the repeatable `--mention` flag. Returns `undefined` when the flag was
+ * not supplied at all, so the request body omits `mentions` entirely rather
+ * than sending an empty array (the server treats absent and empty differently
+ * only in that absent skips normalization — but omitting keeps the payload
+ * honest about what the caller asked for).
+ */
+function parseMentions(values) {
+    if (!values || values.length === 0) {
+        return undefined;
+    }
+    if (values.length > exports.MAX_GROUP_CHAT_MENTIONS) {
+        throw new MentionParseError(`Too many mentions (${values.length}). Maximum ${exports.MAX_GROUP_CHAT_MENTIONS} allowed.`);
+    }
+    return values.map(parseMention);
+}
+/**
+ * Build the send-message request body from parsed flags.
+ *
+ * Absent options are omitted rather than sent as `undefined`: the server reads
+ * `threadId` / `replyToMessageId` straight through to `saveGroupChatMessage`,
+ * so an explicit undefined would persist an empty threading field on a message
+ * that was never a reply.
+ */
+function buildSendMessageBody({ text, mentions, threadId, replyToMessageId, embeds, }) {
+    return {
+        text,
+        ...(mentions && mentions.length > 0 ? { mentions } : {}),
+        ...(threadId ? { threadId } : {}),
+        ...(replyToMessageId ? { replyToMessageId } : {}),
+        ...(embeds && embeds.length > 0 ? { embeds } : {}),
+    };
+}
+/** Column layout shared by every transcript-printing command. */
+exports.GROUP_CHAT_MESSAGE_COLUMNS = [
+    { key: 'id', header: 'ID' },
+    { key: 'sender', header: 'SENDER', maxWidth: 20 },
+    { key: 'content', header: 'CONTENT', maxWidth: 60 },
+    { key: 'createdAt', header: 'SENT AT', maxWidth: 30 },
+];
+/**
+ * Shape raw message records into table rows.
+ *
+ * Agent messages carry `senderName` with no `sender` object, so the display
+ * name is resolved across every shape the API emits rather than assuming the
+ * enriched-participant form.
+ */
+function toMessageRows(messages) {
+    return messages.map((msg) => {
+        const sender = msg.sender;
+        return {
+            id: (0, format_1.formatCell)(msg.messageId ?? msg._id),
+            sender: (0, format_1.formatCell)(sender?.name ?? sender?.username ?? msg.senderName ?? msg.senderId),
+            content: messageBodyCell(msg),
+            createdAt: (0, format_1.formatCell)(msg.createdAt),
+        };
+    });
+}
+/**
+ * Render the body cell, labelling a body that is empty *because the message is
+ * still being produced*.
+ *
+ * An agent reply is persisted as an empty `status: 'sending'` row the moment
+ * the run starts and filled in as it streams. Printing that as a blank cell
+ * makes an in-flight reply indistinguishable from a message with no text, which
+ * matters most in exactly the case people poll a Room for. `--json` is
+ * untouched — machine consumers read `status` directly.
+ *
+ * A `failed` row gets the same treatment one step further: it also carries WHY,
+ * and saying so is the difference between a user who knows what to do next and
+ * one who just asks again.
+ */
+function messageBodyCell(msg) {
+    const body = (0, format_1.formatCell)(msg.text ?? msg.content, '');
+    const references = messageReferenceCell(msg);
+    if (body)
+        return references ? `${body}\n${references}` : body;
+    if (references)
+        return references;
+    const status = typeof msg.status === 'string' ? msg.status : '';
+    if (status === 'sending')
+        return '(sending…)';
+    if (status === 'failed') {
+        const reason = messageFailureReason(msg);
+        return reason ? `(failed: ${reason})` : '(failed)';
+    }
+    return '';
+}
+/**
+ * The reason a failed agent turn already gave for itself.
+ *
+ * `GroupChatWorker` records one on EVERY path that marks a message failed —
+ * all three `status: 'failed'` writes set `agentMetadata.error` beside it — and
+ * this table printed a bare `(failed)` anyway. So an agent bound to a runtime
+ * that no longer exists (`runtime_offline`) and an account with no billing
+ * owner rendered identically, though one is fixed by re-attaching a harness and
+ * the other by configuring the account. The row was carrying the answer the
+ * whole time.
+ *
+ * First line only, and capped: the reason is sometimes an Error message with a
+ * stack behind it, and CONTENT is a 60-column cell. `--json` is untouched, so a
+ * machine consumer still reads the full `agentMetadata.error`.
+ */
+function messageFailureReason(msg) {
+    const meta = msg.agentMetadata;
+    const raw = typeof meta?.error === 'string' ? meta.error.trim() : '';
+    if (!raw)
+        return '';
+    const firstLine = raw.split('\n')[0].trim();
+    return firstLine.length > 80 ? `${firstLine.slice(0, 79)}…` : firstLine;
+}
+/**
+ * The message's entity references, one compact line each.
+ *
+ * These were invisible here. A message may carry `metadata.embeds` — a task, a
+ * view, a wiki page — which every OTHER surface renders as a card or a text
+ * line, while this table printed only `text` and dropped them silently. An
+ * agent that answers by attaching a reference looked, from the CLI, like an
+ * agent that answered with nothing.
+ *
+ * No `webOrigin`: a deep link would blow past the CONTENT column's width and
+ * the id is already one `--json` away. The format itself is the shared one, so
+ * a reference reads the same here as it does in Slack.
+ */
+function messageReferenceCell(msg) {
+    return (0, data_provider_1.embedsAsText)((0, data_provider_1.normalizeMessageEmbeds)(msg.metadata), {
+        maxTitle: 48,
+        maxSubtitle: 32,
+    });
+}
+/**
+ * Inspect a transcript page for the agent replies a just-sent message
+ * triggered, and decide whether they have settled (dogfood OSK-4909).
+ *
+ * `skrr chats send` is fire-and-forget: it posts the message and exits, so a
+ * mentioned agent that fails (`Unsupported agentic model: …`) is invisible
+ * unless the caller thinks to poll. `--wait` polls for the placeholder rows
+ * the send spawns — an agent reply is persisted as an empty `status: 'sending'`
+ * row and filled in (or marked `failed`) as it streams — and this pure helper
+ * turns one page snapshot into the settled/failed verdict the flag reports.
+ *
+ * A reply is one the send triggered when it is an agent message strictly newer
+ * than the sent row (the user's own message is `senderType: 'user'`, so it is
+ * excluded regardless). `settled` requires at least one such reply with no
+ * `sending` placeholder left, so a caller keeps polling until every mentioned
+ * agent has answered or a timeout intervenes.
+ */
+function summarizeAgentReplies(messages, sent) {
+    const sentAt = Date.parse(String(sent.createdAt));
+    const replies = messages
+        .filter((msg) => {
+        if (msg.senderType !== 'agent')
+            return false;
+        const id = String(msg.messageId ?? '');
+        if (!id || id === sent.messageId)
+            return false;
+        // Newer than the trigger. When the send timestamp is unparseable, fall
+        // back to id inequality alone rather than dropping every candidate.
+        if (Number.isNaN(sentAt))
+            return true;
+        const at = Date.parse(String(msg.createdAt ?? ''));
+        return Number.isNaN(at) || at >= sentAt;
+    })
+        .map((msg) => {
+        const status = typeof msg.status === 'string' ? msg.status : '';
+        const sender = String(msg.senderName ?? msg.senderId ?? 'agent');
+        const text = typeof msg.text === 'string' ? msg.text.trim() : '';
+        if (status === 'sending') {
+            return { messageId: String(msg.messageId), sender, status: 'pending', text, error: null };
+        }
+        if (status === 'failed') {
+            const meta = msg.agentMetadata;
+            const error = typeof meta?.error === 'string' ? meta.error : null;
+            return { messageId: String(msg.messageId), sender, status: 'failed', text, error };
+        }
+        return { messageId: String(msg.messageId), sender, status: 'ok', text, error: null };
+    });
+    const settled = replies.length > 0 && replies.every((r) => r.status !== 'pending');
+    const anyFailed = replies.some((r) => r.status === 'failed');
+    return { replies, settled, anyFailed };
+}

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

@@ -0,0 +1,78 @@
+/**
+ * OSK-3894 / OSK-3897 — the harness trust tier, as the CLI reports it.
+ *
+ * ── What this file used to be, and why it changed twice ────────────────────
+ *
+ * `skrr code doctor` reported "sky-code is Tier 2 … its tool calls are adjudicated
+ * per call by the daemon" while the daemon had recorded Tier 1 since the owner
+ * decision of 2026-08-11. The audience that runs `doctor` runs it BECAUSE
+ * permissions are confusing them, so that line was wrong to exactly the people it
+ * exists to help — and a unit test asserting the stale string made the wrong claim
+ * look load-bearing.
+ *
+ * OSK-3894 replaced the prose with DATA plus a mirror of the daemon's table,
+ * guarded by a spec that parsed the daemon's source. That closed the regression
+ * and was still only a guard.
+ *
+ * OSK-3897 removed the mirror. `HARNESS_TIERS` and `getHarnessTier` now come from
+ * `@skrr-ai/auth-core` — the one package both the CLI and the daemon already
+ * resolve, and the one already copied verbatim into the published CLI by
+ * `cli/scripts/vendor-monorepo-deps.js`. There is nothing left to drift.
+ *
+ * ── What this file still owns ─────────────────────────────────────────────
+ *
+ * The PROSE. A tier is a number; what it means for a human debugging their
+ * permissions is a sentence, and that sentence is derived from the number here
+ * ({@link describeTier}) so the two cannot disagree. The daemon owns the number
+ * and the enforcement; the CLI owns how the fact is explained.
+ *
+ * It does NOT own provenance. `effectiveHarnessTier` and the signature
+ * verification stay in the daemon: a tier is a published fact, provenance is
+ * evidence about bytes on disk, and the CLI has no way to gather it. The doctor
+ * therefore reports the FLOOR and says the daemon decides.
+ */
+import { HARNESS_TIERS, getHarnessTier, type HarnessTrustTier } from '@skrr-ai/auth-core';
+export type { HarnessTrustTier };
+export { HARNESS_TIERS, getHarnessTier };
+/**
+ * Where the tier is decided, for the doctor's remedy text.
+ *
+ * The TABLE is in `@skrr-ai/auth-core`; the daemon is what APPLIES it, and can
+ * elevate it with binary provenance the CLI cannot see. A reader who wants to
+ * change the posture edits the first; a reader debugging what actually happened
+ * looks at the second. Naming both is the honest answer.
+ */
+export declare const HARNESS_TIER_TABLE = "packages/auth-core/src/harnessTrust.ts";
+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. */
+export declare function mirroredTier(harness: string): HarnessTrustTier | null;
+export interface TierDescription {
+    /** What is true, in one line. */
+    detail: string;
+    /** What to do or know about it. Absent when there is genuinely nothing. */
+    remedy?: string;
+    /**
+     * Whether this posture is worth flagging. Tier 1 is flagged NOT because it is
+     * wrong but because it grants the most and currently grants it to an unsigned
+     * build — exactly the kind of fact a diagnostic exists to surface.
+     */
+    notable: boolean;
+}
+/**
+ * Render the user-facing meaning of a tier.
+ *
+ * Both consequences are stated for every tier because they move independently of
+ * each other in the shared table, and a reader debugging one will be misled by
+ * hearing only the other:
+ *
+ *   - PERMISSION (`tierPermitsConfiguredAutoMode`) — may an operator-configured
+ *     `auto` mode stand, or is it downgraded to per-call human adjudication?
+ *   - CREDENTIAL (`credentialPolicyForTier`) — may the platform master key be
+ *     delivered directly, or only a scoped gateway token, or nothing?
+ *
+ * A tier NEVER approves an individual tool call. That sentence is repeated in the
+ * output because "my harness is Tier 1" is regularly misread as "my tool calls are
+ * pre-approved", and the gate order in the daemon's permission authority says
+ * otherwise.
+ */
+export declare function describeTier(harness: string, tier: HarnessTrustTier): TierDescription;

package/dist/lib/harness-tiers.js

@@ -0,0 +1,121 @@
+"use strict";
+/**
+ * OSK-3894 / OSK-3897 — the harness trust tier, as the CLI reports it.
+ *
+ * ── What this file used to be, and why it changed twice ────────────────────
+ *
+ * `skrr code doctor` reported "sky-code is Tier 2 … its tool calls are adjudicated
+ * per call by the daemon" while the daemon had recorded Tier 1 since the owner
+ * decision of 2026-08-11. The audience that runs `doctor` runs it BECAUSE
+ * permissions are confusing them, so that line was wrong to exactly the people it
+ * exists to help — and a unit test asserting the stale string made the wrong claim
+ * look load-bearing.
+ *
+ * OSK-3894 replaced the prose with DATA plus a mirror of the daemon's table,
+ * guarded by a spec that parsed the daemon's source. That closed the regression
+ * and was still only a guard.
+ *
+ * OSK-3897 removed the mirror. `HARNESS_TIERS` and `getHarnessTier` now come from
+ * `@skrr-ai/auth-core` — the one package both the CLI and the daemon already
+ * resolve, and the one already copied verbatim into the published CLI by
+ * `cli/scripts/vendor-monorepo-deps.js`. There is nothing left to drift.
+ *
+ * ── What this file still owns ─────────────────────────────────────────────
+ *
+ * The PROSE. A tier is a number; what it means for a human debugging their
+ * permissions is a sentence, and that sentence is derived from the number here
+ * ({@link describeTier}) so the two cannot disagree. The daemon owns the number
+ * and the enforcement; the CLI owns how the fact is explained.
+ *
+ * It does NOT own provenance. `effectiveHarnessTier` and the signature
+ * verification stay in the daemon: a tier is a published fact, provenance is
+ * evidence about bytes on disk, and the CLI has no way to gather it. The doctor
+ * therefore reports the FLOOR and says the daemon decides.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.HARNESS_TIER_AUTHORITY = exports.HARNESS_TIER_TABLE = exports.getHarnessTier = exports.HARNESS_TIERS = void 0;
+exports.mirroredTier = mirroredTier;
+exports.describeTier = describeTier;
+const auth_core_1 = require("@skrr-ai/auth-core");
+Object.defineProperty(exports, "HARNESS_TIERS", { enumerable: true, get: function () { return auth_core_1.HARNESS_TIERS; } });
+Object.defineProperty(exports, "getHarnessTier", { enumerable: true, get: function () { return auth_core_1.getHarnessTier; } });
+/**
+ * Where the tier is decided, for the doctor's remedy text.
+ *
+ * The TABLE is in `@skrr-ai/auth-core`; the daemon is what APPLIES it, and can
+ * elevate it with binary provenance the CLI cannot see. A reader who wants to
+ * change the posture edits the first; a reader debugging what actually happened
+ * looks at the second. Naming both is the honest answer.
+ */
+exports.HARNESS_TIER_TABLE = 'packages/auth-core/src/harnessTrust.ts';
+exports.HARNESS_TIER_AUTHORITY = 'daemon/src/harness-trust.ts';
+/** The tier the shared table records for a harness, or `null` for an unknown name. */
+function mirroredTier(harness) {
+    return Object.prototype.hasOwnProperty.call(auth_core_1.HARNESS_TIERS, harness)
+        ? (0, auth_core_1.getHarnessTier)(harness)
+        : null;
+}
+/**
+ * Render the user-facing meaning of a tier.
+ *
+ * Both consequences are stated for every tier because they move independently of
+ * each other in the shared table, and a reader debugging one will be misled by
+ * hearing only the other:
+ *
+ *   - PERMISSION (`tierPermitsConfiguredAutoMode`) — may an operator-configured
+ *     `auto` mode stand, or is it downgraded to per-call human adjudication?
+ *   - CREDENTIAL (`credentialPolicyForTier`) — may the platform master key be
+ *     delivered directly, or only a scoped gateway token, or nothing?
+ *
+ * A tier NEVER approves an individual tool call. That sentence is repeated in the
+ * output because "my harness is Tier 1" is regularly misread as "my tool calls are
+ * pre-approved", and the gate order in the daemon's permission authority says
+ * otherwise.
+ */
+function describeTier(harness, tier) {
+    if (tier === 1) {
+        return {
+            notable: true,
+            detail: `${harness} is Tier 1: an operator-configured \`auto\` permission mode STANDS ` +
+                '(it is not downgraded to per-call adjudication), and direct platform-key ' +
+                'delivery is permitted. A tier still never approves an individual tool call.',
+            remedy: 'skrr does not yet sign sky-code releases, so in practice an UNSIGNED build can ' +
+                'receive the platform master key. The provenance machinery still runs and still ' +
+                'verifies binaries — signing stops being what earns the key and becomes what lets ' +
+                `you prove which bytes held it. Reverting to the strict posture is one line in ${exports.HARNESS_TIER_TABLE}.`,
+        };
+    }
+    if (tier === 2) {
+        return {
+            // NOT notable. Tier 2 is the ordinary, correct posture for a recognised
+            // harness: a scoped token and per-call adjudication is what the design
+            // intends, and its `remedy` below is diagnostic help for someone already
+            // seeing cancelled tool calls — not a warning about the tier itself.
+            //
+            // It said `true`, as did Tier 3, which made `describeTier` unconditionally
+            // notable, `skrr code doctor` unconditionally `warn`, and the report's
+            // "All checks passed." branch DEAD CODE — a diagnostic that can never
+            // report health has no way to tell a user that nothing is wrong.
+            notable: false,
+            detail: `${harness} is Tier 2: it receives a scoped gateway token, never the platform ` +
+                'master key, and an operator-configured `auto` mode is downgraded to per-call ' +
+                'adjudication by the daemon.',
+            remedy: 'Expect a managed session to ask about every tool. An UNATTENDED run has no human to ' +
+                'ask, so each call burns the approval timeout and returns cancelled — if that is what ' +
+                `you are seeing, the tier is why. The tier is set in ${exports.HARNESS_TIER_TABLE}; ` +
+                `${exports.HARNESS_TIER_AUTHORITY} is what applies it.`,
+        };
+    }
+    return {
+        // NOT notable either, and this one is the clearest: the text calls it "the
+        // safe default". Flagging the safest posture as a warning inverts the
+        // signal — the tier that grants the most is the one worth surfacing, which
+        // is exactly what the `notable` docstring says.
+        notable: false,
+        detail: `${harness} is Tier 3 (the safe default for any unrecognised harness): NO platform ` +
+            'credential is injected, and an operator-configured `auto` mode is downgraded to ' +
+            'per-call adjudication.',
+        remedy: `Tier 3 is what an unmapped name resolves to. If you expected otherwise, the name the ` +
+            `daemon spawns does not match any key in ${exports.HARNESS_TIER_TABLE}.`,
+    };
+}