I dont think the Fuzzy mather is prefroming very w...

Assessment

Yes—this can be made substantially smarter, safer, faster, and more useful for both code and book-length Markdown/plain text.

My recommendation is an overhaul of the matching pipeline, rather than continuing to add fallbacks inside the /api/apply route. The present implementation has several good ideas, but they are tangled together with path resolution, mutation, fuzzy scoring, prose normalization, duplicate detection, and file writing. That makes the behavior unpredictable and difficult to test.

I reviewed the uploaded app.py. The actual core matcher—apply_patch_to_content() and find_similar_candidates()—is imported from patch_core.py, which was not included, so this is an audit of the matcher’s integration layer and prose fallback rather than the complete scoring algorithm. (app.py)

Critical problems

1. path is used before it is assigned

Inside apply_edits(), this runs before the edit loop:

python
if is_prose_file(path):

But path is not assigned until later:

python
for idx, edit in enumerate(edits_to_apply):
    path = edit["path"]

That can produce:

text
UnboundLocalError: local variable 'path' referenced before assignment

This prose configuration must happen separately for every edit, after its path has been resolved.

2. The project’s fuzzy setting is ignored

Projects are created with:

python
"fuzzy_patch": True

But applying edits uses:

python
fuzzy_patch = data.get("fuzzyPatch", False)

Therefore, whenever the frontend does not explicitly send fuzzyPatch, fuzzy matching is disabled—even though the project says it is enabled.

It should be:

python
fuzzy_patch = data.get(
    "fuzzyPatch",
    project_data["settings"].get("fuzzy_patch", True),
)

This alone may explain a significant amount of the poor performance.

3. Named missing paths follow the wrong control-flow branch

The section labelled “CASE C: AI gave a name, but maybe just the basename or hallucinated a directory” is attached to an elif that runs when the path already exists.

For a named path that does not exist, neither of the intended inner branches necessarily assigns resolved_path. It can then be:

• undefined on the first edit, or
• left over from an earlier edit because loop iterations do not create a new Python scope.

resolved_path must be initialized to None at the beginning of every edit, and the path-resolution logic needs to be reorganized.

4. A tuple is tested incorrectly

Most calls show that apply_patch_to_content() returns:

python
(new_content, match_count)

But one path-resolution branch does this:

python
if apply_patch_to_content(...) is not None:

Even a failed result such as:

python
(None, 0)

is a non-None tuple, so this condition is true. The first same-named candidate can therefore be selected even though it did not match.

It must unpack the result:

python
candidate_content, _ = apply_patch_to_content(...)

if candidate_content is not None:
    ...

5. It deliberately guesses the target file

When several files share the same basename and none matches, the code chooses the shortest path:

python
candidates.sort(key=lambda x: len(Path(x).parts))
resolved_path = candidates[0]

A patching engine should never make that guess. This could modify the wrong config.py, index.js, README.md, or chapter file.

Ambiguous destructive operations must fail closed and return ranked candidates.

6. SEARCH ALL recovery can affect the wrong block

The code scans the entire latest assistant response for any SEARCH ALL marker. If it finds one and the current block’s original text appears somewhere in that response, it may force the current block into replace-all mode.

That means one replace-all block can contaminate another block in the same response. Replace-all intent must be attached to the parsed block itself and never inferred globally afterward.

Prose and Markdown weaknesses

The prose fallback is not sufficiently safe for books yet.

It can replace text inside larger words

A one-word search such as:

text
cat

can match inside:

text
concatenate

and produce corrupted text. Token boundaries are not enforced.

It can cross structural boundaries

The joiner is:

python
r"[\s\u200c]+"

That includes unlimited newlines. A search for:

text
alpha beta

can match:

text
alpha


beta

across paragraphs. For books, matching should not cross paragraph, heading, list-item, front-matter, or fenced-code boundaries unless explicitly requested.

The advertised normalization is unused

normalize_text_for_matching() is defined but never called.

Consequently, the intended NFC, trailing-space, ZWNJ, and direction-mark normalization does not participate in standard matching. There is also no mapping from normalized offsets back to the original document.

Persian/Arabic handling is incomplete

Current logic primarily treats spaces and ZWNJ as interchangeable. A robust Persian/Arabic profile should optionally account for:

• Arabic ي versus Persian ی
• Arabic ك versus Persian ک
• tatweel
• optional diacritics
• ZWNJ differences
• direction marks
• Arabic and Western punctuation variants

These transformations should only be used for comparison. The original source text must remain untouched outside the selected span.

The fallback is also enabled for code

This condition is unsafe:

python
is_safe_substring = (
    block_replace_all
    or is_prose_file(path)
    or len(original.strip()) > 30
)

Almost every meaningful code block is longer than 30 characters. Therefore, when normal code matching fails, the prose regex can be applied to Python, JavaScript, JSON, or another source file.

That bypasses indentation and structural safeguards. Prose matching must never be selected merely because a block is long.

Markdown fences may be legitimate content

strip_markdown_fences() assumes wrapping fences are accidental. In a .md document, those fences may be exactly what the user intends to edit. Fence stripping should depend on parser metadata, not just first and last lines.

Reliability and efficiency problems

The current implementation repeatedly invokes the complete patch engine while:

• resolving paths;
• scanning all files;
• checking duplicates;
• testing global candidates;
• applying the winning candidate again.

This can become expensive for a large repository or a full book. It also catches any ValueError during global search and counts the file as a matching candidate, even when the error may represent something other than a valid match.

The whitespace-insensitive duplicate check is also too permissive:

python
_norm_ws(updated) in _norm_ws(content)

For code, indentation may be semantically meaningful. For prose, removing all whitespace boundaries can join unrelated paragraphs. This can incorrectly report that an edit is “already applied.”

There is also a broader transactional problem: the function called load_and_lock_project() does not appear to begin a write transaction or hold an actual project-level lock. Concurrent edits can load the same state and overwrite one another, making matching appear unreliable even when the candidate selection was correct.

Recommended replacement design

I would build a dedicated matcher module with three explicit stages.

1. Analyze without modifying anything

A matcher should return a structured result:

python
MatchResult(
    status="unique" | "ambiguous" | "not_found",
    file_path="chapters/chapter-03.md",
    start_offset=12550,
    end_offset=13190,
    score=0.973,
    runner_up_score=0.711,
    strategy="normalized_paragraph",
    reasons=[...],
    candidates=[...],
)

Candidate discovery must be pure. It should not produce replacement content just to determine whether a file might match.

2. Use separate code and prose profiles

Code profile

• Exact text first.
• Newline-normalized exact match.
• Indentation-aware line matching.
• Token-aware matching that does not confuse strings, comments, and identifiers.
• Function/class scope as a ranking signal.
• Comment-insensitive comparison only when explicitly enabled.
• Never “nuke” an entire function based on a low-confidence match.

Prose/Markdown profile

• Segment the document into headings, paragraphs, lists, blockquotes, footnotes, front matter, and fenced code.
• Prefer candidates in the same heading or chapter.
• Match whole words and punctuation-aware tokens.
• Allow configurable smart-quote, dash, Unicode, and Persian/Arabic equivalence.
• Do not cross paragraph boundaries by default.
• Preserve the exact original layout outside the replacement span.

3. Apply only after confidence and uniqueness checks

Auto-apply should require:

• a sufficiently high score;
• a meaningful margin over the second-best candidate;
• a unique target file or explicit file path;
• compatible document structure;
• an expected match count.

For example:

text
Best candidate: 0.96
Second candidate: 0.71
Margin: 0.25
Decision: safe to apply

But:

text
Best candidate: 0.91
Second candidate: 0.89
Margin: 0.02
Decision: ambiguous; do not modify anything

A fixed threshold by itself is not enough. A very good candidate can still be unsafe when an almost identical second candidate exists.

Performance plan

For large books and repositories, I would:

1. Normalize each file only once per apply request.
2. Build indexes of rare lines, tokens, headings, and token trigrams.
3. Use those indexes to shortlist likely files and locations.
4. Run expensive fuzzy scoring only around those locations.
5. Cache candidates between preview and apply.
6. Stage all modifications in memory.
7. verify every postcondition.
8. Write files atomically using temporary files and rename operations.

This avoids repeatedly fuzzy-comparing every search block against every character of every file.

Test requirements

Before calling the matcher reliable, I would create a corpus covering:

• repeated functions in different files;
• duplicate Markdown paragraphs;
• repeated dialogue and chapter headings;
• CRLF versus LF;
• tabs versus spaces;
• comments added or removed;
• Markdown code fences;
• front matter and footnotes;
• smart quotes and em dashes;
• Persian ZWNJ and Arabic/Persian letter variants;
• mixed RTL/LTR text;
• very short search blocks;
• replace-one versus replace-all;
• renamed or incorrectly specified paths;
• idempotent reapplication;
• concurrent edits;
• one-megabyte and larger manuscripts.

Core invariants should include:

• Never edit when the two best candidates are too close.
• Never modify outside the chosen span.
• Applying an edit twice must not duplicate it.
• Replace-one must modify exactly one location.
• Replace-all must report and verify its exact count.
• A failed batch must not leave half-written files.

Recommended course

I would retain the parser and UI-facing result format, but replace most matching and path-selection behavior with a standalone, testable engine. The immediate defects in app.py should be fixed first, but more fallback conditions should not be added to this route.

The next required source file is patch_core.py, because that contains the actual scoring, lazy matching, function matching, and candidate-generation implementation. With that file, I can produce the concrete overhaul rather than only auditing its integration layer.