From bacc01d9f4b80de4912f16222226744a09cf0421 Mon Sep 17 00:00:00 2001 From: Emil Lerch Date: Wed, 13 May 2026 13:06:19 -0700 Subject: [PATCH] add accumulation SWR todo --- TODO.md | 48 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 39 insertions(+), 9 deletions(-) diff --git a/TODO.md b/TODO.md index fd94290..0b0e95b 100644 --- a/TODO.md +++ b/TODO.md @@ -16,15 +16,45 @@ manual-check accounts mechanism (medium effort, real user value). - **Configurable return cap per position — priority MEDIUM.** Default: none; cap outliers like NVDA. Should route through `projections.srf` cleanly. -- **"Not Retired Yet" accumulation-phase mode — priority HIGH.** - Accumulation phase with contributions before retirement. - Separate from life events — the simulation has two distinct phases: - accumulation (base spending = 0, contributions applied) and - distribution (searched-for withdrawal + spending model). Config: - `retirement_age::60` or `retirement_in::10`, plus - `annual_contribution::100000`. Safe withdrawal search only applies - to the distribution phase. Chart shows portfolio growing during - accumulation, peaking at retirement, then drawing down. +- **Accumulation-mode SWR rate column is misleading — priority LOW.** + When `retirement_age`/`retirement_at` is configured, the "Safe + Withdrawal" table's % column divides the SWR amount by the + CURRENT portfolio value, not the post-accumulation portfolio + value. The dollar amount is correct (it's the safe spending in + retirement, given the projected accumulation), but the % rate + comes out absurdly high (e.g., 22% of today's portfolio). The + Accumulation phase block already shows the median portfolio at + retirement, so the user can compute the real rate themselves — + but the SWR table's rate column should ideally divide by the + median post-accumulation value, or be suppressed when accumulation + is active. Decide which. +- **Chart vertical line at retirement boundary — priority LOW.** + The accumulation-phase spec called this "mandatory" but it was + explicitly deferred during implementation. The chart currently + shows the full `accumulation_years + horizon` span without a + visual marker for where accumulation ends and distribution + begins. Easier to add to the kitty-graphics chart than the braille + one. +- **Goal-seek over distribution horizon for W1 — priority LOW.** + Today the W1 ("set spending, find date") workflow reports the + earliest retirement at each user-configured `(horizon, confidence)` + cell. The philosophically correct version asks "when have I + accumulated enough wealth that the projection shows a 95% + probability of success withdrawing X per year from retirement + until age-of-death?" — i.e. goal-seek across both `accumulation_years` + AND `distribution_years` simultaneously, anchored to a configured + age-of-death. NP-shaped search; not worth optimizing until + someone wants it. +- **Per-person retirement_age — priority LOW.** + V1 of the accumulation-phase spec chose Option A: a single + household retirement boundary derived from the oldest configured + birthdate. Households where one earner retires significantly + earlier than the other would benefit from per-person + `retirement_age` fields on each `type::birthdate` record, with + contributions stopped per-person. +- **Configurable max_accumulation_years — priority LOW.** + Hardcoded at 50 years. Route through `projections.srf` if anyone + hits the cap. - Configurable MIN period selection (currently 3Y/5Y/10Y, exclude 1Y) - Multiple spending models: flat (current), decreasing (1-2% real annual decrease, Blanchett "spending smile"). Late-life healthcare better modeled as a life event.