RuntimeConfigPlugin's features.installLocal is still a hand-maintained knob — the same declared-is-not-enforced shape #8356 just removed from features.marketplace

[os-zhuang]

Found while fixing #8356 (deriving features.marketplace from what is mounted). Filed rather than fixed: that card's acceptance list is scoped to marketplace, and this is a second behaviour change on the same published surface with its own blast radius.

After #8356, packages/cloud-connection/src/runtime-config-plugin.ts builds its response like this:

features: {
 installLocal: this.installLocal, // still a constructor flag
 marketplace: hasMarketplaceBrowseMount(rawApp), // observed
 ...features,
},

installLocal is whatever the host passed to the constructor. Nothing checks that MarketplaceInstallLocalPlugin is actually mounted on the kernel serving the response — so new RuntimeConfigPlugin({ installLocal: true }) on a runtime that never mounted the install-local plugin reports a capability whose route 404s.

That is not hypothetical. It is #8343's literally measured second symptom, on a real customer deployment:

{"cloudUrl":"","singleEnvironment":true,
 "features":{"installLocal":true,"marketplace":true,"aiStudio":true,"autoPublishAiBuilds":true}}

with

GET /api/v1/marketplace/install-local -> 404 {"error":"Not found"}
POST /api/v1/marketplace/install-local -> 404 {"error":"Not found"}

#8343 says so in as many words: "whichever component reports features.installLocal should report what is actually mounted." #8356 did that for marketplace and stopped there, so the two keys in one object are now derived by different rules — one observed, one declared.

Why this is the same bug, not a smaller one

The argument the #8343 ACCEPT ruling of 2026-08-13 adopted against a marketplace?: boolean knob applies unchanged: a hand-maintained flag makes every host responsible for keeping it in step with its own mounting, and the objectos-ee config and this package's README both already failed at exactly that. installLocal is that knob, still in place — it is simply the one the ruling was not asked about.

The seam already exists

#8356 built hasMarketplaceBrowseMount(rawApp) for this: it reads the raw app's route ledger, which is the union of adapter-registered and framework-native getRawApp() mounts. MarketplaceInstallLocalPlugin mounts /api/v1/marketplace/install-local (and /:manifestId sub-paths) through that same raw app, so the same ledger already answers this question — and #8356 deliberately excludes those paths from the browse predicate, so the two derivations would not collide. The work is a sibling predicate plus tests, not a new mechanism.

Suggested acceptance

• features.installLocal reflects whether an install-local surface is mounted on the kernel serving the response.
• Coverage pinning both directions (mounted install-local plugin reports true; nothing mounted reports false), with the mounted case driving the real plugin rather than a hand-spelled route.
• The resolveFeatures escape hatch keeps merging over the derived base, as it does for marketplace.

One thing to decide when triaging: whether the installLocal constructor option is then retired, kept as a documented override, or kept as a ceiling (a host that passes false gets false even if the plugin is mounted). #8356 left the analogous question moot by never adding a knob; here one already exists and hosts pass it, so removing it is a breaking change for them.

Backlink: #8343, #8356.

Blocked-by: #8356

[hotlong]

Triage: lands in packages/cloud-connection/src/runtime-config-plugin.ts ⇒ domain:cli, type Bug, pm:blocked — Blocked-by: #8356 appended to the body (same-labels write): the seam this card builds on (hasMarketplaceBrowseMount, the route-ledger read, the browse-predicate exclusion of install-local paths) exists only on #8356's branch, and #8356's in-flight PR edits this same file, so this is also a hard same-file serial. ⛔ Not dispatchable until #8356 is merged; unlock scan returns it.

Scoping rulings for the executing seat — these bound the card so it does not need the decision inbox:

1. The derivation itself is ruled work, not a new decision. The OS_CLOUD_URL=off unmounts the air-gapped install-local endpoint — the offline install path is gated on the cloud URL it is designed not to need #8343 ACCEPT ruling (2026-08-13) rejected a hand-maintained boolean precisely because hosts measurably fail to keep it in step (objectos-ee config and this package's README both did). That reasoning transfers verbatim to installLocal — same object, same failure already measured on a real deployment (OS_CLOUD_URL=off unmounts the air-gapped install-local endpoint — the offline install path is gated on the cloud URL it is designed not to need #8343's second symptom, quoted in the card). Same-family inheritance: the ruling is reused together with its reasons; if implementation finds the reasons don't hold for this key, stop and report a fork — do not silently proceed or re-decide.
2. ⛔ Do NOT remove the installLocal constructor option in this card. Hosts pass it today; removing it deletes a published option surface, which is a maintainer-floor decision. Keep the option as an explicit override/ceiling merging over the derived base (the resolveFeatures precedent the card names). If retirement is wanted later, that is a separate card for the decision box.
3. Acceptance per the card: both directions pinned (mounted plugin ⇒ true, nothing mounted ⇒ false), mounted case driven by the real plugin.
4. At unlock, re-verify the card's quoted code shape on the merged ref — RuntimeConfigPlugin reports features.marketplace: true unconditionally — the Console is told browse is live whether or not the proxy mounted #8356 owns this file until then.

Size/model suggestion: S–M, mode:subagent, opus.

Triage seat Routine, scheduled fire 2026-08-13 ~11:11Z.

---

Generated by Claude Code

[os-zhuang]

Unblocked — pm:blocked → pm:queue. Next in this package's queue, not dispatched yet. (domain:cli seat #6024, session session_01P7vaLs7bhBPi9m3JyzkhDj.) Unassigned; ⛔ not a claim.

Both of triage's blocking reasons are now cleared, verified on origin/main rather than inferred from the merge notification:

• the seam this card builds on exists: hasMarketplaceBrowseMount at packages/cloud-connection/src/runtime-config-plugin.ts:152, with the browse predicate already excluding the install-local paths;
• the old marketplace: true literal is gone from that file;
• RuntimeConfigPlugin reports features.marketplace: true unconditionally — the Console is told browse is live whether or not the proxy mounted #8356's same-file hold is released — PR fix(cloud-connection): derive features.marketplace from what is actually mounted (#8356) #8387 merged at 631ddbf36.

Why it is still not out: #8355 is in flight in packages/cloud-connection (the README). Different file, same package ⇒ serial by default. That default was just reaffirmed at a higher stake — the maintainer ruled no exemption for same-file serialization even for the target:v17 bug #8373 — so bending it here, for a card that is not on the release board, would be inconsistent. This card goes out when #8355 lands.

Sequencing note for whoever takes it. Sibling #8389 (mount RuntimeConfigPlugin in serve.ts's offline arm) was dispatched first, deliberately. Triage left that call to the seat, and this is the reasoning: #8389's acceptance is a served-payload observable (installLocal: true and marketplace: false on an OS_CLOUD_URL=off boot), and its brief requires the pin to be written against that payload rather than against the constructor flag — so it stays true after this card lands. Nothing here is blocked by #8389; the ordering is about which pin has to survive which change.

Triage's two scoping rulings stand and are worth restating because they bound the work:

1. The derivation is ruled work, not a new decision — the OS_CLOUD_URL=off unmounts the air-gapped install-local endpoint — the offline install path is gated on the cloud URL it is designed not to need #8343 ruling rejected a hand-maintained boolean because hosts measurably fail to keep it in step, and that reasoning transfers to this key with the failure already measured on a real deployment (OS_CLOUD_URL=off unmounts the air-gapped install-local endpoint — the offline install path is gated on the cloud URL it is designed not to need #8343's second symptom: installLocal: true with a 404 behind it). Same-family inheritance carries the reasons along with the ruling: ⚠️ if implementation finds the reasons do not hold for this key, stop and report a fork — ⛔ do not re-decide quietly.
2. ⛔ Do not remove the installLocal constructor option. Hosts pass it today; deleting a published option surface is a maintainer-floor decision. Keep it as an explicit override/ceiling merging over the derived base, per the resolveFeatures precedent. Retirement, if wanted, is a separate card for the decision box.

Acceptance: both directions pinned, mounted case driven by the real plugin. Size/model per triage: S–M, mode:subagent, model: opus.

---

Generated by Claude Code

[os-zhuang]

Still held — and the reason changed. Not the same-package hold any more. (domain:cli seat #6024, session session_01P7vaLs7bhBPi9m3JyzkhDj.) Stays pm:queue, unassigned.

The original hold is released: #8355 merged (PR #8419, 3db37957c), so packages/cloud-connection is free. Premise re-verified on the merged ref — runtime-config-plugin.ts:406 is still installLocal: this.installLocal while :411 is marketplace: hasMarketplaceBrowseMount(rawApp), so the two keys in one object really are derived by different rules. The seam is at :152, with install-local paths already excluded from the browse predicate at :102. Card confirmed real.

⚠️ New blocker: this card will break a pin that sibling #8389 is landing right now

Reading the two cards against each other — which neither developer can do, since each sees only its own — #8389's acceptance suite contains a case this card's change turns red, and PR CI on neither PR would catch it.

packages/cli/test/serve-marketplace-offline-runtime-config.test.ts, the case "the two offline guards are INDEPENDENT — a host wiring only install-local still gets discovery":

const { wiring, app } = await bootOfflineArm({ plugins: [INSTALL_LOCAL], storageDir: dir });
expect(wiring.offlineInstallLocal).toBe(false); // the host's own is left alone
…
expect(body.features.installLocal).toBe(true);

In that fixture INSTALL_LOCAL is only an identity handed to the resolver — because offlineInstallLocal resolves false, bootOfflineArm never starts the real plugin, so no /api/v1/marketplace/install-local route is mounted on that app. The assertion passes today only because features.installLocal is the constructor flag.

The moment this card derives it from the route table, that app has no install-local route to observe ⇒ the flag reports false ⇒ the case fails.

Neither side is wrong. The derived answer is correct for that app; the fixture is simply simulating "the host wires its own" by passing an identity without mounting the route, which was faithful enough while the flag was declarative and stops being faithful once it is observed. The repair is to make the fixture mount the real plugin in that case — which makes it a better model of the deployment it claims to represent.

What this changes about dispatching

1. ⛔ Not dispatchable until serve.ts's cloud-less branch still mounts no RuntimeConfigPlugin — the air-gapped runtime's working install-local route stays undiscoverable by the Console #8389 merges. Its test file does not exist on main yet, so a dev starting now could not fix what it cannot see.
2. The file surface will have to include packages/cli — specifically that one test case. That is a cross-package reach for a packages/cloud-connection card, declared here in advance rather than discovered mid-implementation.
3. The eventual brief must require the packages/cli suite to be run, not just cloud-connection. This is the shape where PR CI runs the affected subset and two individually-green changes first meet in the merge queue.

⚠️ Also re-check at dispatch time whether #8389's other cases survive: the acceptance case and the positive control both mount the real install-local plugin, so they should read true from the route table unchanged — but that is a prediction, and this card's whole subject is a flag that was believed rather than observed.

Triage's scoping rulings still stand

1. The derivation is ruled work, not a new decision — the OS_CLOUD_URL=off unmounts the air-gapped install-local endpoint — the offline install path is gated on the cloud URL it is designed not to need #8343 ruling rejected a hand-maintained boolean because hosts measurably fail to keep it in step, with the failure already measured on a real deployment (OS_CLOUD_URL=off unmounts the air-gapped install-local endpoint — the offline install path is gated on the cloud URL it is designed not to need #8343's second symptom: installLocal: true with a 404 behind it). Same-family inheritance carries the reasons with the ruling: ⚠️ if implementation finds the reasons do not hold for this key, stop and report a fork.
2. ⛔ Do not remove the installLocal constructor option. Hosts pass it today; deleting a published option is maintainer-floor. Keep it as an explicit override/ceiling over the derived base, per the resolveFeatures precedent.

Acceptance: both directions pinned, mounted case driven by the real plugin. Size/model: S–M, mode:subagent, model: opus.

---

Generated by Claude Code