Jakob Wennberg
ec27228a8e
Em dashes (—) and en dashes (–) had spread across comments, docs, tests, and a few UI strings, reading as AI-generated boilerplate rather than house style. Replaced each with punctuation matching its context: colon for explanatory clauses, comma for asides, plain hyphen for numeric/legal ranges (e.g. "21-23§"), "to"/"till" for date ranges, parentheses for paired-dash asides. messages/en.json and messages/sv.json were fixed by hand together to keep sv/en in sync. Left untouched where the dash is the functional subject rather than decorative punctuation: date-range-parser.ts's separator regex, charset-repair.ts's CP1252 byte-mapping table (and its test), the SIE encoding mojibake docs, generic-csv.ts's minus-sign normalizer, the agent system-prompt files that already instruct against em dashes, and a golden iXBRL test fixture compared byte-for-byte. Also fixes two bugs surfaced along the way: an off-by-one in ApiKeysPanel's scope-label split (a leftover from an earlier partial pass), and a charset-repair test that had lost the literal en-dash it exists to verify. Regenerated the agent atom seed migration (skills:generate) since 27 SKILL.md files changed. Added a CLAUDE.md rule against em/en dashes, with an explicit carve-out for the functional-dash cases above. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
70 lines
2.1 KiB
TypeScript
70 lines
2.1 KiB
TypeScript
/**
|
|
* `?expand=…` query parameter parser for embedding related resources.
|
|
*
|
|
* Stripe pattern: a single call returns invoice + customer + line items +
|
|
* payments instead of forcing the caller to make 4 round-trips. For agents
|
|
* passing the response into their own context, this is the difference
|
|
* between 200 and 4000 tokens.
|
|
*
|
|
* Each endpoint declares its own allowlist of expandable keys. Unknown
|
|
* values produce a 400 VALIDATION_ERROR rather than being silently ignored:
|
|
* agents that typo expansions deserve a clear error.
|
|
*
|
|
* Usage:
|
|
*
|
|
* const ALLOWED = ['customer', 'items', 'payments'] as const
|
|
* type ExpandKey = (typeof ALLOWED)[number]
|
|
* const expand = parseExpand(url, ALLOWED)
|
|
* // returns: Set<ExpandKey>, empty if no ?expand param
|
|
*
|
|
* if (expand.has('customer')) { ... }
|
|
*/
|
|
|
|
export interface ParseExpandResult<K extends string> {
|
|
ok: true
|
|
expand: Set<K>
|
|
}
|
|
|
|
export interface ParseExpandError {
|
|
ok: false
|
|
invalidKeys: string[]
|
|
allowed: readonly string[]
|
|
}
|
|
|
|
/**
|
|
* Parse `?expand=a,b,c` from a URL against a per-endpoint allowlist.
|
|
*
|
|
* Returns either `{ ok: true, expand: Set<K> }` for valid input (including
|
|
* the empty case when the parameter is absent), or `{ ok: false, invalidKeys,
|
|
* allowed }` listing the unrecognised keys so the caller can build a
|
|
* VALIDATION_ERROR detail.
|
|
*
|
|
* Whitespace around comma-separated keys is trimmed. Duplicate keys collapse
|
|
* to a single Set entry.
|
|
*/
|
|
export function parseExpand<K extends string>(
|
|
url: URL,
|
|
allowed: readonly K[],
|
|
): ParseExpandResult<K> | ParseExpandError {
|
|
const raw = url.searchParams.get('expand')
|
|
if (!raw) return { ok: true, expand: new Set<K>() }
|
|
|
|
const requested = raw.split(',').map((s) => s.trim()).filter((s) => s.length > 0)
|
|
const allowedSet = new Set<string>(allowed)
|
|
const expand = new Set<K>()
|
|
const invalidKeys: string[] = []
|
|
|
|
for (const key of requested) {
|
|
if (allowedSet.has(key)) {
|
|
expand.add(key as K)
|
|
} else if (!invalidKeys.includes(key)) {
|
|
invalidKeys.push(key)
|
|
}
|
|
}
|
|
|
|
if (invalidKeys.length > 0) {
|
|
return { ok: false, invalidKeys, allowed }
|
|
}
|
|
return { ok: true, expand }
|
|
}
|