[MODEL] Prose hard-wrapping and max-width capping recur across sessions despite CLAUDE.md and saved memory

## What happens

When Claude Code writes prose into a file, it breaks sentences at a width it chooses in advance, rather than writing one statement per line and letting the container wrap it.

This shows up in two forms:

- inserting hard newlines into prose at roughly 72–80 characters (markdown, plans, PR descriptions, `.txt` files, commit bodies, code comments)
- adding `max-width: 64ch` / `70ch` / `78ch` to a line of copy in CSS it authors, which produces the same mid-sentence break in the rendered output

I have corrected this four times. It has recurred every time, including across separate sessions, and including immediately after being written to memory.

## Why this is worth filing separately

This is not "the model forgot an instruction once".

The instruction was present in `CLAUDE.md`, present in a saved memory file loaded at session start, and had been explicitly restated in the conversation minutes earlier. It was still overridden.

The part I think is diagnostic: **each occurrence came with a different, individually-plausible justification, produced after the fact.**

- for an artifact: the `artifact-design` skill, which is loaded before writing any artifact, says verbatim *"Keep running text near 65 characters wide."*
- for a commit body: the git convention of wrapping at 72
- for code comments: `CLAUDE.md`'s "write code that reads like the surrounding code", applied to a repo whose comments sit at 77–84 characters

Each of those is a real convention. None of them was the user's instruction. The model reached for whichever one was nearest to hand at the moment of writing, and only recognised the pattern when the user pointed out that a fresh justification had been produced each time.

The `artifact-design` line is a concrete, fixable contributor: it is loaded fresh immediately before authoring, so in practice it outranks an older memory even though the same guidance file states that the user's own words take precedence.

## Reproduction

1. Put an explicit instruction in `CLAUDE.md` or memory: never hard-wrap prose; write one statement per line and let the container wrap it.
2. Ask for a markdown deliverable, a `.txt` email, or an artifact.
3. Observe hard newlines mid-sentence, or a `max-width` in `ch` applied to a prose element.

In my case, occurrence 4 was inside the very document that explained the rule, written minutes after the rule was saved to memory.

## Expected

An explicit, saved user instruction about prose formatting should survive into every writing surface in the session, and should outrank both the built-in design guidance and general typographic convention.

## Suggested fixes

- Make the "user's own words take precedence" clause in `artifact-design` operative rather than advisory, or have the skill omit the 65-character line entirely when a conflicting user instruction is in context.
- Treat formatting preferences as a distinct class that is re-asserted at authoring time, not only at session start. A rule that is read once at boot loses to a skill loaded at the moment of writing.
- Where a convention in a skill can conflict with a user instruction, say so in the skill so the conflict is visible rather than silently resolved in the convention's favour.

## Related

- #41150 — Claude Code ignores `.clang-format` and formatting memory across conversations. Same family: a formatting preference not surviving across sessions.
- #75742 — persistent relapses into non-target dialect/register despite `CLAUDE.md` + memory. Same failure mode for register rather than wrapping.
- #43113 — feature request for long lines in TUI output. Adjacent but distinct: that one is about terminal rendering, this one is about the content of files the model writes.

## Environment

- Claude Code CLI, Opus 5 (1M context)
- Linux
- Recurred across at least two separate sessions roughly a week apart

Start with the reproduction using CLAUDE.md, saved memory, and the artifact-design skill, then compare behavior across markdown, .txt, CSS, commit bodies, and comments. The issue does not identify implementation files or tests; done would mean an explicit user formatting instruction consistently outranks conflicting skill guidance across the listed writing surfaces.

Scritto dal modello di indicizzazione a partire dal testo della issue.