mulmoterminal 8.0.0 → 8.2.0

package/blueprints/adopt/manifest.json

@@ -3,7 +3,21 @@
   "kind": "usecase",
   "title": "文書のフォルダに chaff を入れる（今ある指摘は棚に上げて）",
   "version": "0.1.0",
+  "order": 100,
   "description": "既にある文書のフォルダに chaff を入れる。文書の種類に合わせた chaff.yaml を置き、今ある指摘は chaff baseline で棚に上げて、新しい指摘だけが出るようにする。望めば、GitHub の PR の行に指摘が出るワークフローも作る。原本は変えない。",
   "bases": ["docs"],
-  "report": ".blueprint/adopt-report.md"
+  "report": ".blueprint/adopt-report.md",
+  "next": [
+    {
+      "usecase": "polish",
+      "answers": {
+        "style": "このフォルダの規約（STYLE.md と chaff.yaml）",
+        "scope": "chaff が指摘した所だけ",
+        "shelved": "棚上げした指摘も直す"
+      },
+      "carry": {
+        "targets": "places"
+      }
+    }
+  ]
 }

package/blueprints/adopt/templates/chaff.yml

@@ -21,7 +21,7 @@ jobs:
       - uses: actions/setup-node@v7
         with:
           node-version: 24
-      - run: npx -y chaffjs@0.16 {{PATHS}} --sarif chaff.sarif
+      - run: npx -y chaffjs@0.18 {{PATHS}} --sarif chaff.sarif
         continue-on-error: true
       - uses: github/codeql-action/upload-sarif@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4.38.1
         with:

package/blueprints/ask/manifest.json

@@ -3,6 +3,7 @@
   "kind": "usecase",
   "title": "文書に尋ねる（どこに書いてあるかを添えて）",
   "version": "0.1.0",
+  "order": 40,
   "description": "込み入ったマニュアル・規程・契約書に質問すると、文書のどこに書いてあるかを原文の引用で示して答える。書いていないことは「書いていない」と答える。引用は chaff cite で原文にあることを確かめる。答えは、人が読んでから FAQ.md に残せる。",
   "bases": ["docs"],
   "report": ".blueprint/replies.md"

package/blueprints/ask/presets/kyuka/kitei.md

@@ -0,0 +1,17 @@
+# 休暇規程
+
+## 第1条（目的）
+
+この規程は、社員の年次有給休暇の取り方を定める。
+
+## 第2条（日数）
+
+年次有給休暇は、入社から6か月たった社員に10日を与え、その後は1年ごとに定める日数を与える。
+
+## 第3条（申請）
+
+年次有給休暇を取る社員は、休む日の3日前までに、所属長に申請しなければならない。
+
+## 第4条（繰り越し）
+
+使わなかった年次有給休暇は、次の1年に限り繰り越すことができる。

package/blueprints/ask/presets/kyuka/tebiki.md

@@ -0,0 +1,13 @@
+# 休暇の取り方の手引き
+
+## 申請のしかた
+
+勤怠システムの「休暇申請」から、休む日を選んで送ります。休む日の前日までに送れば間に合います。
+
+## 半日だけ休むとき
+
+午前だけ、または午後だけ休むこともできます。申請の画面で「午前半休」か「午後半休」を選んでください。半日の休みは、年次有給休暇の0.5日として数えます。
+
+## 急に休むとき
+
+当日に体調をくずしたときは、始業の時刻までに所属長へ電話で連絡し、出社した日に申請を送ってください。

package/blueprints/ask/presets.json

@@ -10,6 +10,17 @@
         "questions": "申請の期限はいつまで？\n領収書をなくしたときはどうする？\n海外出張の日当はいくら？",
         "keep": "このフォルダの FAQ.md に書き足す"
       }
+    },
+    {
+      "id": "kyuka",
+      "title": "休暇の規程と手引きに尋ねる",
+      "description": "見本の休暇規程（kitei.md）と手引き（tebiki.md）に 3 つの質問をする。申請の期限は規程と手引きで違うので、両方を引用して食い違いを示す。半日の休みは手引きの引用で答え、どちらにも無い夏季休暇には「書いていない」と答える。答えはフォルダに残さない。",
+      "base": "docs",
+      "answers": {
+        "documents": "kitei.md\ntebiki.md",
+        "questions": "有給休暇は何日前までに申請すればいい？\n半日だけ休める？\n夏季休暇は何日ある？",
+        "keep": "残さない（.blueprint の中だけ）"
+      }
     }
   ]
 }

package/blueprints/compare/manifest.json

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

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

@@ -0,0 +1,22 @@
+出張旅費規程
+
+第1条（目的）
+この規程は、社員が業務のために出張するときの旅費の支給について定める。
+
+第2条（出張の命令）
+出張は、所属長の命令によって行う。
+
+第3条（交通費）
+交通費は、最も経済的な通常の経路と方法によって計算した実費を支給する。
+
+第4条（日当）
+日当は、出張一日につき2,000円を支給する。
+
+第5条（宿泊費）
+宿泊費は、一泊につき9,000円を上限として実費を支給する。
+
+第6条（回数券の購入）
+同じ区間を月に四度以上往復するときは、回数券を購入しなければならない。
+
+第7条（精算）
+出張から戻った者は、戻った日から14日以内に、第3条から第5条までの旅費を精算しなければならない。

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

@@ -0,0 +1,22 @@
+出張旅費規程
+
+第1条（目的）
+この規程は、社員が業務のために出張するときの旅費の支給について定める。
+
+第2条（出張の命令）
+出張は、所属長の命令によって行う。ただし、オンライン会議で目的を果たせるときは、出張を命じない。
+
+第3条（交通費）
+交通費は、最も経済的な通常の経路と方法によって計算した実費を支給する。
+
+第4条（日当）
+日当は、出張一日につき2,500円を支給する。
+
+第5条（宿泊費）
+宿泊費は、一泊につき12,000円を上限として実費を支給する。
+
+第6条（精算）
+出張から戻った者は、戻った日から10日以内に、第3条から第5条までの旅費を精算しなければならない。
+
+第7条（施行）
+この規程は、2027年4月1日から施行する。

package/blueprints/compare/presets.json

@@ -5,7 +5,22 @@
       "title": "業務委託契約書の改定を比べる",
       "description": "見本の業務委託契約書の旧版（kyu.txt）と改定版（shin.txt）を条ごとに対応づけ、委託料や報告の回数が変わったこと、報告の条が足され、成果物の条が消えて契約期間の条が繰り上がったことを新旧対照表にする。原本は変えない。",
       "base": "docs",
-      "answers": { "old": "kyu.txt", "new": "shin.txt", "focus": "" }
+      "answers": {
+        "old": "kyu.txt",
+        "new": "shin.txt",
+        "focus": ""
+      }
+    },
+    {
+      "id": "ryohi-kaitei",
+      "title": "出張旅費規程の改定を比べる",
+      "description": "見本の出張旅費規程の旧版（kyu.txt）と改定版（shin.txt）を条ごとに対応づけ、日当と宿泊費の上限が上がったこと、出張を命じない場合がただし書きで足されたこと、回数券の条が消えて精算の条が繰り上がり期限が短くなったこと、施行の条が足されたことを新旧対照表にする。原本は変えない。",
+      "base": "docs",
+      "answers": {
+        "old": "kyu.txt",
+        "new": "shin.txt",
+        "focus": ""
+      }
     }
   ]
 }

package/blueprints/docs/checks/chaff.sh

@@ -4,4 +4,4 @@
 if [ -n "${CHAFF_BIN:-}" ]; then
   exec sh -c "$CHAFF_BIN \"\$@\"" chaff "$@"
 fi
-exec npx -y chaffjs@0.16 "$@"
+exec npx -y chaffjs@0.18 "$@"

package/blueprints/docs/skills/workspace/SKILL.md

@@ -12,7 +12,7 @@ repository, `.git/info/exclude`) until the person has approved the models.
 1. `.blueprint/` already exists (the build created it). Everything this build records goes there.
 2. Run chaff once through the base pack's wrapper, so its first download happens now and not in the
    middle of a later step: `sh <base pack>/checks/chaff.sh rules --json > /dev/null`. The wrapper runs the
-   pinned chaff (`npx -y chaffjs@0.16`) unless `CHAFF_BIN` names another. If it fails, show the person the
+   pinned chaff (`npx -y chaffjs@0.18`) unless `CHAFF_BIN` names another. If it fails, show the person the
    error and stop — do not work around it.
 3. If the folder is a git repository, add `.blueprint/` to `.git/info/exclude`. That keeps the build's
    working files out of commits without touching `.gitignore`, which belongs to the person.

package/blueprints/from-collection/checks/actions.sh

@@ -44,7 +44,16 @@ const problems = entries.flatMap(({ name, decision }) => {
   if (decision === "manual" && !inHeading(name)) return [`${name} is left to a person, and README.md has no heading naming it`];
   return [];
 });
-if (problems.length > 0) { console.error(problems.join("\n")); process.exit(1); }
+// Said with the titles it read and the rule it reads them by, so the one fixing it sees what is missing rather than guessing.
+const untested = entries.some(({ name, decision }) => decision === "feature" && !inTestTitle(name));
+const hint = untested
+  ? [
+      "",
+      `The test titles ${tests} declares, as this check reads them: ${titles.length === 0 ? "(none)" : titles.map((title) => JSON.stringify(title)).join(", ")}.`,
+      "Only the title of a test counts: the first argument, written as a plain string, of it(...) or test(...) imported from \"vitest\" in that file. A describe(...) name does not count, so put the whole name in each test title.",
+    ]
+  : [];
+if (problems.length > 0) { console.error([...problems, ...hint].join("\n")); process.exit(1); }
 process.stdout.write(String(entries.filter((entry) => entry.decision === "feature").length));
 ' "$file" "$tests" "$titles")
 [ "$features" -gt 0 ] || exit 0

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

@@ -27,7 +27,8 @@ check it against its entry and give it its test here instead of building it a se
 
 Tests in `test/actions.test.ts`, one per `feature`, each with the entry's `name` in the title of its `it(…)` / `test(…)`
 (`it("books.actions.tidy: summarises", …)`) — with `it` / `test` imported from `vitest` in that file (`import { it } from "vitest"`); the check reads titles only from
-calls to those imports, so a global `it`, a helper of the same name, a comment or a title built at run time does not count:
+calls to those imports, so a global `it`, a helper of the same name, a comment or a title built at run time does not count, and neither does a `describe(…)` name (`it("tidy")` inside
+`describe("books.actions")` is not titled `books.actions.tidy`: write the whole name in every test's own title):
 walk the real flow against a temporary database and read back what changed. Never call the network in a test: a model
 call goes through a client the test replaces with a stand-in, and an ingest reads a fixture file kept under
 `test/fixtures/`. The tests must pass with no API key set.

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

@@ -31,7 +31,8 @@ check it against its entry and give it its test here instead of building it a se
 
 Tests in `test/actions.test.ts`, one per `feature`, each with the entry's `name` in the title of its `it(…)` / `test(…)`
 (`it("books.actions.tidy: summarises", …)`) — with `it` / `test` imported from `vitest` in that file (`import { it } from "vitest"`); the check reads titles only from
-calls to those imports, so a global `it`, a helper of the same name, a comment or a title built at run time does not count:
+calls to those imports, so a global `it`, a helper of the same name, a comment or a title built at run time does not count, and neither does a `describe(…)` name (`it("tidy")` inside
+`describe("books.actions")` is not titled `books.actions.tidy`: write the whole name in every test's own title):
 walk the real flow through the Worker on the test D1 and read back what changed. Never call the network in a test: a
 model call goes through a client the test replaces with a stand-in, and an ingest job takes the fetch it uses as an
 argument, so the test hands it a fixture instead. The tests must pass with no API key set.

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

@@ -27,7 +27,8 @@ check it against its entry and give it its test here instead of building it a se
 
 Tests in `test/blueprint/actions.spec.ts`, one per `feature`, each with the entry's `name` in the title of its `it(…)` /
 `test(…)` (`it("books.actions.tidy: summarises", …)`) — with `it` / `test` imported from `vitest` in that file (`import { it } from "vitest"`); the check reads titles only from
-calls to those imports, so a global `it`, a helper of the same name, a comment or a title built at run time does not count —
+calls to those imports, so a global `it`, a helper of the same name, a comment or a title built at run time does not count, and neither does a `describe(…)` name (`it("tidy")` inside
+`describe("books.actions")` is not titled `books.actions.tidy`: write the whole name in every test's own title) —
 against the emulators: do the action as a signed-in user and read back what changed, and check that someone who must not
 do it is refused. Never call the network in a test: the model call and the fetch go through clients the test replaces
 with stand-ins.

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

@@ -30,7 +30,8 @@ check it against its entry and give it its test here instead of building it a se
 
 Tests in `test/actions.test.ts`, one per `feature`, each with the entry's `name` in the title of its `it(…)` / `test(…)`
 (`it("books.actions.tidy: summarises", …)`) — with `it` / `test` imported from `vitest` in that file (`import { it } from "vitest"`); the check reads titles only from
-calls to those imports, so a global `it`, a helper of the same name, a comment or a title built at run time does not count:
+calls to those imports, so a global `it`, a helper of the same name, a comment or a title built at run time does not count, and neither does a `describe(…)` name (`it("tidy")` inside
+`describe("books.actions")` is not titled `books.actions.tidy`: write the whole name in every test's own title):
 walk the real flow against the local stack and read back what changed. Never call the network in a test: a model call
 goes through a client the test replaces with a stand-in, and an ingest job takes the fetch it uses as an argument, so
 the test hands it a fixture instead. The tests must pass with no API key set.

package/blueprints/glossary/manifest.json

@@ -3,7 +3,20 @@
   "kind": "usecase",
   "title": "用語をそろえる（用語集をつくって chaff に入れる）",
   "version": "0.1.0",
+  "order": 90,
   "description": "文書から、定義された語と、同じ語の二重定義や表記ゆれを集めて用語集にする。定義と書き方にはすべて原文の引用を付け、文書が定義する語を落としていないことを機械で確かめる。望めば、使う書き方と社内の言葉をフォルダの chaff.yaml に入れ、以後は chaff が揺れを指摘する。原本は変えない。",
   "bases": ["docs"],
-  "report": ".blueprint/glossary-report.md"
+  "report": ".blueprint/glossary-report.md",
+  "next": [
+    {
+      "usecase": "polish",
+      "answers": {
+        "style": "このフォルダの規約（STYLE.md と chaff.yaml）",
+        "scope": "chaff が指摘した所だけ"
+      },
+      "carry": {
+        "targets": "documents"
+      }
+    }
+  ]
 }

package/blueprints/glossary/skills/apply/SKILL.md

@@ -25,6 +25,18 @@ rules:
 - One `prefer` line for every spelling of a term other than its `preferred`.
 - `jargon` lists every term marked `jargon: true`.
 - `preferred-term` is experimental: it runs only when named under `rules`.
+- **Creating the file for documents of different kinds** (a policy and its guide), give each kind its genre: the
+  kind most documents are goes in `genre`, and each other document gets its own under `by_path`, so a guide is not
+  measured as a policy:
+
+  ```yaml
+  genre: legal/statute
+  by_path:
+    - files: ["tebiki.md"]
+      genre: docs/manual
+  ```
+
+  `files` are globs relative to `chaff.yaml`. An existing file's `genre` and `by_path` are the person's: keep them.
 - **Keep everything the file already had.** Add to its `prefer`, `jargon` and `rules` rather than replacing them;
   the check refuses a line of the old file that is gone.
 

package/blueprints/polish/checks/kind.d.mts

@@ -2,6 +2,10 @@
 export type Kind = { readonly option: string; readonly genre: string | null };
 
 export declare const CHAFF_DEFAULT_STYLE: string;
+export declare const FOLDER_STYLE: string;
+export declare const FIX_SHELVED: string;
+export declare const shelvedArgs: (answers: unknown) => string[];
+export declare const measureArgs: () => string[];
 export declare const genreOf: (answers: unknown, kinds: readonly Kind[]) => string | null;
 export declare const genreArgs: (genre: string | null) => string[];
 export declare const readKinds: (usecaseDir: string) => Kind[];

package/blueprints/polish/checks/kind.mjs

@@ -4,6 +4,8 @@ import { existsSync, readFileSync } from "node:fs";
 import { join } from "node:path";
 
 export const CHAFF_DEFAULT_STYLE = "chaff の既定のまま";
+export const FOLDER_STYLE = "このフォルダの規約（STYLE.md と chaff.yaml）";
+export const FIX_SHELVED = "棚上げした指摘も直す";
 
 /** The genre for the answers' `kind`, from `kinds` ({ option, genre }[]); null when none applies. */
 export const genreOf = (answers, kinds) => {
@@ -20,8 +22,22 @@ const ANSWERS = ".blueprint/answers.json";
 /** The kinds in the pack at `usecaseDir`. */
 export const readKinds = (usecaseDir) => JSON.parse(readFileSync(join(usecaseDir, "kinds.json"), "utf8")).kinds;
 
+/**
+ * The arguments that show the findings the folder's baseline shelved, when the person asked to fix those too. Only
+ * with the folder's style: the baseline is the folder's, and chaff's own style has none to show.
+ */
+export const shelvedArgs = (answers) => (answers?.style === FOLDER_STYLE && answers?.shelved === FIX_SHELVED ? ["--show-baseline"] : []);
+
+const readAnswers = () => (existsSync(ANSWERS) ? JSON.parse(readFileSync(ANSWERS, "utf8")) : null);
+
 /** This build's genre, from the folder's answers (BLUEPRINT_USECASE is the pack); null when its kind has none. */
-export const kindGenre = () => (existsSync(ANSWERS) ? genreOf(JSON.parse(readFileSync(ANSWERS, "utf8")), readKinds(process.env.BLUEPRINT_USECASE)) : null);
+export const kindGenre = () => {
+  const answers = readAnswers();
+  return answers === null ? null : genreOf(answers, readKinds(process.env.BLUEPRINT_USECASE));
+};
 
 /** The arguments every chaff run of this build takes for its kind. */
 export const kindArgs = () => genreArgs(kindGenre());
+
+/** The arguments every chaff run that measures this build's documents takes: its kind, and the shelved findings when asked. */
+export const measureArgs = () => [...kindArgs(), ...shelvedArgs(readAnswers())];

package/blueprints/polish/checks/targets.mjs

@@ -14,7 +14,7 @@ import { existsSync, lstatSync, readFileSync, readdirSync, rmSync, writeFileSync
 import { isAbsolute, join, normalize } from "node:path";
 import { fromBase } from "./base.mjs";
 import { targetsText } from "./targetsView.mjs";
-import { genreArgs, kindGenre } from "./kind.mjs";
+import { kindGenre, measureArgs } from "./kind.mjs";
 import { readCatalog, readRecord, viewpointProblems, viewpointsFor } from "./viewpoints.mjs";
 import { insidePath, namedTextFiles, TEXT_FILE } from "./named.mjs";
 const { actionable, fail, findingsIn, readJson, runChaff } = await import(fromBase("chaff.mjs"));
@@ -60,14 +60,15 @@ const readList = () => {
   return { targets: list.targets, avoided: list.avoided ?? [] };
 };
 
-// The kind of document the person named decides chaff's genre, when the style is chaff's own.
+// The kind of document the person named decides chaff's genre, when the style is chaff's own; with the folder's
+// style, the person may ask for the findings its baseline shelved as well.
 const genre = kindGenre();
-const byKind = genreArgs(genre);
+const measuring = measureArgs();
 // The kind's viewpoints: what a polished file is read for beyond chaff's findings.
 const catalog = readCatalog(process.env.BLUEPRINT_USECASE);
 const viewpointIds = viewpointsFor(catalog, genre);
 
-const findingsNow = (file) => findingsIn(file, byKind).filter(actionable).length;
+const findingsNow = (file) => findingsIn(file, measuring).filter(actionable).length;
 
 /** The addresses of chaff's tree (articles, sections, items) — what a reference to this document points at. */
 const addressesOf = (file) => {
@@ -86,7 +87,7 @@ const polishedProblems = (target) => {
   const [wasTree, nowTree] = [addressesOf(original), addressesOf(target.file)];
   const treeChanged = JSON.stringify(wasTree) === JSON.stringify(nowTree) ? [] : [`${target.file}: the addresses in chaff's tree changed`];
   // A finding set aside with a reason (dismissals.mjs) does not count; one that no longer exists is a stale dismissal.
-  const reported = findingsIn(target.file, byKind).filter(actionable);
+  const reported = findingsIn(target.file, measuring).filter(actionable);
   const dismissals = dismissalProblems(target.file, target.dismissed, reported);
   const left = withoutDismissed(reported, target.dismissed).length;
   const findings = left === 0 ? [] : [`${target.file}: ${left} chaff finding(s) remain under the style`];

package/blueprints/polish/hearing.json

@@ -14,7 +14,9 @@
       "why": "このフォルダに「規約をつくる」で作った STYLE.md と chaff.yaml があれば、それに合わせる",
       "kind": "select",
       "options": ["このフォルダの規約（STYLE.md と chaff.yaml）", "chaff の既定のまま"],
-      "needsPath": { "このフォルダの規約（STYLE.md と chaff.yaml）": "chaff.yaml" }
+      "needsPath": {
+        "このフォルダの規約（STYLE.md と chaff.yaml）": "chaff.yaml"
+      }
     },
     {
       "id": "kind",
@@ -49,7 +51,24 @@
       "why": "機械が見つけた所だけか、手引きの決まり（語調・表記など）にも合わせるか",
       "kind": "select",
       "options": ["chaff が指摘した所だけ", "手引き（STYLE.md）の決まりにも合わせる"],
-      "needsPath": { "手引き（STYLE.md）の決まりにも合わせる": "STYLE.md" },
+      "needsPath": {
+        "手引き（STYLE.md）の決まりにも合わせる": "STYLE.md"
+      },
+      "showIf": {
+        "id": "style",
+        "equals": "このフォルダの規約（STYLE.md と chaff.yaml）"
+      }
+    },
+    {
+      "id": "shelved",
+      "label": "棚上げした指摘も直しますか",
+      "why": "「既存の文書に chaff を入れる」で棚上げした指摘は、ふだん chaff が黙っている。直すと、残りが少しずつ減る",
+      "kind": "select",
+      "options": ["新しい指摘だけ", "棚上げした指摘も直す"],
+      "default": "新しい指摘だけ",
+      "needsPath": {
+        "棚上げした指摘も直す": ".chaff-baseline.json"
+      },
       "showIf": {
         "id": "style",
         "equals": "このフォルダの規約（STYLE.md と chaff.yaml）"

package/blueprints/polish/manifest.json

@@ -3,6 +3,7 @@
   "kind": "usecase",
   "title": "文書を整える（書いてあることは変えずに）",
   "version": "0.1.0",
+  "order": 10,
   "description": "リポジトリやフォルダにある既存の文書を、規約（STYLE.md と chaff.yaml）に合わせて一つずつ整える。書いてあることは変えない: 見出し、条や節の番地、コードブロック、リンク先が変わっていないことを機械で確かめ、直す前の原本を残す。",
   "bases": ["docs"],
   "report": ".blueprint/polish-report.md"

package/blueprints/polish/presets/english-blog/post.md

@@ -0,0 +1,19 @@
+# Speeding Up Our CI by Caching Dependencies
+
+In today's fast-paced world of software development, speed is more important than ever, and every team is looking for ways to ship faster.
+
+## The problem
+
+Our pull request checks took about 14 minutes. Almost 6 of those minutes went to installing the same dependencies on every run, even when the lockfile had not changed at all since the previous run on the same branch, which meant that most of that time was simply wasted work that the runner repeated again and again.
+
+## What we changed
+
+We added a cache step keyed on the hash of the lockfile. When the lockfile is unchanged, the runner restores the installed packages from the cache instead of downloading them.
+
+## The result
+
+The install step now takes about 40 seconds when the cache is warm, and the whole check finishes in about 9 minutes.
+
+## Conclusion
+
+In conclusion, caching is a powerful technique that can dramatically improve your workflow. I hope this was helpful!

package/blueprints/polish/presets/shayo/kitei.md

@@ -0,0 +1,26 @@
+# 社用車利用規程
+
+## 第1条（目的）
+
+社用車の事故は社員の命と会社の信用に関わるため、安全に使うことが非常に重要である。この規程は、会社が持つ自動車（以下「社用車」という。）を安全に使い、その費用を正しく管理するために、社用車の予約、利用、報告の手続きを定める。
+
+## 第2条（予約）
+
+社用車を使う者（以下「利用者」という。）は、使う日の前日までに、総務部の予約表に使う時間と行き先を書き入れなければならない。
+
+## 第3条（利用）
+
+1. 利用者は、社用車を業務のためだけに使い、私用で使ってはならない。
+2. 利用者は、運転の前に、運転免許証を持っていること、ガソリンが半分以上残っていること、車体に傷が無いことを確かめ、傷を見つけたときはその場で写真を撮って総務部に知らせたうえで、傷の場所と大きさを予約表の備考の欄に書いてから出発しなければならない。
+
+## 第4条（報告）
+
+利用者は、使い終わったあと、走った距離とガソリンを入れた量を総務部に報告しなければならない。
+
+## 第5条（鍵の管理）
+
+社用車の鍵は総務部が管理し、利用者は使い終わったら鍵を総務部の鍵箱に戻す。
+
+## 第6条（災害のとき）
+
+大きな災害が起きたときは、社員とその家族を助けるために、社用車を使うことができる。

package/blueprints/polish/presets.json

@@ -51,6 +51,32 @@
         "maxFiles": 1,
         "avoid": ""
       }
+    },
+    {
+      "id": "shayo",
+      "title": "規程を規程として整える",
+      "description": "見本の社内規程（kitei.md）を「規程・社内規則」として読む。中身の無い強調は、書いてあることは変えずに直す。誰に当てはまるか、義務に期限があるか、守らなかったときどうなるか、例外が決まりのそばにあるかを見て、書き足しが要るところは直さずに、書いた人への質問として報告に並べる。直す前の原本は残す。",
+      "base": "docs",
+      "answers": {
+        "targets": "kitei.md",
+        "style": "chaff の既定のまま",
+        "kind": "規程・社内規則",
+        "maxFiles": 1,
+        "avoid": ""
+      }
+    },
+    {
+      "id": "english-blog",
+      "title": "英語のブログ記事を整える",
+      "description": "見本の英語の技術ブログ（post.md）を「ブログ（技術記事）」として読む。文書は英語のまま、長すぎる文を分け、どの記事にも当てはまる書き出しや結びの決まり文句は削る。要約だけの結びなど、書き足しが要るところは直さずに、書いた人への質問として報告に並べる。報告は画面の言語で返る。直す前の原本は残す。",
+      "base": "docs",
+      "answers": {
+        "targets": "post.md",
+        "style": "chaff の既定のまま",
+        "kind": "ブログ（技術記事）",
+        "maxFiles": 1,
+        "avoid": ""
+      }
     }
   ]
 }

package/blueprints/polish/skills/polish/SKILL.md

@@ -33,7 +33,8 @@ Follow `STYLE.md` when the answer `scope` includes the guide; otherwise, and whe
 ## Check it
 
 `sh <base pack>/checks/chaff.sh <the file>` — with the same `--genre` as the survey when the answer `kind`
-gives one (see `<usecase pack>/kinds.json`) — must report no warning or error, except the ones you set aside.
+gives one (see `<usecase pack>/kinds.json`), and `--show-baseline` when the answer `shelved` asks for the shelved
+findings too — must report no warning or error, except the ones you set aside.
 Set a finding aside — never change the meaning to satisfy a rule — in one of two cases, by adding it to the
 file's entry in `.blueprint/polish.json`:
 

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

@@ -21,8 +21,16 @@ Write `.blueprint/polish-report.md` for the person, in their language and in pla
   line per dismissal with its rule, line number and `why`); files over the agreed number, for another
   run.
 
+When the answer `shelved` asked for the shelved findings too, say under `## 整えたもの` / `## What was polished`
+that the counts include them. Their entries stay in `.chaff-baseline.json`; a fixed sentence no longer matches one,
+so there is nothing to clean up.
+
+With the folder's style, the style is its `chaff.yaml`. `STYLE.md` belongs to the answer `scope` only, so when
+`scope` did not ask for the guide, a folder without `STYLE.md` lacks nothing: do not mention it.
+
 When `.blueprint/viewpoints.json` records a `writer` verdict for a polished file, add
-`## 書いた人に確かめてほしいこと` / `## For the writer`: one item per verdict, giving the file, what was read
+`## 書いた人に確かめてほしいこと` / `## For the writer` **right after** `## 整えたもの` / `## What was polished` — it is
+the part the person has to act on, so it comes before what was checked and what was left: one item per verdict, giving the file, what was read
 for (the viewpoint's `title` in `<usecase pack>/viewpoints.json`), the `quote` word for word, and the `note` as
 the question. The check looks for every quotation. Under `## 整えたもの` / `## What was polished`, name the
 viewpoints you fixed in the same way as the other changes.

package/blueprints/polish/skills/survey/SKILL.md

@@ -16,8 +16,12 @@ any file is touched.
 
 Run chaff through the base pack's wrapper, from the folder: `sh <base pack>/checks/chaff.sh <file>`
 (add `--compact` for one line per finding). The folder's `chaff.yaml` applies when the answer `style` is
-the folder's style; if it is and there is no `chaff.yaml`, stop and say the style has to be made first.
-With chaff's own style, the answer `kind` says what kind of document this is: measure it as that kind by
+the folder's style; if it is and there is no `chaff.yaml`, stop and say the style has to be made first. The
+folder's style is its `chaff.yaml`: `STYLE.md` is read only when `scope` asks to follow the guide, so when it
+does not, a folder without one lacks nothing, and the report does not say it does. When `scope` asks for the
+guide and there is no `STYLE.md`, stop and say the guide is missing.
+When the answer `shelved` is 「棚上げした指摘も直す」, add `--show-baseline` to every chaff run as well: the findings
+the folder's `.chaff-baseline.json` shelved are then measured and polished like any other. With chaff's own style, the answer `kind` says what kind of document this is: measure it as that kind by
 adding `--genre <genre>` to every chaff run, taking the genre for the answer from `<usecase pack>/kinds.json`
 (a kind whose genre is `null` adds nothing). The checks measure the same way, so a count taken without it
 will not match.

package/blueprints/polish/viewpoints.json

@@ -109,6 +109,21 @@
       "title": "うまくいったことの確かめ方があるか",
       "look": "The procedure says what the reader sees when it worked (a screen, a message, a result), at its end or after a step where it matters. Quote the last step when it does not; adding it is the writer's.",
       "fix": "writer"
+    },
+    "measurable-requirement": {
+      "title": "満たしたかどうかを確かめられる要件か",
+      "look": "Each requirement says something that can be checked: a number, a limit, a named behaviour. Words that cannot be measured (適切に, 速やかに, 十分な, 高速に, appropriately, promptly, sufficient, fast) leave the reader unable to tell whether it is met. Quote the requirement; the figure or the behaviour is the writer's to supply.",
+      "fix": "writer"
+    },
+    "failure-behaviour": {
+      "title": "失敗や不正な入力のときにどうなるかが書かれているか",
+      "look": "A function, an interface or an operation says what happens when it fails or is given something it cannot take: the message, the code, what is kept or undone. Quote the part that describes only the normal case; the failure behaviour is the writer's to decide.",
+      "fix": "writer"
+    },
+    "first-run": {
+      "title": "最初に動かすまでの手順があるか",
+      "look": "A reader who has just found the project can get it running from the document alone: how to install it and the first command to run, in order, with each command written out. Quote where the reader is left to guess; the missing step is the writer's to supply.",
+      "fix": "writer"
     }
   },
   "genres": {
@@ -122,6 +137,8 @@
     "blog/owned-media": ["padded-intro", "closing-cliche", "empty-conclusion", "title-body-alignment", "thin-section", "unqualified-superlative"],
     "docs/manual": ["prerequisites-stated", "steps-one-action", "result-check"],
     "legal/contract": ["duty-owner-deadline", "breach-consequence", "exception-with-rule"],
-    "legal/statute": ["scope-stated", "duty-owner-deadline", "breach-consequence", "exception-with-rule"]
+    "legal/statute": ["scope-stated", "duty-owner-deadline", "breach-consequence", "exception-with-rule"],
+    "technical/spec": ["measurable-requirement", "failure-behaviour"],
+    "technical/readme": ["prerequisites-stated", "first-run", "result-check"]
   }
 }

package/blueprints/review/manifest.json

@@ -3,6 +3,7 @@
   "kind": "usecase",
   "title": "文書を読み解く（矛盾と不備を見つけて直し方を出す）",
   "version": "0.1.0",
+  "order": 20,
   "description": "長い契約書・規程・仕様書を読み、存在しない条への参照、番号の抜け、同じ語の二重定義、義務や期限の食い違いを見つける。指摘には必ず番地と原文の引用を付け、引用が原文にあることを機械で確かめる。直し方は原本を変えずに別のファイルに書く。",
   "bases": ["docs"],
   "report": ".blueprint/review-report.md"