Corpus adds don’t fetch metadata; no cue; no inspector

The answer to the operator’s question

It didn’t. organization.corpus.add / person.corpus.add → findOrCreateContent writes url, kind, url_domain, and counters to the content_items ledger — full stop. No title, no fetch, no enrichment. This is the same hole [[Corpus-Items-Not-Visible-On-Person-Cards-Coverage-Hard-To-Assess]] noted from the read side (“content_items has no title field”); this doc is the write side of it.

Three wants (one flow)

1. Fetch metadata on add — the way we already do it. The precedent is content-ingest’s source.add: a Jina metadata fetch (title, excerpt, authors, publisher, bibliographic fields — services/content-ingest/src/corpus.ts, the “METADATA-ONLY file” path). Entity corpus adds should ride the same machinery: the ➕ (and search-and-add’s per-row add) triggers the fetch, content_items grows the metadata columns (title, authors?, published_at?), and every corpus render hydrates from the ledger.
2. A visual cue on the row. Fetched → the row shows the title (host+path stays the un-fetched fallback per [[List-Rows-Show-Hostname-Only-Same-Domain-Entries-Indistinguishable]]); un-fetched or failed → a visible mark (badge/dot) that says “bare URL, metadata pending/failed”. The operator should never have to ask the question this issue opens with.
3. An inspector. Click a corpus row → see what the ledger holds and adjust it: title, kind, date, maybe authors. The in-place patch shipped for streams ([[Pulse-Streams-Need-Editable-Kind-And-User-Facing-Names]]) is the edit precedent; a corpus row wants the same, plus the fetched fields. Human adjusts, per [[human-in-drivers-seat]] — Jina’s guess is a candidate, not truth.

Machinery notes (jotted)

• content_items is SCHEMALESS — adding title etc. is free; the work is the fetch trigger + hydration reads + the row UI.
• Where does the fetch run? The resolver could call content-ingest over NATS at add time (sync — the cue is immediate), or a fire-and-forget that patches the ledger after (async — needs the pending/failed cue anyway). The failed/pending badge is wanted regardless, so async is viable.
• organization.detail / affiliation.detail / organization.affiliations would hydrate title via content_id → content_items (the join noted in the #20 issue).
• Backfill: existing bare corpus entries (all of them, today) want a re-fetch pass — same additive discipline as the person-name backfill (fill missing metadata, never overwrite operator-adjusted fields).

Open questions

• Sync fetch on add (immediate cue, slower ➕) vs async patch (fast ➕, needs pending state) — or Jina-on-add with a short timeout and async retry?
• Does the inspector edit content_items (shared ledger — edits visible to every referencing entity) or the per-entity corpus entry? Probably the ledger for metadata, the entry for kind.
• Does search-and-add’s one-click add fire the same fetch (it should — same verb underneath)?