Repository navigation
Description
Story
As a Sidekick reading a deliberately selected large document or report, I want to request an appropriate output window directly, so reading roughly105KB does not require dozens of model turns.
Existing behavior
REPL.Entry.Output already accepts offset and limit. DEFAULT_TEXT_LIMIT is4096 Unicode code points, not a fixed4KB ceiling; resolveLimit accepts an explicit positive whole-number limit. For example, <REPL.Entry.Output entry={35} offset={0} limit={131072} /> requests a larger window. Guide.Entries continuation examples and receipts mostly teach default-size paging, and default Output reads start at the tail.
Required outcome
- Advertise the explicit limit and beginning-versus-tail behavior at the point of use, in shipped guides and applicable read receipts/continuations.
- Make total length, returned range and remaining data clear, and let deliberate larger reads use the existing interface. Do not add another pagination system or pretend existing support is missing.
- Evaluate the default against real reading journeys; keep a bounded default to avoid unsolicited context floods, while avoiding arbitrary tiny mandatory pages. A default change needs an explicit design decision and focused evidence.
- Preserve Unicode boundaries, exact retained content, existing disclosure and history-only behavior. Keep code-point windows distinct from Journal maxBytes (UTF-8 response budget).
Acceptance
A retained approximately105KB report can be requested in one appropriately sized read with no provider execution or mandatory4K walk. Omitted limits remain bounded; explicit limits and returned continuation arguments behave consistently. A small-read/focused-range example prevents whole-document reading from becoming a requirement.
Context and delivery boundary
Requested from the architecture-cleanup Fable retrospective and subsequent maintainer review. Retrospective claims are not automatically established defects; use the cited concrete witnesses and controlled examples. This ticket records backlog work, not a new active lane, automatic recovery policy or authorization to change unrelated work. Keep the change bounded and update the relevant shipped guidance and owning specification together.
Pilot scheduling update
The maintainer selected higher-value work for the second pilot pair instead (#1178 and #1183). This issue is returned to the backlog; no pilot implementation was dispatched and no completed work was replayed.
Activity