ho-04.4 — The ingest dashboard

sharibako init shows every secret it finds on one screen and lets the practitioner route all of them from that single view — set each key's fate, bulk-apply to a marked set or the whole list, then commit once. This replaces the per-key arrow walk from ho-04.2, which read fine at three keys and fell apart at twelve.

This ho is forward-only motion off ho-04.2's Reflect. That Reflect dogfooded the per-key walk against a real twelve-key .env and found the model structurally wrong at scale: each answered key's menu stayed stacked on screen, move-to-shared recorded a corrupted slug, and there was no bulk action for a .env that size. This ho supersedes ho-04.2 Decision 1 — the per-key sequential walk — and replaces it with the one-page dashboard. ho-04.2 is not edited; it stands as the record of what was known then. This ho is the response to what the dogfood surfaced.

Replacing the prompt wholesale also retires two bugs ho-04.2's Reflect documented as known-in-main, rather than patching a surface that's being thrown out:

• the frame-stacking (InteractiveSelect.renderFrame never cleared its frame on exit)
• the move-to-shared slug corruption (a bare readLine() after raw mode, stray arrow bytes echoing into the slug)

Both die as a byproduct of the dashboard owning its screen and its input.

Out of scope:

• Any change to Materializer.ingest/acceptIngest, KeyDecision, or ProposedScope — the ho-03 library surface is consumed as-is, exactly as ho-04.2 consumed it.
• The IngestDecisionSource protocol and ScriptedIngestDecisionSource — kept unchanged; the dashboard is a new implementation of the same protocol (Decision 7).
• Non-interactive init (--scope/--import-all/--yes) — still deferred (ho-04.2 Decision 6). The dashboard is the interactive surface; the scriptable path lands later as another IngestDecisionSource implementation feeding the same acceptIngest.
• InteractiveSelect itself — it stays as the single-question widget for the yes/no and scope-type prompts around ingest. It is not deleted and not extended into a table (Decision 5).
• The GUI ingest matrix — ho-06. The dashboard is the terminal surface; the SwiftUI four-choice flow is that ho's version, and the dashboard's one-page model is the closer analog for it than the per-key walk was.
• .env deletion or rewrite after ingest — unchanged from ho-04.2 Decision 4; the source .env is left byte-for-byte untouched.

What carries forward unchanged from ho-04.2: first-run key generation (Decision 5), Touch-ID-free ingest (Decision 2), scope-ID collision reuse (Decision 3), re-init reconcile (Decision 7), source-.env untouched (Decision 4). Those decisions held under the dogfood. InitCommand keeps that scaffolding; only the decision-collection call changes from the per-key prompt to the dashboard.

Phase 1 — Think

The interaction model was resolved in conversation with the practitioner. What follows records the decisions.

Decision 1 — One page: every key a row, navigate and set in place

init renders all detected keys as a vertical list, one row per key, and the practitioner routes each from that single view. This supersedes ho-04.2 Decision 1's per-key sequential prompt.

Each row shows the key name and its current choice — one of import / link / move / leave / skip — rendered as a colour change plus a ✓, not a reverse-video block (the reverse-video block read as heavy at twelve rows). The active row is marked distinctly (a cursor glyph and/or highlight). Rows are spaced for legibility rather than packed.

Navigation:

• ↑/↓ move the active row.
• ←/→ cycle the active row's choice through the available actions in place. The choice updates live as colour + ✓.
• space toggles a bulk-mark on the active row (see Decision 2).
• Enter commits the whole screen (Decision 6).
• q / Esc cancels (Decision 6).

Initial state honours the Materializer's suggestions: a key with nameMatchedSharedID set starts on link with its matched entry pre-resolved and named in the row; every other key starts on import (the dominant real choice). So the first frame already reflects the sensible default and the common case is often "glance, commit."

suggestedKeysNeedingValues and parseWarnings are context, not decidable rows — they render as a read-only banner (keys that appeared only in .env.example with no value; any parse warnings the ingest collected), placed above or below the table. They inform; they are never navigated.

Decision 2 — Bulk: space marks, a applies to the marked set or the whole list

A large .env wants one motion that sets many keys at once. The model layers a lightweight selection onto Decision 1's per-row control:

• space marks/unmarks the active row. Marked rows carry a visible marker.
• a invokes ALL: choose one action, and it applies to every marked row — or, when nothing is marked, to every row. This is the practitioner's stated semantic: no marks means "bulk them all," marks means "bulk these."

ALL offers the target-free actions only — import / leave / skip. link and move are excluded from bulk because each needs its own target: link needs a specific shared entry, move needs a distinct new slug per key. Bulking many keys onto one shared target is incoherent, so those two stay per-row (←/→ plus their secondary input, Decision 4). This keeps ALL fast and unambiguous — the overwhelmingly common bulk is "import everything," which ALL does in two keystrokes (a, pick import).

ALL overwrites: applying it re-sets the affected rows regardless of their current choice, including name-matched rows. That is deliberate — ALL is invoked explicitly, so overwriting a default is a chosen act, not a stumble.

Decision 3 — Alternate screen buffer, cursor-addressed redraw

The dashboard runs on the terminal's alternate screen (smcup/rmcup — the mode vim, less, and htop use): on entry it switches to a throwaway full screen, on exit it restores the prior screen and the practitioner's scrollback is untouched. This makes the frame-stacking failure structurally impossible — the dashboard cannot pollute scrollback because it never draws into it.

Within the alternate screen the table is redrawn cursor-addressed (position, clear, paint) on each keystroke. Restore is SIGINT-safe: the module-level saved-termios + signal-handler pattern already in InteractiveSelect extends to also leave the alternate screen on Ctrl-C, so an interrupt returns a cooked terminal on the original screen, never a mangled one.

The renderer honours the project's colour discipline — TerminalDetector/OutputRenderer conventions, degrading to plain markers when colour is off.

Decision 4 — Secondary inputs collected inside the dashboard

link and move each need a second input, and the old code collected them wrong — it dropped out of raw mode to a bare readLine() with stray arrow bytes still buffered, which is how move-to-shared recorded a corrupted slug. The dashboard collects both inside its own render loop, owning the input the whole time:

• link → shared-entry pick. Selecting link on a row opens an in-dashboard sub-list of the available shared IDs (from vaultCore.listShared()), navigated the same way, defaulting to nameMatchedSharedID when present. The resolved entry shows in the row.
• move → new-slug entry. Selecting move opens an in-dashboard single-line text field the widget drives in raw mode — printable bytes append, backspace deletes, Enter confirms, Esc cancels back to the prior choice. The entered slug is sanitized with the same rules the scope ID uses. No readLine(), no stdin left mid-line, no leaked escape bytes.

Owning input end-to-end is what retires the corruption bug — it is a construction property of the dashboard, not a patch.

Decision 5 — A new widget; InteractiveSelect kept, InteractiveIngestPrompt retired

The dashboard is a new full-screen widget, IngestDashboard, not an extension of InteractiveSelect. InteractiveSelect answers one question with a single-select list; the dashboard holds persistent multi-row state on an alternate screen and collects secondary inputs. Growing one into the other would overload a small, working widget with a mode flag and two behaviours. InteractiveSelect stays exactly as it is, still used for the first-run "Generate a key? [Y/n]" and scope-type prompts that bracket ingest.

The per-key TTY source, InteractiveIngestPrompt, is superseded — its whole job was the per-key walk. init routes through a new IngestDecisionSource implementation driven by the dashboard, and InteractiveIngestPrompt (with its buggy resolveMove/resolveLink) is removed. The IngestDecisionSource protocol and ScriptedIngestDecisionSource are untouched.

This decision draws the decomposition seam (Phase 2): the reusable dashboard widget and its decision source are one task; wiring init to it and retiring the old prompt is the next.

Decision 6 — Navigate and set freely, commit once, cancel cleanly

Nothing is written until the practitioner commits. Enter commits the whole screen: it collapses the dashboard back to the normal terminal, prints a one-line summary of what's about to happen (counts per action), asks a single confirmation, and on yes calls acceptIngest exactly once with the full [KeyDecision] set. q/Esc cancels — restores the terminal, writes nothing, and init exits as a clean cancel (no scope, no marker). There are no partial writes and no mid-walk commits; the whole routing is one atomic decision handed to acceptIngest, the same call ho-04.2 already proved out.

Decision 7 — The IngestDecisionSource seam holds

The dashboard is a third implementation of IngestDecisionSource.decisions(for:sharedIDs:), alongside the scripted double and the (now-retired) per-key prompt. acceptIngest, KeyDecision, and ProposedScope are unchanged; the protocol signature is unchanged; ScriptedIngestDecisionSource still drives InitCommand's end-to-end tests through every decision branch without a terminal. Non-TTY input still refuses via CLIError.notInteractiveTerminal before any raw read — the dashboard checks isInteractive() on entry exactly as InteractiveSelect does. The raw-mode renderer (byte reads, alternate-screen escapes, termios) is coverage-excluded with a comment; the decision state machine — navigation, cycle, mark, ALL application, secondary-input resolution, and the final map to [KeyDecision] — is driven through injected readByte/write and fully covered.

Deferred to execution

• Exact on-screen layout: banner placement (top vs bottom), the key legend/footer, column alignment, and the active-row marker glyph — feel decisions tuned against a real terminal.
• Whether ALL's action pick is a small InteractiveSelect overlay or an inline cycle on a dedicated line — either is fine; the agent picks the cleaner construction.
• The precise line-editing affordances of the move slug field beyond append/backspace/Enter/Esc (e.g. whether left/right editing within the field is worth it) — start minimal.
• Internal division of labour between IngestDashboard (the widget) and the IngestDecisionSource implementation that wraps it — thin-composition vs the widget returning richer results — the agent's call, provided the injected-byte state machine stays testable and the protocol seam stays intact.
• Whether the dashboard shares any small rendering helper with InteractiveSelect (cursor moves, clear-line) or duplicates the few escapes it needs — factor only if it's genuinely shared, don't force it.