[BUG] Pi extension double-compresses RTK-truncated tool results

[PGAAUmN3yEL0O8g6Yn9J553D3Q8p6g7S7GW1i3U]

Summary

The proposed provider-independent Pi extension in #2657 can double-compress tool results already compacted or truncated by pi-rtk-optimizer.

This does not mean RTK and Headroom cannot coexist: the hooks and /v1/compress contract work together. The problem is that Headroom does not recognize RTK's compaction metadata, so it treats an already-lossy RTK result as a fresh compression candidate.

Versions

• Pi: 0.84.2
• pi-rtk-optimizer: 0.9.0
• Headroom proxy: 0.35.0
• Pi extension code: PR feat(integrations): add provider-independent Pi/OMP extension #2657 (plugins/pi/src/policy.ts)
• macOS arm64

Reproduction

1. Use RTK's default output-compaction configuration (truncate.maxChars: 12000).
2. Run a large bash command that emits log output (example: 2,000 repetitive structured log lines, 262,369 characters).
3. RTK's tool_result hook changes the result to 12,000 characters and returns metadata equivalent to:

{
  "rtkCompaction": {
    "applied": true,
    "techniques": ["truncate"],
    "truncated": true,
    "originalCharCount": 262369,
    "compactedCharCount": 12000
  },
  "metadata": {
    "rtkCompaction": {
      "applied": true,
      "techniques": ["truncate"],
      "truncated": true
    }
  }
}

4. Pass that Pi toolResult through the candidate policy in feat(integrations): add provider-independent Pi/OMP extension #2657.
5. The candidate is still accepted because hasPruningMetadata() only checks top-level prunedAt/pruned and details.truncation.truncated; it does not inspect details.rtkCompaction.truncated or details.metadata.rtkCompaction.truncated.
6. The candidate is sent to /v1/compress and accepted again.

Observed result with the current proxy:

original: 262369 chars
RTK:      12000 chars  (technique: truncate)
Headroom: 10698 chars  (tokens_saved: 837, transform: router:search:0.79)

The Headroom Pi bridge's validateCompression() accepts this result, so the model-facing context is compressed a second time. The CCR/retrieval path cannot restore bytes that RTK already removed.

A second error-log fixture produced:

RTK:      12000 chars  (technique: truncate)
Headroom: 10515 chars  (tokens_saved: 990, transform: router:log:0.73)

Expected behavior

Headroom should detect that the candidate was already lossily compacted by RTK and, by default, skip it or apply an explicit, documented composition policy. It should not silently perform a second lossy transformation on a result whose source has already been truncated.

RTK's command rewriting and ordinary non-truncated output should remain eligible for Headroom compression.

Suggested fix

Extend the Pi policy's pruning/compaction metadata detection to recognize RTK's shape, including both locations RTK writes:

• details.rtkCompaction.truncated === true
• details.metadata.rtkCompaction.truncated === true

Add a regression test using an RTK-shaped toolResult and assert that candidateFromToolResult() returns undefined. A separate test can confirm that non-truncated RTK aggregation remains configurable/eligible.

Related: #2657, #645.

[chopratejas]

Closing here because this isn't a defect in main — it's a defect in an unmerged branch, and it'll get lost on the issue tracker while the fix belongs on the PR.

plugins/pi/ doesn't exist on main; hasPruningMetadata, candidateFromToolResult and rtkCompaction return zero hits repo-wide. The code you're describing lives only in #2657.

I've carried your report onto that PR as review feedback, including the specific fix — extend the pruning-metadata check to both shapes you observed:

details.rtkCompaction.truncated
details.metadata.rtkCompaction.truncated

— and the regression test you specified. #2657 is held out of the merge queue until that's covered, so this won't ship broken.

To be clear this is a filing-location call, not a quality one: you ran the branch end to end and measured the failure (262,369 chars → 12,000 via RTK → 10,698 via Headroom). That's a better bug report than most, and it's exactly why #2657 isn't merging today. Please follow along on the PR.