feat(shell, workspace, chat), skill(inbox-curation): pre-auth sign-in wall, didi persona + curator verbs, and a face (Build-Order Steps 7-8)

Steps 7 and 8 of the humain-vc unlock build order, plus the character art
that both depend on — landed together since the wall and the chat header
both needed the same avatar asset.

Step 7 — pre-auth sign-in wall (services/workspace/src/server.ts, ws.ts,
workspaces.ts, capabilities.ts; packages/workspace/src/state.svelte.ts,
types.ts; shell/src/App.svelte, SignInWall.svelte): a single-tenant
instance now shows a real sign-in wall to an unauthenticated visitor
instead of a shell that renders remotes which all fail closed. Found and
closed a real gap along the way — an anonymous WS upgrade against
DIDI_AUTH=required is rejected (4401) BEFORE any session frame ships, so
the session frame alone can never tell an anonymous visitor's shell to
show the wall. Added a plain, unauthenticated GET /config the shell
fetches alongside connect(). workspace.list also gained `pinned`, hiding
the WorkspaceSwitcher on a single-tenant deploy. Verified live with
headless Chromium: anonymous → full wall, no header/remotes/switcher;
signed in → wall gone, real data loads.

Step 8 — didi chat v0 (services/workspace/src/chat.ts; apps/chat/src/
App.svelte, app.css; context-v/agent-skills/inbox-curation/SKILL.md):
the chat rail's system prompt now introduces didi by name, states both
its jobs (enrichment + corpus curation), and stays explicit that it's
scoped to augment-it only for now — the shared cross-service persona is
its own initiative, per the Didi-sh-One-Login-One-Agent-Three-Services
exploration. New CURATOR_CHAT_VERBS slab wires source.add/domain.create/
extract.add/tag.apply into the existing three-mode chat discipline, with
a live existingCorporaSlab() (a domain.list read per turn) so didi
resolves a name like "consumer-immunology" against what's actually in
the workspace instead of guessing. Authored the first agent-skill,
inbox-curation, following the decile-hub-interface format precedent.
Verified live: "didi, file this link under consumer-immunology" ends
with a real source in thesis:consumer-immunology, created_by matching
the signed-in didi_id.

Didi's face (shell/src/DidiBadge.svelte, SignInWall.svelte; apps/chat/
src/App.svelte; public/, shell/public/, apps/chat/public/): a character
headshot (user-provided, transparent PNG) composited with the shell's
actual brand-duotone gradient tokens, picked from four generated
candidates. Cropped at higher resolution from the full character sheet
than the original headshot offered. Wired into the header badge, the
sign-in wall, and the chat rail's own header.

Files changed:
- services/workspace/src/server.ts
- services/workspace/src/ws.ts
- services/workspace/src/workspaces.ts
- services/workspace/src/capabilities.ts
- services/workspace/src/chat.ts
- packages/workspace/src/state.svelte.ts
- packages/workspace/src/types.ts
- shell/src/App.svelte
- shell/src/SignInWall.svelte
- shell/src/DidiBadge.svelte
- apps/chat/src/App.svelte
- apps/chat/src/app.css
- context-v/agent-skills/inbox-curation/SKILL.md
- context-v/plans/Build-Order-Humain-VC-Unlock-Flow.md
- changelog/2026-07-08_02_Pre-Auth-Sign-In-Wall-The-Anonymous-Visitor-Gap-The-Session-Frame-Couldnt-Close.md
- changelog/2026-07-08_03_Didi-Gets-A-Face-And-A-Voice-Chat-v0-Curator-Verbs-And-Inbox-Curation.md

Author: mpstaton

apps/chat/public/didi-avatar.png

@@ -29,7 +29,12 @@
 
 <div class="chat-app">
   <div class="chat-status" class:open={connectionStatus === 'open'} class:closed={connectionStatus !== 'open'}>
-    chat · {connectionStatus}
+    <img class="didi-avatar" src="/didi-avatar.png" alt="" aria-hidden="true" />
+    <span class="didi-name">didi</span>
+    <span class="chat-status-sep">·</span>
+    <span class="chat-status-app">augment-it</span>
+    <span class="chat-status-sep">·</span>
+    <span class="chat-status-conn">{connectionStatus}</span>
   </div>
   <CharacterCastRow />
   <ChatSurface />

apps/chat/src/App.svelte

@@ -16,14 +16,29 @@
 }
 
 .chat-app .chat-status {
+  display: flex;
+  align-items: center;
+  gap: 0.35rem;
   padding: 0.4rem 0.8rem;
   font-size: 11px;
   font-family: var(--font-mono, ui-monospace, monospace);
   border-bottom: 1px solid var(--color-border);
   color: var(--color-text-muted);
 }
-.chat-app .chat-status.open { color: var(--color-accent); }
-.chat-app .chat-status.closed { color: var(--color-warn, #c66); }
+.chat-app .didi-avatar {
+  width: 16px;
+  height: 16px;
+  border-radius: 50%;
+  object-fit: cover;
+  flex-shrink: 0;
+}
+.chat-app .didi-name {
+  font-weight: 600;
+  color: var(--color-text);
+}
+.chat-app .chat-status-sep { opacity: 0.5; }
+.chat-app .chat-status.open .chat-status-conn { color: var(--color-accent); }
+.chat-app .chat-status.closed .chat-status-conn { color: var(--color-warn, #c66); }
 
 /* --- Character cast row --- */
 .chat-app .cast-row {

apps/chat/src/app.css

@@ -0,0 +1,52 @@
+---
+date_created: 2026-07-08
+date_modified: 2026-07-08
+title: "Pre-auth sign-in wall — the anonymous-visitor gap the session frame couldn't close"
+lede: "Step 7 of the humain-vc unlock build order: a single-tenant deploy now shows a real sign-in wall instead of a half-broken shell to anyone without a didi.sh session. Building it surfaced a genuine architecture gap — an anonymous WS upgrade against a required instance is rejected before any session frame ships — closed with a small, unauthenticated config endpoint."
+publish: true
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Sonnet 5
+files_changed:
+  - services/workspace/src/server.ts
+  - services/workspace/src/ws.ts
+  - services/workspace/src/workspaces.ts
+  - services/workspace/src/capabilities.ts
+  - packages/workspace/src/state.svelte.ts
+  - packages/workspace/src/types.ts
+  - shell/src/SignInWall.svelte
+  - shell/src/App.svelte
+tags:
+  - Progress-Update
+  - Auth
+  - Didi-Platform
+  - Augment-It
+  - humain-vc
+  - Shell
+---
+
+## Why Care?
+
+A single-tenant deploy (the DO box waiting for humain-vc) needs to look like a real product to an unauthenticated visitor, not a broken app rendering remotes that all fail their capability calls closed. Step 7 makes that true — and along the way surfaced a real gap in how "does this instance require sign-in" gets communicated, one worth knowing about before it bites a real visitor.
+
+## What's New?
+
+- **The wall.** When `workspace.didi_auth_mode === 'required'` and the session has no `didi_id`, the shell now renders `SignInWall.svelte` — full-screen, no header, no remotes, no WorkspaceSwitcher — instead of mounting anything. Sign in and the wall disappears; sign out and it returns.
+- **The switcher hides on a pinned instance.** `workspace.list` now reports `pinned: true` whenever the instance booted with `ACTIVE_CLIENT_ID` set (a single-tenant deploy declaring its one client). No point offering a switch to a workspace that doesn't exist on that box.
+- **The real find: a plain `GET /config`.** An anonymous WS upgrade against a `required` instance is rejected with code 4401 *before* any session frame is ever sent — so a genuinely anonymous visitor's shell would never learn `didi_auth_mode` from the session frame alone, and `showWall` would silently stay false. Added an unauthenticated, CORS-open `GET /config` on workspace-service that the shell fetches alongside (not instead of) `connect()`, so the wall renders correctly for the actual case that matters.
+
+## The Story
+
+The session-frame approach looked complete until we asked "what does a fresh, never-visited browser actually see?" The answer: the WS handshake it fires gets closed before the server ever gets to say anything — the exact code path step 3's membership gate already relies on. Rather than weaken that gate (a real, tested, intentional 4401), the fix routes around it: a cheap, side-channel HTTP read that answers one question ("does this instance require sign-in?") without needing a session at all.
+
+Verified with headless Chromium end to end, not just typechecked: a fresh anonymous context landed on the full wall with no header/remotes/switcher visible; filling the email and completing the local dev-token sign-in reloaded into the normal shell — header, WorkspaceSwitcher, and `record-collector` mounted with real data. `pinned: true`/`false` verified live via a temporary `ACTIVE_CLIENT_ID` override on the running container, no rebuild needed, then reverted.
+
+## What's Next
+
+Step 8 — didi chat v0 — landed right behind this one (see the next entry). The remaining work is the deploy tail: Step 9 puts augment-it on the prepped DigitalOcean box.
+
+## Related
+
+- `context-v/plans/Build-Order-Humain-VC-Unlock-Flow.md` — Step 7, now done
+- `context-v/plans/Unlock-Humain-VC-Team-Access-To-Augment-It.md` (ai-labs level) — item 6, "Instance posture flags"

changelog/2026-07-08_02_Pre-Auth-Sign-In-Wall-The-Anonymous-Visitor-Gap-The-Session-Frame-Couldnt-Close.md

@@ -0,0 +1,66 @@
+---
+date_created: 2026-07-08
+date_modified: 2026-07-08
+title: "Didi gets a face and a voice — chat v0, curator verbs, and the inbox-curation skill"
+lede: "Step 8 of the humain-vc unlock build order: the chat rail is now didi, it can file a captured link under an existing thesis by name in one turn, and it has an actual face — a character headshot composited with the shell's own brand gradient. Deliberately scoped to augment-it alone; the cross-service didi vision has its own exploration doc and its own timeline."
+publish: true
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Sonnet 5
+files_changed:
+  - services/workspace/src/chat.ts
+  - apps/chat/src/App.svelte
+  - apps/chat/src/app.css
+  - shell/src/DidiBadge.svelte
+  - shell/src/SignInWall.svelte
+  - context-v/agent-skills/inbox-curation/SKILL.md
+  - shell/public/didi-avatar.png
+  - shell/public/didi-portrait.png
+  - apps/chat/public/didi-avatar.png
+  - public/illustrationOf_Didi--Headshot.png
+  - public/illustrationOf_Didi_character_assortmant.png
+tags:
+  - Progress-Update
+  - Didi-Agent
+  - Agent-Skills
+  - Augment-It
+  - humain-vc
+  - Chat
+  - Brand
+---
+
+## Why Care?
+
+Flow 1's fifth job is "DiDi assists" — the operator says "file this under consumer-immunology" and it just happens, attributed correctly, without a second click. Today that became real, and didi stopped being a generic "in-app assistant" with no face and became a character — the same one that'll eventually show up in dididecks and memopop too, just scoped to augment-it for now.
+
+## What's New?
+
+- **A persona.** `services/workspace/src/chat.ts`'s system prompt now introduces didi by name, states both of its jobs (enrichment + corpus curation), and is explicit that it's scoped to augment-it only — no cross-service claims, matching the [[Didi-sh-One-Login-One-Agent-Three-Services]] exploration's near-term posture (one shared persona *concept*, independent per-app runtimes, no shared code yet).
+- **Curator verbs, chat-invokable.** New `CURATOR_CHAT_VERBS` slab wires `source.add`, `domain.create`, `extract.add`, and `tag.apply` into the same three-mode (answer/propose/invoke) discipline the enrichment verbs already use. A new live `existingCorporaSlab()` runs a `domain.list` read on every turn and hands didi the workspace's real corpora as `Title → type:slug` — so "consumer-immunology" resolves against what's actually there, never a guess.
+- **The `inbox-curation` agent-skill**, `context-v/agent-skills/inbox-curation/SKILL.md` (the `decile-hub-interface` format precedent): the full decision tree — named + existing corpus → invoke directly; new corpus → propose first; unclear → propose-or-park — plus the never-fabricate-an-identifier rule and the boundary with `corpus.inbox.add` (untriaged parking, not filing).
+- **A face.** The character headshot (transparent PNG, user-provided) composited with the shell's actual `--color-accent`/`--color-accent-2` tokens as a soft brand-duotone gradient — picked from four generated candidates. Cropped at higher resolution from the full character sheet than the original headshot alone offered. Now showing in `DidiBadge`, `SignInWall`, and the chat rail's own header ("didi · augment-it · \<status\>").
+
+## The Story
+
+The acceptance line for this step was always going to be the real test: "didi, file this link under consumer-immunology" typed into a live chat turn, with nothing hand-waved. Ran it against the actual local stack — didi correctly resolved the thesis name from the live corpora list, chose `chat_invoke` (not a proposal, since the corpus was named explicitly — exactly the discipline the skill doc describes), and the source landed in `thesis:consumer-immunology`, `created_by` matching the signed-in didi_id. Verified again in the browser itself: didi's very first greeting lists the workspace's three real corpora by name, pulled from the same live slab a curious operator would see if they asked "what corpora do I have?"
+
+The character art took its own small detour — four background treatments generated against the shell's real theme tokens (solid dark, brand duotone, copper glow echoing the glasses' gears, and a punchier single-accent glow), reviewed side by side before picking brand duotone, then re-cropped from the high-resolution character sheet rather than the smaller original headshot for a crisper result everywhere it's used.
+
+```mermaid
+flowchart LR
+    A["chat_turn: 'file this under\nconsumer-immunology'"] --> B[didi resolves name\nagainst live domain.list]
+    B --> C[chat_invoke source.add]
+    C --> D[source filed, created_by\n= signed-in didi_id]
+```
+
+## What's Next
+
+Steps 1–8 of the build order are now done. What's left is the deploy tail — Step 9 puts augment-it on the prepped DigitalOcean droplet, single-tenant for humain-vc.
+
+## Related
+
+- `context-v/plans/Build-Order-Humain-VC-Unlock-Flow.md` — Step 8, now done
+- `context-v/agent-skills/inbox-curation/SKILL.md` — the new skill
+- [[Didi-sh-One-Login-One-Agent-Three-Services]] (ai-labs level) — the cross-service vision this step is the augment-it-local first slice of
+- [[2026-07-08_02_Pre-Auth-Sign-In-Wall-The-Anonymous-Visitor-Gap-The-Session-Frame-Couldnt-Close]] — Step 7, landed just before this one

changelog/2026-07-08_03_Didi-Gets-A-Face-And-A-Voice-Chat-v0-Curator-Verbs-And-Inbox-Curation.md

@@ -0,0 +1,118 @@
+---
+name: inbox-curation
+description: didi's triage discipline for filing captured links and sources into the right corpus (thesis/strategy/topic) inside augment-it. Use whenever the user gives didi a URL to save, asks to "file this under <corpus name>", names an existing thesis/strategy by name for a link to go under, or it's unclear which corpus a captured link belongs to. Encodes the decision tree (named + existing corpus → source.add directly; new corpus → propose domain.create first; unclear → propose or park in the inbox), the domain-resolution discipline (resolve names against the live "Existing corpora" list, never fabricate a domain_type/domain_slug), and the boundary with corpus.inbox.add (the untriaged capture-first fallback). The capability catalog and args shapes live in services/workspace/src/chat.ts's CURATOR_CHAT_VERBS slab — this skill is the reasoning on top of it.
+---
+
+# Inbox curation
+
+didi's job, Flow 1: **a person captures a link while researching, and didi files
+it under the right corpus without becoming a second click for the operator to
+make.** "Corpus" here is augment-it's `domains` table — a typed grouping
+(`thesis`, `strategy`, `topic`, …) each workspace names for itself; `humain-vc`
+calls them theses, `reach-edu` calls them strategies. Same mechanism, different
+noun.
+
+## The data model, in the order you reason about it
+
+1. **A corpus is a `(type, slug)` pair** — e.g. `thesis:consumer-immunology`.
+   Titles are for humans; `type` + `slug` is what every capability actually
+   takes as an argument.
+2. **A source is a URL filed under one or more corpora**, identified by
+   `source_uuid` once it's been added. `source.add` does the filing (DB
+   registry row + Jina metadata fetch + on-disk file, per
+   [[../../specs/Strategy-Curator-Entry-Point-for-Augment-It|Strategy-Curator-Entry-Point-for-Augment-It]]).
+3. **The inbox (`corpus.inbox.add`) is NOT a corpus.** It's a flat,
+   untriaged holding pen — a markdown file with frontmatter, no `domain_type`/
+   `domain_slug` at all. It exists for exactly the case this skill's decision
+   tree below routes to it: a link with no clear corpus home yet.
+
+## The decision tree (this is the whole skill)
+
+Every turn where the user hands didi a URL, ask two questions in order:
+
+**1. Did the user name an existing corpus?**
+
+Check the name (or slug) they typed against the **"Existing corpora"**
+context slab (a live `domain.list` read, injected into every chat turn as
+`Title → type:slug`). Match on title OR slug, case- and
+punctuation-insensitive — "consumer-immunology", "the immunology thesis", and
+"Consumer Immunology" should all resolve to the same `thesis:consumer-immunology`
+row if it's in the list.
+
+- **Match found** → `chat_invoke source.add` directly, with the resolved
+  `domain_type`/`domain_slug`. Do not propose first — the named corpus is
+  unambiguous, and re-confirming a decision the user already made is the
+  friction this flow exists to remove. This is the acceptance case: *"didi,
+  file this link under consumer-immunology"* ends with a real source row in
+  `thesis:consumer-immunology`, attributed to the signed-in user (rides
+  automatically via the `via: 'didi-agent'` actor tag — no extra work needed
+  here).
+- **No match, but the user clearly means a NEW corpus** (e.g. "start a new
+  thesis on X and put this under it") → `chat_propose domain.create` first.
+  Creating a corpus is a bigger, more visible decision than adding one more
+  source to an existing one — it changes what the curator's sidebar shows
+  for everyone on the workspace. Never `chat_invoke` it silently.
+
+**2. Named nothing, or named something that doesn't match?**
+
+→ `chat_propose`, offering the most plausible existing corpus (if the link's
+subject matter clearly matches one title) **and** `corpus.inbox.add` as the
+park-it-for-later option, side by side. Let the operator pick. **Never
+silently guess a corpus and file into it** — a wrong guess is worse than
+asking, because it makes the source invisible in the corpus the operator
+actually meant.
+
+## Never fabricate identifiers
+
+`domain_slug` must come from the live "Existing corpora" list (for filing
+into an existing one) or from a slug didi itself proposes for a NEW domain
+via `domain.create` (never invent one to hand to `source.add` directly —
+`source.add` requires the domain to already exist; `domain.create` is what
+makes it exist). Similarly, `extract.add` and `tag.apply` need a real
+`source_uuid` — if the conversation hasn't surfaced one (e.g. the user says
+"add a quote to that last source" and didi doesn't have its uuid in context),
+ask rather than guess. A wrong write here isn't reversible-by-refresh the way
+a UI mis-click is; the discipline matters more here than in the curator's own
+click-driven surface.
+
+## Boundary with `corpus.inbox.add`
+
+Do not treat the inbox as a lesser `source.add`. It has no `domain_type`,
+skips the Jina metadata fetch's role in a corpus's index, and its content
+lives in a different filesystem location
+(`clients/<client_id>/corpus/inbox/`, not
+`clients/<client_id>/corpus/<type-plural>/<slug>/sources/`). A link parked in
+the inbox needs a **second, separate** triage pass later — either a human
+walking `corpus/inbox/` and manually filing things, or a future didi capability
+that doesn't exist yet. Don't imply to the user that inboxing is equivalent to
+filing; say "parked in your inbox for later" or similar, not "saved."
+
+## Worked examples
+
+- *"didi, file this under consumer-immunology: https://example.com/paper"*
+  → "consumer-immunology" matches `thesis:consumer-immunology` in Existing
+  corpora → `chat_invoke source.add` with `{ url, domain_type: "thesis",
+  domain_slug: "consumer-immunology", client_slug: <active> }`.
+- *"save this for later, not sure where it goes: https://example.com/news"*
+  → no corpus named → `chat_propose` with one plausible existing-corpus
+  guess (only if the URL's subject clearly matches a title) plus
+  `corpus.inbox.add`.
+- *"start a new thesis on gut-brain axis research and put this in it"*
+  → no match, but a new corpus is explicitly requested → `chat_propose
+  domain.create` with a slugified title, then (after acceptance) `source.add`
+  as the natural follow-up turn.
+- *"add a note to that immunology source saying it's peer-reviewed"* →
+  `extract.add` needs `source_uuid`; if it's not already in the visible
+  transcript/context, ask which source before calling anything.
+
+## See also
+
+- `services/workspace/src/chat.ts` — `CURATOR_CHAT_VERBS`, the capability
+  catalog and args shapes this skill reasons on top of; `existingCorporaSlab`,
+  the live `domain.list` read this skill's decision tree depends on.
+- [[../../specs/Strategy-Curator-Entry-Point-for-Augment-It|Strategy-Curator-Entry-Point-for-Augment-It]]
+  — the click-driven UI this skill is the conversational equivalent of.
+- [[../../../context-v/plans/Unlock-Humain-VC-Team-Access-To-Augment-It|Unlock-Humain-VC-Team-Access-To-Augment-It]]
+  (ai-labs level) — Flow 1 item 5, "DiDi assists," the flow this skill serves.
+- `decile-hub-interface` (sibling agent-skill) — the format precedent this
+  doc follows.