Document .ignore negation rule for fs tools#842
Open
rxgrant wants to merge 3 commits into
Open
Conversation
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>
The `grep_files` and `list_files` MCP tool descriptions now explain that results honor the workspace `.ignore` file with gitignore semantics, including negations. Callers can now tell why a file that exists on disk might be missing from a listing or search: it matched an ignore rule, and re-including a subtree under an excluded directory requires negating both the directory and its contents (e.g. `!/target/doc/` and `!/target/doc/**`). The `.ignore` file itself gains a comment documenting this same two-line re-inclusion requirement, so the rule is explained once next to the rules it governs and again in the tool descriptions consumed by the LLM. Signed-off-by: rgrant <rgrant@contract.design>
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
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.
Notes that re-including a subtree under an excluded directory requires negating both the directory and its contents (e.g.
!/target/doc/and!/target/doc/**)