Read saved command diagnostics through Journal queries - #1078

Why

A REPL entry can fail with empty rendered output while its command has retained the useful diagnostic. Journal previously exposed metadata, so Sidekick could see the failure without reading the saved cause.

Closes #1006.

What changes

Before: Journal inspection returned record metadata without saved command channels.

After: <REPL.Entry.Journal entry={14} yq="..." /> and passive xmd sidekick read --attach FILE entry 14 journal --yq '...' queries can select saved exec.exitCode, exec.stdout and exec.stderr. Both return {value, next, prev, last}. Navigation contains ordinary yq expressions or null.

How it works

Selected entry's complete permitted retained data
  -> existing ordinary yq evaluator
  -> bounded query-result page and navigation expressions

The shared read resolves the entry once. Every request recomputes from that entry's current acknowledged data; growth may shift pages. Generated expressions retain the positive entry, original query and window. Recognition accepts only exact formatter output, using a strict JSON header and full-expression equality. Authored queries keep normal yq semantics.

Review guide

Start with: packages/cli/src/repl/sidekick/journal-query.ts and the E1 saved-diagnostic recovery journey in repl-sidekick-journey.test.ts.

Then review: saved exec projection in model.ts, shared root reads in controls.ts, and passive Journal handling in sidekick-acp/server.ts.

Look carefully at: complete input before selection, exact entry identity, absent versus empty channels, frame bounds, and disclosure gates.

What must stay true

• Reads expose only validated, permitted saved exec facts; operation status, actual command exit and entry outcome remain distinct.
• Reading performs no command rerun, provider call, entry admission or history rewrite. Inspection leaves a failed entry failed.
• Both interfaces use the same data, query semantics and successful response. Source, Prompt and Output retain their existing contracts.

How to verify it

The signed delivery candidate is 9c17d04378b6f482c19857b7b65f86153d484a7d. It adds a test-only documentation-boundary correction to the clean combined head e93561b (feature b9cb19f plus merged main bdc88fff). The combined production candidate passed 52 groups and 248 steps:

deno task test packages/cli/tests/repl-model.test.ts packages/cli/tests/repl-sidekick-controls.test.ts packages/cli/tests/repl-sidekick-journey.test.ts packages/cli/tests/repl-sidekick-acp.test.ts packages/core/tests/query-component.test.ts packages/cli/tests/repl-asset-import.test.ts

E1 follows the actual failed-entry receipt and saved diagnostic into the next scripted provider input, with one command launch and an unsubmitted correction. E2 finds a match beyond the old record and text windows. E3–E5 verify JSON types, query refusals and complete multi-page Unicode channels. E6 distinguishes actual saved exits, missing channels, cancellation and malformed facts. E7 compares cold component, socket and CLI reads while checking passivity.

Architect and Planner feedback both passed on feature commit b9cb19f; their provenance remains at that commit. The combined-head focused check covers the overlapping asset-import boundary.

CI2356 on e93561b exposed D1 scanning Sidekick flags as REPL command options under all three runtimes. Test-only 9c17d04 scopes the comparison to the REPL command-line section while retaining genuine drift detection; its regression file passes 33 tests under each of Deno, Node and Bun. Original Planner feedback on that finite correction passed at exact 9c17d04. CI2357 completed successfully on exact 9c17d04, including the required green aggregate. All 57 check runs resolved: 56 success and the expected ordinary-PR composability skip. Current Main bdc88fff also has successful authoritative push CI. The approved Fable attempt failed without a substantive review because the ACP adapter's Claude client does not support the requested model. Its failure is preserved. The independent Codex Astra fallback review initially identified a missing unfamiliar-Sidekick discovery check. That evidence is now established: a fresh real Codex Sol/medium Sidekick independently requested Journal, received the actual saved diagnostic, and prepared the targeted unsubmitted correction in four provider turns. Its first input contained no diagnostic, query or correction. One command ran; no correction was tested or submitted; original failed-entry history remained byte-identical and cleanup joined. The same Astra reviewer's targeted assessment passed command-verification-1, resolving the blocker while preserving the original review's other conclusions. The thread is resolved, source remains exact 9c17d04, and no blocking finding remains. This PR is ready for human merge; no merge has been performed by the delivery coordinator.

Scope

Included

• Saved exec diagnostics, shared Journal queries, passive CLI --yq, focused regressions and user-facing recovery documentation.

Intentionally unchanged

• Command execution, retention policy, process pipe-tail behavior and correction authorization.
• Source/Prompt/Output inspection and their continuations.
• Configurable size arguments remain tracked separately in Make Journal response size limits configurable through arguments #1077.

New abstractions

• The feature-local Journal query helper serves the response component and passive attachment through one root-owned operation. Core exposes its existing selection operation unchanged.
• Each new abstraction has multiple concrete uses or a clear justification.
• No speculative functionality is included.

Risks and limitations

Strings page by Unicode code points. Arrays page by item count and serialized size. Oversized objects or indivisible items refuse with a narrower-query direction; directly selected saved stdout/stderr remain pageable. Navigation recomputes current entry data, so pages can shift as that entry grows. Inspection reports retained command-boundary facts and does not promise additional pipe-tail delivery.

Scope confirmation

• Every changed file supports the purpose described above.
• Unrelated cleanup and formatting changes are excluded.
• Generated or mechanical changes are clearly identified; none are included.
• The description matches the current diff and focused test results.