invitation-scope-gates: `cancel-invitation` writes `status:'canceled'`, a value absent from the spec `InvitationStatus` enum (spec-vs-platform-object divergence)

[huangyiirene]

Symptom

cancel-invitation writes status: 'canceled' onto the sys_invitation row. But the spec enum this item's source names as the authority does not include canceled:

• Spec (authority named by the item): InvitationStatus = z.enum(['pending', 'accepted', 'rejected', 'expired']) — packages/spec/src/identity/organization.zod.ts:105. Four values, no canceled.
• Platform object (what actually gets written): a divergent 5-value select including canceled — packages/platform-objects/src/identity/sys-invitation.object.ts:214: status: Field.select(['pending', 'accepted', 'rejected', 'expired', 'canceled'], …).

Consequence: anything validating an invitation against InvitationSchema (which composes InvitationStatus) rejects a canceled row. Both refs confirmed present on origin/main.

Root cause

A spec-vs-platform-object contract divergence: the two definitions of the invitation status vocabulary disagree by one value. The platform object treats canceled as a legitimate terminal state (it is even used in a listView filter, sys-invitation.object.ts:158 filters status in ['expired','rejected','canceled']), while the spec enum omits it.

Decision needed (routing / authority)

This needs a maintainer ruling on which side is authoritative, then reconcile the other:

• If the spec enum is the contract of record → add canceled to InvitationStatus (organization.zod.ts:105). This is the likely direction, hence domain:spec.
• If the spec deliberately excludes canceled → the platform object and the cancel-invitation writer must stop producing it (use rejected/expired semantics, or drop the value).

Filed under domain:spec (the enum) with a note to reconcile the platform object; flag the decision rather than assume the fix side.

Reproduction

1. Create an invitation (status:'pending').
2. cancel-invitation on it.
3. Read the row → status:'canceled'.
4. Validate that row against InvitationSchema / InvitationStatus → rejected, because canceled is not in the spec enum.

Source

Extracted from the QA run #7663 (framework 92f26f7, console 09987b680).

[os-zhuang]

Claim: PM loop round 3 (spec lane)
Session: session_01JY2Q5Xto1u8YHADgrZDTnk
Branch: claude/issue-7726-invitation-status-canceled
Worktree: cloud dev session (own container)
Domain: domain:spec
File surface: packages/spec/src/identity/organization.zod.ts (InvitationStatus enum, ~:105) + pins + generated closure; verify-only reads of packages/platform-objects/src/identity/sys-invitation.object.ts (the 5-value select + the :158 filter — evidence, not an edit site unless the premise fails). Stop on breach; explain in the report.
Container & model: M (contract reconciliation under a premise-hinged PM ruling), mode:cloud, model: opus
Serial constraints cleared: no in-flight writer on organization.zod.ts (open PRs + queue checked 14:2xZ); in-flight lane cards touch translation/filter/secret/i18n-resolver/userActions surfaces — disjoint.

PM ruling (third-tier, premise-hinged — recorded here for the dispatch): the spec enum ADDS canceled (widening, minor lean), because the platform ships it as a legitimate terminal state — the cancel-invitation writer produces it and the object's own listView filters on it. Premise the dev verifies FIRST: cancel-invitation is a real, user-reachable shipped action writing canceled (not dead code), and no consumer branches on the enum in a way that a fifth value breaks. Premise fails ⇒ stop and report the fork (the remove-the-writer direction is a shipped-behavior removal — maintainer territory). Veto window: this ruling is listed in the round report.

---

Generated by Claude Code

[os-zhuang]

{
  "issue": 7726,
  "status": "done",
  "branch": "claude/issue-7726-invitation-status-canceled",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/7782",
  "premise_still_valid": true,
  "summary": "Both halves of the PM ruling's premise verified on origin/main before any edit, so the ruled direction (widen the spec enum) was implemented. (1) cancel-invitation is a real user-reachable shipped writer: better-auth's organization plugin writes status:'canceled' at crud-invites.mjs:448-451 (and again at :163-166 via cancelPendingInvitationsOnReInvite), the route is declared at auth-route-ledger.ts:146/:274, a user reaches it from the cancel_invitation list_item action at sys-invitation.object.ts:66-80, and the client SDK exposes it at client/src/index.ts:2060-2068. (2) No consumer branches over the enum in a way a fifth value breaks: InvitationStatus has exactly three consumers (InvitationSchema, organization.test.ts, the ADR-0122 type-alias pin), no switch/exhaustiveness/mapping table; positive control confirmed the search finds switch (status) elsewhere in the repo (datasource-connection-service.ts:196, capability-preflight.ts:70, protocol-handshake.ts:283), none of them this enum. InvitationStatus therefore gains 'canceled' as its fifth value, and sys_invitation.status now reads its select options FROM the enum rather than repeating them as a literal — the same binding shape the neighbouring role field already uses (BUILTIN_MEMBERSHIP_ROLE_OPTIONS, ADR-0108), so it is the established convention on this object, not a new one. Output is identical to the old literal (same five values, same order), so no generated translation moved. Worth recording for the next reader: the vocabulary is the union of two upstreams — better-auth contributes 'canceled' and has no expiry concept, while 'expired' is ObjectStack's own — which is why neither side's list was complete alone. The .describe() text was deliberately left unchanged: neighbouring describes in this file are one-line summaries and none enumerate per-value meanings, so the semantics went into the JSDoc where this file already puts explanation.",
  "tests": "All run on the final tree, under the shared verification lock. pnpm --filter @objectstack/spec test => 'Test Files 378 passed (378) / Tests 9950 passed (9950)'. pnpm --filter @objectstack/platform-objects test => 'Test Files 14 passed (14) / Tests 316 passed (316)' (13 before, +1 new pin file). pnpm --filter @objectstack/spec --filter @objectstack/platform-objects typecheck => both 'Done' (spec's check:test-typecheck OK, debt ledger unchanged at 57 files / 265 errors). pnpm --filter @objectstack/spec check:generated => 'All 13 generated artifacts are up to date' (gen:docs was the one stale artifact, regenerated; the diff is the enum line plus one bullet in content/docs/references/identity/organization.mdx). check:merge-driver / check:adr-anchors / check:spec-parsed-alias => green ('1512 bare z.input aliases, 826 pinned isomorphic, 686 paired with an XParsed. OK'). node scripts/check-nul-bytes.mjs => OK (7131 files), plus a targeted control-byte self-scan of the five touched files => no hits. REVERSE VERIFICATION, direction predicted before running, and run on each side where its source is actually read (platform-objects resolves the spec through the workspace symlink to dist; the spec suite reads src): reverting the enum to four values => predicted red on the three cases asserting the fifth, actual '3 failed | 19 passed' with zod reporting expected one of pending|accepted|rejected|expired; re-literalizing the object's options to the old four-value list (simulating the exact drift the binding prevents) => predicted red on parity, actual '2 failed | 3 passed' (parity case + canceled case). Reported honestly rather than template-shaped: with the binding in place, reverting ONLY the enum leaves the parity assertion GREEN, because the object follows the enum down — that is by construction, and it is precisely why the standalone canceled case and the listView-filter case exist; a parity test alone could not fail for the original defect. Restorations used git checkout and a file copy, never git stash; the tree was confirmed byte-identical to the commit afterwards. GATE STATUS ON CI: not known — reported at draft-PR time per the dispatch contract, no idle-polling. One process note for the PM: check:generated flagged api-surface/ stale right after the reverse verification purely because restoring files by checkout bumps src mtimes past dist and that staleness rule is mtime-based; a full spec build (with declarations, not OS_SKIP_DTS=1) cleared it and the closure was re-run green on the final tree.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #7781: the client SDK types the same invitation status union by hand at packages/client/src/index.ts:2030 and is missing 'expired' (the opposite divergence to this card); observation-class, type-level only, labelled finding with no pm:queue"
  ]
}

Note on the platform's PR subscription: this session was auto-subscribed to #7782 with the standard stay-resident/drive-to-green instructions. Per the maintainer ruling of 2026-08-11 (#7512) recorded in .claude/agents/os-dev.md, the dispatch contract outranks that posture for a dispatched dev session — reporting at draft-PR time, no idle-polling and no self check-ins for CI; CI convergence, the ready-flip and landing stay with the PM. Nothing beyond the standard subscription text was involved.

---

Generated by Claude Code