Umbrella: prioritize math branch roadmap across feature tracks

[sacchen]

Create and maintain a prioritized expansion plan for math branches that fit phil's terminal-first mission.

Role of This Issue

This is the roadmap umbrella. It does not implement features directly.

Current Priority (Consolidated)

Now

• Edge-case reliability: correctness, fast answer, fast recovery #7 Edge-case reliability (correctness + fast recovery)
• Prefer SymPy built-ins over custom math plumbing #8 SymPy built-in adoption for core internals (supports Edge-case reliability: correctness, fast answer, fast recovery #7 and future tracks)

Next

• Add exact-first stats/probability helper surface #4 Stats/probability helper surface (implemented via SymPy-native primitives where possible)

Later

• Define CS/applied-math feature track (excluding #1/#4) #3 CS/applied-math (non-stats) helper surface

Why this order

• Reliability and correctness guardrails are prerequisites for adding surface area.
• Prefer SymPy built-ins over custom math plumbing #8 reduces custom math plumbing risk and should precede broader feature expansion.
• New feature families (Add exact-first stats/probability helper surface #4, Define CS/applied-math feature track (excluding #1/#4) #3) should land after reliability baseline is stable.

Milestone Mapping (proposed)

• v0.3: Edge-case reliability: correctness, fast answer, fast recovery #7 phase-1 + Prefer SymPy built-ins over custom math plumbing #8 phase-1
• v0.4: Add exact-first stats/probability helper surface #4 first wave
• post-v1.0 candidate: Define CS/applied-math feature track (excluding #1/#4) #3 phased rollout

Non-Goals

• No implementation details in this issue.
• No speculative branch creation without concrete user workflows.

Acceptance Criteria

• Priorities are explicit (now/next/later).
• Each active track has a scoped issue with acceptance criteria.
• ROADMAP.md reflects the selected order.

Linked Tracks

• Edge-case reliability: correctness, fast answer, fast recovery #7 Edge-case reliability
• Prefer SymPy built-ins over custom math plumbing #8 Prefer SymPy built-ins over custom plumbing
• Add exact-first stats/probability helper surface #4 Stats/probability
• Define CS/applied-math feature track (excluding #1/#4) #3 CS/applied-math (non-stats)
• Improve docs: onboarding, design philosophy, and roadmap #5 Onboarding/docs (phase-1 completed)

[sacchen]

Linking follow-up implementation issue: #8 (Prefer SymPy built-ins over custom math plumbing).\n\nRecommendation: treat #8 as a concrete candidate in this umbrella’s now/next/later ranking, since it is cross-cutting and reduces correctness/maintenance risk.

[sacchen]

Consolidation update:\n- #6 body is now the single source for now/next/later ordering.\n- #7 was narrowed to phase-1 reliability slice.\n- #8 was narrowed to SymPy-internals consolidation work.\n- #5 was closed as phase-1 complete.

[sacchen]

Added strategy anchor issue: #9 (Product principles and design decision framework).\n\nSuggestion: treat #9 as the decision rubric for now/next/later ranking updates in this umbrella.

[sacchen]

Roadmap carry-over note (post #7 closure):

Current state:

• Edge-case reliability: correctness, fast answer, fast recovery #7 phase-1 reliability is closed.
• Next active execution focus remains Prefer SymPy built-ins over custom math plumbing #8, then Add exact-first stats/probability helper surface #4, then Define CS/applied-math feature track (excluding #1/#4) #3 (as documented).

Small maintainability follow-up to include in #8 slice:

• scripts/release_notes.sh currently expects quadruple-fence markers for --body extraction.
• Make the extractor robust to triple/quad fences (or section-based parsing) to avoid future release-process friction.

This keeps release workflow reliability aligned with the same "fast recovery, low surprise" philosophy.