Family Hub
A configurable household application for shared events and tasks, with optional allowance and meal-planning behavior—and enough product policy to keep a family app from becoming a generic calendar.
The starting problem
A household wants one dependable place to answer four everyday questions: what is happening, what needs doing, who owns it, and what changed. The obvious prompt is easy; the consequential product decisions are not.
The specification works through roles, household boundaries, private events, recurrence, independent assignments, guardian confirmation, allowance history, grocery behavior, retries, conflicts, and observable completion.
How the specification was shaped
Define the household boundary
Every record belongs to one household; roles and visibility decide what a person may see or change.
Separate shared work from individual state
A recurring task can create independent assignments, each with its own completion and approval history.
Make optional behavior explicit
Allowance tracking and meal planning are modules selected by the household, not assumptions baked into every realization.
Write the failure behavior
Retries cannot duplicate records or rewards, disabling a module preserves history, and conflicts keep an accepted current state.
A personal configuration
The example configuration makes the package concrete through choices for one household:
The household uses America/Chicago time, receives a daily digest, and gets upcoming-event reminders 24 hours ahead.
What using it should feel like
The adopter does not begin by deciding tables, routes, components, or a framework. They begin by deciding how their household works. The implementing agent receives the product boundaries and remains free to choose navigation, visual design, data architecture, reminder channels, and technical stack.
A faithful output should feel like a calm household coordination product rather than a dashboard assembled from generic CRUD screens. Current commitments should be obvious; private details should stay private; recurring work should not duplicate; history should remain understandable.
Current evidence status: the reference repository contains the specification and example configuration but no committed realization yet. This page describes the intended adoption and output—not an observed implementation result.