docs(rfd): Add RFD D34 for patch-based resource delivery#830
Open
rxgrant wants to merge 2 commits into
Open
Conversation
rxgrant
force-pushed
the
rgrant-dev-changed-resource-patches
branch
from
9ae035e to
d16ceb0
Compare
Proposes a third delivery outcome on top of RFD 067's deduplication decision point: when a previously delivered resource's content has changed but the prior full delivery is still within the LLM's effective context, JP sends a unified diff instead of resending the full content. This targets the edit-then-verify loop and frequently-refreshed listings, the two highest-volume sources of redundant tokens that plain reference-based deduplication cannot help with, since a changed checksum never matches. Patches are always computed against the most recent full delivery (never against another patch), fall back to full content whenever any of five safety conditions fail, and ship disabled by default pending a validation phase that measures reconstruction reliability, token savings, and re-read thrashing across providers. Signed-off-by: rgrant <rgrant@contract.design>
Fill gaps found reviewing D34 against RFD 067's delivery model: the patch conditions collapse the "prior delivery exists" and "was a full delivery" checks into one, add a blob-retrieval-failure check, and define what counts as text content. A new Delivery records subsection states that a delivery record must carry its form (full, reference, patch) and, for patch deliveries, the assembled content's checksum — both required by the re-read rule but previously left implicit. Phase 1 of the implementation plan now names this record extension as part of its scope. Terminal rendering of a patch delivery is deferred to the existing `style.tool_call` configuration rather than specified by this RFD. Trims redundant passages (Terminology, Motivation's closing paragraph, the base-invariant walkthrough, and the re-read rule) to bring the draft closer to RFD 001's length guideline, and normalizes references to RFD 067 in prose to the linked `[RFD 067]` form used across other published RFDs. Signed-off-by: rgrant <rgrant@contract.design>
rxgrant
force-pushed
the
rgrant-dev-changed-resource-patches
branch
from
d16ceb0 to
daea8fc
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposes a third delivery outcome on top of RFD 067's deduplication decision point: when a previously delivered resource's content has changed but the prior full delivery is still within the LLM's effective context, JP sends a unified diff instead of resending the full content. This targets the edit-then-verify loop and frequently-refreshed listings, the two highest-volume sources of redundant tokens that plain reference-based deduplication cannot help with, since a changed checksum never matches.
Patches are always computed against the most recent full delivery (never against another patch), fall back to full content whenever any of five safety conditions fail, and ship disabled by default pending a validation phase that measures reconstruction reliability, token savings, and re-read thrashing across providers.