docs(todo): add composable curio architecture plan for Journey

[AutumnsGrove]

Journey Curio needs to be modular so components (milestones, code stats,
timeline) can be used independently as pages or vines.

[claude]

PR Review: Composable Curio Architecture Plan

Summary

This PR adds a well-structured planning section to TODOS.md for breaking Journey Curio into modular, composable components. The addition is documentation-only and adds architectural planning notes.

---

Strengths

Clear Goal & Context
The section opens with excellent framing—explaining both the "what" (modular components) and the "why" (flexibility for pages vs. vines). This aligns well with Grove's engine-first philosophy.

Thoughtful Decomposition
Breaking Journey into three logical sub-curios (Milestones, Code Stats, Timeline) makes sense architecturally. Each represents a distinct concern that could reasonably stand alone.

API-First Thinking
The composable API design shows good forethought—supporting both "fetch everything" and granular endpoints means consumers can opt into the level of detail they need.

Documentation Awareness
Including "Document component composition patterns for other curios" shows this isn't just about Journey—it's establishing patterns for the broader curio ecosystem.

---

Observations & Suggestions

1. Engine-First Pattern Compliance

Once implemented, these components should live in packages/engine/src/lib/ui/curios/ (or similar) and be exported via @autumnsgrove/groveengine/ui/curios. The TODO should explicitly note this to prevent duplication across apps.

Suggested addition:

- [ ] Implement sub-curios in engine package (not app-level)
- [ ] Export via @autumnsgrove/groveengine/ui/curios

2. Type Safety Considerations

The composable API will need clear TypeScript interfaces for each data shape. Consider adding a task like:

- [ ] Define TypeScript types for each sub-curio's data contract

3. Accessibility Note

Timeline visualizations can be tricky for screen readers. Consider adding:

- [ ] Ensure Timeline Curio provides accessible text alternatives

4. Error Handling Strategy

With modular fetching, partial failures become possible (e.g., milestones load but stats fail). The TODO might benefit from:

- [ ] Handle partial data failures gracefully in composed views

5. Placement in TODOS.md

The new section sits between "Future Enhancements" and "Landing Site Migration" which makes logical sense—it's the bridge between the current Journey implementation and the migration work. Good placement.

---

Code Quality: ✅ Excellent

• Follows conventional commits format in title (docs(todo):)
• Markdown formatting is clean and consistent
• No code changes means no bugs, performance issues, or security concerns
• Aligns with Grove's documentation style (warm, clear, grounded)

Test Coverage: N/A

Documentation-only change requires no tests.

Security: ✅ No Concerns

No code changes, no security implications.

---

Recommendations

Minor: Consider adding the four suggestions above as follow-up tasks when this plan moves into implementation. They're not blockers—just considerations that will surface during development.

Style: The formatting matches Grove's existing TODO patterns perfectly. Well done.

---

Verdict: APPROVED ✅

This is exactly what a good planning TODO should be—clear goal, logical breakdown, considers both immediate needs and broader patterns. The only improvements are minor additions that could be made now or during implementation.

Great work thinking through the architecture before jumping into code. This will save significant refactoring later.

---

🌲 Reviewed with Grove's engine-first and accessibility-first principles in mind