[objectstack-fleet]

Fixes #24336
Clause-②: no

What changed

MetadataEventSchema.source in @objectstack/metadata-core described itself as Origin label: "fs", "studio", "rest", "ai", "git-import", …. No producer on this tree writes studio, rest, ai or git-import, so a reader of the published schema was pointed at values it will never see. The describe now says what the field is: the write path that produced the event, an open label its writer stamps, not an enum of authoring surfaces to pick from or match against. Its examples are labels real producers stamp: protocol.saveMetaItem, protocol.publishMetaItem, migrate-stored, sys-metadata-repo (SysMetadataRepository's default) and fs (FileSystemRepository). The field stays z.string().

The two sys-metadata-history.object.ts comments (the module header and the comment above source) now agree with the describe. They list the labels that actually reach the sys_metadata_history.source column, and they no longer list fs: FileSystemRepository writes its events to its own JSONL change log, never to this table.

No key, type, export, accepted value or emitted value changes. One patch changeset on @objectstack/metadata-core (.changeset/24336-metadata-event-source-describe.md, carrying Clause-②: no).

Producers measured on origin/main bfc1539fe0 (non-test code)

producer	label(s) written	reaches
SysMetadataRepository (packages/metadata-protocol/src/sys-metadata-repository.ts)	the caller's opts.source, else sys-metadata-repo (put / delete), sys-metadata-repo.publish (promoteDraft and the promoted draft-row drop), sys-metadata-repo.revert (restoreVersion); history() passes the stored value through and answers sys-metadata-repo for a row that stored none	sys_metadata_history, MetadataEvent
the protocol (packages/metadata-protocol/src/protocol.ts)	protocol.saveMetaItem, protocol.publishMetaItem, protocol.deleteMetaItem, protocol.rollbackMetaItem, protocol.revertCommit	via SysMetadataRepository
stored-row rewrites	migrate-stored (the protocol's migrateStoredMetadata, and service-automation's flow-credential-migration.ts)	via saveMetaItem
CLI os migrate security-catalog-overlays	os migrate security-catalog-overlays	via SysMetadataRepository.delete
@objectstack/metadata DatabaseLoader (database-loader.ts)	database-loader	sys_metadata_history directly
@objectstack/metadata-fs FileSystemRepository	fs	its own JSONL change log and events, not the table
InMemoryRepository (metadata-core)	in-memory	events; no non-test instantiation
LayeredRepository (metadata-core)	the layer label prefixed to the inner label (LAYER:SOURCE)	events; no non-test instantiation

The card's list missed DatabaseLoader, the three further protocol labels, the CLI migration and the two metadata-core repositories; none of them writes studio, rest, ai or git-import either. No consumer compares source against a fixed value.

Generated artifacts: nothing reads this describe. A repo-wide search for Origin label and git-import finds only the source line, the governed ADR sketch below and two changelog/changeset entries of the earlier spec-half fix. metadata-core is not packages/spec, so check:generated does not cover it and nothing was regenerated.

File surface

• packages/metadata-core/src/types.ts: MetadataEventSchema.source's .describe() only.
• packages/metadata-core/src/objects/sys-metadata-history.object.ts: the module header bullet and the comment above source.
• .changeset/24336-metadata-event-source-describe.md.

Verification (head 197216c57f)

• pnpm --filter '@objectstack/metadata-core...' build (metadata-core and its dependency closure): exit 0. The built dist/index.js and dist/index.cjs each carry the new describe once and git-import zero times.
• pnpm --filter @objectstack/metadata-core test: 18 files, 774 tests passed. pnpm --filter @objectstack/metadata-core typecheck (tsc --noEmit && tsc --noEmit -p tsconfig.test.json): exit 0.
• Derived gate list (node scripts/pm/dispatch-gates.mjs --commands, from the real diff): 57 commands, every one run with its exit code captured before any pipe. 56 exited 0. pnpm check:lean-entry-closure first answered PREREQUISITE NOT MET (exit 3) and exited 0 after building @objectstack/objectql's closure.
• NOT MEASURED: pnpm check:dual-build-cjs-loads. It refuses with exit 3 until all of the roughly 90 workspace packages are built, and only a whole-workspace build satisfies it. CI's Lint & Repo Gates runs it. Declared narrowing.
• node scripts/pm/dispatch-gates.mjs --ran: 57 derived families accounted for, 56 run, 1 NOT MEASURED, 0 UNRUN.
• No ablation: the diff changes describe and comment prose only, and no test pins that text.

Acceptance notes

• Rider for domain:spec, not taken here (it is that lane's file): packages/spec/src/api/protocol.test.ts (around lines 2141 to 2162) calls its fixture "a verbatim-shaped capture of a real historyMetaItem return", but the update event carries source: 'studio'. A real save through that door stamps protocol.saveMetaItem.
• For a person, governed (Tier H) and not touched: docs/adr/0008-metadata-repository-and-change-log.md line 226, the section 2.4 sketch, still reads source: string; // 'fs', 'studio', 'rest', 'ai', 'git-import', …. It is illustration only, and correcting it is a maintainer's edit.
• Cloud's writers were not read. The new describe calls the label open, so a cloud write path that stamps its own label still fits the contract.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-core, touching 7 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/protocol/kernel/metadata-service.mdx (via protocol.saveMetaItem (literal, a string literal in a comment in SysMetadataHistoryObject; a string literal in a comment on a changed line))

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 4 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json bfc1539fe00a33bc3215614a8d6c76a05eb8e8aa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from bcf649040a66bc366819b64947189be77b0fc532 — the merge of head 197216c57fc5b4b29eca3133d26b93a820f148b9 into base bfc1539fe00a33bc3215614a8d6c76a05eb8e8aa, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin bcf649040a66bc366819b64947189be77b0fc532 && git checkout bcf649040a66bc366819b64947189be77b0fc532
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin bfc1539fe00a33bc3215614a8d6c76a05eb8e8aa 197216c57fc5b4b29eca3133d26b93a820f148b9 && git checkout -B drift-repro bfc1539fe00a33bc3215614a8d6c76a05eb8e8aa && git merge --no-ff 197216c57fc5b4b29eca3133d26b93a820f148b9

node scripts/docs-audit/affected-docs.mjs --json bfc1539fe00a33bc3215614a8d6c76a05eb8e8aa

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs bfc1539fe00a33bc3215614a8d6c76a05eb8e8aa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

席位核对 · ACCEPT · domain:engine seat 2 · session_01AHeUBbe6S3JRawcpbLejXD · 2026-10-19T22:50Z

Reviewed against GitHub on head 197216c57f, not against the report.

• Form: draft into main. The body's first line is Fixes #24336, and Clause-②: no sits at a line start. A closing-keyword scan of the whole body finds one hit, Fixes #24336.
• Scope: 3 files, +35 / −6: packages/metadata-core/src/types.ts (the source describe), sys-metadata-history.object.ts (two comments) and the changeset. All are inside claim 6278643856's surface. check-governed-merges --pr 24675: not governed. The packages/spec fixture and the ADR-0008 sketch are left untouched and named in Acceptance notes, as dispatched.
• Prose checked against the tree (origin/main bfc1539fe0, non-test src): every label the new text names is stamped by a producer. protocol.saveMetaItem 2, protocol.publishMetaItem 4, protocol.deleteMetaItem 7, protocol.rollbackMetaItem 4, protocol.revertCommit 2, migrate-stored 14, sys-metadata-repo.publish 2, sys-metadata-repo.revert 1, database-loader 1. The control source: 'studio' gives 0, which is the defect the card names.
• The describe stays z.string(): no key, type, export or accepted value moves, so Clause-②: no and a patch on @objectstack/metadata-core are right. The changeset's sentences match the diff, and so does its claim that only fs of the old list is written, by FileSystemRepository.
• The history comments drop 'fs' on purpose: FileSystemRepository writes its own JSONL log, never sys_metadata_history. That is consistent with the describe, which keeps fs, because MetadataEventSchema serves both repositories.
• Gate note: check:dual-build-cjs-loads is NOT MEASURED locally (it needs a whole-workspace build) and is read from CI.
• Landing: held, not yet armed. main's hourly full battery is red and not yet attributed to a lane (see A conditional validation rule's when that reads through a lookup (record.account.status) saves at every door, but checkConditional evaluates it unhydrated, so every write the rule guards is refused as unevaluable #24512, 6278925351), and CI on this head is still converging (10 of 38 in progress, none red).

---

Generated by Claude Code