Expose privacy-safe pruning receipts for context-cleaning runs

[caioribeiroclw-pixel]

Cozempic is solving the practical side of Claude Code context bloat: prune/minify/stub the stuff that should not keep living in the session. One missing debug primitive I keep seeing across the Claude Code context-bloat threads is a small receipt that proves what was pruned without exposing the raw session.

Suggested shape for a dry-run / execute artifact:

{
  "event": "context.prune.completed",
  "session_id_hash": "hmac-sha256:...",
  "run_id": "uuid-or-hash",
  "prescription": "standard",
  "strategy_counts": {
    "tool-output-trim": 7,
    "tool-result-age:minified": 18,
    "tool-result-age:stubbed": 43,
    "document-dedup": 2,
    "compact-summary-collapse": 1
  },
  "before_tokens_bucket": "100k_150k",
  "after_tokens_bucket": "50k_75k",
  "bytes_removed_bucket": "10mb_25mb",
  "protected_counts": {
    "compact_summary": 1,
    "team_message": 4,
    "behavioral_digest": 3
  },
  "raw_text_copied": false,
  "backup_created": true,
  "audit_gaps": ["receipt_proves_prune_shape_not_summary_correctness"]
}

Why I think this is useful:

• users can distinguish "Cozempic saved tokens" from "it removed the thing I needed"
• maintainers can debug strategy regressions from hashes/counts/buckets instead of asking for private .jsonl sessions
• it gives teams a safe before/after artifact for guard daemon actions, doctor fixes, and aggressive prescriptions
• it pairs well with the existing dry-run default: cozempic treat current --receipt-json could be safe to share by default

Privacy guardrails I would keep strict:

• HMAC session/message/tool ids, not plain SHA-256 over predictable ids
• bucket token/byte/line counts instead of exact raw sizes where possible
• never copy raw tool output, prompts, file paths, screenshots, or behavioral digest text into the receipt
• include protected-item counts so users can verify Agent Teams / compact summaries / digest entries were not touched

This is not a request to make Cozempic an observability system. I think the minimal win is a shareable receipt for each treatment/guard run that answers: which strategy acted, how much changed, what was protected, and what privacy boundary was preserved.

[caioribeiroclw-pixel]

I turned the receipt shape from this issue into a runnable fixture so the proposal is easier to critique.

Artifact:

• release: https://github.com/caioribeiroclw-pixel/pluribus/releases/tag/v0.3.30
• sample input: https://raw.githubusercontent.com/caioribeiroclw-pixel/pluribus/main/examples/context-input-evidence/sample-pruning-log.jsonl
• converter: https://raw.githubusercontent.com/caioribeiroclw-pixel/pluribus/main/examples/context-input-evidence/convert-pruning-log.mjs
• receipt: https://raw.githubusercontent.com/caioribeiroclw-pixel/pluribus/main/examples/context-input-evidence/pruning-receipt.ndjson
• OTel trace: https://raw.githubusercontent.com/caioribeiroclw-pixel/pluribus/main/examples/context-input-evidence/pruning-otel-trace.json

The fixture models context.prune.started → context.prune.strategy.evaluated → context.prune.completed and keeps the receipt to buckets/hashes/flags: prescription, trigger, before/after token+byte buckets, per-strategy changed/protected counts, backup verification, and explicit raw_*_recorded=false fields.

The synthetic input intentionally contains private-looking session/tool-output strings; the generated receipt/trace prove they do not cross into the exported artifact. That seems like the key contract for a future --receipt-json or dry-run export here: useful enough to audit pruning, narrow enough to share in a bug report.

If this is interesting, the smallest Cozempic-native version could be just one completed-run JSON object first, then per-strategy events later.

[junaidtitan]

This is a genuinely good primitive and the shape you've sketched is right — thank you for thinking through the privacy boundary so concretely (HMAC'd ids over predictable SHA-256, bucketed counts, never copying raw tool output / prompts / paths / digest text, and explicit protected-item counts so users can verify Agent Teams / compact summaries / behavioral-digest entries were untouched). That last one is exactly the reassurance the context-bloat threads keep asking for: "did it save tokens, or did it remove the thing I needed?"

Most of the inputs already exist internally — diagnose computes the per-strategy byte/count deltas and the type breakdown, PrescriptionResult carries before/after tokens + bytes + message counts, and is_protected() already classifies the protected entries — so a --receipt-json on treat (and a guard-run variant) is mostly a serialization + bucketing + HMAC layer on top of data we already have, not a new analysis pass. It pairs cleanly with the dry-run default.

Accepting this onto the roadmap. I'll keep the first cut minimal, matching your suggestion: a single context.prune.completed JSON object per run (prescription, strategy_counts, before/after token + byte buckets, protected_counts, raw_*_recorded=false, backup_created), with per-strategy evaluated events deferred to a later pass. Strict guardrails as you listed; the HMAC will use a per-machine secret so ids are stable for a user but not cross-correlatable.

I'm holding the current release for the open correctness fixes, so this lands a release or two out rather than the next one — but it's queued, not parked. Appreciate the fixture/converter you put together; it's a useful reference for the receipt schema even though the Cozempic-native version will be self-contained.