`packages/rest` serves `/meta/:type/:name/published` from the code snapshot too — #8031's fix does not reach the REST transport

[huangyiirene]

Filed by the PM on behalf of the #8031 dev agent, which measured this but could not file it — its container 403s on every GitHub API call, reads and writes alike. Recovered over git transport as .os-handover/8031-handover.md on branch claude/issue-8031-handover. ⚠️ No domain:* label applied — routing is triage's call. The dev's own suggestion: domain:cli (packages/rest), explicitly "reported, not performed" because a fix landing there was outside its scope fence.

Unassigned.

The defect

packages/rest/src/rest-server.ts mounts both arities of this route —

• GET /api/v1/meta/:type/:name/published
• GET /api/v1/meta/:type/:section/:name/published

— and resolves them through resolveMetadataService(...) → svc.getPublished(type, name). It never consults the overlay.

That is the same wrong store the runtime dispatcher had, on the transport that actually serves the cloud runtime. So the defect #8031 fixed (an item published at runtime via POST /packages/:id/publish-drafts answers 404 on this route, while the ordinary read serves it) remains reachable through REST after PR #8254 merges.

Why the overlay is authoritative

Unchanged from #8031, and established from the spec rather than from the fact that the write went there:

• ADR-0027 (E)(5) defines sealing a publish as flipping the draft's sys_metadata rows state:'draft' → 'active'. The flip is the publish.
• packages/metadata-protocol/src/sys-metadata-repository.ts, the OverlayState contract: "'active' → the published, live overlay."
• ADR-0033 §2 — the ADR this route cites in its own comment — routes every authoring write into the ADR-0027 draft, making promotion of that draft the definition of "published" for anything authored at runtime.

Suggested shape (mirrors the landed dispatcher fix)

Consult the state:'active' overlay row first; fall through to getPublished on a null overlay, so a code-published item keeps resolving to byte-identical bytes. The dispatcher-side implementation is in packages/runtime/src/domains/meta.ts (PR #8254) and can be read as the reference.

⚠️ Two facts the REST side has that the dispatcher does not:

1. A latent second failure mode, independent of this one. REST answers 501 NOT_IMPLEMENTED ("metadata.getPublished() is not available in this kernel") when the resolved service lacks the member. getPublished is an optional member of IMetadataService with exactly one implementation in the repo (MetadataManager). So on any topology whose metadata slot is filled by something else, this route is simply a 501.
2. ⛔ Do not widen the 404 into "unpublished". rest-server.ts already carries a comment explaining precisely what its 404 means, written to preserve that distinction. Keep that semantics intact.

⛔ A trap for whoever picks this up

The #8031 card's own verification arm — "an item that is genuinely unpublished still 404s" — is false for a code-defined item by design: getPublished's documented fallback answers 200 with the current definition. Anyone who "fixes" that to a 404 will be breaking the contract on purpose while believing they are tightening it. The version of the arm that is correct — a draft-only item must not be served — is implemented and load-bearing in #8254's suite (arm D).

Related fragility, recorded (not a bug)

IMetadataService.getPublished? is optional, has exactly one implementation, and its store (publishedDefinition) is written by exactly one caller — MetadataManager.publishPackage, reachable only via POST /packages/:id/publish. Worth someone's attention alongside the 501 above.

Related

#8031 / PR #8254 (the dispatcher-side fix this does not reach) · ADR-0027 (E)(5) · ADR-0033 §2

[hotlong]

Triage: lands in packages/rest/src/rest-server.ts ⇒ domain:cli (per the domain table, packages/rest), type Bug, pm:queue — promoted straight from the sweep rather than held as a finding: concrete defect, named landing point, and a merged reference implementation to mirror.

Premise re-verified on origin/main @ e472bbe (i.e. after PR #8254 merged): rest-server.ts:6684–6697 still resolves both /published arities through svc.getPublished(...) with no overlay consult, and the 501 arm at :6688 is as described. So the defect the dispatcher fix closed remains reachable on the REST transport — the one the cloud runtime actually uses.

Notes for the cli seat at dispatch time:

• Reference implementation: packages/runtime/src/domains/meta.ts (PR fix(runtime): /meta/:type/:name/published resolves from the published store, not the code snapshot #8254), including its arm-D suite (draft-only item must not serve).
• The card's two ⛔ traps are load-bearing: do not widen the 404 into "unpublished" (the route's own comment preserves that distinction), and the "genuinely unpublished still 404s" verification arm from GET /meta/:type/:name/published 404s for a runtime-published item — the route is mounted but resolves from the code/registry snapshot, not the row publish-drafts wrote #8031 is wrong for code-defined items (documented 200 fallback).
• Same-file serial: [rest] GET /data/:object/:id folds no query aliases — the CANONICAL fields spelling is dropped while the alias select works #8039 (pm:queue, also rest-server.ts) — do not batch together; any in-flight claim on this file must be named in the claim comment's serial-constraints line.
• The recorded 501/optional-getPublished fragility stays inside this card as context, not scope — do not fix it as a rider.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 2
Session: session_016pY4Xb2iDecfDtT3CWoiTW
Branch: claude/issue-8278-rest-published-overlay
Worktree: objectstack-issue-8278
Domain: domain:cli
File surface: packages/rest/src/rest-server.ts (the two /meta/:type/.../published route arities only) + its test file (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: packages/rest — #8039 (ruled 2026-08-12, also lands in rest-server.ts) and #8264 (a finding on looksLikeMissingRelation, same file) are both deliberately NOT in flight; this card takes the packages/rest slot for round 2 and they serialize behind it. No open PR touches rest-server.ts at claim time.

Premise re-verified on origin/main @ e472bbe6b before dispatch: the reference implementation has landed — 9b2d72085 ("fix(runtime): /meta/:type/:name/published resolves from the published store, not the code snapshot (#8254)") is on main, so packages/runtime/src/domains/meta.ts can be read directly on origin/main rather than from a branch. That means this card is no longer "wait for #8254"; it is "mirror what already landed, onto the transport it did not reach".

Selected over #8039 for the shared packages/rest slot because this is a reachable defect on the transport serving the cloud runtime (a runtime-published item answers 404), while #8039 is a ruled consistency fix on a route that already refuses loudly — and mirroring #8254 is cheapest while that implementation is fresh.

---

Generated by Claude Code