CLI UTF-8 Typography#

Decant's CLI output intentionally uses UTF-8 typographic characters rather than ASCII approximations. These four characters appear across the codebase:

Where each character appears#

• src/export.ts — arrow (→) in tool-use block headers, and ellipsis (…) in truncation markers.
• src/distill.ts — em dash (—) throughout generated script comments and skill descriptions, ellipsis (…) for text overflow, and multiplication sign (×) in the frequency × success ranking label.
• src/cli.ts — em dash (—) in the serve banner ("Opening your browser — the printed link works if it does not.") and in the port-in-use error message ("error: port ${wanted} is already in use — is Decant already running at ${url}?").

Rationale for UTF-8 (not ASCII)#

The decision to use UTF-8 typography is grounded in two facts about Decant's runtime and supported platforms:

1. Bun writes UTF-8 unconditionally. The runtime never downgrades output encoding, so characters like — reach the terminal as intended.
2. Both supported platforms' stock terminals render these characters correctly. Substituting ASCII lookalikes (e.g., -- for —, ... for …) would diverge from the established house style without improving compatibility on any supported system.

Automated reviewers (notably gemini-code-assist) have recurrently suggested downgrading these to ASCII for "older terminal compatibility." That suggestion was evaluated and declined on PR #90 1: unless a concrete rendering failure on a supported platform is demonstrated, ASCII-only nits of this kind should be declined for the same reasons.

E2E test coupling#

The serve banner copy is exact-matched in test/serve-open.test.ts. Key assertions include:

• toContain("Open the link in your browser.") — non-opening path
• toContain("Opening your browser") — browser-opening path (the full string includes the em dash)
• toContain(\port ${port} is already in use`)` — port-conflict error

Any copy change — including character substitution — must update these test assertions.