CLI UTF-8 Typography

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:

Character	Name	Example usage
`—`	Em dash	Clause separation in banner and error copy
`…`	Ellipsis	Truncation markers in exported transcripts
`→`	Arrow	Tool-use block headers in exported markdown
`×`	Multiplication sign	Ranking label in distilled workflow output

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:

Bun writes UTF-8 unconditionally. The runtime never downgrades output encoding, so characters like — reach the terminal as intended.
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 : 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.

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:

Character	Name	Example usage
`—`	Em dash	Clause separation in banner and error copy
`…`	Ellipsis	Truncation markers in exported transcripts
`→`	Arrow	Tool-use block headers in exported markdown
`×`	Multiplication sign	Ranking label in distilled workflow output

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:

Bun writes UTF-8 unconditionally. The runtime never downgrades output encoding, so characters like — reach the terminal as intended.

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.

E2E test coupling#

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

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