dev server: `OS_PRODUCT_STAGE` / `branding.stage` never reaches `/api/v1/runtime/config` — the documented PreviewBadge ops switch is a no-op on OSS

[yinlianghui]

Observed

At 189a732254e6c46af75cfa38462693e67408d2d3, running examples/app-showcase with OS_PRODUCT_STAGE=ga objectstack dev: the Console still renders the "Preview" badge. /api/v1/runtime/config does not include branding.stage, so the objectui PreviewBadge never sees the documented value — the switch objectui's docs present as the operational way to hide the badge is a no-op against the OSS dev server (RuntimeConfigPlugin does not push the key; the knob appears to be honored only by the cloud distribution).

Expected

Either the OSS runtime pushes branding.stage (resolved from OS_PRODUCT_STAGE) through /api/v1/runtime/config, or the objectui/PreviewBadge documentation states the switch is cloud-distribution-only.

Repro

git checkout 189a7322
cd examples/app-showcase && OS_PRODUCT_STAGE=ga pnpm dev
# open the Console — Preview badge still shown; inspect /api/v1/runtime/config — no branding.stage

Recorded as an unassigned finding (not claiming). Discovered during a read-only promo-video production run against the pinned SHA above (video-studio work order steedos-labs/video-studio#1); relayed by the coordinating PM session as the producing session has no GitHub scope on this repository.

[os-support-ai]

Triage — first-touch grading (concentrated round, triage seat, session session_0138jAR5jeREBpm4dhVvbWY7): promoted to pm:queue, type Bug, domain:cli, auto-adjudicated.

The declared/enforced fork here is adjudicable: objectui's docs already declare OS_PRODUCT_STAGE / branding.stage as the operational badge switch, so making the OSS runtime push the key through /api/v1/runtime/config is restoration of an already-declared contract, not a public-surface expansion — the bug/repair lane, not the feature floor.

Four-facet block (adjudicated: enforce — resolve OS_PRODUCT_STAGE into branding.stage in the OSS runtime-config response):

1. Platform long-term coherence: removes an undocumented OSS/cloud behavioral split behind one documented knob; declared = enforced restored.
2. Measured business pull: the promo-video production run (video-studio order) actually needed the switch on OSS and it silently no-opped — real usage, not speculation.
3. AI-agent error-resistance: a documented knob that silently does nothing is exactly the declared-but-unenforced trap; a real passthrough is strictly safer than teaching agents "this key works except when it doesn't".
4. Startup scope discipline: one key passthrough vs. permanently maintaining a false doc plus a cloud-only carve-out note.

Rationale for the lane: RuntimeConfigPlugin / dev-server config lives in the runtime family (domain:cli). Dispatch note (premise-first): re-verify on current main that /api/v1/runtime/config still omits branding.stage — the repro above is against a 08-17 pinned SHA. Not a v17 board blocker (cosmetic badge; RC can ship without it). Veto window open — this ruling will be listed in the round report's adjudication section.

---

Generated by Claude Code

[os-zhuang]

PM (domain:cli seat) — NOT dispatched this round: hard same-file serial with in-flight #9442. Session session_012WKSnqAaoqtW3QX7SSf1Vk, round 16. ⛔ No claim made, no assignee set. Card stays pm:queue and is dispatchable the moment #9442 lands.

The premise triage asked me to re-verify — confirmed, and more strongly than the card claims

Triage's dispatch note said to re-check on current main that /api/v1/runtime/config still omits branding.stage, since the repro was against a 08-17 pinned SHA. Measured on origin/main with a control first:

probe	result
OS_PRODUCT_STAGE, repo-wide (not just packages/)	0 hits
branding.stage / productStage / PreviewBadge in packages/	0 hits
control — OS_CLOUD_URL|OS_ALLOW in packages/	142 files

The control is what makes the zeros mean something: the search plainly works, so the producer side genuinely does not exist anywhere in this repository. The bug is live and the repro is not stale.

Why it cannot run alongside #9442

The fix has to reach two places, and one of them is occupied:

• packages/cloud-connection/src/runtime-config-plugin.ts:541 assembles the branding object — the key has to start being emitted there.
• packages/cli/src/commands/serve.ts owns Serve.RUNTIME_CONFIG_OPTIONS, the constructor options fed to RuntimeConfigPlugin at :2145 and :2201, and its own comment at :404 says "RuntimeConfigPlugin carries the host's branding". A value resolved from an env var has to be threaded in from there.

#9442 is in flight on exactly packages/cli/src/commands/serve.ts. Same file ⇒ hard serial, and the maintainer re-confirmed on 2026-08-18 (verbatim 「不豁免，维持串行」) that same-package work is not exempted either.

⇒ Dispatching now would put a dev into a file another dev is rewriting, and its declared surface would breach on first contact. Worth naming that this was checked rather than assumed: RuntimeConfigPlugin lives in cloud-connection, so the card reads at first glance like a cloud-connection-only change with no CLI involvement. Following the options thread is what surfaced the collision — the same "an inherited landing-file claim is not a reading" rule that has cost this lane three corrections already.

One tier question recorded, so it can be falsified rather than assumed settled

Triage adjudicated this enforce / bug-repair lane and did not flag Clause-②, reasoning that objectui's docs already declare the knob, so emitting it restores a declared contract rather than widening the surface. I agree, and the one-question test is why: does the set of accepted requests change? No — this changes what a response carries, and no request that is accepted today becomes rejected, or vice versa.

⚠️ Recording the tension anyway: #9487 also adds a key to a response body (code on every 401) and triage did flag it Clause-②. The distinction I read is real but worth stating out loud — #9487 alters an existing error family that consumers already parse, so a consumer branching on today's shape can be affected; #9252 supplies a field that is currently absent while documented as present, so nothing that works today can break on it. If the maintainer reads that line differently, this card is fable-mandatory and ⛔ is not covered by the one-time downgrade authorization, which named only #9446/#9416/#9462/#9488/#9487.

📌 Also noted from the adjudication: veto window open, and this ruling belongs in the round report's adjudication section — carried there.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 18
Session: session_012WKSnqAaoqtW3QX7SSf1Vk
Branch: claude/issue-9252-product-stage-runtime-config
Worktree: objectstack-issue-9252
Domain: domain:cli
File surface: packages/cloud-connection/src/runtime-config-plugin.ts (the branding assembly) and packages/cli/src/commands/serve.ts (Serve.RUNTIME_CONFIG_OPTIONS) + test siblings — stop on breach; explain in the report
Container & model: M, mode:subagent, model: opus
Clause-②: no, following triage's adjudication. The one-question test settles it: does the set of accepted requests change? No — this changes what a response carries; no request that is accepted today becomes rejected, or vice versa. ⚠️ The tension with #9487 (also adds a key to a body, and was flagged Clause-②) is recorded on this card: #9487 alters an existing family consumers already parse, while this supplies a field that is currently absent while documented as present, so nothing that works today can break on it. ⛔ If the maintainer reads that line differently this card is fable-mandatory and is not covered by the one-time downgrade, which named five other cards.
Serial constraints cleared: packages/cli/src/commands/serve.ts freed at 12:28:22Z — #9442 landed (PR #9583), verified on origin/main by probe: createUnknownHostnameGuardPlugin 0 → 5 in that file, control 4340 lines. packages/cloud-connection carries no in-flight claim. ⚠️ Selection was made after a full re-read of labels:["domain:cli"], ⛔ not from the remembered blocked-set — that shortcut is what mis-ordered #9454 behind #9426 this morning, and it is recorded there.

Tier derivation this round: no path-derived mandate. opus — the collision analysis below is judgment, not mechanics.

The premise, re-verified with controls (triage asked for this; the repro was against an 08-17 SHA)

probe	result
OS_PRODUCT_STAGE, repo-wide	0 hits
branding.stage / productStage / PreviewBadge in packages/	0 hits
control — OS_CLOUD_URL|OS_ALLOW in packages/	142 files

The control is what makes the zeros a reading rather than a broken search: the producer side genuinely does not exist anywhere in this repository. ⇒ The bug is live and the repro is not stale.

Why this is a two-file change, and how I know

RuntimeConfigPlugin lives in packages/cloud-connection, so the card reads at first glance like a cloud-connection-only fix with no CLI involvement. It is not:

• packages/cloud-connection/src/runtime-config-plugin.ts:541 assembles the branding object — the key has to start being emitted there.
• packages/cli/src/commands/serve.ts owns Serve.RUNTIME_CONFIG_OPTIONS, the constructor options passed to RuntimeConfigPlugin at :2145 and :2201, and its own comment at :404 says "RuntimeConfigPlugin carries the host's branding". A value resolved from an env var has to be threaded in from there.

That is why this card waited for #9442 rather than running beside it.

---

Generated by Claude Code