← Context/ issues
Corpus items aren't visible on person cards — and corpus coverage across entities is hard to assess anywhere
The person card says 'Corpus items 3' and shows nothing — the operator can add a fourth without ever seeing the three that exist.
The symptom (screenshot-confirmed, 2026-07-24)
On the Lumina card → People → Jamie Merisotis: "Corpus items 3" — a count, a 🔍, a ➕, and no list. The operator can add a fourth item without ever seeing the three that exist. Links render in full; corpus doesn't.
Why this happened (a Phase 4 contract decision, now disproven)
organization.affiliations deliberately returns personal_corpus_count
only — the Augment-from-DB spec's Phase 4 scoped entry-listing out
("entries ride affiliation.detail in a later pass if the operator wants
it"). The operator wants it. First real session with the surface proved
count-only wrong: assuring corpus coverage is a core purpose of the
workbench, and you can't assure what you can't see.
Two layers to the fix (jotted)
Per-card visibility (the direct fix). Either extend
organization.affiliationsto returnpersonal_corpus[]entries (payload is small; 8MB NATS ceiling is nowhere near), or lazy-fetch per-person on expand via the existingaffiliation.detail(already returnsperson.personal_corpus— zero new verbs). Render with the same list shape as links: kind badge · host/title · date. Same question applies tocontent_itemshydration — org corpus rows render bare URLs today; titles live in the ledger unused.Coverage assessment (the real job). A view that answers "which relevant orgs/people have NO corpus items (or none newer than X)?" — a sortable roster of entities with link/stream/corpus counts, thin rows, red-zero highlighting. Could be a lens over the canonical layer, a workbench mode, or a didi verb (
/coverage). This is what "hard to assess" actually asks for; the per-card fix alone doesn't answer it.
Open questions
Eager (extend affiliations reply) vs lazy (affiliation.detail on expand) — lazy ships with zero service changes; eager is one query.
Do corpus rows want titles from
content_items(a join) or is URL+kind enough for v1?Where does the coverage roster live — and does it fold into the usability-iteration sweep alongside No Component Library UI Improvised Not Component Based?