attachments-access.mdx's 401 row is incomplete once the four tenancy-posture doors land — one family-wide addition, not four per-card edits

[claude]

Filed by the PM dispatch loop on behalf of the #15352 round (PR #16017), which measured it but deliberately did not file it — it is family-wide rather than that card's, and the REST search endpoint is refused in that container, so it could not dedupe. ⛔ Filing blind is the one failure mode the dedupe rule exists to stop. ⛔ Unassigned and ungraded — domain:*, type and priority are triage's.

⛔ BLOCKED until the four tenancy-posture seam cards land: #15349 (PR #15996), #15350 (PR #16011), #15351 (PR #16015), #15352 (PR #16017). The addition below is true of all four doors, so a per-card edit would write the same paragraph four times.

The page and the row

content/docs/permissions/attachments-access.mdx, the "Download — authenticated and parent-scoped" section. Its AUTH_REQUIRED (401) row reads:

Anonymous download of an attachments-scope file

⚠️ It is INCOMPLETE, not wrong — and the distinction decides the remedy

Under a wall-enforcing posture, that same 401 is now also the answer for:

• an ex-member's org-stamped API key — under both isolated and group;
• an organization-less key — under isolated only.

⭐ This is not a falsified claim, and E3's 「已发布必修」 therefore does not bite: the row was already a simplification before this family, since an unknown, revoked or expired key has always produced the same 401. So the work is an addition, not a correction. That is precisely why it was not fixed inside #16017 — a page that was already simplifying is not made false by one more case reaching the same status.

Why one card rather than four

The four repaired doors (plugin-sharing share-link admission, service-datasource admin routes, service-settings manifest gate, service-storage file read) now share this behaviour. One paragraph describes all of them; four per-card edits would write it four times and drift apart on the fifth.

⚠️ Measure before writing — the four doors do NOT agree on everything

Two readings from the family that a docs edit must not flatten:

1. group is not uniform. Measured on service-datasource: the admin routes supply no tenancyPosture to resolveAuthzContext — an ex-member's org-stamped API key is admitted #15350: under group the ex-member's stamped key is refused (organization_membership_ended keys on postureEnforcesWall, which group satisfies), but the organization-less key stays admitted (organization_required additionally requires NOT postureUsesUnionScope, which group fails). A sentence that says "under group these keys are refused" would be wrong for one of the two rows.
2. The outage answer differs per door, and is not the declared 503 anywhere measured so far — service-datasource renders 500, service-storage renders 403 FILE_DOWNLOAD_DENIED. That is tracked separately on service-datasource: the AuthzStoreUnavailableError the admin guard re-raises reaches the wire as 500 INTERNAL_ERROR, not the 503 SERVICE_UNAVAILABLE the brand declares #15999; ⛔ do not document a status this page cannot promise.

Provenance

The page was read in full (141 lines) by the #15352 round precisely because it is the drift check's declared blind spot — it documents this door by its inputs, and an emitter-only diff can never list it. Its verdict on falsification was a measured null with per-file positive controls; this addition is the residue that survived that null.

Refs

#15349 · #15350 · #15351 · #15352 (the four doors) · PRs #15996 / #16011 / #16015 / #16017 · #15999 (the outage-status divergence) · #16013 (the helper extraction, also blocked on the same four)

---

Generated by Claude Code

[claude]

✅ UNBLOCKED — all four tenancy-posture seam cards have landed, verified by content on origin/main

PM dispatch seat, session_01ARYe3yQTQCUFm5qPYNgKaJ. ⛔ Not a claim, ⛔ not a dispatch, ⛔ no domain:* or grade added — this card was filed unlabelled on purpose and routing stays triage's write.

The four landings

⛔ Verified by content on origin/main, not the API's merged field — and ⚠️ not by merge_commit_sha, which is populated on open PRs too (measured today: six open, queued PRs all carried one).

card	PR	landed as	door
#15349	#15996	2e3576503	plugin-sharing share-link admission
#15350	#16011	fb447b47e	service-datasource admin routes
#15351	#16015	2024eca4f	service-settings manifest gate
#15352	#16017	b8c82de0d	service-storage file read

Each verified with the three call sites reading 0 at the parent, 1 on origin/main (comments stripped, anchored on the call (), and each with a positive control firing identically on both refs.

⇒ The four doors this page's addition describes now all behave the same way on main, which is the precondition this card was waiting for. The paragraph can be written once instead of four times, which is why it was filed as one card rather than four.

⛔ The two readings that must NOT be flattened still stand

Both were measured during the family and neither is superseded by the landings:

1. ⚠️ group is not uniform. Under group the ex-member's org-stamped key is refused (organization_membership_ended keys on postureEnforcesWall, which group satisfies), but the organization-less key stays admitted (organization_required additionally requires NOT postureUsesUnionScope, which group fails). ⇒ A sentence reading "under group these keys are refused" would be wrong for one of the two rows.
2. ⚠️ The outage answer differs per door and is not the declared 503 anywhere measured — service-datasource renders 500, service-storage renders 403 FILE_DOWNLOAD_DENIED. Tracked separately on service-datasource: the AuthzStoreUnavailableError the admin guard re-raises reaches the wire as 500 INTERNAL_ERROR, not the 503 SERVICE_UNAVAILABLE the brand declares #15999; ⛔ do not document a status this page cannot promise.

And the reason this page is invisible to the drift check

⭐ Restated because it is why this card exists rather than a drift-check row: content/docs/permissions/attachments-access.mdx documents this door by its inputs, and an emitter-only diff shares no identifier with it — so the Docs Drift Check cannot list it, not on the four landing runs and not on any run. The page was read in full (141 lines) by the #15352 round for exactly that reason. ⇒ This addition has to be made by hand; no tool will nominate it.

⭐ Also unchanged: this is an addition, not a correction. The 401 row was already a simplification before this family (an unknown, revoked or expired key has always produced the same 401), so E3's 「已发布必修」 does not bite and this is not a falsified-claim repair.

Sibling

#16013 (the helper extraction) was blocked on the same four and is unblocked by the same set; it is a code card, not this one.

---

Generated by Claude Code