Skip to content

test(qa): re-sync the authz-matrix sharing-rules recipient summary with the authorable enum - #17465

Merged
os-justin merged 3 commits into
mainfrom
claude/issue-15240-sharing-rules-recipient-summary
Sep 10, 2026
Merged

os-justin merged 3 commits into
mainfrom
claude/issue-15240-sharing-rules-recipient-summary

Conversation

@os-justin

Copy link
Copy Markdown
Collaborator

Fixes #15240

The sharing-rules row of the ADR-0056 D10 authorization conformance matrix enumerated five recipients. The authorable enum has carried six since the field kind became enforced, so a row whose state is 'enforced' was under-reporting what is enforced.

Two corrections, both inside that one row; packages/plugins/plugin-sharing/** is domain:services and was read as evidence only, never edited.

What changed

1. summary — the drift the card filed.

- (recipients: user/team/position/unit_and_subordinates/business_unit)
+ (recipients: user/team/position/unit_and_subordinates/business_unit/field — `field` expands per RECORD)

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: field is authorable and deliberately does not expand there — expandRecipient throws for it, because answering [] is precisely how a rule-wide caller turns "per record" into "nobody" (reconcile would then revoke every grant). The prose now names the real split: five rule-wide kinds in expandRecipient, and field's pairs derived per record in desiredGrantsForRule / expandRecipientForRecord.

This is the "possible second half" the card raised. It is the sharper of the two defects: a reader who greps expandRecipient for field finds nothing and concludes field is unenforced, when it is enforced through two dedicated paths.

3. A note recording 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 note as well as here.

I let the file's own practice decide it, as suggested, and the measurement was one-sided:

measurement over the 49 rows reading
summaries carrying hedging language (e.g. / such as / etc / ellipsis) 0
summaries carrying a parenthetical enumeration 16
closest structural twin scope-depth vs ObjectAccessScopeSchema member-for-member, in declaration order

There 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 ShareRecipientType in packages/spec/src/security/sharing.zod.ts —

enum:  user/team/position/unit_and_subordinates/business_unit/field
row:   user/team/position/unit_and_subordinates/business_unit/field

So the drift was a defect against a canonical source, not a stylistic gap.

queue is deliberately excluded. The runtime type SharingRuleRecipientType has seven members — the card and the dispatch both described field as "the sixth", and the seventh is queue. It stays out on purpose: it is reserved (no sys_queue), expandRecipient returns [] for it, and it is not authorable (the authoring enum is "this union minus queue"). Naming it on an enforced row would make the row false in the other direction — the exact hazard the card warned about for landing early. The note records 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:

premise reading
Blocked-by: #15072 closed closed completed
the sixth recipient really is enforced bootstrap-declared-sharing-rules.ts:114 → case 'field': return 'field'; (positive control: 6 case arms) — and enforced at the bulk path too, not just a case label: desiredGrantsForRule carries a dedicated field branch
the row was stale yes — five listed, six authorable

Coordinates that had moved: the card cited :316; the row is at :321 (:327 after 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 head 2541fd1e. Plus pnpm lint whole-repo, exit 0 (no narrowing claimed, so no narrowing evidence owed), @objectstack/dogfood typecheck exit 0, and the companion authz-conformance.test.ts 47/47.

check:doc-authoring red 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/dogfood typecheck green is a real measurement, not a vacuous one — tsc --listFiles confirms this file is in the program.

Changeset

skip-changeset, on the repo's own rule rather than on diff size: @objectstack/dogfood is private: true, so nothing published moves. Per the repo's convention this takes the label rather than an empty changeset.

Clause-②: no — a human-readable summary on a conformance-matrix row declares no contract and widens nothing.

⚠️ Worth a reviewer's eye despite the size: nothing mechanical reads summary, enforcement or note. 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

…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>
@os-justin os-justin added the skip-changeset PR has no user-facing published change; bypasses the changeset gate label Sep 10, 2026 — with Claude
@github-actions

Copy link
Copy Markdown
Contributor

📓 Docs Drift Check

Nothing 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
  • 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.

Coarse fallback — 0 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 3644fadc8e3728ab995f57311c1d6f32f2210f06 → packageMentionDocs.

@github-actions

Copy link
Copy Markdown
Contributor

⛔ merge queue 构建失败 — 先分诊,再决定要不要重排

队列构建 34501605908 红了。队列跑的是全量套件(PR 侧 CI 只跑 affected 子集),
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job(日志抽取,best effort):

  • Dogfood Regression Gate (2/3) — 失败步骤: Boot example apps and exercise real user flows

    @objectstack/dogfood:test:  FAIL   isolated  test/schedule-sweep-organization-scope.dogfood.test.ts > dogfood [sqlite-wasm]: a time-relative sweep selects inside its declared organization (#16659)
      ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
    @objectstack/dogfood:test:  FAIL   isolated  test/schedule-sweep-organization-scope.dogfood.test.ts > dogfood [memory]: a time-relative sweep selects inside its declared organization (#16659)
      ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
    
  • Dogfood Regression Gate (3/3) — 失败步骤: Boot example apps and exercise real user flows

    @objectstack/dogfood:test:  FAIL   isolated  test/schedule-acting-organization.dogfood.test.ts > dogfood [sqlite-wasm]: a scheduled run executes as its declared organization (#16659)
      ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
    @objectstack/dogfood:test:  FAIL   isolated  test/schedule-acting-organization.dogfood.test.ts > dogfood [memory]: a scheduled run executes as its declared organization (#16659)
      ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
    

↳ 失败原因 是判读的关键:超时(Test timed out in … / Hook timed out in …)多半是负载/时序,不是本 PR 的回归;
断言(AssertionError: …)才指向真实的行为改变。两者的 FAIL 行长得一模一样,只有这一行能区分。

⚠️ 断言这一侧有一类例外,判据是断言在测什么,不是它是不是 AssertionError。 断言的对象是产品行为(一个值、一个形状、一次拒收)⇒ 照上面读:真实的行为改变,去查,⛔ 不要重排掉;
断言的对象是这次实验自身的有效性前提(跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件)⇒ 它跟超时是同一类,同样对负载敏感,重排一次是合法的判别手段。
识别是机械的:断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为(真回归);
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提:它守护的那条不变式当时是绿的,同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量,仍然是时间测量。(⛔ 这只改「怎么读一次红」,不改「哪些测试可以重排」——后者由别处管。)

跨 PR 相同签名(24h,按失败测试文件聚合):

历史信号:

  • 本 PR 过去 24h 无队列失败记录(首次)。
  • 过去 24h 队列共有 2 个失败构建(不含本次)。

分诊清单:

  1. 失败测试在本 PR 改动的包里 → 真回归,修 PR。
  2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」;已有汇总 issue ⇒ flaky/环境问题实锤,去那张 issue 上谈,修好前重排只会再烧一轮全队列。
  3. 两者都不是 → 可能与同组 PR 语义冲突;等前面的 PR 落地或失败出队后再重排一次即可,不要连续重排。

Generated by Claude Code · merge-queue-triage workflow (#4859)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/s skip-changeset PR has no user-facing published change; bypasses the changeset gate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[finding] the dogfood authz-conformance matrix's sharing-rules recipient summary goes stale when #15072 lands — and no gate reads it

2 participants