docs(audits): round 5d, a person's file and a 40-line file against round 5c

docs/architecture/05-building-block-view.md

@@ -49,12 +49,12 @@ owns.
 
 ## 5.3 Level 2: manifest
 
-![How a template reaches a chain. The resolver starts from a stack's root, seeds the core tier, follows depends_on into the opt-in tier and resolves an orthogonal template when the project picks it. It writes the chain in order, the core tier, the base templates the chain reaches, the layer templates, then the stack. An orthogonal root resolves to a chain of its own in the same way](../diagrams/building-blocks-manifest.png)
+![How a template reaches a chain. The resolver starts from a stack's root, seeds the core tier, follows depends_on into the opt-in tier and resolves an orthogonal template when the project picks it. It writes the chain in order, the core tier first, then each dependency depth-first before what needs it, and the root last, unless the core tier already holds it. An orthogonal root resolves to a chain of its own in the same way](../diagrams/building-blocks-manifest.png)
 
 | Tier | Members | Reaches a chain | Source |
 |------|---------|-----------------|--------|
 | Core | `core:`, then a fork's `fork_core:` | Seeded into every chain, so it never needs declaring | FR-03-02 |
-| Opt-in | CI (`cicd`, `quality-gates`), security, devsecops, containers, deployment, config, data | Only when a stack's `depends_on` names it | FR-03-03 |
+| Opt-in | CI (`cicd`, `quality-gates`), security, devsecops, containers, deployment, config, data | When a project picks it as a root, or a chosen root's dependency tree names it | FR-03-03 |
 | Orthogonal | Advanced data templates, embedded checks, measurement, a fork's platforms and workflow choices | Picked by the project, in a fork's interview where it has one, and resolved as a root of its own | FR-04-01 |
 
 Every top-level list of entries except `core` and `fork_core` is a section

docs/architecture/06-runtime-view.md

@@ -23,7 +23,7 @@ orders, placing each rule where the output contract says.
 |------|--------------|--------|
 | 1 | The team names a root, such as a stack, and the agent generates its context by reading Markdown | FR-05-01 |
 | 2-3 | The questions live in the fork's interview. A conflict the rules cannot settle goes to the team, and the answer is recorded in the file | ADR-049, FR-05-03 |
-| 4 | The resolver seeds the core tier, then walks `depends_on` depth-first, without duplicates, base before layer before stack | FR-03-02, FR-04-01 |
+| 4 | The resolver seeds the core tier, then walks `depends_on` depth-first, without duplicates, each dependency before what depends on it | FR-03-02, FR-04-01 |
 | 5-6 | An override replaces a section, and each extension of the same ID adds to it. An inline file copies in every adopted rule. A hybrid file copies in every rule whose breach is silent and which no tool enforces, and any other rule may stay a reference | FR-04-02, FR-04-03, ADR-052 |
 | 7-8 | The agent writes both files to the output contract, then runs the contract's self-check against them | FR-05-02, FR-05-04 |
 | 9 | The emitter leaves out overridden rules and the sections the project declines, places each remaining section by its load, copies each rule's text unchanged, and builds the same files from the same input | ADR-058, proposed; FR-06-03, FR-06-06 |
@@ -100,5 +100,5 @@ takes, and only a regeneration or an edit changes its context files.
 | Scenario | What happens | Source |
 |----------|--------------|--------|
 | A pull request upstream | CI runs smoke, conformance and fork sync, and the maintainer approves the merge | FR-10-01, FR-10-02 |
-| Cutting a release | `tools/cut_changelog.py` writes an entry for each merged pull request from its `changelog:` label and cuts the `Unreleased` section into the version, and `tools/check_release.py` checks the section and the SemVer step before the tag | QG-03-02 |
+| Cutting a release | `tools/cut_changelog.py` writes an entry for each pull request merged since the previous tag whose `changelog:` label names a section, and cuts the `Unreleased` section into the version, and `tools/check_release.py` checks the section and the SemVer step before the tag | QG-03-02, FR-09-04 |
 | Deprecating a template | It keeps resolving until the next major, naming a live replacement | FR-09-02 |

docs/architecture/08-crosscutting-concepts.md

@@ -42,8 +42,9 @@ A heading may carry several tag lines:
   check enforces. A heading without one loads on every turn, and a
   heading's subheadings take its load (ADR-058, proposed)
 - A heading carries one load at most, among its tags, and none under a
-  heading that has one. A template that guards data, credentials or
-  authentication carries none. SYS-25 checks each of these
+  heading that has one. A section whose breaking exposes data, credentials
+  or an unauthenticated path carries none. SYS-25 checks each of these, the
+  last for the security templates and `backend/auth.md`
 - A section runs from its tags to the next `[ID:]` or the end of the file,
   and is never empty
 - Shipped IDs are frozen, never removed, renamed or moved to another