Confirmed all six occurrences in templates/tool-spec.json, and the same six in both derived artifacts - exactly as reported. Scanned the whole tracked tree rather than just the two files named: 19 occurrences across 4 files, of which the fourth is their own report text quoting the corruption, so the damage was contained to the three tool metadata artifacts.

Root cause is an encoding layer, not a typo. sys.stdout.encoding is cp1252 on this machine, so `python scripts/prd_tools.py ... > file.json` mangles every non-ASCII character on the way out. Demonstrated directly: a redirected print of U+2014 writes the single byte 0x97 instead of the UTF-8 sequence e2 80 94.

Fixed: tool-spec.json repaired, mcp/tool-metadata.json regenerated from it, utcp.json regenerated with --static-manifest --output (the earlier attempt with --utcp-manual would have silently dropped the hub-discovery block). --output now pins UTF-8, LF and a trailing newline, so a regenerated artifact is byte-identical across platforms instead of churning CRLF into everyone else's diff.

Guards added as requested: shipped tool metadata is rejected if it carries any common cp1252 mojibake marker or U+FFFD, must be valid UTF-8, and the committed manual must match a fresh generation.