Pickup notes — 2026-05-27

Where things stand

The two-day arc 2026-05-25/26 closed with packs and bundles end-to-end as a shipped pattern (modulo bundles themselves — see the bundle gap below). Specifically:

services/social-search is in the Docker stack, registered for pack.search.requested + pack.fan_out.requested, fanning out concurrency-bounded across the common-seven roster (linkedin, x, bluesky, youtube, facebook, wikipedia, instagram). Tavily is the v1 connector; key reads from .env; stack-up works whether or not the key is set.
apps/pack-runner is the new federated remote at :3009, paired-only (not in the peek-deck rotation), reached via the shell’s augment-it:navigate → PAIRINGS fallback. The four-card flow (record set → entity-name column → row multiselect → pack checkboxes) is the canonical pack-invocation surface.
apps/prompt-template-manager (:3003) gained the paired “Custom Prompt / Pre-built Pack” tab pair that toggles in sync with pack-runner via the augment-it:enrichment-mode window event + localStorage.
apps/response-reviewer (:3005) is the by-record triage cockpit — one card per organization, inline URL / display_name / entity-name editing, four-button triage (good / wrong / partial / accept), correction + human-supply paths on the same response.set_structured subject. This is the surface that absorbed the foundation-dataset smoke and produced the eleven emergent-requirements rows in the blueprint.
services/row-store writes back to row.fields.socials[] via addSocial / removeSocial with replace-by-pack_id semantics; the response-store accept-handler forks on pack_id.
services/response-store has the sibling-payload schema (prose + structured: Candidate | null + outcome enum + pack_id + bundle_id + pass), with load-time backfill that costs nothing for the legacy prompt-runner path.
packages/shared-ui is bootstrapped with its first reusable component (ConfidencePill.svelte).
packages/theme gained the amber family + the three Tier-2 confidence tokens.

What’s NOT yet built but is now named in writing:

Bundles. The blueprint locked the bundle sub-contracts; zero bundles exist yet. profile-builder.common (LinkedIn + X first) is the natural first one.
Run as a first-class entity. Part 1 of Run-as-First-Class-Operation.md shipped (the pair); Parts 2–6 are sequenced.
Search providers as first-class. Issue filed with eight steps + a measurable acceptance criterion; not started. Reframed 2026-05-27: the decision is provider plurality as an architectural concern, not a Tavily→SearXNG swap. SearXNG joins as a peer and becomes the new default for the common-seven social packs; Tavily stays as a peer for content-RAG packs/bundles; the dispatcher gets a provider_override parameter so the per-row iteration loop (re-fire pack X on row Y through a different provider) lands without a second refactor.
needs_clarification row state. Reserved key declared in the design; not yet implemented.
Agent-chat capability roster. New exploration lists ~20 candidate verbs across five categories; today’s chat only knows the four-verb gated-enhancement triad.

Everything passes pnpm stack up. The foundation-dataset triage has been exercised in anger.

What got written tonight (no code, all context-v + README)

changelog/2026-05-26_01.md — narrower entry, focused on the :3005 response-reviewer triage cockpit specifically.
changelog/2026-05-26_02_Packs-and-Bundles-End-to-End.md — the broader ten-commit arc entry. The system-as-it-now-exists ASCII map lives here.
README.md — rewritten end to end. Old README said React + Next.js + Perplexity + wrong app list; new README has Svelte 5, the actual seven remotes with ports, the five services, the context-v/ + changelog/ discipline, pnpm stack up as the real entry point.
context-v/explorations/Agent-Chat-Skills-and-Commands-Candidates.md — new living roster of ~20 verbs the chat could route, organized into five categories (data safety, inspection, enrichment flow, record-set lifecycle, triage assist). Each entry names its adapter shape (TS handler / ScriptCapability / McpCapability / SkillCapability), its gating concerns, and its suggested chat phrasing. Nominated by the user wanting backup-stores.sh to be a chat-callable command.

The user explicitly accepted both changelog files even though 2026-05-26_01.md is narrower than the full arc — “leave it, it’s fine, just limited in scope.”

1. Verify first — a quick smoke before building anything new

The two-day arc was a lot of code across a lot of layers. Before opening a new thread, spend 15 minutes doing:

pnpm stack up and confirm every remote is reachable on its own port and the shell at :3000.
Open Pack Runner, fire one pack (e.g. wikipedia) against three rows of the foundation set, watch the responses land in Response Reviewer’s by-record view.
Exercise the inline correction path (edit a URL), the human-supply path (type a URL into a not_found), and the entity-name edit in the header.
Promote one row to a new record set and confirm row.fields.socials[] arrives in the canonical view via the type-driven fold.

This is the first real-data sanity-check since the arc closed. Expect to find at least one wiring bug the typecheck cannot see.

2. Pick ONE of three big threads as the next arc

The three threads below are roughly equivalent in size and value. Pick one deliberately rather than touching all three.

2a. Run-as-First-Class-Operation, Parts 2–6

The plan at context-v/plans/Run-as-First-Class-Operation.md is the most ready-to-build thread. Six parts; Part 1 (the PTM ⇄ pack-runner pairing) already shipped. The remaining work in order:

Part 2 — Lift Run from a string id buried on responses into a first-class entity in response-store with type-discriminated fields (prompt | pack | bundle), scope at kickoff, started_at / ended_at, maintained counters.
Part 3 — Render a Run-context bar at the top of Response Reviewer + a run-scope filter chip tier + a per-response “Writes to →” line that makes the row-field target visible before accept.
Part 4 — Subscribe Pack Runner to run.updated broadcasts so the live tally ticks in place of the static “firing N cells…” placeholder. An “Open Response Reviewer →” button via augment-it:navigate.
Part 5 — needs_clarification as a real reserved key on row.fields, with the three-state row discipline (none / needs_clarification / archived) implemented. Pack Runner + prompt-runner default-exclude these rows; Response Reviewer can flip a row into the state from a response card.
Part 6 — Load-time backfill of existing 96 responses into synthetic Runs grouped by their current run_id so older data renders in the new surfaces without a migration step.

Done-when: the foundation-dataset triage closes out and the run-scope filter + progress bar make Parts 3 and 4 real.

2b. First bundle — `profile-builder.common`

The blueprint’s natural next move: prove the bundle abstraction end-to-end with the smallest possible roster (LinkedIn + X, the two highest-signal common packs). Five sub-contracts to honor per the blueprint:

Pack roster with default-true flag
Orchestration plan (single-pass for v1; two-pass with carry-forward as v2)
Chat-verb registration (profile-builder.common is the chat surface)
Pre-flight dedup hook (profiles.dedup.scan against existing helpful_links and socials)
Bundle-level aggregate render strategy

This thread is smaller in code than Part 2a but larger in design — bundles add a new abstraction layer that doesn’t yet exist anywhere in the codebase. Worth doing soon because the provider-plurality work (2c) gets a cleaner shape if bundles exist when it lands.

2c. Search providers as first-class — SearXNG as the new default; per-row iteration as the workflow

Issue at context-v/issues/Search-Providers-as-First-Class-SearXNG-Default.md. Reframed 2026-05-27 from the earlier “Switch Search Substrate from Tavily to SearXNG” framing — the decision is provider plurality, not a swap. Eight proposed steps; the architectural goal is separating pack concerns from provider concerns by introducing a services/social-search/src/connectors/ directory with a common Connector interface and a discriminated-union PackConfig that names which provider each pack uses. SearXNG joins as a peer (self-hosted, free) and becomes the new default for the common-seven social packs. Tavily stays as a peer for content-RAG packs/bundles (deep-research, document extraction) that don’t exist yet but will. The dispatcher (runOnePackSearch) gains a provider_override parameter so the per-row iteration loop — re-fire pack X on row Y through a different provider, until the data is right with the fewest API calls — lands without a second refactor.

Acceptance criterion is measurable: ≥60% of previously-not_found social rows resolve on re-fire through SearXNG. The foundation-dataset smoke is the test bench. Tavily must still work (re-running an old fixture or wiring a test-only pack against connector: 'tavily' succeeds).

Worth doing after Part 2a because the Run entity makes “previously-not_found” a queryable scope rather than a hand-rolled filter — and the per-row iteration loop the issue names as future-work needs the Run object to be coherent about per-row provider history.

3. The Agent-Chat capability roster — a thread that builds slowly across the others

The new exploration at context-v/explorations/Agent-Chat-Skills-and-Commands-Candidates.md lists ~20 candidate verbs. Don’t try to build it as one arc. Instead:

Pick the first candidate to graduate. Likely data.backup (the nominating script, additive-only, no gating questions to resolve first) — gives the codebase its first ScriptCapability adapter, which becomes the reference for everything else in that adapter shape.
Resolve Q1 from the doc — destructive-op gating live in the capability layer or the chat layer? This blocks data.restore, data.scrap_pack_artifacts, packs.fire, responses.accept_by_confidence, responses.retry_errors. Whichever shape lands first becomes binding for the rest. Pair this resolution with whichever destructive-op spec gets forked first.
Add candidates as the user nominates them. The doc is explicitly a living roster — data.backup arrived because the user wanted that script chat-callable; the same will happen for other scripts as the chat surface gets more use.

4. Smaller threads — do when convenient

The by-record view shows responses from every record set, not just the focused one. After a v4 promote, the parent set’s old prompt responses still appear with row_ids the user doesn’t recognize. Fix belongs in the by-record grouping path — record-set scope filter chip + only show responses whose row_id resolves through rowsByRowId for the focused set. Small change; high triage-clarity value.
No live progress bar on long pack-fan-out runs. The user fires common-seven against 50 prospects and the only feedback is responses arriving. Folded into Run-as-First-Class-Operation Part 4 if you take that thread; otherwise a small standalone job.
Proper page-title fetch for URL edits. Today the auto-derived display_name is just the hostname. An HTTP fetch + <title> parse on URL edit would do better. Defer until the SearXNG provider lands (makes it free per-fire), OR a user explicitly asks.
CORS un-scrubbing on federation script tags so future runtime errors show real stack traces in the shell’s DevTools console rather than the cross-origin 'Script error.' placeholder. Captured in the blueprint’s §Triage Surface UX Requirements as the “federation-time debuggability” item.
Working copy has uncommitted changes. git status shows apps/response-reviewer/src/App.svelte and apps/response-reviewer/src/app.css modified plus three untracked files (context-v/blueprints/Response-Row-Identity-Across-Promote.md, scripts/backup-stores.sh, services/response-store/scripts/). The blueprint and scripts/backup-stores.sh are the substance; commit them deliberately. Note: changelog 2026-05-26_02_Packs-and-Bundles-End-to-End.md references services/response-store/scripts/ and scripts/backup-stores.sh in its files_changed list, but those weren’t part of the arc’s actual commits — they’re sitting untracked. Either commit them with a small “tidy” commit cross-referencing the changelog or remove them from the changelog’s files_changed list.

5. Decisions to make before next session

Which of the three big threads (2a / 2b / 2c) fires first? All three are sized for one focused session each. The argument for 2a (Run entity) is that it unblocks 2c’s acceptance criterion and gives the per-row-provider-history surface a natural home. The argument for 2b (first bundle) is that it proves the blueprint’s bundle layer before more code crystallizes around the pack-only shape. The argument for 2c is that the foundation-dataset smoke is sitting there waiting, the provider-plurality refactor is small (8 steps), and the immediate quality win from SearXNG-on-social is recoverable in one session.
Q1 from Agent-Chat-Skills-and-Commands-Candidates.md — destructive-op gating in the capability layer or the chat layer? Affects every destructive candidate in the list. Decide before the first destructive-op spec forks.
Do we commit and ship the two changelog entries + README + new exploration tonight, or hold them with the working-copy changes for one consolidated commit tomorrow? The current git status mixes substantive work (the new blueprint, backup-stores, response-store scripts) with documentation; a tidy “docs(context-v, changelog, README): close out the packs-and-bundles arc” commit is the cleanest separation.