test(plugin-security): name the sibling card that flips the parent-gate pin; changeset names transfer

Claude-Session: https://claude.ai/code/session_011TdZ8GjixNZFLz1xJD9zzK
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/24647-explain-authored-row-write.md

@@ -2,10 +2,10 @@
 '@objectstack/plugin-security': patch
 ---
 
-fix(plugin-security): `security/explain`'s record-grained `update` and `delete` verdicts compose the by-id write gate's authored-row-write deferral, so a row an app-authored row-level write policy admits is reported writable, as its `PATCH` / `DELETE` answers
+fix(plugin-security): `security/explain`'s record-grained `update`, `delete` and `transfer` verdicts compose the by-id write gate's authored-row-write deferral, so a row an app-authored row-level write policy admits is reported writable, as its `PATCH` / `DELETE` answers
 
 Clause-②: no (no accept set or public surface moves: enforcement is unchanged, and explain's record verdict now gives the answer the by-id write already gives)
 
 - **What was wrong.** The sharing middleware's by-id write gate does not stop at record sharing's refusal: it asks the security service whether an app-authored row-level policy admits the row for that verb (`checkAuthoredRowWrite`), and on `admit` hands the row to the pre-image gate, which admits it. Explain's record-grained write verdict asked record sharing's per-record gate alone, so on a private object, for a row owned by someone else that only such a policy lets the caller write, the `PATCH` / `DELETE` landed while explain answered `record.visible: false`, decided by `sharing`.
-- **What explain answers now.** The same deferral, on the same condition: only when the per-record update or delete gate refuses the row, asked through the sharing service's own probe with the context that gate is asked with. Only the literal `admit` lifts the refusal; `abstain`, any other answer and a failed probe leave it standing. The record verdict is then `visible: true`, `decidedBy: 'rls'`, the layer that last admitted the row; the `sharing` layer still reports `excluded`, and its detail names the deferral. A sharing service without the probe defers nothing, as before.
+- **What explain answers now.** The same deferral, on the same condition: only when the per-record update or delete gate refuses the row, asked through the sharing service's own probe with the context that gate is asked with. A `transfer` is deferred as an `update`, since its door is the `PATCH` that writes `owner_id`. Only the literal `admit` lifts the refusal; `abstain`, any other answer and a failed probe leave it standing. The record verdict is then `visible: true`, `decidedBy: 'rls'`, the layer that last admitted the row; the `sharing` layer still reports `excluded`, and its detail names the deferral. A sharing service without the probe defers nothing, as before.
 - **What does not move.** No enforcement answer changes. The `sys_attachment` and `sys_comment` parent gates ask record sharing first and refuse on its `deny` without asking explain, so a row this deferral admits is still refused there at the record-sharing step.

packages/plugins/plugin-security/src/explain-enforce-parity.test.ts

@@ -1093,7 +1093,8 @@ describe('security.explain answers what enforcement does — the enumeration', (
  * step admits (each gate's own parity table pins it: its `sharing deny` row
  * refuses with explain never called, though the double would admit). So on a
  * row the deferral admits, record sharing's own `deny` still decides both
- * gates: explain admitting it cannot widen either one.
+ * gates: explain admitting it cannot widen either one. That holds for today's
+ * gate composition only, and the case below says which card changes it.
  */
 describe('an app-authored row-level write policy the by-id write gate defers to (ADR-0105 D3)', () => {
   it('the update story names the deferral: record sharing excludes the row, row-level security admits it', async () => {
@@ -1115,6 +1116,12 @@ describe('an app-authored row-level write policy the by-id write gate defers to
   it("the parent gates' first question, record sharing, still refuses the row explain now admits", async () => {
     const rig = await bootSharing({ authored: true });
     try {
+      // ⚠️ A sibling card flips this pin: #24646 (ruling B, comment 6279880675)
+      // drops both gates' own-depth record-sharing step and their master step,
+      // so they ask only explain's record-grained by-id `update` verdict. The
+      // gate then admits exactly what the parent's by-id update admits; for
+      // this scenario, with #24647's deferral, that is ADMITTED. Until then the
+      // gates' first question below is record sharing's, and it refuses.
       expect(await rig.checkEdit(AUTHORED_WRITER, 'l_theirs')).toBe('deny');
       const x = await rig.explain(AUTHORED_WRITER, 'update', 'l_theirs');
       expect(x.kind === 'decision' ? x.decision.record?.visible : x.kind, describeExplained(x)).toBe(true);