# configuration/strings/build.strings.ts
> 136 lines of code and 8 definitions.
Tree: Site tree
Language: typescript
Layer: product
Canonical: https://banes-lab.com/anatomy/tree#file-configuration-strings-build-strings-ts
Source text: https://banes-lab.com/assets/sources/source.b13e8a9af4c0252f339ac0d28d0f59966b2e84bb7cc3ba30e91f9d9cb727c1d6.generated.txt
## Definitions
- `LOOP_DIAGRAM` (lexical_declaration, line 6)
- `FINDING_SAMPLE` (lexical_declaration, line 9)
- `GATE_DIAGRAM` (lexical_declaration, line 12)
- `ORDER_DIAGRAM` (lexical_declaration, line 15)
- `DETECT_SECTION` (lexical_declaration, line 18)
- `GATE_SECTION` (lexical_declaration, line 64)
- `ORDER_SECTION` (lexical_declaration, line 104)
- `BUILD_SECTIONS` (lexical_declaration, line 144, exported)
## Source
```typescript
import { DETECT_SECTION_ICON, GATE_SECTION_ICON, ORDER_SECTION_ICON } from "#configuration/icons/build.icons";
import { DETECT_SECTION_ID, GATE_SECTION_ID, ORDER_SECTION_ID } from "#core/ids/build.ids";
import type { Section } from "#types/document.types";
import { TEXT_LANGUAGE } from "#configuration/constants/code.constants";
const LOOP_DIAGRAM =
'flowchart TB\n detect["Detect · the one command, fixers on"]\n heal["Heal · every finding with one correct answer, in the same run"]\n report["Report · the findings the fixers left, as data on disk"]\n fix["Fix · the model, one finding at a time, from the report"]\n detect --> heal --> report --> fix\n fix -- until the report is empty --> detect';
const FINDING_SAMPLE =
'engine/registries/route.registry.ts:41\n rule literal-in-lookup\n locus the first argument of the lookup call\n trail resolved the callee verb, matched the lookup form, read the argument\n expected an imported constant as the lookup key\n found the string literal "home"\n fix replace the argument with the id from the ids module: HOME_PAGE\n healed no';
const GATE_DIAGRAM =
'flowchart TB\n pattern["A new pattern enters the tree"]\n ships["The check ships in the same change, with a planted violation"]\n slips["A violation slips past the check"]\n appended["The check is extended first, then the content is repaired"]\n inconvenient["A finding is inconvenient"]\n stays["It stays a finding · no warn tier, no exclusion"]\n disagree["Two checks disagree on one line"]\n derived["Both stay on · the form that satisfies both is derived"]\n uncheckable["A pattern no static check can catch"]\n surfaced["Surfaced as a question, never used as license"]\n pattern --> ships\n slips --> appended\n inconvenient --> stays\n disagree --> derived\n uncheckable --> surfaced\n ships ~~~ slips\n appended ~~~ inconvenient\n stays ~~~ disagree\n derived ~~~ uncheckable';
const ORDER_DIAGRAM =
'flowchart TB\n write["Write the check"]\n plant["Plant a violation"]\n fires{"Does it report the expected message?"}\n real["Run it over the real population"]\n passes{"Does at least one real member pass for the right reason?"}\n restore["Restore the planted file"]\n code["Write the code the check holds"]\n write --> plant --> fires\n fires -- no --> write\n fires -- yes --> real --> passes\n passes -- no, everything fails --> write\n passes -- yes --> restore --> code';
const DETECT_SECTION: Section = {
icon: DETECT_SECTION_ICON,
id: DETECT_SECTION_ID,
intro: "Seen from outside, the work is one cycle, as shown in the loop from outside. The tools run with their fixers on and report what the fixers could not repair. The model then fixes what the report names, and the tools run again, until they report nothing. The cycle closes because the tools speak to the model in a typed format, the finding shown in an actionable finding, and because the report on disk holds the state of the work rather than the output of a single run. The architecture page arrives at the same contract from the author's side: because the author is probabilistic, a finding is the contract between the check and the model.",
subsections: [
{
blocks: [
{
application:
"In practice, the model is given the finding rather than the rule: which file, which line, what the tool expected, what it found, and the one action that would close it. It is asked to repair that and nothing else, and the tools run again once the tree has changed.",
boundary:
"A finding whose only repair the toolchain refuses to perform is withdrawn or exempted, with that refusal given as the reason. A report that can never be emptied teaches you and the model to discount its colour, and the findings beside it pay for that.",
cause: "A principle has to be turned into an action again at every line, and the model is likely to turn it into a different action each time.",
decision:
"The effort goes into the check that produces findings, rather than into the explanation that produces agreement.",
failureMode:
"You explain the architecture at length, the model agrees, and the next file it writes breaks it in a way the explanation did not anticipate.",
kind: "lesson",
principle:
"For this reason I give the model specific findings rather than abstract principles, because a model refactoring against a finding tends to do better than a model generating from a principle.",
problem:
"Telling the model about your principles and hoping for compliance does not hold across a session.",
validation:
"To check this, compare a session driven by findings with one driven by explanation, and count the fixes that stuck. The findings session should keep more of them; if it does not, the findings are not specific enough.",
},
{
kind: "text",
text: "Healing comes before reporting, and the ontology calls this auto-remediation. A violation whose repair has exactly one correct answer is repaired in the same run that caught it, without the developer or the model asking: a missing type the grammar computes, a form the registry records, or a name whose only legal spelling can be derived. The fix flag can switch healing off but never on, because a fix that has to be opted into turns a computed repair into a queue of work. A fix is applied, validated again and converges, so applying it twice changes nothing, which is idempotency; a fix that fails its own check is not a fix. What reaches the model is what remains: the findings that need judgement, such as which concern a file belongs to, whether two roles should be split, or where a duplicated fact should live.",
},
{
kind: "text",
text: "The error log is how the tools talk to the model, so it is typed. A finding carries the id of the check that fired, the path and the position inside the file, the steps the check took to reach its result, the value it found, the value it expected where one can be derived, a repair stated as an action with real operands, and whether the fixer already applied it. Prose in a finding counts as a defect, because the model reading it should not have to repeat the analysis the check already did. A sentence describing a rename is only a description, while the action and its two operands are a contract the model can carry out.",
},
{
kind: "text",
text: "Because every run leaves its report on disk, the reports also serve as audit logging: you can go back and read what each run found, as described in a report, not a checkbox.",
},
{ caption: "the loop from outside", kind: "mermaid", text: LOOP_DIAGRAM },
{ code: FINDING_SAMPLE, kind: "code", language: TEXT_LANGUAGE, title: "an actionable finding" },
],
title: "Detect, heal, report, fix",
},
],
title: "Detect, log, fix",
};
const GATE_SECTION: Section = {
icon: GATE_SECTION_ICON,
id: GATE_SECTION_ID,
intro: "You can write a rule down and the model may follow it for a while, but nothing notices when it stops, which is why every rule in this method comes with a check. a check's events shows what happens to that check once it exists. Every other rule depends on this one. The point is not strictness for its own sake: a rule held by a check costs the same to hold on the thousandth change as on the first, while a rule held by attention costs more each time. The checks are fitness functions, and what they do is policy enforcement. The architecture page turns the same idea into an account of decay, in which an anti-pattern is a decay path, and the section seven controls, seven classes places each anti-pattern by the check that was missing.",
subsections: [
{
blocks: [
{
application:
"In practice, the check is written the moment the pattern is introduced, and it is made to catch the pattern's bypasses too. When a violation slips past it, the check is extended before the content that slipped is touched, so the gate gets stronger before the cleanup. A check is never weakened, a case is never excluded to make the run green, and no tier softer than failure is added.",
boundary:
"A pattern that no static check can catch is a question for the developer who owns the work, not a license to skip the check. The honest answer to that question is a rule declared unobservable, with the evidence a check would need written beside it.",
cause: "Convention decides a rule again at every use, and the model has no reason to decide it the same way twice.",
decision:
"The check ships in the same change as the rule, rather than the rule now and the check when it bites.",
failureMode:
"The team agrees on a rule, you tell the model about it, and a month later half the tree follows it, because nothing ever refused the other half.",
kind: "lesson",
principle:
"For this reason I hold a rule with a check rather than with discipline. A rule holds only while a check enforces it: the model's attention and yours both drift, and the gate runs the check on every change regardless.",
problem: "Convention does not survive contact with a model or with a tired developer.",
validation:
"To check this, introduce the pattern's nearest bypass and confirm that the same check reports it. A check that catches the pattern but not its bypass holds the line on one side only.",
},
{
kind: "text",
text: "The check is the fix, and the content edit is the cleanup. The order matters because a repaired instance with an unrepaired check is the same defect waiting for its next instance, and the developer or the model who found it has already spent the attention it would take to find it again. A caught duplicate, a caught escape hatch and a better approach discovered mid-task all call for the same response: the affected rule is extended to cover the shape.",
},
{
kind: "text",
text: "Every check returns pass or fail, which applies fail fast to the gate. There is no warning tier and no advisory level, because a middle tier would let a run finish as successful while a failure is still open, and the verdict is binary to prevent exactly that. A red result that is tolerated is flaky test normalization under another name. Severity survives only as the order in which failures are repaired, never as a softer verdict, so a check that would warn is either promoted to a failure or deleted. The same refusal covers exclusions. A finding is resolved by fixing the code, or by proving that it tests a false premise, in which case the finding is deleted; it is never resolved by widening an exemption or disabling the rule for one file.",
},
{ caption: "a check's events", kind: "mermaid", text: GATE_DIAGRAM },
],
title: "The check is the rule",
},
],
title: "The gate holds the line",
};
const ORDER_SECTION: Section = {
icon: ORDER_SECTION_ICON,
id: ORDER_SECTION_ID,
intro: "A check is proven before it is trusted, as shown in the order. The proof has two halves, and each catches a failure the other cannot. The same discipline applied to checks that already exist is described in verify the verifier.",
subsections: [
{
blocks: [
{
application:
"In practice, the check is written first, then broken on purpose to see that it fires with the expected message. It is then run over the real population to confirm that at least one real member passes for the right reason. The planted file is restored, and only then is the code the check will hold written. After a check is narrowed for precision, the case that motivated it is run again.",
boundary:
"A check that every member satisfies for free always says the same thing, and its green result then passes for evidence that what it measures is working. Where nothing can disagree with a check, it is kept with the property it cannot test written down, rather than shipped in a weaker form.",
cause: "A check has only the code in front of it to be shaped by, so it learns the code's accidents as the rule; testability is either designed in or absent.",
decision:
"Every change is ordered as check, planted violation, conforming member, then code, rather than code first with a check fitted around it.",
failureMode:
"The check comes last and passes on its first run, and neither you nor the model ever learns that it would have passed anything.",
kind: "lesson",
principle:
"For this reason the check comes before the code, and I trust a check only after it has caught something on purpose and let something through on purpose.",
problem: "A check written after the code describes the code rather than the rule.",
validation:
"To check this, find the change where each check first fired and the member it first cleared. A check with no such moments has never shown that it works.",
},
{
kind: "text",
text: "The two halves of the proof answer two different questions. A planted violation shows that the check can reject, because a check that has never been seen to fail looks the same as one that cannot fail. A real member passing shows that the check can tell members apart. A check that every member fails has only been shown to reject, and its first green result looks the same as a scope that stopped reaching anything, the mock mirage of a test that exercises nothing real. Where no member can pass yet because the correct shape does not exist in the tree, the first conforming member is written beside the check in the same change, and the check is proven against it before either is trusted.",
},
{
kind: "text",
text: "Narrowing is where a correct check can lose its subject without anything reporting it, and it is where the rule in a check matches a shape is easiest to break. A rule is written against one case and then scoped for precision. Each refinement is judged by the false positives it removes, and neither the developer nor the model runs the true positive again, so a scope that excludes the motivating case reads exactly like a scope that got tighter. The cheapest scoping is the harmful one, because it keys on the property the correct members share rather than on the property the defect has. Running the motivating case again after every scoping costs a sentence, and it is the only step that tells a check that became precise from one that became blind.",
},
{ caption: "the order", kind: "mermaid", text: ORDER_DIAGRAM },
],
title: "Check, prove, then build",
},
],
title: "The check comes first",
};
export const BUILD_SECTIONS: readonly Section[] = [DETECT_SECTION, GATE_SECTION, ORDER_SECTION];
```