"Hold X cuques" achievement track (current-balance milestones)

[flipbit03]

Source

DM design discussion with @Lucas-chagas, 2026-04-29 (post-merge of the-big-juiceroo):

achievement de 'holdar 1kk' faz mais sentido / coloca mais marcos de holdar / porque faz com que o player pense antes de gastar / se vale a pena buildar pra farmar afk / ou se ele só junta

(Direct quote, lightly cleaned for clarity.)

What

A new achievement axis based on the current cuque balance (state.cuques), distinct from the existing lifetime-cumulative ones. Achievements fire when cuques >= threshold at any tick, regardless of whether the player ever spends those cuques.

Why

Cuque Mogul (lifetime_cuques >= 1_000_000) is trivial to unlock by playing for a while, no matter how aggressively you spend. There's no incentive to ever HOLD cuques — accumulation is rewarded the same as a full vault. Hold-X achievements add a deliberate save-vs-spend tension:

• "Should I dump 50k into another fingerer right now, or hold and bank toward the next milestone?"
• "Is it worth setting up a passive farm and walking away to let the balance climb?"
• A reason to occasionally NOT spend on cooldown.

Lucas's framing: "faz com que o player pense antes de gastar." A different gameplay rhythm than pure DPS-grinding.

Proposed achievements

Tier ladder (suggested, easy to tune):

ID	Threshold	Name (EN / PT_BR)
hold_1k	1,000	"Stash" / "Reserva"
hold_100k	100,000	"Hoard" / "Tesouro"
hold_10m	10,000,000	"Vault" / "Cofre"
hold_1b	1,000,000,000	"Treasury" / "Erário"
hold_1t	1e12	"Cuque Sovereign" / "Soberano do Cuque"

Five rungs gives a nicely-spaced ladder past Cuque Mogul (1M lifetime) without crowding. Names are placeholders — pick whatever fits the project's tone.

Implementation sketch

src/game/achievement.rs: add new entries with unlocked: |s| s.cuques >= 1_000.0 etc. Fits the existing predicate pattern; no schema change. The achievements set is keyed by stable string ids, which state::achievements_earned: HashSet<String> handles automatically — no migration code needed.

src/game/state.rs::tick_achievements() already iterates the catalog every tick and inserts newly-met ids; Hold-X just plugs in.

i18n strings: append to achievement_names and achievement_descs in both EN and PT_BR.

Open questions

1. Should hitting a Hold-X threshold and then immediately spending below it KEEP the achievement (current proposed behavior — once unlocked, stays unlocked)? Or should it require sustaining the balance for N ticks? Default: once-unlocked-stays-unlocked, matches every other achievement and the user's mental model.
2. Should the ladder go higher (1Qa, 1Qi)? Depends on how much late-game we're targeting; 1T already requires significant prestige stacking.
3. How does this interact with Prestige reset? On reset cuques drops to 0, but achievements aren't lost (per achievements_earned semantics — the HashSet isn't cleared). So hold-1t is "ever held 1T" — reaching it once is enough. Confirm this is what we want; if hold-X should be ungranted on prestige, that's a separate semantic and needs explicit clear logic in prestige_reset.

Acceptance criteria

• N new achievement entries (5 suggested) on state.cuques thresholds.
• EN + PT_BR strings.
• No save-schema changes; old saves transparently load.
• cargo fmt, cargo clippy -- -D warnings, cargo test all pass.
• Brief playtest in tu confirming the achievements unlock as the balance crosses each threshold.

Related

• Per-variant golden cuque catch counts (Lucky / Frenzy / Buff) #14 (per-variant golden counts) — orthogonal but ships in the same "more visibility into player progress" theme.
• The lifetime-achievement ladder ends at Cuque Mogul (1M); see follow-up issue for extending THAT track too.