Glossary: BPMN activities
Candidate terms extracted from every BPMN task and call activity: name as the label, its own <documentation> as the definition, the element id as the code. Each is the asset’s own text, verbatim and not curated, and carries the badge “candidate, extracted”. A person promotes one by authoring it. Authored terms are on their owning instance’s page, and those pages, the counts and the sources are linked from the glossary index.
From: bootstrap 38 (SKOS) · bootstrap-tools 7 (SKOS) · cat-harness 483 (SKOS) · folio-assistant-core 161 (SKOS).
Size: this page holds 689 terms and is 567 KB before compression, fetched in one request, within its budget of 1.0 MB. There is no search index: the filter below runs over this page, and the A–Z bar jumps within it.
| target | mapped | unmapped | undetermined | why undetermined |
|---|---|---|---|---|
fhir | 0 | 752 | 0 | — |
skos | 0 | 752 | 0 | — |
Undetermined is never “no match”. A vocabulary that could not be reached has said nothing, and the column above keeps that apart from a checked miss. The counts are reported and not graded: an unmapped candidate may be a term this corpus is right to coin.
Per term. Every term on this page is unmapped on fhir, and unmapped on skos, unless its entry says otherwise. No entry says otherwise.
689 shown
0–9
- 1 · Declare in place (nothing moves) candidate, extracted
-
A
<name>.jsonentry with itsgraphs[]kinds. A sub-graph that owns its own layout gains a NESTED declaration whose paths resolve against its own directory, so the whole graph relocates by moving one folder. - 1 · Declare it in place, with its seam candidate, extracted
-
<name>/<name>.jsonwith name, version,repository(the planned home),livesAt(where it sits today),needs, and only the directories that exist, each declared with its files in one commit (bean dh4f).<name>/platform.tsfrom the first commit, so no climb out of the directory ever needs rerouting. Scaffolded byinit-folio --staged <path>, which writes those two files and nothing at the host root; never--instance, which writes a whole repository. -
Scope it: chapters, the blocks each needs, which statements are normative.
- 1–3 · Declare, detangle, isolate candidate, extracted
-
The graph-detanglement practice, all of its gates: declared in place, zero wrong-direction edges on every axis, and standing alone with its own declaration, namespace and artefact. A plain task on purpose, not a call to graph-detanglement.bpmn: that process ends in its own authorise-and-extract steps, which here are stages 9-13 of this one, and calling it would run them twice.
- 10 · Re-point: livesAt, seam, submodule or subscription candidate, extracted
-
In the new repository
livesAtgoes (absent means it sits at the root ofrepository) andplatform.tspoints at where the platform now is. The host consumes it as a submodule if it imports its code, or a subscription if it only reads its content, pinned to a commit while staging. Additive: the host keeps its copy. - 10 · Seed both repositories candidate, extracted
-
Seed main, then bring the content and the tools in as reviewed pull requests with their history, so neither repository's first commit is unreviewable.
- 11 · Parent consumes, additively candidate, extracted
-
The parent pins the pair (a commit while staging, a version once released) — a code dependency as a
source.remoteinstance in its rootindex.config.json(remote-mount skill), never a submodule — repoints its imports, and keeps its own copy until it is green with the dependency declared. - 11 · Verify on a fresh clone candidate, extracted
-
bun run cat sub-kg:verify-clone --repo <owner>/<name> --ref <branch>(Tool sub-kg-verify-clone): clone into an empty scratch directory with submodules and any sibling it needs, install, and run its own gates. Green, red or unknown, and unknown is never green. The measured falsifier (#2082): the first seeded fork failed with "Cannot find module" because nothing in a seed runs standalone until the seam is re-pointed. - 12 · First release candidate, extracted
-
Tag each repository, publish /<version>/ and /v<major>/. From here the two are versioned independently; a tools release lists the content majors it supports.
- 12 · Owner confirms: freeze the in-repo copy candidate, extracted
-
The agent reports the files that would move, their size, the new repository and the commit the copy matches, then asks: (1) freeze it in the kept trashcan now, (2) keep in place until the first release, (3) show the file list first. Default if there is no answer: (2), nothing moves. A green fresh clone is the precondition for asking, not the answer. Non-relaxable. Owner ruling, 2026-10-06 (bean 3tza, "1"): the host keeps a FROZEN copy in the kept trashcan, not a refreshed mirror and not a deletion; the live copy is the submodule or subscription set up at stage 10.
- 13 · Cutover: freeze the copy in the kept trashcan candidate, extracted
-
Only on the owner's answer (1) at step 12. The in-repo directory moves, as one relocation, under separated/<name>/ in the kept trashcan, on its own branch (a plain mv, git rm --cached, state:push; the trashcan skill says how), with ONE note carrying movedFrom, movedOn, the new repository and the commit the copy matches. Frozen: never refreshed, never rendered; a reader wanting the live content follows the note to the new repository. On main this is one revertable commit removing the directory.
- 13 · Cutover: retire the parent's copy candidate, extracted
-
The one commit worth reverting, made only after the parent consumes the release and every identifier dereferences. It retires the parent's copy, frozen, never refreshed and never rendered, rather than deleting it (owner, 2026-10-06). Where the copy goes is the sub-kg-lifecycle skill's stage 13; this diagram does not name that store, because the published graph must not.
- 2 · Grow it in place candidate, extracted
-
The content type's own authoring process runs here, against the staged instance. Many sub-KGs never leave; this task can last as long as the graph does.
-
The plan becomes beans, so a resumed session or a sibling agent can pick it up.
- 2a · Measure — unassigned column FIRST candidate, extracted
-
bun run cat check:partition. Read the unassigned column before the edge count, and quote BOTH numbers rather than only the one that improved. The count rising when the measurement improves is correct: 43 to 49 when thirteen previously-unjudged edges were folded in. - 2b · Prune, merge, factor — or the classification is wrong candidate, extracted
-
The only four moves. Move the shared TARGET first and the importers after; check the target's layer before the importer's; a schema moves with its script. The fix is never an exemption, it is the right owner.
- 3 · Isolate — own declaration, namespace, artefact candidate, extracted
-
Only once cross-edges measure zero: give the sub-graph its own declaration, its own namespace and its own published artefact, as bootstrap/ has (its own declaration, bs: namespace and graph document). Nothing moves yet; the sub-graph now stands alone in place.
- 3 · Push generic down first candidate, extracted
-
Move what is generic into the harness below before the seam is closed, and consolidate what the sub-KG needs into the harness it instantiates. Wrong-direction edges hide in declarations and data as well as imports: run check:import-direction, check:reference-direction and check:process-bindings. Learned from stages A-D of bean n3ni (#1768, #1782, #1783, #1795).
-
folio_init writes content/, uploads/, library/, the manifests, the builder shim and AGENTS.md. Skipped when the folio already exists.
-
Every block edit runs the HCI validation gate — see editing-hci-validation.bpmn. A normative statement is a
recommendationblock (bean 55ao), drafted through normative-statements: one statement per block, a folio-chosen label, and its strength as a code in a declared code list, so a reviewer signs off each one individually. - 4 · Extract — a directory move, not a file-by-file sift candidate, extracted
-
Only once edges are zero and the declaration stands alone: move the sub-graph out as one directory move, not a file-by-file sift. Its nested declaration resolves paths against its own directory, so moving the folder moves the graph. The five-point gate is in migration-plan.md Phase II.
- 4 · Identity: version, iriBase, nodeSchemas candidate, extracted
-
The declaration carries name, version, iriBase, needs and nodeSchemas. A base move is
bun run iri:sync -- --from <old base>, once; theniri:sync:checkandcheck:node-irisare green. - 4 · Route every climb through platform.ts candidate, extracted
-
Every platform symbol the sub-KG uses is re-exported from
<name>/platform.ts, so re-pointing the platform is a one-file edit. A merge from main is where new climbs arrive; reroute them here. Learned from #1767 and #1860. -
content_profile_check: no math kind, no lean field, no .lean sibling. This is the step a paper folio does not have, and the reason a document folio never needs Lean or TeX to publish.
- 5 · Move harness output about it to the host candidate, extracted
-
QA verdicts, translation templates, the exported graph and the glossary ledger are harness output ABOUT the graph: they live with the harness (kgQaHomeFor, translationsHomeFor). The content keeps only what its own checks need; the leak test's pending list is empty.
- 5 · Rehearse self-contained candidate, extracted
-
bun run cat seed:ready --layer <name> --rehearsecopies the layer and what it needs into a scratch workspace of sibling directories and runs the tests there. Run the gates rather than scanning imports: the fork rehearsal (bean rbz3) found a static scan saw 20 of the 23 platform files the gates loaded, and that renaming the directory changed every generated page. - 6 · Report what would move, and how it undoes candidate, extracted
-
Before the first outward-facing step the agent reports: the files and bytes that would move, the history that comes with them, what in the host changes, and how each step is undone. It never creates a repository on its own initiative.
- 6 · Split content from tools candidate, extracted
-
Create <name>-tools as a sibling directory and move the code: the Zod source, the generators, the README and diagram writers, the content checks. Cut its import cone to its own files and declared packages. Both start at the content's version.
-
Schema and constraint checks over every block.
- 7 · Owner confirms: create the repository candidate, extracted
-
Creating a repository is visible outside this one and is not undone by a revert. Numbered options, recommended first: (1) the owner creates it and says when it exists, (2) the agent creates it, only with that permission, (3) not yet. Default if there is no answer: (3), nothing is created. Non-relaxable.
- 7 · Plan publication candidate, extracted
-
Every identifier the content mints is a file some step publishes: /<version>/ for what programs read, kept for every version; /v<major>/ for pages people read. Name collisions between published files are resolved here.
-
Assemble to Markdown, then pandoc. The PDF goes through an HTML engine — never latexmk.
- 8 · Create the repository candidate, extracted
-
The owner creates the repository, or authorises the agent that has the permission to; when that agent is in another environment, the hand-over is one bean and one sentence (agent-handoff). The new repository is read before anything is written to it: empty is a fact to check, not to assume.
- 8 · Rehearse standalone candidate, extracted
-
Copy the content and the tools alone into a temporary directory, with nothing else on the path, and run the tools' checks there. An empty tree must exit non-zero, so a rehearsal over nothing cannot pass.
-
The reviewer this folio binds. authoring-document relaxes the base SME step precisely because no single lane fits every document.
-
A repository cut changes the substrate every other process binds to; that is a person's decision. Declining leaves the graph declared, detangled, isolated and split in place.
- 9 · Copy the staged contents in, with history candidate, extracted
-
git subtree split --prefix=<name>in the host, then the split branch added to the new repository on a branch, as a draft pull request, never straight to main. The new repository's own root files are a second commit, so the copy stays byte-identical and reviewable. The first fork seed carried 378 commits this way (bean n3ni, stage E). -
See draft-to-publication.bpmn for the review and release path this expands into. Release authorisation is not relaxable.
A
- Abort, restore the tree, list what was refused candidate, extracted
-
git merge --abort. Each refused path is listed with its pattern's reason, or "no declared pattern". - Accept it, and record where it came from candidate, extracted
-
Both branches land here. An unprompted offer is accepted as it stands — do not make somebody follow a process to hand over what they already have. Provenance is recorded whichever channel it arrived through: a description given in chat has a source and can be wrong, exactly as a PDF does.
- Accept, or send back candidate, extracted
-
The editor's lane, kept separate on purpose: the reviewer who judged the change is not the position that accepts it.
- Accessibility: measure, do not assert candidate, extracted
-
Contrast COMPUTED against the real ground, including the worst case a backdrop can present; a non-colour channel wherever colour carries meaning (SC 1.4.1); an accessible name on every region; keyboard and focus order. An automated pass is necessary and not sufficient — axe accepts a non-empty placeholder as an accessible name, and a CSS selector that matches nothing raises no error at all.
- Add an actor, and declare its kind candidate, extracted
-
Human, agentic or mechanical. A userTask because the agentic/mechanical line is JUDGEMENT — role-model.md says so — and reading it wrong disqualifies the actor from every judgement task it exists to perform, silently.
- Address the review candidate, extracted
-
Every finding is answered — implemented, or replied to with why not. A design question does not excuse skipping the nits in the same review.
- Adjudicate against the checker candidate, extracted
-
The reviewer and a checker read the same claim differently — a disagreement about ONE kg-qa criterion (prose-claims-resolve). Descend into Process_CriterionAdjudication, which runs the shared adjudication and then one of its three outcomes: the checker's finding stands, the criterion is scoped, or a dispensation is granted with its reason. The checker's entry is kept beneath the verdict rather than overwritten (requirement R4 of issue #1042).
- Adjudicate flagged passage (human reviewer) candidate, extracted
-
A human SME or editor reviews the flagged passage. They may: - Accept the translation as-is (false positive) - Edit the translation and re-run QA - Reject and request re-translation The round trip establishes that two readings differ. Which one is right is a human call.
- Adjudicate the conflict candidate, extracted
-
A human or agentic decision, never a merge rule. Which side wins depends on why the local edit was made, and a process that picked automatically would be choosing without the one fact that decides it.
- Adjudicate the criterion disagreement candidate, extracted
-
The shared judgement — entry condition, untainted dispatch, person-or-agent restriction — asked with THIS question's permitted answers.
cat-harness.processes:adjudication codessits here rather than onA_Adjudicateinside it because the answers depend on what was asked, and the gateway below is what acts on them: the engine refuses a mismatch between the two.Process_Adjudicationmay also leave atEnd_NotAdjudicable— one entry and no other side is a review or a gate, not a disagreement — in which case nothing below runs and there is nothing to record. - Adjudicate the disagreement candidate, extracted
-
The judgement itself, and the one step nothing here can check: if a mechanism could decide it, the process would not have been entered. It declares NO
cat-harness.processes:adjudication codeson purpose, and that absence is the whole of beanbvuk. This step used to name three — stands, scope, dispensation — and six diagrams called it:review-narrativeandvoice-review, whose question those three answer, and four whose question they do not.refresh-materializedasks which side wins a local-vs-remote conflict; there is no criterion to scope there and no dispensation to grant, yet the outcome half ran regardless. Since the caller's question decides the permitted answers, the caller declares them:cat-harness.processes:adjudication codeson its OWN call activity, with its own gateway acting on them.criterion-adjudication.bpmnis that for the QA-criterion question. What could NOT be fixed by passing the codes as data, which was this bean's first recommendation: the three branches ran three different TASKS, so a caller handedlocal-winswould have had it pointing atA_ScopeCriterion. The branches had to move, not the enum. - Adjudicate the disagreement [adjudication] candidate, extracted
-
adjudication.bpmn. When the editor and a reviewer, or two reviewers, disagree about a finding, an adjudicator settles it and records why; the review comment moves to
adjudicatedwith the Decision that closed it. Permitted answers (beanbvuk, owner 2026-09-23):stands— the finding is right and the author addresses it;withdrawn— the finding is wrong and the comment closes. Recorded on the comment, not branched: either way the flow goes on to the coverage check. - Adjudicate the flagged passage candidate, extracted
-
A machine can detect that two readings differ. Which one is right is a human call.
- Adjudicate the voice findings candidate, extracted
-
Three outcomes, all legitimate: the register is wrong for this genre; the criterion does not belong in this genre and should carry
profiles; or the block is a stated exception and a reviewer entry records why. - Adjudicate: prose, scope, or exception candidate, extracted
-
The same three outcomes as the base voice axis. The register is wrong for this block (fix the prose); the rule does not apply to this content (scope it on the voice, one edit rather than ten overrules); or the rule applies and this block is an exception (a reviewer entry saying why).
- Adjudication candidate, extracted
-
folio-assistant's adjudication: the adjudication leads, the checker's entry is kept, and the dispensation carries its reason. Reviewers disagreeing on ONE criterion is a criterion disagreement, so this calls the QA-criterion specialisation (bean
bvuk, owner 2026-09-23): the failing entry stands, the criterion does not apply to this screen, or a dispensation is granted with its reason. FOR THIS CALLER THE SPLIT WAS A REGRESSION, not a fix, and that is worth keeping because the PR that made it said the opposite. Whenbvukmoved the outcome half out ofadjudication.bpmn, #1074 reported that all four remaining callers "no longer reach A_ScopeCriterion or A_Dispensation" and framed it as the intended effect. True for three of them, whose question never admitted those steps. Here it removed the two steps the sentence above already documents, so the call was left pointing at a shared judgement that no longer runs either. Repointing restores what the documentation always claimed rather than changing it. The entry condition matches exactly rather than approximately: GW_Agree asks whether the blind reviewers' entries agree and takesnohere, andProcess_CriterionAdjudicationstarts at "entries for one criterion disagree" — R_Review records pass, warn or fail PER CRITERION with a reason, so the disagreement reaching this step is a per-criterion disagreement between reviewer entries and nothing else. - Admit it to the train, record the train id candidate, extracted
-
Writes the queue entry's
trainIdandplacement(rule, class, rank) with who decided and when. A decision, so it is stored; the facts it was decided on are not. PRECONDITION, CHECKED RATHER THAN ASSUMED: the worktree carries no untracked, non-ignored file before the member is merged and the tree regenerated.git status --porcelainmust be empty. The reason is specific: generated directory READMEs carry a per-subdirectory file count, and the writer counts the files GIT WOULD COMMIT --git ls-files --cached --others --exclude-standard(bootstrap-tools/scripts/git-files.ts:23).--exclude-standardalready keeps IGNORED junk out, which is the__pycache__case that drove that line, but--othersstill counts an untracked file nobody has ignored. So a transient written by an earlier train step moves a committed count,readme:subgraphs:checkgoes red, and the red belongs to nobody. Train 6 hit this. The count is volatile for a second reason the precondition cannot fix: two members each adding a file write different integers to one line. Measured in beany7b3-- 76 of 300 replayed merges conflicted onbeans/README.md, every one on the| defs/ | N files |line -- and the exposure is wider than that bean states: 54 generated READMEs across 14 instances carry 207 such rows (measured 2026-10-02).merge:mainalready resolves them (readme-generated-regions), so the cost falls on merges made by plain git. The chosen fix is beanba9e: take the integer offmaininto the KG's_datalayer, which classifiestake-baseand is therefore auto-resolved, leaving the README with a marker that is invariant until the directory crosses LIST_LIMIT. Not done here -- it spans the pinnedbootstrap-toolssubmodule. - Adopt the version bump candidate, extracted
-
The reusable subprocess. Every pinned dependency enters it the same way, so a new tenant is a registry row and a call — never a second diagram saying the same thing in different words.
- Adopt, hold or decline candidate, extracted
-
A PERSON decides. The lane admits
persononly, soactivity-fulfilment-kindfails the moment somebody makes an agent the accepting party, andrelaxable="false"means no package may relax the step. The publication manager rather than the editor because a pin is not a change to the corpus — it is a change to what the published artefact is BUILT FROM, and that role is the one accountable for what is live. Deliberately NOT a DMN-backed gateway. Every computed gateway in this repository reduces to arithmetic over tool output; this one weighs a rendering nobody can score against the cost of staying behind, and a table here would look authoritative without being so. - Agent review of the change [content-review] candidate, extracted
-
A review agent judges what no checker can: accuracy, voice, exposition, whether the change says what the editor meant.
- Agree each change-set's requirements on its issue candidate, extracted
-
A change-set gets its primary GitHub issue the first time somebody engages with it (the Discuss form, a recommendation or decision on one of its comments, a mention, a PR), opened by the folio's public-comment workflow; any number of other issues may discuss it and are linked. People agree the requirements there, and the committee or editor changes the record with cs-add / cs-remove / cs-title / cs-requirements / cs-merge / cs-split / cs-close / cs-new. The issue's change-set section is rendered from the record and put back if hand-edited; the nightly reconcile keeps every issue in line. The issue is for requirements; the PR that closes it is for preview, review and approval.
- Alert the publication manager [publish-verification] candidate, extracted
-
Process_PublishAlert — the ONE alert every failing step after the publish button goes through, whichever step it was.
- Announce the branch on the issue candidate, extracted
-
On CREATING the feature branch, comment on the issue: the branch name, the process and phase, and the beans claimed. Visibility is the whole point — without it a sibling session or a human cannot tell that work has begun, only that it has finished. Deliberately on this edge and not inside Phase 6. The three loops back into A_Implement (increment rejected, MVP not ready, feedback translated) re-enter implementation on the SAME branch, and re-announcing on each would be noise. Announce once, when the branch is created. Before announcing, run the collision review that starts any new unit of work (coordinate, "Starting new work"): open PRs and in-progress beans checked against the branch's files and subject, scaled to the blast radius, and the result recorded in the bean before the first edit.
- Answer, decline, or say nothing candidate, extracted
-
The Requestor's move. Declining is an answer. Saying nothing is not, and is what the recommendation's "if there is no answer" was for.
-
Append
removedwith the reason candidate, extracted -
BEFORE the removal, not after: a job that dies mid-step must leave a record of the intent rather than an artefact that vanished with no entry. A reason is REQUIRED — an entry saying an artefact went and not why is the ambiguity this log exists to prevent.
-
Append
renderedcandidate, extracted -
A re-deploy is a rendering, so it gets its own entry rather than overwriting the last. "When was this last built" is then answerable without diffing commits.
-
Append
renderedto the render log candidate, extracted -
Its OWN commit, not part of the deploy. The publish action writes only into
destination_dir, so an entry riding in_sitewould land atSTAGING/<slug>/_render-log/— inside the directory a cleanup removes, which is the one place a record of the removal must not be.continue-on-error: a preview that deployed and whose entry did not is a gap in the record, not a failed deploy. -
Append
restoredcandidate, extracted -
A full-replace deploy (
docs-site.yml, the only publisher without keep_files) wipes the branch;restore-stagingcarries the previews AND this log back in. Its own event rather than a secondrendered, because "somebody pushed this branch" and "an unrelated merge nearly deleted it" are different facts — and beanplj1is what happens when the second is invisible. -
Append
retainedwith the reason candidate, extracted -
THE ENTRY THAT MAKES THE LOG WORTH READING. A preview still standing because a signal fired leaves no trace otherwise, and the next person asking "why is this still up" has nothing to consult. A reason is REQUIRED — the tool refuses without one.
-
Append
retained, with why it stays candidate, extracted -
The event that makes the log worth reading. A removal was CONSIDERED and refused; without an entry that leaves no trace on the branch at all, and the next person asking *"why is this preview still up"* has only a comment on a pull request that may itself be closed.
- Append WHO disclaimer (if DAK) candidate, extracted
-
For WHO SMART Guidelines content, automatically appends the WHO legal disclaimer: - Translation not created by WHO - English edition is authoritative original - WHO not responsible for translation accuracy Only applies when folio contentType includes WHO/DAK content.
- Apply it, and state each option's trade-offs candidate, extracted
-
Follow the selected methodology as written — adopted whole, not blended with another. At least two real options: one option is not a choice, and a straw option is worse than a short list because it makes the analysis look thorough while narrowing it. Never quantify the comparison to make it look measured. Where a method scores and sums, this platform takes the structure and refuses the arithmetic: the weights are invented and a total reads as a measurement.
- Apply the stated default, and say so candidate, extracted
-
Only the default stated in A_Recommend, only where the caller allows one, and recorded as assumed with the default named — never as the person's answer. The next message to the person says it was applied, so they can reverse it.
- Appraise and grade the body of evidence candidate, extracted
-
Certainty of evidence per the grading system the folio declares. The grade attaches to the BODY of evidence for one PICO question, not to an individual citation -- which is why this step is after the join and not inside the fan-out.
- Approve candidate, extracted
-
The committee approves the change: the judgement, recorded with the evidence it rests on. Approving is not merging. They were one task ("Approve and merge") until bean en2d split them, because a self-authored change cannot be approved through GitHub's own review (the approver may not be the PR's author), and a merge needs the owner's explicit confirmation whoever approved.
- Approve requirements candidate, extracted
-
Stakeholders approve the requirements and impact analysis on the issue, or send them back for revision. Only their approval moves the work to sign-off; an agent never records an approval on a person's behalf.
- ARCHIVAL verify fixity — never re-fetch candidate, extracted
-
Re-compute the digest and compare. An archive is NEVER re-fetched — the source is what it exists to survive, so replacing it with today's version discards the state it was keeping. A mismatch means OUR copy rotted, and the remedy is restoration from a backup, not re-download.
- Archive → greppable contents manifest candidate, extracted
-
NOT IMPLEMENTED. Tracked as a bean; see docs/document-ingestion.md. Tar/zip is opaque to every grep in the corpus until its contents are listed as data.
- Ask BA to create or link issue candidate, extracted
-
Ask — never create. Creating an issue without the BA's permission is the thing this step exists to prevent.
- Ask first about what could not be determined candidate, extracted
-
The caller's question waits, and is counted ("one more question after this"). What is put first is the undetermined one: the context you could not establish, the Role you are not sure you hold, or the Process you cannot place this in. It goes through the same order as any question — say what you determined and what you could not, the candidates you see, the one you would pick and why — and it allows NO default: a Process or Role assumed rather than confirmed is an authority nobody gave. With more than one undetermined, ask about the outermost first (the Process before the Role before the context), since the outer answer usually settles the inner.
- Ask ONE question candidate, extracted
-
One question, answerable by picking. With several decisions open, ask one in full and give a count for the rest. Uses whatever channel the caller is in — in bootstrap, the conversation the person is already in.
- Ask the owner on the PR, both sides quoted candidate, extracted
-
The asset carries no description.
- Ask the person to do what only they can candidate, extracted
-
A step the agent cannot do or cannot check from here — switching Pages on without a signed-in
gh, granting a permission, choosing between two ways of fixing a declaration. Asked through the one reusable discussion, with the exact step written out so it can be followed without opening anything else. A person saying "done" is recorded as their word, not as a check; the next run checks it. - Ask the Requestor: which harness, and where? candidate, extracted
-
The candidates go in as the options; the recommendation may name one; the default is NONE. What A_DetermineWhere established goes in too — the process, the two roles, the context — so the called discussion checks it rather than re-deriving it; and anything it could not establish goes in as undetermined, to be asked first. The Requestor's answer comes back as answered, or the question as still open.
- Ask who is acting candidate, extracted
-
The one step that needs a person. Asked ONCE and recorded, never re-asked:
cat-harness/memory/interaction.jsonand the record exist so that a preference stated once is not requested again, which is WCAG 2.2 SC 3.3.7. - Ask, per open PR, whether its HEAD has a run — skipping heads younger than 15 min candidate, extracted
-
Run check:prs-have-runs --min-age-minutes 15, writing the report file first. A head younger than 15 minutes legitimately has no run yet and is skipped. Exit 0 clean, 1 findings, 2 could not determine; an exit 1 with no report file is a crash and is treated as could-not-determine.
- Assess downstream impact candidate, extracted
-
Agent reviews downstream implications: - Will indicators need adjustment? - Will referral/follow-up for next visit be impacted? - Are translations affected (re-extract POT)? - Do Lean proofs still hold? skill: integration-watcher, translation-manager
- Assign to committee members candidate, extracted
-
public-comment assign: by GitHub login. A committee member who recommends on an unassigned comment is assigned it as they do.
- Assign to qualified human translator candidate, extracted
-
The coordinator assigns the translation to a qualified translator, ideally a domain SME for the content area. For WHO content, the translator should be familiar with WHO SMART Guidelines terminology. The assignment includes: - The .pot file(s) from extraction - The domain glossary - Context notes (block kind, chapter, content area) - The deadline
- Attach the evidence to the recommendation [content-author] candidate, extracted
-
The PICO, the graded body of evidence, each verified citation and its resolved authority record are written onto the recommendation block, so a reader can retrace the whole chain from the sentence back to the source.
- Attest the pair, with a reason candidate, extracted
-
The prose holds: record it with
bun run cat pairs:attest -- --sidecar … --by agent|human --reason "…", naming what was compared. The attestation moves the pair's baseline to the current hashes, so the staleness flag clears and stays cleared until the code moves again. - Attribute the failure: each member's own CI first candidate, extracted
-
T2 (SQ19 §2.1 pp. 2-3). A member whose own PR CI is red, or never ran on its head, is the prime suspect, and the evidence is already on GitHub. Only when every member is green alone is the failure a real conflict between them.
- Audit the code nodes the increment adds candidate, extracted
-
Descend into the review task for what this increment CHANGED IN THE GRAPH — Tool definitions in
tools/and schema definition nodes underschemas/. It runs before the summary, and therefore before an MVP can be shared: a Tool or schema node shipped in an MVP is the version stakeholders start building expectations on, and a node that names a skill nobody wrote is cheaper to catch here than after sign-off. Called, not inherited: the agent keeps its implementing role and takes on thecode-reviewerlane inside Process_CodeReview for that call path only. - Audit the graph [kg:audit] candidate, extracted
-
AFTER the change, not before. Every criterion here is a join — role to lane, actor to role, activity to skill — so what an administrative edit breaks is not in the file it edited. The sidecars under
test/results/kg-qa/are committed for the reason a printed verdict is not: without them, "unbound since it was drawn" and "broken by this change" are indistinguishable. -
The one step no package may relax. A repository cut changes the substrate every other diagram's lanes bind to, and that is a person's decision.
-
Publication requires authorisation by the programme manager or designated authority.
- Available to cite as an L1 source candidate, extracted
-
Every knowledge-graph reference to this source now resolves through library/. Authoring and review consume it from here -- see authoring-a-document.bpmn.
B
- Back off [backoff-sleep] candidate, extracted
-
Wait the same intervals
backoff-sleep.tsuses, then go round again: fetch the new tip and splice onto it. Three attempts in all. - Basic ingestion (harness) candidate, extracted
-
The harness's
document-ingestion.bpmn: accept the upload by a declared route, extract its metadata into the KG, and catalogue the asset in library/ — placed if materialized, recorded as referenced if not. Everything below refines that result for a document. Called, not copied: this was Lane_0 and Task_Place of this diagram until placement PR6 moved them down as the basic flow. - Bind the folder name to the bibliography slug candidate, extracted
-
Bind the folder name to the document's bibliography slug, so library/<bib-slug>/ and its citation key are the same string: a citation resolves to a directory without a lookup table between them.
- Bind the test data [fixed or generated] candidate, extracted
-
Per bean
vm6m: a fixed set is a committed path and counts as evidence only once reviewed; a generated set is template + params + seed and is never materialised. Both feed the run's data hash, and nothing that feeds the process hash may feed it too. - Bind Typed Parameters & Execute SPARQL candidate, extracted
-
Safely bind validated parameters into the audited SPARQL template with escaping. Execute SPARQL query against the Oxigraph store.
- Bisect the train candidate, extracted
-
Halve the members and re-run the gates on each half until the conflicting one is found: two or three CI runs for three to six members. Only reached when the cheap evidence is silent.
- Blind review per criterion candidate, extracted
-
Criteria: intent-fit, web usability, mobile usability, accessibility, and alternatives considered. A review at one viewport only is incomplete.
- Branch, and announce it candidate, extracted
-
Announce the branch WHEN IT IS CREATED, not when the work is done. The gap between one agent's view of an issue and everyone else's is what this closes.
- Branch, gates, PR and review [code-change-review] candidate, extracted
-
Called rather than restated. The mechanics of getting an edit reviewed and merged are not specific to the role graph, and a second description of them is a second thing free to disagree with the first.
- Branding: does it read as this instance? candidate, extracted
-
Marks, palettes and art against the instance's own declaration rather than a remembered style. The question a downstream folio makes sharp: would this instance inherit something it did not choose?
- Brief the topic before touching anything candidate, extracted
-
What am I doing and why is it worth doing; what do I already know, with each measurement's provenance; how do I plan to do it and WHAT WOULD FALSIFY THE APPROACH. A falsifier that never fires is decoration — this practice's own fired, took edges 5 to 12, and rewrote the plan.
- Brief, and claim the bean candidate, extracted
-
What is separating and why, what is already measured with its provenance, how it will be done, and what would falsify the approach. Claim the bean so a sibling session sees the work.
- Brief, and claim the bean candidate, extracted
-
What the sub-KG is and why it is staged here rather than in a repository of its own, what is already measured, and what would falsify the plan. Claim the bean so a sibling session sees the work.
- Build and QA gates [content-test] candidate, extracted
-
Lean build and proof status, LaTeX compile, FHIR/SUSHI validation, QA axes.
- Build each slice into _site at deploy candidate, extracted
-
gen-slice-sqlite.ts --out ./_site/assets/slices --payload-out ./_site/payload/sha256 --slice <name>, once per slice, from the tree being published: the file, its manifest, the slice index, and the deploy payloads beside the committed KG payloads. Never into the committeddocs/payload/, whose orphan audit admits KG nodes only. - Build it locally and measure the file candidate, extracted
-
Run
bun run cat slice:sqlite -- --slice <name> --out <scratch>and read the manifest:bytes, the row counts, the payload count and bytes,overBudget,duplicateIdsandfindings. Record the measurement on the bean with its provenance (the command and the date), beside the size of the source it replaces. - Build staging site candidate, extracted
-
feature-staging.yml triggers: 1. Regenerate docs (schema, skills, content-backed pages) 2. Render BPMN diagrams 3. Stamp build with commit SHA + timestamp + branch 4. Build Jekyll site with STAGING/ baseurl 5. Inject yellow staging banner into every HTML page
- Build the docs site Jekyll · TypeDoc · KG export candidate, extracted
-
Build the preview from the PR's head: regenerate the generated docs, trim what this preview does not need, render the BPMN diagrams, then Jekyll, TypeDoc and the knowledge-graph export, with the staging banner and SEO identity claims stripped.
- Build the draft publication [content-publish] candidate, extracted
-
Render the corpus into the draft form of the folio: PDF, HTML site, or FHIR IG.
- Build the entry [tree + manifest] candidate, extracted
-
First the working copy is produced (
qa:refresh, bean3hk4): while the checkout still trackstest/results/, the commit's own copy is the record and nothing runs; once it does not, every declared QA writer runs into the empty tree, because the gates are in judge mode and wrote nothing a publish could carry. A refresh that leaves a writer failed, a family empty or a file unclaimed is INCOMPLETE: the job goes red andqa:publish --completenessrefuses, so a partial tree is never stored as the commit's record — the "Not stored" outcome, reached before any push. Then it hashes the working copy of every declaredqadirectory (<instance>/test/results/**, byte-identical to the checkout's layout) into a tree through a private index, and writesmanifest.json(qa-reports-manifest/v1): inputs, producers, verdict counts and the gates' result. Identical JSON is the same blob, so an unchanged family costs nothing to store again. Its git objects live in a private bare repository, never in the checkout's own store. - Build the Jekyll site and the API reference candidate, extracted
-
Compose the docs layers, build the Jekyll site, mount instance-rendered content, and generate the TypeScript API reference with TypeDoc.
- Build the L1 knowledge graph [document-intake] candidate, extracted
-
See ingest-build-l1-kg.bpmn.
- Build the test run [folio-test-run/v1] candidate, extracted
-
Assemble the run record the signature will cover: the data hash and the process hash, each all-or-nothing. An UNKNOWN_HASH never reproduces another unknown, so a run that could not be hashed is signable only as what it is — unverifiable.
C
-
Each hit gets a category (overlaps: coordinate; affected by; out of scope; unrelated) and a one-line summary with its state. Judgement, not a keyword score: say why each is in its category.
- Check before you create (exact-title search) candidate, extracted
-
STRICT.
beans createis not idempotent: it mints a fresh id every call and dedupes on nothing, so re-entering a step duplicates the plan instead of no-op'ing. In the qou folio an unguarded re-run produced 14,688 duplicate beans — 92% of every open bean — which starved the idle-backlog policy of signal and collided with 15 real ids. - Check disk against lock against declaration candidate, extracted
-
mount:remote:check, with no network: the lock's pins are the declaration's, and every locked directory is on disk and hashes to its digest. Could-not-determine outranks missing, which outranks mounted. - Check Graph Availability Guard (requiredSubgraphs) candidate, extracted
-
Inspect query definition requiredSubgraphs list. Verify that each required subgraph is currently loaded into the Oxigraph store.
- Check it candidate, extracted
-
Look, do not remember. The answer is one of the four states, and "could not determine" is its own answer: a check that could not look is not a pass.
- Check staleness (source hash) candidate, extracted
-
On source content change: computes sha256(source.md) and compares to each translation's status.json sourceHash. If they differ, sets stale: true. The translation remains visible with a "stale — needs re-adjudication" indicator.
- Check the JSON Schemas and JSON-LD are at their IRIs candidate, extracted
-
THE PRIMARY STEP of initializing a Knowledge Graph harness (owner, 2026-09-30: "json(ld) is primary step in initializing KG harness"), and so the first one checked once the declarations are read. Every JSON Schema the harness publishes (its
$id) and every JSON-LD document (its vocabulary, its diagram vocabulary, its graph export, each carrying its own@context) is at the address it names undeririBase, where a program following the IRI finds it. Two checks: that the site build stages each one at its address, and that each address answers. A 404 is not published; a 403 or no answer from here could not be determined. The Pages site is the vehicle: when the documents are not yet answering, the site steps below are how they get there, and the report leads with this step's state. - Check the selected methodology's evidence base candidate, extracted
-
Before applying a methodology, establish that the thing being applied is what it claims to be. A methodology is adopted because it is somebody else's named, external work; this step checks that the
originit cites resolves to a source in a declared library, and reads themethodology-evidenceQA sidecar for it. WHY THE CHECK IS HERE AND NOT AT ADOPTION. Adoption happens once; selection happens every time a decision is made. A source that was reachable when the methodology was adopted can stop being so, and a methodology adopted before this axis existed was never checked at all. Measured 2026-09-22: six methodologies cited an origin and NONE had that source in any library, so every selection made until then rested on an unverifiable citation. WHAT A GAP DOES AND DOES NOT DO. A missing source does NOT block the decision, and this step has no branch that stops the process — that would make a documentation gap into an outage, and the owner decides whether an unbacked methodology may still be used. It does two things: it runsliterature-searchto try to close the gap, and it puts the evidence state into the recordA_Recordwrites, so a reader can tell a decision made on a verified method from one made on a citation nobody could follow. The third state is the one that matters. "Source ingested", "source located but unreachable from here" and "no source found" are three different facts, andliterature-searchexists largely to stop the middle one being reported as the last. - Check the slug's SHAPE and that the confirmation repeats it candidate, extracted
-
Guarded three ways because a dispatch input is a DELETION TRIGGER.
workflow_dispatchis available only to an actor with write access; the slug must match exactly the characters the sed pipeline can produce, with.and..refused by name; and the confirmation must repeat the slug, so a confirmation cannot be carried over from an earlier run against a different preview. - Check translation completeness candidate, extracted
-
Verify that all msgid entries have msgstr translations. Partial translations are acceptable for initial submissions but must be flagged for follow-up. The coordinator checks: - % of strings translated - Any fuzzy-flagged entries - Missing critical sections
- Check what is served candidate, extracted
-
Ask the root URL and every document address. 2xx or 3xx answers; 404 is not there; 403, 407, 5xx or no answer is about the way here and could not be determined.
- Check what was staged candidate, extracted
-
site.ts --check and readme-book.ts --check: every document at its address, no address taken by another file, every link on the page landing. This is the QA of what would be pushed.
- Choose a candidate candidate, extracted
-
A one-off choice between surviving candidates. Rejected candidates are kept, with the reason each lost.
- Choose a destination, or none candidate, extracted
-
A PERSON'S STEP, and
noneis one of the answers rather than a refusal to answer. A requirement whose whole content is carried by the code becomes a commit and nothing else; a graph that acquires a node for it is a graph with a node nobody will ever read. The default creates NOTHING. An agent that decides on its own that a requirement "is really a skill" has manufactured a node nobody asked for, in a graph somebody else maintains — which is what this step exists to prevent. - Choose from the offered options candidate, extracted
-
The question is presented as a short list of selectable options, never as free prose, and the list names the top-level content types the agent knows about. The answer becomes the statedIntent fact and the table is evaluated again — the user's answer is read as evidence, like any other fact.
- Choose subgraphs, the asset policy, harnesses candidate, extracted
-
Written to the entry as
subgraphs,assets.policy(none, on-demand or all) andharnesses. Choosing is not holding: a chosen subgraph is still referenced until the gates below let it through. Choosing nothing is legitimate — a subscription with no parts chosen is a pinned reference, the case associatedHarnesses covers today. - CI Gate Verification: Audit Manifest & Schemas candidate, extracted
-
Validate that subgraph-manifest.json conforms to NQuadsDistributionManifestSchema, all referenced partitions exist, and external schema w3c-n-quads is satisfied.
- Circulate the draft [content-review] candidate, extracted
-
The draft publication is circulated to the review team for formal review.
- Cite the author of every narrative candidate, extracted
-
A generated description is a claim by someone. Record whether a human or an agent wrote it, and for an agent the model version. An uncited narrative is indistinguishable from a transcription of the source.
- Claim it (status: in-progress) candidate, extracted
-
Idempotent. Claim BEFORE working, and note the branch, so a sibling session can see the item is taken rather than discovering it by collision.
- Claim or open the bean [todo-manager] candidate, extracted
-
Every edit is tracked as a bean in beans/. Check for an existing bean by exact title first; claim it (status in-progress) rather than minting a duplicate.
- Claim the work item candidate, extracted
-
Claim before you work. A claim ANNOUNCES rather than reserves until the PR exists, which is why the branch is announced at the next step and not at the end.
- Classify every conflicted path against the declared patterns candidate, extracted
-
The first matching pattern decides: take-base, generated-regions, qa-sidecar, or refuse. A path no pattern names refuses.
- Classify what changed candidate, extracted
-
Prose, code nodes, or both. This is the only decision the generic lane makes on its own: everything after it is made inside a subprocess by the role that lane binds. Binds
content-review, the same skill as Task_Consolidate in this lane, since placement PR3 (bean63wl): it namedsemantic-review-scoping, a paper skill the science layer owns, which this harness diagram cannot reach. A paper process that wants semantic scoping adds it by calling this process. - Clinical / scientific sign-off [content-review] candidate, extracted
-
Domain sign-off: clinical SMEs for a guideline, subject-matter reviewers for a paper.
- Close issue ONLY on BA authorisation candidate, extracted
-
Reachable only through BA_Confirm, which is the BA saying every criterion is met. An agent must never close an issue without that explicit authorisation — the gate is the preceding task, and this name says so rather than leaving a reader to trace the flow for it.
- Close the bean, merge commit as evidence candidate, extracted
-
The asset carries no description.
- Close the publication manager's alert, if open candidate, extracted
-
A clean publish resolves whatever the last failure raised: close the open publication-manager tracking issue with a comment naming this run.
- Close the release beans [todo-manager] candidate, extracted
-
What shipped is resolved; what slipped stays open and carries into the next cycle.
- Close the session candidate, extracted
-
Records that the actor stopped. It does NOT resolve beans or complete instances: those outlive the session by design, and a machine that closed them on the way out would be asserting work finished because somebody went away.
- Close the tracking issue candidate, extracted
-
Clean: close the open ci-health issue, if any, saying why (main is clean). Runs only on a clean verdict — on unknown the issue is left untouched and the job fails instead, because could-not-check is never rendered as clean.
- Close the tracking issue candidate, extracted
-
Clean: close the open pr-no-checks issue, if any, saying why (every open pull request's head now has a CI run). Runs only on a clean verdict — on unknown the issue is left untouched and the job fails instead, because could-not-check is never rendered as clean.
- Close the tracking issue candidate, extracted
-
Clean: close the open repo-health issue, if any, saying why (every check ran and none had anything to report). Runs only on a clean verdict — on unknown the issue is left untouched and the job fails instead, because could-not-check is never rendered as clean.
- Close the tracking issue candidate, extracted
-
Closed automatically when every pin is current, so the issue's existence is the state rather than a log of past states.
- Close the window back to its avatar candidate, extracted
-
[x] closes the window back to its avatar. Only a person's [x] does this; a zoom-out never closes a window, or [x] and zooming become indistinguishable to the reader.
- Close-out candidate, extracted
-
The stakeholders sign off, the BA confirms every criterion is met, and only then does the agent close the issue. Never the other way round: an agent must never assume completion.
- Code node review candidate, extracted
-
Descend into Process_CodeReview. The actor takes on the
code-reviewerlane for this call path only. - Collate findings into a report candidate, extracted
-
Mechanical results and review findings are merged into one report against the proposed change.
- Collect or reconstruct a handover report per agent candidate, extracted
-
Use the agent's own report and check it against live state; if none, ask the agent if it is still reachable, else reconstruct with the handover-report template and mark it reconstructed. Unpushed state is unknown, never empty.
- Comment on the open issue, naming the step candidate, extracted
-
Add this failure to the open issue as a comment (which notifies), and refresh the body to the latest state.
- Comment on the PR once, linking the bean candidate, extracted
-
One comment per refused PR, edited in place on every later event.
- Comment ONCE per (PR, head sha) candidate, extracted
-
Comment on each affected open PR once per (PR, head sha): a hidden marker carrying the sha is checked first, so a re-run on the same head stays silent and a new push can be reported again. A PR that is no longer open is skipped.
- Comment staging URL on PR candidate, extracted
-
Bot comments or updates the staging URL on the PR. Includes commit SHA, branch name, and build log link, and the review list of rendered files the change alters (skill rendered-impact), each linked on the preview and on main, with any input the renderer could not place named as not known.
- Comment the preview URL on the PR candidate, extracted
-
Post, or update in place, one comment on the PR giving the preview URL (STAGING/<slug>/) and the commit it was built from. Pull-request events only.
- Commit a tip without the pruned entries candidate, extracted
-
One new commit whose tree lacks the pruned entries, parented on the current tip, through the same fetch → rebuild → push loop as a publish: no
-f, three attempts. History is not rewritten — truncating it is a deletion of a different order and the owner's call (deletion-requires-confirmation), not a scheduled job's. - Commit into the corpus candidate, extracted
-
Only now does the change become corpus content, together with its QA sidecars. Subject to the commit-hygiene requirement.
- Commit the merge candidate, extracted
-
The asset carries no description.
- Commit, push, open the PR candidate, extracted
-
The PR opens at the FIRST commit, even on a stub, and permission is never asked for it. Holding a green PR back for someone to look at is not caution — it is a blocked reviewer. A change to a rendered surface carries a before/after preview in the PR body (skill before-after-preview).
- Commit, push, update PR candidate, extracted
-
Agent commits all changes to the feature branch and pushes. The feature-staging.yml workflow automatically deploys to STAGING/<branch-slug>/ and comments the URL on the PR. For a rendered change the agent also produces the before/after preview (skill before-after-preview) and links it in the PR body.
- Compare main vs staging candidate, extracted
-
The review starts from the Change Set's RENDERED list (skill rendered-impact): every rendered file the change alters, predicted from each renderer's dependency cone and checked against the build. The reviewer opens every content page on it, not only the pages the author mentions; index files are listed but not reviewed. An input the renderer could not place is shown as not known, never as no change. Review committee opens both URLs side by side: - Main site: <pages-url>/ (current published state) - Staging: <pages-url>/STAGING/<branch-slug>/ The staging banner shows the commit SHA so they can verify what they are reviewing matches the PR. A changed figure, diagram or table is also pictured before and after on the review page, with the share of changed pixels in words (skill visual-diff, Tool folio-block-screenshots). Anything the staging job cannot picture (page chrome, scroll behaviour, a PDF page, an IG page) is in the agent's before/after preview (skill before-after-preview).
- Compare what the processes need with what is granted candidate, extracted
-
The needed set is the agent-permissions skill's list (write generated projections: CI only, never the agent; edit hooks or settings; run the gates; push a feature branch; open a PR), scoped to what this instance's processes actually call. The granted set is the recorded grants plus the Tool's current config, read through its adapter. A config rule with no recorded grant is reported as unrecorded, not treated as granted.
- Complete (no unchecked todos left) candidate, extracted
-
Only once nothing is unchecked, and with a summary of what changed. The engine's
resolvecompletes a bean only after the instance itself has completed — whether work is done is a judgement, and a bean is not closed on someone else's say-so. - Compose the message candidate, extracted
-
Five required strings — timestamp, actor, process, task, message — and one optional markdown body. The five are required because each answers a question a reader of the log will otherwise have to guess, and a guessed answer in a log is worse than a missing one.
- Confirm all criteria met candidate, extracted
-
The business analyst confirms every acceptance criterion from the requirements is met. The issue closes only on their authorisation — an agent never closes an issue on its own say-so. Since issue #2405 (FR-013) it IS an adjudication with the requirement-set answers: an approval here moves the set to
accepted, whichcheck:requirementsrefuses unless it is a human's and every approved member isin-force. - Confirm main's CI on the merge commit candidate, extracted
-
Read the runs on the merge commit. Red is fixed forward (continual-progress). With no CI the report reads "not verified: no CI", never green.
- Confirm needs statement candidate, extracted
-
Stakeholders confirm, on the issue, that the needs statement says what they need — or say what to change. A stakeholder's judgement; an agent does not record it for them.
- Confirm the cardinalities candidate, extracted
-
An operational question, asked of the people who run the process because they know where the exceptions are.
- Confirm the entities are the ones meant candidate, extracted
-
A naming question. The BA owns the domain vocabulary; the agent does not guess, which is CRDM's own rule for phase 1 and applies here with more force.
- Consolidate findings candidate, extracted
-
One report from however many subprocesses ran. Findings are advice: a reviewer cannot accept the change.
- Consolidate into 2-4 themes, with a recommendation each candidate, extracted
-
Group by what the work delivers, not by agent. Each theme gets its epic, members, dependencies, risk, and one of: continue, fold in, new epic, park, scrap (owner only).
-
The asset carries no description.
- COPYRIGHT per bitstream, and for the derived work candidate, extracted
-
What the licence permits for THIS bitstream, and separately whether it permits the derivation. LICENSE-CONTENT.md exists in this repository and the ingestion pipeline does not read it.
- Create feature branch candidate, extracted
-
Agent creates a feature branch from main. Branch naming: feature/<short-description> Opens a PR immediately (AGENTS.md: "open the PR at the first commit").
- Create the bean (agent CLI, not an engine op) candidate, extracted
-
beans create "<title>". This is the AGENT's call. The workflow engine has nocreateop — its vocabulary is claim, note and resolve, all of which act on an instance's existing bean. - Create the repositories candidate, extracted
-
The owner creates the content and tools repositories and their Pages. Nothing is committed to them before this.
- Create the repository candidate, extracted
-
Only on the new-repo branch, and only after the user has named it. An empty working directory is scaffolded in place instead.
- Cross the axes into SO, WO, ST, WT candidate, extracted
-
The TOWS matching step, and the only step that produces anything actionable. Strengths and weaknesses across, opportunities and threats down, and each cell names the strategy the pairing implies: SO — achieve opportunities that greatly match the strengths; WO — overcome weaknesses to attain opportunities; ST — use strengths to reduce vulnerability to threats; WT — prevent weaknesses, to avoid becoming more susceptible to threats. A SWOT that stops at four lists is the failure the source names as its central one. This step is what the process exists to reach. It produces CANDIDATE strategies, not a chosen one, and they are not ranked — see the process documentation on why no scoring activity exists.
- Cut the subgraph that leaves candidate, extracted
-
Apply the editorial scope mechanically and report what it removed. A selection that reports nothing cannot be told from one that ran over an empty rule.
D
- Data model Entities + cardinalities candidate, extracted
-
Between requirements and sign-off, and the order is the argument: requirements are statements about things, and the model says what the things ARE. Drafted earlier it is invented from nothing, since the entities come from the phase-2 BPA; drafted later, sign-off approves requirements whose nouns were never pinned — which is how two stakeholders approve one sentence meaning different things. Owner, 2026-09-20.
- Decide each theme candidate, extracted
-
The asset carries no description.
- Decide what may leave the repository candidate, extracted
-
EDITORIAL, and it is stage 1 rather than a filter bolted to the exporter. kg-export produces the WHOLE graph because inspection wants the whole graph; a portal wants what its readers may see. Running the second as the first is how a QA verdict, a bean's blocking note or an unpublished draft reaches a public cache. Decided once, here, rather than at each consumer.
- Decide, weighing the recommendations candidate, extracted
-
public-comment decide, or decide: code on GitHub from a login in config.json editors. accepted, accepted-modified, not-accepted, noted, deferred; a reason for all but accepted. Also reopens a decided comment.
- Declare Distribution Manifest & Named Queries candidate, extracted
-
Write subgraph-manifest.json conforming to folio-nquads-distribution/v1. Declare datasetIri, servedRoute, spine, subgraphs, and audited named SPARQL queries with explicit requiredSubgraphs and typed parameter definitions.
- Declare the model where a tool can read it candidate, extracted
-
A model in prose is a proposal; a model in the declaration is a model. Ship a reader in the same change — everything here that was only documentation went inert within weeks.
- Declare the mount: harness, repository, pin candidate, extracted
-
An instance
{ name, source: { remote: { repository, ref } } }in the downstream's rootindex.config.json, written throughwriteDeclaredMounts. A folio with no index still readsremoteMountson its declaration; both at once is refused.refis a full 40-character commit. Overrides, if any, are keyed by instance name and then by directory id — never by path. The index itself is the index-config skill's. Decide first whether you want a remote mount at all: reading another graph without holding its code is a SUBSCRIPTION, not a mount. -
Declare the node
materializedcandidate, extracted -
The node's state moves from
referencedtomaterialized, carrying purpose, localPath, gates and (archival) fixity. There is NO default state: a node that has not said is invalid, because 'the author did not say' and 'the author said they could not tell' are different facts. - Declare the purpose: working or archival candidate, extracted
-
working or archival, and it is asked FIRST because three of the five gates mean different things under each. An archival copy keeps the original bytes, never expires, requires fixity, and is the only thing that discharges sourceLoss; a working copy keeps derived content and discharges none of that. A process that gated first and asked afterwards would be judging a copy whose obligations it did not yet know.
- Deduplicate, and keep what is actually relevant candidate, extracted
-
The paper's Refiner. Accumulates into the evidence set the report is built from — so what is dropped here is invisible downstream, which is why it is a step somebody performs rather than a filter buried in retrieval.
- Deploy the MVP to staging candidate, extracted
-
An MVP is shared AS A STAGING DEPLOY, not as a description of one.
feature-staging.ymlpublishes the branch underSTAGING/<branch-slug>/on gh-pages and comments the URL on the PR, so the stakeholder who tests it is looking at the built artefact rather than at a screenshot — the same argument the merge discipline makes about rendered work. Measured in this repo on 2026-09-16: holding a rendered change back for assessment made assessment harder, not safer. - Deploy the rendering candidate, extracted
-
Commit the staged tree onto gh-pages as a full replace (the instance's Pages workflow on a push to main, or by hand); GitHub Pages then builds it from the branch. Rebuild and retry on a rejected push; never rebase the branch. The gh-pages commit SHA is the message the report names.
- Deploy to STAGING/<slug>/ candidate, extracted
-
peaceiris/actions-gh-pages deploys to gh-pages branch under STAGING/<branch-slug>/ with keep_files: true so other staging deployments and the main site are preserved.
- Derive content from the assets [document-intake] candidate, extracted
-
See ingest-derive-content.bpmn. Most of this subprocess is not implemented yet.
- Derive the key [main/<sha> or pr/<n>/<sha>] candidate, extracted
-
qa:publish --githubreads the event: a push to main publishes undermain/<sha>/, a pull request underpr/<n>/<head-sha>/— the head that was tested, not the merge ref. It also reads whether the token can write, which the gateway after it routes on. - Derive the slug from the head ref candidate, extracted
-
Derive the slug from the PR's head ref: every character outside [a-zA-Z0-9._-] becomes '-', runs of '-' collapse, and leading or trailing '-' is trimmed. It must be one safe path segment, checked by value.
- Describe the desired change candidate, extracted
-
Author describes the content change in natural language. Example: "Update the immunization schedule to add a booster at 18 months."
- Describe the intended change candidate, extracted
-
The editor states the change in natural language; no content has moved yet.
- Describe the need (chat, issue, discussion) candidate, extracted
-
The BA describes the capability gap in their own words. They do not need to know it is called CRDM.
- Detect change scope & impact candidate, extracted
-
Agent analyses the requested change: - Which content blocks are affected? - Are there downstream implications (indicators, referral logic, visit schedules)? - Will deterministic logic (CQL/DMN) need updating? skill: content-graph, integration-watcher
- Detect feature request (crdm-detect skill) candidate, extracted
-
Recognise the request as a platform capability change rather than content work, from crdm-detect's signals. Never call it "CRDM" to the person. Mid-content-work, ask whether to pause for requirements now or record a bean for later — do not switch on your own.
- Detect media type and mint a doc id [document-intake] candidate, extracted
-
Sniff the media type rather than trusting the extension, and mint the doc id from the page-1 arXiv stamp where there is one, else from the filename.
- Detect the interaction modality candidate, extracted
-
Before the first question is asked, establish HOW to ask it: audio, ordinary chat, selectable options for a user with limited hand function, large-type for low vision. A user who finds the questions unusable never reaches the rest of this diagram.
- Determine the context: what is known, and already decided candidate, extracted
-
Before composing anything: what is already known, each fact with where it came from; which declaration governs the matter (the instance's
<name>.json, the diagram the caller is in, the Skill its task names); what state is recorded; and whether the question has ALREADY been decided — by the person earlier in the conversation, or in a declaration that quotes their ruling. A settled question is not asked again: asking it reopens a decision and spends the person's attention twice. Read it, do not remember it: cite what you read. What the caller handed in is checked here, not re-derived. - Determine the process and task, or that you are idle candidate, extracted
-
Name the Process, the lane and the task the question belongs to, and say so in the message: "Process: Initialize a harness, at Determine the harness and repositories, as the Bootstrapping Agent". A reader who does not know which process you are in will assume the last one's rules still hold. If you are in no Process, that is an answer too: you are IDLE, and what you are doing is classifying a request to find the Process it belongs to — say that, rather than presenting a question as though a step had asked for it. You are OUT of process, and it is undetermined, when you cannot name the instance, when two candidates fit, when the step you believed was next is not the one the diagram enables, or when the work in hand was not what you said you would do. Do not infer your way back in.
- Determine the roles: which you act as, and the person's candidate, extracted
-
An Actor performs a task in a Process AS a Role. Nothing is a Role by nature: the same agent is the Bootstrapping Agent in one diagram and another Role in the next, and which one it is depends on the lane of the task it is performing now. So say which Role you are acting as — the lane of the CALLING task, since this lane is variable — and which Role the person you ask holds (the Requestor, or whoever the calling lane names). It decides what you may ask them for: only the Requestor chooses a harness, and a question put to somebody who does not hold the decision gets an answer that settles nothing.
- Determine where you are: process, roles, context candidate, extracted
-
Before narrowing, say where this is happening, in the words you will use in the question. PROCESS: Initialize a harness, at its first step, inside Determine the harness and repositories — the only place a Bootstrapping Agent can be (FR-2). If you cannot say that (you were started some other way, or a step you believed done is not), you are out of process: do not infer your way back in. ROLES: you act as the Bootstrapping Agent because you were told so; the person you will ask is the Requestor — the one who asked for the harness, and the only one who may choose it. A request relayed by somebody else leaves the Requestor undetermined. CONTEXT: what the request said, and what the checkout holds — a declaration at its root, a harness named in the request. Whatever cannot be determined is handed to the called discussion as undetermined, and asked about first; it is never filled with a default.
- Determine which harness, and where candidate, extracted
-
The candidates are listed and the Requestor is asked, in
discussion, which asks throughhuman-agent-discussion. IN: nothing but the context this agent was handed. OUT: zero or ONE harness, and the locations — a document conforming todiscussion.output.schema.json. One at most: a list of two is not an answer, and the Bootstrapping Agent may not break the tie itself. - Discard all entries, or a whole session candidate, extracted
-
Remove every entry, one session's, or those before a date — emptyLog with { all }, { session } or { before }; there is no default selector. A file that will not parse is kept, and the result must say what was refused and why, not only what was removed.
- Discard one entry by id candidate, extracted
-
Remove one entry by its stable id, with emptyLog({ id }). Logs are the one exception to the never-delete rule because an entry records no decision; the exception covers files that declare folio-log/v1, not the directory.
- Dispatch one agent, recorded on the bean candidate, extracted
-
Before the agent starts: the date, why the fail condition fired, the agent's id, its budget. Never while the first writer may still be live. Two failed attempts with the same cause go to the owner instead.
- Dispatch with adjudicator_sees — never the artefact candidate, extracted
-
UntaintedDispatchon the criterion declares what each party is given; the caller names a subject and a criterion and does not hand-assemble a brief, because the party composing a brief by hand is the producer.untaintedPartitionDefectsreportsoverlapwhen the checker and the adjudicator can read the same file — one of them is then grading its own input, and the verdict measures nothing while raising no error. - Do it, then check again candidate, extracted
-
Only what the agent, or a tool it has, can do without replacing anything somebody wrote: regenerate a README section, add a missing Pages workflow, switch Pages on with an authenticated
gh. Performing is not the same as done: the flow goes back to the check, and only the check says done. - Do the work candidate, extracted
-
The task itself. This diagram says nothing about how it is done; it only brackets it, so that a reader of the log can tell where one run of work began and ended.
- Draft the block edit [content-author] candidate, extracted
-
The authoring agent produces a PROPOSED change. Nothing is written to the corpus yet. For a rendered change it also produces the before/after preview (skill before-after-preview) here, before Gateway_ValidationFork, so the preview exists when the parallel review starts.
- Draft, review and publish [content-publish] candidate, extracted
-
See draft-to-publication.bpmn.
- Drain: land, close or re-target the open PRs candidate, extracted
-
Work the PRs
seed:readynamed until the source settles: land or close the heavy movers and the next layer's PRs, bring the layer's open PRs to five or fewer, and finish any move in flight. Fix a red rehearsal or a discovery miss where it is. Nothing is seeded from here; it goes back to the gateway, which re-asks. - Drain: land, close or re-target the open PRs candidate, extracted
-
Work the pull requests seed:ready named until the source settles, then ask again.
- Drop its positions and sweep orphans candidate, extracted
-
Only after the content has moved: drop its positions from the layout layer and sweep any position whose note is now gone. Sweeping first would make the board authoritative over the folio for one step.
- Drop the file in the queue candidate, extracted
-
Through the forge's upload form, a commit, or any other route that lands the file in the declared queue. The agent watches rather than chases: an arrival may be minutes or days away.
E
- Edit deterministic logic (if needed) candidate, extracted
-
If the content change affects decision logic, indicators, or workflows: - Update CQL expressions - Update DMN decision tables - Adjust indicator definitions skill: dak-authoring, fhir-pipeline
- Edit it in place — it is your own content candidate, extracted
-
The ordinary path, drawn so the process does not read as though every edit needs a copy. Content in a writable directory is authored content and is edited where it lives; the copy-out is for somebody else's bytes, not for yours.
- Edit narrative content blocks candidate, extracted
-
Agent modifies the relevant content blocks (.md files, block manifests). Validates each edit against the schema (content_validate). skill: content editing, block builders
-
public-comment edit --branch: the author (human, or an agent in the author role) edits the folio's blocks as the decision says, on a feature branch for one change-set. Its PR says Closes #N for the change-set issue, and opening it moves that issue's accepted comments to editing.
- Edit the flagged passage and re-inject candidate, extracted
-
The reviewer corrects the passage in the PO rather than sending the whole translation back. Flows to Task_PoInject, so the round-trip QA runs again over the corrected text — "edit the translation and re-run QA", which is what the adjudication step has always offered and what this process could not do. A userTask, not a service task: this is the one step here where a person edits content, and the lane's actor is the reviewer who just adjudicated.
- Editing and HCI validation [content-author] candidate, extracted
-
See editing-hci-validation.bpmn. Runs once per proposed change, not once per cycle.
- Editing and HCI validation [content-author] candidate, extracted
-
The editing sub-process. Every change to the corpus goes through its HCI validation gate — a red draft is fixed there, never by patching the built artifact.
- Eject the culprit, record why candidate, extracted
-
T1 (R3; SQ19 §2.2 p. 3): the culprit leaves, the rest re-run. Writes
ejectionon its queue entry (train id, reason, evidence URL, when) and a dated evidence snapshot on this instance. The train is never rejected whole for one member. - End-to-end + accessibility (HARD) candidate, extracted
-
Install Chromium, check the rendered BPMN SVGs are current, then run the Playwright suite, which includes the accessibility checks. Hard: a failure blocks the PR. SHARDED since bean
dlqu(drawn as one task, deliberately: a multi-instance marker would add a BPMN term to every instance's UML overview, about 75 generated files, for a picture this sentence already gives): the suite runs as threee2e-shardjobs (E2E_SHARD=i/3, one Playwright worker per core in each), and each shard is its own required check, so a shard that failed, was cancelled or never ran is a red check of its own. Until bean5p4m(issue #2456) ane2ejob carried one check name for the three and completed the task only when every instance succeeded; it was ~1 s of work behind a runner request that waited minutes, and was removed. Measured before the split:playwright testalone was 4m33s of a 5m16s job, the workflow's slowest oncebun testran in parallel. The BPMN-render and.bat-wrapper checks run in shard 1 only, so they are asked once. - Ensure the publication-manager label candidate, extracted
-
The alert is a tracking issue labelled
publication-manager— the role, not a person, because no actor declares a GitHub account for it. Whoever watches that label is alerted. - Ensure the tracking label exists candidate, extracted
-
Create the ci-health label with --force so it exists before either issue path runs — the close path filters on it too, and on a repository that has never had a finding it would not exist yet. Skipped on an unknown verdict.
- Ensure the tracking label exists candidate, extracted
-
Create the pr-no-checks label with --force so it exists before either issue path runs — the close path filters on it too, and on a repository that has never had a finding it would not exist yet. Skipped on an unknown verdict.
- Ensure the tracking label exists candidate, extracted
-
Create the repo-health label with --force so it exists before either issue path runs — the close path filters on it too, and on a repository that has never had a finding it would not exist yet. Skipped on an unknown verdict.
- ENUMERATE + SUBSET against the source descriptor candidate, extracted
-
Resolve the request against the source's descriptor (one per corpus, in the declared sources/ of the instance that owns it, e.g. who-iris/sources/), read against cat-harness/schemas/source-descriptor.ts BEFORE any gate. Three things come from it and none may be guessed. (1) Which subset strategies the source supports — supportsSubset(). (2) Whether a subset stands on its own: when subsetIsSelfContained is false (mathlib), the request is closed over its dependencies here, and every gate after this one is asked about the CLOSURE, because a subset that omits what its members depend on is not a smaller corpus, it is one that does not build. (3) What enumerating the whole costs — enumerationCost(), which is undefined when the descriptor has no measured denominator; SIZE then refuses rather than estimates. A source with no descriptor is not an error here: it is an unknown, and SIZE refuses on it. Bean w5bn: the descriptor is CALLED here rather than restated.
- Establish origin and licence candidate, extracted
-
Authors, publication, identifier, and the licence the source itself states. No stated licence means reference only: headings, page ranges and a summary in our own words; the file stays in uploads/ (git-ignored) pinned by checksum. A method with no origin is a house process; write a skill instead.
- Establish the licence from the upload alone [document-intake] candidate, extracted
-
EARLY, by the owner's ruling on bean 7bg9 (2026-09-20): before any derivation, because library/ is holds: content and anything derived first is committed, so refusing it later is a deletion nobody may take unasked. This step sees only the upload itself — the licence recorded in its intake.json (the same stated / unknown record a library manifest carries) and whether a LICENSE file sits beside it. It never infers a licence from extracted text. The verdict is stated, unknown, or UNDETERMINED, and undetermined is never reported as cleared: the pipeline proceeds and says so, because a licence that only extraction can reveal is a later check's to find.
- Establish who is acting candidate, extracted
-
The first step and not a formality:
actoris the one field of the record that nothing else can supply. Every other field is recoverable by reading the repository; who is acting is not. - Every identifier dereferences candidate, extracted
-
After the release is live, every published identifier resolves to the file it names.
- Every skill and tool used becomes a Tool candidate, extracted
-
Each script, CLI or checker the process relies on gets a Tool node in cat-harness/tools/index.ts that satisfies a named skill, validated by folio-assistant's ToolDefinitionSchema.
- Execute every case, or skip it with a reason candidate, extracted
-
Every case in dependency order. A case is executed or explicitly
skippedwith its reason; a case that simply has no verdict is a finding, because it cannot be told from a case nobody ran. - Explain each missing permission, with the exact config diff candidate, extracted
-
Per permission: what it allows the agent to do without asking, why a process here needs it, the narrowest form that would do, and the exact change to the Tool's config. Context, options, recommendation, question (interaction-modality §4.1). Least privilege is the recommendation unless there is a measured reason for more.
- Export the knowledge graph and its schema candidate, extracted
-
Export the knowledge graph and its schema into the published tree, then check every maintained artefact is present and no block-level markup escaped. The unpublished graph typologies are stripped on export.
- Extract & Skolemize RDF Dataset candidate, extracted
-
Extract the target RDF triples and ensure strict upstream skolemization: transform every blank node into a deterministic IRI under the dataset namespace. Zero blank nodes allowed in serialized N-Quads.
- Extract claim candidates candidate, extracted
-
candidates.json holds extracted theorems and definitions. Proposals only -- never adjudicated verdicts.
- Extract its metadata into the KG [asset-extraction] candidate, extracted
-
THE METADATA STEP. What enters the knowledge graph is the asset's INDEX — what it is, how big, what type, when it says it was written — and, for a container, what is in it; its contents do not go in unless somebody asks, with a reason. Owner, 2026-09-20: "make sure you have zip ingestion skills to extract metadata of assets into KG. don't extract contents unless explict ask by user." The tool is
cat-harness-tools/scripts/extract-assets.ts, writing afolio-extraction/v1record (schemas/extraction.ts, moved down to this layer in placement PR5). The media type is sniffed from the leading bytes, never taken from the extension. - Extract POT (translatable strings) candidate, extracted
-
Pre-processes source markdown: 1. Segments prose by paragraph 2. Shields non-translatable content (math, code, labels) as placeholders 3. Normalizes whitespace 4. Extracts metadata (titles, alt text, captions) Produces .pot file(s) at the configured granularity. Tool: translation_extract MCP tool
- Extract structure [document-intake] candidate, extracted
-
See ingest-extract-structure.bpmn.
- Extract the text layer candidate, extracted
-
The document has a text layer: extract it with pdf-extract (pdfminer.six, then a zero-dependency content-stream reader). Exit 2 means no text layer — a scan — and routes to OCR; it is not an empty document.
- Extract translatable strings (POT generation) candidate, extracted
-
Scans content nodes and extracts translatable strings to .pot files. Excludes math, labels, code, and Lean companions. Tool: translation_extract MCP tool or bun run content/pipeline/pot-extract.ts
F
- Feature sign-off on issue candidate, extracted
-
Stakeholders sign off on the delivered feature on the issue, having tested the built artefact rather than a description of it.
- Fetch & Ingest Missing Subgraphs (.nq.gz) candidate, extracted
-
Fetch missing partition payloads over HTTP (servedRoute) or local files, decompress gzip streams, and ingest quads directly into store.
- Fetch the root declaration at the pin, and validate it candidate, extracted
-
A sparse, shallow fetch of the substrate's root declaration only. Two questions: does it parse as bootstrap's KnowledgeGraphDeclarationSchema, and does it declare at least one harness?
could not fetchis a third answer and is never read asconforms. - Fetch, and record fixity candidate, extracted
-
Fetch, then record sha256 and byte count. Fixity is REQUIRED for an archival copy: an archive that cannot demonstrate it is unchanged is a copy, and it cannot be re-fetched to check, because the thing it would be re-fetched from is what it exists to survive. The data already exists — every structure.json carries sha256 and bytes, and nothing reads them as fixity.
- File feedback as beans [todo-manager] candidate, extracted
-
Triaged feedback re-enters the work plan as beans, which is how the next cycle knows what it is for.
- File info, sizes, hashes, timestamps, mimetype candidate, extracted
-
NOT IMPLEMENTED. Tracked as a bean; see docs/document-ingestion.md. Mechanical and cheap; the checksum is what makes a remote asset verifiable.
- File the signed certification [qa-attestations/v1] candidate, extracted
-
The signed certification goes under the declared
attestationsgraph on main (owner ruling D2 (a), D5 default), pointing at the report it certifies. The bean resolves here, once the process has actually finished. - Filter the corpus, choose the granularity, decompose the question candidate, extracted
-
The paper's Planner. Three outputs, and the middle one is the method's substance: a filtered document subset, the granularity to search at, and the sub-questions. CHOOSING THE GRANULARITY PER QUESTION is the whole point of parsing at several. A broad question is answered from summaries and a specific one from chunks; a pipeline that picks once has answered every future question the same way. This checkout cannot yet offer the choice —
l1-blocks.tsproduces blocks, there is no summary level — so this step SAYS which granularity it searched rather than implying the corpus offered alternatives. Re-entered on every iteration, not only the first: the sub-questions are re-derived from what has been found so far, which is what makes the loop a search rather than a retry. - Find members with no CI on their head [pr-checks-present] candidate, extracted
-
GitHub runs no
pull_requestCI while a PR conflicts, so a member can arrive with nothing on its head (beanu7beitem 3). That member is T2's first suspect if the train goes red. - Find the footprint candidate, extracted
-
handover notes (beans/notes, title 'handover:'), open PRs and branches by session or time window, in-progress beans, workflow instances, last PR and issue comments. REST, one batched pass.
-
Classify what exists into one value:
explicit(the owner's own words naming this merge, given against this head),waiver(a validmemory/waivers/node with gate merge-to-main, in scope and unexpired),instruction-only(a broad instruction about the work, such as "fix all issues until green" or "ship it", which is not an authorisation),none, orunknown(waivers unreadable or malformed). A sibling agent's message is never the owner's consent. - Fix the PR, report on the PR candidate, extracted
-
Claims the refusal bean, brings main in with
merge:main, settles what it refused, pushes. Completed with the outcomefail conditionby the steward when the condition fires first. - Fix the PR, then re-signal ready candidate, extracted
-
On the sibling's own branch: merge main in, fix, push, and re-mark ready (
ready: <head sha>). It re-enters the queue as a new placement; the ejection stays on its entry until a later train lands it. - Follow it, and say that you did candidate, extracted
-
A stated step — a harness's own
docs/bootstrap/initialization.md. Read it and do what it says. It staysstatedin the record: nothing can observe that it was followed, and the record does not pretend otherwise. - Follow them, at each location candidate, extracted
-
The instructions belong to the harness being installed, not to bootstrap — bootstrap does not know what any Harness above it requires, and does not need to.
- Follow up, narrower candidate, extracted
-
The answer did not settle it: it named a kind rather than an option, or chose two. Ask once more, narrower, naming what the first answer left open. Once: an agent that keeps asking has stopped narrowing.
- Format Universal Result Response Envelope candidate, extracted
-
Serialize query results into NamedQueryResponseSchema envelope: queryId, executionTimeMs, rowCount, bindings (for SELECT), boolean (for ASK), or quads (for CONSTRUCT).
- Frame the decision and check the trigger candidate, extracted
-
One sentence naming the KIND of thing being chosen, not the options — "which cache strategy", never "A or B". Then the trigger: is this irreversible, or would the answer surprise someone? If neither, say so and stop; the calling step decides without this subprocess. Stopping here is a correct outcome, not a skipped step.
- Frame the question as PICO [content-author] candidate, extracted
-
Population, Intervention, Comparator, Outcome. The PICO is what makes the search reproducible and the evidence auditable: without it, 'we looked for evidence' is not a claim anyone can check. WHO guideline development states the question this way before any retrieval.
G
- Gate every slice: slice:sqlite:check candidate, extracted
-
For every slice: build twice and require one sha256; read the row digest back from the file and require it to equal the digest computed from the source without SQLite; run an FTS5 phrase query for a known row; and audit the payloads with
auditPayloadTree(deploy payloads as written, the kg slice's pointers against the committed payload tree). A slice whose rows do not match its source fails; it never passes as whole. - Gather and verify the evidence [evidence-retrieval] candidate, extracted
-
Before anything is drafted: the author reads the guidance ALREADY in this content, frames the question as PICO, retrieves candidates across the three evidence classes, and has each candidate's authority resolved against its publisher's own API. A recommendation reaches the drafting step with its evidence attached, or with the gap recorded. This step has nothing to do for content that carries no recommendations -- a mathematics folio has none -- and is skipped there rather than satisfied vacuously.
- Give a link, a description, or neither candidate, extracted
-
"Or neither" is a real outcome, not a failure. The ask says what happens if nothing comes, and then that happens — the work proceeds without the resource and says so.
- Grant a dispensation, with its reason candidate, extracted
-
The rule applies and this subject is a stated exception. A
kind: "human"entry withresult: "pass"overrides the script'sfailfor that criterion, and ONLY while itsfield_hashmatches the current source — so the dispensation is scoped to the version it was granted against, lapses when the block changes, and never becomes precedent. There is nothing to overturn later; the source moving overturns it. A dispensation with nonotesis not a dispensation. It is an override somebody applied to get to green, and nobody can review it afterwards — which is why this step is not relaxable. - Grant or revoke a permission candidate, extracted
-
A permission travels with the PARTICIPANT and cross-cuts every lane, so unlike a role it cannot be scoped by the diagram it is used in. Granting one is a standing decision, which is why this lane is person-only and why the log capture on this process is on.
- Grant, narrow or refuse each candidate, extracted
-
The owner's answer, per permission, in their own words. Quoted verbatim in the record.
H
- Hand back, with a fail condition candidate, extracted
-
The
agent-handoffformat (#1884): Roles, Report to (the PR), Done when, Fails if. The fail condition: nostartedline within 4 h, no push within 24 h, the session gone, orblockedon something it cannot settle. One line to the session; the instructions are in the bean. - Hand it back [merge-refusal] candidate, extracted
-
Red CI, a conflict or a blocking review is the PR owner's to fix, not the merger's:
merge-refusal.bpmnrecords the reason on the bean and returns the PR. The merger does not fix the PR to make it pass. - Hand it back [merge-refusal] candidate, extracted
-
merge-refusal.bpmn(PR #1888, beanzacz): a bean under the right epic, a hand-back to the owning session with a fail condition (agent-handoff, #1884), or a dispatch when nobody owns it. R4: the PR returns with its reason. - Hand over the live link candidate, extracted
-
Confirmed live. The link is given as a link, and the author is told what is on it.
- Hand the candidates to a decision methodology candidate, extracted
-
The candidate strategies go to
options-analysis, which selects the decision methodology by context and applies it. SWOT does not make that selection and does not make the decision. What is handed over includes the ambiguities from A_RecordAmbiguous and the fact that the candidates are UNRANKED. A receiving methodology that assumed an ordered list would be reading a priority SWOT never established. - Hand the culprit back [merge-refusal] candidate, extracted
-
The same hand-back as a refused placement (#1888), carrying the ejection's evidence (R4). Then the train re-runs without it.
- Human / SME review [content-review] candidate, extracted
-
Escalated to a human reviewer or subject-matter expert when the change turns on clinical or scientific judgement. A rendered change reaches the reviewer with its before/after preview (skill before-after-preview).
- Human eyes on the rendered artefact candidate, extracted
-
Bean xies, gate 3, and the one that is easy to drop because gate 2 (merge to main) looks like an approval. It is not: merging approves the CHANGE, and this approves what a reader will actually see. continual-progress measured why a description cannot stand in for it (PR #178, 2026-09-16).
I
- Identify content and target locale candidate, extracted
-
The coordinator selects: - Which content nodes need translation (block, section, chapter, or folio) - The target locale (one of the supportedLocales in <name>.config.json) - The priority and deadline
- Identify entities from the BPA and requirements candidate, extracted
-
Every verb in the BPA whose object is a candidate entity, and every noun in a requirement. An entity with no identifier is an attribute of something else — that test is decisive and belongs to the technique skill.
- Identify the agent Tool(s) acting here candidate, extracted
-
Which coding-agent Tool is running this session, and which others the instance is configured for (each has its own config files: AGENTS.md is read by many; Claude Code, Gemini CLI, Cursor, Copilot and Codex each add their own). The Tool's adapter says where its permissions live and how a rule is written. A Tool with no adapter is reported, and its permissions are left to the person.
- Impact analysis what of ours binds it candidate, extracted
-
The half a changelog cannot supply, because upstream does not know what you reached into. Worked from the row's
bindslist inupstream-pins.json. For the theme:site-chrome/assets/js/docs-ui.jsMOVES the theme's own search markup into the action launcher and binds.search,#search-inputand.search-label;docs-ui.cssoverrides.side-bar,.site-headerand.main-header; three e2e specs assert the structure the theme emits. An upstream rename of any of those is not a build failure — it is a shipped feature that quietly stops working. - Import hygiene (HARD) and advisories (WARN-ONLY) candidate, extracted
-
FOUR QUESTIONS, ONE RUNNER — bean
7fu5. They were four jobs (lean-bare-import,python-imports,rust-wildcard,dependency-advisories), each about a second of work behind a ~13 s checkout and a runner request; measured onmainrun 37133247484 (2026-10-03), the run took 21.7 min while its longest job executed for 174 s, the rest waiting for runners. Now they are steps of thehygienejob, and every step after the first gate runsif: !cancelled(), so a red one masks none of the others — theom30rule kept inside one job rather than by splitting it. (1) Lean, HARD: fail on any bareimport Mathlibin content/**/*.lean; in this platform repo there is no content/, so the step prints SKIP and states that nothing was scanned. (2) Python, HARD: ruff F401 (unused) and F403 (wildcard) over the Python trees that exist, then the Python tests; an absent tree is dropped rather than passed to ruff, and an empty set says SKIP. (3) Dependency advisories, WARN-ONLY by the owner's ruling on beanj41m: is anything in the resolved tree KNOWN-VULNERABLE? The script exits 0 in every state and keeps them apart in its output;.github/dependabot.ymlis the other half of that ruling and is not drawn here. (4) Rust wildcard imports, WARN-ONLY: report non-testuse …::*;in tools/**/*.rs;continue-on-error, and therefore the job's LAST step, where it masks nothing. - Import into the store, and test the import candidate, extracted
-
The part only this process does. Load the landed sample into the chosen store and check what an import can get wrong: every item arrived (count against the request), identifiers survived (the descriptor's authoritative ones), structure validates against the store's schema, and provenance (source, revision, fixity) is attached to each node. A check that could not run is a failure, not a pass.
- Import what, where, and who does it candidate, extracted
-
Three questions the scan cannot answer: import these or not; library or content for each group; leave the files where they are or reorganize to declutter. Plus whether to dispatch one ingestion agent or a small swarm. Non-relaxable: nobody's files are moved or imported on inference.
- Ingest and place each comment candidate, extracted
-
public-comment import / import-narrative: one record per row or cited passage, anchored through review-anchors.json. Status: received.
- Ingest into library/ candidate, extracted
-
The harness's basic ingestion flow (
document-ingestion.bpmn,Process_Ingestion): the source is accepted, its metadata goes into the KG, and it is catalogued in library/ — held if materialized, recorded as referenced if not. Since placement PR6 (beanapcg) the flow makes no content-type decision: reading a document into sections and blocks — choosing the rung mechanically (embedded outline, pages, OCR), and writing section text only when the licence allows it — is a refinement in the layer above, which calls this same flow first. - Ingest tagged review comments [folio-review-comments] candidate, extracted
-
Every PR conversation comment that starts with
block: <label>becomes areview-comment/1.0.0todo (open), idempotently, and is published with the preview asreview-comments.json. The staging workflow runs this on every push and on every tagged comment; the coordinator owns that it has run before slicing, because the slices are cut around what reviewers have already said. This is theingesttransition of REVIEW_TRANSITIONS. - Ingest the theme [theme-art-intake] candidate, extracted
-
See ingest-theme.bpmn. The subprocess derives one Theme node with kind sticky|webpage|publication, and refuses a source it cannot complete rather than emitting a partial theme.
- Inject PO → translated Markdown candidate, extracted
-
Post-processes the completed .po file: 1. Substitutes msgstr for msgid in source markdown 2. Unshields placeholder tokens back to original content 3. Validates structural integrity (paragraph count, heading levels) 4. Validates completeness (flags empty msgstr) 5. Runs linting (doubled punctuation, orphaned placeholders) Tool: translation_inject MCP tool
- Inject translations (PO → Markdown) candidate, extracted
-
Reads .po file and source .md, substitutes msgstr for msgid, preserves non-translatable elements, writes translated .md to translations/<locale>/block.md. Tool: translation_inject MCP tool or bun run content/pipeline/po-inject.ts
- Instantiate the harness: write its config candidate, extracted
-
Write
<harness>.config.jsonat the repository root, plus the state directories the harness declares, and — where the checkout has a rootindex.config.json— add the harness to itsinstances[](kg:instantiate does both), because the index, not the file, is then what reads as INSTANTIATED (index-config skill); a root config the index does not list fails check:landing-instance. That instantiation is what puts the harness in the navbar's bottom region. check:instance-render must be green on the result; a config that renders nothing is an entry pointing nowhere. - Integrate: call existing processes candidate, extracted
-
The method's steps become a process whose judgement points call the processes that already exist (adjudication, options analysis, review) by calledElement. Nothing is re-implemented. A needed change to an existing process becomes a bean against its owner.
- Integration test and QA sweep [content-test] candidate, extracted
-
Corpus-wide checks that a single-block gate cannot make: cross-references, build green, proof status, QA axes across the whole folio.
- Inventory the ingested assets candidate, extracted
-
Which graphical assets arrived, for which surfaces of the website or app design, in which locales, and at which VIEWPORTS: every surface at a web width and at a mobile width (owner, 2026-09-23, issue #1023). Read off the ingested artefacts rather than off the intent — a layout the source declares but does not supply is not in the inventory, and a surface the design needs but no asset covers is the one that would ship wrong.
- Is every derived artefact present? candidate, extracted
-
L1 source to L1 KG is NOT complete while a required derived artefact is missing. This is the gate that makes the derivation steps obligatory rather than aspirational.
- Iterate on author feedback candidate, extracted
-
Agent receives revision requests from the author and applies changes. Each push triggers a new staging deployment with updated SHA stamp. A revision push does not pass through Task_CommitPush, so for a rendered change the agent refreshes the before/after preview here (skill before-after-preview), and the next review round never reads a stale one.
J
- Judge the assets in their design candidate, extracted
-
A person looks at the ingested assets laid out in the design they are for, at BOTH a web and a mobile width. THIS IS A HUMAN STEP INSIDE INGESTION, and that is stated rather than hidden:
ingest-theme.bpmnused to refuse to call this process for exactly that reason. The owner's ruling puts theme review at ingestion only, and a ruling that moves a review does not remove the person who performs it — so ingestion of a THEME SOURCE is attended at this step, while ingestion of everything else stays unattended becauseGateway_ThemeSourceroutes it past. A judgement made at one viewport is incomplete, not passed, and the wireframe of the surface (wireframe-design-review) says what each layout was meant to be. Three defects in the landing board — a selector matching nothing, a crop cutting the subject, a fade wrong in both directions — were invisible to a clean build, a passing suite and every gate, and were found only by rendering the page and looking.
K
- Keep it as a trial: the unpublished trashcan candidate, extracted
-
A trial goes to the kept trashcan: addressable, exported, never published. Its node declares
$schema: folio-fsh-guts/v1and carries the bean or issue it was written under, since it was never moved from anywhere and amovedFromwould be invented provenance. It is NOT refreshed: a trial records what the source looked like when it was tried. Promoting a trial means running this process again with permanent = yes, so the gates are asked afresh. - Keep the local edit, and re-pin so it stops being asked candidate, extracted
-
The local edit wins, so nothing is re-materialized — and the pin moves to the upstream revision that was compared against. Re-pinning is the half that is easy to forget and is the reason this is a step rather than an absence: without it the same upstream change is detected as new on every cycle, and a contributor is asked the same settled question for ever. The record says the copy is deliberately divergent FROM a named revision, which is a different claim from being stale against an unknown one.
L
- L1 completeness gate candidate, extracted
-
See ingest-l1-completeness-gate.bpmn. Skill-backed by
l1-document-ingestion(2026-09-30, bean 7bg9; the section moved there from the harness'slibrary-ingestionin placement PR6): its section "What a complete L1 entry holds" namescheck:l1-completeas the gate and states its three results. Until then this step namedpaper-relevance-triage, which never existed, and was left uncovered rather than bound to a guess. The gate contains one adjudication (Task_FlagDrift:real,spuriousorsource-wrong), and its own Task_Verdict records the answer as a reason against the verdict before returning. So both answers reach this step, and nothing here branches on them; Gateway_Complete branches on the gate's completeness verdict instead. - Land each member [merge-to-main] candidate, extracted
-
Once per member, in train order, at the SHA the train's gate set tested.
merge-to-main.bpmnis where merging is a step with its own gate: it reads the head's evidence live (the train's green run is that evidence, andmerge:guardre-evaluates it), establishes that the owner authorised THIS merge (explicitly, or by a standing ruling quoted verbatim with its date, e.g. 2026-10-01 "you may merge green PRs", which covers green heads only and only the queue as it stood), records the authorisation, merges pinned to the head, and then confirmsmain, re-pins downstream mounts and notes the bean. Until 2026-10-09 this was two steps here,Task_Releasein the owner's lane bound to interaction-modality andTask_Landbound to prepare-merge; neither could refuse a merge, and neither said what happens when a repository has no CI. R1 still holds: what lands is exactly what CI tested. Ifmainmoved after the train's CI started, re-run rather than land. Each member'strainIdis cleared, and its preview is then taken down byfeature-staging.bpmn. A member the sub-process does not merge (held, refused, handed back) leaves the train with its reason on its queue entry. - Land it in library/ candidate, extracted
-
A permanent sample joins the library as an L1 source, with the materialization record (purpose, gates, fixity) beside it. From here refresh-materialized governs it.
- Land the bytes in the copier's own folio/ candidate, extracted
-
Into the copier's own declared
folio/, never a scratch area — a directory nobody declared is a directory nobody gates, and the copy would be publishable by accident. The copy is NOT read-only: it is the copier's own content, makes no claim about anybody else's bytes, and freezing it too would mean the next person needs a copy of the copy. - Land the feature's PRs [merge-to-main] candidate, extracted
-
Phase 6's "explicit confirmation before merging to main", made a step that can refuse. Once per pull request the feature still has open, after the sign-off is recorded and before the issue is closed: an issue is not closed on a feature that is not on
main.merge-to-main.bpmnreads each head's evidence live, establishes that the owner authorised THAT merge (a stakeholder sign-off or the BA's confirmation is acceptance of the feature, not authorisation to merge it, unless the owner's own words say so), records the authorisation, merges, and confirms the base. A PR the owner holds or refuses stays open, and A_Close then waits: the BA's authorisation to close does not cover a feature that did not land. An increment the owner asked to land earlier in Phase 6 went through the same sub-process at that time. - Languages: extracted, rendered, and RTL candidate, extracted
-
Every user-facing string reaches the .pot; every declared locale renders without clipping or overflow; right-to-left is laid out rather than mirrored by accident. New UI is where untranslated strings enter, because nothing was stale — there was nothing there before.
- Lay out the options, with what each costs candidate, extracted
-
Every option the agent could narrow the question to, each with what it costs and what it makes hard to undo. Narrow from context first: an option the agent could have ruled out itself wastes the reader's attention.
- Leave a reachable way back candidate, extracted
-
Leave the way back reachable: the collapsed window becomes a control in its own position and focus moves to it — left alone, focus lands on <body> and the keyboard position is lost. An action whose inverse is not reachable is not a toggle (bean l4zi).
-
Leave it
referenced, record why candidate, extracted -
A refusal is not a failure of the process — it is the process working. The node stays
referenced, which means the graph still knows it exists and where, and the refusing gate's basis is recorded so the next caller does not re-litigate it. - Leave it alone (coordinate instead) candidate, extracted
-
Never resolve, scrap or delete a bean another session or a human owns. Claiming is how two sessions avoid picking the same item; closing someone else's is how one of them loses work it had not finished reporting.
- Leave the content exactly where it is candidate, extracted
-
The reader said no: nothing moves, no position is dropped, and the board is left exactly as it was. Drawn as its own end state because a destructive action whose refusal is not drawn gets performed by accident.
- Link L1 nodes into the corpus graph candidate, extracted
-
Anything in library/ is L1 source content. A knowledge-graph reference from any artefact -- paper, L2, L3 -- resolves to it through library/.
- Link the work to an issue candidate, extracted
-
Feature work must be linked to a GitHub issue. Scan before creating, and never create one without the BA's permission — an issue is the stakeholder's record, not the agent's scratchpad.
- Link to existing issue candidate, extracted
-
A match was found: ask the person whether the requirements go on #NNN, then link the work there. The issue is where stakeholders sign off, so no phase proceeds without one.
- List the harnesses this could be candidate, extracted
-
Zero or more. The candidate everybody has is bootstrap itself. Context may name others: "please set up <owner>/<repo> here" names one, and so does any Harness built on bootstrap that the Requestor mentions. This step narrows; it does not decide.
- List the locations this could install to candidate, extracted
-
Zero or more. Is this a git repository already, or were one or more URLs to repositories supplied? Both are Knowledge Graph Data Stores; the difference is only how they are reached. A location whose root already holds a declaration,
<name>.json, is not a blank slate, and says so in the question. - List the steps the declarations name candidate, extracted
-
In the order of the table in
initialization-steps: declaration, needs, each dependency's instructions, the documents at their IRIs (checked above, and listed first), directories, assets, README, README sections, site. Each step names the declaration that names it, so a reader can see why it is there. - List upstream releases and compare to the pin candidate, extracted
-
git ls-remote --tags, filtered by the row'stagPatternand ordered by version. Nothing is cloned and no API token is needed, so the check runs the same way on a laptop and in CI. - Load the active voices candidate, extracted
-
The activated set only, never everything shipped. An id naming no shipped voice is an error rather than a skip — a folio that believes it is applying a voice and is applying nothing has the cleanest-looking output of the three.
- Log a message or an error candidate, extracted
-
Write a message or error entry whenever a later reader would need it. A command run goes in
execution(command, exit code, where output went) — never the output itself, and never a secret, token or credential: capture on puts entries in git. - Log findings on the bean [todo-manager] candidate, extracted
-
Findings are appended to the bean, so the next agent or human sees what is outstanding.
- Log task-end candidate, extracted
-
Write a task-end entry, with the outcome in the detail. The step is the unit: an entry per step, not one when the whole process finishes, or every intermediate entry is lost.
- Log task-start candidate, extracted
-
Write a task-start entry before touching anything: summary, actor, and the process/task/bean/branch/session it belongs to where they exist. role, process and task are optional on purpose — do not invent a lane for work done outside a process.
- Log the failure candidate, extracted
-
Every failure path passes through here, so "logged as failed" is a step somebody performs rather than an adjective on an end event. What differs between the ways in is the message, which is an input, not the mechanism.
- Log the start of the install candidate, extracted
-
REQUIRED logging, which is what drawing the call says. Logged before anything is written, so an install interrupted halfway is distinguishable from one never begun.
M
- Make sure every step is done candidate, extracted
-
Following a harness's instructions once is not the same as every step being done.
complete-initializationwalks the steps the declarations name — FIRST the harness's JSON Schemas and JSON-LD at the IRIs they name, the primary step of initializing a Knowledge Graph harness; then declared directories, assets, the README and its sections, and the site that carries the documents — checks each, does what can be done, asks the person for what only they can do, and reports every step in its state. An agent may be dispatched to run it on its own: it needs nothing but that diagram and the declarations. - Make sure gh-pages exists and Pages serves it candidate, extracted
-
Provisioning the target, owned by this Tool's subprocess rather than by the general step (owner, 2026-10-01: "need to create gh-pages branch before can turn on"). In order: (1) an orphan gh-pages branch exists — git ls-remote --heads origin gh-pages; if absent, push a placeholder (index.html + .nojekyll); (2) Pages is on, Source = the gh-pages branch at / — gh api -X POST repos/<o>/<r>/pages -f source[branch]=gh-pages -f source[path]=/ when gh is signed in, otherwise the exact manual step (Settings → Pages → Deploy from a branch → gh-pages, / (root)). Each half is done, not done, or could not be determined; never assumed.
- Make the change candidate, extracted
-
The loop's only open-ended step. Everything around it is procedure; this is the work.
- Map values onto the shared palette ROLES candidate, extracted
-
surface / ink / edge / accent, shared across every kind. A palette per kind would be three spellings of "accent colour", free to disagree about what an accent IS. Where the source is SILENT on a role, say so and mark the value a choice rather than dressing an invention as a measurement.
- Mark incorporated when the change set merges candidate, extracted
-
public-comment incorporate, naming the branch, PR and staging URL; done by the folio's workflow when the PR that closes a change-set issue merges. A PR closed unmerged moves nothing.
- Materialise the part [materialize-remote] candidate, extracted
-
The ONLY way bytes arrive. Purpose first, then the five gates — size, restrictions, copyright, retention, source loss — then fetch with fixity, or stay referenced with the refusing gate's basis recorded. Both ends of that subprocess return here and the walk continues: one part refused is not the subscription refused.
- Materialize remote content (the five gates) candidate, extracted
-
The shared subprocess. It resolves the request against the source descriptor, then asks size, restrictions, copyright, retention and source loss, and either fetches with fixity or leaves the content referenced. This process does not restate any of that; it waits for the outcome.
- Measure the cutover: separation:cutover:check candidate, extracted
-
Run
bun run cat separation:cutover:check --sitein the SEPARATED repository (Toolseparation-cutover-check). Six conditions, each decided by an existing gate and none assumed: every declared layer mounted at its pin; every path a declaration names resolves (check:declaration-resolution— directories, assets, visualisers, needs); no wiring still names the monorepo (livesAt, a submodule, a reusable workflow, a path into the old checkout — lessons 15 and 16); no import or reference against the layer order; and the site builds from the mounts alone. A finding inside a mounted layer is upstream's and is listed, not counted. - Measure the signals candidate, extracted
-
Files and bytes per instance, clone cost (
bun run cat health), gate time, merge contention, the candidate's cohesion and cut (kg:detangle), wrong-direction edges, and the would-be tools package's import cone. Recorded in the bean; none alone is a trigger. - Mechanical checks, both viewports candidate, extracted
-
Tool wireframe-check renders every candidate at a web and a mobile viewport. It fails on horizontal overflow at mobile width, on placeholder text, and on a missing viewport, and writes screenshots and a script entry per criterion.
- Merge each member onto the base [merge-base] candidate, extracted
-
merge-base.bpmnonce per member, in order,--no-regen; then ONEbun run cat regenover the result. Tool:merge:train. Always onto the current base, never a cached one (R5). - Merge main in, regenerate, fix mechanical gates candidate, extracted
-
Merge commits only; never a force-push.
- Merge the base in, without committing candidate, extracted
-
git merge --no-ff --no-commit origin/mainon a clean tree (untracked files refuse too, so the final stage cannot sweep in a scratch file). - Merge, hold or refuse candidate, extracted
-
The owner's answer to the question Task_Ask asked. Their words are quoted verbatim in the record, so the answer is given in the conversation or on the PR, not inferred from tone.
- Merge, on explicit confirmation candidate, extracted
-
The owner says "merge it", and only then is the branch merged. Merge to main triggers: 1. the main site rebuilds with the changes; 2. the staging preview's cleanup runs; 3. the review comments committed on the feature branch land on main, as the review record.
- Merge, pinned to the evaluated head candidate, extracted
-
Through
merge:guard <pr> --merge --session <id>where the repository has it; elsewhere with the merge call pinned to the head SHA, so GitHub refuses if the head moved. Merge commit unless the repository or owner says otherwise. Never delete the branch. - Mount each instance at its declared path candidate, extracted
-
Sparse checkout of the declaration and the chosen directories, copied to the mount path (by default the instance's home path, so relative imports and sibling discovery hold). Never onto tracked bytes; never onto a directory no lock says this mount made; never over edits to a previous mount — those are left untouched and reported.
- Mount the branch tip at the declared path candidate, extracted
-
A
branchsource keyed bytip:branch-store mount --id <dir-id>writes the tip's files at the declared path, so every reader finds the directory where it always was;pushsplices edits back onto the tip, never forcing, and a same-file race is a conflict. The branch's NAME is the declaring directory'sstorage(orsource) — a branch no declaration names is refused rather than guessed. Acommit-keyed branch is read per commit through its own store (qa-store), not mounted. - Mount the remote tree at its pin candidate, extracted
-
A
remotesource (bean0mpw): another repository's tree at a full 40-character commit.bun run cat mount:remotelays it down at the declared path and locks its tree digest; it is never written back, because the bytes are somebody else's at somebody else's pin. Usually reached through asource.remoteinstance in the rootindex.config.json(legacy:remoteMounts), which expands a whole harness and its closure —Process_MountDependency. - Move into library/<bib-slug>/ candidate, extracted
-
The folder name IS the bibliography citation key, so a citation and a directory are the same string.
- Move the entry's ref and re-cache the declaration candidate, extracted
-
Only after every held part has been through the refresh. Moving the ref first would make the records of parts not yet refreshed describe a commit the entry no longer names. The cached declaration is replaced so the review that follows shows what the NEW pin offers, including subgraphs that did not exist at the old one.
- Move the pin and open the PR candidate, extracted
-
The pin literal moves in the one file
upstream-pins.jsondeclares, and the PR body says what the version range changed in RENDERED output — the evidence, not just the verdict. - MVP: build the candidate on a staging branch candidate, extracted
-
An MVP is a DEPLOYED BUILD, not a description of one. The pin is moved on a branch and
feature-staging.ymlpublishes it underSTAGING/<branch-slug>/, so the reviewer looks at the artefact rather than at a screenshot — the same argument the merge discipline makes about rendered work.
N
- Name the subject and the level candidate, extracted
-
One sentence naming WHAT is being analysed and at WHICH level — individual, organisational, national, international. The source requires this before anything is listed: "the classification of a variable also depends on the purpose of the practice", and the criteria for assigning a variable to a quadrant "may be more difficult to clarify if the methodology is not used for a company but for a country". It also bounds the known limitation that SWOT "is rarely deployed at lower than the organization level", where one scan drives strategy for units its factors do not hold equally for. Naming the level does not remove that risk; it makes it visible in the record.
- Name the substrate, pin a full commit SHA candidate, extracted
-
owner/repoand a 40-character commit SHA — never a branch, never an abbreviated SHA. The schema refuses anything else (SubscriptionSchema.ref), and this step exists so the refusal is met while choosing rather than at commit time. A tag replaces the SHA only once the substrate publishes releases. - Name what will move, and where it lands candidate, extracted
-
Before anything moves, name the content that would move — what it is, with its size and age — and where it lands. The confirmation sits in front of the move: an agent never relocates a durable artefact on its own initiative.
- Narrative description per image, localized candidate, extracted
-
NOT IMPLEMENTED. Tracked as a bean; see docs/document-ingestion.md. Applies equally to an image EXTRACTED FROM A PDF, not only to an uploaded one.
- Narrative review candidate, extracted
-
Descend into Process_NarrativeReview. The actor takes on the
narrative-reviewerlane for this call path only. - No CI: run the repo's own gates locally candidate, extracted
-
Only on
no-ci. Run the repository's own gates (its tests, typecheck and whatever its README or package.json names) on the merge result, not the branch. Record each command, exit code and the SHA it ran on. This is evidence the owner can weigh. It is not CI, and the question to the owner says so in words. - Note the bean, summarise on the issue candidate, extracted
-
The merge SHA and the authorisation block on the bean; a round summary on the issue (issue-working). The issue is not closed here: in CRDM, crdm-close closes it after this process returns, on the BA's authorisation.
- Note the main-branch watch [watch] candidate, extracted
-
Second dispatch point: the change was approved and merged, and the root of the site has been rebuilt from main. This is the moment docs-site.yml failed all 30 times over two months (bean xom7) while looking exactly like a green run from inside the repo.
noterather thanclaim, and the difference is not cosmetic. By here the branch-watch bean already exists, and whether the publish SUCCEEDED is a judgement this step cannot make -- the build reports its own exit code, and xom7 is the record of that being believed. AGENTS.md: a bean is not closed on someone else's say-so. So the step records what it observed and leaves the verdict to the watcher.
O
- OCR to ocr/page-*.txt candidate, extracted
-
A document ingested this way keeps its text in ocr/ and only a stub in sections/, which the documented sections/ grep cannot see. That asymmetry is why the corpus-grep checklist has a fourth tier. The run also records WHICH SOFTWARE made the pages, in ocr/run-context.json: a folio-run-context/v1 (cat-harness schemas/run-context.ts, the record test runs and QA reports use for the same question), naming the OCR engine, the rasteriser and each language model with its version and the sha256 of the bytes that ran. Two OCRs of one scan can read differently ("Manual" and "Manval", bean turh), and without it neither could be told from the other or reproduced.
- Offer the knowledge-graph destinations for the agreed set candidate, extracted
-
THE STEP THAT WAS MISSING. Requirements were elicited, agreed and signed off, and then existed as an issue and a conversation — so the output of the process that exists to produce durable requirements was the one thing the knowledge graph never learned. ONE question for the SET, not one per requirement: a six-phase run can agree many, and asking six times is the same failure as a form that re-asks what it was already told. The options are DERIVED from the graphs this instance declares in
<name>.json, read at the time of asking, so an instance that adds a graph gets it in the offer without anybody editing a skill. Never a list typed from memory. - Open a bean for the unverified citation [todo-manager] candidate, extracted
-
An unresolvable citation is not dropped and not silently kept. It becomes a tracked item, so the gap is visible in the work plan rather than surviving as a footnote nobody re-checks.
- Open beans for the change requests [todo-manager] candidate, extracted
-
Each requested change becomes a bean, so the editors and agents picking the work up next see exactly what review asked for and what is still open.
- Open or claim the release bean [todo-manager] candidate, extracted
-
The release itself is a bean: it carries what is in this draft, what is outstanding, and who is holding it.
- Open or close a role to an actor candidate, extracted
-
The join every other diagram depends on. An empty
rolesis a DETERMINED empty — it says the actor takes on none — and is not the same as an absent one, which asserts nothing. - Open or EDIT the one tracking issue candidate, extracted
-
Findings: EDIT the one open issue labelled ci-health if there is one, otherwise create it, with the report as the body. One issue edited in place, never a new issue or a comment per run, so the tracking issue never becomes a feed.
- Open or EDIT the one tracking issue candidate, extracted
-
Findings: EDIT the one open issue labelled pr-no-checks if there is one, otherwise create it, with the sweep's report as the body. One issue edited in place, never a new issue or a comment per run, so the tracking issue never becomes a feed.
- Open or EDIT the one tracking issue candidate, extracted
-
Findings: EDIT the one open issue labelled repo-health if there is one, otherwise create it, with the report as the body. One issue edited in place, never a new issue or a comment per run, so the tracking issue never becomes a feed. The body states that nothing in it has been acted on.
- Open or EDIT the one tracking issue candidate, extracted
-
One issue, edited in place. GitHub's own failure mail is the channel that was already ignored thirty times, so this adds none: an edit does not notify, and a pin that stays behind for two months stays one unread item rather than nine.
- Open the branch-watch bean [watch] candidate, extracted
-
First dispatch point for a CI watcher: the feature branch has changed and a staging build now exists to watch. The watcher is DISPATCHED BY OPENING A BEAN, not by a workflow_dispatch -- per the owner on bean 29ij, this is a task/workflow initiation. That is the whole reason it is an activity rather than a line of prose. A bean makes the watch durable past the session that opened it: the container is reclaimed, and what survives is the claim. Starting the watcher and recording that it is running are ONE declared step, so the two cannot disagree about whether anything is watching. Claim rather than note: the watch is work in progress, and it is idempotent, so re-entering on a subsequent push does not duplicate it.
- Open the rule's citation candidate, extracted
-
Every rule resolves to a real
library/section or a KG node, and carries the quote it was read from. Opening it is what lets a reviewer say WHY the rule applies — and it is the only way to catch a rule that misread its own source. - Open the session record candidate, extracted
-
Writes
id,actorandstartedAt, withopenandclaimedempty. An emptyopenis the NORMAL state, not an unfinished one: an agent reading, answering or deciding is in no process at all. - Open the tracking issue, naming the failed step candidate, extracted
-
Open the issue with the step that failed, the run link and — for a verification failure — the verifier report.
- Options analysis accept · revise · discard candidate, extracted
-
On the edge out of
Task_ReviewFindingsand beforeTask_RecordDecision: the findings are the evidence, so the options can only be weighed once they exist, and afterTask_RecordDecisionthe decision is already written down. NOT betweenGateway_EditorDecisionandTask_RecordDecision, which is the pair the work-plan named — in this diagram those run the OTHER WAY ROUND.Flow_21bgoesTask_RecordDecision->Gateway_EditorDecision, so the gateway reads a decision that has already been recorded, and interposing there would analyse options after the choice was made. In the Agent lane, and this diagram makes the reason sharp.Task_RecordDecisionis auserTaskinLane_Editorthat already namesdecision-audit, andProcess_OptionsAnalysisends with its owndecision-auditnote. Those are two different acts — the subprocess records that the options were WEIGHED, the editor records WHAT WAS CHOSEN — and putting the analysis in the editor's lane would collapse them, making the same party both analyse and decide. The subprocess's own documentation refuses that: it produces options and a recommendation, and the authorisation belongs to the calling step.CallActivity_Evidencesits inLane_Editorinstead, and that is not an inconsistency: the author performs the evidence retrieval, whereas here the point is that the analyst is not the decider. On the trigger:A_Frameopens the subprocess onopening-brief's trigger — irreversibility and surprise — and leaving there is a correct outcome. A spelling fix that reachedTask_ReviewFindingswith one mechanical finding exits immediately; a revise-or-discard on a block other content depends on does not. - Options analysis adopt · hold · decline candidate, extracted
-
On the single edge into
PM_Decide, and deliberately not earlier: the MVP build and its gates are HOW the options' costs are measured, so an analysis beforeTask_Mvpwould weigh alternatives against no evidence. Everything the decider needs exists by the time the reviewer has finished and the fixable findings are fixed. In the Agent lane, because this step produces the analysis and does not make the decision —PM_Decideis auserTaskwhose lane admitspersononly, and putting the analysis in the agent's lane is what keeps that separation legible rather than implied. A subprocess that decided would be a second accepting party. Reached through the loop as well as straight through:SF_UA_8re-enters atA_Impact, so a run where the reviewer found something fixable arrives here a second time with different evidence. That is a genuine re-analysis and itsop="note"appends rather than deduping, which is the behaviour wanted — a second note records that the options were weighed again against changed inputs. - Options analysis how to absorb the impact candidate, extracted
-
On the edge OUT of
Task_AssessImpactand beforeTask_CommitPush, because the impact assessment is the evidence the options are weighed against. An analysis before it would compare ways of absorbing a downstream effect nobody has measured yet; one after the commit would be a rationalisation of a choice already pushed. NOT betweenTask_AssessImpactandTask_ReviewImpact, although that is the handoff the work-plan named. Those two tasks are in DIFFERENT LANES with no sequence flow between them — the agent's assessment reaches the committee throughTask_CompareBeforeAfter, not directly — so there was no edge there to interpose on. The conceptual handoff is real; the edge was not. In the Agent lane, matchingupstream-version-adoption: this step produces the options and their trade-offs, andGW_Approvedin the Review Committee lane is where a decision is taken. A subprocess in the reviewer's lane would read as the committee analysing its own options, which is a different process. On the trigger: reaching this call is not the same as running the whole of it.Process_OptionsAnalysisopens withA_Frame, whose trigger isopening-brief's — irreversibility and surprise, not size — and leaving at that first activity is a correct outcome rather than a skipped step. A copy-edit exits immediately; a logic change that moves an indicator does not, and this is the diagram where that distinction has teeth, sinceTask_EditLogicfeeds straight into the assessment. - Options analysis how to implement candidate, extracted
-
On the single edge from
Start_Process_CRDM_DeliverintoA_Implement, so the approach is chosen before any code exists. By Phase 6 the needs, requirements and data model are signed off, which is exactly the evidence an options analysis needs and the reason it belongs here rather than earlier: atCall_Needsthere is nothing to weigh, and afterA_Implementthe choice has been made in code. Note where this is NOT. The work-plan namedcrdm-requirements-workflow, andA_Implementis not in that diagram —crdm-requirements.bpmnis the orchestrator, seven call activities and a gateway, and Phase 6 lives here incrdm-deliver.bpmn. The call goes where the step is, not where the plan said to look. The three loop-backs intoA_Implement—_5(increment rejected),_7(MVP not ready),_13(feedback translated) — deliberately BYPASS this call. Routing them through it would run the subprocess on every iteration of the inner loop, which is the ceremony this design refuses: a gate invoked on every pass stops being read. An iteration reworks an approach already chosen; if the APPROACH is what is wrong, that is not a loop iteration and it belongs to the calling step incrdm-requirements.bpmn. Contrastupstream-version-adoption, where the loop DOES re-enter the analysis. There the loop-back returns toA_Impact, which re-gathers the evidence, so the second pass weighs genuinely different inputs. Here the loop returns to implementation with the evidence unchanged.A_Implementcarriescat-harness.processes:bean op="claim"; this step carries no bean op, becauseProcess_OptionsAnalysisends with its owndecision-auditnote on the bean the caller claimed.
P
- Package: files plus a manifest of digests candidate, extracted
-
The serialization alone is not a package. A package is an addressable set — the JSON-LD, the assets it references, and a manifest naming every file with its digest and byte count. The manifest is what makes a REMOVED file detectable, which a per-file signature cannot do on its own.
- Persist the log to the data store candidate, extracted
-
Capture is explicitly on — by <cat-harness.processes:log capture="on"/> on the process or by config — so the entries go to the git data store. Only this branch commits anything.
- Phase 1 Needs candidate, extracted
-
Identify the stakeholders, synthesise a needs statement from the sources, and loop until the BA and the stakeholders both recognise it. The loop is the phase: a needs statement nobody confirmed is an agent's summary, not a requirement.
- Phase 1: Identify stakeholders candidate, extracted
-
The agent asks the BA who is affected by this change. The BA knows the domain — the agent does not guess.
- Phase 1: Synthesise needs from sources candidate, extracted
-
From the chat, issue, uploads and library sources, write a clear, jargon-free statement of what is needed and why, tied to a concrete workflow. Post it on the GitHub issue, not in chat, and ask the requester and stakeholders to review it.
- Phase 2: Map current workflow (BPA) candidate, extracted
-
Business-process analysis here means reading the existing diagrams under processes/ and drawing the gap, so the skill that implements this step is the BPMN one.
- Phase 4a: Compare the viable options candidate, extracted
-
Phase 4 often ends with a CHOICE rather than a plan, and this is the step that hands it over. Per option: what it does, its pro, its con, what it changes DOWNSTREAM, and how reversible it is — laid out where the rows can be read against each other, then one recommendation and a stated default. A step of its own rather than a line inside A_DefineReqs, because it has a different output and a different reader: the impact analysis is for the record, the comparison is the thing the BA answers from. Folding it in is how it gets skipped — the analysis feels finished, so the options go over as a list of names. When Call_Wireframe ran, its wireframe candidates are among the options: one row per candidate, with a link to its web and mobile screenshots. Skipped legitimately when the analysis yields ONE viable approach. Do not manufacture alternatives to fill a table.
- Phase 5 Beans + sign-off candidate, extracted
-
The approved requirements become work-plan items, the BA signs off, and the branch is announced on the issue. The announcement is on the single edge into delivery, so the three loops back into implementation do not re-announce.
- Phase 5: Create beans candidate, extracted
-
The agent mints the implementation beans itself with
beans create, running the exact-title existence check first. The engine has nocreateop — it claims, notes and resolves the instance's OWN bean — so what this step records here is a note that the plan now exists. - Phase 6 Implement + acceptance candidate, extracted
-
One phase and not three, because the loops say so: an increment the BA rejects, an MVP that is not ready, and stakeholder findings all route back into implementation. A subprocess has one exit and cannot be re-entered once finished, so splitting this region would have changed what the diagram says.
- Phase 6: Implement (feature branch + PR) candidate, extracted
-
Inner loop: agent claims a bean, implements on feature branch, opens PR, posts summary to the issue. When the requirement changes a rendered surface, implement against the wireframe candidate the requester or BA chose in Phases 3–4 (Process_WireframeDesignReview, called from Process_CRDM_Requirements), not against a fresh design; and the delivery summary links the chosen candidate beside the after-screenshot, so the reviewer can see the build matches what was approved.
- Phases 2–4 BPA + requirements candidate, extracted
-
Map the current workflow, then define the requirements and the impact they carry, and loop until approved. Same shape as Phase 1 and for the same reason: an unapproved requirement is a proposal.
- Phases 3–4: Define requirements + impact candidate, extracted
-
Two skills, because this step is two things: the requirements come from the CRDM process, the impact half is a question about the entities and relations the change touches, which is what data modelling answers. It named
content-graphuntil placement PR3 (bean63wl): that is a folio-content skill, and this diagram is the harness's own. - Pick up the stale pin claim a bean candidate, extracted
-
The hand-off from the mechanical lane to the one that can exercise judgement. Claiming the bean here is what stops two sessions adopting the same bump.
- Place by ownership; declare the directory candidate, extracted
-
A domain-neutral method belongs to the harness and a domain method to the folio that owns the domain. If the session cannot write where it belongs, draft it where it can, say so in the file, and open a bean to move it.
- Place it by hand, with a reason candidate, extracted
-
Recorded as a queue entry whose placement is
overridewith a position and a reason; the schema refuses one without a reason. It enters the next placement as the table'sownerOverrideinput. - Place it in uploads/ by a declared route [upload-routes] candidate, extracted
-
THE FIRST LINK, and it did not exist until 2026-09-30. Everything downstream of here takes a file that is already in the queue, and both ingest Tools type their first input as "The upload to ingest, under the declared
uploadsgraph". So the act of PUTTING it there was performed by three different mechanisms and governed by none of them. WHAT THIS STEP IS. The basic flow's ACCEPT step: choosing an arrival route, writing the bytes into the declared queue of the instance that will own them, and discharging what that route does not discharge for you. The routes, what each writer owes, and the two that are mechanisms against the one that is a persona are in theupload-routesskill;upload-urlcomposes the forge URL for the web route from the declaration rather than from a literal, because a hand-written one 404'd. WHY A PLAINbpmn:taskAND NOT AuserTask. AuserTaskasserts a human performs it, and this lane is named "Contributor (human or agent)" precisely because both do — measured over this repository's own history, files have reacheduploads/in commits authored byCarl Leitnerand in commits authored byClaude. Asserting human-only here would be theactivity-fulfilment-kindcontradiction written deliberately: the diagram saying one thing and the lane's role graph another. A plain task asserts nothing about the performer, which is the truth. WHY THE BEAN OP ISnoteAND NOTclaim. Placing a file claims nothing; it adds to a queue. What it owes the work plan is visibility — three batches of PDFs arrived through the forge's web UI (c8349950fa5,f4ddfc65c8d,b8549160bb1) with no bean, no PR and no note, and the first sibling to notice was a generator going stale. A note against the ingestion bean is what makes the queue's growth something another session can see. - Place the asset in library/<slug>/ [library-ingestion] candidate, extracted
-
The materialized branch. The asset lands in library/<slug>/ with its metadata record, its provenance and its fixity. The folder name IS the citation key, so a citation and a directory are the same string. The upload is then RETIRED, not left and not deleted: it moves to fsh-guts/uploads/ beside a sidecar naming where it came from and when (owner, 2026-09-29), and
check:uploads-retiredfinds one that was not. A refining process that derives content from the bytes does so before that retirement;library-ingestioncarries the rule. - Plan scope, team, artifacts [content-plan] candidate, extracted
-
Scope the work, identify artifacts and actors, form the team, set the timeline.
- Plan the prune [planPrune] candidate, extracted
-
Keep every
main/<sha>for 90 days and one per day after that; droppr/<n>7 days after the PR closed. The rule isplanPruneinscripts/qa-store.ts, pinned by its tests, and the plan is printed whether or not it is applied. - Point at the upload target [scripts/upload-url.ts] candidate, extracted
-
Composed from the declaration, never written by hand. The queue is declared with INSTANCE scope, so its declared path is missing the segment a repository-relative forge URL needs: /upload/main/uploads is a 404 and /upload/main/cat-harness/uploads is not, verified against GitHub 2026-09-20. Every failure is named — no origin remote, a non-GitHub forge, a declared-but-absent queue — because a URL is believed, and somebody sent to a wrong one cannot tell it from an empty directory. On failure, fall back to the conversation.
- Pool knowledge across participants candidate, extracted
-
The four lists are reviewed by more than the person who wrote them. This is the method's own answer to its own bias limitation, and it is a distinct activity rather than advice attached to the scans, because an activity can be recorded as not performed and a recommendation cannot. Disagreement about which quadrant a factor belongs in is an OUTPUT of this step, not a failure of it — it feeds A_RecordAmbiguous.
- Post summary to issue candidate, extracted
-
What was accomplished, what remains, and the staging links: one deep link per changed page on the preview, with the same page on main (staging-review, "The deep-link rule").
- Post the MVP evidence staging URL + gate results candidate, extracted
-
Staging URL, gate results and the impact analysis, on the PR. Enough for the reviewer to answer without opening anything else.
- Post the retention notice on the PR candidate, extracted
-
Removal was not confirmed, so the preview stays: post a retention notice on the PR giving its URL and saying it has NOT been removed, and the two ways to remove it: the staging:cleanup label while the PR is open, or, once it is closed, a Run workflow dispatch with cleanup_slug and a matching cleanup_confirm.
- Preflight: is the preview live? candidate, extracted
-
previewLiveness— a disjunction over open-pr, unmerged-branch and recent-commit, shared with the health sweep so the two cannot disagree. Beanw2g5: a preview whose pull request is closed is NOT an abandoned one. - Prepare domain glossary candidate, extracted
-
Generates or retrieves the domain glossary for the target locale. Sources: 1. Root folio's translations/ glossary 2. Folio-assistant dependency translations (depth-first walk) 3. WHO standard terminology (from the WHO SMART Base IG) 4. Previous translations of related content
- Prepare the merge, and watch it through candidate, extracted
-
prepare-mergebrings the base in, re-runs the gates and pushes — it does NOT merge. Bringing the base in ISmerge-base.bpmn(bun run cat merge:main): conflicts a declared pattern covers are resolved and proved by the gate set; anything else aborts the merge and comes back to the agent (beany7b3, #1707).watchfollows the PR until it is merged or closed, because webhooks do not reliably deliver CI success or a merge-conflict transition. - Produce >= 2 candidates, web + mobile candidate, extracted
-
Mid-fidelity HTML: monochrome, real folio content, semantic icons, no placeholder text. Each candidate has both a web layout and a mobile layout.
- Produce translation (PO file) candidate, extracted
-
Translation of .pot → .po by one of: 1. Existing PO from the WHO SMART Base IG (Weblate/Crowdin/Launchpad) 2. FHIR/translation-utils po-translate CLI (DeepL/Google, tagged #fuzzy) 3. Agent (LLM) translation 4. Human translator Result: <locale>/block.po with msgid/msgstr pairs.
- Project a window onto the board candidate, extracted
-
Project a window onto the board for the chosen card. A window is not the card grown large: it survives zooming out, and only [x] closes it. The frame is fixed ([x] always present, always in the same place); the kind fills in its declared controls.
- Propose change-sets, as records with no issue yet candidate, extracted
-
public-comment-changesets seed / propose: the agent groups the comments to be weighed into change-sets, one per change the document may need, each a record under changesets/ with its requirements and members. A PROPOSAL: nothing is decided, no GitHub issue is opened, and a comment may sit in zero, one or several change-sets. The record is the only one; everything shown about a change-set is rendered from it.
- Prose and the code it describes candidate, extracted
-
Descend into Process_NarrativeCodeReview: judge what the pair checks could not settle (a stale pair, a false or undetermined claim), and send a disagreement with a checker to adjudication. Issue #1042, stage C.
- Prose blocks enter the summary queue [l1-document-ingestion] candidate, extracted
-
Owner, 2026-09-24: "Make as QA sidecar as part of general doc ingestion to slowly drain." Nothing is written to ENQUEUE a block: the queue is derived (every prose block in every declared library, minus those whose summaries.json record is a current draft or confirmation), so a promoted entry is in it the moment its blocks are. A re-ingested document whose text changed re-enters it on its own, because the record's source_hash no longer matches. What an agent doing ingestion work does here is DRAIN a few:
bun run cat summaries:next -- --n Khands it the next K blocks with their text, it writes a short summary of each in its own words, andbun run cat summaries:recordwrites them into library/<bib-slug>/summaries.json as drafts naming the agent and its model. The block itself stays verbatim andingested. ADVISORY, never a gate: this step does not hold up Task_Citeable, and check:l1-complete reports the backlog (block-summaries) without failing on it. Confirming or rejecting a draft is a person's act, inbun run cat narratives. - Provision gh-pages candidate, extracted
-
Before Pages is switched on, make sure the gh-pages branch exists — the semantics of A_Provision in bootstrap-tools' render-kg-to-github-pages.bpmn, first half.
git ls-remote --heads origin gh-pages; if absent,bun run cat-harness/scripts/pages-bootstrap.ts --provisionpushes an orphan gh-pages holding a placeholder index.html and .nojekyll (idempotent; never forced; the script creates no remote branch without the flag). Then Settings → Pages → "Deploy from a branch: gh-pages, / (root)" — not "GitHub Actions" when the publish workflow pushes gh-pages. Every publishing path reaches this step: new-repo, overlay and add-folio, and an overlay or new repo that remote-mounts its dependencies (litlfred/test, provisioned at 860f9c2). Owner, 2026-10-01: "need to create gh-pages branch before can turn on"; 2026-10-07: "need to create gh-pages before can deploy" (#2417). - Public comment on the review version candidate, extracted
-
When the draft is released for public comment: comments returned on the frozen, line-numbered review version are placed, triaged, recommended on by the review committee and decided by the editor (public-comment.bpmn). Bean v26p, issue #197.
- Publish Distribution via 'served: true' to Pages candidate, extracted
-
Publish distribution directory to _site/ via mount-instance-docs.ts respecting 'served: true' declaration. Quads files become accessible identically to web clients and CLI/agent runners.
- Publish QA results to qa-reports (NOT A GATE) candidate, extracted
-
Bean
16ei, arc3fva. After Task_RepositoryGates, WHATEVER it concluded (needs:its two corpus parts, withalways()), and after Task_QaWorkingCopy, whose copy it restores and publishes rather than building a second time (beanjtfk),qa:publish --githubwrites this run'stest/resultstrees to the orphanqa-reportsbranch:main/<sha>/on a push to main,pr/<n>/<head-sha>/on a same-repository PR (owner rulings D1, D3). A fork PR's token is read-only, so it is skipped with a::noticenaming why. It does NOT reach GW_Join: a red publish is its own red and never decides mergeability, and the hard gates never wait on it. The only job here holdingcontents: write, which is also howbun run cat gatesknows not to run it locally. A CALL ACTIVITY: the key derivation, the fork skip and the never--fretry loop areqa-publish.bpmn, which also draws the retention run that takes entries off the branch again. - Publish to the origin (a cache may front it) candidate, extracted
-
Reach host behaviour through publication.host, never by assuming GitHub Pages' behaviour — Pages CANNOT serve application/ld+json and a local server can. A CDN in front is a layer, not the host: the canonical URL stays the origin's, and the cache is an accelerated route to the same bytes. Uploading and exposing are separable steps on purpose (xies, gate 4), because collapsing them removes the last moment at which a bad URL layout can still be caught.
- Push to the CDN [render-kg-to-cdn] gh-pages, FULL REPLACE candidate, extracted
-
THIS SITE IS ONE INSTANCE OF THE GENERAL STEP (owner, 2026-09-30: gh-pages is "one specific tool of general 'publish to CDN'"). Process_RenderKgToCdn, entered with the tree this build already rendered and verified, the site root as the publication root URL, and GitHub Pages as the target — so its
gh-pagesTool pushes. Here that push is a FULL REPLACE of thegh-pagesbranch: anything on it this build did not produce is gone unless the restore put it back, which is why the restore and the survival check either side of this call stay in THIS process rather than in the general one. The call returns the push's status and message (the gh-pages merge commit and the QA result); a status other thanpushedtakes thenobranch of Did the deploy succeed?. - Push to the CDN at STAGING/<slug>/ [render-kg-to-cdn] candidate, extracted
-
A PREVIEW IS THE GENERAL STEP WITH A DIFFERENT ROOT (owner, 2026-09-30: "independent of staging vs publication … just rendering"). Process_RenderKgToCdn, entered with the tree Task_Build rendered,
STAGING/<slug>/under the site root as the publication root URL, and GitHub Pages as the target, so itsgh-pagesTool pushes. For this target the push iskeep_files: truewith adestination_dir, so it adds one directory beside whatever else is on the branch; it is also RETRIED once: five other workflows push togh-pageswithout joining this one's concurrency group, and a queue does not help because GitHub CANCELS a pending job when a newer one arrives for the same group rather than queueing it. Measured 2026-09-19: three staging runs from three different branches inside 17 seconds, two cancelled. The call returns the push's status and message; the render log and the PR comment that follow are this process's own. THE PREVIEW CAP rides in the same commit (owner ruling 2026-10-02, issue #1868: "cap the maximum number of previews (<= 10) and rotate old ones off", amended 2026-10-04 to a SIZE budget: "Cap by size, not count", "3gb"):staging-rotate.tskeeps this preview plus the most recently updated others while their total fits MAX_PREVIEW_BYTES = 3 GB and removes the rest, oldest first, each with aremovedrender-log entry and its record retired into STAGING/_retired/. Every push attempt re-readsgh-pagesand re-decides rather than rebasing, so a lost race never pushes a stale removal. A rotated-off preview is regenerated by the next push to its PR branch. - Put the merge to the owner, evidence first candidate, extracted
-
Context, options, recommendation, question (interaction-modality §4.1). One row per PR: repo, PR, head, CI on head, mergeable, review, local gates. A repository with no CI is named as such, in words. One question may cover a batch, provided every PR in it is a row.
Q
- QA working copy, built once (NOT A GATE) candidate, extracted
-
Bean
jtfk, issue #2456.bun run qa:working-copy(bean72a8) — the bootstrap kg-export, then every declared QA writer — used to run INSIDE each job that reads the QA tree, andqa-publishran the same writers again: nine builds of one tree from one commit, measured at 2,284 of 4,714 runner-seconds (48 %) on run 37659324493. Now theqa-working-copyjob builds it once and uploads everything the build changed as an artifact with a sha256 manifest; each reader downloads it, checks the manifest against the hash this job reported and every restored file against the manifest, and only then judges. An artifact rather than a cache, because a cache key built from less than the real inputs serves stale data; an artifact is per run and exact. It judges nothing, so it is not a gate and does not reach GW_Join; a failed build fails every reader at its first step (they runif: !cancelled()), never a skip. Drawn feeding GW_Readers, the four tasks that wait for it; within themtypescript-staticandgates-standaloneread no QA tree and do not wait, andqa-publishwaits for it as well as for Task_RepositoryGates. - Query data repositories and statistical datasets candidate, extracted
-
Indicator and microdata sources. Distinct from the two above because the unit of evidence is a MEASUREMENT with a population, a period and a method, not a claim in prose.
R
- Raise a finding against the wrong side candidate, extracted
-
The prose and the code really disagree: raise a finding that names which side is wrong and why. Usually the prose, because the code is what runs — but a skill can state intended behaviour correctly while the code has regressed, and then the finding is against the code.
- Raise findings before the assets land candidate, extracted
-
Findings go back to whoever authored the choice, because the choice was theirs: a theme is picked per note by a human or an agent, and there is no mapping to correct instead. Raised, never silently fixed — a reviewer who re-themes a note has substituted their judgement for the author's without saying so.
- Raise MissingPartitionError (Fail-Closed Guard) candidate, extracted
-
Fail execution fast: throw MissingPartitionError naming the required subgraphs that are absent. Never return silent partial answers.
- Raise the window the reader selected candidate, extracted
-
Raise the selected window to the top. Selecting ANY part raises it, not just a title bar. Z-order is session-only by stated default: no z is written to the layout, so a raise is never a file write.
- Re-enter a train on the new head candidate, extracted
-
The next train is the verifier: the executor's own log is evidence, not the close.
- Re-evaluate liveness AT REMOVAL TIME candidate, extracted
-
Re-evaluated AT REMOVAL TIME, through the same
previewLivenessthe health sweep uses rather than a second implementation of it. The sweep runs daily and proposes; this acts. Between them a branch can come back to life — beanw2g5documents exactly that, a session reusing one branch across five successive pull requests. - Re-execute a sample, blind to the tester's verdicts candidate, extracted
-
Given the plan, the bound data and a sample of case ids — not the report. Says
agree,disagreeorunknown;unknown(could not run) is said as plainly as a disagreement, because the table reads both the same way and an unknown read as agreement certifies on one party's word. - Re-materialize, re-asking the five gates — and record the new fixity candidate, extracted
-
The gates are re-asked, not inherited: a licence can change, and a collection can grow past the size a caller agreed to. AND THE NEW FIXITY IS RECORDED IN THE SAME CHANGE. This step rewrites bytes that a materialization record describes, so leaving the old digest behind would make a CORRECT run of this process fail check:materialized-fixity as a mismatch — the gate reading "somebody edited held content without saying so" about the one process whose job is to replace it. Measured 2026-09-22 (bean 10s1): this task named no fixity write at all. This is the owner's publication exception, stated as a rule rather than as a carve-out. The exception is NOT "these actors may skip the rule"; it is "say what you did". A writer that updates the digest alongside the bytes passes, and the record then describes what is actually there. A writer that does not fails, correctly, because it has forked upstream silently. A list of permitted writers would go stale the first time somebody added a sixth one; this does not.
- Re-pin downstream mounts, as PRs candidate, extracted
-
For each instance whose index.config.json mounts this repository: a PR moving
refto the merge commit, with a trust.consent whose evidence quotes the owner's consent to that pin, and the lock regenerated bymount:remote. Each re-pin PR is itself a merge to main and runs this process again. None found is recorded with where it looked. - Re-read the prose against the code candidate, extracted
-
For each open item, read the prose claim beside the code it describes and decide what is true. For a stale pair, read what changed in the code and whether the prose still describes it. For an undetermined claim, say whether it points at something real outside this repository. For a false claim, check the checker's reading before trusting it.
- Re-render the agent surface candidate, extracted
-
When the lock changed, the layers an agent's skills and memory are generated from changed with it.
mount:remotere-runs the generators of what an agent actually reads —skill:commands(.claude/commands/) andagent-memory(.claude/agent-memory/and the.agents/copies) — from the checkout root, and a generator that fails fails the run. A re-pin commit therefore carries the new layers AND the surface rendered from them; shipping the first without the second is how folio-assistant#2526 went red on three agent-memory tests. Owner, 2026-10-10: "it may have new agentic skills to re-render and add. same for memory." - Re-route open PRs that lost their driver candidate, extracted
-
Green, up-to-date PRs join the queue; mid-merge branches are re-driven from the PR head, never guessed at; red PRs go back to the new driver.
- Read each queued PR's live facts candidate, extracted
-
From GitHub and the checkout, now: authored paths, shared declarations, size, conflict risk and overlap KIND against the other queued PRs (T3), own CI and whether it ran on the head (T2). Tools:
merge:overlapfor the overlap facts,check:head-has-runforownCi. Nothing read here is written to a queue entry; it is the input to the placement table.ownCiIS NOT A VERDICT READ. Never ask whether anything is red: ask which workflow runs are OWED for the head's event and whether each one is present and successful. The two readings come apart, measured 2026-10-02 on #1889's head 7ab6119405 -- 9 runs present, all 9 gating job NAMES matching, 3 of them in_progress with a null conclusion, and 3 check SUITES completed asaction_requiredhaving executed nothing. A filter for conclusion = failure finds zero, and counting the runs does not catch it either.check:head-has-runis the only thing here that asks the owed question (bean3pqn), and the five states it distinguishes are the five values ofownCi.Rule_HeadNotGreenin merge-priority.dmn then hands back anything butgreen, so this is a gate the engine applies rather than advice a steward remembers. Overlap kind matters as much as overlap:merge:overlapover all 36 open PRs on 2026-10-02 (459 pairs) found #1907 x #1909 NOT independent onpackage.jsonalone, with zero authored content shared.generated-onlyneeds a regeneration andshared-declarationneeds ordering; onlyauthoredneeds a train. - Read every PR's state candidate, extracted
-
gh pr list --state all: number, state and when it closed, so eachpr/<n>/entry can be judged against its close date. A PR missing from the list isunknown, and an unknown is kept. - Read the declaration, and each one it needs candidate, extracted
-
<name>.jsonat the root, then each name in itsneeds, from a sibling checkout../<name>/<name>.json. A dependency that is not beside it is itself a step, not done — never skipped. - Read the guide's own stated rules candidate, extracted
-
From the INGESTED document's sections, not from a screenshot and not inferred from a site that happens to use the brand. Units stay as the source gives them: rewriting 29.7cm as millimetres is a conversion nobody asked for and a chance to be wrong.
- Read the harness's declaration and instructions candidate, extracted
-
Performed against the data store — a git repository, through the git CLI or a forge API. The instructions are at a PREDETERMINED spot on the harness:
<stub>/docs/bootstrap/initialization.md, the same for every harness, which is what lets a Bootstrapping Agent be pointed at one nobody has written yet. - Read the head's evidence, live candidate, extracted
-
On the PR's current head SHA, now:
ciState(green, red, pending, none, unreadable) per OWED job from the workflow runs whose head_sha is the head;mergeable(clean, dirty, unknown);review(clear, blocking, unknown), including open CHANGES_REQUESTED reviews, a draft,needs-merge-human, and Claude Approvals where the repository runs it. Where the repository hasmerge:guard, its evaluate mode is this step (exit 2 isunreadable, never a pass). Write each fact down with the URL it came from. - Read the original — and write nothing candidate, extracted
-
A read, and the only interaction this process has with the source. Its digest and
provenanceare carried forward: the digest so Task_VerifySourceUntouched has something to check against, andprovenanceso the copy can name what it came out of without re-deriving it. - Read the pair checks' findings candidate, extracted
-
Open the subject's kg-qa sidecar and list what is open: a failing prose-reviewed-since-code-changed (code moved, prose did not), and every false or undetermined claim from prose-claims-resolve —
bun run cat pairs:claimsprints the full list, including what it did not check. Claims that hold and pairs that are not stale need nothing. - Read the pin registry upstream-pins.json candidate, extracted
-
The registry lists the tenants and says, per row, WHICH FILE holds the pin literal and how to read it. It deliberately does not store the version: one answer to "what are we running", read from the file the build reads.
- Read the repository facts candidate, extracted
-
Mechanical, read-only: does the instance's config (its
index.config.jsonentry; a legacy<name>.config.jsononly as a fallback) declare a contentType, does the working tree hold somebody's existing project, and what has the user actually said. These are the three inputs to folio-intent.dmn. Non-relaxable: scaffolding without looking first is how a folio gets written over somebody's project. - Read the served stylesheet's declarations candidate, extracted
-
Read the ROLE, never the prettiest value. Bootstrap's --blue is a scale entry and --primary is the role; DSpace sets them differently, and taking the brand-looking one is the hardcoding schemas/theme.ts exists to end. Column widths come from declared columns, never from breakpoints: a breakpoint is a viewport.
- Read the sidecar findings candidate, extracted
-
Open the block's
.qa.json, not just the evidence line: register is a property of the passage, and the sidecar quotes one line of it. - Read what each location already is candidate, extracted
-
Ask the location, not your memory of it: a Knowledge Graph Data Store that carries a declaration at its root is ALREADY an instance, and it says so itself.
<name>.jsonpresent and parsing is the whole test, andbootstrap-kg-navigationsays what the three answers mean — absent (not an instance yet), present, and present-but-unreadable, which is an instance asserting something broken and is not a green light either. Before reading the chosen harness rather than after, deliberately: if the location is spoken for by another harness there is nothing to learn from the chosen one, and fetching it first only makes the failure more expensive. - Rebuild main site candidate, extracted
-
docs-site.yml triggers on the merge commit to main, rebuilding the root of gh-pages with the accepted changes. The build SHA stamp now reflects the merged state.
- Receive assignment and materials candidate, extracted
-
The translator receives: - .pot file with source strings (msgid) - Domain glossary with approved term translations - Context notes per string - Style guide and WHO terminology references Tools: Poedit, Weblate, Crowdin, or direct .po editing.
- Recommend a decision, with a rationale candidate, extracted
-
A GitHub comment tagged pc: PC-0042 / recommend: code, from a login in config.json committee, or public-comment recommend.
- Recommend one, and say what happens with no answer candidate, extracted
-
Mark the option the agent would take and say why. Then say what happens if nobody answers: the default, when the caller allows one, or that the question stays open and the work stops, when it does not. Said now, so silence has a meaning both sides agreed to before it happened.
- Reconcile the two by hand candidate, extracted
-
Neither side wins whole: the contributor produces content that is neither the local copy nor the remote one, and THEN it is applied. Drawn as a separate step before Task_Apply rather than folded into it, because Task_Apply re-asks the five import gates against what is being materialized — and what is being materialized here is a hand-made artefact, which is exactly the case those gates should see rather than be told about.
-
Write the chosen coordination where it will be found: bean links (--blocked-by, --parent), a line in the issue or PR body, or 'note only'. A declined coordination is recorded too.
- Record assets[] — local path or remote URL candidate, extracted
-
kind / role / url-or-path / checksum / retrieved. A SIBLING of library:, never inside it: LibraryRef is regenerated from the tree, so an authored URL placed there is dropped on the next sync.
- Record contradictions IN the source candidate, extracted
-
A step because it happened twice on the first real ingestion: the WHO guide states its black logo as both K:100 and R:100 G:100 B:100, and gives the logo blue as C:95 on page 6 and C:90 on page 12. A contradiction silently resolved is indistinguishable from one nobody noticed, so it is kept as data and the reading taken is stated as a choice.
- Record each answer: who, when, scope, the quote candidate, extracted
-
One record per permission: by, on, tool, permission, scope (session, instance, or until a date), the config diff, and evidence (the owner's words verbatim, with where they were said). Refusals are recorded the same way.
- Record findings as advice candidate, extracted
-
A reviewer cannot accept a change — that is the editor's lane — so the output is findings on the sidecar, not a commit.
- Record how the walk ended, part by part candidate, extracted
-
One line per offered part: materialised, referenced by choice, or referenced because a gate refused (and which). Nothing new is decided here; it is the account the visualizer and the next refresh read, written once rather than reconstructed from the loop.
- Record it in library/ as referenced [library-ingestion] candidate, extracted
-
The referenced branch. Nothing is fetched and no bytes are written: the catalogue record says where the asset is and that we hold none. A reference is not a fetch — it stays navigable without being held, and materializing it later is
materialize-remote.bpmn's decision, with its purpose and five gates, not this flow's. - Record it where a person can read it candidate, extracted
-
Performed by the Logger, which records and decides nothing. In bootstrap the one available destination is the discussion the human actor is already in.
- Record on the block's QA sidecar candidate, extracted
-
Through
qa-merge-findings, so the icon and the published witness agree with the decision. The adjudication LEADS the criterion and the script entry is kept beneath it: a disagreement between a checker and a reviewer is information. - Record provenance.local — what this is a copy OF candidate, extracted
-
The step that is easy to omit and impossible to reconstruct afterwards.
provenanceis a PAIR:upstreamis the remote thing,localis the original in this repository. A copy-out writeslocal; it does not overwriteupstream, and it does not reuseupstreamfor a local value — that was one field until 2026-09-22, and by then 5 of the 9 who-iris item records were using it for a local one in violation of its own documentation. Withoutlocal, one rename later the copy is indistinguishable from original work and nothing downstream can repair it, because the information was never written down. - Record the answer, and who gave it candidate, extracted
-
In the form the caller asked for — for bootstrap's harness question, a document conforming to discussion.output.schema.json with determinedBy asked. Who answered (a person or an agent) is part of the record. An answer about the context, the Role or the Process is recorded the same way, as the person's word.
- Record the blocker and hand back candidate, extracted
-
Blocked is not scrapped. Set
--blocked-by, say in the body what would unblock it, and return it totodoso it is visible to whoever can act. An in-progress bean nobody is progressing reads as active work. - Record the certification decision [attestations] candidate, extracted
-
The judgement: the certifier records, under their own name, that the system meets plan P at this version on this run. It is written under the declared
attestationsgraph beside the other judgements, never on theqa-reportsbranch with derived results. A user task, so no agent or pipeline can fill it. - Record the conflict, decide nothing, and do NOT re-pin candidate, extracted
-
Both copies stay and the conflict is written down with what each side says. Deliberately does not re-pin, which is the one thing separating it from Task_KeepLocal: the question is unresolved, so it must be asked again next cycle. Recording is not optional here for the reason A_RecordEntry is not optional in an adjudication — a judgement nobody wrote down is indistinguishable from a check that never ran, and a DEFERRAL nobody wrote down is indistinguishable from a refresh that silently did nothing.
- Record the decision and its audit note [decision-audit] candidate, extracted
-
A decision is an act ABOUT the findings, not a finding. Record the outcome, every finding it weighed, every finding it overrules — and an audit note saying why it was made, or why a finding in it was left. Each note cites corpus evidence: a witness, another finding, a QA report, a block, a file range. An overruled mechanical finding stays on the record; a gate whose findings vanish when somebody disagrees with them cannot be audited. An agent may assemble the citations and is recorded as
proposed_by; the author is whoever decided. - Record the decision as still open candidate, extracted
-
An undetermined decision is DATA, not silence. It is recorded with what it waits on and what would settle it, so the next session can tell "nobody has chosen" from "somebody chose and did not write it down" — the same third state bean-blocking keeps for a block with no expiry.
- Record the determination candidate, extracted
-
Writes a document conforming to
discussion.output.schema.json: the harness, the repositories as read-from / written-to pairs,determinedBy: asked, and who answered. This artefact is what finishes the task. - Record the evidence gap [todo-manager] candidate, extracted
-
Insufficient evidence is a RESULT. It is recorded as such -- an honest gap the guideline can state -- rather than being closed by weakening the recommendation until the available evidence supports it.
- Record the gap as a bean candidate, extracted
-
A missing derived artefact is a tracked gap, not a silent omission. The document stays in uploads/ until the gap closes.
- Record the hold or the decline candidate, extracted
-
A HOLD is a block with an expiry and a revisit trigger: a hold with neither cannot be told from abandoned work, and the next watcher run re-raises the same pin with no memory of why it was left. A DECLINE is a scrapped bean carrying its reasons — what stops the next agent re-entering the same dead end. Either way the decision is written down before the process ends, and the bean is resolved from here: a run that stops at "we looked and said no" is as finished as one that moved the pin.
- Record the L1 completeness verdict candidate, extracted
-
Record the completeness verdict in three states — met, unmet, or not yet derivable — as bun run cat check:l1-complete reports it. Not-yet-derivable is never a pass. An unmet verdict opens a bean and returns to derivation; only a met one lets the entry into library/.
- Record the recommendation AND the rejected options candidate, extracted
-
The rejected options and why they lost are part of the output, not an appendix. A rejected option with no record is a dead end nobody marked, and the next agent walks into it — the same argument
bean-coordinationmakes forscrappedover deleted. In a bean context the form is MADR's. Which methodology was followed is named here, so a reader can check the method rather than take the conclusion. - Record the refusal on the bean candidate, extracted
-
The PR, the head sha the train used, the train and its other members, each refused path or failing gate and why. A repeat refusal goes under
## Attemptswith--body-append. - Record the refusal, with the failing cases candidate, extracted
-
A complete, trusted run in which a case failed. The refusal names the failing cases and is the end of this request; nothing is signed. The bean resolves here because the process has finished — what to do about the failure is a new piece of work.
- Record the sign-off as a requirement-signoff attestation candidate, extracted
-
THE RECORD, and not relaxable: a judgement nobody wrote down is indistinguishable from one never made (
adjudication, A_RecordEntry). Append onerequirement-signoffrecord totest/attestations/requirement-signoff/<set slug>.attestations.json— who (kind, id, actor), at, scope (the set or one member), the outcome from the requirement-set code list, the stage it moves the set to, the reason, and the permalink to the issue comment where it was decided — and set the set'sstageto match. Issue #2405 FR-011 / FR-012. GW_SignoffRecorded after this reads the record back, so this step cannot be skipped by completing it: a sign-off that left no attestation loops here again. - Record the sign-off as a requirement-signoff attestation candidate, extracted
-
THE RECORD, and not relaxable: a judgement nobody wrote down is indistinguishable from one never made (
adjudication, A_RecordEntry). Append onerequirement-signoffrecord totest/attestations/requirement-signoff/<set slug>.attestations.json— who (kind, id, actor), at, scope (the set or one member), the outcome from the requirement-set code list, the stage it moves the set to, the reason, and the permalink to the issue comment where it was decided — and set the set'sstageto match. Issue #2405 FR-011 / FR-012. GW_SignoffRecorded after this reads the record back, so this step cannot be skipped by completing it: a sign-off that left no attestation loops here again. - Record the step in its state candidate, extracted
-
The step, the declaration that named it, its state, what was seen, and — for anything not done — exactly what to do next.
- Record the triage and claim the picked-up work candidate, extracted
-
A 'triage: <date>' bean note on each theme's epic; new or re-parented beans; claims via beans:claim. Owning sessions still alive are notified before their branches are touched.
- Record the verdict on the node candidate, extracted
-
Findings are advice, not commits — the same separation the generic reviewer lane keeps. Record them where the next reader meets the node.
- Record the withdrawal candidate, extracted
-
public-comment withdraw, from any open status.
- Record what did not classify cleanly candidate, extracted
-
Factors that sit in two quadrants, or in none, are written down as such. The source states this as inherent rather than as analyst error: "the same factor can be fitted in two categories. A factor can be a strength and a weakness at the same time." It adds the two drifts — strengths not maintained become weaknesses, and opportunities not taken but taken by competitors become threats. A scan that silently forced every factor into one quadrant would report a cleanliness the method does not have. This is the same third-state discipline the rest of this repository applies to "could not determine": an unclassifiable factor is a finding, not a blank.
- Record what failed candidate, extracted
-
Which check failed, on which items, and the evidence. The landed copy is not removed: a failed import is information about the source or the store, and deleting the copy would destroy the evidence.
- Record what is still open candidate, extracted
-
outcome: unsettledwith what was asked and what is still open, so the next actor resumes rather than restarts. An agent that reaches for a default here has produced a guess, not a determination. - Record what is still open candidate, extracted
-
Declined, or silent where no default is allowed. The record says what was asked and what is still open, so the next actor resumes rather than restarts. Never a guess. When it is the context, the Role or the Process that is still open, say so and stop: a step completed in the wrong Process records an authority that was never given.
- Record what was done, and close candidate, extracted
-
A closed work item is read later by somebody deciding whether to reopen the subject, so "completed" with nothing behind it cannot be audited. An ISSUE is never closed on the agent's own say-so.
- Record which route signed it candidate, extracted
-
The attestation records the route, not only the signature. A reader who cannot tell an API signature from a human one cannot tell which trust assumption they are relying on.
-
Before the merge, in the shape of
ReleaseSchema(schemas/merge-queue.ts): verdict, decidedBy (the person), decidedAt, authority (explicit, standing ruling with its date, or waiver id), the quote verbatim with its source, releasedSha (the head approved; a later push voids it) and capturedBy (this session). Where the merge queue exists,merge:queue:decidewrites and validates it; elsewhere it is amerge-authorised:comment on the PR and a note on the bean, with the CI state (green, or none with the local gate commands). A paraphrase is not evidence. - Record why it could not be decided candidate, extracted
-
The third state: which fact kept the table from deciding — a run not finished, an unknown data hash, an unexecuted case, a checker that disagreed or could not run, or nothing passed. A note and not a resolution, because the request is still open: it needs a re-run or an adjudication, not a verdict.
- Record why it is not a substrate; write no entry candidate, extracted
-
No subscription entry is written for a repository that is not a substrate. What is recorded is the reason (non-conforming, no harness, or unreachable) and the pin it was asked at, so a later attempt at a different commit starts from what failed.
- Record x,y for this note on THIS board candidate, extracted
-
Record the note's x,y in the layout layer for THIS board, naming the note by id. An existing card dragged here only gets a new position — placing is not creating, so no content is duplicated.
-
Refresh
updatedAtonly candidate, extracted -
Nothing changed, and saying so is the point. A record that stops being written looks exactly like an abandoned session; a refreshed timestamp with no other change says the session is alive and idle, which is a different fact and the commonest one.
- Refresh materialized content candidate, extracted
-
Refresh is not re-import: what changed upstream, what changed locally since, and what to do when both did. The shared subprocess answers all three, and re-asks the five gates, since a licence can change and a collection can grow past the size agreed.
- Refresh the held part [refresh-materialized] candidate, extracted
-
The shared refresh, called, not re-described: what changed upstream, what changed locally, and what to do when both did. An archival copy is fixity-checked and never re-fetched. Whatever that process decides — refreshed, kept divergent, or deferred — is the part's new state; this loop only moves to the next part.
- Refuse: no flow for this source kind candidate, extracted
-
A kind added to the union (a graph database, say) before this diagram and the mount tool learn it. Refused with its own exit code — reading it as a directory would scan an empty path and report it clean, the
dh4fdefect. - Regenerate every derived reference from its source candidate, extracted
-
Regenerate every derived reference from its source before building: skill schema and instruction pages, content-backed docs pages, the graph projections and viewers, the handler and translation indexes, and the rendered BPMN diagrams. The published site is built from sources, never from committed copies that may be stale.
- Regenerate harness projections (CI) candidate, extracted
-
A workflow step, on the PR head: run the generators whose output is an agent-host projection of the graph (today
skill:commandsfor.claude/commands/, and theagent-memoryassembler for.claude/agent-memory/and.claude/agents/) and commit what changed to the PR branch. An agent never writes or commits these files (harness-projections). A commit here moves the head, so the evidence below is read on the new head. Where a repository has no such workflow, this step is not performed and the merging session says so in the evidence rather than writing the projections itself. - Regenerate the context, block, library and site graphs — and diff candidate, extracted
-
Run the five --check generators in one job — the JSON-LD context, block siblings, library nodes, site graph, then the label-resolution and emitter tests. Any committed .jsonld that differs from what its generator now produces fails the PR, because a stale generated file is still consulted.
- Regenerate, asking every CI gate candidate, extracted
-
bun run cat regen: every check/writer pair the CI workflow runs, repeated until the tree settles. - Registered gates that never run (HARD) candidate, extracted
-
check:gates-registered, split out of Task_RepositoryGates by beandlqu: one step of that job measured 1m46s-2m28s across four runs, the longest step in it by a factor of four, and a sequential job is as slow as the sum of its steps. In its own job it runs beside the rest rather than after them. It still asks the same question — is every gate a script registers actually run somewhere — and is still hard. It also carriesbun run cat security:gate(beanieum, owner 2026-10-07: "security check before release"): the security checks by name, plus third-party action SHA pinning outside staging-only workflows, as one step that merge-train's gate call reaches. A blocking fail OR could-not-check fails the job. - Reject Request with ValidationError candidate, extracted
-
Abort execution immediately with detailed validation error describing missing or ill-typed arguments.
-
When the requirement is initiated or updated through a human-agent chat, search the beans and the repository's issues and open PRs for relevance, categorize and summarize them, and ask the user whether and how to coordinate. Judgement decides the categories; the user decides the coordination. Owner, 2026-09-23 (issue #1023).
-
Search beans, issues and open PRs for work the method touches, categorize and summarize them, and ask the owner whether and how to coordinate. CRDM calls the same sub-process.
- Relations and cardinalities, both ways candidate, extracted
-
Stated in both directions, because "one attestation per report" and "one report per attestation" are different claims and a model with only the first cannot say whether a re-signature is an update or a second row.
- Relocate the content to the trashcan candidate, extracted
-
Relocate the confirmed content — that one thing, not the class it belongs to — to the trashcan. The folio changes first, because the folio carries what is true.
-
Remove it AND append
removed— one commit candidate, extracted -
Say what is going — size and file count — then remove STAGING/<slug>/ and append
removedto the render log in the SAME commit, so a preview cannot vanish without a record of who dispatched it and why. The slug is a dispatch input, so the tool re-checks it by value rather than trusting the guard. - Remove STAGING/<slug>/ candidate, extracted
-
When the PR is merged or closed, the cleanup job removes the STAGING/<slug>/ directory from gh-pages so stale previews don't accumulate.
- Remove the artefact candidate, extracted
-
rm -rf STAGING/<slug>. Cannot reach the log, which lives outside STAGING/ — structural rather than guarded, because a branch named to collide with a directory under STAGING/ slugifies to exactly that name and git permits the ref. -
Remove the preview AND append
removed— one commit candidate, extracted -
ONE COMMIT for the removal and its record. A separate log push can fail on its own and leave a preview that vanished with nothing saying why — which is the exact state bean
plj1left the branch in.render-log.tsrefuses aremovedentry with no reason, so this step fails loudly rather than writing a record that says an artefact went and not why. - Render and push with the target's Tool [its own subprocess] candidate, extracted
-
BOUND BY THE TOOL, so no
calledElementis written here: the activity names the skill, the Tool satisfies it, and the Tool'ssubprocessesare what this descends into — forgh-pages, bootstrap-tools' render-kg-to-github-pages (make sure gh-pages exists and Pages serves it, stage, check the staging, commit onto gh-pages, check what is served). A diagram that named it would make every other CDN a second copy of this process. Whatever the Tool, it returns the two outputs below. - Render every card as its avatar candidate, extracted
-
Render every card as its avatar — the starting state. Each content kind controls its own avatar; the board decides only that nothing starts open.
- Render the method: adopted vs refused candidate, extracted
-
What the source says, section by section, then a table of what this platform adopts and what it refuses, each with a reason. Extensions beyond the source (such as web plus mobile where the paper studied mobile) are stated as ours. Reported results are not imported as facts.
- Repeat the slug, exactly, to confirm candidate, extracted
-
The one step in this process that is a person's. Repeating the slug is not ceremony: it names the artefact being confirmed, so a confirmation cannot be inherited by a later run pointed at a different preview.
- Report Budget Finding; Refine Subgraph Splitting candidate, extracted
-
Record the oversized partition on the coordinating bean. Refine subgraph partitioning boundary or split into finer subgraphs. Do not ship oversized partition.
- Report every step candidate, extracted
-
One report, every step in its state, with counts: done, not done, could not determine, stated — led by the primary step, the JSON Schemas and JSON-LD at their IRIs. Required, which is what drawing the call says: an initialization that finished with steps open must say which.
- Report the capture state candidate, extracted
-
Capture is off or unknown, so nothing is committed. Say which of the two it is: off is somebody's decision, unknown means nobody could tell, and an agent that believes it has an audit trail when it has none acts on a false belief.
- Report the measurement; ship nothing candidate, extracted
-
Write the measurement and what was tried onto the bean, and ask the owner whether the slice should ship at that size, be cut further, or not exist. Nothing is wired: no manifest is published, no gate added, no deploy line written.
- Report the push: status and message candidate, extracted
-
pages-status.ts: pushed, not-pushed or could-not-determine, and one line — the commit, the root URL, and the QA of both the staging and what is served. On the path from a failed staging it says not-pushed and names the problem. Required on every path: a caller that gets no status cannot tell a push from nothing.
- Report the push: status and message candidate, extracted
-
The output, on every path:
pushed,not-pushedorcould-not-determine, and one message — what is live (a commit), at which root URL, and the QA result. From the no-Tool branch the status isnot-pushedand the message names the target nobody implements. A check that could not look is never reported as pushed. - Report what moves — sizes, what breaks candidate, extracted
-
The agent reports and waits: what moves, how large, what in the parent breaks, and the rollback. It never relocates a durable artefact on its own initiative.
- Report what the run found, once candidate, extracted
-
Every member's verdict, in one table in the run's summary: merged, already up to date, refused, an expected race, a repeat of a failure already reported, something new, or a member that could not say.
cat-harness-tools/scripts/merge-main-comment.ts --aggregate. - Report what would move — sizes, and what breaks candidate, extracted
-
The agent reports and waits.
deletion-requires-confirmationis not a courtesy to waive: an agent never removes or relocates a durable artefact on its own initiative. - Repository gates (HARD) candidate, extracted
-
The 43 repository-gate steps — workflow refs, lane and process documentation, kg:audit:check, detangle, skills, published packages — 150
bun runinvocations in all. A SEPARATE job from Task_TypeScript since beanom30: they were one job in whichbun testcame second of 47 steps, and because Actions stops a job at its first failing step and no step was continue-on-error, a deliberate test failure onmainmeant none of these ran. A gate never asked and a gate that passed are indistinguishable from outside, which isxom7at the step rather than the workflow. No sequence dependency on Task_TypeScript is drawn because there is none: a red test must not stop these being asked.bun run cat gatesderives its list from BOTH jobs, so the local set still cannot drift from CI's. - Request certification of the system against plan P candidate, extracted
-
Name the plan by id AND version, and the system under test by actor id. The actor must carry the
systemUnderTestfacet: an actor that has not said it can be tested is not run against a plan by default. The bean this instance tracks is claimed here. - Request changes candidate, extracted
-
Committee provides feedback. PR stays open. Author and agent iterate further.
- Request completion of remaining strings candidate, extracted
-
Return to the translator with a list of untranslated or fuzzy strings that need attention.
- Request further revisions candidate, extracted
-
Author provides feedback on what needs adjustment. Agent iterates on the feature branch.
- Resolve by hand, then regenerate candidate, extracted
-
The asset carries no description.
- Resolve each by its declared strategy candidate, extracted
-
qa-sidecar paths first, through
qa:resolve-conflicts; take-base paths take the base's copy; generated-regions files take the base's side of each hunk, which lies inside a generated region by construction. - Resolve or re-open the bean [todo-manager] candidate, extracted
-
Resolved when the change landed clean; left open with the residue when it did not.
- Resolve the closure at the pin candidate, extracted
-
Fetch the pinned tree (shallow, blobless). Read the harness's declaration from it; for each
needsname, find that instance in the same tree, else follow a GITLINK at that tree as a pin into its own repository. A need found in neither is missing; one the downstream already holds is local. Paths and directories come frommountDefaultsunless overridden. - Resolve the kind's zoom threshold candidate, extracted
-
Resolve the semantic-zoom threshold for each card's kind: the folio default unless the kind overrides it with a stated because. Return the source alongside the value, so a card that flipped too early can be traced to a decision or to a default.
- Resolve the performer's reach [effectiveReach + signing-api probe] candidate, extracted
-
Compute the two facts the gateway reads: effectiveReach(deployment, actor) from schemas/actor-reach.ts, and whether the signing-api capability is configured. Undeclared reach resolves to "unknown" rather than to the deployment's value — an aggregate does not determine a member.
- Resolve the plan [test-plan/v1] candidate, extracted
-
The plan parses, names at least one
req:requirement, itsexitCriteriaresolves to a decision in a.dmnthat exists, and itsscope.kindis the system's facet kind. A plan that does not resolve is not run —test-plan-resolvesaudits the same join afterwards. - Resolve the subgraph's content source candidate, extracted
-
declaredSubgraph(start, id): the declaring instance, the entry, and the resolved source withdeclaredInsaying which layer answered. Never readsourceoff the declaration directly — the config override and the legacystoragefield are folded in by the resolver and nowhere else. A contradiction (bothsourceandstorage; aqasubgraph keyed by tip) throws here, before anything is mounted. - Resolve the Subgraphs and the root URL candidate, extracted
-
Read the instance's declaration. Every Subgraph id asked for must be one it declares; none asked for means the whole graph. The root URL is the one given, else the declaration's iriBase, else https://<owner>.github.io/<repo>/. An unknown id is refused, never rendered as a smaller site.
- Resolve the Subgraphs, the root URL and the target's Tool candidate, extracted
-
Every Subgraph id asked for must be one the declaration lists; none means the whole graph. The root URL is the one given. The target's Tool is the one that
satisfies: ["render-kg-to-cdn"]for that CDN —gh-pagesfor GitHub Pages. A caller that already rendered and verified its tree hands the tree over instead of the graph, and the Tool pushes it without rendering again. - Restore the OPEN PRs' staging previews candidate, extracted
-
Copy every OPEN pull request's STAGING/<slug>/ preview from gh-pages into the publish directory before the replace, once per publish attempt. Without it the full replace deletes every preview, silently (bean plj1). Only open PRs' previews are carried.
- RESTRICTIONS unknown is an answer, not a green light candidate, extracted
-
The owner's phrase is 'no restrictions known in context', and that is a STATE, not a green light. GateVerdict is three-valued for this reason alone, and
unknownis never rendered aspermitted. - RETENTION what expires this copy candidate, extracted
-
A copy with no expiry cannot be told from an abandoned one — the same argument bean-blocking makes about a block with no expiry. An ARCHIVAL copy is the exception and it is a specification rather than an omission: freshness() reports it
permanent, notno-expiry. - Retire an actor — never delete one candidate, extracted
-
An actor id is referenced from roles, diagrams, beans and commits, so removing the file leaves every one of those unable to tell retirement from accident. Same rule, and the same reason, as a scrapped bean.
- Retire or archive [content-retire] candidate, extracted
-
No more content is planned: deprecate the folio. Post a deprecation notice and timeline, update its status metadata, archive it, point references at any successor, and remove it from active publication. The programme manager decides; retirement archives rather than deletes.
- Retrieve for each sub-question candidate, extracted
-
The paper's Searcher, at the granularity A_Plan chose. Which retrieval paradigm — text-only, vision-only or hybrid — is recorded in the methodology node as an open trade-off rather than settled here: the paper's comparison was measured on its own corpus and says nothing about a folio's.
- Retrieve the npm package or tarball candidate, extracted
-
An
npmsource (schemas/subgraph-source.ts,npm-kg-distribution): an npm package specifier or tarball path (.tgz).kg-retrieve-npmornpmfetches and unpacks the package contents into the declared path. - Retry a declared-flaky gate once candidate, extracted
-
T7, narrow (R11; TAP17 Table II p. 5): only gates on a declared flaky list (browser e2e), once, both outcomes recorded. A deterministic gate is never retried: that would spend a CI cycle to learn nothing.
- Return for correction with annotations candidate, extracted
-
The reviewer annotates specific passages that need correction and returns to the translator with detailed feedback. Each annotation includes: - The passage in question - What is wrong (terminology, meaning, style) - The suggested correction or reference
- Review each slice [review-task] candidate, extracted
-
review-task.bpmn, once per slice, in parallel lanes by role. What kind of thing changed decides which review the slice descends into; the reviewer takes on that inner lane's role for the call only. Each reviewer gives the slice's blocks a verdict, and comments on the pull request with the
block:tag where something needs saying. - Review impact assessment candidate, extracted
-
Committee reviews the agent's impact assessment: - Were all downstream effects identified? - Are the indicator changes acceptable? - Does the logic change match the narrative intent?
- Review increment (test behaviour) candidate, extracted
-
Inner loop: the BA tests each delivered increment against the acceptance criteria. They do not review code — they test behaviour.
- Review requirements and impact analysis candidate, extracted
-
The BA reviews the formal requirements and the impact analysis the agent produced. When a requirement changes a rendered surface, the BA (or the requester) also reviews the wireframe candidates, web and mobile, shown wherever the requester will look (the conversation, the issue, the pull request, or several) with staging deep links and screenshots, and chooses one before implementation starts. The agent records the choice; it never makes it.
- Review staged rendering candidate, extracted
-
Author reviews the rendered feature branch at <pages-url>/STAGING/<branch-slug>/ and compares against the main site. The staging banner shows the commit SHA. The agent's before/after preview (skill before-after-preview) sits beside the URLs, with its counts and status line.
- Review synthesised needs statement candidate, extracted
-
The BA reviews what the agent synthesised and checks it against what they actually need.
- Review the adoption candidate, extracted
-
The asset carries no description.
- Review the change candidate, extracted
-
A human or an agent acting AS reviewer. Nothing is a reviewer; somebody acts as one for the duration of this lane. For a rendered change the reviewer reads the agent's before/after preview rather than building one. On agent-touched changes, an adversarial code review evaluates against the RED FLAG taxonomy and writes a committed verdict.
- Review the change set on its staging preview candidate, extracted
-
The existing content-change review, unchanged, of the author's branch: its PR lists the PC refs it answers, and its staging preview is the after side of every deep link. A change the reviewers send back returns to the author inside that process.
- Review the draft publication [content-review] candidate, extracted
-
Content reviewer, QC reviewer and technical officer review the draft as a whole — coherence, phase-gate criteria, breaking vs non-breaking change.
- Review the editorial dependencies candidate, extracted
-
uses[]is what a READER must have read to follow the block — never populated from the formal dependency graph. Once every changed block is covered, the committee checks the editorial dependencies of the change as a whole before judging its impact. Moved here from the harness'sreview-narrativeby placement PR3 (bean63wl): reading order is a property of folio content, so the step belongs to the content process, which reaches the harness's review by calling DOWN intoreview-task. - Review the findings candidate, extracted
-
THE GATE: the editor sees every finding BEFORE anything reaches the corpus.
- Review the guidance already in this content [content-review] candidate, extracted
-
The author reads what the document, DAK or IG ALREADY says on this question, before looking outward. A recommendation that contradicts a sibling recommendation in the same artefact is a defect no external evidence will reveal.
- Review the MVP against what we bind to candidate, extracted
-
A narrower question than "is the new version good": does everything in
bindsstill hold, checked against the deployed page. AuserTask, and the lane admitspersonandagent— a review agent is a legitimate reviewer here, and the separation that matters is the next lane's: a reviewer cannot accept. - Review the schema definition node candidate, extracted
-
Does the node declare what KIND of node it is? Does a widened type carry its mirrors? Does a removed field leave a reason behind, so the next author does not re-add it in good faith? And where the node RENDERS to something the site serves — a colour, a glyph, a theme's tokens — does a Tool maintain that artefact, and does the visual fact have only one home? The node decides; the stylesheet reports.
- Review the Tool node candidate, extracted
-
Does it name skills, and do they resolve? Is the mechanism it advertises the one that actually runs? Are its IRIs minted rather than written out? And the question a covered skill hides: is the COMMAND reachable, or only the skill satisfied? A skill can be served by the neighbours of its mechanism while the mechanism itself is reachable from no node, and check:tools reports it as covered and is right to.
- Review the translation candidate, extracted
-
Coverage, preserved terms and echoes are mechanical. A semantic round trip needs a back-translator that has not seen the original; where none has run, the criterion carries no verdict and that is the honest state.
- Review translation for accuracy candidate, extracted
-
A subject-matter expert reviews the injected translated markdown for: - Clinical/technical accuracy of terminology - Preservation of meaning from the source - Cultural appropriateness for the target locale - Consistency with the domain glossary For WHO content: the SME verifies that normative statements ("SHALL", "SHOULD", "MAY") are translated with the correct force in the target language.
- Review what the substrate offers candidate, extracted
-
Every subgraph, asset class and harness the cached declaration names, each with its current state — referenced, materialised, unknown, stale, or refused by a gate. Shown whole, because a reader who sees only what was chosen cannot tell "not offered" from "not taken".
- Revise the proposed change [content-author] candidate, extracted
-
The editor chose revise: rework the proposed change against the findings the editor reviewed, then send it back through validation as a new proposal. The before/after preview is refreshed with it (skill before-after-preview).
- Root-cause the failure candidate, extracted
-
"Flake" is not a root cause. A red PR is work now, whatever its review state — only a green, mergeable head waits on reviewers.
- Round-trip translation QA candidate, extracted
-
Bean: folio-assistant-ktt2 Back-translates target-language .md to source language and compares meaning. Distinguishes semantic drift from terminology misses. Tool: translation_validate MCP tool No gateway follows: drift or clean, the translation goes to Task_SMEReview with the findings attached. Which of two readings is right is a human call (translation-manager, "route drift to a human reviewer"), and every translation in this workflow is reviewed and signed off anyway, so a clean result is evidence for the reviewer and never a way around them.
- Round-trip translation QA candidate, extracted
-
Back-translate each localized narrative into its source language and compare the meaning, to catch semantic drift and bad terminology that a forward-only check cannot see. Agentic, by the owner's ruling of 2026-10-06 (bean ktt2). Two parties are kept apart under untainted-verification: a back-translator that sees ONLY the target-language text, and an adjudicator that sees the original and the back-translation and rules. The verdict is recorded per block, under criterion
translation-semantic-roundtripin the block's<block>.<locale>.translation-qa.jsonsidecar, by thetranslation-roundtrip-recordTool (translation-manager §5). A terminology miss is a different criterion,translation-terms-preserved(acronyms, numbers, URLs that must survive), so Gateway_Drift can tell the two apart. Never close this step by reversing the PO's msgid→msgstr map: that returns the source exactly and scores 1.0 always. An emptytranslation-semantic-roundtripentry list means "not yet run", which is never a pass. - Round-trip translation QA (back-translate) candidate, extracted
-
Bean: folio-assistant-ktt2 Back-translates the target-language .md into the source language and compares meaning with the original. Detects semantic drift and terminology misses that a forward-only fluency check cannot see. Tool: translation_validate MCP tool
- Route it, and watch the queue candidate, extracted
-
A file goes to ingestion; a link or a description goes to whatever will resolve it. Acquisition stops here — the moment a file is in the queue, library-ingestion owns it, and keeping that seam sharp is what lets a resource acquired through a channel that does not exist yet reach ingestion unchanged. An arrival may be minutes or days away, so it is watched rather than chased.
- Run check:ci-health, WRITING the report file candidate, extracted
-
Run check:ci-health --out, writing the report file before any exit path. Exit 0 clean, 1 live failures, 2 could not check. bun also exits 1 on an uncaught exception, so an exit 1 with no report file is a crash and is treated as could-not-check.
- Run every verifier over the export candidate, extracted
-
Run the verifier set (scripts/publish-verify.ts,
bun run cat publish:verify -- --dir <site>) over the built tree. A SET: each verifier is one entry, and adding one changes nothing else. The first is JSON-LD expansion under a real processor, network refused — a property the context does not declare, a relative IRI or a context that will not load is a finding. Only documents of OURS are verified; third-party data in the tree is counted and cannot block. - Run placement, and raise a bean for the authoring candidate, extracted
-
The offer produces a DECISION, not a node.
placementthen decides instance, graph and node kind — it is the step that catches a hardcoded path or a literal naming one folio — and the authoring itself becomes a bean, because work here is a bean before it is a file.op="note"and notcreate, for the reasonA_CreateBeansabove states: the engine has nocreateop — it claims, notes and resolves the instance's OWN bean. The agent mints the authoring bean itself withbeans create, running the exact-title existence check first, and what this step records is a note that the decision was taken. - Run publication QA gates [content-test] candidate, extracted
-
Publication-readiness QA across layers — QC reports, IG Publisher QA, proof status, broken links, build warnings.
- Run the gate set on the train [code-quality-gates] candidate, extracted
-
Every gate CI runs, on the combination (R2): a member that passes alone can still break
mainwith another. The merge-gate epic (nok9, #1887) adds its gates here when they land. The release security gate (bun run cat security:gate, beanieum) is one of them: it runs inside the gate set, so no train merges past a blocking security finding or a security check that could not run. - Run the gates against the merge of head into base candidate, extracted
-
CI tests the MERGE, not the branch. That is why a locally green tree can go red here: the agent's tree and the merge result are different trees, and the difference is invisible from a checkout.
- Run the health checks, keeping the report either way candidate, extracted
-
Run bun run cat health --out and upload the JSON report whatever the verdict — on unknown it is the only evidence of why the sweep went blind. Exit 0 clean, 1 gating findings, 2 could not check; exit 1 with no report is a crash. The checks report and never act: every finding names something a person does.
- Run the node audits candidate, extracted
-
check:tools,kg:auditandtypecheck. Read the kg-qa sidecar rather than the summary: it is written per node so an inherited defect and a new one are distinguishable. - Run the platform's own gates candidate, extracted
-
Before pushing, not after CI says so.
bun testpassing is NOT the gates passing: measured 2026-09-19, a green unit suite sat beside atscfailure and a missing@graphNodetag, and the second broke a QA sidecar comparison as well — one cause, two symptoms, and an agent running only the tests would have pushed all three. - Run the release security gate [security:gate] candidate, extracted
-
bun run cat security:gate, before anything is built (beanieum, owner 2026-10-07: "security check before release"). It runs every security check this repository has by name: workflow injection, secret leaks, lockfile and toolchain pins, QA reviewer permission, materialised fixity, and third-party action SHA pinning outside staging-only workflows. Each is reported as pass, fail or unknown. A blocking fail OR unknown refuses the publish, because could-not-check is never clean. Until this step existed, no publish or merge process named any security check; they ran only inside the CI gate set. - Run the row's gates tests · e2e · site-links candidate, extracted
-
The
mvpcommands declared for this tenant. For the theme:bun test,CI=1 bunx playwright test(a11y, action tiles, sidebar panels, QA panel) andscripts/site-links.ts --site ./_site, which checks the navbar tiles against the BUILT site rather than against the attribute — the distinction that let a 404 ship unnoticed once already. A red gate is EVIDENCE, not an exit. It does not end the process and it does not loop by itself: "this version breaks us" is a finding the decider needs, not a reason to stop before they see it. - Run the rule's mechanical half candidate, extracted
-
Whatever
patternsandterminologythe rule carries. AjudgementOnlyrule has no mechanical half by declaration, which is different from nobody having written one yet.
S
- Say it could not be confirmed candidate, extracted
-
No URL, no probe, or a failed request. Reported as "could not check", never as "not yet" and never as "live".
- Say what is being decided, and why it matters now candidate, extracted
-
First, and in the message itself: where you are (the Process and task, as which Role, asking whom — from the three determinations), what the decision is, what depends on it, and what is already known — each fact with where it came from. A link is where somebody goes for more; it is never where the terms are defined.
- Say what is needed, and ask for a link OR a description candidate, extracted
-
Both forms, named together. A person who cannot find the file often knows exactly what it is, and a description in their own words is an acquired resource rather than a consolation prize. Asking for the upload first demands the one thing they may not have, before the cheaper answers have been offered. Say what happens if they do nothing.
- Say what moved and where it went candidate, extracted
-
Tell the reader what moved and where it went, so the content can be found in the trashcan rather than inferred missing from a card that disappeared.
- Say where it will be candidate, extracted
-
A measured 404. The author is told the address and that the first build has not landed there yet — which is useful, and is not the same as being told it is live.
- Scaffold the folio (folio_init) candidate, extracted
-
content/, uploads/, library/, the first manifests, <slug>.json and index.config.json (the instance's config inline in its entry; no <slug>.config.json, bean ymvt), the builder shim, AGENTS.md with its stubs, .mcp.json, the session-start hook and the beans store. Refuses rather than overwrites when a folio is already present.
- Scan open issues for match candidate, extracted
-
Search open issues, then recently closed ones, by title and body keywords for one this request belongs to. Requirements may span several issues; note every relevant one.
- Scan the environment opportunities and threats candidate, extracted
-
The external axis, first, per Weihrich. Work the source's categories of environmental change rather than free-associating: societal, governmental, economic, competitive, supplier and market changes, each item recorded with what it impacts. An opportunity is an external element that gives benefit; a threat is one that could cause trouble. Both are outside the subject and largely beyond its control — that is what puts them on this axis, not whether they feel good or bad.
- Scan the repo for content worth importing candidate, extracted
-
Read-only. Classifies candidates into library/ (external source) and content/ (authored here), and reports what it could not classify as its own bucket rather than forcing every file into one of the two.
- Scan the subject strengths and weaknesses candidate, extracted
-
The internal axis. Work the source's functional checklist rather than a blank page: marketing, research and development, management information systems, management team, operations, finance, human resources. A strength gives advantage over others in the field; a weakness places the subject at a disadvantage relative to others. Both are attributes OF the subject. The source's warning belongs to this step specifically: listing strengths on paper "is very different from testing the organization and experiencing the strengths at work", so a strength recorded here is a claim, and where evidence for it exists it is cited.
- Schema and constraint checks [content-validate] candidate, extracted
-
Block schema, label prefixes, required fields, constraint rules.
- Scope the criterion so it stops applying here candidate, extracted
-
One edit to the criterion rather than ten overrules on the blocks it should never have covered. This branch is the one an adjudicator under time pressure converts into a dispensation, and the conversion is a defect: a dispensation lapses when the source moves, so a mis-scoped criterion granted its way past comes back every time anybody touches the block.
- Scope the delta pinned → candidate candidate, extracted
-
Restricted to the directories that reach our output — for a Jekyll theme
_sass,_includes,_layouts,assets. Upstream's own docs, CI and tests cannot reach us, and counting them makes a harmless release look alarming. The changelog is the claim;git diff --stat pinned..candidateover those paths is the evidence. - Scope the sample: which items, which store, and is it PERMANENT? candidate, extracted
-
Three answers, recorded before anything is fetched. WHICH ITEMS: named by the source's identifiers, or by a subset strategy its descriptor supports. WHICH STORE: the knowledge graph or other structured store the import is tested against. PERMANENT OR TRIAL: a permanent sample lands in library/ and is refreshed; a trial lands in fsh-guts/ and is not. The purpose materialize-remote asks for (working or archival) is asked there, not here.
- Scrap the bean, with the reason candidate, extracted
-
The agent's own
beans update --status scrapped; never deleted. - Scrap with reasons NEVER delete candidate, extracted
-
status: scrapped, plus a "Reasons for Scrapping" section. This is what "disable" means here — the CLI has no disabled state; its vocabulary is draft, todo, in-progress, completed, scrapped. DELETION IS NEVER THE ANSWER, even thoughbeans deleteexists. A scrapped bean records that the work was considered and rejected, and why; a deleted one leaves a sibling session unable to tell abandonment from accident, and leaves the next agent free to re-open the same dead end. -
beans list --json / beans query over titles AND bodies, open and recently completed. A completed bean is evidence of a decision already made.
-
The repository's issues (open and closed) and its open pull requests. An open PR touching the same files is the collision most worth finding early.
- Search the published slice in a browser candidate, extracted
-
Open
slices/search.html?slice=<name>on the deployed site, run a phrase search for a known row, open it so its payload is fetched, and look at the result; send the screenshot rather than a description of it. Report the mode the page says it used (OPFS or in memory), never an assumed one. - Search trusted CONTENT — L2 DAKs, L3 IGs candidate, extracted
-
Already-adjudicated guidance: WHO SMART DAKs at L2 and FHIR Implementation Guides at L3. A recommendation adopted in a published DAK is evidence of a different kind from a primary study -- it is a prior decision, with its own provenance, and must be cited as that rather than laundered into primary evidence. NOT YET SKILL-BACKED. This step named
corpus-search, which has never existed. It is notcorpus-grep, whose job is the pre-declaration check that something really is an open gap — searching adjudicated L2/L3 content for evidence is a different task, so pointing the ref there would have been a plausible-looking wrong answer. Left uncovered until the skill is written. - Search trusted SOURCES — L1 [document-intake] candidate, extracted
-
Ingested primary literature under library/: the sections/*.md tree and, where a document was scanned, ocr/page-NNN.txt. NOTE the known blind spot — a document OCR'd but never re-run through pdf-structure.py has only a stub in sections/, so a sections-only search misses it.
- Secure the agent's permissions candidate, extracted
-
Once the actor is known and the record is open, check that the coding agent acting here holds the permissions this instance's processes need, granted by a person and recorded, and ask for any that are missing. This is where initiating the harness for an actor secures them, rather than the first denied command. A run that finds them current returns without asking anything; the same process is called on demand when an action is denied later in the session. Vendor-neutral: the agent is a Tool, and its config is written through that Tool's adapter. Skill: agent-permissions.
- Seed the work plan candidate, extracted
-
The first beans: what the author said they want to get started on, one bean per top-level content object they named.
- Seed the work plan [todo-manager] candidate, extracted
-
The plan becomes beans. From here on, beans/ is the shared answer to 'what is done, what is next' — for humans and agents alike.
- Select the methodology by context candidate, extracted
-
Ask the selection question in order, first yes decides: do the criteria RECUR with the same inputs having to produce the same answer; is this the CERTAINTY of a body of evidence behind a recommendation; is the context a BEAN recording a decision; otherwise a one-off choice among candidates. If none fits, that is a finding — say which question the decision is and that no adopted methodology covers it. Do not improvise one and do not stretch the nearest fit. The declared set is the contents of the
methodologygraph. Ask for it; do not remember it. - Separate this graph? candidate, extracted
-
The owner decides from the measured signals, and also decides the address base for its identifiers, where verdicts about it live, and what its tools repository owns. Declining is a real outcome: the graph stays where it is.
- Serialize to JSON-LD candidate, extracted
-
kg-export, already built and host-agnostic by design. Every edge term declared {"@type": "@id"} — without that coercion the document is a list of records that merely LOOKS linked, and the node IRIs are fragments of the document's own @id so the graph is mergeable with anyone else's.
-
Outer loop: the BA presents the accumulated increments to stakeholders as a testable MVP. Staging URL, demo, or walkthrough.
- Sheet names, headers, shape, narrative candidate, extracted
-
NOT IMPLEMENTED. Tracked as a bean; see docs/document-ingestion.md. CSV and spreadsheet: tabs, column and row headers, sizes, and what the dataset is about.
- Should it leave now? candidate, extracted
-
The owner decides, from what is measured, whether the sub-KG starts staging for separation now. Asked as numbered options with the recommended one first and a stated default: keeping it in place is the default, and is a real outcome.
- Sign as release authority candidate, extracted
-
A person attests the run hashes out of band. This is a userTask, not a serviceTask, and the distinction is enforced:
fulfilmentKindsForBpmnTypewill not let a system actor fill it, which is what stops the air-gapped route quietly becoming another machine route. - Sign off on requirements candidate, extracted
-
The business analyst / requester signs off on the agreed requirement set, on the issue: what was agreed and what was deferred. Recorded as their decision, with its reason, never by an agent on their behalf. Since issue #2405 (FR-013) it IS an adjudication: it calls Process_Adjudication with the requirement-set answers, and every answer goes through A_RecordSignoff before anything follows it.
- Sign off translation (human adjudicator) candidate, extracted
-
A human reviewer signs off the translation at the chosen hierarchy level (block, section, chapter, or folio). Updates status.json: { official: true, signedOffBy: "...", signedOffAt: "...", sourceHash: "..." } Tool: translation_signoff MCP tool
- Sign off translation as official candidate, extracted
-
The reviewer signs off the translation, making it official. This records: - signedOffBy: the reviewer's identity - signedOffAt: the current timestamp - sourceHash: SHA-256 of the source .md - level: block | section | chapter | folio Tool: translation_signoff MCP tool
- Sign over the API candidate, extracted
-
The attestation service signs the run hashes. Reached only from the one table row that has both egress and a configured endpoint.
- Sign the certification candidate, extracted
-
qa-report-signing.bpmn, unchanged: it builds the signable run record, resolves the signer's reach, and routes the signature to the API or to a human release authority. - Sign the package and/or each asset candidate, extracted
-
THE TRUST ANCHOR IS GDHCN, SPECIFIED BY THE WHO SMART TRUST IG (owner, 2026-09-20, paraphrased: proposal signing is GDHCN, as the WHO SMART Trust IG specifies). READ OFF THAT IG rather than from general knowledge: a GDHCN trustlist distributes KEY MATERIAL as W3C DID documents, and says nothing about what you wrap your bytes in — the health-certificate envelope is a separate specification in the same IG, and a document package is not a health certificate. So what is settled is where a verifier GETS THE KEY, not what it verifies. A portal that can fetch the bytes but not reach the trustlist cannot verify, which is
unknownand not a failure — air-gapped is a declared deployment value, so that case is answered rather than assumed away. Still OPEN and unread: the rotation and revocation model, and whether a document-package signature can be expressed for a GDHCN-aware verifier at all. Two schemes with different properties remain to choose between, and the trustlist does not choose between them. A PACKAGE signature over the manifest verifies the SET — nothing added, removed or altered — and must be reissued whenever any file changes. A PER-ASSET signature verifies one file independently, which is what an edge cache serving one asset can actually check, and it cannot detect a removal because there is nothing left to verify. They compose; composing them is the safer and more expensive default, and it is the deployment's choice rather than the pipeline's. - SIZE what fraction, and what the whole would cost candidate, extracted
-
What is being taken, and what the whole collection would cost. REFUSES when it cannot tell: 'three items' with no denominator is not a size answer. 0.7 TB is the measured reason the IRIS import is by reference.
- Skill-registration chain (UNMASKED) candidate, extracted
-
Runs the five
--checkcommands that adding a skill stales, each on its own: gen-skill-docs, check:glossary, auto:docs:check, kg:audit:check, kg:detangle:check. CORRECTED 2026-09-26, after main split this workflow: the original justification is GONE. It read "the only place those five are read against the tree as checked out", because at the time all six lived in one job behindbun test, which runs the kg-audit and detangle WRITERS and repaired two artefacts before their checks read them (beanymsu). Task_RepositoryGates is now a separate job that runs all six and never runsbun test, so they are unmasked THERE. What survives is narrower and is the reason this is kept: one command a skill author runs (bun run cat skill:register) that regenerates and verifies the chain together, a committed QA sidecar saying which steps ran, and ONE named failure instead of six unrelated generated files — which is beanv625's actual complaint. The unmasking argument belongs to Task_RepositoryGates now. Its first CI run earned the place: it went red onkg:detangle:checkand the cause waskg-detangle.tscounting 1214 files of a gitignorednode_modules/as graph nodes — 1441 where a clean checkout computes 227, pinned in a committed sidecar. Not a step in front ofbun testeither: measured on main's run 36234052354, a failing step SKIPS every step behind it, so a red there would turn one named failure into forty-five unevaluated ones. 13s, in parallel. Beansv625,fjwi. - Slice the change and assign reviewers candidate, extracted
-
From the ChangeSet, its rendered list (skill rendered-impact: each changed rendered page is assigned like a changed block) and the heat map on the review page: cut the change into slices a reviewer can hold (usually a section, or a run of sections where the heat map clusters), and assign each slice to a review lane by what it contains — clinical content to a clinical SME, a decision table to a QC reviewer, prose to a narrative reviewer. A block that needs no review (a pure rename, say) is WAIVED here with a written reason, which is what the coverage gate counts. Re-entered from GW_Covered when coverage is incomplete: the uncovered blocks become new slices.
- SOURCE LOSS what survives if the origin goes candidate, extracted
-
Not hypothetical. The one IRIS record this repository holds carries a handle on iris.wpro.who.int, a regional instance merged into the global one. Only an ARCHIVAL copy of the original bytes discharges this; a working copy cannot, because the derived sections are not the publication.
- Splice onto the tip and push (never -f) candidate, extracted
-
Fetch the branch tip, splice this entry into its tree,
commit-tree -p <tip>, and push without-f, withpack.useSparse=falseso blobs already on the remote under another key are not resent. Writers own disjoint keys, so splicing onto whatever tip is current loses nobody's entry. - Split into sections/*.md with doc_brief front-matter candidate, extracted
-
Contextual retrieval: a chunk in isolation loses what makes it mean anything, so each section carries the document brief.
- Stage the rendering candidate, extracted
-
site.ts --root <instance> --out <dir> [--subgraph <id>]…: every JSON Schema and JSON-LD document at the IRI it names, the files as they sit, the README page as README.md (served as README.html), and index.html as a redirect to it — the default landing page, which an index.html or index.md at the instance root replaces. Generated pages carry the generated-by notice at their top, and a footer that links their generator and source, never an edit page.
- Start the Pages build and derive the URL candidate, extracted
-
scripts/pages-bootstrap.ts: check the gh-pages branch first (absent is
unprovisioned), derive the site URL from the git remote or the instance's config (its index.config.json entry), report whether a publish workflow exists and the Pages source it needs, and optionally probe until the site answers. - State the constraints, with denominators candidate, extracted
-
Money, network traffic, graph size, latency. Each needs a NUMBER and each number needs a denominator, because a constraint with no denominator is a preference: "the graph is too big" is not a finding, "6.2 MB per publication against a 100 GB free tier" is. Say which figures were measured, which were quoted from a vendor, and which could not be obtained — a figure from a chat message is none of the three, and the who-iris catalogue carries the worked example where "0.7 TB" propagated through ten files and the measured figure was about half.
- State the finding and what it read candidate, extracted
-
Each provider says what it found and on what evidence. A finding that does not show what it read is an opinion, and an adjudicator cannot tell it from a finding about some other version of the block.
- Store the signed report on qa-reports candidate, extracted
-
The signed report, its signature and the route that produced it are written TOGETHER into the
qa-reportsentry keyed by the commit the report judged (main/<sha>/orpr/<n>/<sha>/), throughscripts/qa-store.ts— never committed to main and never pushed by hand (arc3fva, owner ruling D1). A signature kept apart from the bytes it covers attests nothing a reader can check. A certification DECISION taken on the report is a separate node that stays on main besidetest/attestations/(ruling D5, default (a)); it is not written here. - Stream W3C N-Quads into Subgraph Partitions candidate, extracted
-
Serialize lines conforming to W3C RDF 1.1 N-Quads (subject predicate object graphIri .). Split into Tier 1 Spine (routing backbone) and Tier 2 Subgraphs (communities, domains). Compress each into .nq.gz.
- Submit completed .po file candidate, extracted
-
The translator submits the completed .po file back to the pipeline. This may happen via: - Git commit + push - Weblate/Crowdin sync - File upload to the coordinator
- Submit to review committee candidate, extracted
-
Author submits the PR for formal review by the guidance review committee. The STAGING URL is the review surface.
- Swap cards below the threshold; leave open windows alone candidate, extracted
-
Cards whose rendered width is strictly below the threshold swap to their avatar — automatic, driven by size. Open windows are left alone: semantic zoom and open/close are two mechanisms and must not be conflated.
- Sweep positions whose note is gone candidate, extracted
-
Remove every position in this board's layer whose note no longer exists. The sweep edits only the layer — one file, one pass — and never a note a person owns; a stale position must not keep a note alive.
- Syntax, spelling and links [content-validate] candidate, extracted
-
Syntax, spelling, cross-references, citation and link resolution.
- Synthesise, cite to a location, and say what was not found candidate, extracted
-
The paper's Reporter, with two obligations it does not state. CITE TO A LOCATION, not to a document — the page and bounding box the parse preserved, so a reader verifies a claim where it was made rather than being sent to a PDF. AND SAY WHAT WAS NOT FOUND. The failure this method makes easy is that a search which ended quietly looks exactly like one that succeeded. Sub-questions that returned nothing are reported, distinguishing "not in the corpus" from "not found by this search" — only the first is a fact about the folio. A figure description an agent drafted is NOT reported as what the figure shows.
schemas/narrative.tsholds that line and this step does not cross it.
T
- Take in the turn candidate, extracted
-
A turn is anything that arrives — a person's message, a tool result, a notification. The machine advances on turns rather than on a clock, because a session that has been told nothing has not changed.
- Take the next PR in queue order candidate, extracted
-
Owner overrides at their positions first, then by the table's rank, then by PR number, oldest first (
scripts/merge-queue.tsorderQueue). - Test MVP in own context candidate, extracted
-
Stakeholders test the delivered feature in their own workflow, with their own data. They report what works and what does not.
- The RULE is the defect — bean it candidate, extracted
-
A rule its own quote does not support is a finding against the voice, not against the block. Measured precedent:
voice-editorializingflags "clearly", and the exemplar the Milnor gate is named after uses it fourteen times as proof economy (bean2t41). - Theme and UI review [theme-ui-review] candidate, extracted
-
THEME REVIEW HAPPENS HERE AND NOWHERE ELSE. Owner, 2026-09-23: "theme review to ingestion of graphical assets in context of website or app design and determining graphical assets/UI"; asked directly on 2026-09-24 whether that meant ONLY at ingestion: "Yes only at ingestion". Bean
9fdi. So this step now CALLStheme-ui-review.bpmnrather than performing one automated check out of it. Until 2026-09-24 it carried afolio:no-callreason — "calling it would put a human gate into an automated ingest" — and the review ran post-MVP fromcrdm-deliver.bpmninstead. That call is gone, and the reason for not calling is withdrawn rather than left standing beside a call it contradicts. WHAT THE CALL COSTS, stated rather than hidden. The subprocess has a human step,R_Judge: a person looks at the ingested assets laid out in their design at a web and a mobile width. So ingesting a THEME SOURCE is attended at that step. Ingesting anything else stays unattended —Gateway_ThemeSourceindocument-ingestion.bpmnroutes non-theme documents past this subprocess entirely. THE OLD AUTOMATED CHECK IS INSIDE THE CALL, NOT DROPPED. "A theme sets the stripe's hue; it never sets its width to zero" — colour alone carrying a whole signal fails WCAG SC 1.4.1, and the WHO guide agrees ("Never red with green, never blue with yellow"). That check isA_Accessibilityin the called process, which measures contrast against the real ground and requires a non-colour channel wherever colour carries meaning. - Transcribe and translate audio candidate, extracted
-
NOT IMPLEMENTED. Tracked as a bean; see docs/document-ingestion.md.
- Translate feedback into agent direction candidate, extracted
-
The BA translates stakeholder findings into actionable direction: new beans or bean updates for the agent.
- Translate strings in preferred tool candidate, extracted
-
The translator works through each msgid, producing msgstr translations. They: - Follow the domain glossary for technical terms - Preserve placeholder tokens ({1}, {2}) in position - Mark uncertain translations as #fuzzy - Note any source ambiguities for the coordinator
- Triage published feedback [content-feedback] candidate, extracted
-
Implementer and reader feedback on the published folio, triaged by severity and scope.
- Triage the failure: hold or fix forward candidate, extracted
-
The publication manager reads what failed and decides: hold the release, or fix forward and publish again. Nothing was deployed on a failure before the deploy; a failure after it (the deploy itself, or the previews lost) is live, and says so. The next successful publish closes the issue.
- Triage: confirm the anchor, type and priority candidate, extracted
-
public-comment triage / reassign / duplicate. An unplaced or low-confidence anchor is placed here, by a person.
- TypeScript: lint, types and tests (HARD) candidate, extracted
-
Three checks:
bun run cat lint,tsc --noEmitandbun test. The repository gates it used to carry are Task_RepositoryGates now (beanom30). Since beandlquit is split across jobs:typescript-static(lint, then typecheck),typescript-test(bun testas four SEQUENTIAL shards on separate machines — Bun's in-process--parallelworker pool hung at both 4 and 2 workers, measured — the shard passed inBUN_OPTIONSso the command stays the onebun run cat gatesruns locally) each shard andtypescript-staticits own required check. A fourth job,typescript, carried one check name for all of them and was green only when the others succeeded; bean5p4m(issue #2456) removed it — a runner request for ~1 s of work that waited minutes for a runner — so branch protection names the five checks directly. The step-order rule the single job needed —bun testLAST, because Actions stops at the first failing step and a red-by-decision test would otherwise mask lint and typecheck — no longer has anything to order: separate jobs cannot mask each other. Measured on threemainruns before the change:bun testalone was 7m30s-7m45s of an 8m14s-8m33s job.
U
- Use the checkout path in place candidate, extracted
-
A
directorysource IS its declared path. Nothing is mounted; a write is an ordinary commit on the working branch, which is whybranch-store pushanswers "commit through git" for it rather than pushing anything.
V
- Validate Arguments against Parameter Schema candidate, extracted
-
Look up query definition by queryId in distribution manifest. Validate supplied arguments against parameter types, required fields, and pattern constraints.
- Verdict reuse: tree already green? (NOT A GATE) candidate, extracted
-
Bean
qbco, issue #2456 (owner, 2026-10-07: "1y, 2y, 3y, 4y"). On a PUSH tomainonly; on any other event it is skipped and nothing waits for it. A merge-button merge of an up-to-date PR carries a tree CI has already tested.verdict-reuse.shlooks up the runs of this workflow on the merged head (the merge commit's second parent) and answersreuse=trueonly when one concludedsuccess, ran every job a reuse would skip, and tested exactly this tree: for apull_requestrun, thetested-tree:its Task_QaWorkingCopy job wrote into its check run's summary; for a dispatch, the head's own tree. Then the fourbun testshards (part of Task_TypeScript), the three e2e shards (Task_E2E) and the standalone ratchet (part of Task_RepositoryGates) are skipped on this push, and the summary names the run whose verdict stands. Everything that judges the tree againstmainor readsqa-reportsstill runs. A squash, an API error, a missing record or a mismatch isreuse=falseand every job runs: could-not-determine is never green. Drawn before the fork because the jobs it can skip wait for it; the others do not. Since the same ruling, a newer push tomainalso cancels an older main run still in progress (the workflow'sconcurrency), so main's verdict history is thinned by decision. -
Each candidate is resolved against the standard API of the body that publishes it, so that 'authoritative' is a RESOLVED FACT rather than an assertion in the citation. What is checked: that the identifier resolves at the publisher; that the retrieved record matches what the citation claims; that the version and date are the ones cited; and that the publisher is one this folio has declared trusted. STRAWPERSON: the concrete registry list and endpoints are not settled here -- see the cat-harness.processes:policy note.
- Verify Queries via CLI & Test Graph Availability candidate, extracted
-
Execute named queries using scripts/nquads-query.ts and the nquads-query MCP tool. Assert that missing partition triggers MissingPartitionError and typed parameters prevent injection.
- Verify the export [publish-verification] candidate, extracted
-
Process_PublishVerification: the verifier set over the built tree, before anything is deployed. Owner, 2026-09-23: before deployment, blocking.
- Verify the ORIGINAL still hashes to its digest candidate, extracted
-
check:materialized-fixity. Run against the SOURCE, not the copy — the copy is new content with no claim to verify, and the source is the thing a botched copy-out would have disturbed. A mismatch here means the copy-out was an edit in place wearing a copy's clothes, and it is the only signal that tells the two apart. - Verify what arrived against what was signed candidate, extracted
-
Against a GDHCN DID trustlist, which means the verifier needs THE NETWORK and not only the bytes — the key is resolved from the trustlist rather than read out of the package. The trustlist is itself static JSON served from a CDN (
tng-cdn.who.int), and its path is a hierarchical filter — domain, participant, key usage, with-as a wildcard — so a verifier fetches the slice it needs rather than the whole list. WHO's own trust network is therefore the same shape as this diagram one layer down, which is the strongest argument the design has. The stage that gets dropped, because every other stage produces something visible and this one produces nothing when it passes. A package that is signed and never verified is a package whose signature is decoration. A portal that CANNOT verify reportsunknown— a portal nobody asked is not a portal that checked. - Version, tag and publish [content-publish] candidate, extracted
-
Version bump, release notes, tag, build the final artifacts, deploy to the publication platform. The deploy is the general render-kg-to-cdn step with the RELEASE root as its publication root URL — the same step a staging preview takes with a root under it; the target (GitHub Pages, or a folio's own platform) is chosen by its Tool.
- Voice overlay review candidate, extracted
-
Descend into Process_VoiceReview for whichever named voices the folio has ACTIVATED — the WHO editorial style, the guideline-development register, the publication design conventions, the Milnor exposition standard. No new role is taken on: register is what this lane already judges, and a voice is a register. Placed after the base voice adjudication because a voice OVERLAYS the house voice rather than replacing it, so the house finding has to be settled first. Its own first gateway leaves immediately when no voice is active, which is this instance's case and the default everywhere.
W
- What changed LOCALLY since candidate, extracted
-
The half nothing answers today. A materialized copy that was edited in place is not a copy any more, and overwriting it silently destroys work whose existence the process never established.
- Wire it: gate, deploy line, search, tests candidate, extracted
-
Give the slice everything a slice owes: its manifest (written by the builder from the definition), its
--check(covered byslice:sqlite:check), one deploy line indocs-site.ymland infeature-staging.yml, its search (the generic page needs no code, only the definition'ssearchblock), a unit test over a fixture and over the real source, and a search inslice-sqlite.e2e.ts. - Wireframe candidates (web + mobile) candidate, extracted
-
Design use of wireframe-design-review, before implementation: a written design intent, at least two mid-fidelity candidates each with a web and a mobile layout, the mechanical checks, and a blind review. The candidates are committed as assets of the request's proposal, under docs/proposals/<slug>/wireframes/ beside docs/proposals/<slug>.md, on the feature branch so feature-staging publishes them, and shown where the requester will look, chosen from context — the conversation, the issue the request came from, the pull request, or several of these — each place carrying the same staging deep links and screenshots (staging-review, the deep-link rule, point 5: where it goes is a judgement). The requester or BA is the human reviewer and chooses one at BA_ReviewReqs. The owner asked for this on 2026-09-23 (methodologies/wiregen.md): a wireframe is part of the design process for adjudication. The candidates ARE the options A_CompareOptions lays out, so this merges into it rather than producing a second comparison.
- Withdraw a review comment [folio-review-comment-move] candidate, extracted
-
The reviewer who made a comment takes it back (it was a misreading, or a later slice answered it). Recorded with
folio-review-comment-move --to withdrawn, committed to the edit-set's feature branch like every status change. This is thewithdrawtransition of REVIEW_TRANSITIONS. - Work, keeping the body current (this is 'edit') candidate, extracted
-
Editing a bean is not a separate ceremony: check off todo items as they happen, append measurements with the command and date that produced them, and record what you now know that the next agent does not. A bean whose body is a title is a placeholder, not a plan.
- WORKING what changed upstream candidate, extracted
-
Compare the recorded upstreamVersion against the source.
could not reach the sourceis a THIRD answer and is never reported asunchanged— an unreachable source is the sourceLoss gate firing late. Reachability is asked bybun run cat sources:liveness <instance>against the node's resolvable IRI, its Handle first: live, gone, or could not determine, never live on an error (bean 08u4). - Write dublin-core.jsonld (the record of truth) candidate, extracted
-
One standalone Dublin Core record per folder. dcterms is already this corpus's JSON-LD vocabulary, so this extends a live context rather than introducing one.
- Write it through the Tool's adapter candidate, extracted
-
The exact diff the owner saw, nothing more, written by the person or by the agent under their consent to that diff. Hand-edited agent config only; generated projections are CI's (harness-projections).
- Write manifest.jsonld referencing it candidate, extracted
-
Write manifest.jsonld for the folder: its @id, @type folio:SourceDocument, what it contains and its provenance, referencing the standalone dublin-core.jsonld as the record of truth rather than copying its fields.
- Write status.json (official) candidate, extracted
-
Writes translations/<locale>/status.json with the official sign-off metadata and source hash for staleness detection.
- Write status.json (official) candidate, extracted
-
Records the sign-off with the SHA-256 of the source .md, enabling staleness detection on future source changes.
- Write status.json (unofficial) candidate, extracted
-
Records the translation as unofficial in translations/<locale>/status.json: { official: false, generatedBy: "...", generatedAt: "..." } The translation is usable but carries a visible warning badge.
- Write structure.json (TOC, page ranges, metadata) candidate, extracted
-
Write structure.json (pdf-structure/v1): doc id, TOC from the PDF outline or inferred from headings, page ranges, metadata, and source{} with the sha256 and a mimetype sniffed from the bytes, never the extension. A structure that could not be determined says so in structure_note rather than being rendered as one. For OCR'd text, source.runContext cites the OCR step's run context by sha256. A title already known for the document (the catalogue's dc.title, or one given with --title) is passed through as the raw title, so the sections' doc_title does not carry a scan's misreading (bean turh).
- Write the design intent candidate, extracted
-
A short statement of who the screen is for, what they need to do, and what it must show. It is the criterion every candidate is judged against.
- Write the entry and cache the declaration candidate, extracted
-
The
subscriptionsentry in the subscriber's instance declaration — id, repository, ref, and nothing chosen yet — plus a cached copy of the substrate's declaration at the pin. The entry holds the choice and the pin, never state: whether a part is held is answered by its materialisation record, and a second answer here would be free to disagree with it. - Write the entry that LEADS — keeping the checker's beneath it candidate, extracted
-
Not relaxable, and the one step here that is not. A judgement nobody wrote down is indistinguishable from a checker that was never run, so the judgement is free and the record is not. Do not resolve the disagreement away: both entries stay, the adjudication on top under the sweep's most-recent-matching-hash rule. A disagreement between a checker and a reviewer is information, and somebody re-running the check next month needs to find that a checker read it differently rather than a clean pass.
/api/relevance/adjudicatereached the same rule independently —human_adjudicatedwritten alongside, never over, the agent'sassessed_by. - Write the lock candidate, extracted
-
index.lock.jsonbeside the downstream'sindex.config.json(the legacy<instance>.mount-lock.jsonis still read, and is renamed onto the new name when rewritten; both present is an error): the pins it was written for, each instance's repository, SHA and how the pin was found, each directory's tree digest — and what was NOT mounted, with why, so an offline check cannot read a gap as clean. - Write the note into the folio — with no coordinate candidate, extracted
-
A new note: write it into the folio with no x, no y, no board and no position. A folio is complete with no board, and one note may sit on several boards, which a coordinate on the note could not express.
- Write the root README, if it is not there candidate, extracted
-
The repository now IS an instance of something, and nothing at its root says so. It carries a LINK to the harness that was installed and the OVERALL install status across every location — WHEN ABSENT, never replacing: where a README is already there, the link and status go in a marker pair the harness's own README tool maintains. WRITING IT IS NOT A PROCESS WRITE.
instance-readmedeclareslayer: context, and this step writes one. Both hold, because INITIALISATION IS NOT PROCESS RUNTIME: the rule governs a process operating on an instance that exists, and this is the act that brings the instance into being. - Write the slice definition candidate, extracted
-
Add one
SliceDefto the builder's slice table: the DDL (one table per node type, edge tables, one CONTENTLESS full-detail FTS5), the order each table's rows go in, theloadthat turns the source into rows, where the payloads live (written at deploy, or already published), and thesearchblock the generic page reads. Choose the heavy fields bykg-export§"What is heavy": a heavy field is apayload_sha256pointer, never a stored column. Never copy the builder. - Write the test run and the test report [folio-test-run/v1 + test-report/v1] candidate, extracted
-
The run records
plan {id, version}andsut {actor, version, reach}with its data and process hashes; the report rolls up per plan, never across plans, and goes to theqa-reportsbranch attests/plan/sut/run/. No verdict in it may name the system under test as its reviewer. - Write what changed candidate, extracted
-
An instance opened or closed, a bean claimed, a wait started or ended. All by REFERENCE: the bean and the instance are each the authority on themselves, and a status copied here would be free to contradict them. NO
cat-harness.processes:beanon this step. It records that a claim happened; it does not claim.