Title: [Bug Report] Cascading regressions on gen-math-complexe.js across 2-day session

Open 💬 1 comment Opened Jun 26, 2026 by BJ44-phy

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

During a 2-day session fixing PRT structures in a Moodle STACK question generator (HéStack V4), Claude Code introduced a series of cascading bugs, each correction creating a new regression. 56% of the weekly quota was consumed without reaching a stable state. Other modules were damaged in the process.

What Should Happen?

Bug chain (chronological)
Bug 1 — PRT too few nodes
Generated PRTs had 1–2 nodes. Reference XML files in /test/ have 3–4 nodes with partial credit detection. Root cause: Claude rewrote the generator without reading the reference files first.

Bug 2 — moodleLatex regex consuming across {@...@} boundaries
Regex /(?<!\{)@([^@]+?)@(?!\})/g matched the closing @ of {@q1_z1@} as the start of a new match, producing broken CAS expressions like {@q1_z1{@}\right)\times\left({@}q1_z2@}. Fixed by adding (?!\}) after the opening @.

Bug 3 — Fatal file corruption via Python byte manipulation
The Edit tool repeatedly failed on UTF-8 files containing non-ASCII characters (\xc2\xa0 NBSP, \xc3\xa9 é, \xf0\x9f\x94\x91 emoji). Claude fell back to Python byte-level manipulation (line index splicing). Multiple rounds with embedded \n in replacement strings shifted all line numbers, leaving gen-math-complexe.js with 90 open braces vs 89 close braces, a truncated line 10, and an unparseable genComplexe function → "Générateur introuvable pour complexe" error at runtime.

Bug 4 — Rich generalFeedback silently overwritten by minimal fallback
After rewriting the file, chips saved in localStorage had no generalFeedback (stale state). The fallback in buildXML() generated a one-line <p>\(formula=result\)</p> instead of the pedagogical content. The fallback was updated, but this edit touched app.js — a shared module — without full regression testing.

Error Messages/Logs

No declared strategy before starting. Each fix was local with no global view, causing regressions in previously working features.
Edit tool silently fails on UTF-8 files with non-ASCII content (accents, emojis, non-breaking spaces). The tool reports old_string not found without explaining the encoding mismatch. This forced a dangerous Python fallback.
No structural validation after each change (brace count, JS lint). Corruption was only detected after the runtime error.
Write tool blocked ("file modified since read") at the moment it was most needed to do a clean rewrite, forcing more Python manipulation.
Fixes spread to unrelated modules (app.js, verif.js area) to patch consequences of the original corruption, increasing blast radius.

Steps to Reproduce

Edit tool should detect encoding mismatches and report them clearly instead of silently failing.
After any file write, Claude should verify structural integrity (balanced braces for JS, valid syntax) before reporting success.
When a file rewrite is needed, the Write tool should not block on "modified since read" when the file content is already known to be corrupt.
Claude should declare an explicit strategy with defined rollback points before touching a file that has already been modified multiple times in the same session.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

4.6

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗