fix(service-storage)!: the upload commit, chunked-completion and progress doors act only for the uploader

[objectstack-fleet]

Fixes #22046
Clause-②: no (narrowing)

Ruling B on the card, with its addendum: one ownership rule, declared once and checked at the three storage upload doors that act on an id the caller names. Classes, positions and functions only.

What changed

• packages/services/service-storage/src/upload-ownership.ts (new). isFileUploader(callerUserId, file) is the one rule. The caller's user id must equal the file's owner_id. An empty owner_id and a missing file row both answer false, so a door never guesses an owner. There is no administrator exception. The module also declares the refusal: 403, PERMISSION_DENIED, and one constant message.
• storage-routes.ts. requireUploader(authSession, file, res) calls the predicate and sends the refusal. Each door calls it right after its by-id read and before any write or disclosure:
  • commit door (POST …/upload/complete): after getFile, before updateFile;
  • chunked-completion door (POST …/upload/chunked/:uploadId/complete): after getSession it reads the session's file by file_id, because the session row has no user column, then checks. This comes before the expiry stamp, the status writes and the answer;
  • progress door (GET …/upload/chunked/:uploadId/progress): the same, before the expiry write and the progress answer.
• Unchanged: the download doors' authorizeDownload, the two start doors, the tenant stamp and the tenant scope, the not-found answers, and the chunk door with its resume-token check.
• Open mode (no session resolver wired, which means a kernel with no auth service): requireUploader passes. There is no caller identity to compare, and the routes stay open as the resolveSession option documents. See the acceptance notes below.
• Changeset .changeset/22046-upload-doors-uploader-only.md: @objectstack/service-storage minor. It is an accept-set narrowing, marked BREAKING under the launch-window convention, with ADR-0087 disposition not-required (no-migration-prescription).

Pins

service-storage · src/upload-door-ownership.test.ts (23 cases). Per door:

• positive: the uploader passes;
• same organization: a non-uploader gets 403 PERMISSION_DENIED, the rows are unchanged, and the body names nothing about the row;
• another organization: a caller gets the identical body.

It also covers: an empty owner is refused; a session whose file row is gone is refused; there is no administrator exception; the rule runs before the expiry write and before the expiry disclosure; the not-found answers are unchanged; open mode is unchanged; and the predicate's own cases.

Booted organization wall · packages/plugins/organizations/src/storage-upload-door-ownership.wall.test.ts (10 cases). Cross-lane files, declared here:

• this test;
• packages/plugins/organizations/package.json: devDependencies @objectstack/service-storage and @objectstack/verify;
• packages/plugins/organizations/vitest.config.ts: both aliased to source, as check:test-source-alias prescribes;
• pnpm-lock.yaml: 6 lines.

The wall is raised by OrganizationsPlugin. ADR-0132's boundary (no-framework-dependents.pin.test.ts) lets no other workspace package declare it, which is why the dogfood multi-organization blocks skip. That makes this package the smallest one that boots the wall. The ADR-0132 pin allows the dependency in this direction.

What the test runs:

• the stack: bootStack with this package's OrganizationsPlugin and the real StorageServicePlugin, OS_TENANCY_POSTURE=isolated and OS_AUTH_MEMBERSHIP_POLICY=invite-only;
• the premise, read back from the tenancy service: posture isolated, isolationActive: true, degraded: false;
• the callers, made through the product's own doors:
  • the seeded platform owner is the uploader;
  • a colleague joins the owner's organization through invite and accept;
  • an outsider creates an organization of their own.

Per door:

• a positive pin;
• a same-organization pin;
• a cross-organization pin: 403 PERMISSION_DENIED with a body equal to the colleague's.

The rows the door names are read back whole, as system, before and after each refused call, and must be equal.

Fixture triage. The route block in tenant-audit-update-delete-half-repairs.test.ts seeded rows with no uploader. The commit and progress doors now refuse such rows before the write that block pins, so its seeds gain owner_id (the session's user) and the progress case gains its file row. Envelope conformance gains the new refusal's case.

Evidence (head 67e5a1ef)

• Red before the fix: the new service-storage pin file against the unmodified doors (base 033e5c53 plus the pin file) gave Tests 12 failed | 11 passed (23). Every negative pin was red and every positive or unchanged pin was green.
• Green: @objectstack/service-storage vitest Test Files 43 passed (43) · Tests 683 passed (683). @objectstack/organizations vitest Test Files 10 passed (10) · Tests 141 passed (141). The dogfood suites that drive these doors on the wire (attachments-permission-matrix, field-file-collection, predicate-write-unreadable-not-matched, write-door-unreadable-is-not-found) gave Tests 56 passed | 1 skipped (57); the skip is the existing multi-organization block, which skips in this repository. Typecheck is green for both packages, and both test-layer programs list the new files (--listFiles).
• Ablation, per door (scripts/ablation-replace.mjs --delete, the door's requireUploader call removed; each leg restored to the HEAD blob with git diff HEAD empty):
  • service-storage pins: at each door that door's 4 negative pins went red and the other 19 stayed green. That is commit 4 red · completion 4 red · progress 4 red.
  • wall pins: at each door that door's same-organization pin and cross-organization pin each went red on their own assertion (status not 403), and the other 8 stayed green.
  • No rebuild leg was needed: both suites resolve @objectstack/service-storage to source (the relative import in the storage suite, the vitest alias in the wall suite).
• Lint: eslint --no-inline-config --format json on the 7 touched lintable files: 7 files, 0 errors, 0 warnings. The population is every touched .ts file, and eslint reports none as ignored. This repo's config enables no type-aware rules, so the diff cannot move a verdict on an untouched file.
• Gates: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack at 67e5a1ef derived 79 gate commands. All 79 were run on that head and each exited 0. --ran with the recorded exit codes reports 79 run, 0 NOT-MEASURED (a DERIVED zero). One gate was red on the first pass and is fixed in this diff: check:registry-log-declared required the organizations suite, now booting a stack, to declare OS_REGISTRY_LOG.

Acceptance notes (boundary readings, not changed here)

• Not-found vs refused. An unknown id still answers 404 (FILE_NOT_FOUND / UPLOAD_SESSION_NOT_FOUND). An id that exists but belongs to someone else answers 403. The pair therefore tells a caller whether an id they hold exists. The ruling fixes 403 and leaves the not-found answer alone, so neither is touched. Before this change the same distinction existed through the door's success answer.
• Open mode is a kernel with no session resolver: no identity, routes documented open. The rule needs a caller identity and does not apply there. Every upload in that mode lands with no owner.
• The chunk door (PUT …/chunk/:chunkIndex) is outside the ruling. It keeps its resume-token check.
• CI cost: @objectstack/organizations tests now depend on @objectstack/verify and its closure (test only; nothing ships).

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/organizations, @objectstack/service-storage, touching 13 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/plugins/organizations/vitest.config.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

24 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json 959c209d56a8b9ab6f7e561e87700721194e4678.

⛔ 6 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/plugins/organizations/vitest.config.ts) — pages documenting those are invisible to this run
• 1 anchor(s) matched too much of the corpus to be a work list: owner_id (literal, 30 pages)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 13 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 959c209d56a8b9ab6f7e561e87700721194e4678 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ac1ee4b6045999e967ba71bbd3daf09b736382b5 — the merge of head e4eb04d602ca9f8e797d515fc5d93c336f633a7c into base 959c209d56a8b9ab6f7e561e87700721194e4678, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ac1ee4b6045999e967ba71bbd3daf09b736382b5 && git checkout ac1ee4b6045999e967ba71bbd3daf09b736382b5
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 959c209d56a8b9ab6f7e561e87700721194e4678 e4eb04d602ca9f8e797d515fc5d93c336f633a7c && git checkout -B drift-repro 959c209d56a8b9ab6f7e561e87700721194e4678 && git merge --no-ff e4eb04d602ca9f8e797d515fc5d93c336f633a7c

node scripts/docs-audit/affected-docs.mjs --json 959c209d56a8b9ab6f7e561e87700721194e4678

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 959c209d56a8b9ab6f7e561e87700721194e4678 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Validate Package Dependencies is red here, and it is not this PR's · domain:services seat 1 (#6021) · session_01WkL6Eijt432S1Y7ekb6ovQ · 2026-10-08T04:00Z

• The failing check: the OSV-Scanner step matches six advisories on next@16.3.6 (fixed in 16.3.8). The next resolutions come from apps/docs and better-auth; this PR's 6 lockfile lines add test-only devDependencies for packages/plugins/organizations and none of them is next.
• Red on the base too: main's own scheduled scan at ef1fcb26 failed the same way (run 37721176529). The anchor card is [finding] main's lockfile matches six new OSV advisories on next@16.3.6 (GHSA-mcj8-r9mp-w47p and five more): Validate Package Dependencies goes red on main's scheduled scan and on every dependency-touching PR #22148 (domain:devx, pm:queue).
• No fix exists yet to port. Two changes would turn this check green: [finding] main's lockfile matches six new OSV advisories on next@16.3.6 (GHSA-mcj8-r9mp-w47p and five more): Validate Package Dependencies goes red on main's scheduled scan and on every dependency-touching PR #22148's dependency bump, or PR ci(validate-deps): judge a pull request's OSV findings against the merge base; main keeps the absolute daily scan; job timeout 15 min #22138 (ci(validate-deps): on pull_request the OSV scan judges the whole lockfile, so a PR that changes no dependency inherits main's red for hours (7 red-main findings in 5 weeks) — judge base-relative on PRs, keep the daily main scan, add a job timeout #22082), which makes the PR-side scan judge only what a PR adds. Porting either into this security PR would widen it, so the seat waits for one to land, then merges main into this branch.
• The seat's review is ACCEPT (on security(service-storage): three upload doors authorize by session alone, with no ownership or resume-token check on the file or upload they name (the owner-check class the #21908 ruling sent to its own card) #22046). Ready and auto-merge follow once every check on the head is green.