Keep Parsons blocks apart when their code has a bare "<"

[aspadiyath]

CodeTailor drops a Parsons block when its code contains a bare <, such as if close < low_close:. A student asking for help on a question built on such a backup problem gets a puzzle with that step missing.

Cause. extract_parsons_code stripped HTML tags with <.*?>. Some stored markup keeps a bare < in its code instead of <. The regex then ran from that < to the next >, usually in the paired distractor's if close > low_close:. It deleted the code and the --- between them, so the correct block merged into its distractor, and the merged block ends in #paired. The subgoal-labels puzzle (#1599) skips distractor blocks, so the step and its label disappeared. The LLM-personalized and fallback paths received the same mangled markup.

Fix. Only real tags are stripped: a < followed by a letter or /, closed on the same line. Any < left over is escaped to <, so the output matches the escaped markup most questions already store and the rest of the pipeline expects.

Scope. Comparing the old and new extraction over all 1,309 Parsons questions in a local database copy:

• 46 questions had text deleted by the old regex. In 43 of them, blocks were merged. All 46 now extract intact.
• 132 change only because a bare < is now <. Their text is identical once unescaped.
• None change in any other way.

Testing.

• New test_extract_parsons_code.py: 4 of its 5 tests fail on the old regex, and all 5 pass with the fix.
• Tested by hand on a local server with a py4e-int question whose backup problem has if close < low_close:. The subgoal-labels puzzle now includes the "update the lowest close…" step, and the example-solution puzzle keeps the if block.

🤖 Generated with Claude Code