Pickup notes — 2026-05-23

Where things stand

The pre-flight / post-flight pipeline is built end to end as code:

Service layer — buildRequest, prompt.preview, the response-store service, per-request model / max_tokens / row_ids. (committed — c185c24)
The two remotes — request-reviewer (3004), response-reviewer (3005), wired into the shell Deck. (committed — 784fa6c)
The review UIs + the request/response de-conflation + the Prompt-Templates → Request-Reviewer auto-fill + moving the run button out of Prompt Templates. (changelog 2026-05-22_03 written; not yet committed.)

Everything passes svelte-check / tsc. Nothing has been run.

1. Verify first — smoke-test the whole pipeline

Before building anything new: pnpm stack up, then walk one record through all four stages.

Author a prompt in Prompt Templates → confirm it auto-selects in Request Reviewer.
In Request Reviewer: step a row, check the resolved request and the JSON view, pick a model, Fire this row.
Confirm a Response lands in response-store and shows in Response Reviewer; flag it; accept it and confirm the value writes to the row cell.

This is the first real exercise of prompt.preview, the response publish, and the response.accept → row.update path. Expect to find wiring bugs the typecheck cannot — that is the point of doing it first.

2. Finish Phase 4

Co-existence PAIRINGS in shell/src/remotes.ts — pair Request Reviewer beside Prompt Templates, and Response Reviewer beside Request Reviewer, so the Deck’s Split mode puts the handoff pairs side by side.
Theme audit — eyeball both new remotes in light / dark / vibrant. Token discipline was held (no hex), so this should be a confirm, not a fix.

3. A decision to make — markdown rendering

Response Reviewer shows the verbose response in a raw textarea. The blueprint wants it rendered (links, code, tables, citations). That needs a markdown-renderer dependency. Decide: add one (marked is the obvious candidate), or keep raw. This is a deliberate dependency call — not something to slip in.

4. The bigger threads

The record-instance fold ([[Original-and-Enhanced-Record-Instances]]) — prompt.run accumulating into one mutable enhanced instance instead of minting a new derived set per run; the original/enhanced twin in row-store. This is the next substantial data-model piece.
highlight-collector — the judgment-class span-distillation stage. The “Distill” button in Response Reviewer is stubbed waiting for it. Needs its own spec ([[Why-Response-Reviewer-and-Highlight-Collector-Exist]] is the rationale).

5. Housekeeping (small, do when convenient)

Commit the Phase 3 work + changelog 2026-05-22_03 (if not done before sign-off).
shell/src/App.svelte:~186 — stageEl is typed HTMLDivElement but bound to a <main>; one-line fix to HTMLElement.
Dead prompt-template-manager CSS — .bindcheck, .progress, .result, .token.bound/.unbound are unused since the run section left; prune app.css.
web_search tool version — the runner sends web_search_20260209 but the installed SDK types only know web_search_20250305 (cast through ToolUnion for now). Reconcile deliberately.

6. Conceived 2026-05-22 evening — bigger features to spec

These came up at sign-off. They are feature seeds, not tomorrow’s tasks — each wants its own spec (and probably its own changelog arc) before it is built.

6.1 Batch review + a response classifier

Reviewing 207 records one response at a time is onerous. Response Reviewer needs a batch review mode. Likely paired with an automated structured-output classifier that tags each response on a confidence-ish axis — certain / uncertain / unsuccessful (exact vocabulary TBD) — so the human triages by exception: trust the certain bucket at a glance, spend real attention on uncertain, re-run unsuccessful. This classifier tag is a field distinct from the human triage flag. Pairs tightly with 6.4 (an agent doing the classification).

6.2 Top-to-bottom split (vertical deck view)

Today’s co-existence split is left↔right behind a draggable vertical seam. Add a top↔bottom split. In particular: Prompt Templates + Request Reviewer may work better stacked as one column — author on top, review the resulting request on the bottom — since they are the tight authoring↔preview loop. This is a shell tiling addition (a horizontal seam) plus a per-pair orientation field on PAIRINGS.

6.3 Structured / rich responses linked to records

A response is not always one cell value. For thorough research, a response may be a structured artifact — JSON, or a Markdown file with YAML frontmatter. Need a durable way to link such an artifact to its source record — an id-map that does not corrupt across enrichment rounds. Use case: enhanced records feeding clever web UIs — e.g. Dididecks decks built from enriched data. Relates to the record-instance model and its id-map ([[Original-and-Enhanced-Record-Instances]]).

6.3b Many-to-many record relationships

Some enrichments produce new records linked many-to-many to the originals, not just new columns. Example: “research the executive team for this organization — include title, LinkedIn, location found on LinkedIn, Twitter.” One org row fans out to N person rows. The enrichment yields a new record set (people) related to the source set (orgs). The record-instance model and its id-map need to express one-to-many / many-to-many lineage, not only one-to-one column addition.

6.4 Agent skills + an in-app-agent-chat shared service (ai-labs level)

An in-app agent chat as a shared service at the ai-labs level, plus agent skills. The motivating link: agents that review responses and classify them into buckets (6.1) are what make review-at-scale plausible — a human cannot eyeball 207 responses, but can supervise an agent that pre-sorts them. This is ai-labs-wide infrastructure, not augment-it-local. Relates to [[In-App-Chat-as-Agent-Surface-for-Client-Apps]].