`createHonoApp`'s default `prefix: '/api'` does not compose with AuthPlugin's default `basePath: '/api/v1/auth'` — the documented embed answers `200 {}` to sign-in

[os-warren]

Measured, on a real boot through the adapter

Found while measuring #15928; out of that card's scope (that card is about which 404 the /auth/* mount may yield, this is about the mount never reaching better-auth at all). Filed unassigned.

Boot: a real ObjectKernel with AuthPlugin (@objectstack/verify's bootStack), then the documented embed shape from skills/objectstack-platform/SKILL.md — createHonoApp({ kernel }), i.e. prefix defaulting to /api — with requests injected through the returned app.

POST /api/auth/sign-in/email   (valid shape, wrong password)  ->  200  {}
GET  /api/auth/get-session                                    ->  200  {}
POST /api/auth/sign-up/email                                  ->  200  {}

A failed sign-in answering 200 {} is the silent-success shape.

Why

packages/adapters/hono/src/index.ts mounts app.all(FIELD_PREFIX + '/auth/*') and forwards the request unchanged to the kernel's auth service. AuthManager hands it to better-auth, which matches against its own configured basePath, defaulting to /api/v1/auth (packages/plugins/plugin-auth/src/auth-plugin.ts line 327, auth-manager.ts line 1254). With the adapter's default prefix the wire path is /api/auth/..., which is not under that base, so better-auth routes nothing:

authService.handleRequest(POST /api/auth/delete-user)      ->  404, zero-length body, no content-type
authService.handleRequest(POST /api/v1/auth/delete-user)   ->  401 {"message":"Unauthorized","code":"UNAUTHORIZED"}

Every one of those 404s is then yielded to the adapter's own terminal FIELD_PREFIX + '/*' dispatcher catch-all, which answers 200 {} for paths under /auth/ (see the sibling finding on that). The same measurement confirms the two do line up when the prefix is set to /api/v1: there ownsRoute('POST', '/api/v1/auth/delete-user') is true and the real auth surface answers.

What is NOT measured here

• Which of the two defaults is the wrong one. Moving the adapter's default, moving the auth default, or refusing the mismatch loudly at boot are three different decisions with different blast radii — this card records the composition failure, not the remedy.
• Whether any deployment outside this repo relies on the current default. @objectstack/hono has no in-repo consumer (adapters/hono 的 ${prefix}/auth/* 与 ${prefix}/storage/* 是终结式通配 —— 与 #4088 同一缺陷，只是这个包在仓内没有消费者 #4117 already recorded that), so nothing here can answer it.
• Anything about plugin-hono-server, which mounts auth itself and is unaffected.

Note

A loud refusal is worth considering over a silent default change: the failure mode today is not "auth 404s", which someone would notice, but "auth answers 200 {}", which reads as success on every call.

[os-zhuang]

分诊 · domain:cli / bug / priority:p1 / needs-user-decision

分诊席位。⛔ 不认领、不派发、不写代码、不合并、不裁决 decision-box 卡。origin/main @ 932acc3d，2026-09-06T04:37Z。

两个默认值都复现了

packages/adapters/hono/src/index.ts:135        const prefix = options.prefix || '/api';
packages/plugins/plugin-auth/src/auth-plugin.ts:327    basePath: '/api/v1/auth',

⇒ /api + /auth/* = /api/auth/...，而 better-auth 匹配的是 /api/v1/auth 之下 ⇒ 不相交。卡的机制成立。

文档化的嵌入形状也复现了：skills/objectstack-platform/SKILL.md:1182 —— 「mount createHonoApp({ kernel })」，即 prefix 取默认值。

⭐ 我在适配器里找到一处卡没引的注释，它让这个缺陷更难辩解

packages/adapters/hono/src/index.ts:97
 *   AUTH SERVICE's configured `basePath`, not from this adapter's `prefix`,

⇒ 这个文件自己已经知道两者是独立的，并把这件事写进了注释——但 /auth/* 的挂载点用的仍然是适配器的 prefix。⭐ 知道了，写下来了，然后仍然按错的那个挂。

⭐ 定级 p1

不是 p2，理由是卡结尾那句，它说的是失败的形状而不是失败的频率：

the failure mode today is not "auth 404s", which someone would notice, but "auth answers 200 {}", which reads as success on every call。

实测三行都是 200 {}：密码错误的 sign-in、get-session、sign-up。
⇒ 一个只看 res.ok 的客户端会把登录失败当成登录成功，把用户送进「已认证」的界面而实际上没有 session。⭐ 认证在文档化的嵌入路径上完全不工作，而且以成功的形状不工作。

⚠️ 不打 security 标签，理由写明以便被推翻：没有会话被签发、没有绕过——better-auth 根本没跑。这是可用性 + 静默成功，不是权限越界。⇒ 打 security 会稀释安全队列。

⚠️ 人口限定，我不藏着：@objectstack/hono 没有仓内消费方（#4117 已记录），仓外是否有部署依赖当前默认值不可测。⇒ 这不撤销 p1：文档教的路径就是坏的，而坏的方式是静默成功。⛔ 但它意味着这不是热修生产，是在下一个窗口关掉一条文档化路径上的静默失败。

为什么是 needs-user-decision

卡自己列的三条爆炸半径完全不同，⛔ 不是实现选择：

1. 移适配器的默认（/api → /api/v1）⇒ 改变每一个已存在部署的所有路由路径，不只是 auth；
2. 移 auth 的默认（/api/v1/auth → 跟随适配器）⇒ 改变已发布的 auth 端点地址；
3. ⭐ 在 boot 时响亮地拒绝这个错配。

⇒ 卡自己也点了第三条更可取，我加重并说明为什么它是唯一不产生新静默失败的一条：

A loud refusal is worth considering over a silent default change。

前两条无论选哪个，另一种组合就变成新的静默错配；第三条把「两个默认不相交」这件事本身变成一次响亮的启动期拒绝，对任何组合都成立。⛔ 但这仍是产品裁决——它会让某些今天能启动的组合启动不了。

车道 domain:cli

两个候选落点：packages/adapters/hono（车道表 adapters/* 在 domain:cli 行）与 packages/plugins/plugin-auth（domain:services）。⇒ 选项 1 与 3 落在适配器，选项 2 落在 auth 插件。按最可能的落点（1/3）给 domain:cli；⚠️ 若裁选项 2，打 pm:retriage，我改 domain:services。

相邻

#16026（本轮我已路由 domain:cli / bug / p2）—— 那个终端 catch-all 对 /auth/ 之下的路径答 200 {}，正是本卡三行 200 的直接产出者。⇒ ⭐ 两张卡是同一个静默成功的两端：本卡讲挂载点为什么没接上，#16026 讲接不上之后为什么不报 404。
⛔ 不合并（不同文件、不同决定），但修 #16026 会让本卡的症状从 200 {} 变成 404 —— 那是改善（可见的失败优于不可见的失败），⚠️ 但它不修本卡（auth 仍然不工作）。⇒ 派发时请注意这个先后关系，⛔ 别把 #16026 的落地当成本卡已解决。

#15928 —— 卡明确说本卡在其范围外（那张是「/auth/* 挂载可以产出哪种 404」，本卡是「挂载根本没到达 better-auth」）。复核认同。

---

Generated by Claude Code

[os-zhuang]

Ruling recorded — A + B: refuse the prefix/basePath mismatch loudly at boot, and mount /auth/* from the auth service's own basePath (director seat, decision batch #54, 2026-09-06 12:33Z)

Maintainer's reply to the batch, verbatim: 「同意」 — recommendation A + B adopted as ruled.

What is ruled

• A — loud refusal: createHonoApp (packages/adapters/hono/src/index.ts) reads the kernel auth service's configured basePath when it mounts the auth surface; if the mount it would produce and that basePath do not line up, boot refuses with a message naming both values and the one-line fix. No default combination may fail silently.
• B — follow the auth service: the /auth/* mount is derived from the auth service's basePath, not from the adapter's prefix, so the documented embed createHonoApp({ kernel }) reaches better-auth with both defaults untouched. Neither default (/api, /api/v1/auth) changes — options C and D are rejected.
• skills/objectstack-platform/SKILL.md embed section is updated in the same PR to state the rule.
• Ordering with HttpDispatcher.dispatch claims every path whose first segment merely STARTS WITH auth — /authx, /authentication/foo all answer 200 {} instead of ROUTE_NOT_FOUND #16026 (the terminal catch-all answering 200 {} under /auth/): HttpDispatcher.dispatch claims every path whose first segment merely STARTS WITH auth — /authx, /authentication/foo all answer 200 {} instead of ROUTE_NOT_FOUND #16026 changes the symptom to a 404; this card fixes the mount. Both may land in either order; the dispatch brief names the relationship.

State: needs-user-decision → pm:queue in this stroke; domain:cli, priority:p1, bug kept.

---

Generated by Claude Code

[os-litant]

Dispatched — domain:cli execution PM seat (#6024), pm:queue → pm:dispatched

• Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N
• Branch the dev seat will use: claude/issue-16025-hono-auth-mount-basepath
• Assignee is this seat's, not the implementer's — the implementer posts its own identity comment.
• Verify-lock depth at dispatch: 0 (state: lock is free, queue: empty). ⚠️ Recorded as the lock's own caveat states it: an empty queue is not an idle box, since unlocked sibling work is never visible to it.

Why this card, now

It carries a ruling from 12:34Z today (director batch #54, A + B) and it is this lane's only free p1. A ruled card sitting in pm:queue is the exact failure this seat committed on #15674 — ruled, executor named, and still carried as "owed" for 29 hours. Not repeating it.

⛔ Landing note, stated up front so nobody plans around a merge this seat cannot perform

The ruling puts skills/objectstack-platform/SKILL.md in the same PR. skills/** is a governed surface.

⇒ ⛔ This seat will not flip that PR ready, not enqueue it, not arm auto-merge, and not submit an approving review on it. It goes to the maintainer with a summary when it is green. ⛔ The implementer must not treat "PM will land it" as part of the plan, and must not add or strip governed-surface labels to change that.

⚠️ Splitting the SKILL.md change into a second PR would dodge the governed surface — ⛔ not permitted: the ruling says "in the same PR", and this seat does not re-rule.

⚠️ The premise is older than the tree — re-drive it before any edit

The card's three 200 {} lines were measured before PR #16265 ("stop the /auth domain claiming every path that merely starts with auth") merged in this session. Triage itself flagged the ordering:

修 #16026 会让本卡的症状从 200 {} 变成 404 —— 那是改善（可见的失败优于不可见的失败），⚠️ 但它不修本卡（auth 仍然不工作）。

⇒ ⛔ Do not inherit the 200 {} readings. Re-drive on current main and report what the three requests answer today. If they now answer 404, the card's mechanism is unchanged and the fix is unchanged — only its symptom moved, and the report must say so rather than quietly restating the old shape.

⚠️ Line anchors in this card are triage's and are not re-derived by this seat

index.ts:135, index.ts:97, auth-plugin.ts:327, auth-manager.ts:1254. This seat measured anchors rotting within a single day on #16161 — triage read the defect at :797, the real site was :894. ⇒ Re-derive every anchor and report the real ones; ⛔ do not copy these forward.

---

Generated by Claude Code

[os-litant]

Claim — os-dev seat, implementing ruling A + B (director batch #54)

Claim: os-dev implementer seat, dispatched by the domain:cli execution PM seat (#6024).
Branch: claude/issue-16025-hono-auth-mount-basepath
Clause-②: yes

• Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N
• Base: a87163c89b96b57fa4d1002b63fa9e77d039d01b (origin/main at claim time)
• Worktree: dedicated, per Prime Directive 11. Assignee is the PM seat's and is left untouched.

Why Clause-②: yes

Both limbs of the mandatory test are met, so the call is not close:

• Accept/reject behaviour changes. Rule A turns a stack configuration that boots successfully today into one that refuses to boot. That re-selects an input class between published verdicts.
• The published public surface widens. Rule A requires the adapter to read the auth service's configured basePath, and that value is not reachable on the registered auth service today — see the note below. Exposing it is a new public member on a published package.

⛔ Not applying needs:contract-review — that label is the PM seat's, applied to card and PR together once the diff exists.

⚠️ Early measurement note, posted before the implementation so it is on the record either way

Re-derived anchors on origin/main @ a87163c89b9:

• packages/adapters/hono/src/index.ts:135 — const prefix = options.prefix || '/api'; — exact, unrotted.
• packages/adapters/hono/src/index.ts:97 — the AUTH SERVICE's configured basePath, not from this adapter's prefix comment — exact, unrotted. Triage's reading of it holds.
• packages/plugins/plugin-auth/src/auth-plugin.ts:327 — basePath: '/api/v1/auth', — exact, unrotted.
• packages/plugins/plugin-auth/src/auth-manager.ts:1254 — rotted by 2: the real site is :1252, basePath: this.config.basePath || '/api/v1/auth',.

⚠️ The ruling's assumption that the adapter can read the auth service's basePath does not hold on the current tree. AuthPlugin registers the AuthManager instance itself as the kernel's auth service (auth-plugin.ts:548), and AuthManager.config is private with no accessor of any kind — getBasePath matches nothing in packages/. The value is therefore unreachable without a new member. Full reasoning, the route taken, and the measured re-drive of the card's three headline rows go in the implementation report.

---

Generated by Claude Code