LevPro sd-math — M5 audit, M6 account types, RRSP port

LevPro Port — sd-math M5 + M6 + RRSP Catch-Up Loan

Closed task: SDC/IT/Tasks/sdc-levpro-sdmath-complete.md (git history has full round-by-round detail).

What shipped

• M5 (audit artifacts): first-principles hand-derived tests, VB6 line-by-line cross-check (LevPro/modMath.bas), an independent algebraic re-derivation, docs/accuracy-audit.md, and docs/test-report.md (generated PDF-vs-computed diff table, 326 rows, 0 failures). No discrepancies found — interest-only and term-loan port confirmed correct.
• M6 (structure): account_type dimension ("taxable"|"registered"|"tax_free") added to LoanProfile/TermLoanProfile. registered/tax_free deliberately raise NotImplementedError — interest borrowed into those account types isn’t tax-deductible in Canada, and their growth is taxed under a different regime; turning off just the deduction would silently produce a wrong number.
• RRSP Catch-Up Loan (real LevPro analysis, not new scope): ported via strategies/rrsp.py::calculate_catch_up().
• Deferred, not built: Smith Manoeuvre / LifeCycle / Debt Swap (design notes only, docs/strategy-notes/ — zero VB6 or author source exists; Debt Swap needs Risks review before any build). RRSP Top-Up Loan. Registered/tax-free account modeling.

Commits (monorepo): f977eb2, 2ce1cca (Phase 1 doc consolidation) → d244a9b (M5) → 5d24c47 (M6 account types) → da76fdb/3596631 (test-report) → bc4bf22 (RRSP).

Key gotcha — VB6 source had a real gap

CalcRRSPAnalysis (modMath.bas:269) only wires the loan amount into a cashflow array and runs generic compound growth — the tax-refund/gross-up business logic lived in unpreserved UI event-handler code (checked two separate preserved copies of the VB6 source, both empty on this). Confirmed by direct grep both times before accepting the finding, per NEVER GUESS.

Resolution: Talbot (LevPro’s original author) supplied his own published booklet chapter (RRSP-Strats.docx, “Borrowing for RRSPs”) as an alternate authoritative source — it contains a complete worked example (Bob: $20k loan, 40% tax, 8% interest, 10yr) with a 16-value results table. The algorithm was hand-derived from the text and verified against all 16 values before any code was written; the implementation matches to within ~$5 of the source’s own $10 rounding.

General lesson: when a “port from source X only” rule hits a genuine gap in X, don’t invent — ask for a different authoritative source, then hand-verify the derivation against real worked numbers before delegating implementation.

Process note — fork subagents

Forks doing heavy build work occasionally returned instantly with 0 tool calls, echoing the launch status back as a fake “done” report. Fix: open fork prompts with “Execute synchronously with your own tools; do not background, do not delegate — you ARE the fork.” Logged to Core/IT/LESSONS.md; /task-continue’s creep-gate Rock-#1-naming edge case (task IS Rock #1) fixed directly in the skill (ai-config commit 1626cb9).

Open, handed to Talbot

• DESIGN.md SSOT (cross-business — SDC.com, MBR site, LevPro mini-app) — ✅ resolved 2026-08-29 by ai-config-design-ssot. It did not become a DESIGN.md: the monorepo’s own anti-fork rule (docs/design/brands.md) forbids that name, and a design system already existed repo-side. Instead, Core/Processes/Design/ now holds the target-agnostic principles — Design-Principles (F.A.S.T., 80/20 core-inputs, simplified inputs/outputs, highest-impact analysis) and Design — Apps (the L0–L3 progression ladder that mini-apps consume). Tokens/colors/type stay repo-side per the boundary rule in Design.
• Next task: sdc-sdapp-deploy-miniapp (Rock #2) — no longer blocked. Its UI work (mini-app, accessibility pass, template reorder) now has an SSOT to design against: Design — Apps for the ladder, monorepo/docs/design/ for tokens.