Decision offers and responses
| Prompt | Stream | Status | Responses | Created |
|---|---|---|---|---|
| Thread credit economy (stake-to-post, prediction voting, ship bounty): decide now or defer past Season Zero? | half-team-protocol | open | 0 | 2026-08-23 18:30:18 |
| Problem→find transformation: when a problem card's winning proposal ships, does the card flip into a find (solution link, steward + proposer credited)? | half-team-protocol | open | 0 | 2026-08-23 18:30:12 |
| One thing per person per season (strict), or allow multiple finds/problems per card? | half-team-protocol | open | 0 | 2026-08-23 18:30:08 |
| Orphan adoption: when a card dies, can someone adopt its find/problem within the 24h ghost window (reviving it under the adopter, original steward credited)? | half-team-protocol | open | 0 | 2026-08-23 18:30:04 |
| SHIP IT? Preview at half.team/?preview=1 — entry flow (name→find→card), ghost cards, contribution-first arrival, 15 founding finds. Flip to production? | half-team-ship | open | 0 | 2026-08-23 18:29:50 |
| Winchester Press has two parallel pipelines racing for segments — V1 (Claude via forge_tasks, rich prompts) and V2 (Llama 3.3 70B inline, generic prompts). V2's 1-minute cron beats V1's 5/15-minute crons, so most segments get Llama quality. Three options to unify: (A) Keep V2 as orchestrator but dispatch Claude forge_tasks instead of Llama inline, (B) Kill V2 cron entirely and let V1 workers handle everything, (C) Keep CF Queue architecture but have handlers dispatch forge_tasks. All achieve single-pipeline. Which direction? | parameter | open | 0 | 2026-08-12 15:20:19 |
| Green-light PERMIT PULSE: Fresno commercial building permits, auto-classified weekly, sold as lead digest to trades (roofers/HVAC/solar) at $49-99/mo. Build = 3 piano-key workers (fetch, classify, digest-email) + Stripe link. The perfectly repeatable event strategy. | idea | open | 0 | 2026-08-10 21:06:13 |
| Two TapLab cards await your forecast taps. MM-B1-W1-02 Ships something public by Friday: https://taplab-card.b-9f2.workers.dev/c/mm-b1-w1-02 — MM-B1-W1-03 Talks to Linda this week: https://taplab-card.b-9f2.workers.dev/c/mm-b1-w1-03 | taplab | open | 0 | 2026-08-02 18:18:06 |
| THROWAWAY TEST: Verify action card pipeline works end-to-end | test | resolved | 1 | 2026-08-02 14:25:55 |
| Rotate our own credentials exposed by the /kv leak? | decision | resolved | 1 | 2026-08-02 14:17:10 |
| Webhook keeps dying — authorize durable poller kill on Brain? | decision | resolved | 0 | 2026-08-02 14:16:59 |
| Clearance proof-gate throwaway card. Tap PASS to confirm cookie auth works. | test | resolved | 1 | 2026-08-02 04:44:07 |
| SITUATION: Telegram can host far more than text walls — buttons that rewrite their own message into an outcome stamp, or the full deck UI running inside Telegram with signed user identity built in. QUESTION: Does Telegram become the deck's front door? STAKES: MINI-APP gets free verified identity (Sam as player two, no login build) and one-tap access from where dispatches already arrive. INLINE-CARDS keeps verdicts in-thread with zero web hop. BROWSER-ONLY keeps Telegram dumb and the web canonical. BUTTONS: MINI-APP / INLINE-CARDS / BROWSER-ONLY / EXPLAIN-MORE. | parameters | open | 0 | 2026-08-02 04:17:25 |
| SITUATION: Telegram bot messages are walls of text with floating buttons — unreadable while walking, taps don't serialize to the ledger. The Deck now exists at URLs. QUESTION: Shrink every bot message to a two-line envelope — one plain-language line + one /piece/ link, all reading and tapping happens on the card URL? STAKES: Envelope-only means Telegram is just the doorbell; doctrine, specs, and buttons all live at URLs where taps are ledger pieces. BUTTONS: ENVELOPE-ONLY = enforce across all bots. KEEP-MIXED = leave as is. EXPLAIN-MORE. | parameters | open | 0 | 2026-08-02 04:15:27 |
| Send card zero to Sam by text now, before the shared-deck plumbing exists? | mirror-match | open | 0 | 2026-08-02 04:09:30 |
| SCRIPT VERDICT: "The Founding Deal" — voice it? Single voice = Andrew warm correspondent. Duo = Ava carries the ledger citations. | copy | resolved | 1 | 2026-08-02 03:58:49 |
| PROOF GATE: End-to-end tap test for dealable-by-URL. Tap pass to verify. | test | resolved | 0 | 2026-08-02 03:48:40 |
| PROOF GATE: Dealable-by-URL integration test. Tap any button to verify the playable card pipeline works end-to-end. | test | resolved | 1 | 2026-08-02 03:44:38 |
| SITUATION: The database-migration task has been dead for a day because one specific key is missing from the build machine. The bigger key doctrine is being decided on other cards, but this one job is blocked now. QUESTION: Mint a replacement key today, ahead of the doctrine? STAKES: Waiting keeps the registry work frozen. BUTTONS: MINT-NOW = new key today, migrate to doctrine later. WAIT = unblock after the rules land. | tokens | open | 0 | 2026-08-02 03:20:56 |
| SITUATION: When a key goes missing today, the task just fails and a red gauge lights up — hours or days can pass before anyone notices. QUESTION: Should a missing key automatically deal you a card with a fix-it button instead? STAKES: Silent failures rot; a dealt card gets a tap within hours. BUTTONS: DEAL-CARD = missing key becomes a card in your deck immediately. ALARM-ONLY = keep the current red gauge. EXPLAIN-MORE. | tokens | open | 0 | 2026-08-02 03:20:47 |
| SITUATION: Some keys open everything; losing one is a disaster. Scoped keys open only one door each, but there are more of them to track. QUESTION: One master key per provider, or one narrow key per job? STAKES: Master = convenience, big blast radius. Scoped = containment, more bookkeeping. BUTTONS: MASTER = one powerful key per provider. SCOPED = narrow keys per purpose. EXPLAIN-MORE. | tokens | open | 0 | 2026-08-02 03:20:39 |
| SITUATION: Keys are scattered — some on the build machine, some inside individual services, some in config files. When one goes missing, work stops. QUESTION: Where does the single master copy of every key live? STAKES: One canonical home means one place to check, back up, and restore. BUTTONS: VAULT = one encrypted cloud store all machines pull from. PER-SERVICE = each service keeps its own key, no central copy. EXPLAIN-MORE. | tokens | open | 0 | 2026-08-02 03:20:29 |
| SITUATION: A task failed because a credential vanished from the build machine, and nobody knows how many keys exist across the system or where they live. QUESTION: Count every key first, before deciding the rules? STAKES: Rules written blind will miss keys; counting costs one background task. BUTTONS: CENSUS-FIRST = read-only inventory, then rules. RULES-FIRST = set doctrine now. PARALLEL = both at once. | tokens | resolved | 1 | 2026-08-02 03:20:20 |
| SITUATION: The UI dissection lab needs its intake — the drop point where a screenshot of good UI becomes a specimen on the ledger. QUESTION: Where do you drop a screenshot? STAKES: You capture while walking; any friction kills the habit. BUTTONS: TELEGRAM = send photo to existing bot, lands as specimen + R2 image. STAGE = DISSECT tab upload on supply-line-live. BOTH = Telegram now, stage tab later. | ui-lab | resolved | 1 | 2026-08-02 01:35:43 |
| Every action in this game gets a number so it can be audited later. Right now each list numbers its own pieces — it works, but there is no single master ledger. Create one permanent registry so every piece gets one number, forever? CREATE: a safe database change ships and numbers become global and stable. KEEP AS-IS: per-list numbers stay, nothing changes. | parameters | open | 0 | 2026-08-02 00:23:55 |
| You start each morning without a structured overnight summary. Should we send a morning briefing card at 4:45am that you acknowledge before starting your day? | idea | open | 0 | 2026-08-01 23:28:18 |
| The decision-card system just launched and this is its first card. Did it arrive and display correctly? | parameters | open | 1 | 2026-08-01 23:28:18 |
| Your daily project briefing is plain text. Should we redesign it as a visual dashboard with gauges that change based on what you do? | idea | resolved | 1 | 2026-08-01 23:28:13 |
| New users see controls like 'strike' and 'commit' with no explanation of what they do. Should we show a one-time explanation card the first time someone encounters each control? | idea | resolved | 1 | 2026-08-01 23:28:10 |
| Users can't report issues from inside the app — they leave and message you directly. Should we add a 'Report' button on every screen that files feedback into a visible tracker? | idea | resolved | 1 | 2026-08-01 23:28:08 |
| Yesterday's system log read like a story — real money moved, a bug blocked a bad trade, the ledger caught an error. Should we turn the daily activity log into a watchable replay anyone could follow? | idea | resolved | 1 | 2026-08-01 23:28:06 |
| Samuel (your son) could co-design a resource-management game for kids. Next step: one design session where he picks what to track and manage. No code yet. | idea | resolved | 1 | 2026-08-01 23:28:04 |
| Our automated tests check the API but skip the path a real user takes. Fix: send you one test card each morning — your tap proves the full user-facing pipeline works. Costs one tap per day. | parameters | resolved | 2 | 2026-08-01 23:28:02 |
| DECK CANARY: one synthetic card each morning; your ack proves render+auth+resolve+ledger end to end through the player's path. Costs one tap/day. Build it? | parameters | resolved | 1 | 2026-08-01 18:11:17 |
| TEST OFFER: supply-line-live proof gate validation — ignore this | test | resolved | 2 | 2026-08-01 16:16:23 |
| TEST OFFER: Supply Line integration test — tap any button to verify end-to-end | test | resolved | 1 | 2026-08-01 15:03:37 |
| GRADUATE: samuels-game? Zero-to-one player archetype — the game that helps build a supply line, not monitor one. Probe = design session where SAMUEL names his gauges and first requisitions. No code. | idea | resolved | 2 | 2026-08-01 14:18:15 |
| GRADUATE: proof-as-content (via Samuel)? The verified ledger rendered watchable = built-in content. Probe = private read-only /replay of yesterday's turn from existing tables. | idea | resolved | 2 | 2026-08-01 14:18:07 |
| GRADUATE: in-game-feedback? FIELD REPORT from any screen onto a status ledger. Probe partially self-ran: MINE FOR IMPROVEMENT button + observations table shipping with arrival detail view. | idea | resolved | 2 | 2026-08-01 14:17:59 |
| GRADUATE: first-use-education? One-time in-fiction briefing at first contact with each control. Probe = cards on strike/commit/requisition with localStorage seen-set. | idea | resolved | 2 | 2026-08-01 14:17:52 |
| GRADUATE: game-mechanical-pm? Work/PM/AI with game-mechanical UX. Probe = hj-pm daily_brief rendered as one SUPPLY section, zero new backend. | idea | resolved | 2 | 2026-08-01 14:17:46 |
| GRADUATE: turn-opens-with-briefing? FORGE-BRIEFING as SUPPLY opening card + morning dispatch with ACK button. All organs exist. | idea | resolved | 2 | 2026-08-01 14:17:40 |
| Nod is live. First tap through the real pipe — confirm? | parameters | resolved | 1 | 2026-07-31 01:44:20 |
| PROOF GATE TEST 2 — clean path | test | answered | 1 | 2026-07-31 00:51:18 |
| PROOF GATE TEST — ignore this | test | answered | 1 | 2026-07-31 00:50:29 |
| MCP proof gate test offer | proof-gate | resolved | 0 | 2026-07-30 22:08:49 |
| Settlement proof gate test: should we ship? | proof-gate | resolved | 2 | 2026-07-30 22:02:13 |
| Settlement test offer | test | resolved | 0 | 2026-07-30 21:12:05 |
| Settlement resolve test | test | resolved | 1 | 2026-07-30 21:12:05 |
| MCP verb test: should this offer appear in the queue? | test | resolved | 1 | 2026-07-30 21:07:59 |