# configuration/strings/readme.strings.ts

> 156 lines of code and 49 definitions.

Tree: Build tree
Language: typescript
Layer: product
Canonical: https://banes-lab.com/anatomy/build#file-build-configuration-strings-readme-strings-ts
Source text: https://banes-lab.com/assets/sources/source.f862058415723606ee16cafa23f06a479120eb8f3300a8e31c2523b384e2c651.generated.txt

## Definitions

- `LICENSED_UNDER` (lexical_declaration, line 11, exported)
- `BY_AUTHOR` (lexical_declaration, line 13, exported)
- `CALLOUT_LEAD` (lexical_declaration, line 15, exported)
- `CALLOUT_BODY` (lexical_declaration, line 17, exported)
- `CALLOUT_GRAMMAR` (lexical_declaration, line 20, exported)
- `CALLOUT_TAIL` (lexical_declaration, line 22, exported)
- `MACHINE_LEAD` (lexical_declaration, line 24, exported)
- `MACHINE_BODY` (lexical_declaration, line 26, exported)
- `MACHINE_INDEX` (lexical_declaration, line 28, exported)
- `MACHINE_TAIL` (lexical_declaration, line 30, exported)
- `INTRO_TEXT` (lexical_declaration, line 33, exported)
- `PROBLEM_TITLE` (lexical_declaration, line 36, exported)
- `PROBLEM_LEAD` (lexical_declaration, line 38, exported)
- `PROBLEM_ITEMS` (lexical_declaration, line 41, exported)
- `WORKS_TITLE` (lexical_declaration, line 50, exported)
- `WORKS_LEAD` (lexical_declaration, line 52, exported)
- `WORKS_NOTE` (lexical_declaration, line 55, exported)
- `CHAPTER_SUMMARIES` (lexical_declaration, line 58, exported)
- `FORMAT_TITLE` (lexical_declaration, line 91, exported)
- `FORMAT_TEXT` (lexical_declaration, line 93, exported)
- `STANCE_TITLE` (lexical_declaration, line 96, exported)
- `STANCE_LEAD` (lexical_declaration, line 98, exported)
- `STANCE_ITEMS` (lexical_declaration, line 101, exported)
- `STANCE_TAIL` (lexical_declaration, line 108, exported)
- `WHY_TITLE` (lexical_declaration, line 110, exported)
- `WHY_LEAD` (lexical_declaration, line 112, exported)
- `WHY_ITEMS` (lexical_declaration, line 115, exported)
- `EXHIBIT_TITLE` (lexical_declaration, line 124, exported)
- `EXHIBIT_LEAD` (lexical_declaration, line 126, exported)
- `START_TITLE` (lexical_declaration, line 129, exported)
- `START_LEAD` (lexical_declaration, line 131, exported)
- `SETUP_STEPS` (lexical_declaration, line 133, exported)
- `CONTEXT_TITLE` (lexical_declaration, line 163, exported)
- `CONTEXT_TEXT` (lexical_declaration, line 165, exported)
- `CONTEXT_NOTE` (lexical_declaration, line 168, exported)
- `QUESTIONS_TITLE` (lexical_declaration, line 170, exported)
- `QUESTIONS_NOTE` (lexical_declaration, line 172, exported)
- `QUESTIONS_LEAD` (lexical_declaration, line 174, exported)
- `QUESTION_ITEMS` (lexical_declaration, line 176, exported)
- `ADAPT_TITLE` (lexical_declaration, line 184, exported)
- `ADAPT_TEXT` (lexical_declaration, line 186, exported)
- `EXPECT_TITLE` (lexical_declaration, line 189, exported)
- `EXPECT_TEXT` (lexical_declaration, line 191, exported)
- `READING_TITLE` (lexical_declaration, line 194, exported)
- `READING_LEAD` (lexical_declaration, line 196, exported)
- `LOOP_TITLE` (lexical_declaration, line 198, exported)
- `LOOP_LEAD` (lexical_declaration, line 200, exported)
- `FAQ_TITLE` (lexical_declaration, line 203, exported)
- `SITE_LABEL` (lexical_declaration, line 205, exported)

## Source

```typescript
import {
    BUILD_TAB,
    COLLABORATE_TAB,
    PLAN_TAB,
    SHIP_TAB,
    START_TAB,
    VERIFY_TAB,
} from "@banes-lab/web/core/ids/methodology.ids.ts";
import type { ChapterSummary, ReadmeStep } from "#types/readme.types";

export const LICENSED_UNDER = " is licensed under ";

export const BY_AUTHOR = "by ";

export const CALLOUT_LEAD = "**Working in a web chat instead of a CLI agent?**";

export const CALLOUT_BODY =
    "This method is written for an agent with tool access, one that reads the project's files, runs the checks and repairs what they report. In a web chat the method still transfers, but you carry out the reads and the runs yourself, and ";

export const CALLOUT_GRAMMAR = "PAG";

export const CALLOUT_TAIL = " is read rather than run, because nothing executes it.";

export const MACHINE_LEAD = "**Reading this with a model?**";

export const MACHINE_BODY = "Every page of the site is also published as JSON and as a Markdown copy, and ";

export const MACHINE_INDEX = "llms.txt";

export const MACHINE_TAIL =
    " lists all of them, so a model can fetch the chapter it needs and use it as context while you work.";

export const INTRO_TEXT =
    "Disciplined Methodology is a way of building software with an LLM that writes most of the code. It replaces reminders with automated checks, chat history with files in the project, and confidence with evidence. It is aimed at the problems that long projects built with a model tend to run into, such as code bloat, architectural drift, instructions that fade as a session grows, and behaviour that degrades the longer the model runs. It addresses them with constraints the tooling enforces, rather than rules the developer has to remember. Throughout the chapters, the tree means the project's files as they are on disk, and the gate means the full set of checks a change has to pass, often called a quality gate.";

export const PROBLEM_TITLE = "The problem";

export const PROBLEM_LEAD =
    "A model is good at answering one question. Asked for a whole feature in one message, it tends to answer several questions at once, guess at the ones you did not state, and hand back code that runs but cannot be extended. The failures below are that pattern at different scales:";

export const PROBLEM_ITEMS: readonly string[] = [
    "Functions that work and have no structure to hold them",
    "The same code written again a few files later, because nothing said it already existed",
    "Architecture that drifts between sessions, because it lived in the conversation",
    "Context that dilutes as the session grows, until the rules given at the start are gone",
    "Behaviour that degrades the longer the model runs",
    "More time spent debugging the output than planning the input",
];

export const WORKS_TITLE = "How this works";

export const WORKS_LEAD =
    "The method applies one loop of ten steps to every piece of work, from a one-line fix to a plan with several phases. The loop runs from understanding the request, through deciding what is worth doing and making the change, to verifying the result and deciding whether the work is finished. The chapters below follow the order of the work, and each chapter is a set of lessons. A lesson starts from a failure the developer is likely to meet, explains its cause, and ends with a test you can run against your own work.";

export const WORKS_NOTE =
    "In every chapter the check comes before the code. A rule that no automated check enforces depends on the developer and the model remembering it, so the method adds the rule and its check in the same change, before the code the check will guard.";

export const CHAPTER_SUMMARIES: readonly ChapterSummary[] = [
    {
        summary:
            "This chapter describes the loop, the division of work between the developer, the model and the tooling, and the four statements the rest of the method rests on. It also covers where a rule is written down so that a correction is made once, and how the method is set up in a new project from a template and one file of project details.",
        tab: START_TAB,
    },
    {
        summary:
            "This chapter describes how the developer and the model decide whether work is worth doing before starting it, and how a plan is written as a dependency graph with a check between its phases. It also covers how a template is run rather than copied, when the model asks a question, and what happens when two rules apply to the same line of code.",
        tab: PLAN_TAB,
    },
    {
        summary:
            "This chapter describes how the tooling detects a problem, reports it and repairs what it can. It explains why a check holds a rule better than attention does, why a check is written against a pattern rather than a particular library, and why every fact is declared in one place. It ends with how folders and file names follow a fixed grammar that the checks can read.",
        tab: BUILD_TAB,
    },
    {
        summary:
            "This chapter describes verification as evidence, and how the checks themselves are tested before their results are trusted. It covers running the checks once for each state of the code and reading the whole output, treating an unknown result as not passed, deriving state instead of writing it by hand, and holding documentation to the same checks as code.",
        tab: VERIFY_TAB,
    },
    {
        summary:
            "This chapter describes how the developer sets the goals and the model works within the limits the developer sets. It covers agents written as contracts that are executed rather than as personas, coordination between several agents built as software with a schema and a validator, and why an agent keeps working instead of ending its turn to wait.",
        tab: COLLABORATE_TAB,
    },
    {
        summary:
            "This chapter describes the single chain of commands that every tool runs in, and how a project scales once its structure is predictable. It covers a deployment that is a file operation with a way back, measures that are dropped once the property they stand in for has a check, and the gaps the method declares rather than assumes.",
        tab: SHIP_TAB,
    },
];

export const FORMAT_TITLE = "Prose and PAG";

export const FORMAT_TEXT =
    "The method writes its rules in two forms. The behaviour document is the system prompt of the collaboration, whatever file name the agent's tool expects, and it is written as prose, with one line per rule that gives the rule a stable name and names the check that enforces it. PAG is used for the parts that have to run the same way every time, such as agents, planning and coordination templates, and validation gates with pass and fail criteria. In a CLI agent both forms are in effect. In a web chat the prose transfers as it is, and PAG is read rather than run.";

export const STANCE_TITLE = "The stance";

export const STANCE_LEAD =
    "The method rests on four statements, and every later mechanism exists to keep one of them true without the developer or the model having to remember it.";

export const STANCE_ITEMS: readonly string[] = [
    "A claim about the code stays unverified until the developer or the model has read the file as it is now.",
    "A review starts by looking for faults, because agreeing costs less than checking.",
    "A step done by hand is a step no check observes, so every manual step is treated as a failure of automation.",
    "A document states what is true now and carries no history of its own.",
];

export const STANCE_TAIL = "Each of them is explained in ";

export const WHY_TITLE = "Why this works";

export const WHY_LEAD =
    "Several properties of the model and of the tooling explain why the method holds up over a long project:";

export const WHY_ITEMS: readonly string[] = [
    "A model answers one question far more reliably than several in one message, so the loop and the plan reduce every request to one question at a time.",
    "Rules kept in a chat have to be restated every session and drift each time, while rules kept in files are read at the start of every session, so a correction is made in one place.",
    "A persona changes how the model sounds, not what it does. A check reports each violation where it occurs and names the fix, and the model is far more likely to repair a reported finding than to follow an instruction.",
    "A statement the model makes about the code is not accepted until the developer or the model has read the file. The checks run once for each state of the code, and their first output is the result.",
    "Constraints such as a file size limit, a closed set of names, a direction for dependencies and one home for each fact can each be decided by a check, so each can be enforced automatically.",
    "Once the structure of a project is predictable, the model can build tooling that validates, repairs and extends itself.",
];

export const EXHIBIT_TITLE = "The site is the exhibit";

export const EXHIBIT_LEAD =
    "I publish the method rather than the projects I build with it. The one exhibit is the site itself, and the pages below show the method applied to the site's own source.";

export const START_TITLE = "Getting started";

export const START_LEAD = "Begin with the stance, not the tooling.";

export const SETUP_STEPS: readonly ReadmeStep[] = [
    {
        steps: [
            "Work by the four statements of the stance for a week before you install anything.",
            "Copy the governance folder into the project and write the one file that holds this project's details. Where the project has nothing that corresponds to a detail, declare it absent rather than inventing a value.",
            "Make every check pass on the empty project before the first line of code is written.",
            "Write the first check before the first feature.",
        ],
        title: "Setup",
    },
    {
        steps: [
            "State the objective and what finished means, in one sentence each, before the first step.",
            "Write the plan as phases with a check between each pair, and rank the possible approaches by worth before starting any of them.",
            "Work on one component at a time, and ask the model one question at a time, with the relevant files in its context.",
            "Run the checks once for each state of the code and read the whole output. The report the checks write is the record of where the work stands.",
            "The second time you give the model the same correction, turn the correction into a check, so that it does not have to be given a third time.",
        ],
        title: "Execution",
    },
    {
        steps: [
            "Types, unused code, formatting and lint, including custom rules for the anti-patterns of the project's architecture",
            "Tests, then the build, then validators that read what the build produced",
            "Documents, held to the same naming, placement and validation rules as code",
        ],
        title: "What the gate holds",
    },
];

export const CONTEXT_TITLE = "Using the site as context";

export const CONTEXT_TEXT =
    "Point your model at the chapter you are applying, and it can use the method while you work without copying anything into the project. The anatomy page shows the site's own client source, with the structure, definitions and calls of every file, and it is the code the other pages draw their examples from.";

export const CONTEXT_NOTE = "Read the anatomy page.";

export const QUESTIONS_TITLE = "Ask targeted questions";

export const QUESTIONS_NOTE = "Open the index of every page in JSON and Markdown.";

export const QUESTIONS_LEAD = "With a chapter in context, ask your model:";

export const QUESTION_ITEMS: readonly string[] = [
    "How does the loop apply to this project, and which node is the current work on?",
    "Which of these rules can a check hold here, and which cannot?",
    "What is the first check this tree needs?",
    "Where does this correction belong so that it lands once?",
    "Express this constraint in PAG.",
];

export const ADAPT_TITLE = "Adapt it";

export const ADAPT_TEXT =
    "Treat every constraint as an experiment that has to show a result. A constraint is worth keeping when it measurably improves the output, for example when violations fall over time, when file sizes hold without reminders, or when the model's behaviour holds up over a long session. A constraint that changes no measurement can be dropped. A project of a new kind does not need a new method, because a variant is derived from the same core.";

export const EXPECT_TITLE = "What to expect";

export const EXPECT_TEXT =
    "The model still drifts from what was asked and still needs to be redirected. Each drift is turned into a rule or a check, so the same drift is unlikely to happen again. Planning takes longer than before, debugging takes much less time, and fewer corrections are needed as the rules and checks accumulate. The method costs attention at the start and pays it back over a long project, so it is not worth adopting for a project that will not last.";

export const READING_TITLE = "Reading path";

export const READING_LEAD = "Read the chapters in this order. Each one assumes the ones before it.";

export const LOOP_TITLE = "The loop";

export const LOOP_LEAD =
    "The diagram shows the loop every chapter applies, grouped by the three kinds of question it answers.";

export const FAQ_TITLE = "Frequently asked questions";

export const SITE_LABEL = "the site";
```