`POST /api/v1/packages/publish` answers a misleading 405 (`Allowed: DELETE, GET, HEAD, PATCH`) — the request is absorbed by `/packages/:id` because the REST package registrar is not mounted on showcase

[huangyiirene]

Symptom

POST /api/v1/packages/publish on a live showcase boot answers 405 with Allowed: DELETE, GET, HEAD, PATCH.

That method list belongs to a different route. POST is the only verb the publish surface ever had, so a 405 naming four other verbs tells the caller "this path exists, just use another method" — when in truth no publish surface is served on this host at all, and every verb in that list would be operating on a package whose id is the literal string publish.

Expected: either the real publish handler (the route is ledgered — POST /api/v1/packages/publish in packages/rest/src/rest-route-ledger.ts, source: direct-mount, disposition: server-only), or an honest 404 for a surface that is not mounted here. A 405 whose Allowed set describes another route's methods is the one answer that misinforms.

Root cause

As far as the run locates it: the REST package registrar is not mounted on showcase. POST /packages/publish is owned by packages/rest/src/package-routes.ts (which is where marketplace publish landed — the file says so explicitly: "Marketplace publish lives at /packages/publish, NOT at the bare …"), and those REST package routes are service-gated, so on a stack without the package service they never register.

With the registrar absent, the path is still matched — by /packages/:id with id = "publish" — and the router derives its Allowed header from that route's method set, which is exactly DELETE, GET, HEAD, PATCH. The path is therefore "reachable" only by accident of the id-parameter route, and the 405 is generated by the wrong owner.

Related, closed: #3610 (POST /api/v1/packages publish-vs-install shape collision, closed by PR #3621) is the reconciliation that moved publish onto /packages/publish in the first place. This is not a regression of that fix's stated acceptance — it is the residue it did not cover: what the /packages prefix answers on a host where only one of the two owners is mounted.

Still live on origin/main as of 2026-08-11 (route present in package-routes.ts and in the REST ledger; gating unchanged).

Reproduction

1. Boot showcase on a fresh isolated file DB (SqlDriver / better-sqlite3); authenticate as admin@objectos.ai.
2. POST /api/v1/packages/publish with any body.
3. Observe 405 with Allowed: DELETE, GET, HEAD, PATCH — not a handler answer, and not the 404 an unmounted surface should give.
4. Cross-check the ledger: POST /api/v1/packages/publish is a declared route, so the 405 is not "this route does not exist" either.

Source

Extracted from the QA run #7463 (framework a86db17).

[os-help]

Claim — PM loop domain:cli, session session_0158ZQo7LiHSxGWpYKuPq1wu (os-help seat, #6024), wave 6.

Unblocked: held behind #7526, which landed minutes ago as PR #7584 (cc3555e78).

⚠️ And that landing is directly relevant to this card — read it before starting. #7584 added a route-ledger ↔ live-mount parity gate that boots a real server, reads the mount table off it, and asserts every ledgered route is reachably mounted — explicitly distinguishing "mounted but shadowed by a catch-all sibling" from "answers". This card is that exact class: POST /api/v1/packages/publish is ledgered (rest-route-ledger.ts, source: direct-mount, disposition: server-only) and is absorbed by /packages/:id with id = "publish", which is where the misleading Allowed: DELETE, GET, HEAD, PATCH comes from — that header is another route's method set.

First question for the dev, before any fix: does the new gate already flag this? If not, why not — the plausible answer is that the REST package routes are service-gated and never register on a stack without the package service, so a conditional registration may be a shape the gate does not yet model. That answer matters more than the individual route: a parity gate that silently tolerates conditional mounts has the same blind spot the old ledger-as-observation guard had.

• Branch: claude/issue-7563-packages-publish-mount-or-404
• The card names the acceptable outcomes — either the real publish handler answers, or an honest 404 for a surface not mounted on this host. ⛔ What is not acceptable is the status quo: a 405 whose Allowed set describes another route's methods is the one answer that misinforms.
• File surface (expected): packages/rest/src/package-routes.ts and/or the registrar wiring, possibly the ledger. ⛔ Do not touch packages/rest/src/rest-server.ts's /meta/app handler — finding: GET /api/v1/meta/app?id=… — the ?id= filter is inert, the same 3 apps come back for any value #7566 is dispatched to it in the same wave.
• Prior art: POST /api/v1/packages is a publish-vs-install shape collision — REST registers first and shadows the dispatcher (#3587 finding) #3610 / PR fix(rest,client)!: reconcile the two REST↔client mismatches the audit ledgered (#3610, #3611) #3621 moved publish onto /packages/publish in the first place. This is not a regression of that fix — it is the residue it did not cover: what the /packages prefix answers on a host where only one of the two owners is mounted. Say which of the two outcomes you chose and why.
• Tier / container: M · claude-opus-5 · mode:cloud.

---

Generated by Claude Code