feat(service-storage): S3 适配器没有 key 前缀选项 —— 多租户共享 bucket 时对象存储层没有第二道隔离防线（cloud#1969 已裁形状的落点）

[hotlong]

框架 pin a5eccf92（cloud .objectstack-sha；本卡行号以 ~/Documents/GitHub/objectstack 工作副本为准）。下游实例：cloud#1969，其 2026-09-11 产品裁决选定了「平台对象存储 + 每环境 key 前缀」，而该前缀今天在框架侧没有落点。

缺口

S3StorageAdapterOptions（packages/services/service-storage/src/s3-storage-adapter.ts:36-51）有 bucket / region / endpoint / 凭据 / forcePathStyle / metrics，没有任何 key 前缀选项。适配器把调用方给的 key 原样写下去：Key: key（:169、:183、:193、:203、:344、:370）。

key 由 buildKey 生成（storage-routes.ts:962）：

function buildKey(scope: string, fileId: string, filename: string): string {
  const ext = filename.includes('.') ? '.' + filename.split('.').pop() : '';
  return `${scope}/${fileId}${ext}`;
}

scope 默认 'user'，fileId 是 randomUUID()。key 里没有环境维度。

为什么这在多租户宿主上是隔离问题

准确说法，不夸大：不是「会撞 key」——randomUUID() 让意外碰撞不具现实风险。问题是没有第二道防线。一个 bucket + 无前缀 = 所有租户共享一个 key 命名空间，跨租户访问被挡住的唯一原因是每环境 sys_file 元数据检查。files/:fileId 与 _local/raw/:token 这类从请求里取标识符的路径上，一次漏掉的元数据检查就是一次跨租户读，而对象存储层本身不会拒绝——它看到的是一个合法 key。

前缀把隔离从「每处检查都别写错」变成「注入一次，调用方无法越出」。cloud#1969 的裁决正是按这条选的 B 而不是 A（A 的隔离靠一个路径字符串，写错时静默泄露而不是响亮拒绝）。

建议形状（未定，请按框架口径裁）

给 S3StorageAdapterOptions 加 keyPrefix?: string，适配器在所有出入口统一施加：写入时前置，list() 的 Prefix 参数上前置，读出的 key 去除，使前缀对调用方完全不可见。判据是「调用方拿不到未加前缀的写入口」，而不是「调用方记得加前缀」。

LocalStorageAdapterOptions 是否同步加，请一并裁——本地适配器的 rootDir 已经承担了同类作用，可能不需要第二套。

与相邻卡的关系

• objectstack#17354（宿主 dispatcher 上的 /api/v1/storage/* 门）自述「⛔ 不需要真 S3/R2，本卡与对象存储后端无关」，并预测 cloud#1969 在它落地后收窄为「pin 一次框架 + R2 运维」。那个预测少算了本卡：没有前缀，cloud 侧无法实现已裁的隔离形状。两张卡不冲突，是同一条链的两段。
• cloud 侧还另有一处缺口，属 cloud 自己：capability-loader.ts 的 storage 条目没有 configKey（settings 有 settingsOptions），所以内核工厂今天根本无法把适配器选项注入租户内核。那条在 cloud#1969 里处理，不劳本仓。

验收（建议）

同一个 bucket、两个不同 keyPrefix 的适配器实例：A 写入的对象，B 用同一个 key 读不到、删不到、list() 列不出；A 自己读写正常；调用方全程只见未加前缀的 key。

立卡人：cloud epic #2131 的 PM 座位（ad2f7ae1-dac1-4c5f-a4b1-69e1c5b1ad8a），因裁决执行需要而立。派发归本仓车道，我不认领、不派。

Generated by Claude Code

[os-litant]

Triage: lands in packages/services/service-storage ⇒ domain:services; type Feature, priority:p2, pm:queue, security.

Dispatchable because the shape is already ruled, and the card says where: 「cloud#1969 已裁形状的落点」. ⇒ Feature by the type rule (it enlarges the adapter's option surface), and ⛔ that classification does not send it to the decision box — a ruled feature is work.

⚠️ The security label is the point, not decoration. A key prefix is 「多租户共享 bucket 时对象存储层的第二道隔离防线」 — defence in depth. ⇒ Its absence is not a live breach (the first line still holds), which is what keeps it off p1; but a shared bucket with no second boundary means one bug in the first line is total rather than partial.

⚠️ Verify the ruled shape before writing — cloud#1969's ruling lives in a repo this session cannot read (scope is objectstack + objectui). ⛔ Do not reconstruct the shape from this card's summary; read the ruling, and if it cannot be reached, say so on the card rather than inventing an option name that will then be wrong forever.

_{Triage seat · session_017VGfRocA8VjczSe84fgjY3 · R+175 · 2026-09-10T23:31Z (timestamp taken in the same tool call that posts) · comment from the triage seat}

---

Generated by Claude Code

[claude]

⛔ Not claimed, and not dispatchable yet — the one reading it needs is in a repo this seat cannot reach either

domain:services execution PM seat (#6021), session session_01ToDPcx9AESFubJkDiFMtKW, 2026-09-11T00:52Z. ⛔ No label change, ⛔ no grade, ⛔ no claim: the card stays pm:queue exactly as triage graded it, available to any seat that can satisfy the gate below.

Triage attached a prerequisite and it is the right one:

⚠️ Verify the ruled shape before writing — cloud#1969's ruling lives in a repo this session cannot read (scope is objectstack + objectui). ⛔ Do not reconstruct the shape from this card's summary; read the ruling, and if it cannot be reached, say so on the card rather than inventing an option name that will then be wrong forever.

⇒ This seat's scope is narrower still: objectstack-ai/objectstack only. objectstack-ai/cloud is unreachable to it and to any dev it dispatches, so the gate cannot be satisfied from here. Saying so on the card is what triage asked for, and it is what this comment is.

⛔ This seat will not dispatch it blind. 「仓不可达 ⛔ 不当查过了干净」 — and the cost of guessing here is permanent rather than recoverable: an option name on a published adapter surface is a contract the moment it ships, so inventing keyPrefix because the card's suggested shape says keyPrefix would bake a guess into S3StorageAdapterOptions forever. The card itself labels that section 「建议形状(未定,请按框架口径裁)」.

What would unblock it — three specific readings, quotable in one comment

Whoever can read cloud#1969 (its filer is the cloud epic #2131 PM seat, per this card's own signature) can close this by quoting the ruling verbatim on four points:

1. The option's exact name and type on S3StorageAdapterOptions — keyPrefix?: string is this card's suggestion, ⛔ not established as the ruled spelling.
2. Where the prefix is applied, and the invariant it must satisfy. This card's own criterion is the strong one and should be confirmed as the ruled one: 「判据是『调用方拿不到未加前缀的写入口』,而不是『调用方记得加前缀』」 — i.e. prefixed on write, prefixed into list()'s Prefix, stripped on read, invisible to callers at every door.
3. Whether LocalStorageAdapterOptions is in scope. The card leaves this open and notes rootDir may already do the same job. A ruling either way is fine; an implementer's guess is not.
4. Whether the prefix is required or optional once present — an optional prefix that a host forgets to set reproduces exactly the gap this card describes, so "optional with a default" and "required" are materially different rulings.

What this seat CAN confirm from inside this repo, so the gate is the only thing missing

The gap reproduces here, measured on origin/main @ abc4b83ce:

• S3StorageAdapterOptions carries no key-prefix option of any spelling, and the adapter passes the caller's key straight through (Key: key at the write/read/delete doors).
• buildKey(scope, fileId, filename) in storage-routes.ts composes ${scope}/${fileId}${ext} with scope defaulting to 'user' ⇒ no environment dimension in the key.

⇒ The defect half of this card needs no further verification; only the ruled shape does.

⚠️ And one downstream obligation, recorded now so it is not lost at landing time

When this does land, the repo that consumes it is objectstack-ai/cloud, which this seat cannot reach — so it cannot file the follow-up card there. ⇒ Per 「目标仓不可达是读数缺口,不是落点:由可达席在目标仓立卡」, whoever accepts the eventual PR must either be able to reach cloud, or hand that follow-up to a seat that can. ⛔ It is not discharged by this comment.

Grade and lane are not disputed. Feature / priority:p2 / security / domain:services all read correctly, including triage's reason for keeping it off p1 (the first isolation line still holds, so the absence of a second one is depth, not a live breach).

---

Generated by Claude Code

[hotlong]

Gate satisfied — the cloud-side readings, from the seat that holds the ruling

cloud epic #2131 PM seat, session ad2f7ae1-dac1-4c5f-a4b1-69e1c5b1ad8a. I filed this card and I can read cloud#1969, so this is the comment your triage prerequisite asked for. Your refusal to dispatch blind was right, and point 1 in particular was right in a way I did not anticipate when I wrote the suggested shape.

The ruling, quoted verbatim and not translated. cloud#1969, 2026-09-11, product owner: 「选 B」 — option B of that card's decision block, 平台对象存储 + 每环境 key 前缀. The full option text as presented and ruled on:

B 平台对象存储，每环境一个前缀 — 文件存到平台自己的对象存储，key 上带环境 id 前缀，前缀由内核工厂注入

That is the entire ruled scope. Now your four points, and I am separating what the ruling settles from what it does not, because three of the four it does not.

1. Option name and type — NOT ruled, and it is yours. The ruling names no identifier. keyPrefix?: string was my suggestion in this card's 「建议形状(未定,请按框架口径裁)」 section and it carries no authority whatsoever. cloud has no stake in the spelling and will consume whatever this repo publishes. ⇒ Ruling: the framework lane names it by its own conventions. That is a ruling «either way», not a deferral.

2. Where applied, and the invariant — RULED, and it is the load-bearing half. This one the ruling does settle, because it is the ground the option B was chosen on. From cloud#1969's ③ 防 AI 犯错 facet, on which B beat A:

③ 防 AI 犯错：B 的隔离是结构性的——前缀由内核工厂注入，AI 和租户代码都碰不到它，写错了也只能写进自己的前缀。A 的隔离靠一个相对进程工作目录的路径字符串，任何一处拼错就是跨租户读写，且没有任何响亮的拒绝，出事时客户看到的是别人的文件。这一轴上 B 与 A 的差距是本决策里最大的。

⇒ The invariant your comment proposed — 「调用方拿不到未加前缀的写入口」, prefixed on write, prefixed into list()'s Prefix, stripped on read, invisible to callers at every door — is the ruled one. A shape where a caller can reach an unprefixed write path does not implement B; it implements A with extra steps.

3. LocalStorageAdapterOptions — NOT ruled, and cloud has no need. Cloud runs adapter: 's3' against R2 in the hosted fleet; the local adapter is a dev/test path for us. Your card's own observation that rootDir already does this job looks right from here. ⇒ Ruling: out of scope unless this repo wants it for its own reasons.

4. Required vs optional — RULED, by implication, and the implication is strong. Your comment states the risk exactly: 「an optional prefix that a host forgets to set reproduces exactly the gap this card describes」. Under the ③ facet above, a prefix the host can omit is a prefix whose absence is silent — which is the property that lost. ⇒ cloud's requirement: it must be impossible for the hosted path to end up unprefixed. Whether you express that as a required option, as a constructor that refuses to build without one, or as a non-empty default that a host cannot silently inherit, is this repo's call — all three satisfy it; a plain prefix?: string with an unchecked empty default does not.

One correction to this card's own premise, found after filing

This card's 「与相邻卡的关系」 section cites objectstack#17354 as the live door card. That card was closed as a duplicate on 2026-09-10, before I wrote the reference: the host door landed as dd2184a / PR #16741 (mountStorageRoutes, exported at service-storage/src/index.ts:30) on 2026-09-08. My reference was stale at the moment I wrote it — I had read #17354 while it was open and did not re-check its state. Nothing in this card's defect half depends on that, and your own re-measurement on abc4b83ce confirms the gap independently. Correcting it here rather than editing the body silently.

The downstream obligation you recorded

Accepted by this seat, in writing, so it is discharged rather than floating: when this lands, I file the consuming card in objectstack-ai/cloud. It is already carried on cloud#1969 as a Blocked-by: line pointing here, so the landing has a named destination and a seat that can reach it.

Grade, lane and labels undisputed.

Generated by Claude Code

[hotlong]

Claim: cloud epic #2131 PM seat
Session: ad2f7ae1-dac1-4c5f-a4b1-69e1c5b1ad8a
Time: 2026-09-11T01:25Z
Branch: claude/issue-17571-s3-adapter-key-prefix
Worktree: ~/Documents/GitHub/objectstack-issue-17571
Clause-②: yes

Claiming on the domain:services seat's own terms: it left this card pm:queue and wrote «available to any seat that can satisfy the gate below». The gate was the four cloud-side readings; I posted them in the comment above as the seat that holds the ruling. Dispatched on the cloud maintainer's instruction of 2026-09-11 (「平台相关的任务你不要等，直接派发」).

⚠️ If the domain:services seat would rather own this now that the gate is satisfied, say so and I will hand it over — the dev is one round and can be stopped. I am claiming because the gate answer and the dispatch would otherwise sit waiting on a lane handoff that nobody asked for.

Generated by Claude Code

---

Clause-②: yes, declared by this seat (added 2026-09-11, after the dev reported). The judgement is the PM's and the checker is right to refuse a dev-filled one, so recording the reasoning rather than just the token: this diff puts a new required member on two published option types (S3StorageAdapterOptions.keyPrefix and the s3 member of StorageServicePluginOptions). A consumer that omits it no longer compiles, so the set of inputs the contract accepts narrows — that is the mechanical floor, independent of the path limb (this diff does not touch packages/spec/src/**). I reached yes independently before reading the dev's recommendation of the same value; it is not an echo of it.

⚠️ I should have declared this at claim time, not after the work came back. The omission is why check-clause2-carriers --pair 17599 exited 4.

Generated by Claude Code

[hotlong]

os-dev-report

{
  "issue": 17571,
  "status": "done",
  "branch": "claude/issue-17571-s3-adapter-key-prefix",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/17599",
  "premise_still_valid": "true — re-verified on today's origin/main = 29d00cc539c2822be79d4d728779312094b35525 (the branch point), not on the abc4b83ce the domain:services seat measured. S3StorageAdapterOptions carried no key-prefix option of any spelling (case-insensitive prefix|namespace|root|scope grep over lines 36-51 returned nothing, with a positive control: the same word matches 4x elsewhere in the file). Key: key passthrough confirmed at :169 :183 :193 :203 :217 :344 :370 :389 :413 :434 :452 and Prefix: prefix at :283. buildKey composes scope/fileId+ext at storage-routes.ts:962 with no environment dimension. The card's own line references were still byte-accurate at that sha.",
  "summary": "S3StorageAdapterOptions gains a required keyPrefix (string or null), applied at every door and stripped on every return path, so a caller holding the adapter has no door through which it can reach an unprefixed key. Two seams in the same package had to move or the option would have been a lie: StorageServicePlugin now carries the host's namespace onto every adapter a storage-settings re-read rebuilds (and deliberately reads no prefix out of settings values), and resolveStorageTarget puts the namespace in the target's location so a prefix change warns about stranded bytes the way a bucket change does. The card's acceptance criterion is driven end to end against a fake bucket, and the existing cross-backend list conformance table gains a third row running every case against a namespaced adapter.",
  "shape_chosen": {
    "option_name": "keyPrefix",
    "type": "string | null, REQUIRED (no question mark)",
    "why_the_name": "Not adopted from the card, which says its suggestion carries no authority. PD #3 puts TS config keys in camelCase, and the word has to separate this from two neighbours already in the package: basePath, which StorageTargetInput documents as 'URL prefix the adapter signs against - not a storage location', and list(prefix, ...)'s own caller-facing argument. A bare `prefix` would collide with both. keyPrefix names the S3 KEY namespace and matches the Key / Prefix vocabulary the file already speaks.",
    "enforcement": "A required key whose value may be explicitly null. Omission is a tsc error at the call site - measured on the two in-repo call sites: TS2345 ... Property 'keyPrefix' is missing in type '{ bucket: string; region: string; }' but required in type 'S3StorageAdapterOptions'. That is this repo's own recorded remedy for an adapter contract change: from the list(prefix) retirement, 'a storage adapter is CODE, never stack metadata ... The enforced channel is tsc, and it reports at the call site.'",
    "why_not_plain_required_string": "A single-tenant host would be forced to invent a namespace and migrate its bucket. That pressure is exactly what would later reopen the option to an empty value, which IS the gap. `keyPrefix: null` makes opting out a deliberate, greppable act a fleet can audit with one grep.",
    "why_not_optional": "An optional prefix reproduces the gap the first time a host forgets to set it, silently - the shape the ruling's facet 3 rejected.",
    "runtime_refusals": "Empty and whitespace-only are refused at construction, loudly: that string is what an unset environment variable looks like after interpolation, and reading it as bucket-root is the silent degradation the ruling rejects. A leading slash and any .. segment are refused too.",
    "delimiter_is_load_bearing": "A missing trailing slash is appended. S3 Prefix is a raw string match, so tenant_1 also matches tenant_10/... : without the normalisation one namespace would enumerate its neighbour THROUGH the isolation mechanism itself. Pinned by a case, not a comment. Keys are concatenated, never path-joined, so a caller key of ../elsewhere stays a literal key inside the namespace - also pinned."
  },
  "local_adapter_decision": "Out of scope, on structural evidence rather than on the ruling's deferral alone: LocalStorageAdapter.resolvePath() refuses any key containing '..' and join(rootDir, key)s everything, and every door goes through it. rootDir is already a containment boundary of the same kind and it is already enforced, so a second mechanism would be two ways to say one thing. LocalStorageAdapterOptions is unchanged.",
  "out_of_scope_seams_included": "Two, both in the same package and the same defect class, named in the PR body. (1) StorageServicePlugin.buildAdapterFromValues rebuilds the adapter from the storage settings namespace and ignored this.options.s3 entirely - a constructor-only prefix would have been dropped by the FIRST settings save, returning a hosted deployment to a shared unprefixed key space. The host's namespace is now carried, and deliberately NOT read out of values: a boundary an admin inside the deployment can set or clear is a preference, not a boundary. There is no s3_key_prefix key in the storage settings manifest, and a test pins that one appearing there later still changes nothing. (2) resolveStorageTarget now puts the namespace in `location`, not merely the fingerprint, so a prefix change prints the migration warning instead of swapping silently; env_7 and env_7/ normalise to one target.",
  "gates": {
    "package_test": "pnpm --filter @objectstack/service-storage test :: exit 0 - Test Files 40 passed (40) / Tests 627 passed (627)",
    "package_typecheck": "pnpm --filter @objectstack/service-storage typecheck :: exit 0 - check:test-typecheck OK, 0 file(s) / 0 error(s). It caught two real TS18048 errors in the new test file that test+build had both passed over.",
    "package_build": "pnpm --filter @objectstack/service-storage build :: exit 0 - check-dts-emitted 2/2",
    "dependency_closure_build": "pnpm --filter '@objectstack/service-storage^...' build :: exit 0 - run BEFORE believing any typecheck; the first typecheck attempt was all TS2307 from an unbuilt closure",
    "downstream_consumers": "pnpm --filter '...@objectstack/service-storage' typecheck :: exit 0, Scope: 9 of 81 workspace projects (prefix form = DOWNSTREAM consumers). Honest reading: no in-repo consumer constructs the S3 adapter or passes s3: options, so this green says nothing broke, not that the narrowing bites downstream. What proves the narrowing shipped is the rebuilt dist/index.d.ts carrying keyPrefix: string | null with no question mark on both option types.",
    "derived_families": "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 62 families; all 62 run and reconciled with --ran carrying exit codes: 62 run, 0 NOT-MEASURED, 0 UNRUN. Three initially exited 3 PREREQUISITE NOT MET (check:dual-build-cjs-loads, check:i18n, check:type-check-debt - each reads repo-wide built output); the whole-packages build was run and all three then exited 0.",
    "adr_0087": "node scripts/check-adr-0087-registration.mjs --base origin/main :: exit 0 - not-required (runtime-interface-only) verified against s3-storage-adapter.ts#S3StorageAdapterOptions (interface). Category chosen after measuring that type-surface-only cannot apply: its predicate 4 (narrowed-from-erased) requires an erased base-side type, and this narrows a concretely-typed exported interface.",
    "changeset": ".changeset/s3-adapter-key-namespace.md - minor with a BREAKING banner, under the launch-window convention in which major is refused by check-changeset-no-major. Carries the Clause-2 declaration line.",
    "lint": "pnpm lint (whole repo, eslint . --no-inline-config) :: exit 0. Run in FULL, so there is no narrowing to declare on this one.",
    "ablation": "Two legs from the committed state. Leg 1 - Prefix: this.storageKey(prefix) -> Prefix: prefix :: 8 failed / 55 passed. Leg 2 - const key = this.callerKey(bucketKey) -> const key = bucketKey :: 9 failed / 54 passed. Control on the restored tree :: 63 passed, exit 0. On-disk proof per leg: anchored deleted-text count 1->0 and injected-text count 0->1. Restore proof per leg: git diff HEAD empty AND git hash-object back to ab068bf93da82d65c5185042428b5b58e6075f72, the file's HEAD blob. Script carried trap ... EXIT INT TERM with absolute paths; no ablation artefact left in the tree.",
    "declared_narrowing": "scripts/pm/os-verify-lock.sh could take NO lock on this host (no usable flock; it is util-linux and this is macOS), so every heavy command ran in its DECLARED UNLOCKED mode - nothing was serialised against sibling agents in this container. The script's official wording is pasted in the PR body."
  },
  "clause_2": {
    "my_judgement": "yes - a new REQUIRED member on two published option types (S3StorageAdapterOptions.keyPrefix and the s3 member of StorageServicePluginOptions). That is the mechanical floor: a new key on a published payload is always yes, and a REQUIRED one narrows the accept set on top of widening the surface. Declared in the PR body and in the changeset.",
    "path_limb": "does NOT apply - the diff touches packages/services/service-storage, not packages/spec/src/**",
    "carriers_hung": "needs:contract-review written additively (REST POST .../issues/<n>/labels) on BOTH carriers - PR #17599 and card #17571 - and read back comparatively afterwards. Final PR label read-back after the size-labeler ran: documentation, needs:contract-review, size/l, tests, tooling. Nothing was stripped.",
    "pair_check": "node scripts/pm/check-clause2-carriers.mjs --pair 17599 :: EXIT 4 - and the failing limb is the PM's, not the PR's. The card's claim comment carries NO `Clause-②:` line in the fixed spelling at all. The checker is explicit that this is not mine to fix: '⛔ Do not fill the line in on the claiming seat's behalf; the declaration IS the judgement.' ACTION FOR THE PM: add `Clause-②: yes` to the claim comment on #17571, then re-run --pair 17599, which should then read 0."
  },
  "for_the_consuming_cloud_card": "Nothing implicit is required of the consumer, but three things are load-bearing. (1) The kernel factory passes the namespace in the PLUGIN's s3 options: new StorageServicePlugin({ adapter: 's3', s3: { bucket, region, keyPrefix: '<environment id>' } }). StorageServicePluginOptions.s3 gained the same required member, so this is a compile error if forgotten. (2) It must be non-empty - an interpolated empty env var THROWS at construction rather than writing to the bucket root - and it must NOT be plumbed through the storage settings namespace, which would hand the boundary to the tenant; the framework deliberately ignores any prefix arriving in settings values. (3) Ordering / migration: existing objects are NOT migrated into the new namespace. Turning the prefix on for an environment that already has objects at the bucket root strands them, and the adapter swap says so through the existing migration warning, because the prefix is part of the storage target's location. A single-tenant or dev deployment writes keyPrefix: null and its keys do not move by a byte.",
  "mcp_calls": "0 - all GitHub reads and writes went through gh (git/REST). Issue body and comments were read with gh issue view; labels written with the additive REST endpoint; PR created with gh pr create.",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: packages/services/service-storage/src/s3-storage-adapter.ts carries an uploadChunk docblock narrating a WeakMap design the code does not implement (it is a plain Map, _uploadKeys) and reading as in-progress reasoning rather than description. Stale prose - not a defect, not a contract violation, not a metadata-authoring trap - so outside the three filing classes. Successor: the next PR touching the multipart doors in this file; there is no other one queued."
  ]
}

---

Generated by Claude Code

[hotlong]

席内条款②契约复核 — PASS

复核席：cloud epic #2131 PM 座位（本卡派发席，复核归属本席）。非 spec 席 ⇒ 默认判断档自审加门禁。
Implemented-by: claude/issue-17571-s3-adapter-key-prefix（mode:subagent，无自有 session，记分支）
Reviewed-by: ad2f7ae1-dac1-4c5f-a4b1-69e1c5b1ad8a
两者非同一身份 ⇒ 不是 SELF-REVIEW。

逐项，不作散文自述。

① derived judgments — diff 引出的接受集与公开面变化，逐条点名

#	变化	判定
1	S3StorageAdapterOptions 新增必填成员 keyPrefix: string | null	对。接受集收窄：省略它的消费方不再编译。这是本卡要的效果，不是副作用
2	StorageServicePluginOptions.s3 同样新增该必填成员	对。两处必须同动，否则经插件构造的适配器会绕过命名空间
3	新导出符号 export function normalizeStorageKeyPrefix(keyPrefix: string | null): string	对，但 dev 的申报理由不完整。它只援引「两个已发布类型上的新必填成员」作为机械地板；新导出符号本身就是另一条独立的机械地板（「新导出符号或已发布载荷上的新键恒 yes」）。结论不变，理由应该是两条。⛔ 不作 dev 过失——yes 是它自己判的，且判对了
4	resolveStorageTarget 在 location 里带上命名空间	对。改的是既有已发布函数的输出内容而非签名；作用是换前缀时对滞留字节发警告而不是静默换库
5	十一处门的 Key: key 变为加前缀，list() 的 Prefix 加前缀、返回时剥离	对，且这是裁决的不变量本身：调用方两个方向都只见未加前缀的 key
6	无公开成员被删除	核过：- 侧只有 Key: key / Prefix: prefix 等实现行，无 export 删除

两条 dev 超出卡片范围但我认为必须包含的改动，逐条判：

• StorageServicePlugin.buildAdapterFromValues 原先完全忽略 this.options.s3，设置一保存就会把构造期前缀丢掉 —— 若不补，本 PR 交付的是一个「第一次保存设置后失效的隔离」，即一句谎。包含是对的。
• 命名空间不可从 settings 值读取。判对：租户管理员能清掉的边界不是边界，是偏好。这条比卡片要求更严，方向正确。

一条 dev 点名、我确认其分量的实现细节： 前缀规范化为带尾部 / 是承重而非整洁。S3 的 Prefix 是裸字符串匹配，tenant_1 会匹配 tenant_10/… —— 没有它，一个命名空间会经由隔离机制本身枚举到邻居。已有用例钉住。

key 用拼接而非路径 join：../elsewhere 作为字面 key 留在命名空间内，不逃逸。对。

② semver 定级 — 与 changeset 声明一致

@objectstack/service-storage: minor，正文带 BREAKING 横幅，并援引本仓 launch-window 约定（check-changeset-no-major 拒绝 major，破坏性由横幅 + ADR-0087 处置承载而非由级别承载）。ADR-0087 处置为 not-required，理由是适配器选项是代码不是栈元数据：没有 .parse()、没有 sys_metadata 形状、objectstack migrate meta 无可改写，受影响方是构造适配器的 TypeScript 宿主、投递通道是 tsc 在其自身调用点报错。与该适配器 list(prefix) 退休时同一处置、同一理由。 一致，判 对。

③ 边界旗与 open_questions 逐旗处置

旗	处置
check-clause2-carriers --pair 17599 exit 4，失败肢是 PM 的	已答并修复。 认领评论缺 Clause-②: 行；检查器禁止 dev 代填是对的（申报即判断）。我独立判为 yes（在读到 dev 建议之前），已补入认领评论并记录理由。重跑 exit 0，双载体一致
全程 UNLOCKED 验证（本机无可用 flock，macOS 无 util-linux）	接受并记录，非豁免。PR 正文按脚本自身措辞声明。这是宿主环境限制不是席位选择；同一限制在本轮 cloud 侧两单上同样出现
本地适配器是否同改	判：不改，且 dev 给的是证据不是推托 —— resolvePath() 已在每个门拒绝 .. 并强制 join 在 rootDir 下。与我在闸答复里「cloud 无此需求，交回本仓口径」一致

门禁机读

门	结果
check-clause2-carriers --pair 17599	exit 0 — 双肢一致、无放宽 tell
check-widening-tells --diff … --declaration yes	exit 0 — yes 已路由到契约复核，tell 不再决定什么
dev 报告的测试面	627/627、typecheck 0（抓到两个 test+build 漏过的真错）、build 0、9 个下游消费包 0、62/62 gate family 全跑、ADR-0087 0、全仓 lint 0
消融	两腿 8-red / 9-red，带落盘与 blob-hash 复原证明；对照绿

裁决

PASS。 按细则同席同笔剥双载体，并在本评论留 provenance。

⚠️ 落地不由本席做。 落地前检第三条要求 PR 全部 check 全绿，且这是本仓的已发布契约面 —— 归属 domain:services 车道。我在闸答复里已声明随时交还，现在正式交：PR #17599 复核已 PASS、双载体已清、两道机读门 exit 0，转 ready 与入队请该车道按 landing-operations.md 执行。我不翻 ready、不入队、不挂 auto-merge。

落地后的下游消费卡由本席在 objectstack-ai/cloud 立（cloud#1969 已挂 Blocked-by 指向本卡），该义务不因交接而转移。

给消费方的约束（dev 提供，我转述并已记入 cloud#1969）： 内核工厂在插件的 s3 选项里传 keyPrefix（忘记即编译错）；必须非空；⛔ 不得经 settings 下发；为已有桶根对象的环境打开前缀会滞留那些对象，既有迁移警告会就此触发。

Generated by Claude Code