The pages say where a document's files come from

README.md

@@ -66,9 +66,10 @@ keys, the layout roles, the free shapes, the colour slots, the theme keys, the s
 exceptions, the themes that ship, the ceilings, the Word directives, the attributes each of the
 Word directives reads, the keys a Word document's frontmatter may carry, the options the reader of
 a Word document trusts, the features a Word format cannot carry, the Word options, the Word style
-slots and the inline style attributes — and reads the page that carries it for the names it lists.
-The two are compared in both directions: a name the code does not have is a page offering something
-that does not work, and a name the code has and the page does not is a feature nobody can find.
+slots, the inline style attributes, the methods of a finder and the roles a finder resolves a name
+in — and reads the page that carries it for the names it lists. The two are compared in both
+directions: a name the code does not have is a page offering something that does not work, and a
+name the code has and the page does not is a feature nobody can find.
 
 A vocabulary the two halves share is read out of both of them and held to one list, so the
 attributes an inline style takes are the same eight in the deck and in the document — and the
@@ -154,9 +155,10 @@ when the example itself contains a fenced block.
 
 The fence's tag says which way the example runs: the format it starts in, and the format it ends
 in. `md word` builds a Word document from Markdown, `md presentation` builds a deck, and
-`word md` reads a Word document back into Markdown. The body of the fence is the input — the
-Markdown for the first two, the path of the document for the last, relative to the site's own
-directory:
+`word md` reads a Word document back into Markdown. A third word — `finder` — says where the
+example's files come from: `md word finder` builds the document with its theme in a finder rather
+than in a directory. The body of the fence is the input — the Markdown for the first two, the path
+of the document for the last, relative to the site's own directory:
 
 ````markdown
 {% example "A Word document read back to Markdown" %}
@@ -225,15 +227,16 @@ GitHub serves a repository of that name at the root of the organisation's site,
 name under a path of its own. That is the same shape the site will have on its own domain, so
 the build does not change when the domain is pointed at GitHub — only the address does.
 
-The build checks its own links before it publishes:
+The build checks its own links, and the skill it publishes, before it publishes:
 
 ```bash
 npm run check:site
 ```
 
 Every root-relative link in the built HTML has to point at a page that is in the site, and
 every page has to be canonical at the address it is served from. A site whose links 404 is
-worse than no site, and nothing else says so.
+worse than no site, and nothing else says so. The skill is checked with them, because a
+bundle that has fallen behind the pages it was made from is quietly wrong.
 
 ### The custom domain
 
@@ -249,7 +252,7 @@ to it, and the site is published at the GitHub Pages address until then.
 content/          the pages, one directory per chapter
 _includes/        the layout, the stylesheet, the wordmark
 _documents/       the documents the examples read. Committed: an input must not change.
-src/              the reference tables, read out of the libraries and compared with the pages
+src/              the reference tables, read out of the libraries and compared with the pages, and the finder the examples are built with
 tests/            the claims the pages make in prose
 tools/            render-examples.php, make-input-document.php, the three checks, and lib/
 _examples/        built artifacts, published under the site's own path. Not committed.

composer.json

@@ -84,7 +84,7 @@
             "@php tools/check-readme-links.php ../markdown-word ../markdown-presentation ../mdoffice",
             "@test"
         ],
-        "check:site": ["@php tools/check-site-links.php", "@php tools/check-skill.php"],
+        "check:site": "npm run check:site",
         "check:links": "@php tools/check-readme-links.php ../markdown-word ../markdown-presentation ../mdoffice"
     },
     "minimum-stability": "dev",

content/general/errors.md

@@ -4,7 +4,7 @@ permalink: /errors/
 title: Errors in general
 summary: The exception to catch for each package, the two classes that share a name, and what the messages say about paths and losses.
 section: In general
-order: 3
+order: 4
 ---
 
 An exception is only useful if it says what to do next. Every message in this suite names the
@@ -32,9 +32,10 @@ try {
 so one `catch` does not also catch the failures of the libraries underneath. The failures a deck
 author can fix by naming something else extend `Exception\InvalidInput` below it.
 
-Five sit beside `InvalidInput` rather than under it, and nothing a deck names fixes any of them: a
-file that cannot be read, a target that cannot be written, a conversion with nothing to convert, or
-a dependency installed without the fixes the library needs.
+Six sit beside `InvalidInput` rather than under it, and nothing a deck names fixes any of them: a
+file that cannot be read, a target that cannot be written, a conversion with nothing to convert, a
+dependency installed without the fixes the library needs, or a source that cannot serve the master
+a theme carries.
 
 ## The two `UnknownDirective`