Feature request: lossless-only mode + honest account of silent failures truncation causes in agent contexts

Feature Request: no_truncation = true config flag

RTK's internal architecture already distinguishes between lossless summarization (whitespace stripping, ANSI removal, deduplication, reformatting) and lossy truncation (hard result caps that silently drop data). That distinction is encoded in FilterResult.truncated, FormatMode, and FilterLevel — but it's never surfaced to users.

Request: expose a single config flag that disables all lossy truncation while keeping lossless compression:

[safety]
no_truncation = true

When set, RTK would only apply operations that preserve all facts: strip ANSI codes, collapse blank lines, reformat JSON, deduplicate repeated log lines. It would never hard-cap result counts or truncate line content.

---

Why this matters: real failure scenarios

These aren't hypothetical. Every one of these can happen silently today with default config.

1. Incomplete git commits (git status capped at 15 modified + 10 untracked)

An AI agent reviews git status output to decide which files to stage. RTK shows 15 modified files — but 20 were actually modified. The agent stages and commits the 15 it can see. The remaining 5 files — potentially including a config change, migration file, or security fix — are silently left out of the commit. No error. No warning. The commit goes out broken.

2. Missed security vulnerabilities in grep results (200 total, 25/file hard cap)

An agent is tasked with finding all usages of a deprecated/vulnerable API pattern across the codebase. grep returns what looks like a complete result set, but RTK has silently capped it at 200 total and 25 per file. The agent updates every match it sees, declares the job done, and ships — with the remaining instances of the vulnerable pattern still in production code.

3. Approved diffs with hidden changes (diff capped at 10 changes/file, hunks at 100 lines)

An agent performs a pre-commit review of a diff. RTK shows 10 changes per file. There are actually 25. The agent approves the diff having never seen the other 15 changes — which might include a logic error, a hardcoded credential, or a broken test. The ... +15 more marker is easy to miss or ignore.

4. Missing breaking change notices in git log (commit body truncated to 3 lines)

An agent analyzes commit history to understand a change before cherry-picking or reverting it. The commit body contains a BREAKING CHANGE: notice, a required migration step, or a known caveat — but it's on line 4 or later. RTK drops it. The agent proceeds without the context it needed, causing a broken deployment or missed migration.

5. Incomplete API schema inference from curl (30 lines, 200 chars/line)

An agent calls an API endpoint to understand its response structure and generate client code. The response has 50 fields. RTK shows 30. The agent generates a model/interface that handles those 30 fields — missing pagination metadata, error shapes, or required fields. The generated code silently fails at runtime on responses that include the truncated fields.

6. Wrong validation logic from truncated JSON (arrays after 5 items, objects after 20 keys)

An agent reads a JSON config or schema file containing an enum of valid values: ["admin", "editor", "viewer", "moderator", "guest", "readonly", "api", "webhook", "service", "auditor", "superuser", "owner"]. RTK shows [admin, editor, viewer, moderator, guest, ... +7 more]. The agent generates validation code that only accepts the 5 visible values and rejects the other 7 as invalid. Users with those roles start getting access denied errors.

7. Silent grep misses in multi-file refactors (25/file cap)

An agent is renaming a function across a large codebase. A heavily-used file has 40 call sites. RTK shows 25. The agent updates the 25 it can see and considers the rename complete. The other 15 call sites in that file still reference the old name. The codebase no longer compiles.

---

Common thread

In every case: RTK provides no indication that results are incomplete when it would matter most. The ... (N more) messages are easy to treat as cosmetic. An agent has no way to know it's working with a partial picture.

Lossless summarization — stripping noise, collapsing whitespace, reformatting — is genuinely valuable in agent contexts. Hard result caps are not. The fix is to let users opt into lossless-only mode.

Suggested implementation

# ~/.config/rtk/config.toml  (or platform equivalent)
[safety]
no_truncation = true   # disable all lossy caps; lossless compression still applies

Commands that currently have FilterResult.truncated = true paths would skip those paths when this flag is set. The FormatMode / FilterLevel pipeline stages that only reformat (not drop) would continue working normally.

Environment

• RTK version: 0.36.0
• OS: macOS 24.6.0
• Use case: AI coding agent (Claude Code)