Repository navigation
id: decide: grant refund window length and whether pending tokens are spendable #2296
Description
The one product/policy pin in the #2065 design (doc/2026-10-29T12-10-00Z_design_refundable_grants_pending_transfers/ §3, PR #2293). Filed so it is decided deliberately rather than defaulted in code.
Decision 1 — window length
How long a Steam-key grant stays pending (unspendable) before it vests.
| Option | Refund exposure closed | User waits | Note |
|---|---|---|---|
| A. 14 days (Steam's refund window) — design recommendation | essentially all Steam refunds | up to 14 days | the rule the user experiences is the rule that protects the ledger |
| B. 48 hours | refunds inside 48h only | 2 days | leaves a 12-day hole that looks safe and is not |
| C. 14 days with early vest on evidence | most, sooner | hours–14 days | needs a trustworthy 'refund window closed' signal; Steam does not reliably expose one |
| D. none (post immediately) | none | 0 | the status quo #2065 exists to replace |
Decision 2 — spendability of pending tokens
Recommendation: not spendable, at all. Allowing purchases against pending balance reintroduces the clawback problem through the front door.
What I reviewed
The intake review on #2065 asked for this to be surfaced rather than buried; the design doc does that and carries a recommendation for each. Nothing here blocks the design doc landing — the value is a config, and the build issues read it from config.
Answer needed
Pick a window (A unless told otherwise) and confirm pending tokens are unspendable. A one-line answer closes this.
Acceptance criteria
- Decision 1 recorded on this issue: refund/vesting window length chosen (A/B/C/D or an alternative), with the chooser named
- Decision 2 recorded on this issue: pending tokens spendable or not, explicitly confirmed
- The chosen values are reflected as the config defaults the id: design: refundable grants via pending transfers — Steam premium tokens voidable through the refund window #2065 build issues read (issue or PR link recorded here), and this issue is closed with the decisions in the closing comment
Activity
developing-today commentedon Oct 29, 2026
CODE-1152
dezren39 commentedon Oct 29, 2026
Intake review — fleet monitor, 2026-10-29
user/reviewlane.## Acceptance criteriasection was appended (decisions recorded + reflected as config defaults). This is a decision only Drew can make; per the house rule the substance is: Decision 1 — how long a Steam-key grant stays pending before it vests: A. 14 days (design recommendation; closes essentially all refund exposure, users wait up to 14 days), B. 48 hours (2-day wait, leaves a 12-day exposure hole), C. 14 days with early vest on evidence (needs a trustworthy signal Steam doesn't reliably expose), D. none (status quo id: design: refundable grants via pending transfers — Steam premium tokens voidable through the refund window #2065 replaces). Decision 2 — whether pending tokens are spendable; design recommends not spendable at all. Recommendation on the issue: A + not spendable. A one-line answer closes it.developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7322 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
13 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: picked up
task: 7322 (triage; queue repo-health-code-pilot; worker repo-worker-code; lane c8b9355e-319a-4640-8096-7ad19480d151 — OpenChamber scheduled lane)
by: repo-worker-code
Fresh verification: issue #2296 is OPEN, carries user/review, and has no hard-stop labels. Its prior queue handoff expired; task 7322 is claimed again at attempt 7. The decision is genuinely Drew’s: choose the grant refund/vesting window and whether pending tokens may be spent. The issue already contains the alternatives and recommendation; design PR #2293 is MERGED and states the recommendation is 14 days (Steam’s refund window) with pending tokens visible but not spendable. I found no ruling in the current #2296 issue comments or the merged design PR comments/body. I will not decide policy or implement it.
next: surface the explicit decision request with the existing recommendation, change user/review to user/escalated, then block this task as escalated-to-user.
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: escalated — Drew policy ruling required
task: 7322 (triage; queue repo-health-code-pilot; worker repo-worker-code; lane c8b9355e-319a-4640-8096-7ad19480d151 — OpenChamber scheduled lane)
by: repo-worker-code
Fresh read: #2296 remains OPEN. The related design #2065 is closed and design PR #2293 is merged; its documented recommendation is a 14-day vesting/refund window with pending tokens visible but not spendable. No ruling is recorded in #2296 or PR #2293. Because this is a product-policy choice, I have not selected or implemented it.
Drew: please record both choices here.
Recommendation: A + A — 14 days, pending tokens not spendable. A one-line ruling such as “14 days; pending tokens are not spendable” is enough. The queue task is blocked as escalated-to-user until the ruling is recorded; no implementation work should choose a default on your behalf.
Labels: user/review was replaced by user/escalated; queue/blocked and status/blocked now reflect the task state.