🤖 fichas

The Oficina suite's card cabinet. One instance per team.

A ficha is an index card; a fichero is the cabinet it sits in.

Nothing is built. This repo is a design document and this README. There is no module, no binary and no schema yet.

What it is meant to be

Typed records — cards — with append-only entries attached to them, and references out to items in Docs, Sheets and Calendar. The first stack is a CRM: a Customer card, a Call Log entry, and a summary on the card that is derived from its entries and cites them.

The ancestor is DabbleDB, not Microsoft Access. What is worth stealing is schema-by-refinement, entity promotion and views-as-first-class-objects — not the generic-database-builder positioning, whose best execution still found no market. The part that could not have been built in 2008 is that the model replaces HyperTalk: you reshape a card type in a sentence rather than in a dialog.

Why it is not part of memoria

memoria is not an app of record and its decision 7 keeps it that way — it serves nobody to ask, so it cannot own content that needs an owner, a deletion story and a per-item visibility answer. Fichas owns its content and answers for it; memoria indexes it, cites it and reaches into it like any other sibling.

Fichas would also be the first app to serve the suite contract's server half — suite/README.md says that half "arrives with the first app that serves one, and the fixtures get corrected by the second". memoria is the waiting consumer.

The design

docs/superpowers/specs/2026-09-19-fichas-design.md.

Read §1 first: half of its decisions table is marked Proposed and has not been ruled on. A proposal read as a ruling is the failure this suite's specs work hardest to prevent.

Two things block slice 1, both in §10 — the seal-tier list (which card fields leave the seal, and therefore what can be filtered, sorted and grouped), and the reach credential ruling.