futurefin-architecture-contract

Documents FutureFin's load-bearing architecture decisions, invariants, and known weak points for safe code changes.

1|Updated May 2, 2026
One-click install
npx skills add https://github.com/maxlainz/FutureFin --skill futurefin-architecture-contract-maxlainz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: futurefin-architecture-contract
Source: https://github.com/maxlainz/FutureFin/tree/main/.claude/skills/futurefin-architecture-contract
Command: npx skills add https://github.com/maxlainz/FutureFin --skill futurefin-architecture-contract-maxlainz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When modifying a mature self-hosted finance application, developers risk unknowingly violating settled design decisions — such as money serialization rules, cache invalidation semantics, or authorization boundaries — that were each forged by a documented production incident. This Skill loads the architectural contract before any change that touches routes, money handling, sessions, caching, migrations, or the projection engine, preventing regressions of already-fixed bug classes. ## Core Features & Use Cases - Decision Register: A numbered register (D1–D22+) where each entry records the decision, why it exists, the incident that forged it, and what breaks if violated — covering the installation singleton, Decimal-vs-f64 money rules, DB sessions, projection cache TTL/invalidation, and the embedded-Postgres container design. - Invariant Catalog: Explicit invariants like "reads never mutate", "engine purity (no I/O, no f64)", and "view=mine is a display filter, not authorization", each with regression-test pointers. - Weak Points & Boundary Guidance: Known weak spots (W1–W8) plus clear routing to sibling skills for build setup, FIRE math, change control, and debugging. - Use Case: Before adding a new mutating handler, load this Skill to learn that every mutation must await refresh_projection_after_mutation, that snapshot writes deliberately must NOT, and that transaction mutations invalidate conditionally based on savings_source mode. ## Quick Start Load the FutureFin architecture contract and tell me which decisions and invariants apply before I add a new API route that mutates ledger data.

Frequently Asked Questions about futurefin-architecture-contract

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely change FutureFin's architecture without breaking invariants?▼

Load this Skill before any change touching routes, money serialization, sessions, caching, or migrations. It lists each settled decision with the incident behind it and what breaks if violated; actual change gates live in the futurefin-change-control skill.

Why does FutureFin serialize some money amounts as f64 instead of strings?▼

Large projection and history series arrays serialize as f64 to cut roughly 30 KB of JSON and thousands of client-side parses, with under 1 euro precision loss over 70-year horizons. Scalars and KPIs stay Decimal-as-string, and the engine itself never uses f64.

Should transaction mutations invalidate the projection cache in FutureFin?▼

It depends on the savings_source mode. In budget mode transactions are display-only and never invalidate; in transactions_avg or budget_income_real_expense modes they are engine inputs and must invalidate via invalidate_projection_if_savings_uses_transactions, best-effort after commit.

Why does FutureFin use database sessions instead of JWT?▼

Sessions live in the database so logout and owner revocation are instant, with no signing-key management. On a single-node self-hosted deployment the extra DB round-trip per request is cheap, making stateless JWTs a net loss.

When should I not use the FutureFin architecture contract skill?▼

Do not use it for build or environment setup, FIRE math formulas like SWR and gross-up, step-by-step change gates, or live bug triage. Those belong to the build-and-env, fire-domain-reference, change-control, and debugging-playbook skills respectively.

Can I edit an already-shipped sqlx migration in FutureFin?▼

No. Editing a shipped migration changes its checksum and aborts startup on every existing deployment, since migrations are embedded and fail loud with no auto-repair. Always add a new migration file instead.