Skip to content

Commit 62b3ec3

Browse files
docs(metadata-protocol, objectql): docblocks say a code package's objectExtensions are registered as extend contributors, never stored as items (#28874) (#28925)
domain:server#1 · os-project-manager · session_01R1q2xdtYgU6FKrZ7LgjPCC Fixes #28874 Clause-②: no Metadata-protocol: none ## 维护者速读 - **改了什么**:三处注释改为说实话:代码包的 `objectExtensions` 从不存成 `object_extension` 条目,也不进 metadata 服务;ObjectQL 引擎的 `registerApp` 把每条注册为目标对象的 `'extend'` 贡献者。该类型的条目只有 `/api/v1/meta` 写入口存下的行。 - **为什么改**:原注释说制品加载器把它们存成该类型的条目,或作为单独集合存进 metadata 服务,误导读者。措辞与 #28873 的 spec 注册表行注释一致。 - **风险与回滚**:无行为变化,只改注释。回滚即还原本 PR。 - **先看**:`packages/metadata-protocol/src/protocol-object-extension-item.ts` 头部注释。 - **两分钟验证**:`git diff origin/main -- packages/` 只有注释行。 - **需要你做的**:无,席位落地。 ## What changes Comment only, in three docblocks. 1. `packages/metadata-protocol/src/protocol-object-extension-item.ts`, header (the card's site). It said "`object_extension` is the type the artifact loader already stores a code package's `objectExtensions` under". It now says they are never stored as items of this type: `registerApp` registers each one as an `'extend'` contributor, and the artifact loader maps the collection to this type but files no item from it, because an extension carries `extend` and no `name`. This type's items are the rows the `/api/v1/meta` doors write. 2. `packages/metadata-protocol/src/protocol.ts`, the `foldObjectExtendersFromRegistry` docblock (triage's second site). It said an artifact deployment registers `objects` and `objectExtensions` into the metadata service "as SEPARATE collections". It now says only `objects` reach that service, and gives the reason above. 3. **Third site, same drift:** `packages/objectql/src/registry.ts`, the public `SchemaRegistry#foldObjectExtendersOnto` docblock, said the same "stored as SEPARATE collections". Corrected the same way. Read before writing: - `packages/metadata/src/plugin.ts`: `ARTIFACT_FIELD_TO_TYPE` maps `objectExtensions` to `object_extension`, and `artifactItemSlot` returns no slot for a body with no `name`, so each registration loop skips it. - `packages/objectql/src/engine.ts`: the `registerApp` `objectExtensions` loop calls `registerObject(…, 'extend', priority)`. A `git grep` for the drift phrases finds no other site. **Changeset: patch** on `@objectstack/metadata-protocol` and `@objectstack/objectql`. The corrected docblocks ship in each package's `dist` declarations, and AGENTS.md rule 3 gives `none` a patch. ⛔ No `packages/spec/**`, no code change, no new gate. ## Tests <details><summary>Typecheck, lint, gates</summary> No behaviour change, so there is no new test. Head `c1c35ba7`, after a whole-repo `pnpm build` (exit 0): - `pnpm typecheck` in full: metadata-protocol exit 0, objectql exit 0 (test-typecheck ledger unchanged); - `eslint --no-inline-config src`: exit 0 for both packages; - `dispatch-gates.mjs --commands` derived 57 (including `check:dts-closure`, `check-dts-emitted`, the comment-mask and drift-comment gates), all run, every exit 0. `--ran`: 57 derived, 57 run, 0 NOT-MEASURED. </details> 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01FEkQ5oTRCUNQ4EA3YV84sZ Co-authored-by: Claude <noreply@anthropic.com>
1 parent ff88105 commit 62b3ec3

4 files changed

Lines changed: 34 additions & 13 deletions

File tree

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
---
2+
'@objectstack/metadata-protocol': patch
3+
'@objectstack/objectql': patch
4+
---
5+
6+
docs(metadata-protocol, objectql): three docblocks say where a code package's `objectExtensions` go: never stored as `object_extension` items or into the metadata service, but registered by the engine's `registerApp` as `'extend'` contributors (#28874)
7+
8+
Clause-②: no
9+
Metadata-protocol: none
10+
11+
Comment only, with no behaviour change. The header of `protocol-object-extension-item.ts`, the `foldObjectExtendersFromRegistry` docblock in `protocol.ts` and the `SchemaRegistry#foldObjectExtendersOnto` docblock each said that a compiled artifact's `objectExtensions` are stored (as `object_extension` items, or as a separate collection of the metadata service). They are not. The ObjectQL engine's `registerApp` registers each one as an `'extend'` contributor of its target object. The artifact loader maps the collection to `object_extension` but files no item from it, because an extension carries `extend` and no `name`. The type's items are the stored rows the `/api/v1/meta` doors write. The wording matches the `@objectstack/spec` registry row comment (#28873). A patch changeset is used because the corrected docblocks ship in each package's `dist` declarations.

‎packages/metadata-protocol/src/protocol-object-extension-item.ts‎

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -4,11 +4,14 @@
44
* [#28574, ADR-0146 D10 / D2 / D3] An object extension is an authorable item
55
* of a writable package.
66
*
7-
* `object_extension` is the type the artifact loader already stores a code
8-
* package's `objectExtensions` under; since #28574 it is also a row a running
9-
* deployment writes. Studio's add-field on a base object (N-23c) writes
10-
* exactly this: an extension in the base's paired `.custom`, its fields
11-
* suffixed `__c`, the base untouched. The row is stored under the writing
7+
* A code package's `objectExtensions` are never stored as items of this type:
8+
* the ObjectQL engine's `registerApp` registers each one as an `'extend'`
9+
* contributor of its target object. The artifact loader maps that collection
10+
* to this type name but files no item from it, because an extension carries
11+
* `extend` and no `name`. This type's items are the stored rows the
12+
* `/api/v1/meta` doors write (#28574). Studio's add-field on a base object
13+
* (N-23c) writes exactly this: an extension in the base's paired `.custom`,
14+
* its fields suffixed `__c`, the base untouched. The row is stored under the writing
1215
* package with the TARGET object's name as its row name — one extension per
1316
* package per target — and its body is `ObjectExtensionSchema` as it stands:
1417
* it carries `extend` and no `name`.

‎packages/metadata-protocol/src/protocol.ts‎

Lines changed: 7 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -9350,10 +9350,13 @@ export class ObjectStackProtocolImplementation implements
93509350
* object's resolved schema is DEFINED (ADR-0029 D9.2 / D9.6) as a base layer
93519351
* with its `extend` contributors folded on, and the MetadataService copy is
93529352
* only the base layer. A deployment that ingests a compiled artifact
9353-
* (`artifactSource`, i.e. every sealed/served runtime) registers `objects`
9354-
* and `objectExtensions` into that service as SEPARATE collections, so the
9355-
* body this method receives is the owner's declaration with no extender in
9356-
* it. Serving it unfolded is what made the showcase's three
9353+
* (`artifactSource`, i.e. every sealed/served runtime) registers its
9354+
* `objects` into that service, and its `objectExtensions` never reach it as
9355+
* items: the ObjectQL engine's `registerApp` registers each one as an
9356+
* `'extend'` contributor of its target object, and the artifact loader files
9357+
* no item from that collection, because an extension carries `extend` and no
9358+
* `name`. So the body this method receives is the owner's declaration with
9359+
* no extender in it. Serving it unfolded is what made the showcase's three
93579360
* `objectExtensions` fields readable through `GET /meta/object`, writable
93589361
* through the data API, and absent from `GET /meta/object/:name` — the read
93599362
* the edit and new forms derive from.

‎packages/objectql/src/registry.ts‎

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -5326,10 +5326,14 @@ export class SchemaRegistry {
53265326
* Why this is public API rather than the protocol reaching for the
53275327
* contributor list: `GET /meta/object/:name` reaches an object body through a
53285328
* source this registry never sees — the copy `MetadataPlugin` registers into
5329-
* the `metadata` SERVICE when a deployment ingests a compiled artifact, where
5330-
* `objects` and `objectExtensions` are stored as SEPARATE collections. That
5331-
* body is ONE LAYER, and serving a layer as the resolved schema is what
5332-
* dropped every `objectExtensions` field from the by-name read (and from both
5329+
* the `metadata` SERVICE when a deployment ingests a compiled artifact. That
5330+
* service holds the owner's declaration only: a code package's
5331+
* `objectExtensions` are never stored there as items, because the ObjectQL
5332+
* engine's `registerApp` registers each one as an `'extend'` contributor
5333+
* here, and `MetadataPlugin` files no item from that collection (an
5334+
* extension carries `extend` and no `name`). That body is ONE LAYER, and
5335+
* serving a layer as the resolved schema is what dropped every
5336+
* `objectExtensions` field from the by-name read (and from both
53335337
* layers of `?layers=true`) while `GET /meta/object` — which reads
53345338
* `resolveObject` — kept them. Two folds would re-open exactly that seam one
53355339
* level down, so there is one.

0 commit comments

Comments
 (0)