Algorithm v3.7.0: require Edit-append for PRD body expansion

[Resistor52]

Summary

Adds a MANDATORY paragraph to the PRD stub section of Releases/v4.0.3/.claude/PAI/Algorithm/v3.7.0.md instructing the AI to expand PRD bodies via Edit-append rather than a single monolithic Write.

Single-shot Write tool calls for long prose content can be truncated mid-parameter by the tool-call wrapping layer, leaving the PRD as a 10-line frontmatter-only stub on disk while the model believes the full body landed. I hit this twice in one day, in completely separate sessions, on completely separate tasks. Both times the failure signature was identical: "malformed closing tag" in the post-run learning log, content visibly in working memory during the run, but nothing beyond frontmatter actually written to the file.

This is a universal Algorithm issue, not specific to any downstream customization. The root cause lives in the tool-call channel reliability envelope that every PAI user on any LLM harness can hit when writing long content in a single Write call.

What this PR changes

One file, one paragraph inserted:

• Releases/v4.0.3/.claude/PAI/Algorithm/v3.7.0.md at line 144 (right after the PRD stub frontmatter block, right before the Console output MANDATORY paragraph)

The new paragraph specifies four concrete rules:

1. The initial stub Write is the ONLY single-shot Write of the PRD.
2. Every subsequent body section (Context, Criteria, Decisions, Verification, and subsections like Risks or Plan) uses its own Edit call capped at about 200 lines of new content.
3. After any Write or Edit landing more than 50 lines of new prose, immediately Read the first and last 10 lines to confirm the content is on disk.
4. Never embed literal closing-tag strings for system-injected XML (function_calls, parameter, invoke, system-reminder) in PRD content; use HTML entities or paraphrase. Those strings can confuse the tool-call parser and terminate the parameter early.

How this was discovered

This fix was produced by running my local PAI Algorithm's own analysis process against two same-day incidents, using the TRACE-style framework (Trigger, Reverse, Analyze, Categorize, Extract). The full methodology for this kind of AI self-learning-from-mistakes is documented here:

Teaching My AI to Learn from Its Mistakes: https://kennethghartman.com/blog/teaching-my-ai-to-learn-from-its-mistakes/

The blog post explains the local process that generated this fix: detect the failure, enumerate prior occurrences, run a 5-level Why analysis, propose a correction, get approval, implement, and preserve the rule in long-term memory. Credit to the process; the paragraph here is one of its outputs.

Compatibility

Pure additive change. Two lines inserted. No existing text removed or reflowed. Downstream forks that have customized the PRD stub section will not see a conflict unless they have also added a paragraph in the same location.

Testing

• Local PAI Algorithm v3.7.0 on my system has been running with this rule applied since 2026-04-10. No PRD Write truncation recurrences since the rule went into effect.
• The rule was derived from two documented incidents, both of which would have been prevented if this paragraph had been in place.