futurefin-failure-archaeology

Documents rejected designs and settled bugs in FutureFin to prevent reintroducing them.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When maintaining a long-lived codebase like FutureFin, developers repeatedly risk re-proposing designs that were already investigated and rejected, or reintroducing bugs that were already fixed. This Skill provides the historical chronicle of every major investigation, dead end, and removal as symptom → root cause → evidence → status, so no future session re-fights a settled battle. ## Core Features & Use Cases - Settled battles table: A catalog of 23 rejected or removed approaches (age-based retirement triggers, per-asset contribution config, external-database mode, OAuth login, and more) with commit hashes, versions, and migration files as evidence. - Detailed forensic entries: In-depth write-ups of root causes, such as the table-CSS saga, inverted SQL binds between Household/Mine branches, hybrid-density deflation bugs, and the five traps of embedding PostgreSQL in the Docker image. - Use Case: Before proposing to add a density parameter to the get_projection MCP tool or to make the container honour DATABASE_URL again, load this Skill to learn these were deliberate non-additions or scheduled removals, with the reasoning and CI guards that pin them. ## Quick Start Load the futurefin-failure-archaeology skill before proposing any change to FutureFin's projection engine, Docker image, authentication, or database topology to check whether the idea was already rejected.

Frequently Asked Questions about futurefin-failure-archaeology

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

FAQPage Schema
How do I check if a FutureFin design idea was already rejected?▼

Load this Skill and scan the settled battles table, which lists 23 rejected or removed approaches with the reason, commit hash, version, and migration file for each. Detailed entries in section 2 explain the full root-cause analysis for the major ones.

What designs were rejected in FutureFin and why?▼

Rejected designs include age-based retirement triggers, per-asset contribution config, deflated engine simulation, migration auto-repair, GET handlers that purge rows, OAuth login with external IdPs, ZIP/CSV export, and Postgres as a separate compose service. Each entry documents the failure mode and evidence.

When should I not use the failure archaeology skill?▼

Do not use it for triaging a live bug step by step, which belongs to the debugging playbook, for forward-looking improvement ideas, which belong to the research frontier, or for the current invariants themselves, which the architecture contract owns.

Why does FutureFin reject re-adding an external database mode?▼

External-database mode was removed in v4.0.0 because it lacked every safety guarantee of the self-contained image: no pre-migration backup, no pg_upgrade, no ordered postmaster shutdown, and no volume guard. The entrypoint now refuses a leftover DATABASE_URL loudly instead of starting empty.

How is the failure history verified against the actual code?▼

Every entry cites commit hashes, release versions, and current file paths so you can re-verify with git show and by reading the referenced source. The chronicle was mined from the git log and CHANGELOG and cross-checked against the code as of specific versions.