Repository navigation
test(qa): re-sync the authz-matrix sharing-rules recipient summary with the authorable enum - #17465
Conversation
…ble recipient enum The `sharing-rules` row enumerated five recipients; `ShareRecipientType` has carried six since the `field` kind became enforced. Two corrections, both inside the row: - `summary` now transcribes the authorable enum member-for-member in declaration order (user/team/position/unit_and_subordinates/business_unit/ field), marking `field` as per-record. `queue` stays out: it is reserved, expands to [] and is not authorable, so naming it on an `enforced` row would make the row false in the other direction. - `enforcement` claimed "every authorable recipient expands in expandRecipient". That is now false: `field` deliberately does NOT expand there — expandRecipient throws for it, and the per-record pairs are derived in desiredGrantsForRule / expandRecipientForRecord. The prose now names the real split. A new `note` records the stance the card asked for: these summaries are exhaustive, not indicative. Measured across the file — 0 of 49 summaries hedge, and the closest twin (`scope-depth`) transcribes ObjectAccessScopeSchema member-for-member — so the drift was a defect rather than a stylistic gap, and declaring the summaries indicative was refused because it would retro-weaken the 16 rows that enumerate. Nothing mechanical reads these strings; the row is hand-maintained. Claude-Session: https://claude.ai/code/session_01DapQyvYrFb1MxSYe7BL2nt Co-authored-by: Claude <noreply@anthropic.com>
`check:doc-authoring` reds on new internal issue ids in sibling-package string prose: a ledger string reaches readers who cannot resolve `#NNNN`, and its baseline is shrink-only (adding an entry is maintainer-only, so that route was not taken). The ids move to the adjacent `//` comment the gate prescribes, where the reader who can resolve them already is. Claude-Session: https://claude.ai/code/session_01DapQyvYrFb1MxSYe7BL2nt Co-authored-by: Claude <noreply@anthropic.com>
…aring-rules-recipient-summary
📓 Docs Drift CheckNothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs. What this run could not see
Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): |
⛔ merge queue 构建失败 — 先分诊,再决定要不要重排队列构建 34501605908 红了。队列跑的是全量套件(PR 侧 CI 只跑 affected 子集), 失败的 job(日志抽取,best effort):
跨 PR 相同签名(24h,按失败测试文件聚合):
历史信号:
分诊清单:
Generated by Claude Code · merge-queue-triage workflow (#4859) |
Fixes #15240
The
sharing-rulesrow of the ADR-0056 D10 authorization conformance matrix enumerated five recipients. The authorable enum has carried six since thefieldkind became enforced, so a row whosestateis'enforced'was under-reporting what is enforced.Two corrections, both inside that one row;
packages/plugins/plugin-sharing/**isdomain:servicesand was read as evidence only, never edited.What changed
1.
summary— the drift the card filed.2.
enforcement— a claim that had become false, not merely incomplete.The row asserted "every authorable recipient expands in
expandRecipient". That is no longer true:fieldis authorable and deliberately does not expand there —expandRecipientthrows for it, because answering[]is precisely how a rule-wide caller turns "per record" into "nobody" (reconcilewould then revoke every grant). The prose now names the real split: five rule-wide kinds inexpandRecipient, andfield's pairs derived per record indesiredGrantsForRule/expandRecipientForRecord.This is the "possible second half" the card raised. It is the sharper of the two defects: a reader who greps
expandRecipientforfieldfinds nothing and concludesfieldis unenforced, when it is enforced through two dedicated paths.3. A
noterecording the stance, so the gap is not re-filed.Acceptance notes
Ending taken: option 1 — append the sixth kind. "Indicative, not exhaustive" was considered and refused. The triage ruling required that whichever ending I took be written down; the reasoning is in the row's
noteas well as here.I let the file's own practice decide it, as suggested, and the measurement was one-sided:
e.g./such as/etc/ ellipsis)scope-depthvsObjectAccessScopeSchemaThere is no open-ended convention in this file to appeal to — declaring these summaries indicative would not have described an existing practice, it would have created one, and retro-weakened the 16 rows that enumerate in order to buy one row a caveat it does not need.
The stronger finding is that this row is not merely "a list that happens to be exhaustive": after the fix it is an exact, order-faithful transcription of the authorable enum
ShareRecipientTypeinpackages/spec/src/security/sharing.zod.ts—So the drift was a defect against a canonical source, not a stylistic gap.
queueis deliberately excluded. The runtime typeSharingRuleRecipientTypehas seven members — the card and the dispatch both describedfieldas "the sixth", and the seventh isqueue. It stays out on purpose: it is reserved (nosys_queue),expandRecipientreturns[]for it, and it is not authorable (the authoring enum is "this union minusqueue"). Naming it on anenforcedrow would make the row false in the other direction — the exact hazard the card warned about for landing early. Thenoterecords this so the next reader who counts seven members does not "fix" the row by adding it.Premise re-verification
Re-derived myself on the merged ref rather than carried from the dispatch:
Blocked-by: #15072closedcompletedbootstrap-declared-sharing-rules.ts:114→case 'field': return 'field';(positive control: 6casearms) — and enforced at the bulk path too, not just acaselabel:desiredGrantsForRulecarries a dedicatedfieldbranchCoordinates that had moved: the card cited
:316; the row is at:321(:327after this change). Located by symbol —grep -c 'sharing-rules'→ 1 hit, so the match is the row.Gates
45/45 derived families green, exit codes captured to disk before any verdict was read, reconciled with
dispatch-gates --ran(45 derived, 45 run, 0 NOT-MEASURED, 0 UNRUN— a derived zero, every family carrying a recorded exit code). Union re-run on the final merged head2541fd1e. Pluspnpm lintwhole-repo, exit 0 (no narrowing claimed, so no narrowing evidence owed),@objectstack/dogfoodtypecheck exit 0, and the companionauthz-conformance.test.ts47/47.check:doc-authoringred once, on my own first draft — it refuses new tracker ids in sibling-package string prose, and its baseline is shrink-only with baselining reserved to the maintainer. Fixed the prescribed way: the ids moved out of the row's strings into the adjacent//comment. Not baselined.The
@objectstack/dogfoodtypecheck green is a real measurement, not a vacuous one —tsc --listFilesconfirms this file is in the program.Changeset
skip-changeset, on the repo's own rule rather than on diff size:@objectstack/dogfoodisprivate: true, so nothing published moves. Per the repo's convention this takes the label rather than an empty changeset.Clause-②: no— a human-readablesummaryon a conformance-matrix row declares no contract and widens nothing.summary,enforcementornote. No gate parses them, so nothing here can go red if the judgement is wrong and nothing goes green to confirm it is right. Review is the only check this change has.🤖 Generated with Claude Code
https://claude.ai/code/session_01DapQyvYrFb1MxSYe7BL2nt
Generated by Claude Code