add accumulation SWR todo
This commit is contained in:
parent
9cea368f2c
commit
bacc01d9f4
1 changed files with 39 additions and 9 deletions
48
TODO.md
48
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.
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue