fix: carry reply metadata into runtime context#90745
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed July 18, 2026, 9:20 PM ET / July 19, 2026, 01:20 UTC. Summary PR surface: Source +139, Tests +331. Total +470 across 10 files. Reproducibility: yes. from source: the changed context-engine test directly demonstrates a reply body moving from the bare prompt into the runtime system prompt. A real Telegram round trip on this exact head was not provided. Review metrics: none identified. Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review findings
Review detailsBest possible solution: Define a channel-generic inbound contract that carries only verified reply identifiers as trusted runtime metadata and delivers any quote/body text through an explicitly untrusted context representation. Do we have a high-confidence way to reproduce the issue? Yes, from source: the changed context-engine test directly demonstrates a reply body moving from the bare prompt into the runtime system prompt. A real Telegram round trip on this exact head was not provided. Is this the best way to solve the issue? No. Preserving clean user and transcript prompts is valuable, but elevating channel-supplied reply bodies to system context is not the narrowest safe solution; separate trusted identifiers from untrusted text instead. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against c3adaa3195bd. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +139, Tests +331. Total +470 across 10 files. View PR surface stats
Security concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (6 earlier review cycles)
|
c336ac7 to
e8badae
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
e8badae to
934957b
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
934957b to
bd5eb33
Compare
fbb581e to
1c02af7
Compare
1c02af7 to
956534a
Compare
|
Rebased onto current One conflict in Validation on the new head:
The two unrelated @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
956534a to
6ec795f
Compare
|
Updated proof for current head Rebased onto upstream Validation on this head:
Known local gate gap: repo-local Codex autoreview helper could not run on this VPS because no @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
6ec795f to
2e640a6
Compare
2e640a6 to
86b6531
Compare
|
Rebased onto current @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
86b6531 to
56db654
Compare
|
Fixed the dependency-check findings by keeping the reply metadata alias and prompt-prefix builder internal; tests now exercise the existing runtime entrypoint instead of widening the public surface. The exact parity suite remains green at 212 tests, with formatter/diff checks passing on the rebased head. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Updated the durable Evidence section for current head The guarded rebase resolved one conflict by retaining current-main Focused exact-head validation:
The pre-PR wrapper was skipped under the approved VPS hardware exception. Hosted CI and current-head Telegram-visible proof remain the explicit pending gates. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: fix: carry reply metadata into runtime context This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
What Problem This Solves
Telegram/forum reply facts can exist in channel context but be lost or persisted as user-authored prompt text before they reach the active model runtime. The runtime needs structured current-turn reply metadata without leaking replied-to message bodies into trusted metadata or transcript text.
Why This Change Was Made
CurrentInboundPromptContext.promptForSession/promptForModelas the user-authored prompt.User Impact
Agents can reason about what a Telegram/forum message replies to without polluting stored user prompts or losing reply/thread identity across embedded and CLI runtime paths.
Evidence
Current contributor head:
a3b98718d84b9e923823c3f4d41f427a02ded8cbrebased onto upstreammain45744c962af8cc012914664039f8e3f8ae973442.transcriptPromptand the context-engine turn prompt remain clean.MEDIA_ONLY_USER_TEXTbehavior while preserving the PR-owned trusted reply metadata block.createCliRunnerPrepareFixtureAPI after the old helper was removed.git diff --check upstream/main...HEAD, and range-diff intent audit passed.Real behavior proof
Earlier redacted Telegram/forum transport supplied real message/thread/reply identifiers and confirmed that the persisted session user message remained user-authored text only. The current-head tests drive the real prompt-envelope, runtime-context split, embedded attempt assembly, context-engine handoff, and CLI prepare path.
No live Telegram bot round-trip was deployed on this exact rebased head. No Gateway restart or production session migration was performed. Current-head hosted CI and Telegram-visible Mantis/maintainer confirmation remain pending; the branch-specific runtime boundary is covered directly.
Addresses the runtime-handoff portion of #88032.
AI-assisted; reviewed and validated before submission.