Measure responsiveness when inspecting large bindings in xmd repl #1001

Story

As a person inspecting a large binding in xmd repl, I want to know whether opening, scrolling or redrawing its value causes avoidable pauses or allocations, so the next presentation improvement addresses a real inspection cost while keeping the complete value accessible.

This evaluation measures the actual Bindings and value-drawer journeys. It produces a recommendation, which may be no change.

Current gap

#997 shortened large string leaves before producing a compact binding summary. Its reported comparison did not establish a lower session peak. That does not measure opening a full value drawer.

Two production paths remain distinct in packages/cli/src/repl/application.ts at the #997 source:

• summarize calls cut, which shortens string leaves but still traverses and copies arrays and objects before serialization.
• A binding drawer calls detail, which serializes the complete value with two-space JSON formatting and splits the result into lines before visible rows are selected.

Those traces identify possible allocation work. They establish neither a visible pause nor a useful optimization. Small string summaries, wide structured values and full-value inspection need separate evidence.

Product journeys and controls

Drive the compiled REPL through actual selection and input:

1. Select Bindings with a multi-megabyte text value available and open its value drawer. First record whether the current presentation wraps a long JSON string, offers horizontal navigation, or otherwise makes the complete text accessible: JSON serialization escapes embedded newlines, so multiline source text alone does not create multiple drawer rows. Exercise the navigation the drawer actually offers and close it. Inaccessible content is a product finding to report, not a defect this evaluation silently fixes.
2. Repeat with a large structured value containing enough members to produce many formatted JSON rows, and scroll forward and backward through those rows. Include escaped text and multiline content without using any real secret or conversation.
3. Type and navigate while the relevant pane or drawer is visible, then resize through the supported terminal profiles. Record the input-to-visible-frame latency and process memory observations.
4. Compare with the same history while another pane is selected, and with otherwise comparable small values. Confirm from the captured frames that the intended pane or drawer was actually reached.
5. As a behavior control, inspect an earlier recorded position after a later entry changes the value. The experiment must continue showing the selected position's value and leave retained data unchanged. This checks interpretation rather than claiming a performance improvement.

Pin the source revision, binary, runtime, terminal sizes, input sequence and generated values. Reuse the real-terminal bench and rendered-cell fixtures where they can witness the claim. State the measurement point and limitations of any latency instrument; a sampled screen is not proof of input arrival or every intervening frame.

Measure opening, scrolling and repeated redraws separately. Report peak RSS, any retained-heap measurement and latency independently, with comparable repeated runs and raw receipts.

If the measured build includes #999's URL-referencing storage, distinguish first inspection from repeated inspection and record bytes fetched or streamed and store caching state. Attribute fetching, decoding and presentation costs separately where the instrument permits. Keeping the complete value accessible does not require materializing every stored binding or loading the entire selected value before presenting its first visible portion. This evaluation does not require a new storage implementation.

Decisions the evidence enables

If inspection is materially costly, propose the smallest correction consistent with the result: avoiding repeated serialization, producing visible rows incrementally, or another intervention supported by the trace. Evaluate whether its own memory retention offsets the gain. If the measurements show no material cost, recommend no optimization.

Any proposal keeps the full value available through honest navigation. Silent truncation, replacing the value with a summary, changing JSON presentation or adding new inspection controls requires an explicit product decision; none is preapproved by this evaluation.

Completion evidence and boundaries

Publish reproducible journeys, actual captured frames and raw measurements. Explain which path carries the cost, whether controls support the attribution, and what change or no-change decision follows. A hidden Bindings pane cannot establish its rendering cost, and passing behavior tests alone cannot establish responsiveness.

The evaluation changes no journal encoding, binding semantics, disclosure policy, frozen model, execution ownership or history selection. It performs no original effect again and leaves every retained value intact. Diagnostic instrumentation is scoped to the experiment.

Relationships

Follows #997. #999 addresses repeated payload storage and does not establish inspection cost. Coordinate any later presentation change with #971's layout and visual checkpoint and #982's selected-scope inspection contract. Neither story's active implementation target is changed by this measurement proposal.