@bakery-framework/plugin-db-explorer 2.0.0-alpha.9 → 2.0.0-rc.2

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@bakery-framework/plugin-db-explorer",
-  "version": "2.0.0-alpha.9",
-  "description": "Bakery database explorer plugin — browse and edit rows — no raw SQL, no DDL.",
+  "version": "2.0.0-rc.2",
+  "description": "Bakery database explorer plugin: browse and edit rows, no raw SQL, no DDL.",
   "keywords": [
     "bakery",
     "bun",
@@ -33,10 +33,10 @@
     "!src/tests"
   ],
   "dependencies": {
-    "@bakery-framework/core": "^2.0.0-alpha.9",
-    "@bakery-framework/orm": "^2.0.0-alpha.9"
+    "@bakery-framework/core": "^2.0.0-rc.2",
+    "@bakery-framework/orm": "^2.0.0-rc.2"
   },
   "engines": {
-    "bun": ">=1.3.14"
+    "bun": ">=1.4.0"
   }
 }

package/src/access.ts

@@ -9,20 +9,20 @@ import {
  *
  * The explorer used to be read-only by construction, so a boolean answered the
  * whole question. It edits rows now, and "may this request in" and "may this
- * request *write*" are different questions — so the predicate returns a level
+ * request *write*" are different questions, so the predicate returns a level
  * rather than a yes.
  *
  * Two doors, and an application may use either or both:
  *
- *   - `users` — named credentials, for people and scripts that have no session
+ *   - `users`: named credentials, for people and scripts that have no session
  *     (an on-call engineer with a key, a seeding job).
- *   - `authorize` — a predicate over the request, for applications that already
+ *   - `authorize`: a predicate over the request, for applications that already
  *     know who their users are and would rather not keep a second list.
  *
  * Either can admit and the **higher** level wins, because they answer about the
  * same caller: a session admin presenting a read-only key is still an admin.
  *
- * Everything fails closed. Nothing configured admits nobody — the same default
+ * Everything fails closed. Nothing configured admits nobody: the same default
  * the read-only explorer had, and the reason there is no `writes: true` flag to
  * leave set by accident.
  *
@@ -37,7 +37,7 @@ export type Access = 'read' | 'write'
 /**
  * An application's own access check. Return `'write'`, `'read'`, or `false`.
  *
- * Anything else — including `true` — is a denial. The predicate is application
+ * Anything else (including `true`) is a denial. The predicate is application
  * code and this return type is only advice; an untyped or transpiled one can
  * hand back anything, and admission is the expensive direction to get wrong.
  */
@@ -71,14 +71,14 @@ function higher(a: Access | false, b: Access | false): Access | false {
 /**
  * The credential this request presents, or `null`.
  *
- * Core's `readCredential` accepts three forms — `x-db-key`, a Bearer token, and
- * `?db-key=` — and the query form is deliberate there: a human opening a URL
+ * Core's `readCredential` accepts three forms: `x-db-key`, a Bearer token, and
+ * `?db-key=`, and the query form is deliberate there: a human opening a URL
  * cannot set a header.
  *
  * **On a state-changing request the query form is refused.** A credential in a
  * URL is what makes a cross-site write possible: the browser will send it
- * because it is in the link, and `checkCsrf` — which is an `Origin` check, not
- * a token — passes when `Origin` is absent or literally `"null"`, as it is from
+ * because it is in the link, and `checkCsrf` (which is an `Origin` check, not
+ * a token) passes when `Origin` is absent or literally `"null"`, as it is from
  * a sandboxed iframe or some redirect chains. Requiring a header for writes
  * means the caller had to run script on this origin.
  */
@@ -87,10 +87,17 @@ function presentedKey(req: Request): string | null {
   if (presented === null) return null
   if (SAFE_METHODS.has(req.method)) return presented
 
-  // `readCredential` prefers header, then Bearer, then the query — so if
-  // neither header is present, the value it returned came from the URL.
-  const fromHeader =
-    req.headers.has(`x-${DB_KEY}`) || req.headers.has('authorization')
+  // `readCredential` prefers header, then Bearer, then the query, so if
+  // neither header carried a value, what it returned came from the URL.
+  //
+  // **The value, not `has()`.** An empty header is *present*, so
+  // `x-db-key: ''` alongside `?db-key=SECRET` read as "a header was used" and
+  // let a URL credential through on a write, the one case this function
+  // exists to refuse. `readCredential` skips a falsy header and falls to the
+  // query, so the two checks disagreed about which form had been presented.
+  const fromHeader = Boolean(
+    req.headers.get(`x-${DB_KEY}`) || req.headers.get('authorization'),
+  )
   return fromHeader ? presented : null
 }
 
@@ -99,7 +106,7 @@ function presentedKey(req: Request): string | null {
  *
  * **Every entry is compared, with no early exit.** Each comparison is constant
  * time (core's `credentialMatches`), and stopping at the first match would make
- * the response time depend on where in the map the matching key sits — which
+ * the response time depend on where in the map the matching key sits, which
  * leaks the position of a valid key over enough samples.
  */
 export function accessFromUsers(
@@ -151,7 +158,7 @@ export async function resolveAccess(
   req: Request,
   config: AccessConfig,
 ): Promise<Access | false> {
-  // Both doors are consulted even when the first admits — the predicate may
+  // Both doors are consulted even when the first admits: the predicate may
   // grant `write` where a key granted `read`, and the caller is one person.
   const fromKey = accessFromUsers(req, config.users)
   const fromPredicate = await accessFromPredicate(req, config.authorize)
@@ -170,8 +177,8 @@ export function canWrite(access: Access | false): boolean {
  * `hostStore` is one in core: a module variable is shared by every in-flight
  * request, so under any concurrency at all one caller's level would decide
  * another caller's write. It is also cheaper than re-resolving per endpoint,
- * which would run an application's `authorize` predicate — possibly a session
- * lookup — twice for one request.
+ * which would run an application's `authorize` predicate (possibly a session
+ * lookup) twice for one request.
  *
  * Outside a request it is `false`, which is the safe answer rather than a
  * crash: an endpoint reached some other way has no caller to grant anything.
@@ -186,3 +193,32 @@ export function currentAccess(): Access | false {
 export function currentCanWrite(): boolean {
   return canWrite(currentAccess())
 }
+
+/**
+ * Refuse a `users` map that names a level the explorer does not have.
+ *
+ * `access` is typed `Access`, and a JavaScript caller or a value read from the
+ * environment is not bound by that. An unknown level (`'admin'` is the one
+ * that gets written) passed straight through `higher`, reached the client as
+ * the caller's own level in `/api/_db/schema`, and then failed `canWrite`,
+ * which compares against `'write'` exactly. So it failed *closed*, which is
+ * the right direction and an unhelpful way to say "your configuration has a
+ * typo": the operator sees "no access" on a map they believe grants write.
+ *
+ * Thrown at registration rather than logged, because this is a configuration
+ * error in code the application controls, it cannot become correct later, and
+ * the alternative is a server that runs while quietly refusing the people it
+ * was set up to admit.
+ */
+export function assertValidUsers(users: ExplorerUsers | undefined): void {
+  if (!users) return
+  for (const [name, user] of Object.entries(users)) {
+    if (user.access !== 'read' && user.access !== 'write') {
+      throw new Error(
+        `dbExplorerPlugin: users.${name}.access is ${JSON.stringify(
+          user.access,
+        )}; it must be 'read' or 'write'`,
+      )
+    }
+  }
+}

package/src/client/api.ts

@@ -34,14 +34,14 @@ export class ApiError extends Error {
  * What to show a user when a call threw.
  *
  * Here rather than in `dom.ts` because the thing it knows about is `ApiError`,
- * whose `message` is the server's own sentence from the envelope — the reason
+ * whose `message` is the server's own sentence from the envelope: the reason
  * a failed write reads as "row was modified by someone else" instead of
  * "Request failed (409)". `String(error)` is the fallback for the two throws
  * that are not ours: an abort and a network failure.
  *
- * There used to be three of these — one exported from `bulk.ts`, a private
+ * There used to be three of these: one exported from `bulk.ts`, a private
  * near-copy in `save.ts`, and a third inlined at the `notify` call in
- * `csv-commit.ts` — so improving the wording in one left the other two alone.
+ * `csv-commit.ts`, so improving the wording in one left the other two alone.
  */
 export function messageOf(error: unknown): string {
   const api = error as Partial<ApiError>
@@ -91,7 +91,7 @@ interface Envelope {
 /**
  * The data, plus what the server said it cost.
  *
- * `time` is the envelope's own field — `router.ts` fills it from `getElapsed`,
+ * `time` is the envelope's own field: `router.ts` fills it from `getElapsed`,
  * so it is the server's measurement of its own work rather than a round trip
  * timed in the browser. The status bar shows it, which is the one honest number
  * available for "why is this slow": a filter that cannot use an index shows up
@@ -159,7 +159,7 @@ export async function fetchGraph(): Promise<SchemaGraph> {
  * One page of a table, with the server's own timing.
  *
  * **`filters` carries an operator now.** It used to be a bare column→substring
- * record, which meant `col LIKE '%value%'` and nothing else — so a filter could
+ * record, which meant `col LIKE '%value%'` and nothing else, so a filter could
  * narrow a page but could never *name* a row, `1` matching `11` and `21`. With
  * `eq` in the vocabulary it can, which is what removed `ViewState.focus` and
  * turned a foreign-key jump into an ordinary filter.
@@ -167,6 +167,28 @@ export async function fetchGraph(): Promise<SchemaGraph> {
  * The scalar form is still what the endpoint accepts from anyone else; `toWire`
  * always sends the object form from here.
  */
+/**
+ * What the last counted listing was, and what it counted.
+ *
+ * One slot, so it is bounded by construction (convention 6). The key is
+ * everything that changes which rows a listing covers - table, sort and
+ * filters - and *not* the page number, because paging through one listing is
+ * precisely the case where the total does not change.
+ */
+let lastCounted: { signature: string; total: number } | null = null
+
+function listingSignature(
+  view: ViewState,
+  wire: Record<string, unknown>,
+): string {
+  return JSON.stringify([view.table, view.sortBy ?? '', view.sortOrder, wire])
+}
+
+/** Test seam (convention 9): page 2 of one test must not see page 1 of another. */
+export function __resetPageCount(): void {
+  lastCounted = null
+}
+
 export async function fetchPage(view: ViewState): Promise<Timed<TablePage>> {
   const params: Record<string, string> = {
     tableName: view.table,
@@ -178,11 +200,31 @@ export async function fetchPage(view: ViewState): Promise<Timed<TablePage>> {
   const wire = toWire(view.filters)
   if (Object.keys(wire).length) params.filters = JSON.stringify(wire)
 
+  // The `COUNT(*)` is 97% of what a page costs - 51.3 ms against 1.6 ms for
+  // the rows on a filtered page of a 200,000-row table - and page 2 of a
+  // listing asks exactly what page 1 already answered.
+  //
+  // Sent only when the listing is the same one and this is not its first
+  // page. The server enforces the second condition too, so a total that has
+  // drifted is corrected as soon as the view returns to the start; changing a
+  // filter or a sort changes the signature, which is the other way back.
+  const signature = listingSignature(view, wire)
+  if (view.page > 1 && lastCounted?.signature === signature) {
+    params.knownTotal = String(lastCounted.total)
+  }
+
   const query = `?${new URLSearchParams(params)}`
   const res = await fetch(`/api/_db/table-data${query}`, {
     headers: keyHeaders(),
   })
-  return await unwrapEnvelope<TablePage>(res)
+  const answer = await unwrapEnvelope<TablePage>(res)
+
+  // Remember what came back, whether it was counted or echoed: echoing keeps
+  // the slot on the same listing, and a real count refreshes it.
+  if (typeof answer.data?.totalRows === 'number') {
+    lastCounted = { signature, total: answer.data.totalRows }
+  }
+  return answer
 }
 
 export interface LookupRef {

package/src/client/bulk.ts

@@ -3,7 +3,7 @@
  *
  * **Every count that reaches a dialog comes from a `dryRun`.** The server
  * executes the statements inside a transaction and rolls back, so the number is
- * what would actually happen — not the number of checkboxes, which is the same
+ * what would actually happen, not the number of checkboxes, which is the same
  * number only when nothing has changed underneath and no key has gone missing.
  * `confirm.ts` turns that count into the right amount of ceremony.
  */
@@ -69,7 +69,7 @@ export function bulkToolbar(ctx: BulkContext): BulkToolbar {
  * One column, one value, across the selection.
  *
  * The value goes through the same editor the grid uses, so an enum is a select
- * and a nullable column can be set to NULL — the operation people actually
+ * and a nullable column can be set to NULL: the operation people actually
  * reach for and the one a plain text prompt cannot express.
  */
 async function openSetColumn(ctx: BulkContext): Promise<void> {
@@ -97,7 +97,7 @@ async function openSetColumn(ctx: BulkContext): Promise<void> {
   }
 
   const picker = select(
-    editable.map(c => ({ value: c.name, label: `${c.name} — ${c.type}` })),
+    editable.map(c => ({ value: c.name, label: `${c.name}: ${c.type}` })),
     column.name,
     name => {
       column = editable.find(c => c.name === name) ?? column
@@ -199,7 +199,7 @@ async function runDelete(ctx: BulkContext): Promise<void> {
 /**
  * A ten-second offer to put the row back.
  *
- * Only for the immediate tier — anything above one row went through a dialog,
+ * Only for the immediate tier: anything above one row went through a dialog,
  * and re-inserting a hundred rows from the browser's memory is a second bulk
  * write dressed up as a safety net. The pre-image is already in hand because
  * the grid holds the rows it rendered.
@@ -213,7 +213,7 @@ function offerDeleteUndo(
     notify(`${deleted} rows deleted`)
     return
   }
-  const row = rows[0]!
+  const row = restorableRow(rows[0]!, ctx.columns)
   const restore = async () => {
     await run(async () => {
       await insertRows({ table: ctx.table.name, rows: [row] })
@@ -230,7 +230,7 @@ function offerDeleteUndo(
  * Add rows by hand.
  *
  * A column is sent only when the user gave it a value or when the database
- * cannot supply one — `omittableOnInsert` is the same predicate the importer's
+ * cannot supply one: `omittableOnInsert` is the same predicate the importer's
  * blocking check uses. Sending every column would defeat every default in the
  * schema and would make an auto-increment key impossible to leave alone.
  */
@@ -344,7 +344,7 @@ function buildInsertRows(
  * A rejected promise from an event listener is an unhandled rejection and a
  * silent no-op on screen, which is the one outcome a destructive action must
  * not have. `null` is the failure, so a dry run's caller checks the result and
- * an action's caller ignores it — they were two identically-bodied functions
+ * an action's caller ignores it: they were two identically-bodied functions
  * until the second was noticed to be the first with the value discarded.
  */
 async function run<T>(call: () => Promise<T>): Promise<T | null> {
@@ -355,3 +355,27 @@ async function run<T>(call: () => Promise<T>): Promise<T | null> {
     return null
   }
 }
+
+/**
+ * A deleted row, reduced to the columns the table actually has.
+ *
+ * `selectedRows()` hands over the row as `getData` returned it, and two of the
+ * three dialects add a key that is not a column: SQLite selects `rowid` and
+ * Postgres `ctid::text AS rowid`, while MySQL selects `*` and so never showed
+ * this. `validateInsertRow` refuses unknown columns by design, so restoring
+ * the row verbatim came back `400 rowid: unknown_column`, the undo offered
+ * after a delete silently did not undo, on two dialects out of three.
+ *
+ * Exported for the test. There is no DOM here and the bug lived in a callback
+ * a click builds, so the only way to pin it is to name the transformation.
+ */
+export function restorableRow(
+  source: Record<string, unknown>,
+  columns: { name: string }[],
+): Record<string, unknown> {
+  const row: Record<string, unknown> = {}
+  for (const column of columns) {
+    if (column.name in source) row[column.name] = source[column.name]
+  }
+  return row
+}

package/src/client/cell.ts

@@ -4,9 +4,9 @@
  * **Pure, and the reason it exists apart from the grid.** A key handler that
  * reads the DOM to decide what to do can only be tested by building a DOM;
  * this one takes a plain `{key, shiftKey}` and a plain cursor and answers with
- * an action, so `cell.test.ts` pins the whole interaction model — including the
+ * an action, so `cell.test.ts` pins the whole interaction model, including the
  * two rules that are easy to regress, *Enter commits and moves down* and
- * *blur is not in this table at all* — without happy-dom.
+ * *blur is not in this table at all*, without happy-dom.
  *
  * **Blur is deliberately absent.** The dashboard saves on blur, so a stray
  * click into another cell is a write, and a three-column edit is three
@@ -45,7 +45,7 @@ export type CellAction =
   | { type: 'commit'; move: 'down' | 'right' | 'left' | 'none' }
   /** Throw the editor's value away and restore the cell. */
   | { type: 'cancel' }
-  /** Stage SQL NULL — distinct from staging the empty string. */
+  /** Stage SQL NULL: distinct from staging the empty string. */
   | { type: 'null' }
 
 const NONE: CellAction = { type: 'none' }
@@ -78,14 +78,14 @@ function moveTo(state: CellState, row: number, col: number): CellAction {
   return { type: 'move', ...next }
 }
 
-/** Only when the table is editable — a read-only grid still navigates. */
+/** Only when the table is editable: a read-only grid still navigates. */
 function whenEditable(action: CellAction): Rule {
   return (_event, state) => (state.editable ? action : NONE)
 }
 
 /**
  * While an editor is open. Four keys, and everything else belongs to the input
- * — a `default` that swallowed keys here would make the editor unable to
+ *: a `default` that swallowed keys here would make the editor unable to
  * receive a literal `a`.
  */
 const EDITING: Record<string, Rule> = {

package/src/client/confirm.ts

@@ -3,8 +3,8 @@
  * ZONE.
  *
  * `frictionFor` is **pure and tested**; the dialog below is the DOM half. The
- * split matters because the ladder is policy — the thresholds are the answer to
- * "how bad is this if it was a mis-click" — and policy that lives inside a
+ * split matters because the ladder is policy (the thresholds are the answer to
+ * "how bad is this if it was a mis-click"), and policy that lives inside a
  * click handler cannot be asserted.
  *
  * **The count fed to this must come from a `dryRun`, never from the page.** A
@@ -20,12 +20,12 @@ export type Friction = 'immediate' | 'confirm' | 'typed' | 'refuse'
 /**
  * How much ceremony `count` rows deserve.
  *
- * - **≤ 1** — immediate, with an undo. One row is recoverable and a dialog per
+ * - **≤ 1**: immediate, with an undo. One row is recoverable and a dialog per
  *   row makes the tool unusable for the thing it is for.
- * - **2–100** — a dialog naming the count and what changes.
- * - **101–10 000** — the same, plus typing the table name. At this size the
+ * - **2 to 100**: a dialog naming the count and what changes.
+ * - **101 to 10 000**: the same, plus typing the table name. At this size the
  *   user is doing something deliberate and should have to prove it.
- * - **> 10 000** — refused. Not a dialog: there is no phrasing of "are you
+ * - **> 10 000**, refused. Not a dialog: there is no phrasing of "are you
  *   sure" that makes a ten-thousand-row unreviewed write a good idea, and the
  *   honest answer is to narrow it with a filter.
  */
@@ -56,7 +56,7 @@ export interface DangerOutcome {
  * Ask, at the level `frictionFor` decided.
  *
  * Returns rather than throws, and returns `{ok: false}` for a dismissal and for
- * a refusal alike — the caller does one check. The refusal carries its reason
+ * a refusal alike. The caller does one check. The refusal carries its reason
  * so the message names the ceiling instead of failing silently.
  */
 export async function confirmDanger(
@@ -69,7 +69,7 @@ export async function confirmDanger(
       ok: false,
       refusal:
         `${request.count} rows is past the ${(10_000).toLocaleString()} row ` +
-        'ceiling for one action — narrow it with a filter',
+        'ceiling for one action: narrow it with a filter',
     }
   }
   const ok = await openDialog(request, level === 'typed')
@@ -81,7 +81,7 @@ export async function confirmDanger(
  *
  * For the questions that are not about blast radius. Discarding one row of
  * unsaved typing deserves a prompt even though `frictionFor(1)` is `immediate`
- * — the ladder is about how much damage a mis-click does to the *database*,
+ *: the ladder is about how much damage a mis-click does to the *database*,
  * and this one is about work the user has done and the database has not seen.
  */
 export async function confirmChoice(request: DangerRequest): Promise<boolean> {
@@ -93,8 +93,7 @@ export async function confirmChoice(request: DangerRequest): Promise<boolean> {
  *
  * The native element rather than a hand-rolled overlay: it traps focus, closes
  * on Escape, and is inert to the page behind it without a single line of
- * script. Resolved through a `close` listener so a dismissal by any route —
- * Escape, the backdrop, the button — lands in one place.
+ * script. Resolved through a `close` listener so a dismissal by any route ( * Escape, the backdrop, the button) lands in one place.
  */
 function openDialog(request: DangerRequest, typed: boolean): Promise<boolean> {
   const dialog = el('dialog', { class: 'danger' })
@@ -141,7 +140,7 @@ function openDialog(request: DangerRequest, typed: boolean): Promise<boolean> {
 
   // `settle` is narrowed to `(value: boolean) => void` rather than used as the
   // executor's own `resolve`, whose parameter is `boolean | PromiseLike<boolean>`
-  // — calling that reads as an unhandled promise to the floating-promise rule.
+  //. Calling that reads as an unhandled promise to the floating-promise rule.
   let settle: (value: boolean) => void = () => {}
   const answered = new Promise<boolean>(resolve => {
     settle = resolve

package/src/client/csv-commit.ts

@@ -2,7 +2,7 @@
  * The last step: the bad-row policy, and sending.
  *
  * The interesting part is `commit`. It chunks, and the Cancel button stops
- * **before** the next request rather than aborting one in flight — cancelling
+ * **before** the next request rather than aborting one in flight: canceling
  * mid-flight would leave the user unable to say what landed, and this way the
  * answer is exact and is reported: the chunks that completed are the rows that
  * are in.
@@ -22,8 +22,28 @@ import {
 import { append, box, button, downloadText, el } from './dom'
 import type { SchemaColumn, SchemaTable } from './meta'
 
-/** One request per chunk. Well under `policy.ts`'s 50,000 row ceiling. */
-const CHUNK = 500
+/**
+ * One request per chunk. Well under `policy.ts`'s 50,000 row ceiling.
+ *
+ * Raised from 500, which made a full-size file 100 requests. Measured end to
+ * end on 20,000 rows through the real endpoint, three rounds against a
+ * CPU-bound control flat at 26-29 ms: **108 ms at 500 against 89 ms at 5,000**,
+ * an 18% saving and 0.53 ms of fixed per-request cost removed 36 times over.
+ *
+ * The reason on record for raising it was that each request re-introspected
+ * the schema, and that is no longer true - `introspect()` is cached against
+ * `schemaFingerprint()` now, so the second request onwards pays 10 us rather
+ * than 8.28 ms. What is left is HTTP, authorization and a transaction per
+ * request, which is what the 18% is.
+ *
+ * **The cost is cancel granularity**, and it is worth stating plainly.
+ * `cancelled` is checked between chunks, so a chunk in flight always
+ * completes: canceling used to leave at most 500 further rows inserted and
+ * now leaves at most 5,000. Progress also advances ten times less often. Both
+ * follow from the chunk size rather than from anything that could be tuned
+ * separately, since a chunk is one request and one transaction.
+ */
+const CHUNK = 5000
 
 export interface CommitContext {
   table: SchemaTable
@@ -107,7 +127,7 @@ async function commit(
   append(stage, [progress, box('row-bar', stop)])
 
   // All-or-nothing means one transaction, and one transaction means one
-  // request — chunking it would produce N transactions and exactly the partial
+  // request: chunking it would produce N transactions and exactly the partial
   // apply the option exists to rule out.
   const batches = model.onBadRow === 'all' ? [records] : chunk(records, CHUNK)
   const onBadRow = model.onBadRow === 'skip' ? 'skip' : 'stop'
@@ -155,7 +175,7 @@ function paintDone(
   append(stage, [
     el('p', {
       text: facts.cancelled
-        ? `Cancelled — ${facts.inserted} rows landed before it stopped.`
+        ? `Cancelled: ${facts.inserted} rows landed before it stopped.`
         : `${facts.inserted} rows imported.`,
     }),
     failures.length ? rejectedDownload(model, failures) : null,

package/src/client/csv-map.ts

@@ -1,7 +1,7 @@
 /**
  * Steps two and three: how the file was parsed, and where each column goes.
  *
- * Nothing here inspects a `<select>` to work out what the mapping is — the
+ * Nothing here inspects a `<select>` to work out what the mapping is: the
  * mapping *is* the model, and every control writes a whole new one through
  * `update`. `csv-model.ts` holds all of it and is pure.
  */
@@ -32,7 +32,7 @@ export interface Reparse {
 /**
  * Delimiter and header, both sniffed and both overridable.
  *
- * Re-parsing needs the original text, which the model does not keep — so the
+ * Re-parsing needs the original text, which the model does not keep, so the
  * source is rebuilt from the parsed rows. That is lossless for the purpose:
  * changing the delimiter after the fact re-splits fields that the wrong
  * delimiter merged, and the merged text is exactly what was in the file.
@@ -134,8 +134,8 @@ export function paintMapping(
 /**
  * One CSV column: its name, three samples, and where it goes.
  *
- * Re-picking a database column already taken **moves** it — `reassign` clears
- * the previous holder — so a duplicate mapping cannot be expressed here at all,
+ * Re-picking a database column already taken **moves** it (`reassign` clears
+ * the previous holder), so a duplicate mapping cannot be expressed here at all,
  * rather than being flagged after the fact.
  */
 function mappingRow(
@@ -148,8 +148,8 @@ function mappingRow(
   const row = box('map-row')
 
   const options = [
-    { value: SKIP_VALUE, label: '— skip —' },
-    { value: CONST_VALUE, label: '— constant… —' },
+    { value: SKIP_VALUE, label: '(skip)' },
+    { value: CONST_VALUE, label: '(constant…)' },
     ...ctx.columns.map(column => ({
       value: column.name,
       label: `${column.name} · ${column.type}`,
@@ -200,7 +200,7 @@ function constantControls(
 ): HTMLElement[] {
   const target = select(
     [
-      { value: SKIP_VALUE, label: '— into which column —' },
+      { value: SKIP_VALUE, label: '(into which column)' },
       ...ctx.columns.map(column => ({
         value: column.name,
         label: column.name,