feat(config): lens sections - a repository's own text appended to a shipped charter

A lens has one charter, the one this pipeline ships; what a repository
knows that is not general to the lens - its platform and layers, the
record it keeps its decisions in, what its users already have, the
calibration entries that are its own - goes in a file the config names
for the lens (lenses.<name>.section), and Charter appends it after one
blank line. The charter sha in every reuse key covers the combined text.

The config refuses a path outside the repository - absolute, or
climbing out with `..` - by the check slots.dir had, now one both
settings share; a file missing or one the run could not use (a dangling
link, unreadable, not UTF-8) is a problem too, checked through the
reader Charter uses (Prompt::ReadSection), so a section is never
dropped in silence, and a name that is no lens is the unknown key it
always was. Nothing lists a directory, so what lies beside the files is
no concern of the config's: a directory listed would have to tolerate or
refuse every foreign entry. The run logs which charters got one.

The better-solution charter gains a consumer's general entry
(2026-10-31: a mechanism reworked a second time in one submission is the
signal to derive the fix at every layer the data crosses). The procedure
names the section wherever it names the charter: among the config's keys,
in the lens inputs, in the reuse rule (an edit to either re-runs the lens)
and in the feedback loop, which routes a repository's own lesson to its
section and a general one to the shipped charter.

process/lenses/repo-better-solution.md

@@ -98,3 +98,10 @@ record is a `reserve-answer` or `info` note. Never grade a finding.
   polished over six rounds and removed by the owner in one line ("they can
   be viewed in the releases tab"). Ask first whether the thing needs to exist
   in the tree at all.
+- 2026-10-31 (round 9 of a consumer's first push): rounds 6–8 reworked an
+  app's mapping of a daemon's message ids three times before round 9 asked
+  whether the ids should be unique at the layer that mints them — the
+  daemon's, a repository of the same owner, where the fix was one change. A
+  mechanism reworked a second time in one submission is the signal: at the
+  second rework, derive the fix at every layer the data crosses before
+  another variant on the consuming side.

process/prepush.md

@@ -32,7 +32,8 @@ hash at Gate 5.
   — content, history and blame; the state before the range via
   `git show <base>:<path>`.
 - `--context-paths` for the evidence dirs the commit messages' claims rest on.
-- The lens charter (`process/lenses/repo-*.md`, system text
+- The lens charter (`process/lenses/repo-*.md`, with the repository's own
+  section, `lenses.<name>.section`, appended; system text
   `_common-repo.md`) and the dispositions in force.
 - A lens with the `browser` or `browser+supabase` environment (the
   functional lens by default; `lenses.<name>.environment` in the config):
@@ -159,7 +160,14 @@ is empirical and needs one with the browser while it runs; the static
 lenses default to `none` and may take any. A verdict bought in one
 environment is never reused, resumed or salvaged in another, and a defect
 found in one drops the clean verdicts the lens holds for the same code in
-the others), `supabase`, the database under test for every lens with
+the others; `section`, a file of the repository's own — a relative path
+inside it — appended to that lens's shipped charter after one blank line:
+the calibration entries and conventions that are this repository's rather
+than the lens's, which has the shipped charter for what is general to it;
+the reuse keys carry the combined text's hash; a path outside the
+repository and a file missing, unreadable or not UTF-8 (a dangling link
+included) are config problems, a name that is no lens an unknown key),
+`supabase`, the database under test for every lens with
 `supabase` or `browser+supabase`: `dbUrl` (the local stack's Postgres —
 this machine only; masked in the dump and the log), `start` / `stop` (how
 the operator brings the stack up when no lens drives the application;
@@ -360,9 +368,10 @@ the functional lens):
   never stored, so it runs on the next hash whatever changed;
 - every code unit and both whole passes: the range base (a rebase re-runs
   all of them);
-- as always: the lens charter, the prompt version, the model, the
-  dispositions in force. An edit to a `repo-*.md` charter re-runs that lens
-  on the next hash; a re-run on the SAME hash resumes and salvages by hash and
+- as always: the lens charter (the shipped text with the repository's
+  section), the prompt version, the model, the dispositions in force. An
+  edit to a `repo-*.md` charter, or to the repository's section of it,
+  re-runs that lens on the next hash; a re-run on the SAME hash resumes and salvages by hash and
   model alone (use `--no-reuse --no-salvage` there).
 
 What is stored as reusable: a pass that itself returned no undischarged
@@ -470,8 +479,10 @@ can still reject (a fixture repository with one planted defect per gate;
 
 A defect that reaches a pushed release, or a review comment on the
 repository nobody's lens predicted, is a process bug: post-mortem it and
-append a dated calibration entry to the `repo-*.md` lens that should have
-caught it, or here. The entries dated before 2026-10-15 were carried from the
+append a dated calibration entry where the lesson belongs: a lesson of
+this repository's in its own section of the lens that should have caught
+it (`lenses.<name>.section`), one general to the lens in the shipped `repo-*.md`
+charter, one of the mechanics here. The entries dated before 2026-10-15 were carried from the
 pipeline's earlier home because they are rules of the mechanics, not of one
 repository.
 

process/templates/config.json

@@ -13,63 +13,78 @@
   "lenses": {
     "repo-better-solution": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "repo-functional": {
       "run": false,
-      "environment": "browser"
+      "environment": "browser",
+      "section": null
     },
     "repo-bug-prover": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "repo-security": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "repo-facts": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "better-solution": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "code-quality": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "minimalism": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "bug-prover": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "facts": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "consistency": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "process-docs": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "etiquette": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "conciseness": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     },
     "maintainer-persona": {
       "run": false,
-      "environment": "none"
+      "environment": "none",
+      "section": null
     }
   },
   "supabase": {