# 🤖 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.