# BaoLife — Polish/Hardening + Continued Improvement

## Objective

(1) Fix the two concrete follow-ups flagged at the end of the feel/pacing goal, then (2) discover and execute the next highest-leverage BaoLife improvements in verified waves until a natural stopping point. Craig trusts my judgment on what matters most after the two fixes.

## Original Request

"Hit the follow-ups and then proceed further. (1) Diamond clamp — choices with diamond costs apply even when unaffordable, driving diamonds negative. (2) Offline-digest stale death line — the digest showed 'You have died!' while the saved end-state was alive; investigate + fix. Then proceed: discover + execute the next highest-leverage improvements, I trust your judgment." (Pre-authorized big autonomous run.)

## Intake Summary

- Input shape: `existing_plan` (2 concrete fixes) + `open_ended` (discover/execute further).
- Audience: BaoLife players + Craig.
- Authority: `approved` — pre-authorized; trusts judgment on the open-ended part.
- Proof type: `test` + `metric` + `demo` — tests green, simulator metrics where relevant, in-app where it matters.
- Likely misfire: (1) churning low-value "improvements" instead of real player-felt wins — the open-ended part must pick HIGH-LEVERAGE work (Judge gates value); (2) diamond fix that breaks legitimate diamond spending or the IAP economy; (3) the digest "death line" being a symptom of a deeper offline-death-not-applied bug — investigate root cause, don't just hide the message; (4) regressing the now-green 1627 suite; (5) touching the avatar WIP.
- Blind spots: offline death may not be fully applied (status/routing) — the digest line could be exposing a real offline-death correctness gap; diamonds are premium currency (IAP) so clamping must not corrupt purchased balances; "proceed further" should prefer player-felt value (content/feel/retention/UX) over internal churn.
- Existing plan facts: preserved in state.yaml (the 2 follow-ups + their suspected locations).

## Goal Oracle

`The 2 follow-ups are fixed and proven (diamonds can NEVER go negative — asserted by test; the offline-death/digest inconsistency is root-caused and resolved consistently — no phantom 'you died' while alive, and a real offline death is applied + routes correctly), AND each subsequent improvement wave is implemented + verified green (tsc clean + vitest >= 1627 no regression; metrics/in-app where relevant), AND a final Judge/PM audit confirms the tranche delivered real player-felt value (not churn) and maps every change to a verified outcome with full_outcome_complete: true.`

## Goal Kind

`existing_plan` (2 fixes) → `open_ended` (discover/execute)

## Current Tranche

Continuous: (1) T001 diamond-clamp fix; (2) T002 Scout investigate offline-death/digest → T003 fix; (3) Scout discovers the next highest-leverage improvement candidates → Judge picks by player-felt value × confidence × reversibility → Worker executes in verified waves; keep advancing until the Judge audit says the tranche delivered enough real value. Prefer player-felt wins (content/feel/retention/UX) over internal churn.

## Non-Negotiable Constraints

- **Never edit legacy `ws/`.** Source of truth = TS `server/`.
- **DO NOT touch the avatar WIP** — `server/src/services/character/avatar.ts`, `avatarLibrary.*`, and the `Player.ts` DiceBear-migration change are a separate uncommitted effort; leave them alone (don't stage, don't edit).
- **Mirror loop changes** across online `PlayerSession.ts` + offline `GameEngine.ts`/`LoopManager.ts`.
- Diamonds are premium/IAP currency — the clamp must not corrupt legitimate balances or break IAP grants; never let a balance go negative, and don't silently swallow a legitimately-affordable spend.
- Investigate root cause before "fixing" the digest death line — it may expose a real offline-death-not-applied gap.
- After every change: `cd server && npx tsc --noEmit` then `npx vitest run` — stay green, total >= 1627. Update tests whose intent legitimately changed (+explain).
- iOS priority for any client work; Android parity.
- The open-ended part must pick HIGH-LEVERAGE, player-felt work — the Judge gates value; avoid churn/over-engineering.
- No production deploy unless Craig asks.
- Keep `notes/PROGRESS.md` updated.

## Stop Rule

Stop only when a final Judge/PM audit confirms: 2 follow-ups fixed + proven, the further-improvement waves delivered real verified value, suite green, with full_outcome_complete: true. Don't stop after the 2 fixes (the user said "proceed further"). Don't churn low-value work to pad the tranche — when the Judge decides further improvements are diminishing-returns or warrant owner steer, surface that and stop cleanly. Missing device access blocks a specific in-app check, not the goal.

## Slice Sizing

Largest safe useful slice = one coherent fix or one player-felt improvement end-to-end, verified. Group same-shape work. The open-ended waves should each be a real win, not a wrapper.

## Canonical Board

Machine truth: `docs/goals/baolife-polish-plus/state.yaml`. Human tracker: `docs/goals/baolife-polish-plus/notes/PROGRESS.md`. state.yaml wins on conflict.

## Run Command

```text
/goal Follow docs/goals/baolife-polish-plus/goal.md.
```

## PM Loop

On every `/goal` continuation: read this charter + state.yaml, re-check intake + likely misfire (esp. value-over-churn + root-cause-the-digest + don't-touch-avatar), work only the active task, assign Scout/Judge/Worker/PM, write a compact receipt, update board + notes/PROGRESS.md, advance to the next highest-leverage safe slice, review at phase/risk/final boundaries, and finish only with a Judge/PM audit mapping every change to a verified outcome with full_outcome_complete: true.