Daily reward and streak review

Daily Reward And Streak Review

Produce a Return Loop Contract that reinforces real recurring value and voluntary mastery without anxiety, hostage progress, or economy damage.

Atomic boundary

Own one daily/streak/calendar/mission loop: cadence, clock authority, eligibility, claim/grant/reversal, missed-day recovery, reward table, economy handoff, notification intent, abuse, support, and measurement. Do not own the whole game or app retention architecture, channel delivery, payment provider, or complete economy.

Begin with a draft artifact ID and reference sibling artifacts by owner and required decision. Let deterministic delivery tooling seal exact versions and digests later; never invent them during design.

Agent-first invariant

Build all declared states, recovery modes, timezone/DST handling, server clock, ledger, notification intents, abuse controls, experiments, canaries, and support tools now. In games, exposure may follow real progression/level gates; in utility apps, do not gate core functionality behind streak or tenure. A disabled loop has zero timers, notifications, background work, or reward grants.

Workflow

1. Define the recurring user value and behavior worth reinforcing. Reject a loop whose only reason is opening the product.
2. Read references/daily-reward-streak-systems.md; define audience, age mode, cadence, reset authority, locale/timezone, progression context, reward types, economy/inventory owners, and commercial interactions.
3. Model eligible -> available -> claim_pending -> grant_committed -> claimed plus missed, grace, frozen, repaired, expired, duplicate, offline, reversal, migration, and support-corrected states.
4. Define server-authoritative time, DST/timezone travel, device-clock abuse, late/out-of-order events, idempotency, restore/merge, and season/version migration semantics.
5. Specify reward curve, caps, duplicate ownership treatment, sources/sinks, baseline reachability, paid repair, VIP/gacha impact, comeback grants, and inflation/fairness simulations.
6. Hand notification intents to notification-strategy-review with user value, exact reminder request, consent/preference, cooldown, quiet hours, and stop conditions. The streak does not create emergency-message authority.
7. Define false-positive-safe abuse bands, support evidence, appeal/correction, experiments, countermetrics, canaries, and automatic pause/rollback.

Source verification

Retrieve current notification, payment, child/age, chance-based reward, store, privacy, and promotion authority for the exact product/platform/territory. Paid repair or gacha-linked rewards require transparent terms and current authority.

When not to use

• Use game-design-blueprint or app-design-blueprint for the complete retention/value architecture rather than one return loop.
• Use game-economy-review when sources, sinks, inflation, progression, and payer fairness are the primary artifact.
• Use notification-strategy-review when the job is permission, channel, frequency, privacy, deliverability, or cross-channel suppression.
• Use promotion-campaign-review for a time-bounded offer/event whose recurrence is campaign-driven rather than a durable daily state machine.

Guardrails

• Never make anxiety, shame, irreversible loss, or paid repair the main value.
• Preserve creations, earned ownership, purchases, relationships, and core app utility independently of streak state.
• No silent clock correction, duplicate grant, surprise expiry, pay-to-win multiplier, or gacha-currency inflation.
• Missed-day recovery must be proportionate and accessible; repeated deliberate churn/rejoin cannot become the optimal earning strategy.
• Measure D7/D30 retained value, core behavior, fatigue, support/trust, economy, payer/non-payer fairness, and abuse false positives—not claims alone.

Output contract

Return one typed Return Loop Contract with:

1. recurring value hypothesis and audience/progression/age modes;
2. cadence, clock/reset, eligibility, claim/grant/reversal, grace/repair, and migration state machine;
3. reward calendar/table with economy, inventory, paid/VIP/gacha, cap, and duplicate-ownership effects;
4. notification intent and suppression handoff;
5. abuse, support, correction, appeal, offline/restore, and idempotency rules;
6. event schema and cohort/economy/trust countermetrics;
7. simulation, experiment, canary, pause, rollback, and live-readback plan.

Complete only when every clock, missed-day, duplicate, offline, migration, refund/reversal, and support path has deterministic behavior and evidence.