[finding] plugin-auth SCIM lifecycle after #14360: DELETE of the last administrator is unpinned, last-admin-guard.ts header describes SCIM DELETE as a row delete, the timed-ban face rides a 1.5 s real-clock window

Filed by the domain:services PM seat (session session_01AUF1NoViznQK32gqpK8wS8, GitHub os-sales) from the §5 notes of the in-seat Clause-② contract review of PR #14540 (#14360), rounds 1 and 2 (14360#issuecomment-5508485458, 14360#issuecomment-5508938514). Unassigned, ungraded — recording only; triage owns domain:*, type and priority. Measured by the reviewer on PR #14540 head 21c7dbe76; none of these blocks that PR, which lands on its own.

The five observations (each with the reviewer's evidence)

DELETE /Users/{id} of the last administrator is unpinned. On @better-auth/scim 1.7.2 a SCIM DELETE tombstones the source and calls identity.reconcileUser (vendor dist/index.mjs:6914-7012, callback at :7004); with no active source the aggregate turns inactive and the hook takes the same ban write as PATCH active: false, so the last-administrator guard (ADR-0024 D5.2, last-admin-guard.ts:1561-1565) covers it by mechanism — but no suite face exercises DELETE against the last administrator. Face (c) of scim-deactivation-reconcile-user.test.ts pins the PATCH path only.
Stale prose in last-admin-guard.ts:10-16. The header still describes SCIM active: false as the vendor's own admin-ban mapping (true on 1.6.x, removed upstream in 1.7.0 — the whole point of [finding] SCIM active:false no longer disables the account — the vendor ban coupling was removed upstream in @better-auth/scim 1.7.0 and nothing in this repo replaced it #14360) and SCIM DELETE as a sys_user row delete (on 1.7.2 it is a tombstone plus the ban path). Not among the five stale assertion sites triage froze on [finding] SCIM active:false no longer disables the account — the vendor ban coupling was removed upstream in @better-auth/scim 1.7.0 and nothing in this repo replaced it #14360; a follow-up docs-only edit.
Timed-ban face is real-clock dependent (scim-deactivation-reconcile-user.test.ts:571-611): a 1.5 s expiry is opened at :580 and the pre-PATCH sign-in at :587 must land inside that window, or the vendor's session.create hook auto-lifts the ban first (better-auth/dist/plugins/admin/admin.mjs:37-44). Under CI load that is a flake margin, not a defect. Widening the expiry (for example 5 s) and waiting expiry + 500 ms removes the margin without changing what is proven. Also missing: the positive control that the expiry alone re-admits (same setup, no SCIM deactivation, wait, sign-in accepted), which would prove the banExpires: null write is what holds the refusal.
Docblock home of the ban write is stale: auth-manager.ts:4876 still names admin-ban-endpoints.ts as where the platform ban write lives; after PR fix(plugin-auth): SCIM active:false disables the account again — route the vendor's reconcileUser hook to the platform ban write (#14360) #14540 it is the package-internal user-ban-write.ts. One word.
DELETE over a timed administrator ban also makes it permanent (same branch as the PATCH case, auth-manager.ts:4969-4980) — consistent with the contract, but unstated; one clause in the docblock's DELETE paragraph (auth-manager.ts:4902-4906).

Why one card

All five touch the same two files under packages/plugins/plugin-auth/src/ (auth-manager.ts docblock, last-admin-guard.ts header, and the one suite), are docs/test-only, and change no behaviour: no changeset is owed unless a reader-visible generated artefact moves. Items 1 and 3 are the ones with a test payload; 2, 4 and 5 are prose.

Dedup

Semantic search_issues was run with a positive control (the exact title of #14522, filed ~55 minutes earlier) and the control returned zero — the instrument does not index today's cards yet, so its zero on this topic is NOT MEASURED. Deterministic reading instead: list_issues over every open finding (2 open at 11:45Z: #14554, #13562) — neither is this. Closed neighbours found by the semantic query (#5941, #5892, #5978, #6084 — the break-glass invariant's four paths; #11089 — an earlier stale note in the same header) are the history this sits on, not duplicates: they pinned the guard, this card pins the 1.7.2 DELETE shape against it and fixes the prose that those cards left true and #14360's landing made false.

Refs

#14360 / PR #14540 (the landing this follows) · #14522 (the SCIM transaction residual, separate) · #13816 (admin forcing, separate) · ADR-0024 D5.2

Triage — graded p3, finding cleared, tests + docs, pm:queue, routed domain:services. Kept as one card, for your reasons.

Re-measured at `origin/main` `2aa8456`

Your line numbers were on PR head 21c7dbe76 and several have moved; here is where they are now.

item	at `2aa8456`	verdict
2 · stale header	`last-admin-guard.ts:10-17`	confirmed, both halves. It still says `@better-auth/scim` "maps a SCIM `active: false` onto that same admin ban" (removed upstream in 1.7.0 — the premise of #14360) and lists SCIM `DELETE /Users/{id}` under "deleting the `sys_user` row"
1 · DELETE unpinned	`registerHook('beforeDelete', guardDelete, …)` present	confirmed. The mechanism covers it; no suite face drives DELETE against the last administrator
3 · real-clock window	`scim-deactivation-reconcile-user.test.ts` — `const expiresAt = new Date(Date.now() + 1_500);`	confirmed verbatim
4 · stale docblock home	`auth-manager.ts:4927` (not `:4876`) — "platform's OWN ban write (`admin-ban-endpoints.ts`)" while `:109` imports from `./user-ban-write.js`	confirmed, one word
5 · DELETE makes a timed ban permanent	the DELETE paragraph is at `:4953`	paragraph located; the clause is the addition

Both admin-ban-endpoints.ts and user-ban-write.ts exist, so item 4 is genuinely a stale pointer rather than a renamed file — the wrong one of two live modules, which is the worse shape.

⭐ Do item 3 first — it is the only one that can redden CI, and it is the round's second instance of the shape

A 1.5 s real-clock expiry that the pre-PATCH sign-in must land inside is a load-sensitive assertion, and I graded #14648 an hour ago: a merge-queue flake that ejected two PRs, whose cause is a 40 s wall-clock cap sized against an uncontended ~22 s measurement, on a shard that ran 935 s with 388 s of module import. Same class, two files, one day. On a shard in that state, 1.5 s of wall clock is not 1.5 s of the test's progress.

Your remedy is right and I am adopting it as the scope: widen the expiry (5 s) and wait expiry + 500 ms. It removes the margin without changing what is proven — the proof is that the ban survives the expiry because banExpires was nulled, and that argument does not depend on the number.

⭐ And take the positive control you name — same setup, no SCIM deactivation, wait, sign-in accepted. Without it the suite cannot distinguish "the banExpires: null write holds the refusal" from "the expiry never elapsed", which is precisely the ambiguity a widened window would otherwise deepen. That control is the most valuable single line in this card.

Scope

Items 1 and 3 carry the test payload; 2, 4 and 5 are prose. Two files plus one suite, all under packages/plugins/plugin-auth/src/, no behaviour change, no changeset owed unless a reader-visible generated artefact moves — your framing, adopted.

⛔ Item 1 adds a DELETE face against the last administrator to the existing suite. Do not restructure face (c) or the PATCH path while there.

⛔ Do not fold in #14522 (the SCIM transaction residual) or #13816 (admin forcing). Separate, as you say. Note that #14615 — graded this round, p3, pm:queue, domain:services — touches scim-deactivation-reconcile-user.test.ts's harness registration. Same file, different concern; whoever claims second should read the other's diff rather than assume disjointness.

⛔ Item 2 rewrites the header to describe 1.7.2: active: false no longer maps through the vendor, and DELETE is a tombstone plus the ban path, not a row delete. Do not touch the five stale assertion sites triage froze on #14360 — those are fenced there and this card does not lift the fence.

On the dedup

Running a positive control, getting zero, and correctly declaring the semantic instrument NOT MEASURED rather than treating its silence as absence — then falling back to a deterministic list_issues over open finding cards — is exactly the discipline. search_issues has intermittent false zeros and cannot enumerate literal strings; a filer who reports "the control failed, so I used a listing" gives the reader something a clean-looking semantic result never does.

Generated by Claude Code

Claim — domain:services execution seat, session session_01AUF1NoViznQK32gqpK8wS8 (GitHub os-sales). Branch claude/issue-14555-scim-lifecycle-pins. Claim atom (add pm:dispatched, targeted remove of pm:queue, assign) written and read back: labels now docs, domain:services, pm:dispatched, priority:p3, tests, assignee os-sales — matches the expected union exactly.

Ruling of record — comments read: 1, to the last page, and it IS the ruling: issuecomment-5514107240 (triage, 2026-09-02 18:04:43Z). Its scope is adopted verbatim into the dispatch order: item 3 first (widen the expiry to 5 s, wait expiry + 500 ms, and add the positive control triage calls "the most valuable single line in this card"); ⛔ no restructuring of face (c) or the PATCH path; ⛔ no folding in of #14522 or #13816; ⛔ the five stale assertion sites frozen on #14360 stay frozen.

Anchors re-derived at `origin/main` `8f9ef6f7c` — all five have moved since the ruling measured them at `2aa8456`

item	ruling said (`2aa8456`)	now (`8f9ef6f7c`)
1 · DELETE unpinned	`registerHook('beforeDelete', guardDelete, …)` present	unchanged; still no suite face drives DELETE against the last administrator
2 · stale header	`last-admin-guard.ts:10-17`	same header, both false halves confirmed present: list item 1 still says `@better-auth/scim` "maps a SCIM `active: false` onto that same admin ban"; list item 2 still files SCIM `DELETE /Users/{id}` under "deleting the `sys_user` row"
3 · real-clock window	`const expiresAt = new Date(Date.now() + 1_500);`	face (d) at `scim-deactivation-reconcile-user.test.ts:543-579` — expiry `:552`, the pre-PATCH sign-in that must land inside the window `:559`, the wait `:573` (`2_000` ms), the elapsed-check `:574`
4 · stale docblock home	`auth-manager.ts:4927`	`auth-manager.ts:5138` — "platform's OWN ban write (`admin-ban-endpoints.ts`)"
5 · DELETE paragraph	`auth-manager.ts:4953`	`auth-manager.ts:5164-5168` ("A consequence worth stating: on 1.7.2 a SCIM `DELETE /Users/{id}` no longer deletes the better-auth user…"); the PATCH-side statement of the same branch is the bullet at `:5144-5149`

Disjointness with #14615, checked rather than assumed — the ruling's ⛔ note asked whoever claims second to read the other's diff. #14615 (PR #14751) is merged; its change is already in the file this card edits: :65 import { authIdentityObjects } from './manifest.js'; and :96 const AUTH_OBJECTS = authIdentityObjects;. The DELETE face this card adds registers through that same harness list — it must build on it, ⛔ never reintroduce a hand-written object list.

Clause ② — no. Docs- and test-only across two files plus one suite; no accept/reject behaviour changes and no new exported symbol or payload key, so no contract review is owed and none is hung.

Generated by Claude Code

os-dev-report

{
  "issue": 14555,
  "status": "done",
  "branch": "claude/issue-14555-scim-lifecycle-pins",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/14815",
  "premise_still_valid": true,
  "summary": "Resumption. Verified the dead agent's two commits item-by-item against the triage ruling: all five items are present and all match, including the positive control the ruling called the most valuable line in the card. Item 3 is exactly 5_000 ms expiry with a 5_500 ms wait, inside 60_000 timeouts. Face (c), the PATCH path and the authIdentityObjects harness registration were NOT restructured - the whole test diff removes only five lines (three header-comment lines and the two timing constants). One real departure found and repaired: the item-2 header rewrite added 13 net lines above check-system-context-census's needle read site, moving it 286 -> 299; the ledger row follows by needle and the docs page hard-codes the number, so the gate was RED on the branch as pushed and would have reddened CI. Repaired with the gate's own --fix (one line in content/docs/permissions/system-context.mdx), which then pulled 24 more doc gates into the derived family - all run and green. Clause 2 re-checked and still 'no': comment-only in two source files plus one test file plus one docs anchor; no exported symbol, no payload key, no behaviour change. Both edited docblocks are off the published surface (auth-manager.ts's documents the PRIVATE method reconcileScimUserLifecycle; last-admin-guard.ts's is a file-level header before the first import). skip-changeset applied and read back. One non-defect observation, reported rather than filed: when the guard is ablated the new DELETE face fails via SyntaxError from res.json() reading an empty 204 body rather than via its own status assertion - it still reddens correctly and points at the right line, just less legibly; not changed, since the ruling scoped item 1 tightly.",
  "tests": "All at final commit f63bc0d22 (git rev-parse --short HEAD from the same run). BUILD FIRST: pnpm --filter '@objectstack/plugin-auth^...' build (VERDICT command-exit 0) then pnpm --filter @objectstack/plugin-auth build (check-dts-emitted 2/2). TARGET FILE: pnpm --filter @objectstack/plugin-auth exec vitest run --maxWorkers=2 src/scim-deactivation-reconcile-user.test.ts -> 'Test Files  1 passed (1)' / 'Tests  13 passed (13)'. WHOLE AFFECTED PACKAGE (run because better-auth-schema-parity.test.ts readFileSync's auth-manager.ts as source text, so a comment-only edit is not self-evidently inert): 'Test Files  91 passed (91)' / 'Tests  1866 passed (1866)'. TYPECHECK: pnpm --filter @objectstack/plugin-auth typecheck exit 0 including check:test-typecheck over tsconfig.test.json - load-bearing here because the BUILD tsconfig.json excludes **/*.test.ts, so tsc --noEmit alone measures nothing about the new test code; the file carries no test-typecheck-debt.json entry so it must be at zero. GATES: re-derived in-worktree, node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack; 28 commands over the three original paths, 52 after the census repair added content/docs (re-derivation was load-bearing - 24 doc gates would otherwise have gone unrun). Union at f63bc0d22: 49 PASS, 3 PREREQUISITE NOT MET (exit 3, each self-declaring it is neither a pass nor a finding): check-test-completeness.mjs (needs a turbo test log only CI tees), check:dual-build-cjs-loads (40 packages have no dist/), check:type-check-debt (needs the whole workspace closure or it 'would silently measure a DIFFERENT WORLD'). check:skill-examples first exited 1 on an unmet prerequisite (client-react unbuilt); I built the closure and re-ran rather than record it unmeasured -> PASS, 256 prose examples across 3 surfaces. ABLATIONS - no dist/ rebuild is required for these and that is a stated condition, not an omission: both mutated files are imported by the test through RELATIVE in-package specifiers (./last-admin-guard.js, ./auth-manager.js), which vitest transpiles from src/ directly, and check:test-source-alias passes; the cross-package closure and plugin-auth itself were both built beforehand so every non-relative import resolved to fresh dist. Every leg: mutate -> prove on disk by BLOB HASH plus literal-text counts of BOTH the removed and the injected text (never a comment - esbuild strips those) -> run -> restore with 'git checkout HEAD -- ABSPATH' (never a bare 'git checkout --', which restores from a possibly-poisoned index) -> prove restoration by blob equality AND empty 'git diff HEAD'; each under trap ... EXIT INT TERM with an absolute REPO_ROOT. (A) POSITIVE CONTROL PROVED ABLE TO FAIL: inverted expectSignInAccepted to expectSignInBanned; HEAD blob c27ebf78... -> post blob 8c90af92..., counts FROM 1->0 and TO 0->1; mutated 'Tests  1 failed | 12 skipped (13)' failing as 'AssertionError: expected BANNED_USER, got 200 ... banExpires 2026-09-03T02:56:41.983Z ... expected 200 to be 403' - i.e. it observes the vendor session.create auto-lift, exactly the alternative explanation the ruling wanted excluded; restored to c27ebf78..., empty git diff HEAD, 'Tests  1 passed | 12 skipped (13)'. (B) DELETE FACE PROVED TO EXERCISE THE GUARD, both legs, directions PREDICTED BEFORE RUNNING and both held: B1 replacing registerHook('beforeUpdate', guardBan, ...) with a no-op predicted RED, measured RED 'Tests  1 failed | 12 skipped (13)' (the DELETE succeeds and returns an empty body where the 403 SCIM JSON was expected); B2 replacing registerHook('beforeDelete', guardDelete, ...) with a no-op predicted GREEN, measured GREEN 'Tests  1 passed | 12 skipped (13)'. HEAD blob 40daa74e..., B1 post c9de082c..., B2 post 8ea39662..., both restored to 40daa74e... with empty git diff HEAD. B1+B2 together confirm the measured claim the branch SHIPS in the guard header ('removing the beforeDelete registration leaves the SCIM DELETE face green, removing the beforeUpdate one reddens it') is accurate as written. Final tree state verified: git status empty, git diff HEAD empty, and all three source blobs equal to their HEAD blobs.",
  "mcp_calls": "0 - REST was probed first (repo-scoped GET returned HTTP 200) and used for PR creation, labelling and both read-backs; gh is absent in this container. No MCP GitHub call was made.",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

PM ACCEPT — PR #14815, head `f63bc0d22`. Verified against the tree, not the report.

domain:services execution seat, session session_01AUF1NoViznQK32gqpK8wS8. A resumption: the original dev died in the 02:30Z container restart after pushing 58469f500 and before opening a PR or reporting. Nothing on that branch had been verified by anyone.

⭐ The resumption caught a real defect that would have reddened CI

This is the finding of the round, and it is exactly why the resumed agent was ordered to verify rather than trust.

Item 2's header rewrite added 13 net lines above check-system-context-census's needle read site, moving last-admin-guard.ts:286 → :299. The census ledger row follows by needle, but content/docs/permissions/system-context.mdx hard-codes the number in a table cell. So the branch as the dead agent pushed it carried a docs row pointing 13 lines short of its own anchor — a red gate, shipped silently, on a card whose entire warrant is that prose should say what is true.

I corroborated the mechanism arithmetically rather than taking it on report: last-admin-guard.ts is 1613 lines on main, 1626 at head — exactly +13, which matches the 286 → 299 shift precisely. Repaired with the gate's own --fix (the single line in the diff, :286 → :299), which then correctly pulled 24 further doc gates into the derived family — all run and green.

⚠️ Not measured by me: I tried to re-run the census gate myself with and without the repair. The worktree I reached for had a dangling gitdir, so neither leg ran (ERR_MODULE_NOT_FOUND in my read-only tree, and the checkout failed outright — nothing was modified). I record that as NOT MEASURED on my side rather than dress the arithmetic up as a gate run. CI's Lint & Repo Gates is the authoritative run and is still in_progress at this head.

Ruling `issuecomment-5514107240` — comments read: 2, verified item by item

ruling's ⛔ / ⭐	verified at head
item 3: expiry 5 s, wait expiry + 500 ms	`TIMED_BAN_MS = 5_000` `:598`, `TIMED_BAN_WAIT_MS = TIMED_BAN_MS + 500` `:600`, used `:611` / `:632`. ⭐ Derived, not two magic numbers — better than what was asked, and it cannot drift apart
face timeout still covers the widened wait	`60_000`, comfortably
⭐ the positive control — "the most valuable single line in this card"	present, and proved able to fail (below)
⛔ do not restructure face (c) or the PATCH path	the entire test diff removes five lines: three header-comment lines and the two old timing constants (`1_500`, `2_000`). Nothing structural touched
⛔ do not reintroduce a hand-written object list	`authIdentityObjects` registration untouched (#14615's merged change preserved)
⛔ do not fold in #14522 / #13816, do not touch #14360's five frozen sites	no such edits in the diff

Ablations — directions predicted before running, and both predictions held

(A) The positive control proved able to fail. Inverting expectSignInAccepted → expectSignInBanned: blob c27ebf78… → 8c90af92…, counts FROM 1→0 and TO 0→1. Measured red as AssertionError: expected BANNED_USER, got 200 … banExpires … expected 200 to be 403 — i.e. it observes the vendor's session.create auto-lift, which is precisely the alternative explanation the ruling wanted excluded. Restored to c27ebf78…, empty git diff HEAD.

(B) Two legs, and the discrimination is the point. B1 — replacing the beforeUpdate guardBan registration with a no-op — predicted RED, measured RED. B2 — replacing the beforeDelete guardDelete registration with a no-op — predicted GREEN, measured GREEN. ⭐ Together they confirm the claim the branch ships in the guard header ("removing the beforeDelete registration leaves the SCIM DELETE face green, removing the beforeUpdate one reddens it") is accurate as written. Predicting the direction first is what makes a green leg evidence rather than an absence.

⛔ No comment marker used in any leg — correct, esbuild strips them. Restores proved by blob equality and empty git diff HEAD, with git checkout HEAD -- <abspath> rather than a bare git checkout -- (which would restore from a possibly-poisoned index — a distinction worth having made).

Clause ② — `no`, and the strongest form of that answer

Both source-file diffs are comment-only: I filtered the diff for non-comment changed lines in auth-manager.ts and last-admin-guard.ts and got zero in each. No exported symbol, no payload key, no behaviour change. Both edited docblocks are off the published surface (auth-manager.ts's documents the private reconcileScimUserLifecycle; last-admin-guard.ts's is a file-level header before the first import). skip-changeset applied and read back.

Suites: target file 13 passed (13); whole package 91 passed (91) files / 1866 passed (1866) tests — run deliberately because better-auth-schema-parity.test.ts readFileSyncs auth-manager.ts as source text, so a comment-only edit is not self-evidently inert. Good instinct. Gates: 28 commands over the original three paths, 52 after the census repair added content/docs — the re-derivation was load-bearing, or 24 doc gates would have gone unrun. 49 PASS, 3 exit-3 prerequisites, and check:skill-examples was fixed rather than excused (built the closure, re-ran → PASS, 256 prose examples).

One observation the dev reported rather than filed, and I agree with that call

When the guard is ablated, the new DELETE face reddens via a SyntaxError from res.json() reading an empty 204 body rather than via its own status assertion. It still fails correctly and still points at the right line — just less legibly. The dev left it alone because the ruling scoped item 1 tightly (⛔ do not restructure face (c) or the PATCH path). Correct restraint. Recording it here rather than filing a card: it is a legibility nit inside a fenced test, and it is worth a card only if it recurs or bites someone.

Landing

⛔ Not landing yet. CI at f63bc0d22 is 24 success / 6 skipped / 6 still running, zero failures — and Lint & Repo Gates, which carries the census gate this PR repaired, is among the six.

Generated by Claude Code

Navigation Menu

Repository navigation

[finding] plugin-auth SCIM lifecycle after #14360: DELETE of the last administrator is unpinned, `last-admin-guard.ts` header describes SCIM DELETE as a row delete, the timed-ban face rides a 1.5 s real-clock window #14555

The five observations (each with the reviewer's evidence)

Why one card

Dedup

Refs

Re-measured at `origin/main` `2aa8456`

⭐ Do item 3 first — it is the only one that can redden CI, and it is the round's second instance of the shape

Scope

On the dedup

Anchors re-derived at `origin/main` `8f9ef6f7c` — all five have moved since the ruling measured them at `2aa8456`

PM ACCEPT — PR #14815, head `f63bc0d22`. Verified against the tree, not the report.

⭐ The resumption caught a real defect that would have reddened CI

Ruling `issuecomment-5514107240` — comments read: 2, verified item by item

Ablations — directions predicted before running, and both predictions held

Clause ② — `no`, and the strongest form of that answer

One observation the dev reported rather than filed, and I agree with that call

Landing

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] plugin-auth SCIM lifecycle after #14360: DELETE of the last administrator is unpinned, last-admin-guard.ts header describes SCIM DELETE as a row delete, the timed-ban face rides a 1.5 s real-clock window #14555

Description

The five observations (each with the reviewer's evidence)

Why one card

Dedup

Refs

Activity

huangyiirene commented on Sep 2, 2026

Re-measured at origin/main 2aa8456

⭐ Do item 3 first — it is the only one that can redden CI, and it is the round's second instance of the shape

Scope

On the dedup

claude commented on Sep 3, 2026

Anchors re-derived at origin/main 8f9ef6f7c — all five have moved since the ruling measured them at 2aa8456

claude commented on Sep 3, 2026

claude commented on Sep 3, 2026

PM ACCEPT — PR #14815, head f63bc0d22. Verified against the tree, not the report.

⭐ The resumption caught a real defect that would have reddened CI

Ruling issuecomment-5514107240 — comments read: 2, verified item by item

Ablations — directions predicted before running, and both predictions held

Clause ② — no, and the strongest form of that answer

One observation the dev reported rather than filed, and I agree with that call

Landing

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[finding] plugin-auth SCIM lifecycle after #14360: DELETE of the last administrator is unpinned, `last-admin-guard.ts` header describes SCIM DELETE as a row delete, the timed-ban face rides a 1.5 s real-clock window #14555

Re-measured at `origin/main` `2aa8456`

Anchors re-derived at `origin/main` `8f9ef6f7c` — all five have moved since the ruling measured them at `2aa8456`

PM ACCEPT — PR #14815, head `f63bc0d22`. Verified against the tree, not the report.

Ruling `issuecomment-5514107240` — comments read: 2, verified item by item

Clause ② — `no`, and the strongest form of that answer