[repo:cloud] The plugin artifact contract carries granted_permissions — ruled producer half of #11333 Phase 1

[os-sam]

Seam card (target repo unreachable from the filing seat — falls to objectstack per the cross-repo rule, repo:cloud + named reader). Named reader: the cloud lane seat — this card is its dispatch input; the objectstack consumer half (#13457) is pm:blocked on this card.

⚠️ The Blocked-by: #14865 line has been REMOVED — that blocker is discharged. #14865 closed 2026-09-03 via merged PR #14992, and cloud's pin e581457baaaf carries it: packages/spec/src/system/environment-artifact.zod.ts:173 declares grantedPermissions: z.record(z.string(), PluginPermissionsSchema).optional(). The line is removed rather than struck through because it is a machine-grepped reverse index and a stale entry pollutes it. Unlock reading recorded in the 2026-09-07 comment below.

The ruling this executes

Maintainer, 2026-09-01, PM chat channel, director decision batch A, verbatim 「同意。」 on the presented recommendation for #13457:

裁「grant 由 artifact 契约承载」⇒ #11333 Phase 1 重切为 cloud 先行 + objectstack 消费卡 Blocked-by 排后；materialize 缝归 ADR-0025 设计。

Architecture direction, as presented and adopted: the granted-permissions set rides the plugin artifact contract. cloud (the owner of the install-consent flow) compiles the consented structured set {services, hooks, network, fs} into the artifact/manifest carrier it produces; objectstack's loader later consumes it from the environment-local carrier at materialize time. This follows ADR-0003 (revised by cloud ADR-0007): sys_package_installation is control-plane desired state, never read on any runtime path — runtime truth lives with the environment's own carrier.

First deliverable is a measurement, not code

Does the artifact cloud compiles today already carry the granted set?

⇒ Measured by the repo:cloud seat on 2026-09-07: NO. grantedPermissions appears in packages/service-cloud/src/ only in two forward-looking comments (cloud-artifact-helpers.ts:679, routes/cloud.ts:752, both saying it "is next"). Positive control: granted_permissions is written in routes/package-install.ts. ⇒ The second branch applies — add the field to the envelope and write it at consent-compile time. ⛔ Re-verify this on the dispatch head rather than inheriting it; the file has moved twice since.

Contract-first: the field's shape is the four-class structured set the consent flow already parses (plugin-consent.ts's own header states the intent verbatim: "the environment runtime later feeds it to the framework's PluginPermissionEnforcer (F4) to gate the plugin at load time").

Boundaries

• ⛔ The objectstack materialize seam (per-plugin context construction, SecurePluginContext wiring) is NOT this card — it belongs to the ADR-0025 install-flow design work and to Phase 1 of #11333: wire granted_permissions into PluginPermissionEnforcer (F4) as the load-time gate #13457 once this lands.
• Clause-② discipline applies on the cloud side per its own lane rules (a new contract field is a public-surface widening there).

Refs: #11333 (parent ruling, option A 2026-08-30 「同意」) · #13457 (consumer half, blocked on this) · #13458 (Phase 2, blocked behind #13457) · #14865 (the spec half, landed and pinned) · ADR-0003 / cloud ADR-0007 · ADR-0025.

Filed by the director seat, session session_015adLit3ZYASJiXwxKG78Wi.

[os-sam]

本评论来自分诊座位(R+84,pm:blocking 推导施加)。⛔ 不认领、不派发、不写码、不合并。

施加 pm:blocking —— 来自索引推导,⛔ 非手工判断

R+83 巡检 H14-A 行:

H14 #14034 targeted by 1 open card(s)' Blocked-by: line, body or comment (#13457), but NOT carrying pm:blocking

前置条件已核:#13457 open,本卡 open 且此前无 pm:blocking。依 SKILL.md:100,施加即分诊 sweep 的推导步(巡检 report-only)。

⚠️ 本卡带 repo:cloud(seam 卡)—— 方向 A 在仓盲下是安全的

按 #13975 的判定:

方向	仓盲下的风险
A(添加)	✅ 安全 —— 漏掉一条跨仓边只会造成欠标注,那就是现状
B(移除)	⛔ 不安全 —— 「本仓无人指向我」不等于「无人在等」

⇒ 本次是方向 A,且触发它的边(#13457)就在本仓内,不依赖任何跨仓读取。⇒ 施加成立。

⛔ 反向提醒:本卡带 repo:cloud ⇒ H14 的移除方向对它冻结(本会话新边界:任何点名兄弟仓 issue 的卡,不论是否带 repo:*,冻结至 #13992 结案)。

---

Generated by Claude Code

[baozhoutao]

Claim: PM loop round R35 (wave 4) — measurement phase only; the code phase, if any, is a separate dispatch at CONTRACT_REVIEW_TIER
Session: session_017Wu48ZSjk7HJjyJmGNBtUk
Branch: claude/issue-14034-artifact-granted-permissions (in objectstack-ai/cloud; created only if the measurement yields a lock-the-field change that is doc/schema-comment-only; ⛔ no contract-widening code lands from this dispatch)
Worktree: cloud-issue-14034
Domain: repo:cloud (whole-repo seat, seat post #6026 — the named reader)
File surface: read-only across the install-consent flow (plugin-consent.ts and neighbours), the artifact/manifest compiler the control plane produces at consent time, and the .osplugin / package-installation carrier (packages/service-cloud/**, packages/objectos-runtime/**, packages/security-enterprise/** as found) — stop on breach; explain in the report
Container & model: M measurement, mode:subagent, model: opus for the reading; model: fable (CONTRACT_REVIEW_TIER) for any change that adds or locks a contract field — per the card's own boundary ("Clause-② discipline applies on the cloud side … a new contract field is a public-surface widening")
Clause-②: yes — the deliverable this card ultimately asks for widens the artifact contract's public face; declared now so the入队 gate binds whichever phase lands code
Serial constraints cleared: no in-flight claim touches the consent flow or the artifact compiler; cloud#1452's cloud half (composed-shape agents, PR #1471) is merged; objectstack#13457 (the consumer half) is pm:blocked on this card by design. Fold-or-serial: none.

---

Generated by Claude Code

[claude]

Dev claim (os-dev subagent, dispatched by the repo:cloud PM seat, round R35) — measurement phase only.

• Session: session_017Wu48ZSjk7HJjyJmGNBtUk
• Worktree: /home/user/cloud-issue-14034, detached at objectstack-ai/cloud origin/main = 2f46923 (git worktree add --detach). No branch, no install, no build — the dispatch is source-reading + REST only.
• Framework pin read at .objectstack-sha = 655b106ce2804d2cdb9ed4386df795152535d372, read via git show/git grep against that commit in the shared objectstack checkout (never switched).
• Scope: answer the card's first deliverable (does the artifact cloud compiles today already carry the granted set) with evidence, and produce the contract-field proposal the code phase would land. No contract field, schema or wire shape is added or changed from this dispatch — that is Clause-② and lands only from a separate CONTRACT_REVIEW_TIER dispatch.

Reading follows in the next comment.

---

Generated by Claude Code

[claude]

Measurement — does the artifact cloud compiles today carry the granted permission set?

Answer: NO. Every carrier on the runtime path is measured below; the granted set stops at the control-plane row.

Refs. cloud main @ 2f4692339566c5df91afe8b1977daeb19119f2e4 (detached worktree, read-only) · framework pin .objectstack-sha = 655b106ce2804d2cdb9ed4386df795152535d372 (read with git show / git grep against that commit; the shared checkout was never switched) · no install, no build.

---

1. The consent flow — what holds the consented set, and where it lands

The four-class parse and the widening rule are pure helpers in packages/service-cloud/src/plugin-consent.ts:

• StructuredPermissions = { services?, hooks?, network?, fs? } — :24-29; PERMISSION_KEYS :31.
• parsePermissions(raw) — :39-62. Coerces the DB text column / JSON / parsed object into that shape, keeping only the four known keys.
• permissionsWiden(granted, next) — :70-83. The ADR §3.8 re-consent condition.
• serializeGrantedPermissions(perms) — :90-95. undefined for a null set "so the column is left empty for pure-metadata packages".

The file header states the wiring intent verbatim (:6-11): cloud persists the consented set onto sys_package_installation.granted_permissions; "the environment runtime later feeds it to the framework's PluginPermissionEnforcer (F4) to gate the plugin at load time".

Where it is persisted — one place, the control-plane row. Two write sites, both onto sys_package_installation:

Site	Line	What
marketplace install / upgrade	routes/package-install.ts:640-652	declaredPerms = parsePermissions(version.permissions); consentBearing = artifact_kind === 'plugin' OR declaredPerms !== null; 409 on widening without reconsent (:644-649); pluginInstallFields = { granted_permissions: JSON.stringify(declaredPerms ?? {}), is_preview }
written to the row	routes/package-install.ts:667 (update) / :678 (create)	spread of pluginInstallFields
SDK arm (projects/PROJECT/packages)	routes/environment-crud.ts:1607-1609, 1641	same helpers; granted_permissions: serializeGrantedPermissions(declaredPerms2) ?? null

Column declaration: packages/service-tenant/src/objects/sys-package-installation.object.ts:158-167 — Field.textarea, description names the F4 hand-off. The REQUESTED set lives one level up on sys_package_version.permissions (sys-package-version.object.ts:286-294), written by the publish path (plugin-artifact.ts:181).

⭐ Note the distinction the row already carries and any carrier must preserve: absent (not consent-bearing — a pure-metadata package) versus {} (consent-bearing, consented to nothing). package-install.ts:651-653 writes the key only under consentBearing.

---

2. Per-carrier verdict, with producing and consuming lines

#	Carrier	Carries the granted set?	Evidence
1	sys_package_installation.granted_permissions (control plane row)	YES — but this is desired state, ADR-0003 / cloud ADR-0007 forbid reading it on any runtime path	write routes/package-install.ts:652/667/678, routes/environment-crud.ts:1641; decl sys-package-installation.object.ts:158-167
2	sys_package_version.permissions (published manifest)	NO — this is the REQUESTED set, not the granted one	plugin-artifact.ts:41,181; decl sys-package-version.object.ts:286-294
3	Compiled environment artifact — GET /cloud/environments/:id/artifact	NO	envelope literal routes/cloud.ts:747-757 = schemaVersion, environmentId, commitId, checksum, metadata, functions, manifest, builtAt, builtWith, runtime. ⭐ The marketplace-install merge loop (:611-680) reads the very install row and consumes exactly three of its columns — inst.enabled :629, inst.package_version_id :630, inst.with_sample_data :668 — and never inst.granted_permissions. What it pushes as a bundle is { metadata: manifest, manifest } from ver.manifest_json (:632-637, 679), i.e. the version's DECLARED manifest, not the installation's grant.
4	Metadata merge into the envelope	NO, and structurally cannot without a declaration	mergeArtifactMetadata ingests only ARRAY-valued keys that are in KNOWN_METADATA_CATEGORIES or PASSTHROUGH_ARTIFACT_KEYS (cloud-artifact-helpers.ts:540-573, the filter at :555-557); a per-install grant map is neither an array nor a member of either set, and the merge concatenates across bundles, which would destroy per-install attribution anyway
5	Environment-local carrier — sys_env_artifact_cache (the ruling's named carrier, ADR-0007 step ③)	NO today; YES for free the moment the envelope carries it	objectos-runtime/src/env-artifact-cache.ts:39-44 (three columns: environment_id, artifact_json, cached_at), :88-102 writeArtifactCache stores JSON.stringify(artifact) verbatim, :73-82 reads it back verbatim. No projection, no schema of its own.
6	.osplugin unpack	does not exist in cloud	plugin-artifact.ts:6-11: "cloud treats the .osplugin as an OPAQUE tar.gz blob … cloud does NOT unpack the tarball (no tar dependency)". Zero unpack / verify sites anywhere in packages/
7	Tenant kernel materialize — ArtifactKernelFactory	NO	the artifact reaches artifact-kernel-factory.ts:473 (fetch) / :476 (cache fallback); the bundle handed to AppPlugin is { ...artifact.metadata, manifest, functions } (:986-990). Zero permission wiring: PluginPermissionEnforcer, SecurePluginContext, enforceServiceAccess return 0 hits in the entire cloud repo.
8	Public route /pub/v1/environments/:id/artifact	NO	routes/public.ts:78+ serves the stored revision blob; it does not even run the marketplace-install merge, so it carries neither grants nor installed packages

⭐ The consumer side of the loop is the sharpest single line. The assembly loop already has inst — the row that holds granted_permissions — open in front of it and reads three other columns off it. This is not "the data is far away"; it is one field read and one envelope key.

---

3. Framework side at the pin 655b106

What the enforcer expects to read, and in what shape.

packages/core/src/security/plugin-permission-enforcer.ts:102-111
  registerGrantedPermissions(pluginName: string, granted: GrantedPermissions | null | undefined): void

with GrantedPermissions imported as PluginPermissions from @objectstack/spec/kernel (:4) — i.e. exactly PluginPermissionsSchema = { services?, hooks?, network?, fs? }, .strict() (packages/spec/src/kernel/manifest.zod.ts:32-44). Its docblock :90-101 says the set "the cloud control plane persists to sys_package_installation.granted_permissions" is registered "when materializing a third-party plugin … independent of whatever the manifest requested".

⇒ The consumer wants a per-plugin keyed map, PLUGIN_ID to PluginPermissions. Whatever cloud emits must preserve that key.

Is there already a manifest field for GRANTED (as opposed to REQUESTED) permissions? NO.

• manifest.zod.ts:290-291 — permissions: ManifestPermissionsSchema.optional(), described as "Required permissions" — the REQUEST, and a union whose legacy string[] arm is the only one with a live local reader (this card's parent, manifest.permissions is live on its LEGACY string[] arm only — the structured PluginPermissionsSchema (services / hooks / network / fs) has zero readers, and new code is told to prefer it #11333).
• Grepping granted across packages/spec/src at the pin returns zero permission-related declarations (hits are invitedBy, granted_by on sharing, API-primitive prose). There is no granted-permissions field anywhere in the spec surface.
• granted_permissions across packages/ at the pin = 3 hits, all prose: the enforcer docstring (plugin-permission-enforcer.ts:94), the liveness-ledger note (packages/spec/liveness/manifest.json:66), the PluginPermissionsSchema docblock (manifest.zod.ts:23).

Is sys_package_installation read on any runtime path? NO — the ADR-0003 invariant holds. Zero production callers survive at the pin: registerGrantedPermissions, new SecurePluginContext(, new PluginPermissionEnforcer(, createPluginPermissionEnforcer return only the definition, the barrel re-export (packages/core/src/security/index.ts:59) and three test files. #13457's git grep reading is re-confirmed at this pin, not merely inherited.

---

4. Controls — every zero above has a firing positive control

Control	Result
Any permission spelling in the artifact-assembly + env-local-carrier + kernel-factory files (routes/cloud.ts, cloud-artifact-helpers.ts, cloud-artifact-api-plugin.ts, env-artifact-cache.ts, artifact-kernel-factory.ts, artifact-api-client.ts)	8 hits, none about plugin grants — ai_seat, systemPermissions, audience_self_registration_permission_set, and permissionSets as a metadata-category name. The instrument reaches those files and finds permission-shaped words there.
Same files, a field that DOES flow (with_sample_data / manifest_json / requires)	artifact-kernel-factory.ts 19, cloud-artifact-helpers.ts 9, routes/cloud.ts 9 — the population is reachable
⭐ The strongest one: the same inst row in the same loop	inst.enabled :629, inst.package_version_id :630, inst.with_sample_data :668 all fire; inst.granted_permissions = 0. The zero is a reading about ONE object the code already holds, not a dead search.
Requested-permissions field flowing through the publish compiler (proves the permissions surface itself is findable end to end)	plugin-artifact.ts:41 (PluginPermissionsSchema composed into PluginManifestSchema) then :181 (permissions: JSON.stringify(manifest.permissions) onto PluginVersionFields) then package-install.ts:640 (parsePermissions(version.permissions)) then :652 (serialized onto the install row). The chain is live and greppable — it simply stops at the row.
granted_permissions repo-wide in cloud	23 hits. Production code touches it only on the control-plane row (package-install.ts:643/652, environment-crud.ts:1609/1641); the rest are the column declaration, four docblock/comment lines, one route-ledger note, and 13 test lines. Zero on any artifact-assembly, artifact-cache or kernel-factory path.

---

5. Proposal — the exact contract field the code phase would land

⛔ Nothing below is implemented in this dispatch. This is the specification the CONTRACT_REVIEW_TIER dispatch would build.

5.1 The field

Add one top-level key to the artifact envelope, sibling of metadata:

{
  "schemaVersion": "0.1",
  "environmentId": "env_...",
  "commitId": "...",
  "checksum": "...",
  "metadata": { "objects": [], "apps": [] },
  "grantedPermissions": {
    "com.acme.crm-plugin": { "services": ["object"], "hooks": ["record.beforeInsert"], "network": [], "fs": [] }
  },
  "runtime": {}
}

• Name: grantedPermissions (camelCase — the envelope is camelCase throughout: schemaVersion, environmentId, commitId, builtAt).
• Shape: z.record(z.string(), PluginPermissionsSchema).optional() — the map key is the plugin id the enforcer keys on; the value is the existing four-class schema, imported, not re-declared. This is exactly the set plugin-consent.ts already parses, so the producer needs no new parser.
• Semantics, stated in the schema: key absent from the map = no consent record for that plugin (first-party / built-in, or a pure-metadata package); key present with {} = consent-bearing and consented to nothing. The whole map absent = this artifact predates the field. ⭐ Preserving absent-versus-{} is load-bearing: it is the distinction package-install.ts:651-653 already writes, and it is the input to Phase 1 of #11333: wire granted_permissions into PluginPermissionEnforcer (F4) as the load-time gate #13457's clause 1.3 fail-safe question. The producer must not collapse it.

5.2 Why top-level, and not inside metadata

Three measured reasons, in order of weight:

1. metadata is ObjectStackDefinitionSchema — the AUTHORED, compiled app definition. A consent decision is not authored metadata. Putting the grant where the plugin's own compiled body lives makes the grant reachable by the thing it constrains; the control plane's own decision belongs in the control-plane-assigned band of the envelope, next to commitId, checksum and runtime.
2. The merge would destroy it. mergeArtifactMetadata (cloud-artifact-helpers.ts:540-573, the filter at :555-557) ingests array-valued known-category keys and concatenates them across bundles. A per-install map is not an array, and even as an array the concat loses which install each entry came from.
3. The envelope literal is where cloud already writes control-plane facts (routes/cloud.ts:747-757), which is the one place a per-install map can be assembled once, after the install loop has run.

⚠️ The alternative carrier — putting a grant on each ADR-0130 D4 assembled package body (metadata.packages[], ArtifactPackageSchema, framework stack.zod.ts:1237) — is unavailable today and would be blocked behind a separate defect: cloud's merge drops metadata.packages[] entirely (packages is in neither KNOWN_METADATA_CATEGORIES nor PASSTHROUGH_ARTIFACT_KEYS), and the ADR-0078 completeness gate cannot see that drop because collectArtifactCategoryKeys records only recognised keys (cloud-artifact-helpers.ts:589-594). Filed separately as objectstack-ai/cloud#1888.

5.3 Where it is written (cloud, consent-compile time)

packages/service-cloud/src/routes/cloud.ts, inside the marketplace-install merge loop :611-680 — the loop that already holds inst:

• accumulate parsePermissions(inst.granted_permissions) (helper already imported in the sibling routes) into a map keyed by the install's manifest id, for every enabled, consent-bearing install;
• add the assembled map to the envelope literal at :747-757.

No new parser, no new query, no new table. sys_env_artifact_cache needs no change — it stores the envelope verbatim (env-artifact-cache.ts:91), so the field rides into the environment-local carrier for free. That is the ruling's carrier claim, confirmed.

5.4 Where it would be read (materialize time)

ArtifactKernelFactory already has both halves in hand at artifact-kernel-factory.ts:473-490: the artifact (control-plane or env-local cache) and the kernel it is about to build. The read is artifact.grantedPermissions[PLUGIN_ID] handed to enforcer.registerGrantedPermissions(...) at the point a third-party plugin is materialized.

⚠️ That materialization seam does not exist yet — #13457's A2.1 finding, re-confirmed at this pin (§3 above). This proposal makes the grant available at the seam; it does not build the seam.

5.5 File list and dependency order

objectstack — must land FIRST:

1. packages/spec/src/system/environment-artifact.zod.ts — declare grantedPermissions on EnvironmentArtifactSchema (:83-146), importing PluginPermissionsSchema from ../kernel/manifest.zod. TSDoc names producer (cloud, at consent-compile), consumer (F4, at materialize), and the absent-versus-{} semantics. ⚠️ Clause-② public-surface widening on packages/spec — review chain.
2. packages/spec/src/system/environment-artifact.test.ts — wire-shape pins in both directions: absent parses; {} parses; a fifth permission class is REJECTED (rides PluginPermissionsSchema's existing .strict()); a non-object value is rejected.
3. packages/spec/src/kernel/manifest.zod.ts — doc only, no shape change. The PluginPermissionsSchema docblock :19-31 currently says the consent flow turns the declaration into "the persisted granted_permissions set enforced at load by the PluginPermissionEnforcer" — a sentence that points the reader at the control-plane table ADR-0003 forbids reading at runtime. Add the carrier: persisted on the row for audit, carried to the runtime on the artifact envelope.
4. (consumer half — Phase 1 of #11333: wire granted_permissions into PluginPermissionEnforcer (F4) as the load-time gate #13457, not this chain) packages/core/src/security/** plus the materialize seam.

cloud — after the spec version is pinned:

5. .objectstack-sha — bump to the framework commit carrying (1).
6. packages/service-cloud/src/routes/cloud.ts — §5.3.
7. packages/service-cloud/test/ — pins: an enabled plugin install's consented set reaches the envelope under its manifest id; a pure-metadata install contributes no key; a disabled install contributes no key (matching the :629 skip).
8. packages/objectos-runtime/src/artifact-kernel-factory.ts — the eventual caller (§5.4), gated on the framework seam existing. Note for triage: this file is in cloud, not objectstack, so the "objectstack consumes it at materialize time" half of the ruling actually spans two repos — objectstack owns the seam, cloud owns the call.

5.6 Pin-lag check — the framework half is NOT consumable by cloud at the current pin, and landing cloud first would fail SILENTLY

At 655b106, EnvironmentArtifactSchema has no such key, and every door on the path is non-strict:

• EnvironmentArtifactSchema is a plain z.object (packages/spec/src/system/environment-artifact.zod.ts:83) — unknown keys are stripped, not refused.
• ManifestSchema is a plain z.object (packages/spec/src/kernel/manifest.zod.ts:158) — same.
• objectstack's artifact door parses through it: packages/metadata/src/plugin.ts:900-925, _parseAndRegisterArtifact, EnvironmentArtifactSchema.parse(...) at :908 / :915.

⇒ A cloud-first landing produces green tests on the cloud side, a field present on the wire, and nothing at all on the objectstack side — the exact silent-strip class the spec's own tombstone machinery exists to prevent (retiredKey, packages/spec/src/shared/retired-key.ts:106-108). Spec first, pin bump, cloud second. That order is also plain contract-first.

⚠️ One asymmetry worth recording for whoever builds §5.4: cloud's own ArtifactKernelFactory reads the envelope structurally and never runs EnvironmentArtifactSchema.parse (artifact-kernel-factory.ts:981-990), so on the cloud-hosted path an undeclared field would survive. That is not a licence to skip the spec declaration — it means the two consumer paths would disagree, which is worse than either failure alone.

---

6. Two contract questions the code phase needs answered (not blocking this measurement)

1. What is the map key? The enforcer keys on pluginName (plugin-permission-enforcer.ts:102). cloud holds sys_package_installation.package_id and the manifest's id. AppPlugin derives the kernel plugin name from bundle.manifest.id (artifact-kernel-factory.ts:975-983), so the manifest id is the spelling that matches what the enforcer will be asked about. Recommend manifest id; the residual risk is a package whose manifest id differs from its control-plane package_id, which the code phase should pin either way.
2. Absent versus empty at the consumer. The producer contract above keeps them distinct. Which one means "deny nothing" and which means "deny everything" is Phase 1 of #11333: wire granted_permissions into PluginPermissionEnforcer (F4) as the load-time gate #13457's clause 1.3 and stays the consumer half's question — but it is only answerable if the producer preserves the distinction, which is why it is stated in the schema rather than left to the writer.

---

7. Filed out of scope

• objectstack-ai/cloud#1888 — artifact assembly drops metadata.packages[] (ADR-0130 D4 assembled package bodies) silently, and the ADR-0078 completeness gate cannot see the drop by its own design. Same class as cloud#897 / [portal] 多语言 supportedLocales + fallbackLocale + 切换器协议（GAP-3 of #1294） #1333 / fix(runtime): mount set-initial-password on per-environment auth-proxy (#1544) #1562 / chore(automation): retire the workflow_rule authoring paradigm (ADR-0018 M5 dropped) #1578. Dedup: all 56 open cloud issues listed by repo-scoped REST and grepped title plus body — 0 hits, with artifact = 15 and merge = 9 as positive controls on the same corpus.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 14034,
  "status": "done",
  "branch": null,
  "pr": null,
  "premise_still_valid": true,
  "summary": "MEASUREMENT PHASE, no code. VERDICT: NO -- the artifact cloud compiles today does NOT carry the granted permission set. The consent flow parses the four-class set and writes it to exactly one place, the control-plane row sys_package_installation.granted_permissions (routes/package-install.ts:640-652, written :667/:678; SDK arm environment-crud.ts:1607-1641; column decl sys-package-installation.object.ts:158-167). The compiled environment artifact does not carry it: the envelope literal is routes/cloud.ts:747-757 (schemaVersion, environmentId, commitId, checksum, metadata, functions, manifest, builtAt, builtWith, runtime) and the marketplace-install merge loop at :611-680 reads the very install row and consumes exactly three of its columns -- inst.enabled :629, inst.package_version_id :630, inst.with_sample_data :668 -- never inst.granted_permissions; what it merges is ver.manifest_json, the version's DECLARED (requested) manifest. Per-carrier: control-plane row YES (but ADR-0003 forbids runtime reads); sys_package_version.permissions = requested only; artifact envelope NO; metadata merge NO and structurally cannot without a declaration (mergeArtifactMetadata cloud-artifact-helpers.ts:540-573 ingests only array-valued known-category keys and concatenates across bundles); env-local carrier sys_env_artifact_cache NO today but YES for free once the envelope carries it (env-artifact-cache.ts:39-44 three columns, :88-102 stores JSON.stringify(artifact) verbatim) -- the ruling's carrier assumption is CONFIRMED, not contradicted; .osplugin unpack does not exist in cloud (plugin-artifact.ts:6-11, cloud never unpacks); ArtifactKernelFactory NO (bundle built structurally at :981-990; PluginPermissionEnforcer / SecurePluginContext / enforceServiceAccess = 0 hits in the whole cloud repo); public /pub artifact route NO. Framework at pin 655b106: the consumer wants a per-plugin keyed map -- registerGrantedPermissions(pluginName, PluginPermissions) at packages/core/src/security/plugin-permission-enforcer.ts:102-111, value shape = PluginPermissionsSchema {services,hooks,network,fs} .strict() at packages/spec/src/kernel/manifest.zod.ts:32-44. There is NO granted-permissions field anywhere in the spec surface (grep 'granted' across packages/spec/src returns zero permission declarations; manifest.zod.ts:290-291 permissions is the REQUEST). sys_package_installation is read on no runtime path in objectstack -- granted_permissions = 3 hits at the pin, all prose -- and #13457's zero-production-callers reading is re-confirmed at this pin. Proposal delivered on the card: one top-level envelope key grantedPermissions, z.record(z.string(), PluginPermissionsSchema).optional(), key absent vs empty-object preserved (the distinction package-install.ts:651-653 already writes); written in the install loop that already holds the row and added to the envelope literal; read at materialize time by ArtifactKernelFactory once #13457's seam exists. Files: objectstack FIRST (spec/src/system/environment-artifact.zod.ts declare + its test pins + a doc-only carrier sentence on manifest.zod.ts:19-31), then cloud (.objectstack-sha bump, routes/cloud.ts, cloud tests); env-artifact-cache.ts needs no change. PIN-LAG: the framework half is NOT consumable at the current pin and a cloud-first landing would fail SILENTLY -- EnvironmentArtifactSchema (spec/src/system/environment-artifact.zod.ts:83) and ManifestSchema (manifest.zod.ts:158) are both plain z.object, so an undeclared key is STRIPPED at objectstack's artifact door (packages/metadata/src/plugin.ts:900-925, parse at :908/:915). Spec first, pin bump, cloud second. One scope observation for PM, not a fork: the materialize-time CALLER (ArtifactKernelFactory) lives in cloud/packages/objectos-runtime, not objectstack, so the ruling's 'objectstack consumes it at materialize time' half spans two repos -- objectstack owns the enforcer seam, cloud owns the call.",
  "tests": "No build, no test run, no gates -- this dispatch changed no code in either repo (read-only detached worktree at cloud origin/main 2f4692339566c5df91afe8b1977daeb19119f2e4; framework read via `git show` / `git grep` against pin 655b106ce2804d2cdb9ed4386df795152535d372 in the shared checkout, never switched). Evidence is greps, each zero paired with a firing positive control. (1) Any 'permission' spelling across the artifact-assembly + env-local-carrier + kernel-factory files (routes/cloud.ts, cloud-artifact-helpers.ts, cloud-artifact-api-plugin.ts, env-artifact-cache.ts, artifact-kernel-factory.ts, artifact-api-client.ts) = 8 hits, NONE about plugin grants (ai_seat, systemPermissions, audience_self_registration_permission_set, permissionSets-as-metadata-category) -- the instrument reaches those files and finds permission-shaped words there. (2) Same files, fields that DO flow (with_sample_data / manifest_json / requires) = 19 / 9 / 9 hits -- population reachable. (3) STRONGEST: the same `inst` row inside the same loop -- inst.enabled (routes/cloud.ts:629), inst.package_version_id (:630), inst.with_sample_data (:668) all fire; inst.granted_permissions = 0. The zero is about an object the code already holds open. (4) Requested-permissions chain end to end, proving the permissions surface is greppable: plugin-artifact.ts:41 then :181 then package-install.ts:640 then :652 -- live, and stopping at the row. (5) granted_permissions repo-wide in cloud = 23 hits: production touches it only on the control-plane row (package-install.ts:643/652, environment-crud.ts:1609/1641), plus the column decl, four docblock/comment lines, one route-ledger note, 13 test lines -- zero on any artifact-assembly, artifact-cache or kernel-factory path. (6) Framework at the pin: registerGrantedPermissions / new SecurePluginContext( / new PluginPermissionEnforcer( / createPluginPermissionEnforcer return only the definition, the barrel re-export (packages/core/src/security/index.ts:59) and three test files -- zero production callers, #13457's reading re-confirmed; `granted` across packages/spec/src returns zero permission declarations while returning invitedBy / granted_by / API-primitive prose (control fires). (7) Dedup for the out-of-scope filing: all 56 open objectstack-ai/cloud issues listed by repo-scoped REST (pages 2 and 3 empty) and grepped title plus body for packages-array / mergeArtifactMetadata / KNOWN_METADATA_CATEGORIES / ADR-0130 / assembled package = 0 hits, with `artifact` = 15 and `merge` = 9 on the same corpus as positive controls. CHANNEL NOTE: repo-scoped REST reads and writes both work from this seat (200 on issue reads, 201 on comment and issue creation); the GitHub SEARCH API is 403 from here, so dedup used the repo-scoped list endpoint plus a local grep rather than search_issues. NOT MEASURED: whether a real published artifact carries metadata.packages-array today (recorded on cloud#1888 with its re-check).",
  "mcp_calls": "0 -- all GitHub reads and writes went through repo-scoped REST (curl); no MCP GitHub tool was called",
  "open_questions": [
    {
      "question": "What is the map key for the artifact's grantedPermissions record -- the manifest `id` or the control-plane `package_id`? (For the CONTRACT_REVIEW_TIER code phase; not blocking this measurement.)",
      "options": [
        "A. manifest `id` -- matches what the enforcer will be asked about: AppPlugin derives the kernel plugin name from bundle.manifest.id (artifact-kernel-factory.ts:975-983) and PluginPermissionEnforcer keys on pluginName (plugin-permission-enforcer.ts:102)",
        "B. control-plane `package_id` -- the key cloud already owns on sys_package_installation, but it is not the identity the enforcer is queried with, so the consumer would need a second resolution path"
      ],
      "recommendation": "A, because the grant must be findable under the identity the enforcer is actually asked about; a second name-to-package resolution path is the shape objectstack#14512's triage rejected by name. Residual risk to pin either way: a package whose manifest id differs from its package_id."
    },
    {
      "question": "Absent versus empty at the consumer -- which of `key absent from the map` and `key present with an empty object` means deny-nothing and which means deny-everything? (This is #13457 clause 1.3 and stays the consumer half's question.)",
      "options": [
        "A. Producer preserves the distinction and the consumer decides -- absent = no consent record (first-party/built-in or pure-metadata package), empty object = consent-bearing and consented to nothing",
        "B. Producer collapses both to an empty object -- simpler wire shape, but destroys the only signal separating 'never went through consent' from 'consented to nothing'"
      ],
      "recommendation": "A. cloud already writes the distinction (package-install.ts:651-653 emits granted_permissions only under consentBearing), and clause 1.3 is only ANSWERABLE if it survives the carrier -- which is why the proposal states it in the schema rather than leaving it to the writer."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectstack-ai/cloud#1888: artifact assembly drops metadata.packages-array (ADR-0130 D4 assembled package bodies) silently -- `packages` is in neither KNOWN_METADATA_CATEGORIES nor PASSTHROUGH_ARTIFACT_KEYS (cloud-artifact-helpers.ts:461/492/532), and the ADR-0078 completeness gate cannot see the drop because collectArtifactCategoryKeys records only recognised keys by design (:589-594). Same class as cloud#897/#1333/#1562/#1578. Load-bearing for this card: it is why the per-package body is NOT an available carrier for the grant today."
  ]
}

---

Generated by Claude Code