Depends on #79 and on #28.
#79 decides that the prose on a plugin page lives here, keyed by the roster
identifier. This is the consuming half: the files, the way the template reaches
them, and the check that keeps the two halves in step.
What each file carries, so that the pages are the same page rather than twelve
different ideas of one. What the plugin does, in more than the sentence the table
already prints. What it needs before it is any use, which for the pairing family
is a second server and for the transcription one is a model. What it does with
data about a person, which is the per-plugin line #49 asks for and is the reason
several of these pages exist at all. And what state it is in, in words rather
than as the computed word repeated.
Prose for a plugin that is a shell says what the plugin is meant to do and that
it does none of it yet, in the same shape as the others. A shorter page for a
shell is right; a missing one is not, because the reader arriving at a shell is
the reader most likely to have been sent by the table and least likely to know
what they are looking at.
The identifier is the only join. The template takes the file matching the row it
is rendering and nothing else, so adding a plugin is a row plus a file and never
an edit to the template.
Two failures, both decidable by walking the tree: a roster row whose file is
missing, and a file whose identifier no row carries. Both red the build, and the
failure names the identifier rather than the path, because the identifier is the
thing the two sides share.
Nothing here is fetched. The build reads the tree, which is what keeps it
reproducible and offline, and it is the reason #79 rejected reading the
repositories directly.
Text out of these files is escaped on the way into the page by the same path the
roster sentence takes, so a bracket in a paragraph cannot become markup. #43
fuzzes that path and this issue adds no second one.
The pages this produces are already counted in decisions/0003-generator-or-hand-written.md.
This adds prose to pages that record already counts and no address the plan did
not already have.
Done when
Every roster row has a prose file keyed by its identifier and every prose file
matches a row; a row with its file removed reds the build and the failure names
the identifier; a file whose identifier matches no row reds the build; each
produced plugin page renders its file rather than the roster sentence alone; a
file containing markup characters renders as text; and every produced plugin page
is inside every line of the budget in #6.
Depends on #79 and on #28.
#79 decides that the prose on a plugin page lives here, keyed by the roster
identifier. This is the consuming half: the files, the way the template reaches
them, and the check that keeps the two halves in step.
What each file carries, so that the pages are the same page rather than twelve
different ideas of one. What the plugin does, in more than the sentence the table
already prints. What it needs before it is any use, which for the pairing family
is a second server and for the transcription one is a model. What it does with
data about a person, which is the per-plugin line #49 asks for and is the reason
several of these pages exist at all. And what state it is in, in words rather
than as the computed word repeated.
Prose for a plugin that is a shell says what the plugin is meant to do and that
it does none of it yet, in the same shape as the others. A shorter page for a
shell is right; a missing one is not, because the reader arriving at a shell is
the reader most likely to have been sent by the table and least likely to know
what they are looking at.
The identifier is the only join. The template takes the file matching the row it
is rendering and nothing else, so adding a plugin is a row plus a file and never
an edit to the template.
Two failures, both decidable by walking the tree: a roster row whose file is
missing, and a file whose identifier no row carries. Both red the build, and the
failure names the identifier rather than the path, because the identifier is the
thing the two sides share.
Nothing here is fetched. The build reads the tree, which is what keeps it
reproducible and offline, and it is the reason #79 rejected reading the
repositories directly.
Text out of these files is escaped on the way into the page by the same path the
roster sentence takes, so a bracket in a paragraph cannot become markup. #43
fuzzes that path and this issue adds no second one.
The pages this produces are already counted in
decisions/0003-generator-or-hand-written.md.This adds prose to pages that record already counts and no address the plan did
not already have.
Done when
Every roster row has a prose file keyed by its identifier and every prose file
matches a row; a row with its file removed reds the build and the failure names
the identifier; a file whose identifier matches no row reds the build; each
produced plugin page renders its file rather than the roster sentence alone; a
file containing markup characters renders as text; and every produced plugin page
is inside every line of the budget in #6.