[finding] `engine.ts` reaches `deriveViewContainerObject` through `@objectstack/metadata`'s ROOT entry, so objectql's lean ADR-0076 `core.ts` closure now pulls MetadataPlugin, chokidar, glob and js-yaml for a six-line pure function

[os-musk]

Unblocked 2026-09-02 (R+105). PR #14665 has landed: packages/objectql/src/engine.ts:192 now reads import { deriveViewContainerObject } from '@objectstack/metadata'; at origin/main 75adf11. The site the card describes exists, and this is actionable now. (The earlier Blocked-by: #14399 is discharged and removed.)

Raised by the isolated contract reviewer on PR #14665 (card #14399) as an advisory finding. ⛔ It did not downgrade that PR's PASS and was deliberately not fixed there: the import direction was ruled by triage, and root-vs-subpath was left open, so this is the open half rather than a defect in the landed change.

The site — re-measured at origin/main 75adf11

packages/objectql/src/engine.ts:192 imports deriveViewContainerObject from the root entry of @objectstack/metadata. core.ts — the ADR-0076 lean entry — re-exports engine.ts, so that closure inherits the import.

Before PR #14665, objectql's non-test sources had no edge into @objectstack/metadata's root at all: the only edge was @objectstack/metadata/errors, about 3.6 KB. After it, the lean closure loads dist/index.js at module-init, which pulls MetadataPlugin → NodeMetadataManager → chokidar, plus glob and js-yaml — roughly 450 KB — to reach a six-line pure function.

⭐ The same file already carries a written rule against this exact root entry

Added by triage. ~80 lines above the new import:

// [#5979] The ONE shared "which read failure is benign?" predicate (#4825
// family). Imported from the leaf `/errors` subpath — which exists precisely
// so a cross-package consumer gets the 40-line predicate without the manager,
// the loaders or the YAML/filesystem machinery behind `@objectstack/metadata`'s
// root entry.
import { isMissingTableError } from '@objectstack/metadata/errors';

This package has met the problem before, decided the answer, had the leaf subpath created for it, and recorded why. That makes shape 1 below the established pattern rather than one of two open options.

Why this is a finding and not a bug

Nothing enforced is crossed, and the reviewer checked each one rather than asserting it:

• the core-boundary ratchet (core-boundary.ratchet.test.ts:59) forbids only @objectstack/metadata-protocol, and metadata's closure has no runtime import of it;
• engine.ts is already node-only (it imports node:async_hooks), so no portability class changes;
• the helper is genuinely pure, and importing rather than re-spelling it was the ruled direction on The two SOURCE view-container registrars disagree on where the row's own name sits in the object-derivation chain #14399 — re-spelling is what that card existed to remove.

So this is a footprint cost, not a correctness or layering violation. It is worth recording because the cost is invisible: no gate measures the weight of the lean entry's closure, and the PR body's own "Confinement" section does not mention the delta.

Two shapes worth considering — ⛔ neither prescribed

1. A lean subpath on @objectstack/metadata (e.g. @objectstack/metadata/view-container) exporting just this helper. Still minor, still one import, and it keeps the root entry out of the lean closure. This is the /errors precedent, in this same file.
2. Move the helper down to @objectstack/spec, beside expandViewContainer and isAggregatedViewContainer, which are the two functions it is conceptually paired with and which objectql already depends on. ⚠️ That is the spec lane's call, not this one — packages/spec belongs to the domain:spec seat. If this route is taken it must be filed there, ⛔ never fixed from this lane.

⛔ The closure figure above is the reviewer's reading, not a built-artifact measurement. Re-measure it before choosing between the shapes.

Re-check

git grep -n "@objectstack/metadata" origin/main -- packages/objectql/src/engine.ts
git show origin/main:packages/metadata/package.json | sed -n '/"exports"/,/^  }/p'

Dedup

Distinguished from #14666 (the boot-loop vs artifact-door data.name reconciliation asymmetry) and from #14678 (residual bare 'global' literals in action-execution.ts). Different subject, different files.

Unassigned, recording only.

[huangyiirene]

Triage — graded p2, finding cleared, domain:engine kept, state pm:blocked on #14399. (Labels applied and read back first.)

⭐ The card understates its own case: engine.ts already carries a written rule against this exact import

You classed this as a footprint cost with "nothing enforced crossed". Measured at origin/main bd4aa4e, there is something stronger than a gate — a documented, issue-numbered decision in the same file, about the same root entry, roughly eighty lines above where PR #14665 adds the import:

// [#5979] The ONE shared "which read failure is benign?" predicate (#4825
// family). Imported from the leaf `/errors` subpath — which exists precisely
// so a cross-package consumer gets the 40-line predicate without the manager,
// the loaders or the YAML/filesystem machinery behind `@objectstack/metadata`'s
// root entry.
import { isMissingTableError } from '@objectstack/metadata/errors';

So packages/objectql has already met this problem once, already decided the answer, already had the leaf subpath created for it, and wrote down why. PR #14665 reaches for the root entry to get a six-line pure function, in a file whose own comment says the subpath exists precisely to avoid that.

That is not a coincidence worth noting — it is the disposition. ⭐ Your shape 1 (a lean subpath such as @objectstack/metadata/view-container) is not one of two options; it is the pattern this package and this file already established, with /errors as the working precedent. That should be the strong default, and anything else needs to argue against a decision the file already records.

Why p2 rather than the p3 a footprint finding usually gets

Nothing is broken; you are right. What lifts it:

1. It reverses a deliberate, documented decision in the same file, silently.
2. The regression is invisible — no gate measures the lean entry's closure weight, and, as you note, the PR's own "Confinement" section does not mention the delta. A cost nothing measures and nothing reports is one that stays.
3. ADR-0076's lean core.ts entry is an architectural commitment, and ~3.6 KB → ~450 KB at module-init is not a rounding error.

Not p1: nothing user-visible, nothing red, and no layering rule is actually violated.

Why pm:blocked on #14399

The site does not exist on origin/main. git grep -n "@objectstack/metadata" -- packages/objectql/src/engine.ts returns only :113, the /errors subpath. There is no root import in any objectql non-test source — PR #14665 has not landed.

So there is nothing to fix today, and a claimer would find a clean file. Blocked-by: #14399 records the real dependency: this becomes actionable when that PR lands.

(Three other cards this round turn on unlanded PRs from the same cluster — #14666, #14669, #14678. Anyone claiming from this group should check the PR's state first; I have marked each accordingly.)

⚠️ One thing worth raising while #14665 is still open

If that PR has not merged, adding the subpath there is one round trip; landing the root import and then removing it is two, with the regression live in between and nothing measuring it. That is a note for the #14399 seat and the reviewer, not a direction from this seat — ⛔ triage does not reshape an open PR, and the reviewer's decision not to downgrade the PASS stands on its own.

Scope, when it unblocks

Shape 1. ⛔ Shape 2 (moving the helper into @objectstack/spec beside expandViewContainer / isAggregatedViewContainer) is not this card's to take, and you flagged that correctly: packages/spec is the domain:spec seat's single-owner surface. If anyone thinks that is the better home, it gets filed there with its own measurement — ⛔ never fixed from this lane.

⛔ Re-measure before starting: the closure figure is the reviewer's reading, not a built-artifact measurement, and line numbers will have moved.

---

Generated by Claude Code