# configuration/strings/anatomy.strings.ts

> 155 lines of code and 13 definitions.

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

## Definitions

- `ANATOMY_META` (lexical_declaration, line 13, exported)
- `READING_LABEL` (lexical_declaration, line 20)
- `MEASUREMENTS_TAG` (lexical_declaration, line 22, exported)
- `IMPORTS_TAG` (lexical_declaration, line 23, exported)
- `STRUCTURE_TAG` (lexical_declaration, line 24, exported)
- `FLOW_TAG` (lexical_declaration, line 25, exported)
- `DATA_FLOW_TAG` (lexical_declaration, line 26, exported)
- `LAYERS_TAG` (lexical_declaration, line 27, exported)
- `FINDINGS_TAG` (lexical_declaration, line 28, exported)
- `SAMPLE_WALK_TAG` (lexical_declaration, line 29, exported)
- `LEGEND_TAG` (lexical_declaration, line 30, exported)
- `ANATOMY_CHAPTER` (lexical_declaration, line 32, exported)
- `ANATOMY_CONTENT` (lexical_declaration, line 158, exported)

## Source

```typescript
import { ANATOMY_READING_ICON, ANATOMY_SECTION_ICON } from "#configuration/icons/anatomy.icons";
import {
    DERIVED_SECTION_ID,
    DIAGNOSES_SECTION_ID,
    PARTS_SECTION_ID,
    READING_TAB,
    SPINE_SECTION_ID,
    WALK_SECTION_ID,
} from "#core/ids/anatomy.ids";
import type { Section, Tab, TabbedMeta } from "#types/document.types";
import { ANATOMY_SHARE } from "#configuration/strings/page.strings";

export const ANATOMY_META: TabbedMeta = {
    subtitle:
        "The anatomy page shows the client source of this site, parsed on every build. The reading tab explains what the page measures, and the tree tab holds the source as it sits on disk, with every folder and file and, for each file, its syntax walk, its definitions with their call edges, and the source itself.",
    title: ANATOMY_SHARE.headline,
    version: "1.0.0",
};

const READING_LABEL = "Reading";

export const MEASUREMENTS_TAG = "the measurements";
export const IMPORTS_TAG = "the import graph";
export const STRUCTURE_TAG = "structure";
export const FLOW_TAG = "logical flow";
export const DATA_FLOW_TAG = "data flow";
export const LAYERS_TAG = "the layers";
export const FINDINGS_TAG = "the findings";
export const SAMPLE_WALK_TAG = "a walk";
export const LEGEND_TAG = "the legend";

export const ANATOMY_CHAPTER: readonly Section[] = [
    {
        icon: ANATOMY_SECTION_ICON,
        id: DERIVED_SECTION_ID,
        intro: "This section covers what the rest of the page is made of. This tab is the one part of the page I wrote, and everything else, every panel, every number and the whole tree tab, comes out of the build, which parsed every source file of the site's client, built the call graph, ran the diagnoses and laid every syntax node on a grid. The page renders that output by shape, as described in derived state on the methodology page. The module's totals are shown in <cite>the measurements</cite>, and the edges between its containers in <cite>the import graph</cite>.",
        subsections: [
            {
                blocks: [
                    {
                        application:
                            "In practice, every number on this page is a measurement taken at build time. The tree tab shows the source as it sits on disk, and each file there shows its walk, its definitions and its source. Where a number here disagrees with the tree on disk, the tree is right and this page is stale.",
                        boundary:
                            "The page describes the client source the reader is looking at and nothing behind it. The tooling that produced it, the documents that govern it and the checks that gate it are not on this tree, so they are not on this page.",
                        cause: "A description written by hand is a second copy of the tree, and a second copy disagrees with the first from the day one of them moves.",
                        decision:
                            "The derivation is published rather than a description of it, so the page can only be as wrong as the build that produced it.",
                        failureMode:
                            "An architecture page names three containers and the tree holds four, the fourth added the week after the page was written, and every reader of the page reasons about a tree that no longer exists.",
                        kind: "lesson",
                        principle:
                            "For this reason a page about a system is derived from the system in the same build that renders it, since otherwise it is only a claim.",
                        problem:
                            "A page that describes a codebase is prose about the codebase, and prose has no mechanism that makes it wrong when the codebase changes.",
                        validation:
                            "To check this, pick any file on the tree tab and open the same file on disk. The definitions, the line count and the imports on the page match the file, or the page was not derived from it.",
                    },
                    {
                        kind: "text",
                        text: "The measurements are the same ones the quality tooling reads, namely how many definitions the parser found, how many call edges it resolved between them, how many calls it could not resolve, and the diagnoses it ran. A call the parser cannot resolve is counted and never guessed, so the resolution rate is a measured fraction and not a hope.",
                    },
                    {
                        kind: "text",
                        text: "The import graph folds every import a file makes to the container that owns the imported file, so an edge is a container reaching into another container, counted. Which way those edges may run is described in the direction axis on the architecture page, and this graph shows which way they do run.",
                    },
                ],
                title: "What the reader is seeing",
            },
        ],
        title: "This page is derived",
    },
    {
        icon: ANATOMY_SECTION_ICON,
        id: PARTS_SECTION_ID,
        intro: "The four parts named in a system is a graph on the architecture page are each measured here. The components are the definitions, the relations are the call edges between them, the schema is the set of diagnoses the parser can run, and the propagation is the fan-in every definition carries. The shape of the whole is shown in <cite>structure</cite>, and the order in which it runs in <cite>logical flow</cite>.",
        subsections: [
            {
                blocks: [
                    {
                        kind: "text",
                        text: "Every definition carries an in-degree and an out-degree, and the two decide its flow class. An entry has callees and no callers, a leaf has callers and no callees, a relay has both, and an isolated definition has neither. The flow classes are counted per file, per folder and for the whole tree, so a container that is mostly leaves and a container that is mostly relays read differently before a single file is opened.",
                    },
                    {
                        kind: "text",
                        text: "The split between the two charts is the one described in definitions own what, code owns how. The structure is what exists and how it is arranged, and the logical flow is what calls what when it runs. Both are read from the same syntax trees, so they cannot disagree with each other, only with a tree that has moved since the build.",
                    },
                ],
                title: "Components, relations, schema, propagation",
            },
        ],
        title: "The four parts, measured",
    },
    {
        icon: ANATOMY_SECTION_ICON,
        id: SPINE_SECTION_ID,
        intro: "Every file on the tree tab carries its subject, its concern and, where the name declares one, its variant, read off the file name as described in placement is a grammar, and every concern is tagged to a layer of the layer spine. The layers the tree lands on are shown in <cite>the layers</cite>, and what moves between the containers at runtime in <cite>data flow</cite>.",
        subsections: [
            {
                blocks: [
                    {
                        kind: "text",
                        text: "A folder's role is read from its depth and its name. The first folder under the member is a container, a folder whose name is a concern folder is a concern, and anything between is a subject folder that exists only because two sets of one concern must not merge. A file whose name the grammar cannot parse carries no slots and no layer, and the page says so rather than guessing one.",
                    },
                    {
                        kind: "text",
                        text: "The layer a file lands on is a derivation from its concern and never a fact written by hand, which is why the same file shows the same layer on this page and in every check that reads the tree. A folder shows the layer of its concern, and a container shows none, because a container groups by axis and not by layer.",
                    },
                ],
                title: "Roles, slots and layers",
            },
        ],
        title: "Containers on the spine",
    },
    {
        icon: ANATOMY_SECTION_ICON,
        id: DIAGNOSES_SECTION_ID,
        intro: "The diagnoses are the schema applied to the graph, and they look for a call cycle, a definition nothing consumes, a definition declared twice, a file that reaches across too many concerns, and an import cycle between modules. What they found is shown in <cite>the findings</cite>, where a zero is a measured zero, as described in unknown is not pass. One concern folder's walk is shown in <cite>a walk</cite>.",
        subsections: [
            {
                blocks: [
                    {
                        kind: "text",
                        text: "Each diagnosis names the control whose absence lets the decay in, as described in an anti-pattern is a decay path, and carries the remedy that reverses it. A finding on this page lands on the file it names, in that file's record on the tree tab, so the reader can open the walk and the source the finding is about.",
                    },
                    {
                        kind: "text",
                        text: "A diagnosis that runs and finds nothing is different from one that never ran, as described in the honest gaps on the architecture page. The diagnoses here are the ones the parser runs on every build, and a predicate the method calls for that this parser does not compute is declared absent on that page, never assumed clean here.",
                    },
                ],
                title: "What the schema can say",
            },
        ],
        title: "What the diagnoses found",
    },
    {
        icon: ANATOMY_SECTION_ICON,
        id: WALK_SECTION_ID,
        intro: "A walk lays every meaningful syntax node of a file on a hexagonal grid in the order the parser met them, so a file is a path the eye can follow, going down when the code nests, up when it returns and sideways when it continues. The states are shown in <cite>the legend</cite>, which marks what declares, what calls, what writes, what reads, what branches and what merely holds structure.",
        subsections: [
            {
                blocks: [
                    {
                        kind: "text",
                        text: "The arrows mark the direction every few steps, and a flagged cell carries the severity of the finding that flagged it. Every cell is a reference into the data the walk ships beside it, so the vector stays a shape and the text lives in a file the page reads by reference, the same way a code panel is cited from the prose.",
                    },
                    {
                        kind: "text",
                        text: "A walk pans by dragging and zooms by scrolling, and selecting a cell shows its file and line, its syntax kind and its text. A folder's walk is its files in order, and a file's walk is that file alone, so the tree can be read at either scale. A walk shows syntax and never semantics. What a call resolves to comes from the call graph, which the definitions beside each file show.",
                    },
                ],
                title: "States, arrows and cells",
            },
        ],
        title: "Reading a walk",
    },
];

export const ANATOMY_CONTENT: readonly Tab[] = [
    { icon: ANATOMY_READING_ICON, id: READING_TAB, label: READING_LABEL, layout: "chapter", sections: ANATOMY_CHAPTER },
];
```