@erclx/canon 5.25.0 → 5.26.0

package/docs/agents/skills-audit.md

@@ -36,7 +36,8 @@ Each check traces to a line in the standard.
 - Folder name in kebab-case
 - Each `REQUIREMENT.md` declaring `Gap` and `Must`, matched at any heading level
 - No ISO date in `SKILL.md` or any file under `references/`, reported as `datedProvenance` in the JSON record's `findings`
-- Each listed practice skill closing with `## Excuses and rebuttals`, `## Red flags`, and `## Before handing over`, and carrying `references/adopted.md`, reported as `practiceShape`
+- Each listed practice skill closing with `## Excuses and rebuttals`, `## Red flags`, and `## Before handing over`, and each skill on the wider ledger list carrying `references/adopted.md`, reported together as `practiceShape`
+- Each file under `references/` running over 100 lines opening with a `## Contents` H2, reported as `referenceContents`
 
 A body whose frontmatter does not parse reports as declaring neither field rather than ending the run, so one malformed file cannot hide the corpus behind it. A key present with an empty value reads as absent, since a blank `name` would otherwise report as a name disagreeing with every folder. A folder carrying no requirement is reported once under presence rather than counted again for the sections it therefore lacks.
 
@@ -44,7 +45,11 @@ The date check reads prose alone. A date inside a fence or a code span is exampl
 
 Each finding names the file and the line, such as `claude/skills/<name>/references/<file>.md  line 12: <date>`. A date after "measured" or "verified" reports like any other, unlike the context audit, because a skill body states the rule a session follows today rather than a reading of the tree.
 
-The practice check reads only the skills the audit lists, which the JSON record carries as `checkpoints.practiceSkills`. The list names folders under the toolkit's shipped `claude/skills/` corpus alone, so a project's own skill is never read as a practice skill and a same-named folder under `.claude/skills/` produces no finding. Where `claude/skills/` resolves, a listed folder it does not hold reports as a missing skill, so a renamed or misspelled entry cannot pass unread. Each closing section matches only as an exact H2 outside a fence, so an H3 or a heading carrying more words reports as missing.
+The practice check reads only the skills the audit lists, which the JSON record carries as `checkpoints.practiceSkills` for the closing sections and `checkpoints.ledgerSkills` for the ledger. The ledger list holds every practice skill plus the skills that cite outside sources without a practice's closing shape, so a skill on it alone owes the ledger and none of the sections.
+
+Both lists name folders under the toolkit's shipped `claude/skills/` corpus alone, so a project's own skill is never read as a practice skill and a same-named folder under `.claude/skills/` produces no finding. Where `claude/skills/` resolves, a listed folder it does not hold reports as a missing skill, so a renamed or misspelled entry cannot pass unread. Each closing section matches only as an exact H2 outside a fence, so an H3 or a heading carrying more words reports as missing.
+
+The contents check counts every line of a reference, frontmatter included, the way `wc -l` does, so a file of exactly 100 lines passes and one of 101 needs the list. `## Contents` matches the same way the closing sections do, as an exact H2 outside a fence. `SKILL.md` is never read for it, and the threshold travels in the JSON record as `checkpoints.contentsThreshold`.
 
 ## What it leaves alone
 
@@ -56,7 +61,9 @@ A check with no rule behind it prints an opinion as a defect, which is where the
 
 ## Exit codes
 
-Exit codes are `0` for a clean run, `1` for a refusal, and `2` for a skill folder carrying no `REQUIREMENT.md`. Only presence sets a failing code. Name, description, folder, requirement-section, dated-provenance, and practice shape findings print and return `0`, because each is a judgment a reader settles and failing a push on one would make the check something to route around. In the toolkit, two `bun run check` stages read the same report in-process and fail a push on dated provenance and on practice shape, since its own corpus is held at zero on both.
+Exit codes are `0` for a clean run, `1` for a refusal, and `2` for a skill folder carrying no `REQUIREMENT.md`. Only presence sets a failing code. Name, description, folder, requirement-section, dated-provenance, practice shape, and reference contents findings print and return `0`, because each is a judgment a reader settles and failing a push on one would make the check something to route around. In the toolkit, two `bun run check` stages read the same report in-process and fail a push on dated provenance and on practice shape, since its own corpus is held at zero on both.
+
+No stage reads reference contents, so a long reference without a list stays a report.
 
 ## The requirement gate
 

package/docs/agents/slides.md

@@ -1,16 +1,28 @@
 ---
 title: Slides
-description: What a folder of HTML slides declares for the whole deck in deck.json, the faces it embeds, what each slide declares on its own body, transitions and entrances, the master built from the project's tokens, speaker notes, charts, and what each refusal reports
+description: Where a deck folder lives and what it holds, what it declares for the whole deck in deck.json, the faces it embeds, what each slide declares on its own body, transitions and entrances, the master built from the project's tokens, speaker notes, charts, and what each refusal reports
 ---
 
 # Slides
 
-`canon slides render --source <folder>` turns a folder of `.html` slides into an editable PowerPoint deck. Each slide describes its own shapes. What belongs to the whole deck, being the bands, the numbers, and the mark, sits in one file beside them, and the master that carries it takes the project's own colors and face.
+`canon slides render <deck>` turns a folder of `.html` slides into an editable PowerPoint deck. Each deck lives in its own folder under `.canon/slides/`, which `canon records push` backs and git ignores, and `canon slides list --json` lists them. Each slide describes its own shapes. What belongs to the whole deck, being the bands, the numbers, and the mark, sits in one file beside them, and the master that carries it takes the project's own colors and face.
 
 ```bash
-canon slides render --source slides/q3-review
+canon slides list --json
+canon slides render q3-review
 ```
 
+## The deck folder
+
+| Path                             | Holds                                                |
+| -------------------------------- | ---------------------------------------------------- |
+| `.canon/slides/<deck>/*.html`    | the slides, rendered in filename order               |
+| `.canon/slides/<deck>/deck.json` | what belongs to the whole deck, described below      |
+| `.canon/slides/<deck>/assets/`   | images the slides reference by a relative path       |
+| `.canon/slides/layouts/`         | the project's shared layouts, never listed as a deck |
+
+A folder holding no `.html` file is not a deck. `render` with no name takes the only deck there is, and refuses with the list when there are several. It also takes a folder path outside `.canon/slides/`.
+
 ## The deck file
 
 `deck.json` beside the slides is optional. Without it the deck gets its defaults.

package/docs/workflow/ai-workflow.md

@@ -136,7 +136,7 @@ Before the first feature session on a UI-heavy project, pick a design tier. The
 
 ## Skills
 
-The [skill map](skill-map.md) gives every skill the plugin ships one row saying when to reach for it, grouped by the moment a project meets it.
+The [skill map](skill-map.md) and its sibling [skill map on request](skill-map-on-request.md) give every skill the plugin ships one row saying when to reach for it. The first groups rows by the moment a project meets them, and the sibling holds the skills that answer a request.
 
 ## Feedback routing
 

package/docs/workflow/index.md

@@ -15,6 +15,7 @@ How a person and their agents run a feature, from the design tier through the pa
 
 - [Operating model](operating-model.md): Orchestrator, planner, and worker roles for building across parallel sessions
 - [Parallel features](parallel-features.md): Run independent features in parallel worktrees, with the records and board every session shares
+- [Skill map on request](skill-map-on-request.md): When to reach for the plugin skills that serve a request rather than a moment in a project's life
 - [Skill map](skill-map.md): When to reach for each plugin skill, grouped by the moment a project meets it
 - [Visual design workflow](visual-design-workflow.md): Tiered guide for design and wireframe authoring with Claude Code
 - [Zshrc aliases for Claude Code](zshrc-aliases.md): Shell aliases that shorten common Claude Code invocations

package/docs/workflow/parallel-features.md

@@ -54,7 +54,7 @@ A plan that ships is archived, never deleted. `canon tasks archive` moves it to
 
 A branch review report takes the other route and is swept rather than archived. `review-branch` writes it flat into `.canon/review/` as `branch-<slug>.md`, the session addressing it reads it once, and the durable record of what a review found is the comment `review-pr` posts on the pull request, so `context-fold` deletes any report whose branch is gone. The body that writes a report owns how long it lives, which leaves the shipping branch's own report on disk through the run that cites it and collects it a branch later. What that loses is a local-only review on a branch that never opened a pull request, which is why the report says so where a reader meets it.
 
-`canon:context-fold` decides which task closed by reading the diff rather than the conversation. It resolves a merge base against `origin/main`, unions the committed diff with the working tree and untracked files, then matches unchecked outcomes on the board against what shipped. A task that shipped without ever being discussed still gets marked. Requirements, architecture, and design stay session-sourced, because a diff cannot carry a judgment.
+`canon:context-fold` decides which task closed by reading the diff rather than the conversation. It resolves a merge base against `origin/main`, unions the committed diff with the working tree and untracked files, then matches unchecked outcomes on the board against what shipped. A task that shipped without ever being discussed still gets marked. Architecture and design stay session-sourced, because a diff cannot carry a judgment, and an architecture write further needs a folded plan naming the slot decision. The requirements record is never folded. A direction change gets one report line naming `canon:document-health`, which reviews that record only when asked.
 
 ## The task board
 

package/docs/workflow/skill-map-on-request.md

@@ -0,0 +1,42 @@
+---
+title: Skill map on request
+description: When to reach for the plugin skills that serve a request rather than a moment in a project's life
+category: Workflow
+---
+
+# Skill map on request
+
+These two groups hold the skills no single moment in a project's life calls for, so they sit apart from the moment-ordered groups in the [skill map](skill-map.md). The two pages together are the corpus the coverage claim is measured against, and a skill takes one row across both.
+
+## Generate an artifact on demand
+
+| Skill                     | When to use                                                                                                                                    |
+| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| `canon:create-rule`       | For a project-specific governance rule the toolkit does not ship                                                                               |
+| `canon:create-skill`      | For a new `SKILL.md`                                                                                                                           |
+| `canon:create-standard`   | For a new authoring convention                                                                                                                 |
+| `canon:draft-doc`         | For a brand-new `docs/` page, context entry, wireframe surface, wiki reference page, or `README.md`, drafted against the standard for its kind |
+| `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task                                      |
+| `canon:draft-figure`      | For a hand-drawn figure or an architecture view inside an existing doc, drafted in Mermaid or freehand SVG                                     |
+| `canon:bash-cli-script`   | For a small non-interactive shell wrapper, stopping at 100 lines in favor of TypeScript on Bun                                                 |
+| `canon:ci-workflow`       | For a GitHub Actions workflow file                                                                                                             |
+| `canon:draft-slides`      | For a deck, drawn as HTML slides in its own folder and rendered to editable PowerPoint                                                         |
+| `canon:draft-screencast`  | For a recording script with beats and defaults already seeded                                                                                  |
+| `canon:record-screencast` | For recording a screencast draft, then composing the take into a finished mp4 when the draft asks for a wrap                                   |
+| `canon:draft-identity`    | For a project's logo mark and its social card, drafted through `draft-and-pick`'s pick loop                                                    |
+
+## Answer a question at any point
+
+| Skill                       | When to use                                                                                                                                                            |
+| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `canon:canon-cli`           | Before running an unfamiliar verb, a sync, or an install, to learn which command to run, which reference doc covers it, or what it overwrites, merges, or leaves alone |
+| `canon:index-lookup`        | To find where a topic is documented across the tracked `index.md` catalogs                                                                                             |
+| `canon:youtube-transcripts` | When a video transcript is wanted in the repo as context                                                                                                               |
+| `canon:read-frames`         | To read a recorded demo back frame by frame and report what each one shows, with no verdict on whether the recording looks right                                       |
+| `canon:teach-workspace`     | To learn a subject across sessions, in a workspace that holds the progress                                                                                             |
+| `canon:write-human`         | Before drafting or revising prose, for voice, rhythm, and density                                                                                                      |
+| `canon:restate-plainly`     | When an answer or a document has to be read again in plain words                                                                                                       |
+
+Every row answers a question rather than marking a point in a project's life, so filing one under a phase on the [skill map](skill-map.md) would send a reader to the wrong group.
+
+A learning workspace produces two halves and only one of them leaves. A lesson is worked through once and stays in the workspace, and a reference page or a glossary carries no learner, so it belongs wherever the project already keeps prose on that subject. Asking `canon:teach-workspace` to promote sorts each durable page by who owns its subject, sending an Anthropic-owned subject to the wiki, an internal one to the matching context entry, and everything else, subject-neutral material included, to the public docs. It proposes and waits, because a promoted page is public prose that needs a line naming who owns the subject, and it writes nothing to a destination: each page the operator confirms goes to a handoff file that `canon:context-fold` folds in from a branch. A project with no wiki folder gets a refusal naming `canon wiki init` rather than a folder it never asked for.

package/docs/workflow/skill-map.md

@@ -8,7 +8,7 @@ category: Workflow
 
 Groups run in the order a project meets them. They reconcile the scenarios in [AI workflow](ai-workflow.md) with the lifecycle [target projects](../target/projects.md) describes, so every moment either one names has a group. Each row says when to reach for a skill, and its description says what it does.
 
-This page is the corpus the coverage claim is measured against: every name `canon claude skills list --names` reports takes exactly one row here. A skill serving two moments sits at the earlier one, and a mention on any other page is prose rather than routing. The landing page's skills field renders from this page, so its build refuses a skill with no row and a row naming no skill.
+This page and [skill map on request](skill-map-on-request.md) are the corpus the coverage claim is measured against: every name `canon claude skills list --names` reports takes exactly one row across the two. A skill serving two moments sits at the earlier one, this page counting as earlier than the sibling, and a mention on any other page is prose rather than routing. The sibling holds the groups that answer a request rather than mark a moment. The landing page's skills field renders from both pages, so its build refuses a skill with no row and a row naming no skill.
 
 ## Set up a project
 
@@ -115,36 +115,3 @@ This page is the corpus the coverage claim is measured against: every name `cano
 | `canon:canon-feedback`        | When something in the toolkit is broken, missing, or off, to open an issue on it       |
 | `canon:canon-feedback-triage` | In the toolkit repo, to work through the open feedback issues                          |
 | `canon:canon-rollout`         | In the toolkit repo, to take one change out to every consuming project at once         |
-
-## Generate an artifact on demand
-
-| Skill                     | When to use                                                                                                                                    |
-| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| `canon:create-rule`       | For a project-specific governance rule the toolkit does not ship                                                                               |
-| `canon:create-skill`      | For a new `SKILL.md`                                                                                                                           |
-| `canon:create-standard`   | For a new authoring convention                                                                                                                 |
-| `canon:draft-doc`         | For a brand-new `docs/` page, context entry, wireframe surface, wiki reference page, or `README.md`, drafted against the standard for its kind |
-| `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task                                      |
-| `canon:draft-figure`      | For a hand-drawn figure or an architecture view inside an existing doc, drafted in Mermaid or freehand SVG                                     |
-| `canon:bash-cli-script`   | For a small non-interactive shell wrapper, stopping at 100 lines in favor of TypeScript on Bun                                                 |
-| `canon:ci-workflow`       | For a GitHub Actions workflow file                                                                                                             |
-| `canon:draft-slides`      | For a deck, drafted as `.claude/SLIDES.md` and rendered to PowerPoint                                                                          |
-| `canon:draft-screencast`  | For a recording script with beats and defaults already seeded                                                                                  |
-| `canon:record-screencast` | For recording a screencast draft, then composing the take into a finished mp4 when the draft asks for a wrap                                   |
-| `canon:draft-identity`    | For a project's logo mark and its social card, drafted through `draft-and-pick`'s pick loop                                                    |
-
-## Answer a question at any point
-
-| Skill                       | When to use                                                                                                                                                            |
-| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `canon:canon-cli`           | Before running an unfamiliar verb, a sync, or an install, to learn which command to run, which reference doc covers it, or what it overwrites, merges, or leaves alone |
-| `canon:index-lookup`        | To find where a topic is documented across the tracked `index.md` catalogs                                                                                             |
-| `canon:youtube-transcripts` | When a video transcript is wanted in the repo as context                                                                                                               |
-| `canon:read-frames`         | To read a recorded demo back frame by frame and report what each one shows, with no verdict on whether the recording looks right                                       |
-| `canon:teach-workspace`     | To learn a subject across sessions, in a workspace that holds the progress                                                                                             |
-| `canon:write-human`         | Before drafting or revising prose, for voice, rhythm, and density                                                                                                      |
-| `canon:restate-plainly`     | When an answer or a document has to be read again in plain words                                                                                                       |
-
-Every row answers a question rather than marking a point in a project's life, so a phase above would send a reader to the wrong group.
-
-A learning workspace produces two halves and only one of them leaves. A lesson is worked through once and stays in the workspace, and a reference page or a glossary carries no learner, so it belongs wherever the project already keeps prose on that subject. Asking `canon:teach-workspace` to promote sorts each durable page by who owns its subject, sending an Anthropic-owned subject to the wiki, an internal one to the matching context entry, and everything else, subject-neutral material included, to the public docs. It proposes and waits, because a promoted page is public prose that needs a line naming who owns the subject, and it writes nothing to a destination: each page the operator confirms goes to a handoff file that `canon:context-fold` folds in from a branch. A project with no wiki folder gets a refusal naming `canon wiki init` rather than a folder it never asked for.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "5.25.0",
+  "version": "5.26.0",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
   "license": "MIT",
   "bin": {

package/scripts/lib/sandbox-dispatch.sh

@@ -11,7 +11,7 @@
 #
 # Three mechanisms sit here rather than in `sandbox/run.sh`, which is the
 # only caller. Each is reachable from a test that never launches a session:
-# `src/sandbox-dispatch.test.ts` drives the shim against a stub binary and the
+# `src/sandbox/dispatch.test.ts` drives the shim against a stub binary and the
 # reap against a `sleep`, where proving either through `run.sh` would mean
 # spawning the thing the bound exists to prevent.
 

package/scripts/lib/sandbox-git.sh

@@ -60,7 +60,7 @@ configure_sandbox_git_identity() {
 SANDBOX_ANCHOR_REPO="canon-sandbox"
 
 # A scenario calls this from its own use_anchor hook rather than this file
-# defining the hook. manage-sandbox.sh keys off `type -t use_anchor`, so
+# defining the hook. sandbox-hook.sh keys off `type -t use_anchor`, so
 # declaring it here would hand an anchor to the scenarios that source this file
 # for the identity helpers alone.
 use_sandbox_anchor() {
@@ -112,14 +112,6 @@ ensure_sandbox_anchor_repo() {
   log_info "Created ${GITHUB_ORG}/${repo_name} as a private repository."
 }
 
-# Mirrors the merge-base resolution the diff-baseline port already carries
-# across five skill bodies, so a checkout whose local main trails origin/main
-# does not pull in skill bodies other merged branches changed.
-resolve_sandbox_skill_diff_base() {
-  git -C "$PROJECT_ROOT" merge-base HEAD origin/main 2>/dev/null ||
-    git -C "$PROJECT_ROOT" merge-base HEAD main 2>/dev/null
-}
-
 # A remote is useless without an author, so the scenarios that reach one always
 # configure both. configure_sandbox_git_identity stays callable on its own for
 # the scenarios that never push. The probe runs first so an absent remote is

package/scripts/lib/sandbox-path.sh

@@ -13,7 +13,7 @@
 # Mints a short random per-run identifier the first time it is asked for, then
 # holds it in CANON_SANDBOX_RUN_ID for the rest of this process. A direct call
 # (not `$(...)`) exports it into the caller's own shell, which is what lets
-# `run.sh` mint once and have manage-sandbox.sh and the check it shells out to
+# `run.sh` mint once and have the provisioning and the check it shells out to
 # both inherit the same id as ordinary children. A call already carrying the
 # variable, inherited from such a parent, reuses it rather than minting a new one.
 #

package/scripts/sandbox-hook.sh

@@ -0,0 +1,99 @@
+#!/usr/bin/env bash
+# No `-u`. Scenarios ran under the retired dispatcher without it and read unset
+# variables as empty, so turning it on here changes what they provision.
+set -e
+set -o pipefail
+
+# Runs one scenario's hooks for the provisioning order in
+# `src/sandbox/provision.ts`. Scenarios and the library they call stay bash, so
+# the harness reaches them through this entry and nothing else.
+#
+#   probe <scenario>         runs `use_config` and `use_anchor` when declared
+#                            and prints every export they changed, closed by an
+#                            `@anchor=<0|1>` record
+#   stage <scenario> <file>  re-runs both hooks, runs `stage_setup` inside the
+#                            tree, and writes the exports it changed to <file>,
+#                            or an `@exited` record when the shell exits first
+#
+# Pairs are NUL-separated `NAME=value`, since a value can hold a newline. The
+# retired dispatcher ran `stage_setup` in its own shell, so an export, an `exit`,
+# or an `exec` there reached the harness, and the report carries all three: an
+# `exec` skips the EXIT trap and leaves no report at all. The stage re-runs the
+# hooks rather than receiving the probe's pairs, since they only export.
+
+SCRIPT_DIR="$(cd "$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")" && pwd)"
+PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"
+export PROJECT_ROOT
+
+# Globals carry a prefix, since the scenario sourced below shares this shell.
+_hook_die() {
+  echo "sandbox-hook: $1" >&2
+  exit 2
+}
+_hook_mode="${1:-}"
+_hook_scenario="${2:-}"
+_hook_report="${3:-}"
+
+[[ "$_hook_mode" == "probe" || "$_hook_mode" == "stage" ]] || _hook_die "mode must be probe or stage, got: ${_hook_mode:-<empty>}"
+[ -f "$_hook_scenario" ] || _hook_die "no scenario file at: ${_hook_scenario:-<empty>}"
+[ "$_hook_mode" = "probe" ] || [ -n "$_hook_report" ] || _hook_die "stage needs a file to report its exports to"
+[ "$_hook_mode" = "probe" ] || trap 'printf "@exited\0" >"$_hook_report"' EXIT
+
+declare -A _hook_before
+_hook_snapshot() {
+  local name
+  _hook_before=()
+  for name in $(compgen -e); do
+    _hook_before[$name]="${!name}"
+  done
+}
+
+# The shell moves PWD and OLDPWD itself on every `cd`, and neither is state.
+_hook_changed() {
+  local name
+  for name in $(compgen -e); do
+    [[ "$name" == "PWD" || "$name" == "OLDPWD" ]] && continue
+    if [[ ! -v _hook_before[$name] ]] || [ "${_hook_before[$name]}" != "${!name}" ]; then
+      printf '%s=%s\0' "$name" "${!name}"
+    fi
+  done
+}
+
+# Taken before `config.sh`, so a `GITHUB_ORG` it derives from the remote reaches
+# the harness as an export like any other.
+_hook_snapshot
+
+source "$PROJECT_ROOT/scripts/config.sh"
+source "$PROJECT_ROOT/scripts/lib/ui.sh"
+source "$PROJECT_ROOT/scripts/lib/sandbox-path.sh"
+source "$PROJECT_ROOT/scripts/lib/sandbox-git.sh"
+source "$PROJECT_ROOT/scripts/lib/sandbox-fixtures.sh"
+
+# Unexported, as the dispatcher held them, so a scenario reads both while a
+# child it spawns sees neither. Shellcheck cannot see the scenario reading them.
+# shellcheck disable=SC2034
+SANDBOX="$(resolve_sandbox_dir)" SANDBOX_DIR="$PROJECT_ROOT/sandbox"
+
+# shellcheck source=/dev/null
+source "$_hook_scenario"
+
+_hook_declared() { [[ "$(type -t "$1")" == "function" ]]; }
+_hook_run() {
+  if _hook_declared use_config; then use_config; fi
+  if _hook_declared use_anchor; then use_anchor; fi
+}
+
+if [ "$_hook_mode" = "probe" ]; then
+  # Stdout carries the pairs alone, so a hook that prints is moved off it.
+  _hook_run >&2
+  _hook_changed
+  if _hook_declared use_anchor; then printf '@anchor=1\0'; else printf '@anchor=0\0'; fi
+  exit 0
+fi
+
+_hook_run
+_hook_snapshot
+cd "$SANDBOX"
+stage_setup
+trap - EXIT
+_hook_changed >"$_hook_report"

package/src/canvas/capture.ts

@@ -196,14 +196,6 @@ async function serveFor<T>(
 /** The element a composite is captured by, holding every frame and no chrome. */
 export const COMPOSITE_SELECTOR = '#canvas-composite'
 
-/**
- * The container holds no text, so its family exists only for the engine's
- * font probe, which rejects a family the machine lacks. The browser default is
- * Times New Roman, which a Linux runner often lacks, and `system-ui` is the one
- * every platform maps. Each frame keeps its own fonts inside its iframe.
- */
-const COMPOSITE_FONT = 'system-ui'
-
 export interface Placement {
   readonly frame: string
   readonly url: string
@@ -255,7 +247,7 @@ export function buildComposite(
   const html = [
     '<!doctype html>',
     '<html><head><meta charset="utf-8">',
-    `<style>html,body{margin:0;background:transparent}#canvas-composite{position:relative;font-family:${COMPOSITE_FONT}}#canvas-composite iframe{position:absolute;display:block;border:0;background:transparent}</style>`,
+    `<style>html,body{margin:0;background:transparent}#canvas-composite{position:relative}#canvas-composite iframe{position:absolute;display:block;border:0;background:transparent}</style>`,
     '</head><body>',
     `<div id="canvas-composite" style="width:${width}px;height:${height}px">`,
     ...iframes,