# configuration/strings/methodology.start.strings.ts

> 115 lines of code and 7 definitions.

Tree: Site tree
Language: typescript
Layer: product
Canonical: https://banes-lab.com/anatomy/tree#file-configuration-strings-methodology-start-strings-ts
Source text: https://banes-lab.com/assets/sources/source.89f2e1afade8e7a416527d994d7f5c36c03a4d20ff94fc61a7bf4bd7cd34cd29.generated.txt

## Definitions

- `LOOP_DIAGRAM` (lexical_declaration, line 6)
- `SCALE_DIAGRAM` (lexical_declaration, line 9)
- `LABOUR_DIAGRAM` (lexical_declaration, line 12)
- `STAGES` (lexical_declaration, line 15)
- `LOOP_SECTION` (lexical_declaration, line 28)
- `LABOUR_SECTION` (lexical_declaration, line 83)
- `START_SECTIONS` (lexical_declaration, line 122, exported)

## Source

```typescript
import { LABOUR_SECTION_ICON, LOOP_SECTION_ICON } from "#configuration/icons/methodology.start.icons";
import { LABOUR_SECTION_ID, LOOP_SECTION_ID } from "#core/ids/methodology.start.ids";
import { layerLink as layer, nodeLink as node, stageLink as stage } from "#domain/converters/link.converter";
import type { Section } from "#types/document.types";

const LOOP_DIAGRAM =
    'flowchart TB\n    subgraph epistemic["Epistemic · how is it known?"]\n        orient["Orient · name the subject, read from the tree"]\n        see["See · look through the lenses the subject warrants"]\n        derive["Derive · a claim grounded in what was seen"]\n        project["Project · the next admissible move"]\n        act["Act · apply the operation to the state"]\n    end\n    subgraph conative["Conative · what is worth doing?"]\n        intent["Intent · the objective, and the highest-worth branch"]\n        constrain["Constrain · is the operation admissible?"]\n    end\n    subgraph evaluative["Evaluative · is it right, and are we done?"]\n        verify["Verify · is the evidence set non-empty?"]\n        commit["Commit · externalise the result as inspectable state"]\n        terminate["Terminate · saturated, complete and verified?"]\n    end\n    orient --> intent\n    intent -- gate: worth before work --> see\n    see --> derive --> project --> act --> constrain\n    constrain -- gate: admissible --> verify\n    verify -- gate: evidence --> commit --> terminate\n    verify -. refuted, back with the evidence .-> derive\n    terminate -- gate: stop --> orient';

const SCALE_DIAGRAM =
    'flowchart TB\n    fix["A one-line fix · one traversal, minutes"]\n    task["A task · one traversal, an afternoon"]\n    phase["A phase · one traversal that holds many tasks"]\n    plan["A plan · one traversal that holds many phases"]\n    fix --- task --- phase --- plan\n    plan -. each phase walks the loop again inside .-> phase\n    phase -. each task walks the loop again inside .-> task';

const LABOUR_DIAGRAM =
    'flowchart TB\n    subgraph tooling["The tooling"]\n        detect["Detection · every rule, on every change, the same way"]\n        heal["Healing · what a fixer can restore, it restores"]\n    end\n    subgraph ai["The model"]\n        repair["Repair · what the fixers left, one finding at a time"]\n    end\n    subgraph operator["The developer"]\n        govern["Governance · what the work is for, and what finished means"]\n    end\n    detect --> heal\n    heal -- the findings left --> repair\n    repair -- a changed tree --> detect\n    govern -- rules and objectives --> detect\n    govern -- corrections --> repair\n    repair -. questions .-> govern';

const STAGES = [
    "orient",
    "intent",
    "see",
    "derive",
    "project",
    "act",
    "constrain",
    "verify",
    "commit",
    "terminate",
] as const;

const LOOP_SECTION: Section = {
    icon: LOOP_SECTION_ICON,
    id: LOOP_SECTION_ID,
    intro: `Every piece of work in this method follows the same loop of ten steps, which I call nodes, whether the work is a one-line fix or a plan that runs for weeks. A plan, a check, an agent, a refactor and a review are all this one loop, run at a different size. I treat it as the first thing to learn, because each later chapter applies it to one kind of work, and every mechanism in the method exists to hold one of its gates: the points where the work may not continue until a condition holds. The nodes are shown in <cite>ten nodes</cite> and the sizes in <cite>four sizes</cite>, and each node is published as a record on the ontology page: ${STAGES.map(stage).join(", ")}.`,
    subsections: [
        {
            blocks: [
                {
                    application:
                        "In practice this means running the loop at the size of the task and always knowing which node the work is on. Four of the nodes are gates that apply at every size: the work has to be worth doing before any effort goes into it, a change has to be allowed before it is trusted, a claim needs evidence before it is recorded, and the loop only ends as done when nothing is left, everything is done and everything is checked. If that last condition is not met, it ends as blocked instead.",
                    boundary:
                        "The loop has its limits as well. It is not worth the ceremony for a throwaway script, and it pays off where you or your model will read, change or rely on the work later. A reference, a note or a contract is something you read rather than run, so forcing the full loop onto it adds ceremony without making it more reliable.",
                    cause: "Nothing gave the work a shape, so the shape came from whatever sentence the model found most likely next.",
                    decision:
                        "A one-line fix goes through the same ten nodes as a plan does, rather than through a lighter process kept for small tasks.",
                    failureMode:
                        "The model starts writing code in its first reply and guesses what the goal is, and after that each reply answers the previous one rather than the task, so the conversation drifts away from what was asked.",
                    kind: "lesson",
                    principle:
                        "For this reason I give every piece of work the same shape, the loop, whatever its size.",
                    problem:
                        "Work with a model tends to begin at the doing and skip everything that should come before it.",
                    validation:
                        "To check this on your own work, take the plan, the check and the agent for a single task and read each of them as the same ten nodes. A step that fits none of them is either missing from the loop or does not belong in the work.",
                },
                {
                    kind: "text",
                    text: `The ten nodes fall into three groups. The first, the ${layer("epistemic", "epistemic")} layer, is about knowing: orient decides what the subject is by reading it from the tree, see chooses how to look at it, derive draws a claim from what was seen, project picks the next step that is allowed, and act carries it out. The second, the ${layer("conative", "conative")} layer, is about what is worth doing: intent states the ${node("tel-objective", "objective")} and ranks the possible approaches by ${node("tel-priority", "priority")}, and constrain checks that a change is allowed once it has been made. The third, the ${layer("evaluative", "evaluative")} layer, is about whether the result is right and whether the work is finished: verify asks for ${node("ver-evidence", "evidence")}, commit writes the result down where the next round can read it, and terminate decides whether to ${node("ter-stop", "stop")}.`,
                },
                {
                    kind: "text",
                    text: `The order between the nodes matters as much as the nodes themselves. A claim that turns out to be ${node("ver-refutation", "refuted")} goes back to derive together with the evidence that refuted it; it never carries on with a note attached. A repair restarts at the earliest node that can supply the missing evidence, and everything after that node is redone. The number of repairs is limited, so a loop that keeps repairing ends as ${node("ter-block", "blocked")} rather than as done. Each node also owes a specific kind of answer: a node that has to rank options is not satisfied by a yes, and a node that has to answer yes or no is not satisfied by a ranking. The same loop is what an agent template follows and what an instruction pattern is chosen by, which is why the grammar page and this page describe one loop twice.`,
                },
                { caption: "ten nodes", kind: "mermaid", text: LOOP_DIAGRAM },
            ],
            title: "Ten nodes, every size",
        },
        {
            blocks: [
                {
                    kind: "text",
                    text: "The loop also nests inside itself. A plan is one pass through the loop whose act node produces phases, each phase is a pass whose act node produces tasks, and each task is a pass that ends in an edit and a run of the checks. The gates apply at every level: a phase cannot start until the phase before it has recorded evidence the next one can read, and a plan cannot finish until every phase has done so. For this reason a plan has a gate between its phases rather than a tick beside each item, as described in the plan is a graph.",
                },
                {
                    kind: "text",
                    text: "The difference between an instruction and a traversal, meaning one pass through the loop, shows within the first minute. An instruction asks for an outcome. A traversal names the nodes it passes through, so a reader can see where it went wrong. For example, asked to raise a file-size limit, a traversal starts by opening every file that mentions the limit, and finds that the limit is declared in three places. Its intent is one limit with a single source of truth, so it concludes that the problem is the limit having more than one home, not its value. It changes the declaration, deletes the two copies and keeps to the one option the checker offers. It then runs the gate once and reads the output in full, records the report, and stops because the objective reads as true against the tree. The edit touched one file instead of three, and a reader of the messages can tell which node the work was on.",
                },
                { caption: "four sizes", kind: "mermaid", text: SCALE_DIAGRAM },
            ],
            title: "Instruction and traversal",
        },
    ],
    title: "The loop",
};

const LABOUR_SECTION: Section = {
    icon: LABOUR_SECTION_ICON,
    id: LABOUR_SECTION_ID,
    intro: "Three parties do the work in this method: the tooling, the model and me, as the developer. The tooling detects problems and repairs the ones it can, the model repairs what the tooling leaves, and I decide what the work is for and what finished means. The split is shown in <cite>three parties</cite>, and the parts do not swap. I treat it as the second thing to learn, because every later chapter assumes it, and every failure the method knows turns out to be one party doing another party's job. The architecture page reaches the same three parties from a different starting point, that the author is probabilistic.",
    subsections: [
        {
            blocks: [
                {
                    application:
                        "In practice, detection is a check that runs the same way every time, with its fixer switched on by default. The findings the fixer cannot close go to the model one at a time, each with its location and the value that was expected. The developer keeps the decisions about what the work is for, and hands nothing else down.",
                    cause: "A developer cannot pay attention to every line, and a model cannot tell a rule from a preference unless something outside it enforces the rule.",
                    decision:
                        "Detection goes to the tooling and governance stays with the developer, rather than to a review that reads what a check could enforce.",
                    failureMode:
                        "You review the code for style, the model reviews it for correctness, and both of you miss the architectural drift because neither of you owns it.",
                    kind: "lesson",
                    principle:
                        "For this reason I treat quality as a property of the tooling, not of how much attention the developer or the model pays.",
                    problem:
                        "When you don't name the roles, you end up doing work a check should do, and the model ends up guessing what you want.",
                    validation:
                        "To check this on your own work, read the last ten findings your tooling raised. Each of them should name a check; a finding that a developer had to raise by hand points to a check that does not exist yet.",
                },
                {
                    kind: "text",
                    text: "Detection is mechanical because it has to give the same result on every run. A reviewer who applies a rule from memory applies it differently on a tired day, and a model that applies a rule from a prompt applies it differently once its context fills up. A check, by contrast, is static analysis: it returns the same verdict for the same tree. The chapters one correct answer and scale follows determinism work out what follows from that. Repairs that have exactly one correct answer belong to the tooling for the same reason: the fixer applies them in the same run that found the fault, without asking the developer or the model.",
                },
                {
                    kind: "text",
                    text: "Repair belongs to the model because a finding is small and specific, and a model handles small, specific tasks well; what a finding contains is described in detect, log, fix. The model is not trusted to decide that its own work is finished, because reading an edit is not the same as running the checks, and it looked right covers that failure. Governance stays with the developer because nothing in the method computes whether work is worth doing. What the work is for, what finished looks like and which of two acceptable approaches to take are decisions I make and write down before the work starts. When I correct the model, the correction is meant to become a rule rather than something I remember; a rule that lives only in my head is manual-only governance, and it decays.",
                },
                { caption: "three parties", kind: "mermaid", text: LABOUR_DIAGRAM },
            ],
            title: "Three parties, three jobs",
        },
    ],
    title: "Who does what",
};

export const START_SECTIONS: readonly Section[] = [LOOP_SECTION, LABOUR_SECTION];
```