Apply_diff solution

[robwise888]

Problem (one or two sentences)

The apply_diff issue - not working with larger &/ or more complex files. My instructions to a coder are 👍 "## Editing files - editing_files.md

• Never rewrite entire existing files unless explicitly authorised.
• You cannot use "write_to_file" as a code editing method it is strictly forbidden.
• You cannot use "replace_in_file" as a code editing method it also is strictly forbidden.
• Apply_diff is likely tofail of the larger and more coplex URIC code fies.
• If apply_diff is your only editing tool, attempt it first with full Rule 3-5 enforcement.
  If it does not persist to disk (the known unlocked-file defect), escalate to Path.read_text/write_text via Python execution.
  In the event that your default dif tool fails then use a Strict Anchor-Patching strategy for editing files with the following rules:

  • RULE 1: Never Locate Code by Line Numbers
    Line numbers shift as prior edits occur in the session and between file versions.
    Never use line numbers as search parameters or hunk headers.
    Locate target code exclusively using Unique Multi-Line Content Anchors.

  • RULE 2: Construct Unique Multi-Line Anchors
    An anchor must consist of the exact target code block PLUS 2–3 surrounding
    lines of context above and below it.
    Multi-line context ensures the search string is unique within the file,
    resolving ambiguous variable names or repeated function structures.
    Anchors must match exact indentation, spacing, and character case.

  • RULE 3: Enforce Pre-Write Occurrence Assertions (now on the LIVE file, BEFORE the snapshot)
    Before making any edit, search the TARGET file on disk for the exact anchor string.
    Count the number of matches.
    Strict Enforcement:
    If matches == 1: Proceed.
    If matches == 0: ABORT. The anchor was not found (indentation or code drift mismatch).
    Do NOT guess or force the write.
    If matches > 1: ABORT. The anchor is ambiguous. Expand surrounding context until == 1.
    This assertion runs BEFORE the backup copy. A backup of a drifted/corrupted file is
    a corrupt baseline; RULE 3 guarantees the file matches expectations before it is snapshotted.

  • RULE 3.5: Mandatory Pre-Write Backup (NEW — mandatory, not optional)
    Immediately after RULE 3 passes and BEFORE any edit is written:
    cp <target_file> /tmp/<target_file>.pre_refactor.py
    Enforcements:

    • The cp exit code MUST be checked. A non-zero exit code ABORTS the edit —
      a silent copy failure produces a false baseline.
    • The backup MUST be byte-for-byte (cp, never a line-ending-normalizing tool).
    • The backup MUST be written to /tmp (outside the CI-scanned project tree) so the
      recursive CI scanners cannot pick it up as a live file.
    • Record the expected matched-anchor line count/location at snapshot time; this is
      the reference against which RULE 6's diff is judged.

  • RULE 4: Perform Atomic Disk Replacement
    Execute the string replacement directly on disk (Path.read_text/write_text, sed,
    perl -0pi, etc. — any method that bypasses the editor buffer).
    Do not rewrite the entire file. Replace only the specific target anchor with the
    updated code block. Preserve all other bytes exactly (no line-ending normalization).

  • RULE 5: Mandatory Post-Write Disk Verification
    Immediately following the file edit, execute a verification pass:

    • Re-read the file directly from disk using fresh file I/O (not the editor buffer).
    • Assert that the replacement string exists on disk.
    • Assert that the original anchor string no longer exists on disk.
      If verification fails (write "didn't stick"), restore from the RULE 3.5 backup
      (cp /tmp/<target>.pre_refactor.py <target_file>) and report the editing failure.
      Do NOT retry the write against a half-applied file.

  • RULE 5.5: Mandatory Backup-Diff Integrity Proof (NEW — the "nothing but the refactor" gate)
    Immediately after RULE 5 passes, run a full-file diff against the backup:
    diff -u /tmp/<target_file>.pre_refactor.py <target_file>
    Assert ALL of the following:

    1. diff exit code is 1 (differences exist — expected).
    2. Every changed hunk must have been explicitly requested.
    3. The hunk header line numbers correspond to the expected anchor location
       (the location recorded in RULE 3.5).
    4. The + lines are exactly the intended REPLACE block; the - lines are exactly
       the intended original anchor. No insertions, deletions, or modifications appear
       anywhere else in the file.
       If any assertion fails, the edit changed more than the prescription allowed
       (auto-formatting side effects, buffer corruption, an unintended collateral edit).
       Restore from backup and report the failure. Do NOT ship a refactor whose diff
       cannot be proven surgical.

  • RULE 6: Syntax & Integration Verification
    Immediately after the diff proves surgical (RULE 5.5), run:

  • Parse the edited file using Python's ast module.
    If ast.parse() fails:
    Restore the backup immediately.
    Report the edit failure.

    • Python compilation (py_compile) or the language's equivalent syntax check.
    • git diff --stat / grep for the modified anchor to confirm exact placement
      (if the file is tracked).
    • The pipeline CI suite (bash scripts/run_all_ci.sh) to confirm no boundary or
      physics logic was broken.
      After CI passes, remove the /tmp backup (it has served its purpose as the
      verification baseline)."
      It seems to work well - and kept me using the zoo code extension
      Rob Wise

Context (who is affected and when)

as above

Desired behavior (conceptual, not technical)

as above

Constraints / preferences (optional)

as above

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

as above

Acceptance criteria (optional)

No response

Proposed approach (optional)

as above

Trade-offs / risks (optional)

as above