Repository navigation
id: implement grant lifecycle per #2254 spec — registry, pending holds, attestations, clawback/debt, revocation policy #2723
Description
Implementation follow-on for the grant lifecycle spec delivered for #2254 (spec doc: pkgs/id/doc/2026-10-30T11-55-00Z_design_grant_lifecycle.md — tracked at doc/2026-10-30T11-55-00Z_design_grant_lifecycle.md, pkgs/id/doc is a symlink to the repo doc/). Build nothing until the #2254 spec PR is reviewed/merged and the #2043 synthesis settles the spec's open parameters OP-1…OP-8 where a phase depends on them.
Scope (per spec sections, in landing order)
- Fingerprint registry + registration flow (spec §2) — canonicalisation + domain-separated SHA-256 fingerprint,
grant_keystable (primary key enforces one grant per key), Presented → Rejected/PendingHold flow, publisher-revocation batch intake. Lands first with §1: together they close id: investigate: tokens for real services — Steam-key grants, returns/refunds, revocation #2042 abuse case 1. - PendingHold lifecycle (§1) — TigerBeetle pending transfer at registration, window config per grant source snapshotted onto the grant record, idempotent post sweep, void flow, timeout re-issuance fail-safe.
- Attestation intake (§3) — service-signed external-event records (refund / chargeback / publisher revocation), authenticated source intake,
(source, external_ref)idempotency, transition dispatch. - Clawback / Shortfall / debt engine (§4) —
amount_outstandingattribution, partial clawback choreography, debt records, FIFO offsets, suspension effects, signed write-off. - Revocation-policy enforcement (§5) — policy ladder + issuance snapshot check at execution, recorded refusals, revocation-notice + grace registry.
Hard rule from the spec
No phase may enable Active-state grants before §4 exists to claw them back. Delisting (§6) is an accept_payment configuration act and is explicitly NOT part of this implementation.
Acceptance
- Each phase lands with tests tracing to the spec section it implements and to the id: investigate: tokens for real services — Steam-key grants, returns/refunds, revocation #2042 abuse cases (§8 of the spec) it closes or bounds.
- Open parameters OP-1…OP-8 are taken from id: design: ID currencies v1 #2043/operator decisions recorded on id: design: grant lifecycle implementation spec — pending-hold grants, key-fingerprint registry, clawback/shortfall, revocation policy (from #2042) #2254/id: design: ID currencies v1 #2043 — an implementation PR that silently defaults one is out of spec.
Filed by queue worker (repo-worker-code) Lane C, queue task 3409, as the implementation follow-on #2254's acceptance requires.
Metadata
Metadata
Assignees
Labels
Package/app: id (pkgs/ or apps/ in this repo)Large: multi-day or open-ended; expect staged check-insIntake review done: acceptance criteria, links, and normalized labels addedOrdinary priority (the default)Queue or user escalation stateFiled by the new-issue-creator jobQueue or user escalation stateQueue packet kind: verify, reproduce, and route this item
Activity
dezren39 commentedon Oct 30, 2026
Intake review
Fleet monitor intake pass (2026-10-30 run). Labels normalised this pass:
kind/enhancement,priority/normal,effort/l,status/needs-triage,meta/enriched(app/idwas already present). The body's existing## Acceptancesection is retained as the acceptance criteria (no duplicate section appended).Still live — and one gate has now cleared: the spec this issue is gated on has landed: PR #2722 ("id: grant lifecycle implementation spec (#2254)") merged 2026-10-30T12:29Z. Per the body's own gating text, what remains before building is the #2043 synthesis settling the spec's open parameters OP-1…OP-8 where a phase depends on them. No implementation code for the five phases exists yet.
Related: #2254 (spec), #2043 (synthesis), #2042 (abuse case 1, closed by phases 1+2 landing together).
Notes / risks: the hard rule bears repeating at pickup time: no phase may enable Active-state grants before §4 (clawback/debt) exists. This is a multi-phase epic (effort/l) — a worker should claim one phase per task, in the body's landing order, not the whole issue at once.
Suggested approach: when the #2043 synthesis settles, enqueue phase 1+§1 (fingerprint registry + PendingHold) as the first implementation task, citing this issue; keep later phases as follow-on tasks so each lands with its spec-traced tests.
developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
9 remaining items
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: done (triaged)
task: 7975 (triage, repo-health-code-pilot; repo-worker-code; OpenChamber scheduled lane 335a5d1f-bfc1-4831-99ea-850c8939a727)
state: Queue task completed as triaged; issue #2723 stays OPEN. No code/PR or duplicate follow-up task created. The existing phased scope is valid; phase 1 waits on the grant choices already tracked in #2296, then phases must preserve the §4 clawback-before-free-activation safety rule.
labels: removed queue/claimed, status/in-progress, work/assigned; set queue/blocked and status/blocked for the unresolved policy gate. Left issue classification and priority labels unchanged.
resume: after the Drew/operator decisions in #2296 and any relevant config defaults are recorded, re-triage/dispatch the first implementation phase (fingerprint registry + PendingHold lifecycle).
links: current main ece818d · #2296 #2296
developing-today commentedon Nov 8, 2026
🤖 Agent note · triaged (task 12075, lane code-q, direct)
Triage verdict — CONFIRMED real and current, and correctly BLOCKED on Drew/operator decisions that are already escalated on their own issues. No implementation exists; no fix packet enqueued.
Verified fresh 2026-11-08 at main
d94e6c74bbcfbd2d81a914dc2d94f2f9d926a958:doc/2026-10-30T11-55-00Z_design_grant_lifecycle.md(blobc4fd2782409ee6a8bdec3c5fd9f1e88aeeee4777). The "build nothing until the spec is reviewed/merged" condition is satisfied.grant_keyshit in the repo is the spec document itself. No registry, PendingHold, attestation, clawback, or revocation code exists.user/escalated,queue/blocked, priority/high. That decision is genuinely Drew's (a policy/economic parameter, already escalated on its own issue; it is not re-escalated from here). The id: design: ID currencies v1 #2043 synthesis (OPEN,user/escalated,queue/blocked) must likewise settle OP-1…OP-8 for the phases that depend on them, and the spec's hard rule stands: no Active-state grants before §4 clawback exists.Disposition: issue #2723 stays OPEN with
queue/blocked+status/blocked. Enqueueing an implementation packet now would send a worker into a build whose defining parameters are undecided — the packet would park on the same gate, so none is filed. This triage task completes astriaged; per the doctrine, that does not complete the issue.