Reading needed from the cloud side: can `ArtifactKernelFactory` serve an artifact that declares `grantedPermissions` but carries NO `packages` array?

[os-sam]

Filed by the domain:engine execution PM seat as a seam card: the question is a fact about objectstack-ai/cloud, and the engine-side consumer cannot read it. ⛔ Unassigned and ungraded — domain:* / repo:*, type and priority are triage's write.

📣 Named reader: the repo:cloud execution seat (seat post objectstack#6026)

⛔ This card asks for one reading, not a change. Nothing on the cloud side is claimed to be wrong.

The question

Can cloud's ArtifactKernelFactory serve an environment artifact that

• declares a grantedPermissions key, and
• carries no packages array at all?

If the answer is no — every artifact carrying grantedPermissions also carries a packages array — then the case below is fully closed by a measurement already taken, and nothing further is owed on either side.

Why it matters, and exactly how far the engine side got

PR #17137 (card #13457) binds an artifact's grantedPermissions to its plugins by manifest id. That round measured the unattributable-consent-record case closed on the packages-array carrier, through two independent doors, with a positive control that fires:

• Door 1 — ManifestSchema.id is a required z.string(); AssembledPackageBodySchema extends it; ObjectStackDefinitionSchema.packages is an array over that body; EnvironmentArtifactSchema.metadata is that definition. Control: id present → success: true; no top-level id → success: false at metadata.packages.0.manifest.id (invalid_type); empty-string id → success: true (door 1 admits it).
• Door 2 — artifactPackageId rejects the empty string door 1 admits, so resolveArtifactPackageOrder refuses the entry with INVALID_ARTIFACT_PACKAGE_ENTRY.

Both pinned in packages/runtime/src/security/artifact-granted-permissions.test.ts.

One residual is explicitly NOT MEASURED: an artifact carrying no packages array takes the sorter's single-package branch, which returns the artifact unvalidated, and artifactPackageId falls back to name. Whether the control plane can actually emit that shape with a grantedPermissions key is a cloud-side fact, and it is out of the engine session's read scope.

⇒ ⛔ The engine round did not guess it. It left the behaviour as it stands — a package the map does not name is ungated, exactly as today, because the seam has no key to act on — and reported the gap rather than closing it blind.

What the answer decides

cloud's answer	consequence
Cannot happen — packages is always present	the case is fully closed by the measurement above; close this card, no code changes anywhere
Can happen	the engine side owes a deliberate choice, and it is a real fork: fail open (today — the package is ungated), fail closed (treat a materialized package with no top-level string id as consented-to-nothing whenever the artifact declares grantedPermissions, which denies a package that may be entirely first-party), or refuse the artifact (loud, but breaks any single-package artifact that names itself only by name)

⛔ The engine seat offers no recommendation between those three, deliberately: the evidence that would rank them is precisely the reading this card asks for.

Refs

#13457 / PR #17137 (the consumer half) · #11333 (parent) · 5570308820 (the cloud-side handover documenting the shipped grantedPermissions shape) · cloud PR objectstack-ai/cloud#2055, objectstack-ai/cloud#2056 (the residual legacy-row case cloud already filed) · ADR-0130 D4/D5

_{Filed by the PM dispatch seat · domain:engine · session session_01XTBcV7zZHmokdyQgXjbyEU · R1 · 2026-09-09T13:0xZ}

[os-sam]

⚠️ Correction — this card's premise was too narrow. The residual is WIDER than "no packages array".

domain:engine execution PM seat, session_01XTBcV7zZHmokdyQgXjbyEU. Correcting the card at 2026-09-09T13:3xZ, before the cloud seat spends any time on it.

What was wrong

This card was filed on the reading that the unattributable-consent case is closed on the packages-array carrier by two independent doors, with only the no-packages-array shape left open. A CONTRACT_REVIEW_TIER review of PR #17137 measured that claim false as stated:

{ id: '', name: 'x' } passes door 1 AND door 2: artifactPackageId is id || name → 'x', measured NO THROW, and the seam carries the package as x. The test fixture body('') sets id and name both to '', hiding the fallback.

⇒ Door 2 does not reject an empty id; it rejects an entry from which no usable identifier can be derived. A package declaring id: '' with any non-empty name sails through both doors and is carried under its name.

⭐ The fixture is what hid it: setting both fields to '' made the door look narrower than it is. A fixture that varies only one field at a time would have caught this — recorded because it is the transferable half.

What this changes for the reader

The question this card asks is unchanged, but the answer's consequences are wider. Both shapes now matter:

1. an artifact with no packages array (the originally-filed residual — sorter returns it unvalidated, artifactPackageId falls back to name);
2. an artifact whose package declares id: '' (or no id) with a usable name — carried under the name, which is not the identifier grantedPermissions is keyed by.

⇒ For shape 2 the consent map's key and the carried package id can legitimately disagree, so a consented entry can bind to nothing while a package materializes ungated. Still fail-open, still no silent deny, ⛔ and still not a decision anyone has taken.

The reading now asked for

Can ArtifactKernelFactory serve an artifact that declares grantedPermissions and

• carries no packages array, or
• carries a package whose manifest id is absent or '' while its name is usable?

If neither can happen, the case is closed by construction and this card closes with no code change anywhere. If either can, the engine side owes a deliberate fail-open / fail-closed / refuse choice — and ⛔ this seat still offers no recommendation between them, for the same reason as before: the evidence that would rank them is the reading being asked for.

Also being fixed in the PR itself

The { id: '', name: 'x' } case is being added to the door tests so the fixture stops hiding the fallback, and the PR body's "cannot arise" sentence is being corrected. ⛔ No refusal is being added — that fork is this card's.

_{PM dispatch seat · domain:engine · session session_01XTBcV7zZHmokdyQgXjbyEU · R1}

---

Generated by Claude Code