|
| 1 | +# Product |
| 2 | + |
| 3 | +<!-- impeccable:product-schema 1 --> |
| 4 | + |
| 5 | +## Platform |
| 6 | + |
| 7 | +web |
| 8 | + |
| 9 | +## Stack |
| 10 | + |
| 11 | +delegated: plain HTML/CSS/vanilla JavaScript served by the existing FastAPI app; no frontend framework added for a local-first dashboard |
| 12 | + |
| 13 | +## Users |
| 14 | + |
| 15 | +One person reviewing their own private financial activity on a local machine. |
| 16 | + |
| 17 | +## Product Purpose |
| 18 | + |
| 19 | +PFA helps a person understand and improve their financial life over time through evidence-backed |
| 20 | +analysis, deterministic calculations, scenarios, and concise explanations. |
| 21 | + |
| 22 | +## Positioning |
| 23 | + |
| 24 | +Financial facts come from deterministic Python/SQLite services. The local model interprets those |
| 25 | +facts but is never the source of totals, balances, rates, or projections. |
| 26 | + |
| 27 | +## Operating Context |
| 28 | + |
| 29 | +The user imports synthetic or personal bank CSVs, reviews monthly changes, checks budgets and goals, |
| 30 | +asks natural-language questions, and simulates decisions. The application runs locally with SQLite |
| 31 | +and optional Ollama. |
| 32 | + |
| 33 | +## Capabilities and Constraints |
| 34 | + |
| 35 | +Transactions, accounts, budgets, goals, imports, analytics, scenarios, recurring-payment evidence, |
| 36 | +anomaly/trend signals, a CLI, and a FastAPI API are implemented. Initial behavior is read-only and |
| 37 | +advisory. No cloud APIs, money movement, brokerage execution, or hosted telemetry. |
| 38 | + |
| 39 | +## Brand Commitments |
| 40 | + |
| 41 | +The product name is PFA (Personal Finance Agent). Voice is concise, plain-language, evidence-backed, |
| 42 | +transparent about assumptions, and respectful of the user's decision authority. |
| 43 | + |
| 44 | +## Evidence on Hand |
| 45 | + |
| 46 | +`data/demo_transactions.csv` is synthetic demonstration data covering June–August 2026. No real |
| 47 | +financial claims, testimonials, or commercial proof should be fabricated. |
| 48 | + |
| 49 | +## Product Principles |
| 50 | + |
| 51 | +- Deterministic calculations outrank model guesses. |
| 52 | +- Local privacy is the default. |
| 53 | +- Show evidence and assumptions beside recommendations. |
| 54 | +- Keep the user in control; initial features are read-only. |
| 55 | +- Prefer small, explainable workflows over speculative infrastructure. |
| 56 | + |
| 57 | +## Accessibility & Inclusion |
| 58 | + |
| 59 | +The dashboard must support keyboard navigation, visible focus, semantic HTML, responsive layouts, |
| 60 | +adequate contrast, reduced-motion preferences, and text alternatives for status indicators. |
| 61 | + |
| 62 | +## Assumptions |
| 63 | + |
| 64 | +The UI surface, visual direction, and frontend implementation path are inferred because no visual |
| 65 | +brief or question mechanism was available in this session. Revisit these if the user supplies a |
| 66 | +different dashboard scope, brand direction, or frontend constraint. |
0 commit comments