style: remove every em dash from the site, and guard against the next one

[imran-siddique]

You flagged em dashes on the Marketplace. There were twenty-six across the site.

Where they were

The count is less interesting than the locations, which explain why a stated rule did not hold:

File	Count	Kind
marketplace/index.html	7 em, 2 en	Page title, hero copy, empty-state text, sort options, 4 loading placeholders
quickstart/index.html	7 em	Code comments and terminal labels
index.html	4 em	Page title, an image alt attribute, body copy
supernav.js	2 em	Source comments
llms.txt	1 em	Body copy
wcm/index.html	1 em	Body copy
data/adoption.json	1 em	A partner name
schema/trace-v0.2.json	2 em	Mirrored from trace-spec

A page title, an alt attribute, a JSON data file and two source comments. None of those are places prose review looks, which is why a grep run once does not hold the line.

data/adoption.json was not in my original sweep. It arrived in #38 while this was in progress, which is the argument for the check rather than against it.

The rewrites

Rewritten rather than repunctuated, so nothing reads like a dash was swapped for a colon and left dangling.

"Marketplace — Build with…"       →  "Marketplace: Build with…"
"Toolkit—from framework adapters" →  "Toolkit, from framework adapters"
"Terminal 1 — leave running"      →  "Terminal 1: leave running"
"every agent action — signed by"  →  "every agent action, signed by"
"Name A–Z" / "Name Z–A"           →  "Name A to Z" / "Name Z to A"

The four in the Marketplace hero were not prose at all: they are the placeholder shown while the catalog loads, where an em dash stood in for a number that has not arrived. Now an ellipsis, which reads as "still loading" rather than as punctuation.

The guard

tools/check-dashes.js, run in CI on every PR. Reports file, line, character name, and a suggested fix.

It builds its offender table from code points rather than literals. A checker containing the characters it bans reports itself, and the fix somebody reaches for at that point is an exemption for the checker.

schema/ is exempt, deliberately. Those files are byte-for-byte mirrors of trace-spec enforced by schema-parity, so a dash there is an upstream fix followed by a re-sync. Failing CI here for something CI here cannot act on only teaches people to ignore it.

The same workflow now also runs marketplace/marketplace.test.js, which covers the escaping and URL-scheme guards added in #31 after the catalog was found to be rendered from remote JSON without them. It was never wired to a workflow, so it has been passing or failing unobserved since.

Please read this part: the published schema was stale

schema/trace-v0.2.json is re-synced from trace-spec rather than hand-edited, because schema-parity is a byte comparison and a partially-updated mirror is not a mirror.

That pulls in more than the two descriptions, because the published copy had already drifted. The scheduled parity check has been failing since 2026-08-24. Anything fetching the canonical $id URL to validate a Trust Record has since been validating against a schema missing:

• $defs/canonicalizableValue
• the safe-integer maxima on iat and the other numeric fields
• the references block

The re-sync fixes that too, and turns the daily check green again. Upstream prerequisite agentrust-io/trace-spec#228 is merged.

🤖 Generated with Claude Code

https://claude.ai/code/session_014NL8o3PXq6kfs2SdmBv6ak