configuration/strings/architecture.fragment.strings.ts

configuration/strings/architecture.fragment.strings.ts is a file in Bane's Lab Site. 57 lines of code and 4 definitions.

import { ENCODING_SECTION_ICON } from "#configuration/icons/methodology.start.icons";
import { ENCODING_SECTION_ID } from "#core/ids/methodology.start.ids";
import type { Section } from "#types/document.types";

const ENCODING_DIAGRAM =
    'flowchart TB\n    subgraph mechanical["Mechanical rules · what the tree must be"]\n        checks["Checks, fixers, validators, generators"]\n    end\n    subgraph behavioral["Behavioral rules · how the agent is asked to work"]\n        policy["One-line rules with stable names"]\n    end\n    subgraph context["Context architecture · what the agent knows and where"]\n        cores["Agnostic cores · ontologies, templates, the standard"]\n        adapter["One adapter · binds every slot to this tree"]\n        digests["Digests · one concern each, expanding a rule"]\n        memory["Memory · one fact per file, reference never authority"]\n    end\n    tree["The tree"]\n    checks -- findings, healed or not --> policy\n    policy -- a correction hardens into a rule --> policy\n    policy -- a pattern stated twice becomes a check --> checks\n    cores -- read through --> adapter\n    adapter -- resolved slots --> policy\n    digests -- expand --> policy\n    memory -. recalled, then verified against .-> tree\n    checks -- read and heal --> tree\n    policy -- edits --> tree';

const PRECEDENCE_DIAGRAM =
    'flowchart TB\n    policy["The behavior policy"]\n    contract["The codebase contract"]\n    boundary["A member\'s own boundary document"]\n    digests["The per-concern digests"]\n    canon["The document canon"]\n    source["Source files"]\n    memory["Memory"]\n    tree["The tree on disk"]\n    policy --> contract --> boundary --> digests --> canon --> source --> memory\n    tree -. wins over every document, and the document is fixed the same turn .-> policy';

const ENCODING_SECTION: Section = {
    icon: ENCODING_SECTION_ICON,
    id: ENCODING_SECTION_ID,
    intro: "The rules of the method are written down in three different forms, and each form holds a different kind of rule. Mechanical rules are enforced by checks, behavioral rules tell the model how to work, and the context architecture decides what the model is given to read. The three feed into each other, as shown in <cite>three encodings</cite>. A method that uses only one of the three leaks through the other two, and when two documents disagree, the order shown in <cite>precedence</cite> decides which one wins.",
    subsections: [
        {
            blocks: [
                {
                    application:
                        "In practice, a rule about the tree goes into a check. A rule about how the model should work goes into the behavior policy, as one line with a stable name. What the model needs to know goes into the context architecture, arranged so that the general part carries over to other projects and everything specific to this project sits in one file. A fact lives in exactly one of the three places, and the other two point to it.",
                    boundary:
                        "The split follows what a rule applies to, never how important it feels. A behavioral rule whose effect can be seen in an artifact is really a mechanical rule written as prose, and moving it into a check is progress, not a demotion.",
                    cause: "A rule written where no check reads it is held only by memory, and a rule written in two places becomes two rules that drift apart.",
                    decision:
                        "Each rule is assigned to one of the three forms before it is written down, rather than added wherever it happens to fit.",
                    failureMode:
                        "A rule about the tree is written into the behavior policy, the model may keep to it for a session, and the tree drifts anyway, because nothing outside the conversation reads that sentence.",
                    kind: "lesson",
                    principle:
                        "For this reason I keep each kind of rule in its own form: mechanical rules, behavioral rules and context architecture each hold one kind, and all three defer to the tree.",
                    problem:
                        "Rules are often written as one long instruction document, which mixes what a check should enforce with what the developer and the model are expected to remember, and the whole document then decays as fast as its weakest part.",
                    validation:
                        "To check this, pick one line from the instructions you give the model and say where it belongs. A line that fits none of the three forms is two rules, or a rule no check enforces.",
                },
                {
                    kind: "text",
                    text: "Mechanical rules are the ones a check can decide from the tree alone: where a file may live, what a name may say, which imports cross a boundary, whether a fact is declared twice and whether a document's references resolve. They are policy as code, enforced by checks, fixers, validators and generators through static analysis and fitness functions. Each returns pass or fail, and all of them run in one chain, as described in The gate holds the line. The developer has no part in this form at all, and that is intended: a mechanical rule that needs a developer to apply it is a behavioral rule disguised as a check.",
                },
                {
                    kind: "text",
                    text: "Behavioral rules cover how the model is asked to work where no artifact can show whether it did. The model is asked to read a file before saying what it contains, to ask a question before the work that depends on the answer, and never to run a step whose output it will not read in full. Each is one line with a stable name, as described in Rules with names, so that a correction has a place to land and a citation has something to point to.",
                },
                {
                    kind: "text",
                    text: "Context architecture is how the other two forms reach the model in the same way every session. Its core documents name no project: an ontology of readings, a canon of principles, the naming standard and the core templates the grammar page publishes, as described in Principles are typed and Placement is a grammar. A single adapter binds them to one project, as described in The drop-in. Digests expand one concern each where a rule needs more room. Memory holds one fact per file and serves as reference rather than authority, so a remembered fact is checked against the tree before anything is done with it. An order of precedence runs through all of it, and the tree outranks every document: a document that disagrees with what is on disk is out of date, and it is corrected in the same turn the disagreement is found.",
                },
                {
                    kind: "text",
                    text: "The feedback between the three forms is what makes them work as one system rather than three separate ones. A check raises a finding, and the model is asked to repair it within the behavioral rules. A correction I give is written down as a behavioral rule and a memory in the same turn. When a behavioral rule has to be stated twice for the same kind of problem, that is the signal to build the check that makes it mechanical. The prose then becomes a pointer, and the rule has a single source of truth. The core documents stay untouched throughout, because they name nothing specific to this project, and the adapter absorbs whatever changes.",
                },
                { caption: "three encodings", kind: "mermaid", text: ENCODING_DIAGRAM },
                { caption: "precedence", kind: "mermaid", text: PRECEDENCE_DIAGRAM },
            ],
            title: "One kind of discipline per home",
        },
    ],
    title: "Three encodings",
};

export const ENCODING_SECTIONS: readonly Section[] = [ENCODING_SECTION];