mulmoterminal 7.2.0 → 7.3.0

package/README.md

@@ -183,18 +183,19 @@ than as bytes (files within the session's working directory only):
 **A line after the path is followed.** `src/a.ts:42`, `src/a.ts:42:7` (gcc, clang, `eslint -f unix`,
 stack traces) and `src/a.ts(12,5)` (tsc) are one link. In the pane, and in the Files view, the file
 opens as text with the caret on that line and column — an HTML page, an SVG or a table included, and a
-tab reading in Preview switches to Edit. A route that renders the file in a new tab (`.md`, `.json`,
+tab reading in Preview switches to Edit. An image, a PDF, a video or an audio file has no line to go
+to and simply opens as itself. A route that renders the file in a new tab (`.md`, `.json`,
 `.csv`, `.html` with no cell enlarged) ignores the line. When the pane beside an enlarged cell takes
 the click, the keyboard stays in the terminal; the full-screen Files view, with no terminal beside it,
 puts it in the editor. (ESLint's default output puts the path on a line of its own, with no line number to follow.)
 
 **While a grid cell is enlarged, the [Files pane](#files-view-browse--edit) takes the click first** — every
-row above except PDF, video and audio, since the pane is the same editor with a Preview for
-Markdown, HTML and SVG, and shows an image as a picture. The file opens *beside* the terminal
+row above, since the pane is the same editor with a Preview for Markdown, HTML and SVG, shows an
+image as a picture and a PDF in a frame, and plays a video or an audio file with the browser's own
+controls (seeking included, whatever the file's size). The file opens *beside* the terminal
 that printed it, and the pane opens itself if it was closed. It declines, leaving the routing
-above untouched, when nothing is enlarged, when the path is not under that cell's own directory
-(the pane cannot walk above its root), or for a PDF, a video or an audio file, which only a
-browser tab can play.
+above untouched, when nothing is enlarged, or when the path is not under that cell's own directory
+(the pane cannot walk above its root). A file too large to edit as text still offers **Open in OS**.
 
 Highlighting in the Files view covers the JS/TS family, JSON and Markdown (the modes
 `cmEditor.ts` bundles); other languages open as plain text.
@@ -823,7 +824,7 @@ The Settings modal (the gear button) persists per-user UI choices to `~/.mulmote
 | `autoDirIcon` | Whether a project that sets no `icon` shows the favicon its repository already ships (`public/favicon.svg`, `apple-touch-icon.png`, a web manifest — first hit wins, ordered by how the image survives at 14px). **On by default**; Settings → **Directory appearance** has the switch. A single project opts out with `"icon": false` in its own `.mulmoterminal.json`, which this does not override. A key that was written and got it wrong shows nothing rather than falling back — a broken setting has to look broken. `true` / `false` only. |
 | `cockpitLines` | `{ summary, prompt, response }` — how many lines each **cockpit-roster** row shows before it clamps (default `2` / `2` / `3`, each clamped to `1`–`20`). Raising them trades how many sessions fit on screen for reading a long one in place. Three steppers in Settings → **Waiting rows**. |
 | `showLoadAverage` | Whether the grid header draws this machine's **load average** beside the 5h / 7d usage windows, as a percentage of its cores (`load 334%` = a 20-core machine with 66.8 runnable processes). **On by default**; amber at 100%, red at 200%, hover for the raw 1 / 5 / 15-minute figures. Settings → **Grid header read-outs** has the switch. A host that keeps no load average (Windows) shows nothing rather than `0%`, whatever this says. `true` / `false` only. |
-| `remoteServer` | **Experimental.** The server runs on another machine than your browser (an SSH tunnel — [guide](https://receptron.github.io/mulmoterminal/guide/en/remote.html)): the actions that would act on the server's screen (the file dialog, the file manager, the OS app) are hidden or say why, and a dropped file is always uploaded. **Off unless `true`**; set it in the server's config. |
+| `remoteServer` | **Experimental.** The server runs on another machine than your browser (an SSH tunnel — [guide](https://receptron.github.io/mulmoterminal/guide/en/remote.html)): the actions that would act on the server's screen (the file dialog, the file manager, the OS app) are hidden or say why, and a dropped file is always uploaded. **Off unless `true`**; Settings → **Sessions and background tasks** has the box (or set it in the server's config). |
 | `fontFamily` | The **terminal font** every session renders in — a CSS font-family stack, e.g. `"'Cica', 'MS Gothic', monospace"`. Set it in Settings → **Terminal font**, applied at once; editing the file instead needs a **restart** (this config is read once at startup). Unset uses the built-in stack (JetBrains Mono / Fira Code / Menlo / Consolas, then CJK faces for Japanese, Korean and Chinese). Unlike the per-browser font **size**, this is one value for the whole host — it names fonts, and which fonts exist is a property of the machine. A directory can override it. See the [Configuration guide](https://receptron.github.io/mulmoterminal/guide/en/config.html#font-family). |
 
 Every MulmoTerminal on the machine shares this one file, so an older build could save over a key a
@@ -1342,11 +1343,13 @@ or changed (amber), and a notch where lines were removed, as VS Code's gutter sh
 to date as you type. **Changes** in the header also shows the removed lines in place, as a unified
 diff. Nothing is marked for a file outside git or one not yet committed.
 
-**HTML pages and images show in the pane too.** An `.html` file has a **Preview** like a Markdown
+**HTML pages, images, PDFs, video and audio show in the pane too.** An `.html` file has a **Preview** like a Markdown
 file: the page itself, sandboxed as presentHtml pages are — its scripts run on an opaque origin with
 no fetch/XHR; images and the curated CDN list still load, and so does an image it links beside it,
-while a relative stylesheet or script does not. An `.svg` previews as the picture it draws, and a PNG, JPEG, GIF or WebP opens as the image
-rather than as "not text". A path to any of these clicked in terminal output opens in the pane when
+while a relative stylesheet or script does not. An `.svg` previews as the picture it draws, a PNG, JPEG, GIF or WebP opens as the image
+rather than as "not text", a PDF opens in a frame, and a video or audio file plays with the
+browser's controls, seeking by range rather than fetching the whole file. A text file too large to edit
+says so and still offers **Open in OS**. A path to any of these clicked in terminal output opens in the pane when
 it is up, so a chart an agent just wrote stays in the grid. They are served only under the workspace
 or a terminal's directory, like every other file the app hands to the browser.
 

package/blueprints/compare/checks/articles.d.mts

@@ -0,0 +1,8 @@
+// Types for articles.mjs, which the pack runs with plain node and the specs import.
+export type Article = { readonly address: string; readonly label: string; readonly body: string };
+export type Row = { readonly old?: string | null; readonly new?: string | null; readonly change: string; readonly what?: string };
+
+export declare const CHANGES: readonly string[];
+export declare const articlesIn: (tree: unknown, text: string) => Article[];
+export declare const mentions: (text: string, name: string) => boolean;
+export declare const comparisonProblems: (rows: unknown, olds: readonly Article[], news: readonly Article[]) => string[];

package/blueprints/compare/checks/articles.mjs

@@ -0,0 +1,109 @@
+// Two versions of a document, article by article: each article's body as chaff's tree spans it, and whether the
+// pairing an agent wrote says the truth about them. What changed is read by the agent; whether anything changed
+// at all is decided here, by comparing text, so "unchanged" cannot be written over a changed article or the
+// other way round.
+
+export const CHANGES = ["same", "changed", "added", "removed"];
+
+// Spacing aside: a reflowed line is not a change to what an article says.
+const squash = (text) => String(text).replace(/\s+/gu, "");
+
+const articleNodes = (node) => [
+  ...(node?.kind === "article" && typeof node.address === "string" && node.address !== "" ? [node] : []),
+  ...(Array.isArray(node?.children) ? node.children.flatMap(articleNodes) : []),
+];
+
+// The article's own number (第4条, Article 4) is where it sits, not what it says: a renumbered article is the same.
+const withoutLabel = (text, label) => {
+  const trimmed = text.trimStart();
+  return typeof label === "string" && label !== "" && trimmed.startsWith(label) ? trimmed.slice(label.length) : trimmed;
+};
+
+/** Each article of `text` as `tree` (chaff tree --format json) reads it: its address, label and body. */
+export const articlesIn = (tree, text) =>
+  articleNodes(tree).map((node) => {
+    const whole = String(text).slice(node.span?.start ?? 0, node.span?.end ?? 0);
+    return { address: node.address, label: node.attrs?.label ?? node.address, body: squash(withoutLabel(whole, node.attrs?.label)) };
+  });
+
+const rowShape = (row, index) => {
+  if (row === null || typeof row !== "object") return `row ${index + 1} is not an object`;
+  if (!CHANGES.includes(row.change)) return `row ${index + 1}: "change" must be one of ${CHANGES.join(", ")}`;
+  const has = (side) => typeof row[side] === "string" && row[side] !== "";
+  const wanted = { same: [true, true], changed: [true, true], added: [false, true], removed: [true, false] }[row.change];
+  if (has("old") !== wanted[0] || has("new") !== wanted[1])
+    return `row ${index + 1}: a "${row.change}" row has ${wanted[0] ? "an" : "no"} "old" and ${wanted[1] ? "a" : "no"} "new"`;
+  if (row.change === "changed" && !(typeof row.what === "string" && row.what.trim() !== "")) return `row ${index + 1}: say in "what" what changed`;
+  return null;
+};
+
+// Every article of a version in exactly one row, and no row naming one that is not there.
+const coverage = (rows, articles, side, version) => {
+  const named = rows.map((row) => row[side]).filter((address) => typeof address === "string" && address !== "");
+  const known = articles.map((article) => article.address);
+  return [
+    ...known.filter((address) => !named.includes(address)).map((address) => `${version} ${labelOf(articles, address)}: in no row`),
+    ...[...new Set(named.filter((address, index) => named.indexOf(address) !== index))].map(
+      (address) => `${version} ${labelOf(articles, address)}: in more than one row`,
+    ),
+    ...named.filter((address) => !known.includes(address)).map((address) => `${version} has no article at ${address}`),
+  ];
+};
+
+const labelOf = (articles, address) => articles.find((article) => article.address === address)?.label ?? address;
+
+// A pair said to be the same must read the same, and one said to have changed must not.
+const truth = (row, olds, news) => {
+  if (row.change !== "same" && row.change !== "changed") return null;
+  const [was, now] = [olds.find((article) => article.address === row.old), news.find((article) => article.address === row.new)];
+  if (!was || !now) return null;
+  const pair = `${labelOf(olds, row.old)} → ${labelOf(news, row.new)}`;
+  if (row.change === "same" && was.body !== now.body) return `${pair}: written "same", but the text differs`;
+  if (row.change === "changed" && was.body === now.body) return `${pair}: written "changed", but the text is the same`;
+  return null;
+};
+
+// A provision removed from the old version and added to the new one word for word is one that moved: a pair missed.
+const missedPairs = (rows, olds, news) => {
+  const bodyOf = (articles, address) => articles.find((article) => article.address === address)?.body;
+  const added = rows.filter((row) => row.change === "added").map((row) => row.new);
+  return rows
+    .filter((row) => row.change === "removed")
+    .flatMap((row) => {
+      const body = bodyOf(olds, row.old);
+      const twin = added.find((address) => body !== undefined && bodyOf(news, address) === body);
+      return twin === undefined ? [] : [`${labelOf(olds, row.old)} (removed) and ${labelOf(news, twin)} (added) read the same: pair them as "same"`];
+    });
+};
+
+/** What is wrong with `rows` (the pairing) for the articles `olds` and `news`. */
+export const comparisonProblems = (rows, olds, news) => {
+  if (!Array.isArray(rows)) return ['the pairing needs a "rows" list'];
+  const shapes = rows.map(rowShape).filter((problem) => problem !== null);
+  if (shapes.length > 0) return shapes;
+  return [
+    ...coverage(rows, olds, "old", "the old version"),
+    ...coverage(rows, news, "new", "the new version"),
+    ...rows.map((row) => truth(row, olds, news)).filter((problem) => problem !== null),
+    ...missedPairs(rows, olds, news),
+  ];
+};
+
+// Where a name stops and another article's number would go on. A name ending in a letter or digit ("Article 1")
+// stops at a word boundary, so "Article 12", "Article 1bis" and "Article 1-2" are other words. A name ending in any
+// other character (第1条) goes on only into a branch number: a digit, or の/之/ノ with a numeral (第1条の2,
+// 第二十一条の二) — 「第1条の委託料」 still names 第1条, and so does 「第1条第2項」.
+// Letters of the Latin script (full-width ones too) and decimal digits of any width: kana and kanji end the word.
+const WORD_END = /[\p{Script=Latin}\p{Nd}]$/u;
+// A dash of any kind, a point or a slash between two word characters joins them into one number (1-2, 1–2, 1.2, 1/2).
+const WORD_GOES_ON = /^(?:[\p{Script=Latin}\p{Nd}]|[\p{Pd}.．/／][\p{Script=Latin}\p{Nd}])/u;
+const BRANCH_GOES_ON = /^(?:[0-9０-９]|[の之ノ][0-9０-９一二三四五六七八九十百千])/u;
+
+/** Whether `text` names the article `name`: a match that goes on into a longer number names another article. */
+export const mentions = (text, name) => {
+  const goesOn = WORD_END.test(name) ? WORD_GOES_ON : BRANCH_GOES_ON;
+  const source = String(text);
+  const escaped = name.replace(/[.*+?^${}()|[\]\\]/gu, "\\$&");
+  const hits = [...source.matchAll(new RegExp(escaped, "gu"))].map((match) => match.index ?? 0);
+  return hits.some((index) => !goesOn.test(source.slice(index + name.length)));
+};

package/blueprints/compare/checks/base.mjs

@@ -0,0 +1,12 @@
+// The docs base holds the helpers every usecase on it shares (running chaff, reading Markdown sections).
+// A usecase loads them from BLUEPRINT_BASE, which the executor sets for every check.
+import { join } from "node:path";
+import { pathToFileURL } from "node:url";
+
+if (!process.env.BLUEPRINT_BASE) {
+  console.error("BLUEPRINT_BASE is not set: run this check through the blueprint executor");
+  process.exit(1);
+}
+
+/** The URL of a module in the docs base's checks/, for `await import(...)`. */
+export const fromBase = (file) => pathToFileURL(join(process.env.BLUEPRINT_BASE, "checks", file)).href;

package/blueprints/compare/checks/comparison.mjs

@@ -0,0 +1,22 @@
+// The pair step's check: .blueprint/comparison.json pairs every article of the old version with its article in the
+// new one, and says truly whether each changed. Writes the pairing as a person reads it at the gate, and records
+// what was checked so the report can tell the documents and the pairing were not touched since.
+import { writeFileSync } from "node:fs";
+import { fromBase } from "./base.mjs";
+import { comparisonProblems } from "./articles.mjs";
+import { comparisonText } from "./comparisonView.mjs";
+import { readVersions } from "./versions.mjs";
+const { fail, readJson } = await import(fromBase("chaff.mjs"));
+const { fingerprint } = await import(fromBase("documents.mjs"));
+
+const PAIRING = ".blueprint/comparison.json";
+const READABLE = ".blueprint/comparison.txt";
+const CHECKED = ".blueprint/.comparison-checked";
+
+const versions = readVersions();
+const rows = readJson(PAIRING, '{ "rows": [{ "old", "new", "change", "what" }] }')?.rows;
+const problems = comparisonProblems(rows, versions.old.articles, versions.new.articles);
+if (problems.length > 0) fail(`${PAIRING}:\n  ${problems.join("\n  ")}`);
+writeFileSync(READABLE, comparisonText(rows, versions.old.articles, versions.new.articles));
+writeFileSync(CHECKED, JSON.stringify({ old: versions.old.print, new: versions.new.print, pairing: fingerprint(PAIRING) }) + "\n");
+console.log(`${rows.length} pair(s): every article accounted for`);

package/blueprints/compare/checks/comparisonView.d.mts

@@ -0,0 +1,4 @@
+// Types for comparisonView.mjs, which the pack runs with plain node and the specs import.
+import type { Article, Row } from "./articles.mjs";
+
+export declare const comparisonText: (rows: readonly Row[], olds: readonly Article[], news: readonly Article[]) => string;

package/blueprints/compare/checks/comparisonView.mjs

@@ -0,0 +1,14 @@
+// The pairing as plain text a person reads at the gate: one line a pair, the old article first. The marks are the
+// ones a diff uses, so they read the same in any language: "=" unchanged, "~" changed, "+" added, "-" removed.
+
+const MARKS = { same: "=", changed: "~", added: "+", removed: "-" };
+
+const labelOf = (articles, address) => (typeof address === "string" ? (articles.find((article) => article.address === address)?.label ?? address) : "");
+
+const lineOf = (row, olds, news) => {
+  const pair = `${labelOf(olds, row.old)} → ${labelOf(news, row.new)}`.trim();
+  const what = typeof row.what === "string" && row.what.trim() !== "" ? `  ${row.what.split("\n").join(" ").trim()}` : "";
+  return `${MARKS[row.change] ?? "?"} ${pair}${what}`;
+};
+
+export const comparisonText = (rows, olds, news) => [...rows.map((row) => lineOf(row, olds, news)), ""].join("\n");

package/blueprints/compare/checks/report.mjs

@@ -0,0 +1,47 @@
+// The report is the comparison table the person keeps: every pair that is not unchanged is in it, the documents
+// and the pairing are as the pair step checked them, and it says what was checked.
+import { existsSync, readFileSync } from "node:fs";
+import { fromBase } from "./base.mjs";
+import { mentions } from "./articles.mjs";
+import { readVersions } from "./versions.mjs";
+const { fail, readJson } = await import(fromBase("chaff.mjs"));
+const { missingSections, sectionText } = await import(fromBase("markdown.mjs"));
+const { fingerprint } = await import(fromBase("documents.mjs"));
+
+const PAIRING = ".blueprint/comparison.json";
+const CHECKED = ".blueprint/.comparison-checked";
+const REPORT = ".blueprint/compare-report.md";
+const TABLE = ["新旧対照表", "Comparison table"];
+const SECTIONS = [TABLE, ["確かめたこと", "What was checked"]];
+
+const versions = readVersions();
+// What the pair step recorded; anything else (missing, not JSON) means that step has to run again.
+const recorded = () => {
+  try {
+    return JSON.parse(readFileSync(CHECKED, "utf8"));
+  } catch {
+    return null;
+  }
+};
+const checked = existsSync(CHECKED) ? recorded() : null;
+if (checked === null || typeof checked !== "object") fail("the pair step's record is missing: run that step again");
+if (checked?.old !== versions.old.print || checked?.new !== versions.new.print) fail("a version changed since the pair step checked it: run that step again");
+if (checked.pairing !== fingerprint(PAIRING)) fail(`${PAIRING} changed since the pair step checked it: run that step again`);
+const rows = readJson(PAIRING, "the pairing").rows;
+
+if (!existsSync(REPORT)) fail(`${REPORT} is missing`);
+const text = readFileSync(REPORT, "utf8");
+const missing = missingSections(text, SECTIONS);
+if (missing.length > 0) fail(`${REPORT} lacks sections: ${missing.join(", ")}`);
+
+const table = sectionText(text, TABLE);
+
+const labelOf = (articles, address) => articles.find((article) => article.address === address)?.label ?? address;
+const absent = rows
+  .filter((row) => row.change !== "same")
+  .flatMap((row) => {
+    const names = [...(row.old ? [labelOf(versions.old.articles, row.old)] : []), ...(row.new ? [labelOf(versions.new.articles, row.new)] : [])];
+    return names.every((name) => mentions(table, name)) ? [] : [`${row.change} ${names.join(" → ")}`];
+  });
+if (absent.length > 0) fail(`${REPORT}: the table does not show: ${absent.join(", ")}`);
+console.log("the report shows every article that changed, was added or was removed");

package/blueprints/compare/checks/versions.mjs

@@ -0,0 +1,33 @@
+// The two versions the person named, read the same way by every check: one file each, inside this folder, with
+// its articles as chaff's tree gives them.
+import { readFileSync } from "node:fs";
+import { fromBase } from "./base.mjs";
+import { articlesIn } from "./articles.mjs";
+const { fail, readJson } = await import(fromBase("chaff.mjs"));
+const { documentsNamed, fingerprint } = await import(fromBase("documents.mjs"));
+const { treeOf } = await import(fromBase("places.mjs"));
+
+const oneFile = (listed, which) => {
+  const files = documentsNamed(listed);
+  if (files.length !== 1) fail(`the ${which} version must be one file; the answer names ${files.length}`);
+  return files[0];
+};
+
+const articlesOf = (file, which) => {
+  const tree = treeOf(file);
+  if (tree === null) fail(`chaff could not read the ${which} version, ${file}`);
+  const articles = articlesIn(tree, readFileSync(file, "utf8"));
+  if (articles.length === 0) fail(`the ${which} version, ${file}, has no article chaff reads (第1条, Article 1): this compares documents numbered by article`);
+  return articles;
+};
+
+/** Both versions: their files, articles and fingerprints. */
+export const readVersions = () => {
+  const answers = readJson(".blueprint/answers.json", "the interview answers");
+  const [oldFile, newFile] = [oneFile(answers.old, "old"), oneFile(answers.new, "new")];
+  if (oldFile === newFile) fail("the old and the new version are the same file");
+  return {
+    old: { file: oldFile, articles: articlesOf(oldFile, "old"), print: fingerprint(oldFile) },
+    new: { file: newFile, articles: articlesOf(newFile, "new"), print: fingerprint(newFile) },
+  };
+};

package/blueprints/compare/hearing.json

@@ -0,0 +1,27 @@
+{
+  "questions": [
+    {
+      "id": "old",
+      "label": "旧版の文書（このフォルダの中のファイル 1 つ）",
+      "why": "比べる元。条ごとに新版と対応づける",
+      "kind": "text",
+      "pick": "files",
+      "lines": true
+    },
+    {
+      "id": "new",
+      "label": "新版の文書（このフォルダの中のファイル 1 つ）",
+      "why": "比べる先",
+      "kind": "text",
+      "pick": "files",
+      "lines": true
+    },
+    {
+      "id": "focus",
+      "label": "特に見てほしいこと（任意）",
+      "why": "その点に関わる変更を先に、詳しく書く",
+      "kind": "text",
+      "required": false
+    }
+  ]
+}

package/blueprints/compare/manifest.json

@@ -0,0 +1,9 @@
+{
+  "slug": "compare",
+  "kind": "usecase",
+  "title": "版を比べる（新旧対照表をつくる）",
+  "version": "0.1.0",
+  "description": "契約書や規程の旧版と新版を条ごとに対応づけ、何が変わり、何が足され、何が消えたかを新旧対照表にする。変わったかどうかは条の本文を機械で比べて決めるので、変わっていない条を「変わった」と書く誤り、その逆は通らない。原本は変えない。",
+  "bases": ["docs"],
+  "report": ".blueprint/compare-report.md"
+}

package/blueprints/compare/presets/itaku-kaitei/kyu.txt

@@ -0,0 +1,31 @@
+業務委託契約書
+
+株式会社みなと（以下「甲」という。）と株式会社そよかぜ（以下「乙」という。）は、次のとおり業務委託契約を結ぶ。
+
+第1条（目的）
+甲は、第2条に定める業務を乙に委託し、乙はこれを受託する。
+
+第2条（委託業務）
+乙は、次の業務を行う。
+一　甲の会員向けウェブサイトの保守
+二　月に一度の利用状況の報告
+三　前二号に付随する業務
+
+第3条（定義）
+この契約において「成果物」とは、乙が委託業務として作成し甲に納める報告書をいう。
+
+第4条（委託料と支払）
+甲は、乙に対し、委託料として月額200,000円を支払う。
+２　甲は、乙が第12条に定める報告書を納めた月の翌月末日までに、前項の委託料を支払う。
+
+第6条（検収）
+甲は、成果物を受け取った日から10日以内に検収を行う。甲は、検収に合格した成果物について、検収の日から60日以内に委託料を支払う。
+
+第7条（再委託）
+乙は、甲の書面による承諾なく、委託業務を第三者に委託してはならない。
+
+第8条（成果物の扱い）
+この契約において「成果物」とは、乙が作成したプログラム、文書その他一切のものをいう。成果物の著作権は、委託料の支払いが済んだときに乙から甲に移る。
+
+第9条（契約期間）
+この契約の期間は、2026年10月1日から2027年9月30日までとする。

package/blueprints/compare/presets/itaku-kaitei/shin.txt

@@ -0,0 +1,31 @@
+業務委託契約書
+
+株式会社みなと（以下「甲」という。）と株式会社そよかぜ（以下「乙」という。）は、次のとおり業務委託契約を結ぶ。
+
+第1条（目的）
+甲は、第2条に定める業務を乙に委託し、乙はこれを受託する。
+
+第2条（委託業務）
+乙は、次の業務を行う。
+一　甲の会員向けウェブサイトの保守
+二　月に二度の利用状況の報告
+三　前二号に付随する業務
+
+第3条（定義）
+この契約において「成果物」とは、乙が委託業務として作成し甲に納める報告書をいう。
+
+第4条（委託料と支払）
+甲は、乙に対し、委託料として月額220,000円を支払う。
+２　甲は、乙が第12条に定める報告書を納めた月の翌月末日までに、前項の委託料を支払う。
+
+第5条（報告）
+乙は、毎月5日までに、前月の利用状況をまとめた報告書を甲に納める。
+
+第6条（検収）
+甲は、成果物を受け取った日から10日以内に検収を行う。甲は、検収に合格した成果物について、検収の日から60日以内に委託料を支払う。
+
+第7条（再委託）
+乙は、甲の書面による承諾なく、委託業務を第三者に委託してはならない。
+
+第8条（契約期間）
+この契約の期間は、2026年10月1日から2027年9月30日までとする。

package/blueprints/compare/presets.json

@@ -0,0 +1,11 @@
+{
+  "presets": [
+    {
+      "id": "itaku-kaitei",
+      "title": "業務委託契約書の改定を比べる",
+      "description": "見本の業務委託契約書の旧版（kyu.txt）と改定版（shin.txt）を条ごとに対応づけ、委託料や報告の回数が変わったこと、報告の条が足され、成果物の条が消えて契約期間の条が繰り上がったことを新旧対照表にする。原本は変えない。",
+      "base": "docs",
+      "answers": { "old": "kyu.txt", "new": "shin.txt", "focus": "" }
+    }
+  ]
+}

package/blueprints/compare/skills/pair/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: blueprint-compare-pair
+description: "Pair every article of the old version with its article in the new one, and say whether each changed, was added or was removed — writing .blueprint/comparison.json and changing no document."
+---
+
+# Pair the articles of the two versions
+
+`.blueprint/answers.json` names the old version (`old`), the new version (`new`) — one file each — and what the
+person wants looked at first (`focus`, may be empty). Read both in full. The person may not be an engineer: say
+what you do in plain words.
+
+Change nothing in the repository: neither version is touched. Write only under `.blueprint/`.
+
+## Find the articles
+
+Run `sh <base pack>/checks/chaff.sh tree <file> --format json` on each version. Every node whose `kind` is
+`article` is one article; its `address` (`"4"`) is how you name it below, and `attrs.label` (`第4条`,
+`Article 4`) is how the person reads it. The check uses the same tree, so an article chaff does not read as one
+is not yours to pair.
+
+## Pair them
+
+For each article of the old version, find the article of the new version that carries the same provision — by
+what it says, not by its number: a provision that moved or was renumbered (old 第9条 is new 第8条) is one pair.
+Then write `.blueprint/comparison.json`:
+
+```json
+{ "rows": [
+  { "old": "1", "new": "1", "change": "same" },
+  { "old": "4", "new": "4", "change": "changed", "what": "委託料が月額200,000円から220,000円になった" },
+  { "old": null, "new": "5", "change": "added", "what": "毎月5日までの報告の条が足された" },
+  { "old": "8", "new": null, "change": "removed", "what": "成果物の扱いの条が消えた" },
+  { "old": "9", "new": "8", "change": "same" }
+] }
+```
+
+- `same` / `changed` — both `old` and `new`. `changed` needs `what`: one line, in the person's language, saying
+  what is different, with the words or numbers from both versions. A change in a paragraph or an item is a change
+  to the article that holds it.
+- `added` — only `new`; `removed` — only `old`. A `what` saying what the article is about helps the person.
+- Every article of each version appears in exactly one row.
+
+Whether a pair is `same` or `changed` is not a judgement: the check compares the two articles' text (spacing
+aside, and leaving out the article's own number) and refuses a `same` whose text differs and a `changed` whose
+text does not. When you pair two articles that the check calls different but you think the change is trivial
+(punctuation, a character's width), it is still `changed`: say so in `what`.
+
+## Done when
+
+`node <usecase pack>/checks/comparison.mjs` (with `BLUEPRINT_BASE` and `BLUEPRINT_USECASE` set to the pack folders
+from your prompt) passes. It writes `.blueprint/comparison.txt`, the pairing a person reads before the table.

package/blueprints/compare/skills/report/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: blueprint-compare-report
+description: "Write the comparison table of the two versions from the checked pairing, and what was checked."
+---
+
+# The comparison table
+
+`.blueprint/comparison.json` is the pairing the person approved. Write `.blueprint/compare-report.md` for them,
+in their language and in plain words:
+
+- `## 新旧対照表` / `## Comparison table` — one row per pair that is not `same`, in the order of the new version
+  (a removed article where it stood in the old one): the old article, the new article, and what changed. Name
+  each article as the document does (`第4条`, `Article 4`), and quote the words or numbers that differ from each
+  version. A Markdown table works well:
+
+  | 旧 | 新 | 変わったこと |
+  |---|---|---|
+  | 第4条（委託料と支払） | 第4条（委託料と支払） | 月額「200,000円」→「220,000円」 |
+  | （なし） | 第5条（報告） | 足された: 毎月5日までに前月の報告書を納める |
+
+  The check looks for every changed, added and removed article's name in this section.
+- A line after the table on the articles that are the same, including those that only moved or were renumbered
+  (「旧第9条は新第8条になった。中身は同じ」).
+- `## 確かめたこと` / `## What was checked` — that every article of both versions is in one pair; that whether each
+  pair changed was decided by comparing the text by machine, not by reading; that neither document was changed.
+  Say what was not checked: a change's effect on other articles that refer to it (a renumbered article that other
+  articles still cite by its old number), and anything outside the articles (the title, the preamble).
+
+When `focus` names something, put the pairs that touch it first under the table's heading, and say so.
+
+## Done when
+
+`node <usecase pack>/checks/report.mjs` (with `BLUEPRINT_BASE` and `BLUEPRINT_USECASE` set) passes.

package/blueprints/compare/steps.json

@@ -0,0 +1,20 @@
+{
+  "steps": [
+    {
+      "id": "pair",
+      "title": "旧版と新版の条を対応づける",
+      "description": "旧版のどの条が新版のどの条になったかを一組ずつ書き、変わった・足された・消えたを付ける。変わったかどうかは条の本文を機械で比べて確かめる。",
+      "skill": "skills/pair",
+      "check": "node \"$BLUEPRINT_USECASE/checks/comparison.mjs\""
+    },
+    {
+      "id": "report",
+      "title": "新旧対照表をつくる",
+      "description": "対応づけを確かめてから、変わった条・足された条・消えた条を新旧対照表にする。",
+      "skill": "skills/report",
+      "check": "node \"$BLUEPRINT_USECASE/checks/report.mjs\"",
+      "gates": ["review"],
+      "reads": [".blueprint/comparison.txt"]
+    }
+  ]
+}

package/blueprints/docs/checks/markdown.d.mts

@@ -0,0 +1,9 @@
+// Types for markdown.mjs, which the packs run with plain node and the specs import.
+export type Section = { readonly heading: string; readonly hasBody: boolean };
+export type Skeleton = { readonly headings: string[]; readonly code: string[]; readonly links: string[] };
+
+export declare const sectionsOf: (markdown: string) => Section[];
+export declare const missingSections: (markdown: string, wanted: readonly (readonly string[])[]) => string[];
+export declare const skeletonOf: (markdown: string) => Skeleton;
+export declare const skeletonChanges: (before: string, after: string) => string[];
+export declare const sectionText: (markdown: string, names: readonly string[]) => string;

package/blueprints/docs/checks/markdown.mjs

@@ -82,3 +82,19 @@ export const skeletonChanges = (before, after) => {
     ...(differs(was.links, now.links) ? ["link targets"] : []),
   ];
 };
+
+const headingLevel = (line) => /^(#{1,6}) /u.exec(line)?.[1].length ?? 0;
+
+/**
+ * The text under the first `##` or `###` heading starting with one of `names` (the depths a report's sections may
+ * have), up to the next heading at the same depth or above. Empty when there is none.
+ */
+export const sectionText = (markdown, names) => {
+  const lines = String(markdown).split("\n");
+  const start = lines.findIndex((line) => [2, 3].includes(headingLevel(line)) && names.some((name) => line.replace(/^#+ /u, "").trim().startsWith(name)));
+  if (start < 0) return "";
+  const depth = headingLevel(lines[start] ?? "");
+  const rest = lines.slice(start + 1);
+  const end = rest.findIndex((line) => headingLevel(line) > 0 && headingLevel(line) <= depth);
+  return rest.slice(0, end < 0 ? rest.length : end).join("\n");
+};

package/blueprints/from-collection/skills/acceptance/SKILL.md

@@ -10,6 +10,9 @@ The spec numbers the must-haves. For EACH one:
 1. Write a test in `test/acceptance.test.ts` named after it (`must-have 1: …`) that walks the real flow through the
    API on a temporary database — create what it needs, do the action, and read back the result the user would see.
 2. If a must-have does not work yet, make it work — this step is where gaps between the spec and the app close.
+   When that means building one of the source's actions and `.blueprint/actions.json` decides it `feature`, build it as
+   its entry says; the actions step then finds it done. If the entry decides `manual` or `drop`, the spec contradicts
+   itself: ask through the blueprint question tool which one holds, and stop.
 3. If a must-have cannot be tested through the API (it is purely visual), test the screen instead and say so in a
    comment on the test.
 

package/blueprints/from-collection/skills/acceptance-cloudflare/SKILL.md

@@ -12,6 +12,9 @@ The spec numbers the must-haves. For EACH one:
    would see.
 2. If the must-have is limited to some people (signed in, an owner), the same action by someone else is refused.
 3. If a must-have does not work yet, make it work — this step is where gaps between the spec and the app close.
+   When that means building one of the source's actions and `.blueprint/actions.json` decides it `feature`, build it as
+   its entry says; the actions step then finds it done. If the entry decides `manual` or `drop`, the spec contradicts
+   itself: ask through the blueprint question tool which one holds, and stop.
 4. If a must-have cannot be tested through the API (it is purely visual), test the screen instead and say so in a
    comment on the test.
 

package/blueprints/from-collection/skills/acceptance-firebase/SKILL.md

@@ -13,6 +13,9 @@ The spec numbers the must-haves. For EACH one, in `test/blueprint/acceptance.spe
 2. Then the refusal: the same action by someone who must not be able to do it (another user, a signed-out
    visitor) is refused by the rules.
 3. If a must-have does not work yet, make it work — this step is where gaps between the spec and the app close.
+   When that means building one of the source's actions and `.blueprint/actions.json` decides it `feature`, build it as
+   its entry says; the actions step then finds it done. If the entry decides `manual` or `drop`, the spec contradicts
+   itself: ask through the blueprint question tool which one holds, and stop.
 
 Do not add features that are not must-haves.
 

package/blueprints/from-collection/skills/acceptance-supabase/SKILL.md

@@ -14,6 +14,9 @@ The spec numbers the must-haves. For EACH one, in `test/acceptance.test.ts`, nam
 2. Then the refusal: the same action by someone who must not be able to do it (another signed-in user, a signed-out
    visitor) is refused by the database — a `42501`, or a read that comes back empty.
 3. If a must-have does not work yet, make it work — this step is where gaps between the spec and the app close.
+   When that means building one of the source's actions and `.blueprint/actions.json` decides it `feature`, build it as
+   its entry says; the actions step then finds it done. If the entry decides `manual` or `drop`, the spec contradicts
+   itself: ask through the blueprint question tool which one holds, and stop.
 4. If a must-have is purely visual, test the screen instead and say so in a comment on the test.
 
 Do not add features that are not must-haves.