@mossbear/protocol 0.1.0-alpha.26

package/dist/schemas.js

@@ -0,0 +1,1422 @@
+/**
+ * Runtime validation schemas using Valibot.
+ *
+ * Schemas are the single source of truth — TypeScript types in types.ts are
+ * derived from these via `v.InferOutput<typeof Schema>`.
+ *
+ * Callers can use the exported `parse*` wrappers (throw ValiError on invalid
+ * input) or call `v.safeParse(Schema, data)` directly for non-throwing checks.
+ */
+import * as v from 'valibot';
+// ---------------------------------------------------------------------------
+// Core enum schemas
+// ---------------------------------------------------------------------------
+export const VerdictSchema = v.picklist(['aligned', 'unguided', 'misaligned']);
+export const GuidingTierSchema = v.picklist(['pattern_match', 'cached', 'llm', 'batch']);
+export const PlatformKindSchema = v.picklist([
+    'claude_code',
+    'cursor',
+    'copilot',
+    'windsurf',
+    'other',
+]);
+export const GuideFileFormatSchema = v.picklist([
+    'agents-md',
+    'agents-dir',
+    'claude-md',
+    'claude-rules',
+    'cursorrules',
+    'cursor-rules',
+    'skill-md',
+]);
+const NonEmptyStringSchema = v.pipe(v.string(), v.minLength(1));
+const Sha256HexSchema = v.pipe(v.string(), v.regex(/^[a-f0-9]{64}$/i));
+// No eval-provider schemas here. They described the LLM credentials the CLI
+// needed to grade on-device; grading is server-side and the CLI holds no
+// provider config (docs/plans/cli-local-grading-removal-plan.md). The server's
+// own provider settings are environment variables read in
+// `apps/dashboard/src/lib/eval/serverEvalAdapter.ts`, not a wire contract.
+// Auth wire schemas used to live here (ValidateTokenRequest/Response,
+// CliTokenMetadata). The validate-token route never adopted them — it checks
+// `typeof body.token === 'string'` by hand — and nothing else imported them.
+// Deleted rather than kept as a parallel contract that had already drifted
+// from the route's `{ valid }` response.
+// The guide snapshot schemas live further down, after
+// `SafeRelativePosixPathSchema` and `GuideDiscoveryRootSchema`: the bundle now
+// carries the same `(root, path)` pair the import payload does, and a `const`
+// cannot be referenced above its own declaration.
+/** Max serialized size (UTF-8 bytes) of an imported guide file's raw content. */
+export const MAX_RAW_GUIDE_CONTENT_BYTES = 512 * 1024;
+/** Max member files a single skill-md payload may carry. */
+export const MAX_SKILL_MEMBER_FILES = 64;
+const BoundedRawContentSchema = v.pipe(v.string(), v.check((value) => new TextEncoder().encode(value).length <= MAX_RAW_GUIDE_CONTENT_BYTES, `rawContent must be at most ${MAX_RAW_GUIDE_CONTENT_BYTES} bytes`));
+// A path that is safe to re-create on disk and safe to store as identity:
+// forward slashes only, never absolute (POSIX or Windows drive-letter form),
+// no empty / `.` / `..` segments, no control characters. Every path this
+// protocol carries is eventually written into a project tree by the export
+// round-trip, so the rule belongs at the schema boundary rather than in each
+// consumer — CLAUDE.md → Validation.
+//
+// Exported so the member-files read path (server response filtering, CLI
+// defense-in-depth before writing to disk) enforces the identical rule.
+export const SafeRelativePosixPathSchema = v.pipe(v.string(), v.minLength(1), v.maxLength(512), v.check((path) => !path.includes('\\'), 'path must use forward slashes'), v.check((path) => !path.startsWith('/') && !/^[a-zA-Z]:/.test(path), 'path must be relative'), v.check((path) => !/[\u0000-\u001f\u007f]/.test(path), 'path must not contain control characters'), v.check((path) => path
+    .split('/')
+    .every((segment) => segment !== '' && segment !== '.' && segment !== '..'), 'path must not contain empty, "." or ".." segments'));
+// Member paths are relative to the skill directory, and additionally may never
+// name the skill's own SKILL.md (the payload itself).
+export const SkillMemberPathSchema = v.pipe(SafeRelativePosixPathSchema, v.check((path) => path.toLowerCase() !== 'skill.md', 'path must not shadow the skill’s own SKILL.md'));
+// A sibling file of a skill's SKILL.md (scripts/, references/, assets/,
+// supporting docs), imported alongside it as a guide_file row.
+export const RawSkillMemberFileSchema = v.object({
+    path: SkillMemberPathSchema,
+    rawContent: BoundedRawContentSchema,
+    lastModified: v.pipe(v.number(), v.integer(), v.minValue(0)),
+    content_hash: Sha256HexSchema,
+});
+/** Max skipped-member paths a skill-md payload may report alongside `members`. */
+export const MAX_SKILL_SKIPPED_MEMBER_PATHS = 256;
+// Paths (relative to the skill directory) that discovery found but could not
+// import this run — binary/non-UTF-8, oversized, unreadable, or beyond the
+// member cap. Deliberately looser than SkillMemberPathSchema: these describe
+// what is on the user's disk and are only ever string-matched against stored
+// member paths server-side (never re-created as files), so an odd on-disk
+// filename must not fail the whole payload.
+const SkippedMemberPathSchema = v.pipe(v.string(), v.minLength(1), v.maxLength(512));
+/**
+ * Which root a discovered guide file's `path` is relative to: the repo checkout
+ * (`project`) or the user's homedir (`global`, e.g. `.claude/CLAUDE.md`).
+ * Part of the import resolution key — see `RawGuideFilePayloadSchema.root`.
+ */
+export const GuideDiscoveryRootSchema = v.picklist(['project', 'global']);
+// ---------------------------------------------------------------------------
+// Guide snapshot schemas
+// ---------------------------------------------------------------------------
+export const GuideSnapshotSchema = v.object({
+    id: v.string(),
+    title: v.string(),
+    content: v.string(),
+    enabled: v.boolean(),
+    updatedAt: v.string(),
+    // origin is `file:{format}:{path}` for imported guides, null/absent
+    // otherwise. contentHash is the SHA-256 of the canonical bytes; the CLI uses
+    // the pair to round-trip imported files back to disk without re-encoding.
+    //
+    // **`origin` is not superseded by `(root, path)`.** Nothing on the write side
+    // reconciles on it after this slice, but `resolveRuleFileDelivery` still
+    // matches delivery evidence on `(origin, contentHash)`
+    // (`apps/dashboard/src/lib/eval/ruleFileDelivery.ts:395-430`), so dropping it
+    // would make every guide read as undelivered — silently, since runs still
+    // grade and verdicts still appear. It stays as provenance.
+    origin: v.optional(v.nullable(v.string())),
+    contentHash: v.optional(v.nullable(Sha256HexSchema)),
+    // Which scope root `path` is relative to, and the path itself — the write
+    // side's half of the identity the read side already stores on
+    // `guide_files.root` / `guide_files.path`
+    // (`guide-write-side-identity-plan.md` → "Carry `root` on every write path").
+    //
+    // Without them the bundle could not express "global": `origin` is
+    // `file:{format}:{path}` with no root component, so every writer resolved it
+    // against the repo and a guide imported from `~/.claude/CLAUDE.md` came back
+    // down as `<repo>/.claude/CLAUDE.md`.
+    //
+    // **Both optional and nullable, and their absence is not an error.** A guide
+    // authored in the dashboard has no path; a row imported before the columns
+    // existed has neither. Such a guide keeps resolving from `origin` alone —
+    // today's behaviour — rather than becoming undeliverable. A missing `root` is
+    // read as `project`, which is what every pre-existing row meant.
+    root: v.optional(v.nullable(GuideDiscoveryRootSchema)),
+    path: v.optional(v.nullable(SafeRelativePosixPathSchema)),
+});
+export const GuideBundleResponseSchema = v.object({
+    guides: v.array(GuideSnapshotSchema),
+    pulledAt: v.string(),
+});
+export const RawGuideFilePayloadSchema = v.pipe(v.object({
+    // Relative to the discovery root the CLI walked (`payloadPath`,
+    // `packages/cli/src/rules/discover.ts:29-30`). Two things depend on it
+    // being a safe relative path, which is why it is parsed here rather than
+    // guarded downstream:
+    //
+    // - it is embedded verbatim in the guide's `origin` (`file:{format}:{path}`)
+    //   and parsed back out to place the file on disk. The writer that does so
+    //   is now the docs phase's projection resolver
+    //   (`packages/cli/src/docs/guide-projection.ts`), which rejects anything
+    //   absolute, traversing or uncontained — so an unsafe path stores a guide
+    //   that can never round-trip. (`mossbear guides export` was the original
+    //   writer and skipped such a path *silently*; it was deleted by
+    //   `unified-item-sync` Slice 5.);
+    // - it is stored as `guide_files.path`, the column import reconciles on
+    //   (`guide-versioned-identity-plan.md` → Decision 4), and identity must
+    //   not be keyable on a value the exporter refuses to honour.
+    path: SafeRelativePosixPathSchema,
+    // Which discovery root `path` is relative to — `guide-versioned-identity-plan.md`
+    // → Decision 6. Without it, `(repoId, path)` collapses a project skill onto
+    // its `~/.claude/skills` twin: `.claude/skills` is in both of the CLI's root
+    // lists and both scans emit the same relative string, while `repoId` is
+    // envelope-level so both files carry the same one.
+    //
+    // **Optional, and its absence is not an error** — a CLI predating this field
+    // sends none, exactly as it may send no `repoId`. A payload missing either
+    // does not participate in reconciliation and keeps the content-hash insert
+    // behaviour it was created under, rather than being defaulted to `'project'`:
+    // guessing would let an old client's `--global` file adopt a project row.
+    root: v.optional(GuideDiscoveryRootSchema),
+    format: GuideFileFormatSchema,
+    rawContent: BoundedRawContentSchema,
+    lastModified: v.pipe(v.number(), v.integer(), v.minValue(0)),
+    content_hash: Sha256HexSchema,
+    // Only meaningful on `skill-md` payloads. `[]` asserts the skill has no
+    // member files (stale synced rows are removed server-side); omitting the
+    // field means "no member information" and leaves member rows untouched.
+    // No CLI caller omits it today — every sender reaches this schema through
+    // a directory scan that populates it — but the distinction is load-bearing
+    // on the wire and must not collapse: reading an absent `members` as an
+    // empty skill would hard-delete a client's member rows.
+    members: v.optional(v.pipe(v.array(RawSkillMemberFileSchema), v.maxLength(MAX_SKILL_MEMBER_FILES))),
+    /**
+     * The body-item version this machine last agreed with the server about for
+     * this `(scope, root, path)` — the machine-local baseline
+     * (`guide-versioned-identity-plan.md` → slice 2b-B, D10 in
+     * `context-bundle-authoring-plan.md`).
+     *
+     * It is the *client* half of the reconcile precondition, and it exists to
+     * answer a question the server cannot: whether the bytes on this disk were
+     * edited **from** the version the server currently holds, or from an older
+     * one. The server-only guard shipped in 2b-A can see that a dashboard edit
+     * exists, never that this machine has already seen it — so a guide the
+     * dashboard edited and the user then re-synced to disk forks forever.
+     *
+     * **Optional, and its absence is not an error.** A CLI predating the
+     * baseline store, a fresh machine, or a deleted `~/.mossbear/state/` sends
+     * none, and the payload falls back to the server-only guard exactly as it
+     * behaves today. Absence therefore degrades to "decline and fork", never to
+     * an overwrite; a *stale* value degrades to a reported conflict.
+     */
+    expectedVersion: v.optional(v.pipe(v.number(), v.integer(), v.minValue(1))),
+    // Only alongside `members`: member paths present on disk but not imported
+    // this run. The server must NOT treat their absence from `members` as
+    // removal — a transiently unreadable or newly-oversized file would
+    // otherwise hard-delete its previously synced row.
+    skippedMemberPaths: v.optional(v.pipe(v.array(SkippedMemberPathSchema), v.maxLength(MAX_SKILL_SKIPPED_MEMBER_PATHS))),
+}), v.check((payload) => payload.members === undefined || payload.format === 'skill-md', 'members are only supported on skill-md payloads'), v.check((payload) => payload.skippedMemberPaths === undefined || payload.members !== undefined, 'skippedMemberPaths requires members'), 
+// Case-insensitive uniqueness: the export round-trip re-creates these files
+// on disk, where the default macOS/Windows filesystems fold case — two
+// members differing only by case would silently overwrite each other.
+v.check((payload) => payload.members === undefined ||
+    new Set(payload.members.map((member) => member.path.toLowerCase())).size ===
+        payload.members.length, 'member paths must be unique (case-insensitive)'));
+// A skill guide's member file as served by GET /api/v1/guides/:id/member-files
+// — the export round-trip's read side. Lean by design: member bodies are NOT
+// part of the guide bundle (the eval hot path pulls that every session), they
+// are fetched lazily per skill guide at export time.
+export const GuideMemberFileSchema = v.object({
+    path: SkillMemberPathSchema,
+    content: BoundedRawContentSchema,
+    contentHash: Sha256HexSchema,
+});
+export const GuideMemberFilesResponseSchema = v.pipe(v.object({
+    memberFiles: v.pipe(v.array(GuideMemberFileSchema), v.maxLength(MAX_SKILL_MEMBER_FILES)),
+}), 
+// Mirrors the import payload's rule: on case-folding filesystems two
+// entries differing only by case resolve to one file, and both planning as
+// NEW would let the second silently clobber the first without the
+// OVERWRITE diff prompt. A response that case-collides is malformed.
+v.check((response) => new Set(response.memberFiles.map((file) => file.path.toLowerCase())).size ===
+    response.memberFiles.length, 'member file paths must be unique (case-insensitive)'));
+/** Max number of rules accepted in a single `POST /api/rules/import` request. */
+export const MAX_RULES_IMPORT_BATCH = 100;
+/** Opaque checkout digest shared by run logs, manifests, and `runs.repo_id`. */
+export const RepoIdSchema = v.pipe(v.string(), v.regex(/^repo_[0-9a-f]{32}$/, 'repoId must be repo_ followed by 32 hex chars'));
+/** Longest accepted `projectId`. Generated ids are far shorter; this bounds a hand-declared one. */
+const MAX_PROJECT_ID_LENGTH = 128;
+/**
+ * A repo's declared portable identity. See `RulesImportRequestSchema.projectId`
+ * for why this is looser than {@link RepoIdSchema} — a declared id is
+ * human-authored and predates any prefix rule.
+ */
+export const ProjectIdSchema = v.pipe(v.string(), v.trim(), v.minLength(1), v.maxLength(MAX_PROJECT_ID_LENGTH), v.regex(/^[A-Za-z0-9_.-]+$/, 'projectId must contain only letters, digits, underscore, dot or hyphen'));
+// Envelope-only schema: caps request shape/size before the per-item
+// parseRawGuideFilePayload loop validates each rule in detail (preserves
+// index-aware error reporting — see apps/dashboard/app/api/rules/import+api.ts).
+export const RulesImportRequestSchema = v.object({
+    rules: v.pipe(v.array(v.unknown()), v.maxLength(MAX_RULES_IMPORT_BATCH)),
+    /**
+     * Which checkout these files came from — the same opaque digest the hook and
+     * the rule manifest already carry (`packages/cli/src/repo-id.ts`,
+     * `RuleManifestSchema.repoId`). Envelope-level, not per-file: every file in
+     * one import comes from one repo, and the per-file payload stays lean (the
+     * "Import endpoint payload" resolved decision).
+     *
+     * It is what lets the server reconcile an edited file back onto the guide it
+     * already created instead of inserting a second one. `origin` alone cannot:
+     * it is `file:{format}:{path}` with no repo component, so two checkouts
+     * sharing `.agents/code-style.md` would collide.
+     *
+     * **Optional, and its absence is not an error.** A CLI predating this field
+     * sends none, and the server falls back to the content-hash dedupe it always
+     * used. Never send a repo id derived anywhere but `repoIdFromRoot` — the
+     * digest is keyed by a machine-local secret precisely so the server never
+     * learns a path.
+     *
+     * Shaped by the canonical `RepoIdSchema` (shared with run logs and manifests)
+     * rather than a looser local check: a row storing anything but
+     * a real digest could never match one, so a malformed identity has to be
+     * rejected at the boundary instead of persisted as a permanent orphan.
+     */
+    repoId: v.optional(RepoIdSchema),
+    /**
+     * The repo's **portable** identity — `project.id` from the committed
+     * `<repo>/.mossbear/config.json` (`guide-write-side-identity` slice 1, shipped in
+     * #540). This is what makes `(scope, path)` reconciliation portable, and it is
+     * the field `unified-item-sync` slice 2 exists to put on the wire.
+     *
+     * **Why `repoId` is not enough, even though it is already here.**
+     * `repoIdFromRoot` is an HMAC keyed by a machine-local secret
+     * (`packages/cli/src/repo-id.ts`), so the same checkout on two machines — or
+     * one teammate's clone versus another's — produces two different digests. A
+     * guide reconciled on it therefore forks the moment anyone else edits the
+     * file, which is the one-way trip this item is closing. `projectId` is
+     * declared in a committed file, so every clone agrees on it.
+     *
+     * **Optional, and its absence is not an error.** A CLI predating this field
+     * sends none and the server falls back to `repoId` scoping, which is exactly
+     * the behaviour those clients already have. A repo that has never run
+     * `mossbear init` also has no declaration, and must keep importing.
+     *
+     * Deliberately looser than `RepoIdSchema`: a generated id is
+     * `proj_`+hex, but a *declared* one is whatever a human committed —
+     * `readRepoProjectId` accepts any non-empty trimmed string
+     * (`packages/cli/src/docs/repo-config.ts`), and rejecting those here would
+     * break a shipped contract. Constrained only as far as it must be to serve as
+     * a storage key: no whitespace, no path separators, no control characters,
+     * bounded length.
+     */
+    projectId: v.optional(ProjectIdSchema),
+});
+/**
+ * What the server did with one payload, reported per file so the CLI can update
+ * its machine-local baseline (`guide-versioned-identity-plan.md` → slice 2b-B).
+ *
+ * The distinction that matters is not "did something change" but **do disk and
+ * server now agree**: `imported`, `updated` and `skipped` all mean they do, and
+ * only those license recording a new baseline. `conflict` means the disk bytes
+ * did *not* land — recording the server's version for one would hand the next
+ * import a matching `expectedVersion` and turn a refused overwrite into an
+ * automatic one on the following run, which is the failure this whole precondition
+ * exists to prevent.
+ */
+export const GuideImportOutcomeSchema = v.picklist([
+    'imported',
+    'updated',
+    'skipped',
+    'conflict',
+]);
+/**
+ * Per-payload import outcome, addressed by the same `(root, path)` pair the
+ * server reconciles on so the CLI can key its baseline identically without
+ * re-deriving anything.
+ *
+ * `version` is the body item's version **as the server holds it after this
+ * request** — the value a later import should send as `expectedVersion` once
+ * disk and server agree. It is reported for a `conflict` too, deliberately: the
+ * conflict report needs it to offer explicit resolution, and reporting it is not
+ * the same as recording it.
+ *
+ * Entries are omitted for a payload the server could not address at all (no
+ * `root`, or a pre-R0 row): there is no identity to key a baseline on, and
+ * inventing one would let a later import claim a precondition it never observed.
+ */
+export const GuideImportResultSchema = v.object({
+    root: GuideDiscoveryRootSchema,
+    path: SafeRelativePosixPathSchema,
+    outcome: GuideImportOutcomeSchema,
+    version: v.pipe(v.number(), v.integer(), v.minValue(1)),
+});
+// Deletion signal for a previously imported guide file that disappeared from
+// disk. The dashboard disables (sets active=false) any row whose origin matches
+// `file:{format}:{path}` — the row is retained so historical actions are not
+// orphaned, and so re-creating the file can flip it back on.
+//
+// **That last part is not true today.** The import endpoint's lookup has no
+// `active` predicate, so restoring a deleted file matches the disabled row's
+// hash and is skipped — the row stays off. Reactivation arrives with
+// reconciliation (`guide-versioned-identity` slice 2), which resolves the row
+// by `(userId, repoId, origin)` rather than by hash.
+//
+// **No first-party emitter as of 2026-08-11.** `mossbear rules watch` was this
+// signal's only caller and was deleted (`guide-versioned-identity-plan.md` →
+// "Watch removed"), so nothing in the CLI now derives a deletion from a
+// vanished file. Schema and route stay: Decision 3 of that plan keeps exactly
+// these `(userId, origin)` → `active=false` semantics for unshared
+// repo-authored guides, and whatever re-introduces the signal must address it
+// by item id rather than reviving the origin path.
+export const RawGuideFileDeletionSchema = v.object({
+    path: v.pipe(v.string(), v.minLength(1)),
+    format: GuideFileFormatSchema,
+});
+/** Max number of deletions accepted in a single `POST /api/rules/deletions` request. */
+export const MAX_RULE_DELETIONS_BATCH = 500;
+// Envelope-only schema, matching RulesImportRequestSchema's shape: caps
+// request shape/size before the per-item parseRawGuideFileDeletion loop in
+// apps/dashboard/app/api/rules/deletions+api.ts validates each entry in
+// detail (preserves its index-aware error reporting).
+export const RuleDeletionsRequestSchema = v.object({
+    deletions: v.pipe(v.array(v.unknown()), v.maxLength(MAX_RULE_DELETIONS_BATCH)),
+});
+// No RuleDeletionsResponseSchema — the route returns
+// `Response.json({ disabled, skipped })` directly and nothing parsed the
+// response shape.
+// ---------------------------------------------------------------------------
+// Context bundle schemas (docs/plans/context-layer-mcp-inbox-plan.md — Phase 0)
+// ---------------------------------------------------------------------------
+// url-safe slug, unique per user. Lowercase alphanumerics + hyphens, must start
+// with an alphanumeric so it reads cleanly in a URL/path.
+const BundleSlugSchema = v.pipe(v.string(), v.minLength(1), v.maxLength(64), v.regex(/^[a-z0-9][a-z0-9-]*$/, 'slug must be lowercase alphanumeric with hyphens'));
+export const BundleSchema = v.object({
+    id: v.string(),
+    slug: BundleSlugSchema,
+    name: v.string(),
+    createdAt: v.string(),
+});
+export const BundleListResponseSchema = v.object({
+    bundles: v.array(BundleSchema),
+});
+export const CreateBundleRequestSchema = v.object({
+    slug: BundleSlugSchema,
+    name: v.pipe(v.string(), v.minLength(1), v.maxLength(200)),
+});
+export const CreateBundleResponseSchema = v.object({
+    bundle: BundleSchema,
+});
+// Membership addressing matches the bundle_items composite key: itemType is
+// part of identity, so detach must carry it too — an itemId alone cannot
+// address a `guide` membership.
+export const BundleMemberTypeSchema = v.picklist(['guide_file', 'guide']);
+export const AttachBundleMemberRequestSchema = v.object({
+    itemId: v.pipe(v.string(), v.minLength(1)),
+    // Defaults to 'guide_file' server-side.
+    itemType: v.optional(BundleMemberTypeSchema),
+});
+export const AttachBundleMemberResponseSchema = v.object({
+    // False when the item was already a member — attach is idempotent, and the
+    // caller (multi-select menu applying a diff) treats both as success.
+    attached: v.boolean(),
+});
+export const DetachBundleMemberResponseSchema = v.object({
+    detached: v.boolean(),
+});
+// Rename changes the display name only. The slug is the bundle's identity —
+// repos subscribe by slug in `.mossbear/config.json` → `docs.bundles`, and
+// `mossbear pull <slug>` addresses it — so a slug change would silently break
+// every subscribed repo (context-bundle-authoring-plan.md → D14).
+export const RenameBundleRequestSchema = v.object({
+    name: v.pipe(v.string(), v.minLength(1), v.maxLength(200)),
+});
+export const RenameBundleResponseSchema = v.object({
+    bundle: BundleSchema,
+});
+export const DeleteBundleResponseSchema = v.object({
+    deleted: v.boolean(),
+    // `movedToInbox` was removed in `inbox-as-view` slice 2. Deleting a bundle no
+    // longer re-parents anything: an item that loses its last membership is
+    // unfiled, which is what the inbox view shows, rather than stranded. The
+    // field could only ever have reported 0 afterwards, and a number that can
+    // never be non-zero is a discriminator carrying no decision. Nothing on the
+    // CLI wire parsed it — `parseDeleteBundleResponse` has one caller, the
+    // dashboard's own `bundlesApi.ts`.
+});
+// ---------------------------------------------------------------------------
+// Context item + inbox schemas (context-layer-mcp-inbox-plan.md — Phase 1a)
+// ---------------------------------------------------------------------------
+// The `type` of an item returned to an agent. A `guide` is a canonical guide
+// row; the rest are guide_files rows (documents, references, assets).
+export const ContextItemTypeSchema = v.picklist([
+    'guide',
+    'document',
+    'reference',
+    'asset',
+]);
+// The contentType a caller may *create* through the context layer. `guide` is
+// deliberately absent, and stays absent after slice 2b-B made guides pushable:
+// this schema is reached only by POST (create) and the MCP `push_context`
+// tool's create branch — the PUT body carries no contentType at all
+// (`UpdateContextItemRequestSchema` below). So admitting `guide` here could
+// only legalize a *create*, which the endpoint cannot honor: POST always calls
+// `insertBundleGuideFile`, which writes a standalone guide_files row with
+// `guideId: null` and never the `guides` registration a guide needs, so the
+// caller would get a 201 for something that is not a guide. Updating an
+// existing guide needs nothing from this picklist — it is addressed by
+// `itemId` alone (`guide-versioned-identity-plan.md` → Slice 2b-B, the third
+// Codex constraint, resolved as "restrict to itemId-bearing updates").
+export const PushContentTypeSchema = v.picklist(['document', 'reference', 'asset']);
+// Inbox capture is text or an image today (image upload lands in Phase 2b).
+export const InboxContentTypeSchema = v.picklist(['document', 'asset']);
+/** Max serialized size (UTF-8 bytes) of a pushed or captured item's content. */
+export const MAX_CONTEXT_CONTENT_BYTES = 256 * 1024;
+const ContextContentSchema = v.pipe(v.string(), v.check((value) => new TextEncoder().encode(value).length <= MAX_CONTEXT_CONTENT_BYTES, `content must be at most ${MAX_CONTEXT_CONTENT_BYTES} bytes`));
+const ContextItemNameSchema = v.pipe(v.string(), v.minLength(1), v.maxLength(200));
+// The wire ceiling for an in-place update — see UpdateContextItemRequestSchema
+// for why it is the guide bound rather than the context bound.
+const UpdatableContentSchema = v.pipe(v.string(), v.check((value) => new TextEncoder().encode(value).length <= MAX_RAW_GUIDE_CONTENT_BYTES, `content must be at most ${MAX_RAW_GUIDE_CONTENT_BYTES} bytes`));
+// The item shape returned to agents. `content` is nullable because an asset
+// stores an object key elsewhere (Phase 2b), not inline text.
+export const ContextItemSchema = v.object({
+    id: v.string(),
+    type: ContextItemTypeSchema,
+    name: v.string(),
+    contentType: v.string(),
+    content: v.nullable(v.string()),
+    origin: v.optional(v.nullable(v.string())),
+    // Monotonic content version of the underlying doc (guide_files), surfaced so a
+    // caller can echo it back as an expected-version precondition. See
+    // doc-version-history-plan.md.
+    //
+    // A `guide` item reports the version of its **body item** — the guide_files
+    // row holding its content (`guide-versioned-identity-plan.md` → Decision 1).
+    // That is the row a guide push updates, so the precondition a caller echoes
+    // back is checked against the same counter it read. Guides carried no version
+    // until slice 2b-B, which is why this stays optional: a guide whose
+    // `body_item_id` is still NULL (created by an old client mid-rollout, or
+    // imported before slice 1's backfill) has no version to report, and the CLI
+    // declines to push it rather than falling back to last-write-wins.
+    version: v.optional(v.number()),
+    // Scope root and path, mirroring `GuideSnapshotSchema` — the docs phase
+    // projects an item onto disk, and without a root it resolved every one of
+    // them against the repo checkout. Every member kind carries the pair: a
+    // `guide` since #543, and a `guide_file` member — documents included — since
+    // `unified-item-sync` put the columns on the wire and `docs-in-place` slice 0
+    // made the docs phase land a document at its own declared path rather than in
+    // the bundle directory. The same optional/nullable rule applies throughout:
+    // absent means "no declared path", which degrades to the origin-derived
+    // projection (guides) or the bundle-directory default (documents) rather than
+    // failing.
+    root: v.optional(v.nullable(GuideDiscoveryRootSchema)),
+    path: v.optional(v.nullable(SafeRelativePosixPathSchema)),
+    updatedAt: v.string(),
+});
+export const ContextItemsResponseSchema = v.object({
+    items: v.array(ContextItemSchema),
+});
+/** Max number of context item ids a push may cite as its transform sources. */
+export const MAX_TRANSFORM_SOURCE_IDS = 100;
+/**
+ * The ids of the caller-owned context items a pushed document was produced
+ * from (inbox captures, bundle items — any item the caller owns). Shared
+ * between the REST contract and the MCP tool's client-side arg validation so
+ * the two can't drift.
+ */
+export const SourceItemIdsSchema = v.pipe(v.array(v.pipe(v.string(), v.minLength(1))), v.minLength(1), v.maxLength(MAX_TRANSFORM_SOURCE_IDS));
+// The update-side variant: same element and upper bound, but an empty array is
+// legal and means "clear the stored provenance". See
+// `UpdateContextItemRequestSchema.sourceItemIds` for why the create side keeps
+// the non-empty bound.
+export const UpdatableSourceItemIdsSchema = v.pipe(v.array(v.pipe(v.string(), v.minLength(1))), v.maxLength(MAX_TRANSFORM_SOURCE_IDS));
+// Push a canonical item into a bundle. `itemId` present → update in place (the
+// MCP push maps to PUT); absent → create (maps to POST). The dedicated update
+// schema below is what the PUT route validates.
+//
+// `sourceItemIds` (optional, on create and update alike) cites the context
+// items the pushed document was produced from. It is **provenance**: the server
+// validates the ids against the caller's own items and stores them on the
+// item's metadata. It no longer triggers a second grading pass — that path was
+// removed in `transform-grading-removal`; work an agent does is graded once,
+// through its run.
+export const PushContextRequestSchema = v.object({
+    name: ContextItemNameSchema,
+    contentType: PushContentTypeSchema,
+    content: ContextContentSchema,
+    itemId: v.optional(v.string()),
+    origin: v.optional(v.nullable(v.string())),
+    sourceItemIds: v.optional(SourceItemIdsSchema),
+});
+export const PushContextResponseSchema = v.object({
+    item: ContextItemSchema,
+    created: v.boolean(),
+});
+// Update a canonical item in place — the edit propagates to every bundle that
+// references it. Both fields are optional so a partial update parses; the route
+// rejects a body that changes nothing.
+export const UpdateContextItemRequestSchema = v.object({
+    itemId: v.pipe(v.string(), v.minLength(1)),
+    name: v.optional(ContextItemNameSchema),
+    // Bounded by the **guide** cap, not the context cap, because an update can
+    // target either kind and the two disagree: an imported guide body may be up
+    // to `MAX_RAW_GUIDE_CONTENT_BYTES` (512 KiB) while a pushed/captured item
+    // caps at `MAX_CONTEXT_CONTENT_BYTES` (256 KiB). Before slice 2b-B that gap
+    // was unreachable — guides could not be pushed — and closing it by lowering
+    // the import cap would reject guides that already import today, while raising
+    // the context cap would double what the context layer accepts for everything.
+    // So this is only the wire ceiling (the DoS bound); the *kind-specific* limit
+    // is enforced in `updateBundleGuideFileContent`, which is the one place that
+    // has already resolved which kind of row it is about to write. Enforcing it
+    // in the route instead would be exactly the rule a future caller forgets
+    // (Planning Principle 14).
+    content: v.optional(UpdatableContentSchema),
+    // Optimistic-concurrency precondition: the version the caller last read (from
+    // `ContextItemSchema.version`). When present and it no longer matches the
+    // current version, the update is rejected with 409 instead of silently
+    // clobbering a concurrent write. Omit it to keep last-write-wins behavior.
+    expectedVersion: v.optional(v.pipe(v.number(), v.integer(), v.minValue(1))),
+    // Replaces the item's stored provenance. An update re-derives the document,
+    // so the citation records where the item's *current* body came from; leaving
+    // the previous ids in place would describe content that no longer exists.
+    // This used to be rejected outright, because a transform was graded once at
+    // creation — that reason was deleted with the grader
+    // (`transform-grading-removal-plan.md`).
+    //
+    // Three states, which is why this is not `SourceItemIdsSchema`: **omitted**
+    // leaves the stored ids alone (a name-only or provenance-preserving edit),
+    // a **non-empty** list replaces them, and **`[]` clears them**. Without the
+    // empty case an item rewritten from scratch could never shed provenance that
+    // no longer describes it — the silently-wrong record this field's own
+    // rationale argues against. `POST` keeps the non-empty bound: there is
+    // nothing to clear on a create, so `[]` there would only be a second way to
+    // say "no sources" alongside omitting the field.
+    sourceItemIds: v.optional(UpdatableSourceItemIdsSchema),
+});
+export const UpdateContextItemResponseSchema = v.object({
+    item: ContextItemSchema,
+    updated: v.boolean(),
+});
+// The same edit addressed by URL instead of by body field. The item-scoped
+// `PUT /api/v1/context/items/:itemId` takes the id from the path, so carrying it
+// in the body as well would let the two disagree and force the route to pick a
+// winner. Derived with `v.omit` rather than re-declared, so the updatable fields
+// and their bounds cannot drift between the two shapes.
+export const UpdateContextItemBodySchema = v.omit(UpdateContextItemRequestSchema, [
+    'itemId',
+]);
+/** A single canonical item, for the item-scoped read route. */
+export const ContextItemResponseSchema = v.object({
+    item: ContextItemSchema,
+});
+// `POST /api/v1/context/items/:itemId/archive`. A boolean, not a count: the
+// route addresses exactly one item and answers 404 when it does not resolve, so
+// there is no "succeeded on 0 of 1" state left for a number to express. That
+// ambiguity is the bug this route exists to remove — the batch inbox endpoint
+// answered `200 {archived: 0}` for an item it declined to touch
+// (`inbox-as-view-plan.md` → Evidence).
+export const ArchiveContextItemResponseSchema = v.object({
+    archived: v.boolean(),
+    item: ContextItemSchema,
+});
+export const InboxCaptureRequestSchema = v.object({
+    contentType: InboxContentTypeSchema,
+    content: ContextContentSchema,
+    name: v.optional(ContextItemNameSchema),
+    source: v.optional(v.string()),
+});
+// An inbox item carries capture provenance on top of the base item shape.
+// `capturedAt` is the underlying row's createdAt, so "last 24h" is a filter on it.
+export const InboxItemSchema = v.object({
+    id: v.string(),
+    type: ContextItemTypeSchema,
+    name: v.string(),
+    contentType: v.string(),
+    content: v.nullable(v.string()),
+    source: v.optional(v.nullable(v.string())),
+    // Monotonic content version of the underlying doc, mirroring
+    // `ContextItemSchema.version` — an inbox item is a guide_file too, so a caller
+    // that edits it via PUT can echo this back as an expected-version precondition.
+    version: v.optional(v.number()),
+    capturedAt: v.string(),
+    updatedAt: v.string(),
+});
+export const InboxCaptureResponseSchema = v.object({
+    item: InboxItemSchema,
+});
+export const InboxListResponseSchema = v.object({
+    items: v.array(InboxItemSchema),
+});
+/** Max number of ids accepted in a single `POST /api/v1/context/inbox/archive` request. */
+export const MAX_INBOX_ARCHIVE_BATCH = 500;
+export const InboxArchiveRequestSchema = v.object({
+    ids: v.pipe(v.array(v.pipe(v.string(), v.minLength(1))), v.minLength(1), v.maxLength(MAX_INBOX_ARCHIVE_BATCH)),
+});
+export const InboxArchiveResponseSchema = v.object({
+    archived: v.pipe(v.number(), v.integer(), v.minValue(0)),
+});
+// ---------------------------------------------------------------------------
+// Doc version history (read API)
+// ---------------------------------------------------------------------------
+// One append-only saved version of a context doc (guide_file). Rows are served
+// lazily over REST and never sync through Zero — syncing them would grow every
+// client's initial-sync payload forever. See doc-version-history-plan.md.
+//
+// `authorType` is intentionally an open string, not a picklist: the server owns
+// the closed set ('user' | 'agent' | 'cli'), but a deployed client parses this
+// response strictly, and a picklist would turn any future author kind into a
+// hard parse error on an otherwise valid history read.
+export const ContextItemVersionSchema = v.object({
+    id: v.string(),
+    // Monotonic per doc; the newest version equals the item's current `version`.
+    version: v.pipe(v.number(), v.integer(), v.minValue(1)),
+    contentHash: v.string(),
+    authorType: v.string(),
+    // Non-secret provenance the write path recorded (e.g. bundle slug, capture
+    // source). Never a bearer secret — these rows outlive tokens and ride export.
+    metadata: v.optional(v.nullable(v.record(v.string(), v.unknown()))),
+    createdAt: v.string(),
+});
+// The full version including the snapshotted body, returned by the per-version
+// content fetch. `content` is nullable to stay blob-tier compatible: a future
+// encrypted/blob version stores a hash pointer, not inline text.
+export const ContextItemVersionDetailSchema = v.object({
+    id: v.string(),
+    version: v.pipe(v.number(), v.integer(), v.minValue(1)),
+    content: v.nullable(v.string()),
+    contentHash: v.string(),
+    authorType: v.string(),
+    metadata: v.optional(v.nullable(v.record(v.string(), v.unknown()))),
+    createdAt: v.string(),
+});
+// Newest-first page of a doc's version summaries. `nextCursor` is the version
+// number to pass back as `?before=` for the following (older) page, or null
+// once the oldest version has been returned.
+export const ContextItemVersionsResponseSchema = v.object({
+    versions: v.array(ContextItemVersionSchema),
+    nextCursor: v.nullable(v.number()),
+});
+export const ContextItemVersionResponseSchema = v.object({
+    version: ContextItemVersionDetailSchema,
+});
+/** Default and max page size for the version-history list endpoint. */
+export const DEFAULT_VERSIONS_LIMIT = 50;
+export const MAX_VERSIONS_LIMIT = 200;
+// ---------------------------------------------------------------------------
+// Sync payload schemas
+// ---------------------------------------------------------------------------
+const DashboardSyncTierSchema = v.picklist([
+    'pattern_match',
+    'cached',
+    'llm',
+    'batch',
+    'unguided',
+]);
+const DashboardGuideSuggestionStatusSchema = v.picklist([
+    'pending',
+    'accepted',
+    'dismissed',
+]);
+const DashboardFeedbackCandidateStatusSchema = v.picklist([
+    'inferred',
+    'confirmed',
+    'dismissed',
+]);
+const DashboardFeedbackSignalTypeSchema = v.picklist([
+    'correction',
+    'approval',
+    'implied_preference',
+    'stated_preference',
+    'skill_suggestion',
+]);
+export const ProposalCitationSchema = v.object({
+    sessionId: v.string(),
+    timestamp: v.optional(v.string()),
+    summary: v.string(),
+});
+/** Max serialized size of an action's `metadata` field — bounds storage bloat. */
+export const MAX_ACTION_METADATA_BYTES = 16 * 1024;
+/**
+ * Longest accepted CLI version string. Releases are `x.y.z` /
+ * `x.y.z-<channel>.<n>`, so this is generous — it exists because the value is
+ * client-supplied and lands on every action row, not to constrain the format
+ * (ordering already fails closed on anything unparseable).
+ */
+const MAX_CLI_VERSION_LENGTH = 64;
+const CliVersionSchema = v.pipe(v.string(), v.nonEmpty(), v.maxLength(MAX_CLI_VERSION_LENGTH));
+/**
+ * Identity of the skill an agent loaded, captured by the logger hook from a
+ * `Skill` tool call (docs/plans/run-level-grading-plan.md, Slice 0).
+ *
+ * Two fields because the hook can only ever be sure of one of them:
+ *
+ * - `name` is `tool_input.skill` verbatim — always present, never qualified.
+ *   Two skills that share a directory name (`.claude/skills/review` and
+ *   `.agents/skills/review`) are indistinguishable by it, which is review
+ *   finding 5 on PR #387.
+ * - `path` is the skill's *directory*, relative to the discovery root the
+ *   guide import walks and in the same posix form its `origin` carries
+ *   (`.claude/skills/review`). This is the qualified identity: it is exactly
+ *   `guides.origin`'s path with the trailing `/SKILL.md` removed, so the two
+ *   sides of the join are the same string rather than two derivations of it.
+ *   Optional because the hook resolves it by probing the filesystem: a skill
+ *   that lives somewhere the probe does not look (a plugin skill, a
+ *   `~/.claude/skills` skill, a session whose cwd is not the repo root) has a
+ *   name and no path, and matching falls back to the name.
+ */
+export const ActionSkillLoadSchema = v.object({
+    name: NonEmptyStringSchema,
+    path: v.optional(NonEmptyStringSchema),
+});
+/**
+ * The `actions.action_type` a skill load is stored under.
+ *
+ * Deliberately **not** a member of `KNOWN_ACTION_TYPES` below, even though the
+ * CLI emits it on purpose. A skill load is evidence about what was in the
+ * agent's *context*, not a piece of work anyone should grade — it is an input to
+ * `inContextGuides`, never a row the grader judges (`gradeableActions.ts`
+ * filters it out). Keeping it out of the known-vocabulary list is what stops it
+ * being treated as gradeable work by anything that enumerates that list.
+ */
+export const SKILL_LOAD_ACTION_TYPE = 'skill_load';
+/**
+ * A machine-shaped label for *why* a tool call failed — `ENOENT`, `TimeoutError`,
+ * `permission_denied`.
+ *
+ * Deliberately not free text. An error *message* is content: it quotes file
+ * contents, stderr and third-party data, which is exactly the class
+ * `content-sync-privacy` gates and `sanitizeCommand` cannot redact (it targets
+ * shell syntax, not prose). A class is metadata, so it rides the same
+ * unblocked path as the exit code. The character set admits identifiers and
+ * dotted/namespaced codes and nothing else; anything failing it is dropped
+ * rather than truncated, because half an error class is not a smaller fact, it
+ * is a different one.
+ */
+export const ActionErrorClassSchema = v.pipe(v.string(), v.regex(/^[A-Za-z0-9_.:-]{1,32}$/, 'errorClass must be 1-32 chars of [A-Za-z0-9_.:-]'));
+/**
+ * Whether a logged tool call actually succeeded
+ * (docs/plans/action-evidence-sync-plan.md — the outcome-metadata slice).
+ *
+ * The logger hook parsed `tool_input` and dropped the `tool_response` beside
+ * it, so every action reached the grader looking like it had happened. A failed
+ * edit and a successful one rendered identically, and the run grader has no
+ * other way to tell them apart.
+ *
+ * **Absent means unknown, never success.** The hook emits this only from a
+ * response shape it recognizes (`extractActionOutcome`), and agent tool
+ * responses vary per tool and per platform; a guess here would be worse than
+ * silence, because the grader would weigh it. `status` is therefore the only
+ * required field, and the whole object is optional everywhere it appears.
+ */
+export const ActionOutcomeSchema = v.object({
+    status: v.picklist(['ok', 'error']),
+    errorClass: v.optional(ActionErrorClassSchema),
+    /**
+     * Bounded to a signed 16-bit range, which covers every real exit status
+     * (0-255, 128+signal, and Node's -1) with room to spare. The bound is a line
+     * length bound as much as a validity one: this renders into the grading
+     * prompt, where every field is capped.
+     */
+    exitCode: v.optional(v.pipe(v.number(), v.integer(), v.minValue(-32_768), v.maxValue(32_767))),
+});
+/**
+ * {@link ActionOutcomeSchema} with unknown keys refused rather than ignored.
+ *
+ * Used only by `ActionMetadataSchema`'s boundary check, where the difference
+ * matters: see the comment there. Readers parse with the permissive schema,
+ * which strips unknown keys on output the way `v.object` always has.
+ */
+const StrictActionOutcomeSchema = v.strictObject(ActionOutcomeSchema.entries);
+/**
+ * Longest narration field accepted on the wire.
+ *
+ * Matches `MAX_PROSE_CHARS` in `@mossbear/eval-core`, which is the cap the
+ * client-side redactor already applies. Duplicated as a literal rather than
+ * imported because the dependency runs the other way — `@mossbear/eval-core`
+ * depends on this package — and inverting it to share one constant would make
+ * the wire contract depend on the evaluation package. The number is a bound, so
+ * a drift between them fails safe in the direction that matters: the server
+ * refusing something the client would have sent, never the reverse.
+ */
+export const MAX_ACTION_NARRATION_CHARS = 2000;
+/**
+ * A code fence at the start of a line, allowing Markdown container prefixes.
+ *
+ * The exact structural inverse of what `stripCodeBlocks` guarantees: it removes
+ * every fenced block by this same rule, so a narration field reaching the server
+ * with a line-initial fence in it *cannot* have been produced by a client that
+ * ran the pipeline. Rejecting is therefore free of false positives — inline
+ * `` `code` `` spans and a mid-sentence "wrap it in ```" are untouched, because
+ * neither begins a line.
+ *
+ * **What this does and does not buy.** It catches the realistic failure — a
+ * client whose stripping broke, or one built against the wire schema without
+ * reading the class table — before its output lands in a column. It is not a
+ * defense against a determined client, which would simply send the same source
+ * with no fence around it; the server cannot tell prose from code in general,
+ * which is exactly why the class table strips whole *structures* rather than
+ * asking a scrubber to recognize code. Claiming more than this would be the
+ * "alignment theater" the charter's fourth commitment names.
+ */
+const LINE_INITIAL_FENCE = /^[ \t]*(?:>[ \t]?)*(?:`{3,}|~{3,})/m;
+const NarrationTextSchema = v.pipe(v.string(), v.maxLength(MAX_ACTION_NARRATION_CHARS), v.check((value) => !LINE_INITIAL_FENCE.test(value), 'narration must not contain a code block — code is stripped structurally on the client before upload'));
+/**
+ * Transcript evidence attached to an action
+ * (docs/plans/transcript-content-classes-plan.md — the founder's class call of
+ * 2026-08-13).
+ *
+ * **Two fields, and the omissions are the specification.** The class table
+ * decides that user turns and assistant *prose* sync prose-redacted, assistant
+ * code blocks are stripped to a language-and-line-count placeholder, and
+ * tool-result bodies **never** sync. There is therefore no field here for a
+ * tool result, no field for a code-block body, and no field for a diff.
+ *
+ * **`strictObject`, so a body that carries one is rejected rather than
+ * trimmed.** This is the same decision `StrictActionOutcomeSchema` above makes
+ * and for a sharper version of the same reason. A permissive `v.object` strips
+ * unknown keys on output, which would turn a client sending
+ * `narration.toolResult` into a *silently accepted* request: the sender is told
+ * it worked, learns nothing, and keeps sending. Trimming is a policy that fails
+ * open — it makes an over-sharing client indistinguishable from a correct one.
+ * Rejecting makes the class table enforceable against a client the server does
+ * not control, which is the only kind of enforcement worth having here; the
+ * CLI's own choke point (`packages/cli/src/transcript/narration.ts`) is the
+ * first line, not the last.
+ *
+ * The forward-compatibility cost is the same as `outcome`'s, and so is the
+ * ordering that pays it: widen this schema and deploy the server before any
+ * CLI starts sending a new narration field.
+ */
+export const ActionNarrationSchema = v.strictObject({
+    /**
+     * The user turn this action followed — prose-redacted on the user's machine.
+     *
+     * **Not every message with `role: 'user'`.** A tool result is delivered as a
+     * user-role message whose content is a `tool_result` block, so the client
+     * selects on content-block type rather than role
+     * (`packages/cli/src/transcript/messages.ts`). Nothing on this side can tell
+     * the difference after the fact, which is why the client selects
+     * structurally and this schema constrains the shape rather than the content.
+     */
+    userText: v.optional(NarrationTextSchema),
+    /**
+     * Assistant prose adjacent to the tool call — code blocks structurally
+     * removed, then prose-redacted, then windowed, all on the user's machine.
+     */
+    assistantText: v.optional(NarrationTextSchema),
+});
+const ActionMetadataSchema = v.pipe(v.record(v.string(), v.unknown()), v.check((value) => new TextEncoder().encode(JSON.stringify(value)).length <= MAX_ACTION_METADATA_BYTES, `metadata must serialize to at most ${MAX_ACTION_METADATA_BYTES} bytes`), 
+// `metadata` is an open record by design (platform-specific context), but the
+// one key the server *reads* has to be trustworthy: `skill` is what resolves
+// a run's loaded skills, so a malformed one must be rejected at the boundary
+// rather than silently ignored downstream.
+v.check((value) => value.skill === undefined || v.is(ActionSkillLoadSchema, value.skill), 'metadata.skill must be { name: string, path?: string }'), v.check((value) => value.repoId === undefined || v.is(RepoIdSchema, value.repoId), 'metadata.repoId must be repo_ followed by 32 hex chars'), 
+// Same reasoning as `skill` above: the server reads this one, so a malformed
+// outcome is rejected at the boundary rather than reaching the grader as a
+// half-parsed fact about whether the action succeeded.
+//
+// `v.is` only answers yes/no — it does not substitute the schema's stripped
+// output — and the surrounding `metadata` is an open record that keeps what
+// it was given. A permissive object check would therefore *store* an
+// unrecognized `outcome.message`, which is exactly the free-text error prose
+// this field exists to keep off the wire. `strictObject` is what makes the
+// check mean what it says.
+//
+// The forward-compatibility cost is real and the ordering that pays it:
+// widen this schema (server, deployed first) before any CLI starts sending a
+// new outcome field, or an un-upgraded server rejects the whole action.
+v.check((value) => value.outcome === undefined || v.is(StrictActionOutcomeSchema, value.outcome), 'metadata.outcome must be { status: "ok" | "error", errorClass?: string, exitCode?: number } with no other keys'));
+// Token usage extracted from an agent's own transcript (e.g. Claude Code
+// JSONL), keyed by model. See docs/plans/token-cost-tracking-plan.md — Phase 1
+// stores raw token counts only; cost is derived server-side in Phase 2.
+export const TokenUsageSchema = v.object({
+    model: NonEmptyStringSchema,
+    provider: v.optional(v.string()),
+    inputTokens: v.pipe(v.number(), v.integer(), v.minValue(0)),
+    outputTokens: v.pipe(v.number(), v.integer(), v.minValue(0)),
+    cacheReadTokens: v.optional(v.pipe(v.number(), v.integer(), v.minValue(0))),
+    cacheWriteTokens: v.optional(v.pipe(v.number(), v.integer(), v.minValue(0))),
+});
+export const DashboardRunUsageSchema = v.object({
+    runId: v.optional(v.string()),
+    sessionId: NonEmptyStringSchema,
+    usage: v.array(TokenUsageSchema),
+});
+// Per-skill Tier-1 "load overhead" token usage extracted from an agent's own
+// transcript (docs/plans/token-cost-tracking-plan.md §13.3) — the precise part
+// of skill-cost attribution: the tokens billed to load a Skill/SKILL.md into
+// context, approximated in v1 as the first-load message's usage. Tier 2
+// (heuristic guided-work spans) is not implemented yet.
+export const SkillUsageEntrySchema = v.object({
+    skillName: NonEmptyStringSchema,
+    model: NonEmptyStringSchema,
+    inputTokens: v.pipe(v.number(), v.integer(), v.minValue(0)),
+    cacheWriteTokens: v.optional(v.pipe(v.number(), v.integer(), v.minValue(0))),
+});
+export const DashboardSkillUsageSchema = v.object({
+    runId: v.optional(v.string()),
+    sessionId: NonEmptyStringSchema,
+    usage: v.array(SkillUsageEntrySchema),
+});
+/**
+ * Bounds on the action fields that reach an LLM prompt verbatim.
+ *
+ * Every one of these is interpolated into the run grader's action log
+ * (`apps/dashboard/src/lib/eval/runGradePrompt.ts`), so an unbounded value is
+ * not just storage bloat: it is an authenticated client deciding how much
+ * context one nominally-capped action consumes, or making the provider call
+ * fail on length over and over while the run stays retryable. The prompt caps
+ * them again on the way out — these stop the oversized value being *stored*,
+ * which is the only place a cap holds for rows the prompt never renders.
+ *
+ * Sized well above anything the CLI produces: summaries are capped at 200
+ * characters before they leave the machine (`MAX_SUMMARY_CHARS`,
+ * `packages/cli/src/action-queue.ts:31`), action types are derived from tool
+ * names, and `filePaths` carries at most one entry per action
+ * (`toSyncAction`, `packages/cli/src/action-queue.ts:135-147`).
+ */
+const MAX_ACTION_ID_LENGTH = 128;
+const MAX_ACTION_TYPE_LENGTH = 128;
+const MAX_ACTION_SUMMARY_LENGTH = 4_000;
+const MAX_ACTION_FILE_PATHS = 100;
+const MAX_ACTION_FILE_PATH_LENGTH = 1_024;
+/**
+ * An action id as it may appear in a prompt: bounded, and free of the control
+ * characters that would let it break out of the line it is rendered on. Ids are
+ * the one field the grader reads back and cites, so they cannot be truncated or
+ * sanitized after the fact without silently detaching every citation that used
+ * them — the boundary is the only place to reject a bad one.
+ */
+const ActionIdSchema = v.pipe(v.string(), v.maxLength(MAX_ACTION_ID_LENGTH), v.regex(/^[^\p{Cc}\p{Cf}\s]*$/u, 'id must not contain whitespace or control characters'));
+export const DashboardSyncActionSchema = v.object({
+    id: v.optional(ActionIdSchema),
+    adapterId: v.optional(v.string()),
+    runId: v.optional(v.string()),
+    /**
+     * Optional on the wire, but **required to be graded**: runs are the only
+     * grading unit, and an action with no session joins no run
+     * (docs/plans/run-level-grading-plan.md). The field stays optional because
+     * tightening it would 400 a whole batch — a poison pill for any queue file
+     * carrying one — and no shipped CLI omits it: the hook always writes a
+     * session id, falling back to the literal `'unknown'`
+     * (`packages/cli/src/hook-logger.ts:129`), which groups into a run like any
+     * other. A direct API caller that omits it gets its actions stored and
+     * ungraded, and the server logs `sync.actions_without_session` so the case is
+     * visible rather than silent.
+     */
+    sessionId: v.optional(v.string()),
+    actionType: v.pipe(v.string(), v.maxLength(MAX_ACTION_TYPE_LENGTH)),
+    summary: v.pipe(v.string(), v.maxLength(MAX_ACTION_SUMMARY_LENGTH)),
+    filePaths: v.optional(v.pipe(v.array(v.pipe(v.string(), v.maxLength(MAX_ACTION_FILE_PATH_LENGTH))), v.maxLength(MAX_ACTION_FILE_PATHS))),
+    verdict: v.optional(VerdictSchema),
+    gradingTier: v.optional(DashboardSyncTierSchema),
+    guideIds: v.optional(v.array(v.string())),
+    violatedGuideId: v.optional(v.nullable(v.string())),
+    evalReasoning: v.optional(v.nullable(v.string())),
+    metadata: v.optional(v.nullable(ActionMetadataSchema)),
+    /**
+     * Transcript evidence for this action. See {@link ActionNarrationSchema}.
+     *
+     * A top-level field rather than a `metadata` key, and that is a decision
+     * rather than a style choice (design review, 2026-08-15): `metadata` is an
+     * open record holding *metadata* under one shared 16 KB budget, and this is
+     * content — the first content an action carries. It lands in its own column
+     * server-side for the same reason.
+     *
+     * **No shipped CLI sends this yet.** Slice 2 builds the extraction and both
+     * halves of the enforcement; Slice 3 adds the column and the disclosure
+     * surface and is what turns it on, so nothing begins leaving a user's machine
+     * a release before the panel describing it.
+     */
+    narration: v.optional(ActionNarrationSchema),
+    /**
+     * Version of the CLI that *produced* this action's verdict.
+     *
+     * **No shipped CLI sends this any more.** Its only writer was `mossbear verdict
+     * record`, whose queue files could outlive an upgrade, which is why the
+     * per-action version was distinguished from the request-level one at all.
+     * That command is gone (docs/plans/cli-local-grading-removal-plan.md) and no
+     * client-side verdict exists to attribute.
+     *
+     * Kept on the wire for one release so an un-upgraded CLI's queued verdicts
+     * are not rejected mid-migration; the field and the `actions.cli_version`
+     * column it feeds are dropped together (`action-cli-version-column-drop`).
+     * For the CLI making the request — which is live, and what
+     * `enforceCliVersionFloor` reads — see `DashboardSyncRequestSchema`.
+     */
+    cliVersion: v.optional(CliVersionSchema),
+});
+export const DashboardGuideSuggestionSchema = v.object({
+    id: v.optional(v.string()),
+    content: v.string(),
+    reasoning: v.optional(v.string()),
+    triggerType: v.picklist([
+        'uncovered',
+        'ambiguous',
+        'performance_pattern',
+        'conversational_feedback',
+    ]),
+    sourceActionIds: v.optional(v.array(v.union([v.string(), ProposalCitationSchema]))),
+    status: v.optional(DashboardGuideSuggestionStatusSchema),
+});
+export const DashboardFeedbackCandidateSchema = v.object({
+    id: v.optional(v.string()),
+    signal: v.string(),
+    signalType: DashboardFeedbackSignalTypeSchema,
+    confidence: v.optional(v.pipe(v.number(), v.minValue(0), v.maxValue(1))),
+    occurrences: v.optional(v.pipe(v.number(), v.integer(), v.minValue(1))),
+    status: v.optional(DashboardFeedbackCandidateStatusSchema),
+});
+/** Max number of actions accepted in a single `POST /api/sync` request. */
+export const MAX_SYNC_ACTIONS_BATCH = 500;
+/** Max number of guideSuggestions/feedbackCandidates/runUsage entries per sync request. */
+export const MAX_SYNC_AUX_BATCH = 100;
+/**
+ * Max rule files one delivery manifest enumerates. Well above what a real repo
+ * carries (this one: ~20), and bounded because the manifest rides every
+ * action-carrying batch: an unbounded list would multiply across a chunked
+ * sync. Overflow sets `truncated` rather than being dropped silently.
+ */
+export const MAX_RULE_MANIFEST_FILES = 500;
+/**
+ * A rule file observed on disk in the repo `mossbear sync` ran from.
+ *
+ * `path` is relative to that repo root, in exactly the form `payloadPath`
+ * takes at import time (`packages/cli/src/rules/discover.ts`), so
+ * `file:{format}:{path}` reconstructs the `origin` the dashboard stored for
+ * the guide this file produced. That reconstruction is the whole join; nothing
+ * else about the file is needed and nothing else is sent.
+ *
+ * **Never any content.** `contentHash` is the same sha256 the import payload
+ * carries, present so a later slice can tell "delivered" from "delivered but
+ * edited since import" without shipping the bytes again.
+ */
+export const RuleManifestFileSchema = v.object({
+    path: v.pipe(v.string(), v.minLength(1), v.maxLength(512)),
+    format: GuideFileFormatSchema,
+    contentHash: Sha256HexSchema,
+});
+/**
+ * Which rule files were actually on disk in the repo this sync ran from —
+ * observed delivery, replacing the assumption that every non-skill active
+ * guide reached the agent (docs/plans/run-level-grading-plan.md, review
+ * finding 3). Without it, an account with several repos, or a
+ * dashboard-authored guide never exported anywhere, is graded against
+ * instructions the agent never received.
+ *
+ * `repoId` is an opaque, machine-local digest — deliberately not a path, a
+ * remote URL, or a repo name. Its only job is to keep two checkouts on the
+ * same account distinguishable, which is the half of review finding 5 that
+ * repo-root-relative origins cannot express: two repos each holding
+ * `.claude/skills/review` produce byte-identical origins by construction. See
+ * `repoIdFromRoot` (`packages/cli/src/rules/manifest.ts`) for how it is
+ * derived and why that derivation is privacy-safe.
+ */
+export const RuleFileManifestSchema = v.object({
+    repoId: RepoIdSchema,
+    files: v.pipe(v.array(RuleManifestFileSchema), v.maxLength(MAX_RULE_MANIFEST_FILES)),
+    /**
+     * The repo held more rule files than the cap, so `files` is a prefix. Set
+     * rather than silently trimmed: a manifest read as complete would mark the
+     * omitted files' guides undelivered, which is the exact wrong-verdict
+     * failure this field exists to prevent.
+     */
+    truncated: v.optional(v.boolean()),
+});
+export const DashboardSyncRequestSchema = v.object({
+    actions: v.optional(v.pipe(v.array(DashboardSyncActionSchema), v.maxLength(MAX_SYNC_ACTIONS_BATCH))),
+    guideSuggestions: v.optional(v.pipe(v.array(DashboardGuideSuggestionSchema), v.maxLength(MAX_SYNC_AUX_BATCH))),
+    feedbackCandidates: v.optional(v.pipe(v.array(DashboardFeedbackCandidateSchema), v.maxLength(MAX_SYNC_AUX_BATCH))),
+    runUsage: v.optional(v.pipe(v.array(DashboardRunUsageSchema), v.maxLength(MAX_SYNC_AUX_BATCH))),
+    skillUsage: v.optional(v.pipe(v.array(DashboardSkillUsageSchema), v.maxLength(MAX_SYNC_AUX_BATCH))),
+    /**
+     * Version of the CLI making *this request* — the live one, and the only
+     * `cliVersion` a shipped CLI still sends (the per-action field is a
+     * migration leftover; see `DashboardSyncActionSchema`). It sits on the
+     * envelope because the server reads it before touching any row, to
+     * compare against its version floor and reject an incompatible client with
+     * 426 rather than half-ingesting the batch. Optional: clients predating this
+     * field send none, and are never blocked for it.
+     */
+    cliVersion: v.optional(CliVersionSchema),
+    /**
+     * Sessions whose agent context has ended, named by the CLI's `SessionEnd`
+     * hook (`mossbear sync --session-complete`) — never by its per-turn `Stop` hook.
+     * The server closes those sessions' runs; every other session in the payload
+     * stays open.
+     *
+     * Session-keyed rather than a single envelope-level boolean, because one
+     * `mossbear sync` uploads every session with pending actions and chunks them
+     * across several requests. A boolean would close sessions that merely had a
+     * backlog, and would close a session before the batches carrying the rest of
+     * its actions had arrived. The CLI therefore names a session here only on the
+     * final batch that carries that session's actions.
+     *
+     * Deliberately an assertion, not a fact: `SessionEnd` also fires on
+     * `/clear`, `--resume` and `logout`, and a reclaimed cloud container may fire
+     * nothing at all. Closing is therefore reversible — later actions for a
+     * closed run reopen it — and the server's idle sweep, not this field, is what
+     * runs actually depend on being closed by. See
+     * docs/plans/run-level-grading-plan.md Slice 1.
+     */
+    completedSessionIds: v.optional(v.pipe(v.array(NonEmptyStringSchema), v.maxLength(MAX_SYNC_AUX_BATCH))),
+    /**
+     * The rule files present in the repo this sync ran from — see
+     * {@link RuleFileManifestSchema}.
+     *
+     * Envelope-level rather than per-action because it describes the machine and
+     * the checkout, not any one tool call; the server attaches it to the runs it
+     * materializes from this request. Present on every batch that carries
+     * actions, so a session chunked across several requests has the manifest
+     * available wherever its run is touched.
+     *
+     * Optional: a CLI predating this sends none, and the server must read its
+     * absence as "delivery unobserved", never as "nothing was delivered".
+     */
+    ruleManifest: v.optional(RuleFileManifestSchema),
+});
+export const ExtractedGuideSuggestionSchema = v.object({
+    id: v.string(),
+    content: v.string(),
+    reasoning: v.string(),
+    triggerType: v.picklist(['conversational_feedback']),
+    confidence: v.pipe(v.number(), v.minValue(0), v.maxValue(1)),
+    occurrences: v.pipe(v.number(), v.integer(), v.minValue(1)),
+    citations: v.array(ProposalCitationSchema),
+    source: PlatformKindSchema,
+});
+export const ExtractedSkillSuggestionSchema = v.object({
+    id: v.string(),
+    signal: v.string(),
+    confidence: v.pipe(v.number(), v.minValue(0), v.maxValue(1)),
+    occurrences: v.pipe(v.number(), v.integer(), v.minValue(1)),
+    citations: v.array(ProposalCitationSchema),
+    source: PlatformKindSchema,
+});
+export const ExtractedFeedbackBatchSchema = v.object({
+    guideSuggestions: v.array(ExtractedGuideSuggestionSchema),
+    skillSuggestions: v.array(ExtractedSkillSuggestionSchema),
+});
+// ---------------------------------------------------------------------------
+// Agent config schema
+// ---------------------------------------------------------------------------
+// AgentConfig is what `mossbear guides project` and `packages/projections` share.
+// EvalRequest/EvalResult/Finding and ProjectionRequest/ProjectionResult used
+// to wrap it for the CLI's on-device grader and a projection wire envelope;
+// both are gone (docs/plans/cli-local-grading-removal-plan.md Open questions)
+// and had zero consumers outside this package's own tests.
+export const AgentConfigSchema = v.object({
+    id: v.string(),
+    name: v.string(),
+    description: v.string(),
+    capabilities: v.array(v.string()),
+    meta: v.optional(v.record(v.string(), v.unknown())),
+});
+// ---------------------------------------------------------------------------
+// Action log schemas
+// ---------------------------------------------------------------------------
+export const ActionEntrySchema = v.object({
+    /**
+     * Stable identity, assigned by the logger hook when the action happens.
+     *
+     * Serves two jobs at once (docs/plans/action-evidence-sync-plan.md): it is
+     * the `actions.id` a sync sends, so re-syncing the same append-only run log
+     * is a no-op against the server's `onConflictDoNothing`; and it is the
+     * correlation key for joining transcript evidence to an action, which
+     * adjacency cannot do once one assistant message emits several tool calls.
+     *
+     * Optional because run logs written before this field existed must stay
+     * readable. Sync derives an id for those from `(sessionId, line index)`; see
+     * `deriveLegacyActionId`.
+     */
+    id: v.optional(v.string()),
+    timestamp: v.string(),
+    sessionId: v.string(),
+    toolName: v.string(),
+    filePath: v.optional(v.string()),
+    command: v.optional(v.string()),
+    /**
+     * Set only for a `Skill` tool call: which skill the agent loaded.
+     *
+     * This is what makes a skill load ride the action stream instead of the
+     * transcript. `skill_usage` — the other place a loaded skill name is
+     * recorded — is populated by `extractRunUsage`, which returns empty unless
+     * `mossbear sync` is given `--transcripts-dir`, and the hook `mossbear init`
+     * installs never passes one. So the transcript path has no data in a normal
+     * session, while an action definitionally syncs.
+     */
+    skill: v.optional(ActionSkillLoadSchema),
+    /**
+     * Where this session's transcript lives on *this machine*, as the agent
+     * itself reported it.
+     *
+     * **Local-only, and it must stay that way.** `toSyncAction`
+     * (`packages/cli/src/action-queue.ts`) builds the wire payload field by
+     * field and does not include this one; transcripts are disclosed as
+     * local-only (`apps/dashboard/src/lib/privacy/whatSyncs.ts`), and a path is
+     * still a fact about the user's filesystem. It exists so `mossbear sync` can
+     * find the transcript for a session it is already uploading without
+     * searching for it (docs/plans/default-transcript-discovery-plan.md →
+     * "Session resolution").
+     *
+     * Optional three times over: run logs written before this field existed must
+     * stay readable, a hook protocol other than Claude Code's may not send it,
+     * and resolution falls back to the `<sessionId>.jsonl` filename convention
+     * when it is absent or stale.
+     */
+    transcriptPath: v.optional(v.string()),
+    /**
+     * Which checkout produced this action — the same digest as
+     * {@link RuleFileManifestSchema}'s `repoId`, stamped by the logger hook from
+     * the event's `cwd` so a sync in repo A does not attach A's manifest to
+     * sessions that ran in repo B (`run-repo-attribution`).
+     */
+    repoId: v.optional(RepoIdSchema),
+    /**
+     * Whether the tool call succeeded, when the hook could tell.
+     *
+     * Optional twice over: run logs written before this field existed must stay
+     * readable, and a recognized response shape is not guaranteed even now. See
+     * {@link ActionOutcomeSchema} — absent is "unknown", not "fine".
+     */
+    outcome: v.optional(ActionOutcomeSchema),
+});
+/**
+ * Action types the CLI maps agent tool calls onto.
+ *
+ * Deliberately **not** a closed schema. `DashboardSyncAction.actionType` stays
+ * an open string so a tool the CLI has never seen still syncs as itself
+ * (`packages/cli/src/action-queue.ts` normalizes an unknown tool name rather
+ * than collapsing it into a catch-all) — a closed picklist would silently drop
+ * those. This list is the *known* vocabulary: what the CLI produces on purpose.
+ *
+ * It lives here because it is a contract between two packages that never import
+ * each other. It used to also be the vocabulary the guide-trigger picker
+ * offered; that picker is gone (docs/plans/run-level-grading-plan.md, Slice 4)
+ * and nothing matches against this list any more — relevance is observed from
+ * what was in the agent's context, not asserted against an action type.
+ *
+ * `SKILL_LOAD_ACTION_TYPE` is the one type the CLI emits on purpose that is
+ * deliberately absent here; see its own comment for why.
+ */
+const KNOWN_ACTION_TYPES = [
+    'file_edit',
+    'file_read',
+    'shell_command',
+    'search',
+    'web_access',
+];
+/** True when `value` is one of the action types the CLI produces on purpose. */
+export function isKnownActionType(value) {
+    return KNOWN_ACTION_TYPES.includes(value);
+}
+// No run-eval result schema here. It was the contract for the CLI's on-device
+// grader, which is gone (docs/plans/cli-local-grading-removal-plan.md). The
+// only grader left runs on the server and owns its own output contract in
+// `apps/dashboard/src/lib/eval/runGradeSchema.ts` — one shape of that fact, not
+// two packages holding copies that a comment has to keep in step.
+// ---------------------------------------------------------------------------
+// Parse wrappers (throw ValiError on invalid input)
+// ---------------------------------------------------------------------------
+export function parseAgentConfig(data) {
+    return v.parse(AgentConfigSchema, data);
+}
+export function parseGuideSnapshot(data) {
+    return v.parse(GuideSnapshotSchema, data);
+}
+export function parseGuideBundleResponse(data) {
+    return v.parse(GuideBundleResponseSchema, data);
+}
+export function parseRawGuideFilePayload(data) {
+    return v.parse(RawGuideFilePayloadSchema, data);
+}
+export function parseGuideMemberFilesResponse(data) {
+    return v.parse(GuideMemberFilesResponseSchema, data);
+}
+export function parseRawGuideFileDeletion(data) {
+    return v.parse(RawGuideFileDeletionSchema, data);
+}
+export function parseRuleDeletionsRequest(data) {
+    return v.parse(RuleDeletionsRequestSchema, data);
+}
+export function parseRulesImportRequest(data) {
+    return v.parse(RulesImportRequestSchema, data);
+}
+export function parseBundle(data) {
+    return v.parse(BundleSchema, data);
+}
+export function parseBundleListResponse(data) {
+    return v.parse(BundleListResponseSchema, data);
+}
+export function parseCreateBundleRequest(data) {
+    return v.parse(CreateBundleRequestSchema, data);
+}
+export function parseCreateBundleResponse(data) {
+    return v.parse(CreateBundleResponseSchema, data);
+}
+export function parseAttachBundleMemberRequest(data) {
+    return v.parse(AttachBundleMemberRequestSchema, data);
+}
+export function parseAttachBundleMemberResponse(data) {
+    return v.parse(AttachBundleMemberResponseSchema, data);
+}
+export function parseDetachBundleMemberResponse(data) {
+    return v.parse(DetachBundleMemberResponseSchema, data);
+}
+export function parseRenameBundleRequest(data) {
+    return v.parse(RenameBundleRequestSchema, data);
+}
+export function parseRenameBundleResponse(data) {
+    return v.parse(RenameBundleResponseSchema, data);
+}
+export function parseDeleteBundleResponse(data) {
+    return v.parse(DeleteBundleResponseSchema, data);
+}
+export function parseContextItem(data) {
+    return v.parse(ContextItemSchema, data);
+}
+export function parseContextItemsResponse(data) {
+    return v.parse(ContextItemsResponseSchema, data);
+}
+export function parsePushContextRequest(data) {
+    return v.parse(PushContextRequestSchema, data);
+}
+export function parsePushContextResponse(data) {
+    return v.parse(PushContextResponseSchema, data);
+}
+export function parseUpdateContextItemRequest(data) {
+    return v.parse(UpdateContextItemRequestSchema, data);
+}
+export function parseUpdateContextItemResponse(data) {
+    return v.parse(UpdateContextItemResponseSchema, data);
+}
+export function parseUpdateContextItemBody(data) {
+    return v.parse(UpdateContextItemBodySchema, data);
+}
+export function parseContextItemResponse(data) {
+    return v.parse(ContextItemResponseSchema, data);
+}
+export function parseArchiveContextItemResponse(data) {
+    return v.parse(ArchiveContextItemResponseSchema, data);
+}
+export function parseInboxCaptureRequest(data) {
+    return v.parse(InboxCaptureRequestSchema, data);
+}
+export function parseInboxCaptureResponse(data) {
+    return v.parse(InboxCaptureResponseSchema, data);
+}
+export function parseInboxListResponse(data) {
+    return v.parse(InboxListResponseSchema, data);
+}
+export function parseContextItemVersionsResponse(data) {
+    return v.parse(ContextItemVersionsResponseSchema, data);
+}
+export function parseContextItemVersionResponse(data) {
+    return v.parse(ContextItemVersionResponseSchema, data);
+}
+export function parseInboxArchiveRequest(data) {
+    return v.parse(InboxArchiveRequestSchema, data);
+}
+export function parseInboxArchiveResponse(data) {
+    return v.parse(InboxArchiveResponseSchema, data);
+}
+export function parseDashboardSyncRequest(data) {
+    return v.parse(DashboardSyncRequestSchema, data);
+}
+export function parseProposalCitation(data) {
+    return v.parse(ProposalCitationSchema, data);
+}
+export function parseExtractedGuideSuggestion(data) {
+    return v.parse(ExtractedGuideSuggestionSchema, data);
+}
+export function parseExtractedSkillSuggestion(data) {
+    return v.parse(ExtractedSkillSuggestionSchema, data);
+}
+export function parseExtractedFeedbackBatch(data) {
+    return v.parse(ExtractedFeedbackBatchSchema, data);
+}
+export function parseActionEntry(data) {
+    return v.parse(ActionEntrySchema, data);
+}
+//# sourceMappingURL=schemas.js.map