new(context-v, issues, plans): three usability findings from the first real workbench session, plus the didi-chat team-page plan stub

The first working session on the Org Workbench (Lumina Foundation card)
surfaced three Usability issues, each screenshot- or live-case-grounded:
pulse streams need an editable kind and a user-facing name (Today's
Credentials is not a bare classifier); a person's bio on another org's
domain (Merisotis on bipartisanpolicy.org) is an affiliation signal the
card silently drops — the promote-to-affiliation affordance is missing;
and corpus items are invisible on person cards (count-only, a Phase 4
contract decision now disproven in practice) with no coverage view
anywhere — you can't assure what you can't see.

Also stubs the first agent-action plan: didi chat scoped to the
workbench view, proving action = verify an org's team page → staged
people objects in STATE → operator alters/verifies → on approval the
agent writes persons + affiliations. The stub names the prior art it
composes (chat_propose gating, the person.* write path,
crawl-fetch-ingest's team-page cascade, Response-Reviewer staging
grammar) and leans small-spec-first.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014zrFkWSVgTkoQyiobdBjrd

Author: mpstaton

context-v/issues/Corpus-Items-Not-Visible-On-Person-Cards-Coverage-Hard-To-Assess.md

@@ -0,0 +1,64 @@
+---
+title: "Corpus items aren't visible on person cards — and corpus coverage across entities is hard to assess anywhere"
+lede: "The person card says 'Corpus items 3' and shows nothing — a count with no list, no titles, no URLs. Since a core purpose of this work is assuring corpus items exist for every relevant organization and person, the operator can neither inspect what the 3 are nor assess coverage across the entity graph."
+date_created: 2026-07-24
+date_modified: 2026-07-24
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Fable 5
+semantic_version: 0.0.0.1
+tags:
+  - Issue
+  - Usability
+  - Augment-It
+  - Corpus
+  - Org-Workbench
+  - Persons
+  - Coverage
+status: Open · Jotted
+---
+
+# Corpus items invisible on person cards; coverage unassessable
+
+## 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)
+
+1. **Per-card visibility (the direct fix).** Either extend
+   `organization.affiliations` to return `personal_corpus[]` entries
+   (payload is small; 8MB NATS ceiling is nowhere near), or lazy-fetch
+   per-person on expand via the existing `affiliation.detail` (already
+   returns `person.personal_corpus` — zero new verbs). Render with the
+   same list shape as links: kind badge · host/title · date. Same
+   question applies to `content_items` hydration — org corpus rows
+   render bare URLs today; titles live in the ledger unused.
+2. **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]]?

context-v/issues/Person-Bio-Pages-Are-Affiliation-Signals-Not-Just-Identity-Links.md

@@ -0,0 +1,71 @@
+---
+title: "A person's bio page on another org's site is an affiliation signal, not just an identity link — the UI should offer the promotion"
+lede: "Jamie Merisotis has a bio on bipartisanpolicy.org — filed today as an 'other' identity link, full stop. But that URL is really three facts: a static profile (identity link — correct), evidence of an affiliation with an org we may not have yet (Bipartisan Policy Center), and an observation with a source. The card captures the first and silently drops the other two."
+date_created: 2026-07-24
+date_modified: 2026-07-24
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Fable 5
+semantic_version: 0.0.0.1
+tags:
+  - Issue
+  - Usability
+  - Augment-It
+  - Affiliations
+  - Persons
+  - Identity-Links
+  - Org-Workbench
+status: Open · Jotted
+---
+
+# Person bio pages are affiliation signals
+
+## The rule of thumb the operator already uses
+
+**If it's static, it goes in identity.** Profiles, bios, involvement pages
+→ `personal_links[]`. That instinct is right and stays.
+
+## What gets dropped today
+
+A bio hosted on *someone else's* org domain carries more than identity.
+The live case: Jamie Merisotis (Lumina Foundation card) has links to
+linkedin, luminafoundation.org, forbes.com, **bipartisanpolicy.org**, and
+wikipedia — every non-linkedin one badged `other`. The bipartisanpolicy.org
+link is really:
+
+1. an identity link (captured ✓)
+2. **evidence of an affiliation** with the Bipartisan Policy Center — an
+   organization worth its own record, which may not exist yet (dropped ✗)
+3. **an observation** — `affiliated_with`, source: that URL (dropped ✗)
+
+The schema handles all three today (`person.affiliate` is N-per-person and
+match-or-CREATES the org; observations ride along automatically). Only the
+UI path is missing: from a person's link row, there's no "this is also an
+affiliation" affordance.
+
+## Direction (jotted)
+
+- **A "promote to affiliation" action on person link rows** — takes the
+  link's domain as the org seed → org match-or-create (the
+  `AddPersonInline` gate pattern, inverted: person is fixed, org is being
+  resolved) → `person.affiliate` with optional role → observation cites
+  the bio URL as source. Three clicks, no retyping.
+- Composes with the existing candidate machinery: `resolver.search` by
+  domain (D4 already matches `domains[*].domain`) makes the org
+  suggestion nearly free.
+- Same promotion logic belongs in the search-and-add rail eventually —
+  a result row that IS a bio page could offer add-link *and*
+  promote-to-affiliation.
+- Sibling fact: those `other` badges show `inferLinkKind` needs richer
+  vocabulary (org-bio / press-profile / wikipedia), or the same
+  editable-kind treatment as [[Pulse-Streams-Need-Editable-Kind-And-User-Facing-Names]].
+
+## Open questions
+
+- [ ] Where does the affordance live — a per-row action on the person
+  card's link list, a didi-chat verb, or both?
+- [ ] When the org doesn't exist: create thin (name + domain from the
+  bio page) or route through a full org-resolution gate first?
+- [ ] Should the observation's free-text predicate distinguish
+  `has_bio_at` from `affiliated_with`, letting the human upgrade later?

context-v/issues/Pulse-Streams-Need-Editable-Kind-And-User-Facing-Names.md

@@ -0,0 +1,67 @@
+---
+title: "Pulse streams need an editable kind and a user-facing name — 'Today's Credentials' is not an 'updates_index'"
+lede: "The auto-inferred stream kind is wrong often enough to need a correction path, and streams have no name field at all — but real publication streams have titles. Lumina's https://www.luminafoundation.org/topics/todays-credentials/ is called 'Today's Credentials', and the operator can neither fix its classifier nor record what it's called."
+date_created: 2026-07-24
+date_modified: 2026-07-24
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Fable 5
+semantic_version: 0.0.0.1
+tags:
+  - Issue
+  - Usability
+  - Augment-It
+  - Pulse-Streams
+  - Org-Workbench
+  - Media-Streams
+status: Open · Jotted
+---
+
+# Pulse streams need editable kind + user-facing names
+
+## The two symptoms (same list, same row)
+
+1. **Wrong kind, no correction path.** `inferStreamKind` guessed a
+   classifier for Lumina's Today's Credentials stream that doesn't fit
+   (a `/topics/...` path isn't a blog index in the usual sense, and the
+   operator reading the row can see it's mislabeled). The org card's
+   streams list renders the kind badge but offers no way to change it —
+   the additive-only write discipline (`organization.streams.add`,
+   `shapeStream`) has add and nothing else. The ➕ form does accept a
+   manual kind at add time, but a stream that arrived with a wrong
+   inferred kind is stuck with it.
+2. **No name at all.** `media_streams[]` entries carry
+   `{url, kind, party, url_domain, added_at}` — no `name`/`title` field.
+   Many organizations title their publication streams ("Today's
+   Credentials", "Insights", named newsletters); the operator knows the
+   name at add time and has nowhere to put it. The card then renders a
+   bare hostname, which reads as noise once an org has three streams on
+   the same domain.
+
+## Directions (jotted)
+
+- **Schema is SCHEMALESS — adding `name` is free** on the entry shape;
+  the work is the verb + UI, not migration. `shapeStream` gains an
+  optional `name`; the ➕ form gains a name input.
+- **An update verb** — `organization.streams.update` (match by URL,
+  patch `kind`/`name`) breaks new ground: the entity-list discipline so
+  far is strictly additive. Precedent for careful updates exists
+  (`resolver.update_org` edits name/slug with the old slug pushed into
+  aliases). The same match-by-URL + patch shape presumably extends to
+  `org_links` kinds later (same misclassification risk there —
+  see the person-card 'other' badges).
+- **UI**: kind badge and name become click-to-edit on the stream row —
+  the view-AND-edit-in-place ruling already governs this card.
+- **Naming convention check**: confirm the observed classifier value and
+  whether `inferStreamKind`'s vocabulary (blog_index / newsroom / rss /
+  youtube_channel / substack …) wants a `topic_hub` or `publication`
+  member, or whether operator-set names make finer kinds unnecessary.
+
+## Open questions
+
+- [ ] Does `kind` even matter once `name` exists, beyond scan-mode
+  routing (rss/blog_index get the dependable scan path)? Maybe kind
+  collapses to "scannable-how" and name carries the meaning.
+- [ ] Update semantics vs the additive discipline — is match-by-URL patch
+  acceptable, or does correction mean remove+re-add with provenance?

context-v/plans/Didi-Chat-In-Org-Workbench-Verify-Team-Page-Into-People-Objects.md

@@ -0,0 +1,93 @@
+---
+title: "Didi chat joins the Org Workbench — first agent action: verify a team page and turn it into approved people objects"
+lede: "Integrate the didi chat rail with the Org Workbench so agents can take view-scoped actions. The proving action: point didi at an organization's team page; it returns people objects INTO STATE (not the DB), the user alters or verifies them on the card, and only on approval does the agent write person + affiliation records — to SurrealDB, or CSV, or whatever backend the workspace is using."
+date_created: 2026-07-24
+date_modified: 2026-07-24
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Fable 5
+semantic_version: 0.0.0.1
+tags:
+  - Plan
+  - Augment-It
+  - Org-Workbench
+  - Didi-Chat
+  - Agent-Actions
+  - Team-Page
+  - Persons
+  - Affiliations
+status: Draft · Stub
+---
+
+# Didi chat in the Org Workbench — team page → people objects
+
+<!-- stub — captured 2026-07-24 from the operator's dictation; to be
+developed before execution. Sequenced AFTER the jotted usability issues
+or alongside them; not yet slotted against a spec. -->
+
+## The ask, verbatim-adjacent
+
+1. Integrate didi chat into the Org Workbench view so agents can take
+   certain actions scoped to what the operator is looking at.
+2. The proving action: **verify the team page of an organization** —
+   didi fetches/parses it and returns **people objects in STATE**,
+   presented on/next to the card.
+3. The user **alters or verifies** the staged people (names, roles,
+   dedupe against candidates).
+4. **On approval**, the agent creates the person objects — and their
+   affiliations to the org — in the DB instance (or CSV if that's the
+   active backend) for everyone on that team page.
+
+## Prior art this composes (don't reinvent)
+
+- **Chat verb registry + propose/approve gating** —
+  `services/workspace/src/chat.ts` (`chat_answer` / `chat_propose` /
+  `chat_invoke`); the CURATOR_CHAT_VERBS slab is the template for an
+  ORG_WORKBENCH_CHAT_VERBS sibling. The propose step IS the approval
+  gate this flow needs.
+- **The write path exists end-to-end** — `person.candidates` →
+  `person.apply` → `person.affiliate` (N-per-person, org pre-bound,
+  observations ride along). The agent loops it per approved row; nothing
+  new below the capability line except maybe a batch wrapper.
+- **Team-page parsing** — the `crawl-fetch-ingest` skill's
+  firm-anchored cascade (team pages → people + headshots + LinkedIn
+  URLs) is the extraction playbook; Firecrawl/Jina are already wired.
+- **Staged-state-then-approve** — the Response Reviewer triage model and
+  the AddPersonInline candidate gate are the UI grammar: staged rows,
+  per-row accept/edit/skip, batch approve.
+- **Chat rail is already adjacent** — the shell mounts chat as the
+  persistent left rail; "didi knows what card you're on" needs the
+  active-entity context (org_slug) in the chat envelope, akin to the
+  active-client context the inbox verb already carries.
+
+## Rough shape (to be developed)
+
+1. Context plumbing: org-workbench broadcasts its active org
+   (`augment-it:active-entity` or a workspace frame) → chat includes it.
+2. Verb: `org.team_page.scan` (propose-shaped) — input: team-page URL
+   (from org_links or operator-pasted); output: staged
+   `people: [{name, role, headline?, linkedin?, bio_url}]` in state.
+3. Staging UI on the workbench: the people reveal grows a "staged"
+   section (distinct chrome) with per-row edit/verify/skip.
+4. Approval → batch `person.candidates/apply/affiliate` with
+   per-row candidate gates ONLY where matches are ambiguous
+   (exact-no-candidates rows can flow; the gate-every-step thesis
+   applies to writes, and approval WAS the gate).
+5. Provenance: every created person's observation cites the team-page
+   URL as source.
+
+## Open questions (for the development pass)
+
+- [ ] Where does staged state live — org-workbench runes state, a
+  workspace frame (survives remount), or chat-turn state?
+- [ ] Ambiguous-match policy: inline per-row gates vs. kick ambiguous
+  rows to AddPersonInline?
+- [ ] "or CSV" — does the record-set backend variant matter for v1, or
+  is canonical-DB-only acceptable first?
+- [ ] Relationship to [[../issues/Person-Bio-Pages-Are-Affiliation-Signals-Not-Just-Identity-Links]]
+  — the team-page scan mass-produces exactly the promotion that issue
+  wants one-at-a-time.
+- [ ] Does this want a spec first (it crosses chat + workbench + state
+  staging), or is it plan-sized? Leaning: small spec, per the
+  developing-a-spec rhythm — this stub is the pre-spec capture.