@onlineapps/conn-orch-validator 7.0.0 → 8.0.0

package/CHANGELOG.md

@@ -4,8 +4,2564 @@ All notable changes to this package. Follows [Keep a Changelog](https://keepacha
 
 ## [Unreleased]
 
-> ⚠ Neither this entry nor the connector-step work of `dcddb862` is published.
-> The last version on NPM is 3.3.2, so **no biz CI run sees any of it yet**.
+### Added — zahazovací testovací schéma je export balíčku (d.407)
+
+`createThrowawaySchema` (`src/utils/throwawaySchema.js`, na indexu balíčku) staví schéma, které
+integrační sada vlastní: z deklarace `database` v `config/service/integration-contract.json`, se
+stejným rozhodnutím jako brána CI. Sdílí se **všechno kromě jednoho**: sada migrací a její pořadí
+(`resolveMigrationPlan`, `migrationOrder.js`), požadavek na collation (`requireCollation`), příkaz
+`CREATE DATABASE … COLLATE` (`createDatabaseSql`) i volání klienta (`defaultExec`) mají jedinou
+definici, v `setupDatabase.js`. Liší se ta jediná věc, kvůli které mají dvě jména: `buildSchema`
+staví OSTRÉ schéma služby, a proto odmítne cíl, který nezaložil; `createThrowawaySchema` staví
+schéma testu, a proto ho zahodí a založí znovu — a odmítá jediné jméno, to deklarované.
+
+Tvar vychází z toho, co si dnes staví služby samy (biz-meta `tests/helpers/schemaFixture.js`, tři
+sady): `before` zastaví před jmenovanou migrací (stav, na který se ta migrace aplikuje),
+`applyMigration(name)` pustí jednu, `readMigration(name)` vrátí její SQL, `dispose()` schéma zahodí,
+`seeds: true` doplní deklarované seedy (bez toho se neaplikují). Exekutor je injektovaný a smí být
+asynchronní — služba, jejíž testovací obraz nemá klienta `mysql/mariadb`, si předá vlastní.
+
+**Schéma vybírá volající, nikdy soubor.** Migrace psaná pro instalační běžec začíná
+``USE `oagen_<služba>`;``, tedy jménem ostrého schématu; aplikovaná doslova pošle celý soubor tam.
+Tyto řádky se proto odstraňují a výběr schématu, který strip přežije, běh zastaví. Změřeno na živé
+MariaDB: bez stripu vznikne tabulka v deklarovaném schématu a další migrace spadne na
+`Table '…_throwaway.probe' doesn't exist`.
+
+### Changed — R8 čte import helperu, ne řetězec `CREATE DATABASE` (d.407)
+
+Třetí propustka R8 (`fec9100a`) pouštěla soubor, který obsahuje `CREATE DATABASE` a přesměrování
+`DB_NAME`. To je textová heuristika: přečte dva řetězce a z nich usuzuje, kam dotazy dopadnou.
+Jakmile služba přesune stavbu schématu do sdíleného helperu — přesně to udělala biz-meta —
+propustka zanikne, ačkoli soubor je bezpečnější než předtím. R8 proto nově pouští soubor, který na
+vykonávaném řádku **importuje `createThrowawaySchema` z `@onlineapps/conn-orch-validator`**: kam
+dotazy dopadnou, tam rozhoduje kód (odmítnuté deklarované schéma, jméno zahazovacího schématu u
+každého příkazu, setřené výběry schématu v migracích), ne domněnka z textu.
+
+Obě poloviny se musí zasloužit na vykonávaném řádku a repozitářový modul stejného jména nezíská nic
+— důvěřuje se buildu tohoto balíčku, ničemu jinému. Měřeno nad `api_biz/meta`: dnes 3 hlášené
+soubory (`migration013MeditestMove`, `migration014MeditestRefsLeave100`, `platformIdentitySeed`),
+po záměně jejich importu za knihovní helper 0; táž kopie proti původnímu kódu R8 dál 3.
+
+### Changed — VALIDATION.md šablony nese hlášku chybějící collation (d.407)
+
+`templates/business-service/docs/80-setup/VALIDATION.md` (a jeho zrcadlo v `api/templates`) má v
+§ Failure signatures položku `[SetupDatabase] Missing database.collation …` a co s ní: doplnit klíč
+do bloku `database`. Blok `database` v šabloně nadále není — služba ho píše, až když databázi má.
+
+
+### BREAKING — `database.collation` je deklarace služby: brána s ní schéma zakládá a cizí collation odmítá (d.434)
+
+Rozhodnutí vlastníka 2026-09-14 (`api/docs/governance/confirmations/db-collation-declaration.md` 001,
+`api/docs/biz/70-contracts/database-contract.md` §1): collation, se kterou se schéma služby zakládá,
+deklaruje služba jedním klíčem v bloku `database`, a čte ho CI brána i produkční runbook. Žádný
+default (princip 3).
+
+`buildSchema` proto (1) bez klíče odmítne stavět a pojmenuje ho i s opravou, (2) **měří**
+`information_schema.SCHEMATA.DEFAULT_COLLATION_NAME` cílového schématu a (3) zakládá
+`CREATE DATABASE <schema> COLLATE <collation>` — nikdy `IF NOT EXISTS`. Ta tichá varianta je to,
+co tu dosud bylo, a nad existující databází NIC nezmění (změřeno BIZ-DOCS 2026-09-14 v jednorázovém
+`mariadb:10.5.29`): šest biz pipeline si nechá schéma založit sidecarem z `MARIADB_DATABASE` ještě
+před jobem, takže přesně v prostředí, kde brána běží, databáze už existuje — s defaultem obrazu
+`utf8mb4_general_ci`. Existující schéma s jinou collation tedy nově běh zastaví a pojmenuje obě
+collation, server i opravu (`MARIADB_COLLATION` v sidecaru, nebo `ALTER DATABASE`); se stejnou
+collation se nezakládá nic a migrace běží.
+
+Kontrakt (`bizCiGateContract.js`) validuje TVAR hodnoty, když je uvedena (utf8mb4 collation —
+interpoluje se do `CREATE DATABASE … COLLATE`, a klient i všechny tabulky platformy mluví utf8mb4),
+a nese ji v normalizovaném bloku dál. Řádek uniformy **`D-DB-COLLATION`** (`db`, severity `deploy`)
+hlásí repozitář s blokem `database`, který klíč nedeklaruje; služba bez bloku mlčí. Tři otázky, tři
+místa, žádná kopie: tvar = `C-CONTRACT`, přítomnost = `D-DB-COLLATION`, „bez hodnoty nestavím" =
+`setupDatabase`.
+
+**BREAKING pro služby**: `biz-ci-gate setup-db` selže každé službě s databází, která `collation`
+nedeklaruje. Na HEAD 2026-09-14 blok `database` deklaruje sedm repozitářů a klíč z nich má jediný
+(`property`, `utf8mb4_bin`); `converter`, `emailer`, `hello-service`, `ingest`, `invoicing` a `meta`
+ho doplní ve své kaskádě 8.0.0 (`pdfgen` databázi nemá a mlčí).
+
+RED → GREEN (jednotkově): `npx jest tests/unit/databaseDeclaration.test.js` 6 failed / 20 passed →
+26/26; `tests/unit/setupDatabase.test.js` 11 failed / 28 passed → 39/39; `tests/unit/manifestDbRows.test.js`
+3 failed / 26 passed → 29/29. Integračně proti živé MariaDB 10.5 (`setupDatabaseLive.integration.test.js`,
+sonda `tests/helpers/setupDatabaseProbe.js` v kontejneru nad `gen_mariadb10.5`): 3 failed / 6 passed →
+9/9 — schéma neexistuje → založeno a zpětně změřeno `utf8mb4_bin`; existuje prázdné se správnou →
+postaveno (4 migrace, 1 tabulka); existuje prázdné s `utf8mb4_general_ci` → odmítnuto, a po odmítnutí
+má 0 tabulek a pořád svou původní collation. Kontrolní případy beze změny: populované schéma dál
+padá na počtu tabulek dřív než na collation, služba bez bloku `database` dál hlásí
+`NOT APPLICABLE setup-db`, a řádek `D-DB-COLLATION` mlčí nad službou bez databáze i nad hodnotou
+špatného charsetu (ta patří `C-CONTRACT`).
+
+### Added — test drží, že `doc` každého řádku manifestu vede na existující dokument a sekci (d.438)
+
+`manifestShape.js` odmítá řádek BEZ `doc` (konfirmace `biz-service-manifest` 004 bod 1), ale nikdo
+se neptal, jestli ten ukazatel někam vede: přejmenovaný nebo přečíslovaný dokument udělá ze všech
+řádků, které ho citují, slepou uličku, a sada zůstane zelená — falešná záruka
+(`.claude/rules/automation-gates.md` §5), a totéž hnití, které `L008` chytá v opačném směru.
+`tests/unit/manifestDocPointers.test.js` prochází OBA manifesty a každý `doc`, kdekoli sedí: cesta
+se řeší stejným `resolveWorkspacePath` jako `from:` odkazy a musí existovat; `§ N` musí v dokumentu
+najít nadpis — a hlídají se obě reálné podoby, `## N.` ve `docs/biz/**` i `### §N` v konfirmacích,
+protože kontrola znající jen jednu by druhou hlásila jako mrtvou. Nečíselná citace
+(`§ Version pinning`) se řeší jako text.
+
+Nad HEAD je mrtvých odkazů nula (85 ukazatelů), takže RED se dokládá zasazením: `doc` řádku
+`D-DB-NAMING` přepsán na `database-contract.md § 42` → 1 failed se jménem řádku i chybějící sekce,
+po vrácení 7/7. Kontrolní případy, které to drží poctivé: neexistující dokument je hlášen, obě
+podoby nadpisu projdou, vymyšlená pojmenovaná sekce je hlášena, a kopie balíčku mimo checkout
+řekne NOT RUN místo tichého průchodu.
+
+### Fixed — `D-DB-NAMING` drží `database-contract.md` §5, takže `000_baseline.sql` je platné jméno (d.433)
+
+Regex řádku žádal „aspoň dvě slova" (`(?:_[a-z0-9]+)+`), ale pojmenování migrací vlastní
+normativní `api/docs/biz/70-contracts/database-contract.md` §5 a ten předepisuje
+`NNN_snake_case.sql` — tři číslice, podtržítko, popis malými písmeny — a `000_baseline.sql`
+uvádí jako svůj vlastní příklad; §8 z regenerované baseline dělá aplikovanou migraci. Řádek
+byl tedy přísnější než kontrakt a odmítal jeho příklad: `meta` i `emailer` (a `invoicing`)
+mají `migrations/000_baseline.sql` aplikovaný a dostávaly nález blokující deploy. Kvantifikátor
+je `*` místo `+`, `why`/`fix` cituje vlastníka pravidla místo vlastní formulace a pole `doc`
+míří na `database-contract.md § 5` — dosavadní `repository-installation-sql-contract.md`
+pojmenování souborů nedefinuje vůbec (definuje obsah `BASELINE/` a `SEED/**`, §4, což hlídá
+`D-DB-HEADERS`).
+
+RED (`npx jest tests/unit/manifestDbRows.test.js`): 1 failed / 22 passed — kontrolní případ
+`000_baseline.sql` dostal nález „three digits, then at least two snake_case words". GREEN:
+23/23. Kontrolní případy, které se nesměly hnout a nehnuly: `010_core_tables.sql` (druhý
+příklad §5) mlčí, `10_x.sql` (dvě číslice), `010_CamelCase.sql` (velká písmena), `010_.sql`
+(prázdný popis), `999a_diary_header_alias.sql` (přípona u pořadí) i soubor bez pořadí dál
+nález jsou; `BASELINE/`, `SEED/**` a služba bez databáze dál mlčí. Přes CLI
+(`node src/cli/oa-validate.js <repo> --json`) `meta` i `emailer` před opravou hlásily
+`D-DB-NAMING` na `migrations/000_baseline.sql`, po opravě nic; nad zbylými šesti biz
+repozitáři je řádek beze změny tichý.
+
+### Fixed — R6 odmítne pin na `@onlineapps/*` balíček, který SSOT nezná v žádném seznamu (d.413)
+
+Zúžení na `infraConsumed` pokrývá balíček, který SSOT DEKLARUJE a žádná infra služba ho
+neinstaluje — tam není s čím verzi porovnávat. Pin na `@onlineapps/*` balíček, který SSOT
+nedeklaruje ANI v `libraries`, ANI v `infraConsumed`, padal do téhož `notGated`, takže
+R6 hlásil OK pro balíček, který žádný platformní kontrakt nekryje (změřeno 2026-09-14,
+nález W401, `src/utils/libCompat.js:88` před opravou). Pravidlo R6 je, že služba pinuje přesně
+to, co SSOT deklaruje (`.claude/rules/architecture-principles.md` § Version pinning; kanál dat
+brány = SSOT, konfirmace `libraries-ssot-channel` 001) — u nedeklarovaného balíčku žádná
+taková verze neexistuje, takže se odmítá, ne zužuje (jinak je to fallback na „not gated",
+princip 3). `notGated` zůstává pro deklarovaný balíček, který infra neinstaluje; balíčky mimo
+scope `@onlineapps/*` se do něj nikdy nedostaly (filtr `SCOPE` v `checkLibCompat`).
+
+RED (`npx jest tests/unit/libCompat.test.js tests/unit/bizCiGateCli.libCompat.integration.test.js`):
+4 failed / 32 passed — jednotkově `ok` bylo `true` místo `false`, přes CLI prázdný `stderr` a
+exit 0. GREEN: 36/36. Kontrolní případy, které se nesměly hnout: balíček v `infraConsumed`
+chybějící v `libraries` dál hlásí svou větev (`not present in the infra library set`), shodný
+pin dál prochází, týž repozitář s toutéž pinovanou verzí při deklaraci v SSOT je dál `not
+gated`. Fixtura `api/tests/scripts/lib-compat.bats` (smoke obálky `verify-lib-compat`)
+deklarovala balíček pro případ „narrowing skipped" v žádném seznamu; po opravě ho SSOT fixtury
+deklaruje, takže případ dál popisuje to, k čemu byl napsán (5/5).
+
+### Added — R6 má sadu, která drží, že se na něj `verify-contract` DOSTANE (d.401, `436095a7`)
+
+Ze čtyř sousedních poskládaných kontraktů má každý svou `bizCiGateCli.*.integration.test.js`;
+R6 byl jediný bez ní — a je to ten, který biz repozitáře pouštějí každou pipeline.
+`bizCiGateCli.libCompat.integration.test.js` měří akceptační kritérium R6 přes CLI, které
+pipeline skutečně spouští (`ci:gate:contract` = `biz-ci-gate verify-contract`, 8/8 repozitářů;
+samostatný `verify-lib-compat` v žádném `.gitlab-ci.yml` není): neshodný pin → exit 1 s oběma
+verzemi, caret odmítnut, devDependency stejně jako dependency, balíček mimo `infraConsumed`
+hlášen jako not gated, nenakonfigurovaný nebo nečitelný SSOT odmítnut místo tichého průchodu,
+a shoda verdiktu se samostatným subcommandem. RED s odstraněným fold-inem: 8 failed / 2 passed
+(projdou právě dva testy samostatné koleje — kontrolní případ); GREEN 10/10.
+
+### Changed — konformní fixtura biz repozitáře má jedno místo (d.401, `436095a7`)
+
+`tests/helpers/conformantBizRepo.js`: repozitář, který projde deploy, installation, env
+a test-coverage kontraktem, takže exit kód poskládaného běhu je přiřaditelný. Dvě sady
+potřebují totéž; definice opsaná dvakrát se rozejde, jakmile kterýkoli z kontraktů dostane
+pravidlo (`change-discipline.md` § One rail per concern).
+
+### Fixed — `checkSetupDocs` and the manifest check ask for the exact spelling (d.408)
+
+`fs.existsSync` answers true for `install.md` when the contract spells `INSTALL.md` on a case-insensitive filesystem (macOS APFS), so the install-contract gate passed on a developer machine and failed in `node:24-alpine` (BIZ-PROPERTY, 2026-09-14: 361 findings vs 363). Both places now use `existsExactly` from the git-tracked check — one rail for the trap, exported rather than copied. RED on macOS: a setup doc renamed to lower case passed; GREEN: it is reported as missing on every filesystem.
+
+### Fixed — the contract gates verify their input on the way in (d.400, `98cbb2ab`)
+
+`verifyEnvCompleteness` and `verifyInstallContract` returned `ok: true` over a loader envelope (`{contract, source, …}`) instead of the normalized contract — a gate passing over a declaration it never checked (`automation-gates.md` §5). They now refuse anything but the normalized shape with `[Context] Problem - Expected/Fix`, through the one normalizer the CLI already uses.
+
+### Fixed — `write-summary` cannot be talked out of a failure it measured (d.392b, `3b445f05`)
+
+`--gate-verdict pass` no longer withdraws a failing integration minimum: the measured verdict wins, `--gate-verdict` may only make the verdict worse, and the artefact's reason names the refused override in `[Context] Problem - Fix` form — neither the caller's `--gate-reason` nor the failure's own message stands in its place (`automation-gates.md` §1.5). The CLI help for `--gate-verdict` says what the switch does now. A backtick inside the help template literal took the whole CLI down during the change (`SyntaxError`), caught by the suite; `node --check src/cli/biz-ci-gate.js` is part of the gate from here.
+
+### Changed — the service template stops stating library versions by hand (d.392, `e7943612` … `a8d3c281`)
+
+- `templates/business-service/package.json` pins every `@onlineapps/*` dependency with the `__SSOT_PIN__` placeholder; `oa-sync-template --new` resolves it from `api/config/libraries.json` and refuses a placeholder it cannot resolve. The template used to claim `service-wrapper 2.1.119` and `service-common 1.1.1` while the SSOT said 7.0.0 / 2.0.1 — a number written by hand is a lie with a commencement date. Existing services keep getting their pins from the publish cascade, never from the template. (d.392/1)
+- `docker-compose.production.yml` of the template no longer declares `DEPLOY_ENV` — zero readers anywhere in the workspace (`process.env.DEPLOY_ENV`, `$DEPLOY_ENV`: none); `NODE_ENV` from the shared env manifest owns that fact. Nine manifest fixtures follow (`G-PROD` is `template-render`). (d.392/3, 3b)
+- `biz-ci-gate setup-db` over a service with no `database` block reports `NOT APPLICABLE` with the contract path, instead of `OK` for work it never did. The template's README and `docs/80-setup/INSTALL.md` state that the one-shot test runner is outside a plain `docker compose build` and name `docker compose --profile test build` (measured with `--dry-run`: one image vs two). (d.392/6)
+
+### Fixed — `write-summary` names the step that failed (d.392/5, `47f9114c`)
+
+`gate.reason` comes from the step that failed — the caller's `--gate-reason`, or the integration minimum when that is what failed, or `unknown step failed`. A declared failure with no reason no longer reports "integration minimum satisfied".
+
+### Added — manifest self-test over the template's npm scripts (d.392/2, `4473b956`)
+
+`tests/unit/templateScriptSelftest.test.js` checks the packaged template's scripts against the manifest in both directions, with the deliberately-free list and its reasons (`test:container` stays as a declared exception; `test:integration:container` is `only_with: tests/integration`, which the template does not ship). The CI `test` job of a service is the service's own — the `oa-ci v1` block does not render it (confirmation `biz-service-manifest` 008, d.251) — so the template carries no conditional `mariadb-client`/`XDG_RUNTIME_DIR` rendering; that finding is closed by the recorded decision, not by code.
+
+### Fixed — every `format.md §` citation in the package names a section that exists (d.393b, `631d0cce`)
+
+`CookbookTestRunner` sent cookbook authors to `format.md § Steps` from five messages. The node has no such section, and the five do not even share one owner: a missing `config/service/operations.json` is owned by `30-operations/schema-v3.md § File shape` — `format.md` decides nothing about that file, so the citation named the wrong NODE, not merely the wrong section — while the absent/empty `steps` belong to § Required fields and a step missing `service`/`operation` to § Step definition. All five now say where the answer is. `tests/unit/cookbookFormatDocReference.test.js` no longer checks a single module: it scans every `format.md §` citation under `src/` against the node's headings, carries its own case for the relocated operations.json citation, and says NOT RUN out loud when the node is absent from the checkout. `L008` cannot catch this class — it verifies the document behind a citation, never the section behind `§`.
+
+### Fixed — every fixture cookbook obeys the `step_id` pattern, and a gate now holds it (d.393b)
+
+The last six fixture steps spelling `step_id` with a hyphen (`v3-cookbook-service/**`, `v3-service-undeclared-handler/**`) are on the underscore spelling the schema requires (`^[a-zA-Z0-9_]+$`, `cookbook.v2.schema.json`, every step type); their six assertions prove the same outcomes under the new names. With compliance in the same commit — never ahead of it — `tests/unit/fixtureCookbookStepIds.test.js` widens from two fixture workspaces to the whole `tests/fixtures/**` tree, with no exception list. Files that are not valid JSON are counted rather than silently skipped, and a control case names the only one that is meant to be broken.
+
+### Fixed — the cookbook-format refusals cite a section the node actually has (d.393, `c5611383`)
+
+`readCookbookSteps()` sent a cookbook author to `api/docs/biz/40-cookbooks/format.md § Steps`. The node has no such section: both halves of the rule — `steps` is an array, and a step identifies itself with `step_id` — are owned by § The array is the only accepted shape. `L008` cannot see this class of defect; it checks the document behind a citation, never the section behind `§`. Both messages now name the real section, and `tests/unit/cookbookFormatDocReference.test.js` extracts the citation from the message the module actually throws and matches it against the node's headings (NOT RUN, loudly, when the node is absent from the checkout).
+
+### Fixed — fixture cookbooks obey the `step_id` pattern the schema enforces (d.393)
+
+Seven fixture steps spelled their `step_id` with a hyphen, which `cookbook-core/schemas/cookbook.v2.schema.json` refuses on every step type (`^[a-zA-Z0-9_]+$`) — a shape production rejects and the offline Tier-1 runner accepts, because the runner checks no pattern at all. The six cookbooks now use the underscore spelling, their suites assert the same outcomes under the new step names, and `tests/unit/fixtureCookbookStepIds.test.js` reads the pattern from the schema instead of restating it. Four fixture files under `v3-cookbook-service/**` and `v3-service-undeclared-handler/**` still carry the defect and are deliberately outside this test's scope — an open finding (d.393b), not a silent pass.
+
+### Security — the biz CI template stops putting the registry password on a command line (d.389, `ccde5b17`)
+
+`templates/business-service/.gitlab-ci.yml` logged in to the registry with `-p $CI_REGISTRY_PASSWORD` on the runner, and handed the same password to the deploy host as an argument of the remote `bash -s` — visible in `ps` on both machines for the length of the job (INFRA-DOCS finding, 2026-09-14). The password now travels on stdin only: the build logs in with `--password-stdin`, and the remote stream carries the password as its first line, which the remote shell reads and exports before `bash -s` gets the rest. The remote positional arguments are six and none of them is the secret. Proved by `tests/scripts/biz-deploy-secret-handling.bats`, which runs the template's own shell with doubles that record argv and stdin on both sides.
+
+### Security — both boxes the deploy job talks to are pinned (d.389)
+
+The job's `~/.ssh/config` said `StrictHostKeyChecking no`, so the deploy key, the registry password and the gate-reader key went to whatever answered on the address. The catch-all now carries `StrictHostKeyChecking yes` and `UserKnownHostsFile ~/.ssh/known_hosts`, written from the new CI variables `DEPLOY_HOST_KEY` and `GATE_INFRA_HOST_KEY` (one `ssh-keyscan -t ed25519` line each); the policy lives in `ssh_config` rather than on the command line because `run-post-deploy-gate.sh` opens its own ssh connection and takes no switches from the template — one rail for both. A missing pin fails the job before the first connection, naming the variable and the command that produces its value — never a fallback.
+
+### Changed — `installContract.js` enforces the whole contract, not three directories and four keys (d.320, `d6321fd2`)
+
+BREAKING for any repository whose live SQL lay outside `migrations/{BASELINE,SEED}`: the loop is now `migrations/**/*.sql` minus `archive/` and `superseded/` (confirmation `installation-sql-contract-scope` 001). Measured on HEAD: invoicing 5 files and property 90 files carried no header at all and passed. The header VOCABULARY is checked, not the presence of the key (§4): `Dataset-Class`, `Safe-For-Production` and `Idempotency` accept only the values the contract defines, the value is the first token and free text may follow it; `Target-DB` stays presence-only — the contract calls it a name, not a vocabulary, and comparing it against `database.schema` would make the header a second copy of that fact. Test-only data must carry its visible `TEST-ONLY` comment marker, and `Dataset-Class: TEST_ONLY` anywhere implies `Safe-For-Production: no` (the rule follows the class, not the directory). A manifest package is complete in BOTH directions (§5, §7): every file an `-- Applies:` line names exists, every `.sql` the installer applies is named, and the order is the installer's own (`migrationOrder.compareVersion`, shared with `setupDatabase.js` and the operator's `sort -V`); a file is a manifest exactly when it carries `-- Applies:`. The module cited ADR 0006, where the rule does not live — `Rules:` now names `api/docs/standards/repository-installation-sql-contract.md`, so L008 checks it. RED 14/31 → GREEN 31/31.
+
+### Changed — the delay test states WHEN, not how long the machine took (d.379)
+
+`MockMQClient.test.js` § Delay Simulation measured `process.hrtime` against a 2 ms
+tolerance and a 500 ms ceiling, and went red on roughly one run in four under concurrent
+load. A verdict that depends on how busy the machine is fails the first requirement
+`automation-gates.md` §1.1 puts on any automatic mechanism, and a flake teaches everyone to
+re-run instead of to read. Fake timers replace the stopwatch: the promise is pending at
+`DELAY_MS - 1`, settled at `DELAY_MS`, and no timer is left behind. The three claims are
+unchanged — it waited, it waited once, it waited in the right scale — and each was
+confirmed by breaking `simulateDelay` those three ways and watching the suite go red.
+
+### Removed — three declarations with no consumer (d.378)
+
+- **`operation.headers`.** The dispatch descriptor carried `headers: operation.headers || {}`
+  and nothing read it: ctx.headers is built from `step.headers`, which is what the contract
+  prescribes (api/docs/biz/10-invocation/operation-context.md § ctx.headers names the STEP).
+  The operations.json rules in `service-validator-core` know no `headers` field, and not one
+  of the eight live `config/service/operations.json` declares it. A field nobody reads, in a
+  shape nobody may declare, taught readers that an operation could carry headers.
+- **`mockInfrastructure` in seven cookbook fixtures.** The runner mocks on
+  `options.mockInfrastructure`, which `utils/preValidation.js` passes; the cookbook format
+  carries no such key (`cookbook-core/schemas/cookbook.v2.schema.json` calls `test`
+  acceptance-test metadata, `docs/biz/40-cookbooks/format.md` never names it). One
+  declaration, in the options. The schema admits additional properties at both levels, so
+  nothing can refuse the key at load time — `cookbookMockInfrastructure.test.js` is what
+  keeps it from growing back.
+- **The second copy of the service fixture.** `tests/fixtures/cookbook-counts/service`
+  duplicated `v3-test-service` and had already drifted apart from it — the `returns-nothing`
+  operation and its handler existed in one copy and not the other — while
+  `cookbook-counts/two-cookbooks` held a byte-identical copy of that service's own cookbooks.
+  One fixture now, read by all three suites (`change-discipline.md` § One rail per concern).
+
+### Fixed — the step aggregate adds up: `passed + failed === total` (d.378)
+
+A cookbook that threw on load pushed one entry into `results.steps` and incremented
+`failed`, and nothing incremented `total` — so a run could report `total 2 / failed 3`
+(BIZ-converter, 2026-08-26): an aggregate whose own arithmetic contradicts itself, read by
+`utils/preValidation.js` to decide whether a proof is written and folded by
+`ValidationOrchestrator` into the run's totals. One definition now: everything in
+`results.steps` is counted in `total` exactly once — a real step, or the single entry
+standing for a cookbook that never produced any. Two suites had encoded the old arithmetic
+(`total: 1` against `failed: 2`, and seven failures out of a total of zero) and now state
+the rule instead.
+
+### Fixed — `expect.error` is checked when the step SUCCEEDS too (d.378)
+
+`validateExpectations` guarded the error block with `if (expect.error && result.error)`,
+the sister defect of the `expect.output` guard one block up (d.365). A cookbook declaring
+`expect.error` over a step whose handler returned normally skipped the block entirely, and
+since `expect.status` is optional, a step declaring only `expect.error` came back with
+`validationErrors: []` — green, over an expectation nothing evaluated
+(`automation-gates.md` §5). The absence of the error is now the violation and says so in
+the `[Context] Problem - Expected/Fix` form; a step that genuinely throws is judged exactly
+as before.
+
+### Fixed — the Tier-1 runner reads the workspace the cookbook declares (d.354)
+
+`CookbookTestRunner` built its ctx from `getTestNamespace()` alone, so
+`defaults.workspace_id` and the per-step override the format defines were fields
+nothing read — six emailer cookbooks carried a value the boot probe ignored. Owner
+confirmation `tier1-runner-workspace` 001 (2026-09-14): the runner reads the cookbook.
+
+Per-step wins over `defaults`, and a cookbook that declares neither keeps the platform
+namespace from the environment — 32 of 44 cookbooks in the eight live biz repositories
+declare no workspace, so refusing there would fail six services' boot on day one
+(`automation-gates.md` §3). The TENANT does not move: it stays `getTestNamespace()`'s, so
+no cookbook can walk the probe out of an allowed environment class. A declared workspace
+passes the same rail as the environment value — `assertWorkspaceId` in
+`utils/testNamespace.js`, new and exported from that module — so a value that is not an id
+is refused naming the cookbook key, never swapped for the env value.
+
+### Added — `C-CONNECTORS`: the two connector declarations must agree (d.353)
+
+`verifyConnectorContract` has compared `config/service/config.json` → `wrapper.<connector>`
+against `integration-contract.json` → `requiredConnectors` since F12, and nothing acted on
+the answer: at boot it went into `results.warnings` and the service started, and no CI job
+ran it. Owner confirmation `connector-contract-check` 001 (2026-09-14): a uniform row,
+severity `deploy`. The boot is unchanged — it still reports and still starts.
+
+The row asks only the declaration half; the environment half (`REDIS_URL` and friends)
+stays at boot, where an environment exists. The rule itself stays in one place —
+`utils/connectorContract.js` → `mismatches()` — with `verifyConnectorDeclarations` and
+`verifyConnectorContract` as its two phrasings. Measured against all eight services before
+the row landed: zero findings.
+
+### Fixed — cookbooks and steps are counted apart, and `expect.output` is always checked (d.365)
+
+- `Cookbook tests: X/Y` counted STEPS while saying cookbooks, so three one-step cookbooks
+  read as "3/3" and the day one gained a second step the number rose with no cookbook added
+  (BIZ-converter, 2026-08-27). The aggregate now carries `cookbooks: {total, passed, failed}`
+  beside the step counts, and both lines name their unit: `Cookbooks: 2/2 passed (3/3 steps)`
+  at boot, `cookbooks — 2/2 passed, steps 3/3 passed, 0 failed` from the CLI. A cookbook that
+  cannot be loaded counts as a failed cookbook, never as one nobody counted.
+- `expect.output` was guarded by `if (expect.output && result.actual)`, so a step whose
+  handler returned nothing skipped every field assertion and passed on `status` alone
+  (BIZ-pdfgen, 2026-08-29). The guard is gone: `validateOutput` already answers correctly
+  for an absent output — a required field is missing, and an `exists: false` assertion is
+  satisfied by no output at all.
+
+### Added — `run-prevalidation --operation <regex>` (d.365)
+
+Only the cookbooks holding a step whose operation matches are run, and they run WHOLE — a
+later step reads what an earlier one wrote. A filtered run writes NO validation proof: a
+proof is the claim that the whole cookbook set passed. An expression matching nothing is an
+error naming the operations the directory does run, never an empty pass
+(`automation-gates.md` §5). This is what lets BIZ-emailer delete
+`tests/cookbooks/run-all.js`, the second way of running cookbooks their
+`COOKBOOK_OPERATION_FILTER` kept alive (`change-discipline.md` § One rail per concern).
+
+### Fixed — `run-prevalidation` ends instead of hanging on the service's own pool (d.365)
+
+Measured 2026-09-14: with a handler that leaves one live handle behind — which is what a
+service's module-level Sequelize pool is — the command printed every line, wrote the proof,
+and then hung until a 15 s kill. The connectors are NOT closed, deliberately: at boot the
+same dispatch runs inside `ServiceWrapper` phase 0.2 and that pool serves the service for
+the rest of its life. What differs is the lifetime, so the one-shot command states its exit
+code and ends, after flushing both streams (`process.exit` can truncate a pipe).
+
+The finding that led here (BIZ-ingest, 2026-09-07) named a per-service
+`scripts/run-pre-validation.js` masking the pool with `process.exit(0)`. That script is
+retired — `X-PREVAL` forbids it and the template does not carry it — so nothing masked the
+leak any more, and the hang is what was left.
+
+
+### Fixed — a marker inside a fence is an example, and `--all` stops matching markers by hand (d.319)
+
+Two modules carry the same marker shape: `api/scripts/ci/lib/generatedRegion.js`, which the
+biz-facts and infra-queue generators render through, and this one, which `docsRegion.js`
+and `readmePointer.js` render through. Only the first knew that a marker shown inside a
+fenced code block is an EXAMPLE. The api side learned it the hard way on 2026-09-09, hours
+after the queue generator landed: `api/docs/standards/INFRA-DOC-STANDARD.md` documents the
+marker pair inside a fence — it still does, at the section on generated regions — and the
+generator took its own documentation for a region naming a queue family that does not
+exist, a gate red on the tree it had just been added to (`automation-gates.md` §3).
+
+This module writes into the same tree, and the documents it writes into are precisely the
+ones that TEACH the shape (`docs/biz/60-templates/service-template.md`,
+`docs/guides/library-publishing-process.md`, `docs/guides/DEVELOPMENT.md` — the last already
+shows the markers in prose at `library-publishing-process.md`). One input, two answers,
+depending on which module met it, is what `automation-gates.md` §1.1 calls unpredictable.
+`findRegion`, `extractRegion` and everything built on them now skip fenced markers, so a
+document that only shows the pair declares no region and is never written into.
+
+What did NOT change, and is covered by its own case: an UNFENCED lone marker is still
+damage and still throws, and an inverted pair still throws. Fence-awareness must not turn a
+half-written region into silence.
+
+`generatedRegion.hasRegion()` is new, and `docsRegion.regionIdsIn()` — the question `--all`
+asks before it renders anything — now goes through it. It was the one place in the package
+that matched a marker string by hand, which is a second and fence-blind copy of this
+module's own rule (`change-discipline.md` § One rail per concern).
+
+**What d.319 deliberately did not do**, with the reason on record rather than as a silence:
+
+- **`docs-region` is not retired.** Confirmation `biz-service-manifest` 002 §16.2 and 003
+  §3.3 require the descriptive lists of those three documents to be a rendered region fed by
+  the MANIFESTS; `sync-biz-facts.mjs` does not read a manifest (zero matches on `manifest` in
+  that file), so retiring this renderer would leave the confirmation unimplementable.
+- **No `D-REGION` row over the biz repositories.** Measured 2026-09-14:
+  `grep -rn "BEGIN GENERATED" api_biz` returns nothing — not one of the eight trees carries a
+  region today, and these five regions live in `api/docs/**` in any case. A row checking
+  eight repositories for something none of them bears, and none of them should, is the gate
+  that matches nothing of `automation-gates.md` §5.
+- **The two modules are still two.** They can become one the day this package is published:
+  the api gate runs `npm ci` and would import the RELEASED version, so importing it today
+  would tie a running gate to unreleased code. BIZ-DOCS recorded the same measurement and
+  offered the wiring (`api/shared/TODO.md`, their 2026-09-11 entry); this change makes the
+  merge possible by giving this module the behaviour the api one has. The divergence that
+  remains after that is the error contract — this module throws where the api one returns
+  `{error}` — and it is the caller's to absorb, in the change that deletes the copy.
+
+### Fixed — `ci:gate:setup` builds the operator's schema, and refuses anybody's database (d.338)
+
+Three defects in one path, all of them reported from services and none of them visible
+from inside the gate's own green run.
+
+**The order was a second definition of itself.** The real installation is built by
+`api/scripts/apply-oagen-meta-install-sql.sh` with
+`find … -name '*.sql' | LC_ALL=C sort -V`; `setupDatabase.js` used JavaScript `Array#sort`,
+which is lexicographic. BIZ-META reported it on 2026-08-29 as latent, on the reasoning that
+three-digit zero-padded prefixes sort identically either way. It is not latent: measured
+2026-09-14 over `api_biz/property/migrations` (87 files), `999_layer_tick.sql` is applied
+LAST by the operator and FIRST of the `999*` group by CI, because `_` (0x5F) precedes `a`
+(0x61) byte for byte while version order compares the digit run first. That is exactly the
+shape `.claude/rules/architecture-principles.md` § Version pinning names — CI proving one
+artefact while the deployment runs another — and with migrations the order IS semantics.
+
+`migrationOrder.js` is a port of what the tool actually does (GNU coreutils `filevercmp`
+over gnulib `verrevcmp`), not an approximation that happens to agree on today's names, and
+its expectations come from the tool's own output: the `@integration` case re-runs
+`LC_ALL=C sort -V` during the suite and compares. The alternative — demanding the
+`NNN_` convention `D-DB-NAMING` declares — was rejected because the nine `999a_`…`999i_`
+files in property do not follow it, and a gate lands with compliance, never ahead of it
+(`automation-gates.md` §3).
+
+**A populated target was accepted.** `database.schema` is the REAL name (`oagen_emailer`,
+the same string on the dev server and in production), so nothing about the name
+distinguishes the CI sidecar from live data, and "does it already exist" cannot be the
+criterion either — every biz `.gitlab-ci.yml` has the sidecar create it empty through
+`MARIADB_DATABASE`. BIZ-emailer reported on 2026-09-04 that they had found nothing
+blocking a `npm run ci:gate:setup` against dev; there was nothing. The criterion is the
+premise the build already rests on: the set is proved by applying it to an EMPTY schema
+(ADR 0006 §3). A target holding tables breaks it twice — the run proves nothing, because
+what it would create is already there, and a declared seed carries no `IF NOT EXISTS`. So
+the build now asks `information_schema` first and refuses, naming the schema, the server,
+the count and how to get a legitimate target. A probe that cannot run, or answers nothing
+countable, is a failure and never a pass.
+
+**The charset flag had no test.** `--default-character-set=utf8mb4` has been on the client
+invocation since the gate was written, and BIZ-invoicing confirmed on 2026-09-05 that the
+installer is the clean path — but nothing held it there. `setupDatabaseLive.integration.test.js`
+runs the real build against the dev MariaDB 10.5.17 in a throwaway schema it creates and
+drops, and compares `HEX(note)` with the UTF-8 bytes of the source, so the answer does not
+depend on the reading client either. Its control writes the same text through a latin1
+client and requires the bytes to differ: without that, the case could pass on a leniently
+configured server and prove nothing about the flag.
+
+The executor contract gains one field, `capture`, which asks for the client's stdout in a
+bare shape (`--batch --skip-column-names`). Only the emptiness probe uses it; a migration
+produces nothing to read.
+
+**And the message when no client is on PATH said the wrong reason.** It read "required
+because migrations use DELIMITER"; BIZ-hello met it on 2026-09-14 in the first hello
+pipeline to reach `ci:gate:setup` (job 2845685968) with no `DELIMITER` anywhere in its
+migrations. The requirement and the fix were right, the reason was not — and a service
+without triggers reads it as "this does not apply to me" and goes looking for a
+`DELIMITER` that is not there. The client is required unconditionally, because every
+statement goes through it, the first `CREATE DATABASE` included, and there is no driver
+path; the message now says that (`architecture-principles.md` §5), with a case over its
+text and a control that it no longer blames `DELIMITER`. Why the CLI rather than a driver
+IS the DELIMITER story, and that stays where it belongs: the file's own header.
+
+### Added — `F-DOCKERIGNORE`: a local production build stops copying live secrets into the image (d.316)
+
+`templates/business-service/Dockerfile` line 6 is `COPY . .` and the template carried no
+`.dockerignore` at all, so every service scaffolded from it was born with the defect
+BIZ-hello measured on 2026-09-11: a LOCAL production image of hello came to **6.6 GB**,
+5.2 GB of it `logs/`, and carried `config/env-active/*.env` with `DB_PASSWORD`,
+`JWT_SECRET`, the MinIO keys and `RABBITMQ_URL`. Being ignored by git excludes nothing
+from a docker context. The image CI builds is clean by accident — a fresh checkout has no
+ignored file to copy — which is why the defect is invisible exactly where images are built.
+
+The row is `F-GITIGNORE`'s shape (`contains`, severity `deploy`, fix = the sync) over the
+SAME declaration, `templates/business-service/gitignore`: one list, two consumers
+(`change-discipline.md` § One rail per concern). The derivation TRANSLATES rather than
+copies, because the two formats disagree about the same line — a slash-less `.gitignore`
+pattern matches at every depth, a `.dockerignore` one is matched from the context root, so
+`*.log` there would catch `debug.log` and not `logs/debug.log`. Slash-less entries are
+emitted in both shapes, anchored ones travel unchanged, a negation keeps its `!` in front
+and its place, and `.git` is added — the one exclusion git never has to declare about
+itself. The other trap hello named is avoided by construction: the derivation can never
+exclude `tests/`, which Tier-1 of the boot reads at phase 0.2, because `.gitignore` does
+not exclude it either.
+
+The criterion is hello's comparison, not a list of directories, and it is now a test:
+`dockerignoreBuildContext.integration.test.js` builds the template twice through docker
+itself — `FROM scratch` + `COPY . /app` exported locally, so the matcher under test is
+BuildKit's own — from a working tree carrying `logs/`, `config/env-active/`, `ci/` and
+`node_modules/`, and from `git archive HEAD` of the same commit, and asserts the two file
+lists are equal. Its failure path removes the file and asserts the secrets and logs come
+back. With no docker daemon it says NOT RUN with the reason rather than passing.
+
+Compliance landed with the row: the packaged template, the committed mirror
+`api/templates/business-service` and every fixture carry the generated file.
+
+RED→GREEN: `manifestDockerignore.test.js` 9 failed → 9 passed (99 suites, 1593 tests);
+`dockerignoreBuildContext.integration.test.js` 2 passed against a live daemon;
+`api/tests/scripts/add-service.bats` asserts a scaffolded service is born with both ignore
+files, 68/68.
+
+### Added — `R-PID1`: the process a biz container runs AS is part of the uniform (d.315)
+
+Confirmation `biz-compose-pid1` 001 settled the substance on 2026-09-05 — `command:
+["npm","start"]` makes npm process 1, and npm does not forward SIGTERM, so a stop is ten
+seconds of waiting followed by SIGKILL through a service that never closed a channel — and
+002 (2026-09-13) settled where the decision belongs: *"zaroven by to asi melo byt u vsech
+biz servis reseno jednotne a tudiz by to melo byt soucasti uniformy"*. Until now it
+travelled by being remembered: measured 2026-09-14 over the eight dev composes, **six still
+say `npm`, two say `node`**, eight days after the decision.
+
+`R-PID1` (section `runtime`, severity `deploy`, `doc` → `biz-compose-pid1.md`) reads the
+service block of `docker-compose.yml` and reports anything that is not `node index.js`. It
+accepts both spellings compose allows — `["node", "index.js"]` and `node index.js` — because
+they are one decision written two ways, and a row grading the spelling would report a
+service that is already right. An unreadable bracket form is a finding, not a pass. The
+one-shot test runner is outside the row: it declares no command because `docker compose
+run` supplies one, and its shape is `F-RUNNER`'s.
+
+**Compliance landed with the row, not after it** (`automation-gates.md` §3): the packaged
+template's own `docker-compose.yml` said `["npm","start"]` — every service
+`add-service.sh --scaffold` had created since would have been born with the defect — and
+now says `["node", "index.js"]`, with the reason beside it. The committed mirror and the
+fixtures are regenerated in the same change. The eight live repositories switch in their
+own 8.0.0 cascade commit, citing 001, the way confirmation `biz-service-manifest` 009
+sequences `X-DB-CONFIG`; `R-PID1` ships in the same unreleased version, never ahead of it.
+
+RED→GREEN: `tests/unit/manifestServiceConfig.test.js` 3 failed → 1580/1580 in 97 suites,
+covering the finding, the service that declares no command at all, both spellings, the
+unreadable form, and the CONTROL that the one-shot runner is never reported.
+
+### Added — the biz `deploy-production` job runs the post-deploy gate of the target it declares (d.306)
+
+Confirmation `deploy-gate-targets` 003 point 2. Until now the biz target of
+`api/scripts/run-post-deploy-gate.sh` was called by nobody: measured 2026-09-10 over all
+eight repositories and over this template, 0 callers. A deploy that ends at "the SSH step
+returned 0" has confirmed that compose was told to start something, not that the service
+came up — which is the false guarantee `automation-gates.md` §5 names, and it would have
+made the `deploy-gate-restart-count` 001 decision (a restart loop is a FAIL) unreachable.
+
+The `oa-ci v1` block's `deploy-production` job therefore:
+
+- **declares its target** — `DEPLOY_GATE_TARGETS: "biz:__REGISTRY_NAME__"`. The gate has
+  no default; the job says which checks judge it (002). The name is the registry identity,
+  which is the key `api/config/services.json` and the contract file both use;
+- **runs the gate after the SSH step**, in REMOTE mode
+  (`--biz-host "$DEPLOY_USER@$DEPLOY_HOST" --infra-host "$GATE_INFRA_USER@$GATE_INFRA_HOST"`),
+  out of the read-only `api` clone the uniform step already made beside the checkout. That
+  path is derived from `CI_PROJECT_DIR` rather than spelled a second time, so the layout
+  stays declared once, in `GIT_CLONE_PATH`;
+- **carries a second SSH identity** — the gate-reader key for the infra box, in its own
+  `Host` block with `IdentitiesOnly yes`, so neither key is offered to the other box;
+- **refuses BEFORE it installs or deploys anything** when `GATE_INFRA_HOST`,
+  `GATE_INFRA_USER` or `GATE_INFRA_SSH_PRIVATE_KEY` is empty, naming the missing ones and
+  the fix (`architecture-principles.md` §5). There is no branch that skips the gate
+  (`automation-gates.md` §1 requirement 5);
+- **installs what the gate needs** on an alpine runner: `bash` (the script declares
+  `bash>=4` for `declare -A`), `jq`, `curl`. No `docker` — in remote mode every docker call
+  is carried to the box that holds the fact.
+
+RED→GREEN: `api/tests/scripts/biz-deploy-uniform-gate.bats` 2 failed → 11/11, including
+the failure path (no identity → exit 1 naming all three variables), the single-variable
+case (the message names THAT one) and the CONTROL that a fully configured check says
+nothing and gets out of the way. The 13 fixtures and the committed mirror
+`api/templates/business-service` are regenerated in the same change.
+
+### Added — `D-LINT`: the documentation tree is clean, not merely clean of five classes (d.303)
+
+The documentation block named five classes — a localhost port, a dead script citation, a
+missing npm script, a retired concept, a missing header — and stayed silent about every
+other rule the lint raises. Measured 2026-09-09 over the eight repositories: **80 lint
+findings, 16 of which fell to a row here.** A tree the documentation gate called broken
+came back DEPLOYABLE from this uniform, which is the false guarantee `automation-gates.md`
+§5 is about.
+
+`D-LINT` (section `docs`, severity `deploy`, `doc` → `api/docs/biz/DOC-STANDARD.md`) says
+the lint reports nothing over this service's tree. It **cites no rule id**: a citation
+list here would have to be held equal to the linter's and would fall behind it the first
+time BIZ-DOCS wrote a rule (confirmation `biz-service-manifest` 004 point 2 — the manifest
+cites, it never restates). The five rows above keep their findings and their `fix`
+sentences; one finding still lands on exactly one row, and this one takes what is left.
+
+**The safeguard that lets it land before every tree is clean**: it counts only what the
+LINT graded `error` — the set its own `--severity error` prints, read from the one run the
+block already makes rather than bought with a second process. Grading belongs to BIZ-DOCS
+(`api/config/biz-docs-lint.json` § severities), so a rule they add at `warn` is visible in
+their run and blocks no deploy until they raise it on their own dated transition. Proved
+with the real lint over the real fixture, in both directions: the same finding, graded
+`error`, is counted; graded `warn`, it is not.
+
+**Compliance landed with the gate, not after it** (`automation-gates.md` §3). The packaged
+template's own documentation tree failed the lint on nine findings — no `docs/README.md`
+and no `docs/80-setup/README.md`, so all three installation documents were orphans (S008,
+L006 ×3), and all three `Owns:` lines claimed the same backticked `__REPO_NAME__` (M002 ×2,
+M004 ×3), which is not the fact any of them owns. Every service `add-service.sh --scaffold`
+had created since would have carried those nine. The template now ships both maps, the
+three `Owns:` lines name what each node actually owns, and the tree measures 0 findings;
+the committed mirror `api/templates/business-service` is regenerated in the same change.
+`docs/README.md` joins the manifest's `own` class — the map of a tree is the service's, and
+what the platform holds the tree to is `D-LINT`, not the template's prose.
+
+Today's run from the api checkout over the eight services: **174 findings → 238**, of which
+59 are `D-LINT` (invoicing 28, pdfgen 6, five services 5 each, property 0). The row is
+therefore red for seven of eight and lands with the 8.0.0 cascade; the code is here now.
+97 suites, 1577 tests green.
+
+### Fixed — `C-SERVICE-DEAD`: `service.url` is dead FROM 8.0.0, and `wrapper.tenantContext` joins the list (d.304)
+
+Two sentences in one row, both measured against the artefact a service is actually pinned
+to rather than against this working tree.
+
+- **`service.url` carries a date now.** The row's `why` said the key had "no reader
+  anywhere in the platform". The guard left the SOURCE in `c7ee2256`, but the PUBLISHED
+  `@onlineapps/service-wrapper@7.0.0` — every live service's pin — still throws
+  `Missing configuration - service.url is required` (measured 2026-09-14 in
+  `api_biz/invoicing/node_modules/@onlineapps/service-wrapper`). A rule telling an author
+  the key has no reader would have sent a service pinned to 7.0.0 into a failed boot
+  (BIZ-invoicing 2026-09-11 point 1). The finding now says it is dead from wrapper 8.0.0
+  and that the key travels WITH the pin — which is what confirmation `biz-service-port-url`
+  001 said all along ("v rámci pin kaskády"). Severity is unchanged: `deploy` names the
+  work the cascade carries and never stops a boot.
+- **`wrapper.tenantContext` is a dead key the row did not know.** It was retired with
+  service shape v1.1 (`docs/biz/RETIRED-VOCABULARY.md`, confirmation
+  `service-shape-v11-retirement` 001) and its runtime defaults went in `b5e36431`;
+  `grep tenantContext api/shared/connector/service-wrapper/src` = 0 across 12 files. The
+  key stayed in five of eight live configs and in the packaged template, so the check
+  claiming "dead keys are refused" claimed more than it did.
+- **The template no longer carries it.** `templates/business-service/config/service/config.json`
+  shipped `tenantContext.enabled` plus `requirePathPrefixes: ["/api/"]` and
+  `excludePathPrefixes: ["/health", "/metrics"]` — HTTP prefixes in a service with no HTTP
+  listener (ADR 0005), copied forward by every `add-service.sh --scaffold`. The block is
+  gone and the committed mirror `api/templates/business-service` is regenerated in the same
+  change (`oa-sync-template template --check` in sync).
+
+The row's `why` and `DEAD_KEYS` are held equal by the test that already guards that pair,
+so the enumeration cannot fall behind the list again. 97 suites, 1567 tests green.
+
+### Added — `assertAllowedTenant()`: the tenant whitelist answers about any id, not only about the env (d.255)
+
+`ALLOWED_TENANT_CLASSES` had exactly one consumer, inside its own file. A caller that
+needed the other half of the same question — "may this script touch tenant X?" — had
+nothing to call, so biz-property kept its own guard: `PLATFORM_LIVE_TENANT_ID`, one
+refused id, every customer tenant from 101 up (101 = Meditest) through it. That is the
+hole the whitelist replaced, surviving beside the whitelist because the whitelist was
+unreachable (`api/shared/TODO.md`, "Od BIZ-PROPERTY (2026-09-11)").
+
+```javascript
+const target = assertAllowedTenant(args.tenant, { purpose: '--to-tenant', setBy: 'on the command line' });
+```
+
+- **Returns the id normalized** to an integer — a number and a string holding one both
+  arrive that way, the rail the env reader already used. Nothing else is coerced: `[99]`
+  stringifies to `"99"` and would have passed a bare `Number(String(x))`, so a type that
+  is neither number nor string is now refused by name.
+- **One refusal, one place.** The sentence naming the allowed classes was written inline
+  in `getTestNamespace()`; it is rendered from one function now and `getTestNamespace()`
+  calls it. Writing it twice is how `97` stayed in the list for months after the
+  allocation retired it.
+- **`purpose` / `setBy` belong to the caller**, because the fix does: an operator who
+  typed `--to-tenant 101` must not be sent to `config/env-active/shared.env`. The env
+  reader keeps its own "missing environment variable" sentence — six suites assert it
+  verbatim — while the empty-value condition, the integer check and the class refusal
+  stay one rail.
+- **The class list is not exported.** A copy of a boundary is a second boundary; the
+  refusal names the classes so a caller never has to.
+
+`getTestNamespace()` and `getForeignTestNamespace()` are unchanged, asserted by the
+existing suite plus control cases in the new one: 97 suites, 1566 tests green.
+
+### Fixed — a test that writes gets a directory of its own, outside the repository (d.233)
+
+Two jest processes over this package shared one tree, so a suite went red without a line
+of it changing. Measured 2026-09-11, before the change: `manifestServiceFiles` built
+`tests/fixtures/manifest/service-workspace/api_biz/tmp-alpha-0` and a `manifestRun` running
+beside it aggregated `F-RUNNER@api_biz/tmp-alpha-0/docker-compose.yml` into the union it
+asserts; a second full run raised `[DeployContract] Service root not found -
+…/api_biz/tmp-prod-onebyte` when one suite's `afterAll` removed what the other was reading;
+`StandardLevels` and the two `serviceStructure*` suites wrote under fixed paths in `/tmp`
+and lost them the same way; and a `.tmp-test-coverage-*` directory left by a killed run
+crashed the jest-haste-map of every later run in the package. Two full runs side by side
+ended 33 and 36 tests red.
+
+- **One place a suite gets a writable directory**: `tests/helpers/tmpWorkspace.js` —
+  `mkdtemp` under `realpath(os.tmpdir())` (the engine compares roots through `realpath`,
+  d.227), a copy of a fixture workspace or of one fixture directory, and removal in
+  `afterAll`, which jest runs whether the cases passed or failed.
+- **A temporary service repository can carry an installed jest**: `makeResolvableRoot`
+  writes `node_modules/jest` whose manifest names this package's real jest binary. The
+  test-coverage gate resolves the SERVICE's own jest from the repository root, and a
+  fixture is never `npm ci`-ed; the two alternatives are measured blind alleys, written out
+  where the function is.
+- **Zero writes under `tests/fixtures/**`, measured** — `find tests/fixtures -newer <marker>`
+  answers nothing after two full runs side by side. The last of them was
+  `oaValidateCli.integration`, whose every root is now a copy that brings its own git
+  checkout: `X-IGNORED` asks git what a clone would receive, and a fixture inside the `api`
+  checkout borrows that answer from the repository it happens to sit in.
+- **The completeness case changed its subject, deliberately.** `complete: true` means every
+  row ran, which needs the SSOTs and the sibling `api/scripts/ci` the documentation rows
+  read — so the case used to run over `tests/fixtures/manifest/conforming` and quietly
+  borrow the real workspace around it, the ambient dependence `automation-gates.md` §1.1
+  forbids, over a directory that is a SIBLING of the fixture workspace rather than a service
+  inside one. It measures `workspace-clean/api_biz/alpha` inside a workspace the suite builds
+  and declares, and the sentence is now true of the right subject.
+
+Two full runs side by side end 97 suites and 1566 tests green on both sides, and
+`find tests/fixtures -name '*tmp*'` answers nothing after them.
+
+### `X-DB-CONFIG` cites the contract node, not the library README (d.254)
+
+BIZ-DOCS wrote the prescriptive sentence into `docs/biz/70-contracts/database-contract.md`
+§10 (`api@0b54101a`, owner decision biz-service-manifest 009), so the row's `doc` now
+points at the concept that carries the rule — `doc-code-binding.md` §1.
+
+
+### Changed — `workflow:` and `verify-installation-contract:` join the `oa-ci v1` block (d.251b)
+
+Left outside the block by d.251 because the template did not carry them, not because anyone
+had decided they were the service's. Measured over the eight repositories on 2026-09-11:
+each of the two is BYTE identical in all eight (one sha apiece), and what they say is the
+platform's — `workflow:` decides which pipelines run at all, and
+`verify-installation-contract:` holds the installation document's SQL to the migrations.
+So both are now written by the block and shipped in the template; no service loses a line,
+because the text the block writes is the text all eight already carry.
+
+`test:` is the only key left outside the markers, and the rule it stands on is sharper for
+it: which database an integration needs, which `ci:gate:*` steps run and which artefact it
+publishes are facts about the service. It was also the only key that actually differed
+across the eight.
+
+Evidence. Simulated on a copy of `api_biz/converter` outside the repository: `workflow:`,
+`verify-installation-contract:` AND `test:` all byte-identical to what they were, nine root
+keys, no duplicate, YAML parses, `test:` outside the block, second run `unchanged`, `G-CI`
+clean. Live over the eight services: **8 of 8**, with the eight-key sentence.
+
+Also in this change: `api/tests/scripts/biz-deploy-uniform-gate.bats` asserted "nothing
+turns the gate off" over `sed -n '/^deploy-production:/,$p'` — a range that reached EOF.
+That was the deploy job alone until the block landed; since d.251 it also covered the end
+marker and this repository's own `test:` job. It now reads from the key to the next line at
+column 0. Falsified both ways: `allow_failure: true` inside `deploy-production` makes the
+case fail, the same line inside `test:` leaves it passing.
+
+### Changed — `G-CI` is a platform BLOCK of `.gitlab-ci.yml`, not the whole file (d.251, finding 20)
+
+The row landed in d.248 as `template-render` over the whole file, and its fix could not be
+run: measured over all eight biz repositories on 2026-09-11, the template is 151 lines and
+7 root keys while the services carry 176 to 198 lines and 9. Every difference is theirs —
+the `test` job that stands up MariaDB, Redis and RabbitMQ as service containers, runs five
+`ci:gate:*` steps and publishes `ci/integration-signal.json`, plus `workflow:` and
+`verify-installation-contract:`. Running the sync would have deleted all of it and left
+eight integration tiers running against no database: a finding a gate reports and nobody
+can carry out (`automation-gates.md` §3, last bullet).
+
+So `.gitlab-ci.yml` is split the way `docker-compose.yml` already is (`oa-test-runner v1`,
+d.215d), one level up — a delimited block of top-level keys rather than one compose service:
+
+- **The block `oa-ci v1`** carries `include:`, `stages:`, `variables:`, `build:`,
+  `secret_detection:` and `deploy-production:` — how a service is built, how its image is
+  identified (`R5`), how the digest reaches the deploy (`R1`, `R2`) and the uniform gate of
+  confirmation 008 before the SSH step. `stages:` declares all four stages, the service's
+  own jobs included; measured 2026-09-11, no biz service declares a fifth.
+- **Outside the markers is the service's**, and the sync never rewrites a line of it: which database
+  and which gates its integration needs is a fact about the service. The block carries no
+  variable of a service either, so the sync cannot put back the `REGISTRY_URL` / `PORT` /
+  `SERVICE_URL` that d.244 removed from the biz side.
+- **New check `delimited-block-render`** (`src/manifest/checks/serviceFiles.js`): the block
+  as the file carries it against the template's block RENDERED for this service — the
+  platform half names the service once, in `GIT_CLONE_PATH`. It is `template-block` plus
+  the render, and `template-render` minus the rest of the file.
+- **The fix is a command again**: `npx oa-sync-template .gitlab-ci.yml --target .`. Three
+  states, and the third is the migration — a file with the block is spliced between its
+  markers; a file carrying the platform's keys UNMARKED (all eight, today) has exactly
+  those keys REPLACED by the block where the first of them stood, so no file ends with two
+  `build:` or two `deploy-production:` keys; an absent file is created whole, which is what
+  `--new` writes. Which keys the block claims is read from the block
+  (`serviceTemplate.js` § `topLevelKeys`), never from a list beside it. The migration moves
+  the service's own keys down past the block when they sat between the platform's — their
+  TEXT is untouched, and a mapping is unordered; a block that stayed in several pieces
+  would not be one region.
+
+Evidence. RED over a copy of `api_biz/converter/.gitlab-ci.yml` normalised to the fixture
+service (`tests/fixtures/ci-legacy/`): `carries no "oa-ci v1" block`. GREEN after the sync,
+with `workflow:`, `test:` and `verify-installation-contract:` byte-identical to what they
+were, nine root keys and no duplicate, and `G-CI` clean on the re-run. Simulated on a copy
+of converter outside the repository: YAML parses, the three service keys unchanged, `build`
+differing only in a comment, `deploy-production` gaining exactly the uniform gate of 008.
+Live over the eight services: `G-CI` **8 of 8**, with the new sentence.
+
+
+### Added — `G-CI`, `X-IGNORED`, and the manifest's completeness check over itself (d.248)
+
+Three findings of the controller (`api/shared/TODO.md` 17, 18, 19) with one cause: nothing
+held the manifest to the template, so the template could carry a file no row named, and a
+service could `.gitignore` a file the uniform requires without a word being said.
+
+- **The self-test (finding 18).** `tests/unit/templateCoverage.test.js` walks
+  `templates/business-service/**` and demands, for every file, either a row naming its path
+  or membership of the new class `files.own`. That list lives **in the manifest**
+  (`files.own.allowed`: `Dockerfile`, `index.js`, `package.json`, `src/`, `tests/`), never in
+  the test — an exemption written in a test is a second owner of the decision, and the next
+  file added would be exempted by editing the test. Adding a file to the template is now a
+  decision about who guards it. `Dockerfile` is the case that shows the class is not a
+  loophole: its one platform fact, the node major, is `R-NODE`'s row.
+- **`G-CI`** (`files.generated`, check `template-render`, severity `deploy`, fix
+  `npx oa-sync-template .gitlab-ci.yml --target .`, doc confirmation
+  `biz-service-manifest` 008). Generated rather than identical because since d.246 the file
+  names the service once, in `GIT_CLONE_PATH`. The pipeline of a biz service is the
+  platform's: it runs the same suite, pins the deploy to the digest CI pushed (`R1`, `R2`,
+  `R5` read this file), and carries the step that measures the uniform before the SSH step —
+  a service that edits any of that edits the gate judging it.
+- **`X-IGNORED`** (`files.tracked`, check `git-tracked`, severity `deploy`). Every file row
+  reads the WORKING TREE; what a clone, a CI checkout and the production image receive is
+  what git TRACKS. Measured 2026-09-10 on a copy of converter: `init.sh` and
+  `jest.config.js` in `.gitignore` and still on disk gave `F-INIT` and `F-JEST` **zero**
+  findings; the same two files deleted — the state a clean clone is in — gave both, NOT
+  DEPLOYABLE. Developer green, CI red. The row reads no list of its own: the paths are the
+  ones `files.identical`, `files.contains` and `files.generated` already name, a directory
+  among them covering its whole tree. Outside a git checkout it is NOT RUN with that reason,
+  never a pass — that is the state of a container and of an exported tarball.
+- **`C-SERVICE-DEAD`** names `wrapper.registry.url` too (it entered `DEAD_KEYS` with d.244
+  and the row still listed four keys), and a test now holds the row's enumeration to the
+  list the code owns (`doc-code-binding.md` §1).
+
+Evidence. Self-test RED on `.gitlab-ci.yml` (`placedBy` = `NOTHING`), GREEN 26/26 once
+`G-CI` landed. `X-IGNORED` over a real git repository — a copy of the `conforming` fixture
+with `init.sh` ignored: without the row `DEPLOYABLE, findings []`; with it
+`NOT DEPLOYABLE, findings ["X-IGNORED@init.sh"]`. Live over the eight services on
+2026-09-11: `G-CI` **8 of 8** (every one of them differs from the template at the same
+place — `workflow:` where the template has `stages:`), `X-IGNORED` **0 of 8**, so that row
+lands with compliance rather than ahead of it (`automation-gates.md` §3).
+
+A trap measured on the way: `fs.existsSync` is the wrong question on a case-insensitive
+filesystem. property carries `docs/80-setup/install.md` while `G-SETUP-INSTALL` names
+`INSTALL.md`; the filesystem said yes, git's index said no, and the row reported two
+untracked files that are tracked — hiding the real defect, which is the name the row does
+not match. Paths are now verified segment by segment through `readdir`: a spelling no row
+matches is ABSENT, and absence is the file row's own finding.
+
+
+### Fixed — `S007` asks for the usage word of the LANGUAGE, not of the directory (d.249)
+
+Reported by BIZ-ingest, 2026-09-11 (`api/shared/TODO.md`). The rule demanded `sourced` of
+every file under `scripts/lib/` and `required` of every file under `scripts/ci/lib/` — the
+tree those two lines were written against, not the tree there is. A Node library under
+`scripts/lib/` could therefore go green only by declaring `sourced` about a file nothing
+sources, which is the weakening `architecture-principles.md` §10 forbids. So the rule
+moved; the files did not.
+
+- The directory decides ONE thing: whether the question is asked at all. `scripts/lib/**`
+  and `scripts/ci/lib/**` hold libraries rather than entry points, so their `Usage:` line
+  carries a word instead of a command line. Which word is the extension's answer — `.sh`
+  is `sourced`, a Node module is `required`.
+- The test is written as "shell, or else Node" rather than as a second list of Node
+  extensions beside `SCRIPT_EXTENSIONS`; a copy of that list here would drift
+  (`change-discipline.md` § One rail per concern). A `.cjs` is outside the scan today and
+  needs no edit here the day it enters.
+- The message says what the file IS rather than where it lies: `A Node library declares
+  Usage: required, found "sourced"`. The id, the line and the `(SCRIPTS-STANDARD §2)`
+  citation are unchanged.
+
+Measured 2026-09-11, the same trees before and after the change:
+
+| tree | before | after |
+|---|---|---|
+| `api_biz/ingest` | 1 finding, `S007` | **0 findings** across 5 files |
+| `api_biz/meta` | 7 findings, `S007` | **0 findings** across 12 files |
+| `api_biz/converter` | 0 | 0 across 23 files |
+| `api_biz/property` | 38 findings, none `S007` | 38, none `S007` — its scripts carry no header at all, so `S001` speaks first |
+| `api/scripts` (`npm run scripts:lint`) | 0 across 105 files | 0 across 105 files |
+| `templates/business-service` | 0 across 1 file | 0 across 1 file |
+
+`api/tests/scripts/scripts-lint.bats` passes 18/18, exit 0 — including case 1, the
+no-grandfathering gate over the real tree.
+
+The row `S-SCRIPTS` of the biz uniform runs these rules, so ingest and meta stop being red
+on it through no fault of their own. The standard's own §Scope rows still describe the old
+split; the text for them went to INFRA-DOCS, who own `docs/standards/SCRIPTS-STANDARD.md`.
+
+### Changed — `registry` odchází ze šablony služby, `wrapper.registry.url` je mrtvý klíč (d.244)
+
+Konfirmace `biz-discovery-redis` 002. `templates/business-service/config/service/config.json`
+už blok `registry` nenese: `@onlineapps/service-wrapper` adresu nevyžaduje ani
+nepředává a `@onlineapps/conn-orch-registry` parametr `registryUrl` nemá.
+
+`C-SERVICE-DEAD` (`config-dead-keys`) proto nově hlásí i `wrapper.registry.url`:
+„nothing reads it; registration travels over MQ to registry.register and discovery
+reads the Redis projection". Živě to je **8 nálezů z 8 služeb** — všech osm ten klíč
+dnes v `config/service/config.json` deklaruje (změřeno 2026-09-11); zmizí s jejich
+kaskádou 8.0.0, kde blok vypustí spolu s pinem wrapperu.
+
+### Changed — `shared.env` šablony a fixtur přegenerován z `api/config/shared-env.json` (d.244)
+
+Balíčková kopie i 13 fixtur pod `tests/fixtures/**` běhy `oa-sync-template shared-env`
+(mechanismem, ne rukou). Zachycuje dvě změny manifestu: heslo v `REDIS_URL`
+(INFRA `8d79478a`) a nové `why` u `REGISTRY_URL`. Fixtura
+`service-workspace/api_biz/beta` **záměrně vynechána** — je to ručně rozjetá kopie,
+na které `G-SHARED-ENV` dokazuje, že rozdíl umí najít.
+
+### Added — the deploy-production job of a biz repository measures the complete uniform before its SSH step (d.246)
+
+Confirmation `biz-service-manifest` 006 point 3, placed by 008: a biz service is deployed
+only by its own repository's CI (`server-topology` 004), so the last place that can refuse
+an unfit deploy is that repository's own `deploy-production` job — not
+`api/scripts/deploy-production.sh`, which is not the biz deploy path at all.
+
+- **`templates/business-service/scripts/verify-deploy-uniform.sh`** is the step, as a FILE
+  rather than a heredoc in the YAML. A heredoc can only ever be run by GitLab, so the one
+  place the gate would be proven is production; this file is called by the job with three
+  arguments and by `api/tests/scripts/biz-deploy-uniform-gate.bats` with three others, and
+  both run the same bytes. It reads nothing from the environment
+  (`architecture-principles.md` §1): the checkout, the api repository URL carrying the job
+  token, and the api ref production follows all arrive as arguments.
+- It refuses on the engine's own non-zero exit **and** on `complete: false` — `deployable`
+  says nothing blocked among the rows that RAN, `complete` says no blocking row was
+  skipped, and reading only the first honours a skip nobody flagged
+  (`automation-gates.md` §1.5). No flag, variable or branch turns it off (§1 requirement
+  5), and messages print the clone URL with its userinfo cut out, so the job token never
+  reaches the log.
+- **The layout is what makes the run complete, and the job asks GitLab for it.** Measured
+  2026-09-11 over a converter export against a shallow `api` clone: with the service at
+  `<root>/api_biz/<service>` beside `<root>/api` the run is `complete: true` in 1.1 s;
+  with the same two directories as unrelated siblings, seven blocking rows come back NOT
+  RUN — `U-ORPHAN`, `U-IDENTITY`, `D-PORT`, `D-NPM`, `D-SCRIPT`, `D-RETIRED`, `D-HEADER` —
+  and the signal reads `complete: false`. That is the same seven the container simulation
+  of 006 measured. A symlink is forbidden (api rule: No Symlinks) and a second copy of the
+  repository would leave two trees with no way to say which one the verdict was about, so
+  the job sets `GIT_CLONE_PATH: $CI_BUILDS_DIR/oa-uniform/api_biz/__SERVICE_NAME__` and the
+  script verifies it got what it asked for.
+- The job runs on `node:24-alpine` (the major `R3` compares against `engines.node` and the
+  Dockerfile), adds `git`, and runs `npm ci` — the engine is the one this repository's pin
+  installed, never a floating `npx`.
+- `EXECUTABLE_FILES` in `src/sync/serviceTemplate.js` gains the script: a rendered copy
+  without the bit fails the job with "permission denied" instead of measuring anything,
+  which is the false guarantee `automation-gates.md` §5 names. The packaged template is
+  now **23** files, and `tests/unit/serviceTemplate.test.js` names the 23rd rather than
+  only counting it.
+
+`api/tests/scripts/biz-deploy-uniform-gate.bats` — 9 cases, RED 8/9 against the tree
+before this change (the ninth is skipped in an api-only checkout), GREEN 9/9 after: the
+step stands before the ssh line; the job asks for the layout and the committed mirror
+carries the same bytes; nothing turns the gate off; each precondition refuses with its fix
+and without the token; THE REAL RUN over a converter export comes back `complete: true`
+with `notRun` empty and its 33 findings refuse the deploy; an incomplete run is refused
+even when nothing blocked; and the CONTROL case — only a signal that is `deployable` AND
+`complete` passes.
+
+**UNCERTAIN, and it cannot be measured from here:** whether a real GitLab pipeline reaches
+`complete: true`. Two things this simulation cannot answer — whether the runner allows a
+custom build directory (`[runners.custom_build_dir] enabled`), and whether the api
+project's CI job-token allowlist admits the biz project (the owner's step, 008 point 2).
+The clone step's own message names the second one when it fails.
+
+**What this change does NOT carry:** no manifest row covers `.gitlab-ci.yml` — measured
+over the manifest, zero rows name it — so the step reaches none of the eight services by
+`oa-sync-template`, and none of them is reported as drifting from it. A new service
+created by `oa-sync-template --new` gets it; an existing one does not.
+
+### Changed — the biz box's `shared.env` is rendered on the infra box, not written by role-biz (d.247)
+
+Two sentences of the template — the host-contract comment in
+`docker-compose.production.yml` and the production paragraph of `README.md` — said the one
+host-level `/var/www/html/oadrive/api_biz/shared.env` is written by `role-biz`. Since
+`843b0ba9` it is rendered on the INFRA box by
+`api/scripts/provision/render-biz-shared-env.sh` from that box's own `env-active` and
+carried over by the operator (`server-topology` 004, 005); `role-biz.sh` mentions
+`shared.env` nowhere (0 occurrences) and creates only the `biz_network`, which those texts
+still say and which is still true. The sentence was cascaded by the generator into the
+eight fixtures that are conforming copies of the template; the four deliberately drifted
+ones and `beta` were left as they are, because the sync would erase the defect they exist
+to demonstrate.
+
+
+### Added — `X-DB-CONFIG`: the private connection factory is a forbidden file (d.242)
+
+Confirmation `biz-service-manifest` 009: `@onlineapps/conn-base-db` is kept and its
+cascade finished. Seven of the eight services carried their own
+`src/config/database.js` — a module singleton building its own Sequelize — beside the
+library whose `createSequelize` exists to be the one connection factory
+(`change-discipline.md` § One rail per concern). The 8.0.0 cascade commit of each service
+switches its importers and deletes the file; this row is what keeps it deleted, and it
+ships in the release that does the switching, never ahead of it (`automation-gates.md`
+§3).
+
+- **`X-DB-CONFIG`** (`files.forbidden`, check `file-absent`, severity `deploy`,
+  `scope: service`) — path `src/config/database.js`, `doc`
+  `api/shared/connector/conn-base-db/README.md`. No new check and no new class: the
+  "this file must not exist" class is `files.forbidden`, which `X-HOOKS` and `X-PREVAL`
+  already wear, and `file-absent` reads nothing but the path. Like them it answers inside
+  a service container, with no workspace and no `api/` checkout.
+- The row does **not** ask `requiredConnectors.db` first. 009 names the path with no
+  condition on it, and a service that declared no database has even less business carrying
+  a connection factory. The three `D-DB-*` rows that DO ask the declaration are a different
+  concern and are unchanged.
+
+Live, 2026-09-11, `runManifest` per service against the workspace — 8 services, **7
+findings**, `pdfgen` silent:
+
+| service | `requiredConnectors.db` | `src/config/database.js` | `X-DB-CONFIG` |
+|---|---|---|---|
+| converter | true | present | 1 |
+| emailer | true | present | 1 |
+| hello-service | true | present | 1 |
+| ingest | true | present | 1 |
+| invoicing | true | present | 1 |
+| meta | true | present | 1 |
+| pdfgen | false | absent | 0 |
+| property | true | present | 1 |
+
+`pdfgen` is the control case in both halves: it declares no database AND carries no file,
+and the row stays silent without reading the declaration at all. The mirror
+`api/templates/business-service` carries no `src/config/database.js` either, so the row
+raises nothing over it.
+
+The workspace run (`oa-validate --workspace <root>`, no service root) reports the row
+`NOT RUN`, beside `X-HOOKS` and `X-PREVAL` — a service-scoped row has no service to read
+there, and NOT RUN is printed rather than counted as a pass.
+
+### Added — `S-SCRIPTS`, and the script-header rules move into this package (d.218)
+
+Confirmation `biz-service-manifest` 003 §19: "`scripts/**` of every bearer passes
+`lint-scripts.mjs`, **shipped in the validator package**". The second half was the whole
+requirement. The rules lived in `api/scripts/ci/lint-scripts.mjs`, a file of ONE checkout —
+and a service has no `api/` directory in its own CI and none at all inside its image, so
+the row could only ever have been NOT RUN exactly where it has to answer
+(`automation-gates.md` §5).
+
+- **`src/lint/scripts/lintScripts.js`** carries the rules. Every id, message and closed
+  vocabulary is unchanged: `api/tests/scripts/scripts-lint.bats` passes 18/18, and over the
+  api tree the two runs print the same line (0 findings across 104 files in scope, 97 in
+  the citation scope).
+- **`oa-lint-scripts`** is the command; it owns argument parsing, the report and the exit
+  code, nothing else.
+- **`api/scripts/ci/lint-scripts.mjs` is a thin caller** of the same module — the shape
+  `api/scripts/ci/verify-lib-compat.mjs` already keeps. `npm run scripts:lint` and the CI
+  job `validate-scripts` are unchanged.
+- **`S-SCRIPTS`** (new section `tooling`, severity `deploy`, `scope: service`) is the row;
+  `src/manifest/checks/scriptHeaders.js` is the bridge to the module and decides nothing.
+
+One rule changed behaviour, and it had to. `S006` checks that an `@see` target exists, and
+an `api/…` target used to be resolved by stripping the prefix and looking under the run's
+own root — correct exactly once, when the run IS the api checkout. In a service repository
+that would have measured `api/docs/standards/…` against `<service>/docs/standards/…` and
+reported a dead pointer that is not dead. The api checkout is now a PARAMETER: given, the
+target is resolved against it; absent, the lint returns it as UNRESOLVED and the row is
+NOT RUN with the targets named, never a silent pass. Measured 2026-09-10 over the eight
+services: 47 `@see` lines under their scripts directories, 4 with that prefix.
+
+Live, 2026-09-10: **86 scripts, 86 findings** — not one carries a header (converter 23,
+property 38, meta 13, ingest 6, hello-service 2, invoicing 2, emailer 1, pdfgen 1). The
+mirror `api/templates/business-service` stays DEPLOYABLE with 0.
+
+### Added — the `db` section says what the SQL package is called and who reaches it (d.218)
+
+§19 names three duties beside "is there a database" and leaves the naming convention to be
+chosen. All three ask their question only of a repository that DECLARES a database; a
+stateless service is silent, and `pdfgen` is the measured case.
+
+- **`D-DB-NAMING`** — `migrations/*.sql` reads `NNN_<subject>.sql`: three digits, then at
+  least two snake_case words (chosen by BIZ-general, d.218). No leading verb is demanded,
+  because the measured counter-example is right —
+  `converter/migrations/009_cnv_batch_drop_pending_status.sql` opens with a table prefix;
+  and the three digits are not decoration — `999a_` sorts after `999_` only by accident of
+  the byte after the digits. The convention reaches ONE level: what `BASELINE/` and
+  `SEED/**` must carry is the installation contract's §4, which `D-DB-HEADERS` already
+  checks, and that contract names no shape for their file names at all — measured, not
+  assumed, so no regex is invented where nothing owns one.
+- **`D-DB-README`** — the installation contract §3 asks for four things and
+  `SQL_PACKAGE` (`D-DB-PACKAGE`) checks three directories. The fourth is
+  `migrations/README.md`, the documented execution order of §5 point 4, and nothing was
+  looking for it.
+- **`D-DB-ACCOUNT`** — `DB_USER` in this service's env template reads `oagen_<shortname>`,
+  from the SAME derivation `C-IDENTITY` holds `database.schema` to, so the account and the
+  schema cannot drift into two spellings (confirmation `db-accounts-per-service` 001: root
+  stops being an operational identity — it was the identity of nine containers across eight
+  repositories, which made rotating it a cross-repo batch nobody could run). A repository
+  that declares a database and no `DB_USER` is a finding, not a silence.
+
+Live, 2026-09-10: `D-DB-NAMING` 12 (emailer, invoicing, meta one each — `000_baseline.sql`;
+property nine, eight of them the `999a`–`999h` ordinals plus a single-word `050_views.sql`),
+`D-DB-README` 0, `D-DB-ACCOUNT` 4 (ingest, invoicing, property still `DB_USER=root`; meta
+`oagen_meta_app`). The mirror stays DEPLOYABLE with 0.
+
+### Added — `F-GITIGNORE` and the `contains` file class (d.218, finding of d.240)
+
+`ci/deployability.json` is written by `oa-validate` and by the pre-push hook of
+confirmation 006. Four of the eight services (converter, invoicing, meta, property) do not
+ignore `ci/`, so every run leaves an untracked file behind; the template has carried the
+line since d.212.
+
+The class is `contains`, and the choice was measured rather than preferred. `identical` is
+impossible — a repository ignores its own scratch directories, and the eight services carry
+nine different files (d.220). A delimited `# --- oa-ignore v1` block was refused for the
+opposite reason: not one of the eight files carries a marker today and no generator ever
+wrote one, so a block row would report eight services for a defect four of them do not
+have, and would impose an ordering on lines that are legitimately theirs. What has to be
+true here is a SET of paths — every path this platform WRITES into a repository is a path
+git must not see — and a set is what the row compares: the template's entries against the
+repository's, in any order, every other line untouched.
+
+A narrower pattern does not satisfy the entry it narrows, and that is not pedantry:
+property's `config/env-active/*.env` leaves every non-`.env` file in a directory of live
+secrets committable.
+
+The generator still writes the labelled block — that is how a reader tells the platform's
+lines from the repository's own — but the block is the FIX's shape, never the check's. The
+renderer removes an existing block before computing what is missing, so it is idempotent:
+a second run adds nothing, and an entry the repository has since written by hand drops out
+of the block instead of standing beside it twice. `SYNCABLE_CLASSES` gains `contains`.
+
+Live, 2026-09-10: 4 services, 5 findings. The mirror stays DEPLOYABLE with 0.
+
+### Changed — `C-IDENTITY` holds the sixth spelling: `serviceName` (d.218)
+
+`config/service/integration-contract.json` opens with `serviceName`, and it is the first
+file every platform gate reads. The row held five spellings after d.236 and not this one.
+It is compared against what `config/service/config.json` DECLARES, character for
+character — the same reading the npm name gets, and for the same reason: whether
+`service.name` itself must read `biz-<shortname>` is a question no row owns, and this is
+not the place a rule appears as a side effect (`truth-over-agreement.md` §6). A contract
+declaring no `serviceName` is `C-CONTRACT`'s finding, which calls the validator owning
+every rule of that file.
+
+Live, 2026-09-10: all eight services already agree, so no finding moved — the gate lands
+with compliance (`automation-gates.md` §3). What the row DID find is that the template
+carried two placeholders for one name: `__REGISTRY_NAME__` in `config/service/config.json`
+and `__REPO_NAME__` in the contract. Both render to `biz-<name>` for any real service, so
+nothing changes downstream, but the one bearer that is the shape of all the others wore two
+spellings; `serviceName` is the platform identity, so the contract now writes
+`__REGISTRY_NAME__`. The same correction landed in the conformant fixture, whose contract
+said `biz-v3-cookbook-service` while its `package.json`, its `config.json` and every
+cookbook step said `v3-cookbook-service`.
+
+### Fixed — a suite copying the fixture workspace no longer races the suites writing into it (d.218)
+
+`manifestServiceFiles` and `manifestProductionCompose` create and delete temporary
+services under `api_biz/tmp-*` INSIDE the shared fixture workspace, and jest runs suites in
+parallel — so the three suites that copy that workspace whole walked a directory which can
+vanish between the readdir and the copy. Measured 2026-09-10: `ENOENT …
+api_biz/tmp-prod-onebyte`, in a suite that had been green twice before it appeared. The
+copy now filters those names out, and `cpSync` applies `filter` BEFORE it stats the entry
+(measured), so the window is closed rather than narrowed.
+
+### Added — one service, one name: `C-IDENTITY` and `U-IDENTITY` (d.236)
+
+`api/docs/biz/60-templates/naming.md` is normative and derives every spelling of a biz
+service from one short name. It is not a matter of tidiness: the gateway compares
+`service_code` from the entitlement data against the service name in a cookbook step
+CHARACTER BY CHARACTER, so a second spelling of one service is a request that gets
+refused. Measured 2026-09-10 over the eight live services: seven wear one name each, and
+`hello-service` wore four — directory `hello-service`, repository `biz-hello-service`, env
+template `hello-service.env`, everything else `hello`. No row said a word, and the
+standard's own § Current State had recorded the divergence as a fact rather than a defect.
+
+**`C-IDENTITY`** (section `config`, severity `deploy`, `scope: bearer`, no workspace
+needed) holds the spellings INSIDE the repository to the short name
+`config/service/config.json` declares: the npm `name`, `container_name` in both compose
+files, `config/env-templates/<shortname>.env` together with the `env_file` entries loading
+it, and `database.schema` = `oagen_<shortname>` where the repository declares a database.
+It reads nothing outside the repository, so it answers in a container and in the service's
+own CI too.
+
+**`U-IDENTITY`** (beside `U-ORPHAN`, `scope: bearer`) holds `directory`, `repo` and
+`container` in `api/config/services.json` to the same short name; those three are facts of
+the workspace, so without one the row is NOT RUN.
+
+Four decisions the row makes and states:
+
+- the npm `name` is compared against the DECLARED `service.name`, not against a derived
+  `biz-<shortname>` — `naming.md` gives both the same spelling, and comparing against the
+  derivation would smuggle in a rule about `service.name` itself that no row owns
+  (`serviceIdentity.js` § `REGISTERED_NAME`);
+- only the LAST segment of `repo` is this row's business; the organisation prefix is
+  `naming.md`'s, and a repository moved between groups is not a second name;
+- the database name is read where the repository declares it —
+  `config/service/integration-contract.json` → `database.schema` (7 of 8 services;
+  `pdfgen` is a stateless renderer and declares none, so the row stays silent);
+- a bearer the SSOT knows under neither a name nor a directory is `U-ORPHAN`'s finding and
+  `U-IDENTITY` says nothing — one defect, one owner.
+
+The template is a bearer of every file row and of neither SSOT row: it declares its
+identity as the placeholder, and `api/config/services.json` lists services, of which the
+template is not one. It is held to `C-IDENTITY` and passes — which took fixing the
+template itself (d.220 decision 4): its compose files loaded
+`env-active/__SERVICE_NAME__.env` while the file was called
+`config/env-templates/service.env`, so the one bearer that is the shape of all the others
+wore two names. The source is now `__SERVICE_NAME__.env`; the `--new` rename is unchanged.
+
+### Fixed — `template --check` reads the template's own `.gitignore` (d.237)
+
+`oa-validate` records its verdict in the tree it measured (d.232), so a run over the
+mirror `api/templates/business-service` leaves `ci/deployability.json` behind. The
+template gitignores `ci/`, so git does not see it — but `oa-sync-template template
+--check` did, and reported the mirror stale over the artefact of a legitimate run.
+
+One rule, read from one place: what the template's `.gitignore` ignores, the comparison
+ignores too, on both sides. `compileGitignore()` reads git's own semantics in the part
+these files use — a trailing `/` covers directories only, a pattern carrying a `/` is
+anchored at the root and one without matches a name at any depth, a matched directory
+carries everything under it, and the LAST matching rule decides, which is what makes a `!`
+exception work. `listOutputFiles()` is that filter over `listTemplateFiles()`, and the
+mirror suite reads it too — it carried the same defect in its "carries exactly the files
+the packaged template renders" assertion. A file the `.gitignore` does not cover is still
+reported stale, and an ignored path never hides a real drift in a tracked file.
+
+### Changed — `R-NODE` reads the platform major from the package's own `engines` (d.238)
+
+The row referenced `api/.nvmrc`, a file that exists only in a workspace, so in a service
+container and in the service's own CI — the two places a service is actually built — the
+one row that catches a service quietly living on an older major reported NOT RUN. (`R3`
+of the deploy contract compares CI, Dockerfile and `engines.node` only against each other,
+so a service consistently on Node 22 is green there.)
+
+The reference is now `{ "package": "package.json", "text": true }` — the fourth reference
+shape of d.229 — and the check reads `engines.node` from it. It is not a second copy of
+the number: the library uniform's `L-ENGINES` fails any package whose `engines.node`
+disagrees with `api/.nvmrc`, so this is a checked projection of the SSOT one hop further
+along, and it travels with the pin. `api/.nvmrc` stays the owner and `L-ENGINES` still
+reads it. Owner decision: `api/docs/governance/confirmations/biz-service-manifest.md`
+§ Confirmation 20260910-biz-service-manifest-006, point 2.
+
+Measured over a service copy outside any checkout, with the package installed from a
+`npm pack` tarball: NOT RUN shrank to `U-ORPHAN` and the five `D-*` rows, and `R-NODE`
+reported both places the service states its major.
+
+### Fixed — `L-CONNECTOR-ENV` asks its question of code, not of prose (d.239)
+
+The check matched `process.env` in the raw file text, so a module that DOCUMENTS the duty
+it obeys — "this module reads no `process.env`" — was reported for the sentence in its own
+header. Measured: `api/shared/connector/conn-base-db/src/createSequelize.js`.
+
+The file is now read as source: `codeOnly()` blanks comments, the text of string and
+template literals, and regular-expression literals before the search, keeping length and
+line breaks. What a template literal interpolates is code again, because
+`${process.env.X}` really does read the environment. The tokenizer is written by hand
+rather than pulled from `acorn`: that package is not a declared dependency, and adding a
+runtime dependency for one line-level question would change what every biz service
+installs (§ Shared Packages, "a package sees only what it declares", gate rule G6).
+
+
+### Changed — the production compose of a biz service is a generated file, not a shape (d.234)
+
+`G-PROD` was a bridge to requirement **R1** of the deploy contract: it asked one question
+about `docker-compose.production.yml` — is the image pinned by digest — and said nothing
+about the file the rest of the platform depends on. That left the topology of the
+production compose maintained by hand in eight repositories at once, which is how seven of
+them came to name `api_network` and `gendb-network`: networks the biz box does not have.
+
+The row is now a `generated` whole-file row (`check: template-render`), rendering
+`templates/business-service/docker-compose.production.yml` with the one parameter a service
+has, its DECLARED name (`config/service/config.json` → `service.name`, through
+`deriveParams`). The measurement the owner decided on is what makes that possible: on
+2026-09-10 the seven old-shape files were byte-identical once the service name was
+normalised, apart from `memory: 384M` in ingest and property — so what looked like seven
+per-service files was one file copied seven times, and adding or removing a service is a
+scaffold plus an SSOT entry rather than a hand-written file. Severity is `deploy` from the
+start; a `warn` phase would be a gate that does not gate (`automation-gates.md` §5).
+
+The R1 bridge stays, under the id **`G-PROD-IMAGE`** — a requirement about a file is not
+the file, and it keeps answering on a repository whose compose the generator has not yet
+written. `G-PROD` is the id the owner decision names for the file itself, so it is the id
+the file row wears.
+
+`npx oa-sync-template docker-compose.production.yml --target .` writes it. Unlike an
+installation document, the file is REWRITTEN rather than spliced or blocked: the whole file
+is the template's, so there is no prose of the service's own to preserve. A repository that
+has not declared who it is gets the `[ServiceIdentity] … Fix: …` fail-fast instead of a
+guessed name, and the check stays silent about it — that defect is `C-SERVICE`'s.
+
+Owner decision: `api/docs/governance/confirmations/server-topology.md`
+§ Confirmation 20260910-server-topology-005.
+
+### Fixed — `oa-validate` records its verdict, so a deploy gate can ever see a complete one (d.232)
+
+`ci/deployability.json` had exactly one writer: step **7/7** of the boot validation, which
+runs inside the service container, where the workspace SSOTs are not present. Every signal
+that could exist therefore carried `complete: false` — and the gate INFRA was handed in
+d.230 ("accept the signal only when `deployable && complete`") could never be satisfied,
+because the run that IS complete, `npx oa-validate --workspace <root> <service root>` from
+the api checkout, wrote no file at all. Measured before the fix: a copy of `api_biz/converter`
+validated by the packaged CLI printed `NOT DEPLOYABLE` and left no `ci/deployability.json`
+behind.
+
+A service run now writes the file into the service root it measured, through the same
+`buildDeployabilitySignal` / `writeDeployabilitySignal` step 7 uses — one file shape with
+two producers, asserted by a control case comparing the CLI's file against what the shared
+builder produces from the same run. The report is printed BEFORE the write, as in step 7,
+so an unwritable service root still leaves the human-readable verdict; the write itself has
+no switch (`automation-gates.md` §1 requirement 5), and a root that cannot take it ends the
+run with the writer's `[DeployabilitySignal] … Fix: …` and exit `2`.
+
+The workspace mode (`--workspace` with no service root) and `--library` write nothing. The
+signal is a verdict about ONE service tree: the workspace run has no service root and
+reports every per-service row `NOT RUN` by construction, and a library has no deploy of its
+own (002 §10), so a file from either would be a partial verdict standing where a complete
+one belongs.
+
+This package's own version is now read lazily, at the moment the signal is built, with
+`[oa-validate] This copy of the engine carries no package.json - … Fix: …` where the file
+is missing — a planted copy of the engine used to be a `MODULE_NOT_FOUND` stack trace
+before a single row ran.
+
+### Fixed — a repository is who it DECLARES it is, not what its directory is called (d.229)
+
+`F-RUNNER` and the three `G-SETUP-*` skeleton rows derived this repository's parameters
+from `path.basename(serviceRoot)`. Since d.229 those rows finally answer inside the image
+the service is built into — and that image has `WORKDIR /app`, so every service on the
+platform is called "app" there. Measured over the conforming fixture copied into a
+directory of that name: `F-RUNNER` reported a conformant compose file as drifted, quoting
+a line the substitution had mangled (`It __SERVICE_NAME__lies in dev and CI only`, because
+"app" is a substring of "applies"), and the production stage then fails the build of every
+conformant service. A directory called `My Service` did worse: the derivation threw, and
+`oa-validate` exited 2 with no table at all.
+
+The identity is read from `config/service/config.json` → `service.name`, the key row
+`C-SERVICE` owns (`src/manifest/serviceIdentity.js`). Reading it back is the exact inverse
+of what `deriveParams` writes, which only ever ADDS the platform prefix — so no new rule
+about how a service must be named appears here as a side effect. A file that is absent,
+unreadable or declares no name is `C-SERVICE`'s finding and the rendered rows repeat
+nothing; a name no parameters can be derived from is reported by the row that needed it,
+because nothing else would say a word about it. The generator fails fast with
+`[ServiceIdentity] … Fix: …`.
+
+### Fixed — the uniform sync needs a workspace only where a ROW needs one (d.229)
+
+`oa-sync-template [path…] --target` demanded a workspace root before it planned anything,
+so the `fix` command of `F-INIT`, `F-JEST` and `F-RUNNER` could not be typed in the one
+place their finding is now raised: inside a service container. It asks the same predicate
+the manifest run asks (`rowNeedsWorkspace`, moved to `manifestShape.js` so both read one
+definition), and a row that does need the workspace is printed `NOT RUN` by name.
+`shared-env` still refuses without one — its owner is a platform file.
+
+### Changed — `F-RUNNER`'s fix is a command: the sync writes the block (d.215d)
+
+Confirmation 001 §3.2 asks that every finding's `fix` be a COMMAND. Seven of the eight biz
+repositories carry no `oa-test-runner v1` block at all, so the row's fix read "paste it in
+by hand once", which is advice. `npx oa-sync-template docker-compose.yml --target .` now
+writes it, in three states: a file carrying the markers is rewritten between them; a file
+carrying a runner but no markers has that runner's declaration REPLACED where it stands;
+a file carrying neither gets the block inserted as the first entry under `services:`.
+
+The middle state is the one that matters and the one a first cut got wrong: measured
+2026-09-10 over a copy of `api_biz/converter`, inserting gave the file a SECOND
+`api_service_converter_tests:` key — a duplicate mapping key, which compose either refuses
+or resolves by taking the last one. The replacement spans the key to the next key at the
+same level, so a comment above it (in converter, the memory measurement taken inside that
+container) survives. Where the block goes is not a guess in a compose file — a mapping has
+one place its entries can start — which is why `init.sh` stays `BLOCKED`: there the
+position IS a decision about that service's own install steps.
+
+The `wrote` / `would change` line names both sides of the first difference now. Naming only
+what the file already said reported `line 2: "api_service_converter:"` for an insertion —
+the line the block was pushed past, rather than the block.
+
+### Added — the `Uniform:` region of a README has a gate, not only a generator (d.215e)
+
+Owner decision 2026-09-09: that region is of the class `generated`, and 001 §2 makes such a
+class a generator PLUS a row carrying its `--check` (the precedent is `G-SHARED-ENV`).
+Until now the generator existed alone, so a README whose pointer had gone stale was reported
+by nothing anybody runs on a repository — the false guarantee of `automation-gates.md` §5.
+
+* **`G-README`** (biz-service, severity `deploy`, scope `service`, `fix: npx
+  oa-sync-template readme-uniform --target .`) — reads only the packaged manifest, so it
+  answers in a container.
+* **`L-README-REGION`** (library, severity `publish`, scope `bearer`, `fix: npx
+  oa-sync-template readme-uniform --all`) — a row of its own beside `L-README` rather than
+  an extension of it, because the two halves of that file have different writers: the node
+  header is written by a human, the region by a command. A checkout carrying no copy of
+  this package reports it `NOT RUN` with that reason; a package declaring no category
+  raises nothing, because `U-MISMATCH` already blocks it with its own fix.
+
+Both render through `readmePointer.js` and compare through the same `checkUniformRegion`
+the `--check` run calls, and where each kind's region points is one module
+(`src/sync/readmeLocation.js`), read by the rows and by the CLI.
+
+A forbidden row (`X-HOOKS`, `X-PREVAL`) now renders its path in the region like every other
+row. It did not, and the reason was a test rather than a reader:
+`api/tests/scripts/add-service.bats` grepped the WHOLE template for `hooks/pre-commit`, so
+a region correctly naming a banned path failed a case whose subject is whether `init.sh`
+still INSTALLS the hook. That case now asks it of the files that could.
+
+### Changed — `C-LINT` moved into the `docs` block, whose budget it declares (d.210b)
+
+The literal `config/biz-docs-lint.tree.json` stood in the manifest twice: on the row and
+again as the block's `tree_config`. The block names the ROW now (`tree_config_row`) and the
+row names the path, so a rename has one place to happen. The row id is unchanged, and so is
+every verdict: the block gained `applies_to: "*"`, without which `file-present` would have
+skipped the row in silence.
+
+### Added — `D-NPM`, now that the rule it cites exists (L016)
+
+Guidance until 2026-09-10, and true while it stood: 001 §2 asks that an npm script a live
+document cites still exist, and no rule of `lint-biz-docs.mjs` raised it, so a row would
+have reported nothing and read as a clean tree (001 §6). BIZ-DOCS wrote `L016`, which
+resolves a cited `npm run <name>` against the `package.json` above the tree — exactly one
+file for a service repository. Measured over the eight service trees: evaluated on seven of
+them with no finding, undecided on the eighth, which declares no tree config.
+
+### Fixed — a rule the lint could not EVALUATE is NOT RUN, not a finding
+
+An evidence probe reading `api_biz/*` cannot be evaluated in a checkout that has no
+siblings — the shape of the CI job. Measured 2026-09-10 over `git archive HEAD` into such a
+directory: the template mirror came back `NOT DEPLOYABLE` on `D-PORT` and `D-RETIRED`,
+whose bans nobody had violated, while `U-ORPHAN` in the same run said the honest thing. The
+linter's two channels map onto this uniform's two now: its `findings` are findings, its
+`skipped` list is `NOT RUN`. A tree the lint REFUSES outright — no tree config, a broken
+configuration — stays a finding, because that one has a fix somebody can carry out. A check
+may therefore return `{ findings, notRun }`; until now it could only return an array, so
+"I could not decide this" had to be dressed as a finding.
+
+### Changed — `L-NO-FILE-RANGE` reads `file:` for every package, in every section (d.224d)
+
+The row read `@onlineapps/*` only, so `lodash = file:../lodash` in `devDependencies` passed
+the uniform and the F10 publish gate had to keep rule **G2** of its own for exactly that
+case — one concern on two rails. A `file:` resolves to a path on the machine that wrote it
+and never reaches a published tarball, whoever owns the package, so the row now reads all
+four dependency sections for every name. RANGES (`^`, `~`, `latest`, `*`) stay scoped to
+what the SSOT owns: a caret on a third-party dependency is a judgement nothing here can
+make. G2 is deleted; the gate's rules are G4, G6 and G7.
+
+### Fixed — Step 7 reads the reasons a service is undeployable from the whole manifest run
+
+A `CONFIG_STEP_ROWS` row carrying `deploy` was filtered out of `deployFindings` together
+with its report (`4dcd61a2`).
+
+
+### Changed — the deploy signal says whether the run reached every blocking row (d.230)
+
+`ci/deployability.json` carried one claim: `deployable`, meaning nothing blocked among the
+rows that RAN. Inside a service container the rows reading the workspace cannot run at all,
+so the file routinely said `deployable: true` about a tree whose other half nobody had
+opened — and a deploy gate reading only that key was honouring a `--skip` nobody had
+flagged (`automation-gates.md` §1.5). Confirmation 001 §4 knows one outcome, a finding
+refusing the deploy, and says nothing about NOT RUN.
+
+The second half is **`complete`**: no row whose severity blocks this uniform was NOT RUN.
+It is derived in one place (`runManifest.js` § `incompleteRows`), so the verdict and the
+sentence a human reads name the same rows, and every `notRun` entry now carries the
+`severity` of the row that did not run — without it nothing can say whether a skipped row
+could have stopped anything (a `warn` row could not).
+
+`deployable` is unchanged, and so is the registration contract of d.221. **No exit code
+changes**: an incomplete run must not stop a build image or a boot, because the partial run
+in the container is the intent (001 §4); completeness is the deploy gate's question, asked
+of the file. The gate takes a signal only when `deployable && complete`, and the complete
+run comes from the api checkout: `npx oa-validate --workspace <root>`.
+
+The sentence a clear-but-incomplete run prints belongs to the manifest
+(`verdict.incomplete`, carrying `{count}` and `{ids}`), not to the renderer: a service says
+`deploy row(s)`, a library `publish row(s)`, and `manifestShape` refuses a manifest whose
+verdict lacks the sentence or whose sentence cannot name the rows.
+
+```
+DEPLOYABLE — manifest conformance: no findings, INCOMPLETE: 6 deploy row(s) not run
+(U-ORPHAN, R-NODE, D-PORT, D-SCRIPT, D-RETIRED, D-HEADER). Fix: run the uniform from the
+api checkout — npx oa-validate --workspace <workspace root>
+```
+
+### Changed — the template rows reference the package, not its output (d.229)
+
+`F-INIT`, `F-JEST`, `F-RUNNER`, `G-SETUP-INSTALL`, `G-SETUP-MATRIX`, `G-SETUP-VALIDATION`
+and `G-SHARED-ENV` pointed at `api/templates/business-service/…` and
+`api/config/shared-env.json`. Since d.215a the OWNER of the template is this package and
+`api/templates/business-service` is its committed output (001 §5), so those rows
+referenced the output rather than the owner — which confirmation 004 point 2 forbids.
+
+The measured cost was where it matters most: with no workspace root — a service container
+at boot, and a service's own CI checkout — every one of those rows was `NOT RUN`. Over
+`api_biz/converter` on 2026-09-09 that was 13 rows skipped and two real findings
+(`F-RUNNER`, `G-SHARED-ENV`) never raised. After the change the same run raises the same
+findings as the workspace run, and only `U-ORPHAN`, `R-NODE` and the four `D-*` rows stay
+`NOT RUN` — the rows that really do read something outside this package.
+
+**A fourth `from:` shape**: `{ "package": "<path inside this package>", "text": true }`,
+resolved from the package's own location, so it travels with the pin. `manifestShape`
+describes it and refuses both a packaged reference without `text: true` and one naming a
+`path` and a `package` at once (two owners for one fact).
+
+**Which rows need the workspace is now the ROW's property, not only the scope's.** A check
+answers `needsWorkspace({ row })`; the ones that read nothing but their own reference
+answer from the reference. Scope `bearer` stays — making these rows `service` would have
+stopped the workspace run from checking them across every service, the regression d.223
+removed. With no workspace there is one bearer and nothing to tell apart, so a finding is
+located the way the repository knows it (`init.sh`, not `../../elsewhere/init.sh`).
+
+`G-SHARED-ENV` reads the rendered copy in the packaged template. The key set is still owned
+by `api/config/shared-env.json`; the two are kept equal by `tests/unit/sharedEnvTemplate.test.js`
+— an output with no gate would be a second copy of the fact (`doc-code-binding.md` §5).
+
+### Fixed — one directory, one name: both roots of a run are canonical
+
+The workspace root is derived from this package's own location, which node resolves
+through symlinks; a service or package root is an argument, which `path.resolve()` leaves
+in the spelling the caller typed. On macOS `/var` is a symlink to `/private/var`, so a run
+below the system temp got one root in each spelling — and "is the service inside the
+workspace", a string prefix, then answered no about a service plainly inside it. Measured
+over a `git archive` export of this repository: six rows reported `service root is outside
+the workspace root`, a sentence that was false, and the findings that export really
+carries were never raised. Every root now passes through `workspaceRoot.canonicalRoot()`
+before it is compared or printed.
+
+### Added — the documentation rows of the biz-service uniform (`docs`)
+
+The manifest gained a seventh section. Confirmation `biz-service-manifest` 001 §2 names
+five `D-*` rules about a service's own `docs/**`; four of them land as rows, and the
+fifth lands as `guidance` because the rule it needs does not exist yet.
+
+Nothing here decides whether a document is wrong. The rules of `<service>/docs/**` are
+already written and already have an owner — `api/scripts/ci/lint-biz-docs.mjs`, held by
+BIZ-DOCS — so `src/manifest/checks/docsLintBridge.js` is a bridge in the same shape
+`contractBridge.js` has for the deploy and installation contracts: the row names the lint
+rule it stands for, the bridge runs the lint ONCE per service and hands each row the
+findings of the rules it cites, with the lint's own `file:line` and message.
+
+`D-PORT` cites `F002:http-ports`, `D-SCRIPT` cites `L007`, `D-RETIRED` cites `F002` and
+`D-HEADER` cites `S001,S002` — written in the linter's own `--rules` syntax, so the row
+and the tool cannot grow a private dialect between them. A finding lands on exactly ONE
+row: the most specific citation wins, which is what keeps the port ban from being
+reported twice under two ids with two different `fix` sentences, and two rows claiming
+one rule equally are a fail-fast.
+
+A rule NO row cites is not reported by this uniform. Measured 2026-09-09 over the eight
+repositories: the lint raises 80 findings, of which 16 fall to a row here. The rest is
+the documentation gate's own, landing in each repository's CI at zero findings
+(`biz-docs-foreign-tree-gate` 001) — said out loud in the module header rather than
+implied as coverage that is not there.
+
+Where the rows do NOT answer, they say so. They are `bearer`-scoped and declare
+`api/scripts/ci` as a root they read, so a service image and a service's own CI report
+them `NOT RUN` with that reason. A tree carrying no `config/biz-docs-lint.tree.json` is
+undecided rather than clean — the file itself is row `C-LINT`, with its own fix — and a
+rule whose evidence probe reads a checkout that is not there is reported undecided too,
+never as a pass (`automation-gates.md` §5). An empty `docs/` raises nothing: the absence
+of the tree is `G-SETUP`'s finding, and a second row with a different fix would be a
+duplicate.
+
+`D-NPM` is `guidance`, not a row. 001 §2 asks that an npm script a document cites still
+exists, and no rule of the lint raises it; a row citing a rule nobody raises reports
+nothing and reads as a clean tree ("no check, so not a rule", 001 §6). The interface such
+a rule would need is handed to BIZ-DOCS, and the row is one line of manifest away once it
+exists.
+
+Measured on the eight repositories the day it landed: `invoicing` 17 `D-HEADER` findings,
+`ingest` 4 rows undecided for want of a tree config, the other six clean.
+
+### Changed — `readme-uniform` renders the pointer of a biz service too
+
+Confirmation 005 point 2 names three bearer kinds in one sentence — `library/<category>`,
+`biz-service`, `infra-service` — so `src/sync/readmePointer.js` is parameterised by kind
+rather than copied per kind; a second renderer would be two rails under one rule. What
+differs is declared as data: the region id, the regenerate command, the manifest a failed
+`--check` names, whether the README must carry a node header, and the body.
+
+A service region carries `Uniform: [biz-service](<link>)`, the sentence saying which
+repositories wear the uniform (read from the `discovery` block and its SSOT, never typed),
+the row ids grouped by the manifest section that declares them, and which path falls under
+which row. A row taking its value from elsewhere renders the path that OWNS it, never the
+value (confirmation 004). A **forbidden** row contributes its id and not its path:
+`hooks/pre-commit` and `scripts/run-pre-validation.js` may not occur in a service
+repository as text at all — `api/tests/scripts/add-service.bats` greps the whole template
+for them, because `init.sh` used to install that hook — and a region naming them would
+write a retired path back into the template every service is created from. Measured: with
+the path in the region, that suite went 55/57.
+
+The link points at the manifest as it lies in the service after `npm install`
+(`node_modules/@onlineapps/conn-orch-validator/manifests/biz-service.manifest.json`),
+derived from this package's name and the manifest's position inside it. A path, not a URL:
+a reader of the repository resolves it without a network. It resolves from the pin that
+ships `manifests/`, which is this wave.
+
+`readme-uniform --target` now reads the KIND from the disk — a root carrying
+`config/service/operations.json` is a service, a root carrying `package.json` is a library,
+neither is a fail-fast naming both files. There is no `--kind` flag: it would be a second
+way to say what the directory already says. `--all` stays the library run, because the
+eight service repositories are separate checkouts and there is no list to walk; a service
+also needs no workspace above it, which is only consulted for what to call the target on
+stdout.
+
+`templates/business-service/README.md` and its committed mirror
+`api/templates/business-service/README.md` carry the region rendered, so a service created
+by `--new` starts in sync. The pointer is the FIRST line of a service README: nothing
+requires a node header of a service, unlike a library, where its absence stays a fail-fast.
+The 27 library regions are byte-identical.
+
+Not introduced: a manifest row asserting that a README region is current. The library
+manifest carries none (`L-README` checks the node header alone), so the service manifest
+gets none either — the pointer is a sync artefact with its own `--check`, and adding the
+row is the owner's decision rather than a side effect of this change.
+
+
+### Changed — `F-RUNNER` is a delimited block, and the sync renders it
+
+The row named a compose file and compared it against nothing but itself, so the generator
+printed it `NOT RUN` and the runner stayed a copy kept in sync by review. The template's
+compose now carries `# --- oa-test-runner v1` … `# --- end oa-test-runner v1` (the two
+markers `F-INIT` already uses in `init.sh`, read trimmed so they may sit indented inside
+`services:`), the row declares `block:` and `from:`, and `src/manifest/checks/composeRunnerBlock.js`
+holds the one definition both halves read.
+
+Normalized is not loosened: `build`, `env_file` and `networks` are what the same row
+already compares against the SERVICE the runner tests, so they are removed before the
+block is compared against the template — and grafted back from that service when the sync
+renders it. Seven of the eight biz repositories reach a second network in both nodes
+(measured 2026-09-09); that is the rule being kept, and neither half may report it as a
+difference. `where` now names the repository (`api_biz/<service>/docker-compose.yml`): the
+row runs per bearer, and five services all saying `docker-compose.yml` were five findings
+nobody could tell apart.
+
+### Added — `G-SETUP-INSTALL`, `G-SETUP-MATRIX`, `G-SETUP-VALIDATION` (`skeleton_only`)
+
+The three installation documents are compared by their set of `##` headings against the
+packaged template, never by their prose (confirmation 001 §2). The sync creates a missing
+document from the skeleton — header, title, sections, and no sentence of the template's
+prose, because what a section says is this service's own fact. An existing document is
+never rewritten: a missing section is `BLOCKED` with the heading named. That a document is
+absent at all remains `G-SETUP`'s finding through the installation contract's
+`SETUP_DOCS`, so one defect keeps one owner.
+
+### Fixed — the `G-SHARED-ENV` fix sentence doubled the path
+
+`npx oa-sync-template shared-env --target config/env-templates` wrote
+`config/env-templates/config/env-templates/shared.env`: the subcommand appends
+`config/env-templates/shared.env` to its target. Measured, then corrected to `--target .`
+(confirmation 001 §3.2: every `fix` sentence in the manifest is a command).
+
+### Added — the template's production stage builds only a clean image
+
+`templates/business-service/Dockerfile` runs `oa-validate` in the production stage, after
+`COPY . .` (confirmation 001 §3.1). The CLI is this package's, and all eight biz services
+declare this library under `dependencies`, so `npm ci --omit=dev` installs it. Rows that
+read a platform file print `NOT RUN` there — an image has no workspace above it — and one
+finding of severity `boot` or `deploy` fails the build.
+
+### Changed — step 2 of the boot validation IS the manifest rows for the config documents
+
+`ValidationOrchestrator.validateConfig()` checked `config.json`/`service.name` and a non-empty
+`operations.json` with sentences of its own, while rows `C-SERVICE`, `C-OPS` and `C-CONTRACT`
+demand the same documents with more coverage, an owner, a fix and a doc pointer. One contract,
+two rails — and the same defect was reported twice: a free sentence in step 2 and a table row in
+step 7. Step 2 keeps its place in the boot order (steps 3-6 must not run behind a broken
+configuration, and step 7 runs after them) and now runs those three rows; step 7 leaves them out
+of its table and its errors as already answered. `results.steps.config` gained `findings`, and its
+`errors` are the row messages (`[Manifest] C-SERVICE config/service/config.json - …`). The
+banner and `ci/deployability.json` still describe the whole uniform — the verdict is about the
+tree, not about which step read a row. The manifest is loaded and run ONCE per validation
+(`manifestRun()`); the wrapper builds a fresh orchestrator for every attempt, revalidation
+included (d.224).
+
+### Changed — `installContract.js` exports the requirement ids it raises
+
+`INSTALL_CONTRACT_REQUIREMENTS` joins `DEPLOY_CONTRACT_REQUIREMENTS` as an export, and `add()`
+refuses an id that is not on the list. The manifest bridge
+(`src/manifest/checks/contractBridge.js`) read a hand-written copy of those three ids, with a
+comment saying it was one; the deploy contract had already paid for that pattern, its copy naming
+one requirement fewer than the module enforced. The bridge now reads the export (d.224).
+
+### Added — the documentation tree's descriptive lists are rendered, not typed
+
+`oa-sync-template docs-region (--id <id> | --all) --file <document> [--check]` renders five
+regions from the two packaged manifests: the repository shape annotated with the row owning
+each path, the required and forbidden scripts with their bodies, the runtime parameters, the
+table of every row, and the library categories with their duty sections. Three documents were
+copying the repository tree by hand and two the script table — a descriptive fact kept true by
+review only. A region carries a row's observable and never its `why` or `fix`; a `from:`
+reference renders as the path that owns the value, never as the value. The run replaces a
+region and never inserts one: a document with no markers fails and prints the two lines to
+paste, because where a section belongs in another thread's document is that thread's decision.
+`--list` names the ids, `--check` exits 1 with the drift (d.226).
+
+### Changed — one implementation of the generated-region markers
+
+Finding, replacing, extracting and diffing a marked region moved to `src/sync/generatedRegion.js`,
+shared by `readme-uniform` and `docs-region`. `readme-uniform` renders byte-identical output
+(27 of 28 libraries in sync, exit 0, before and after). Damaged markers are now reported by
+`[GeneratedRegion]` rather than `[ReadmePointer]` — the module that rejects them names itself,
+and the message still names the file to repair (d.226).
+
+### Fixed — the api checkout is found by where this package sits, not by the directory's name
+
+The workspace root was resolved by looking upwards for a directory named `api`. A CI job
+that clones the repository under any other name — `infra-mono` — therefore resolved no
+workspace, and every row reading the platform SSOT printed `NOT RUN` in a checkout that
+had the SSOT all along. The checkout is now identified by the marker it carries
+(`config/services.json`) and located from this package's own path, so the name of the
+directory stops being part of the contract; `--workspace` remains the explicit override,
+and a copy installed in a service's `node_modules` still resolves nothing, which is the
+behaviour a run inside a service container needs (d.227).
+
+
+### Added — `config/service/*.json` is decided, and the keys nobody reads are refused
+
+Confirmation `biz-service-manifest` 003 §18 asks for schemas over the three configuration
+files. Measurement first (d.217b): `operations.json` is already decided by
+`service-validator-core` `validateOperationsSchema`, and `integration-contract.json` by
+`utils/bizCiGateContract.js` — the validator the CI gate runs over it, which checks the
+connector booleans, the integration minimum, the database block and its agreement with
+`requiredConnectors.db`, and the env block with a `why` per name. Writing JSON Schema
+beside either would have been a second implementation of one rule, so `C-CONTRACT` now
+CALLS that validator (`check: config-contract`) instead of only asserting the file exists,
+and its message is the validator's own sentence. One rail, one wording, in the gate and in
+the table.
+
+`config.json` had no owner, and `C-SERVICE` checked one key of it. It now demands the
+three that were measured to have a reader — `service.name`, `service.workspaceScoped` (an
+explicit boolean; the wrapper refuses to boot without one) and
+`service.specificationEndpoint` — and reports a present-but-wrongly-typed value with a
+different sentence than a missing one, because the two send the reader to different places.
+
+`C-SERVICE-DEAD` (new row, severity `deploy`) refuses the four declarations the same
+measurement found no reader for anywhere in the platform: `service.version` (`ConfigLoader`
+assigns it from `package.json` on every load, so the value in the file is never read),
+`service.port` and `service.url` (confirmation `biz-service-port-url` 001) and
+`contractVersion` in the integration contract. Measured over the eight biz services: 22
+findings, and none for `C-SERVICE` or `C-CONTRACT` — the shape they already have is the
+shape the rows demand. A declaration nothing consumes is not harmless; it tells the next
+author something depends on it, and every new service copies it forward
+(`change-discipline.md` § Removing something removes its declaration).
+
+### Removed — `D-DB-DECL`, whose rule `C-CONTRACT` now states
+
+Once `C-CONTRACT` calls the contract validator, a missing or non-boolean
+`requiredConnectors.db` is reported by it as `[BizCiGate] Invalid contract field`.
+`D-DB-DECL` said the same thing in its own words, and two rows for one rule is the
+duplicate `change-discipline.md` § One rail per concern forbids — so the row, its
+`db-declared` check and its tests are gone in this change, not left to drift apart
+(lead decision, d.217b).
+
+`D-DB-CONSISTENT` stays: `requiredConnectors.db` against a repository that has
+`migrations/` or a database client anyway is a comparison the contract validator cannot
+make, because it never looks at the repository.
+
+
+### Added — the business-service template ships in this package, and `oa-sync-template` renders it
+
+Confirmation `biz-service-manifest` 001 §2 named three consumers of one declaration: the
+conformance check, the generator, and the documentation. Only the first existed. Every
+`fix` sentence about a file was therefore a hand-off — "copy the block from
+api/templates/business-service/init.sh" — and a hand-off is how nine copies of one
+`init.sh` block came to differ in the first place.
+
+`templates/business-service/**` moved into this package (§2), so the shape a service is
+created from is pinned by the same version that pins the manifest it is measured against.
+`api/templates/business-service` is now that template rendered with its own placeholders
+as the parameters — generated output, committed for reading (§5) — and
+`tests/unit/templateMirror.test.js` measures §9's acceptance file by file, in both
+directions.
+
+Two template files are packed under a name they are not written under, and both names are
+measurements rather than taste. `gitignore` has no dot because npm never packs a file
+called `.gitignore` — 19 of the template's 22 files reached `npm pack --dry-run` before,
+22 do now. `package.json.template` carries a suffix because a `package.json` inside a
+package is a second package to every tool that walks a package tree: under its written
+name it produced eight findings from `oa-validate --library --all` and two from
+`api/scripts/ci/verify-manifest-pins.mjs`, step 1 of the pre-push hook, all of them false
+— the template is not a published library, and its pins are deliberately not the
+platform's, because the generator writes the SSOT's versions when it creates a service.
+
+Three runs joined `shared-env` and `readme-uniform`:
+
+* `oa-sync-template --new <name> --into <dir>` — a whole service tree. It is what
+  `api/scripts/add-service.sh --scaffold` now runs, instead of a `cp -R`, a `sed` loop
+  and three `jq` calls that made the script a second writer of files the library already
+  knew how to write. `--description` is optional: without it `__SERVICE_DESCRIPTION__` is
+  left standing and the files carrying it are listed, because this run has no description
+  and inventing one would write a fact nobody stated.
+* `oa-sync-template [path…] --target <serviceRoot>` — the uniform sync of §3.2. It walks
+  the rows of classes `identical` and `generated` and renders each from the very `from:`
+  reference that row points the CHECK at: one definition, read twice. It holds no list of
+  files and no template path of its own. Files of the `own` class are never written.
+* `oa-sync-template template --target <dir>` — the committed template directory as output,
+  with `--check` as its gate.
+
+A row the manifest does not make renderable is printed `NOT RUN` with the reason, never
+filled from a guess: `F-RUNNER`, `G-PROD` and `G-SETUP` declare no `from:` reference, so
+nothing says what their content is rendered from (`.claude/rules/automation-gates.md` §5).
+Measured over the eight biz repositories on 2026-09-09, the files `--check` would change
+are exactly the `F-INIT`/`F-JEST` findings `oa-validate` reports on the same trees.
+
+### Changed — the template gained `__REGISTRY_NAME__`, and the ignore list gained `ci/`
+
+The template used to spend `__SERVICE_NAME__` on two facts — the registry identity
+(`biz-reporting`) and the directory-derived paths (`config/env-active/reporting.env`) — so
+the scaffold patched the identity back in with `jq` after copying, reformatting the JSON on
+the way. Each fact now has its own placeholder, which is what makes rendering a pure text
+substitution and the identity render comparable byte for byte. `ci/` joined the template's
+ignore list: `ci/deployability.json` is written on every start.
+
+The `fix` sentences of `F-INIT` and `F-JEST` are now the command that fixes them. The other
+three file rows keep their prose fix, because the command would not do what it says.
+
+
+### Fixed — the workspace run stops printing "no findings" over a drifting workspace
+
+A check declares what it needs in order to look, and until now the vocabulary had two
+words for three needs. `F-INIT`, `F-JEST`, `G-SHARED-ENV`, `R-NODE`, `L-ENGINES` and
+`L-PINS` are facts of ONE bearer that reach their reference file — the template,
+`api/config/shared-env.json`, `api/.nvmrc`, `api/config/libraries.json` — only through
+the workspace. There was no word for that, so they borrowed `scope: workspace`, whose
+contract is "there is no service to read", and each of them opened with
+`if (serviceRoot === null) return []`.
+
+The consequence was a silent pass, which `.claude/rules/automation-gates.md` §5 counts as
+a defect of the same severity as a wrong result. Measured on 2026-09-09:
+`oa-validate --workspace <root>` over this workspace printed `DEPLOYABLE — no findings`,
+while the same eight services, checked one at a time, reported 28 findings of those four
+rows — six drifted `jest.config.js`, four drifted `init.sh`, eight stale `shared.env`, and
+five services building on Node 22 against an `api/.nvmrc` of 24.
+
+`CHECK_SCOPES` now names three: `service` (the bearer's root is enough), `workspace` (the
+check reports about the workspace itself) and `bearer` (about one bearer, workspace needed
+only to read its `from:` reference). A `bearer` row runs once per bearer — the one given in
+service mode, every one the manifest's own `discovery` block finds in workspace mode. The
+service tables and `--library --all` are unchanged, byte for byte; only the workspace run
+gained what it had been quietly dropping.
+
+An unknown scope is refused where the check registers, not where it would first be needed:
+a check the runner cannot place would produce a report indistinguishable from one in which
+it found nothing.
+
+### Fixed — a clean verdict names how many rows did not run
+
+`DEPLOYABLE — no findings` reads as a proven clean bill of health. Over a run where five
+rows could not look it is not one, and the NOT RUN lines above it do not undo the sentence
+a reader believes. Measured on 2026-09-09: the biz-service workspace run over a checkout
+carrying `api/` alone printed `DEPLOYABLE — no findings` with 29 rows not run.
+
+The clear verdict is now `DEPLOYABLE — no findings (29 row(s) not run)` — and
+`PUBLISHABLE — no findings (6 row(s) not run)` for the library uniform — with the
+parenthesis appearing only when something really did not run. The outcome half of the
+sentence has one owner, `report.js` § `describeClearOutcome`, used by the init-log banner,
+the `oa-validate` report and the library report alike; before this the three described the
+same run in three different ways and two of them stopped at `no findings`. The blocked
+verdict and `ci/deployability.json` (which already carried `notRun[]`) are unchanged.
+
+### Changed — `L-CONSUMER` and `L-TOOLING` are bearer rows
+
+Both are facts of ONE package — who pins it, which service carries it — that reach the
+answer only through the workspace: the same shape as `L-PINS`. Carried as
+`scope: workspace` they read a null package root in a whole-set run and returned `[]`, so
+`runManifest({ workspaceRoot })` said nothing about them at all. As `bearer` rows they run
+once per package, and the whole-set run is now the union of what each package says: over
+the fixture workspace, four findings (`lib-bad-core` and `lib-orphan` pinned by nothing,
+`lib-tooling` carried by a service twice) where it previously reported none.
+`--library --all` is unchanged at 30, byte for byte — that path already ran them per
+package.
+
+`scopeByRowId` in the CLI became `packageRelativeRowIds`: it asks the registry which rows
+report a path relative to the PACKAGE root — only `scope: service` does — instead of
+naming a scope in a comment that had not mentioned the third. Nothing there had to move
+when these two rows changed scope, which is the point.
+
+### Fixed — a checkout without its siblings says NOT RUN instead of reporting a false blocker
+
+CI checks out `api/` alone, so `<workspace>/api_biz` is not on disk at all. A check reading
+it then walked an absent directory, got the empty set, and reported it as an answer.
+Measured on 2026-09-09 against a `git archive` export of this repository: `--library --all`
+raised a blocking `L-CONSUMER` on `conn-base-db` — "pinned by nothing under
+api_biz/*/package.json, api/infra/*/package.json" — about files nobody opened, and
+`L-TOOLING` quietly answered "no service carries it" over the same absence. The
+biz-service workspace run printed `DEPLOYABLE — no findings` with `U-ORPHAN` passing over
+an `api_biz` that was not there.
+
+A check now declares the directories it walks — `requiresSiblings({ row, block })`,
+derived from the row's own patterns so no name is written twice — and the RUNNER verifies
+them before running it, once, for every row alike: `NOT RUN — sibling root api_biz is not
+present in this checkout` (`sibling roots …, … are not present` when several are missing).
+Same rule `lint-biz-docs --allow-missing-siblings` already follows,
+`automation-gates.md` §5. A `bearer` row in workspace mode inherits the manifest's own
+discovery roots, because enumerating no bearers is how it would otherwise pass eight
+services nobody looked at.
+
+Measured after: the same export raises 16 findings instead of 17 — the false one is gone —
+and names `L-CONSUMER` and `L-TOOLING` as NOT RUN. `--library --all` over the full
+workspace is unchanged at 30, byte for byte.
+
+### Changed — the template `jest.config.js` is a clean norm, so `F-JEST` measures against one
+
+`templates/business-service/jest.config.js` set `RABBITMQ_URL` and `REGISTRY_URL` from a
+`||` fallback onto a hardcoded address — two violations of
+`.claude/rules/architecture-principles.md` §2 and §3 in the file `F-JEST` holds up as the
+norm. None of the eight biz services had copied it (measured: zero `||`, zero
+`process.env` writes in all eight), and the environment those two names come from is
+already owned elsewhere — `.gitlab-ci.yml` variables and `config/env-templates/shared.env`
+— so nothing was orphaned by removing them.
+
+The template is now byte-equal to `api_biz/converter/jest.config.js`, the shape two of the
+eight already share exactly and six share in substance (referential run, confirmation
+`biz-service-manifest` 001 §8.4). `F-JEST` consequently clears for `converter` and `meta`
+and keeps reporting the other six, which differ for reasons of their own.
+
+### Added — the service uniform's rows: files, scripts, config, runtime, database
+
+`manifests/biz-service.manifest.json` grows from three rows to twenty-nine, in six
+sections (confirmation `biz-service-manifest` 001 §2, §8 step 2). What each row decides
+is its `check`, and the checks fall into two kinds.
+
+**Rows that cite a checker this package already runs**, and add no rule of their own
+(004 point 4): `G-PROD` and `R-PORTS` name requirements `R1` and `R4` of
+`utils/deployContract.js`; `G-SETUP`, `D-DB-PACKAGE` and `D-DB-HEADERS` name
+`SETUP_DOCS`, `SQL_PACKAGE` and `SQL_HEADERS` of `utils/installContract.js`;
+`C-ENV-READS` runs the completeness half of `utils/envContract.js`. One registry entry
+per checker, a `requirement` per row, and a row naming a requirement its checker does
+not raise fails fast instead of finding nothing.
+
+**Rows that decide what nothing decided before**: `F-INIT` (the `oa-deps-guard v1` block
+of `init.sh`, byte-equal to the template — the same two markers
+`api/tests/scripts/infra-init-scripts.bats` matches on, reaching the biz repositories
+that bats file says are kept in sync by review only), `F-JEST`, `F-RUNNER` (the one-shot
+test runner's shape: one `test` profile, its own `1g` budget, no `restart`, the same
+build, env and networks as the service), `S-TEST`, `S-ALL-C`, `S-INT-C`, `S-COOKBOOKS`,
+`S-HOST`, `S-HOOKS`, `C-SERVICE`, `C-OPS`, `C-CONTRACT`, `C-ENV`, `C-LINT`,
+`G-SHARED-ENV`, `R-NODE`, `R-MEM`, `R-PORTS-DEV`, `D-DB-DECL`, `D-DB-CONSISTENT`.
+
+Three of those fill a measured gap rather than repeating a gate: `R-NODE` compares the
+Node major against `api/.nvmrc`, where `R3` of the deploy contract only compares CI,
+Dockerfile and `engines.node` against each other — five of the eight services are
+internally consistent on Node 22 while the platform runs 24; `R-PORTS-DEV` reads the dev
+compose, which `R4` never does; and the memory norm had no gate at all.
+
+A container script's body is parameterised by `${runner}`, resolved from the compose
+service carrying `profiles: [test]`, so seven spellings of one body are one body and not
+seven findings. `S-INT-C` carries `only_with: tests/integration`: a script pointing at an
+absent suite is a declaration with nothing behind it, and jest exits 1 on a path that
+matches no test.
+
+### Changed — `templates/business-service` reconciled with the rows it is the reference for
+
+The template is the reference bearer of every `identical` row, so a row that is red on it
+is a test of the row (lead decision, `api/shared/TODO.md` §0.2b-9 point 4). It gains
+`scripts["test:all:container"]`, the canonical `scripts.test` body, and
+`config/biz-docs-lint.tree.json`; its README no longer offers the bare host scripts as a
+second way to run a suite, because the runner is the only rail
+(`biz-test-container` 001). `npx oa-validate` over the template reports nothing.
+
+
+### Added — `oa-sync-template readme-uniform`, the rendered uniform pointer of a library README
+
+Every library's `README.md` now carries a generated region between
+`<!-- BEGIN GENERATED: library-uniform -->` markers: the line
+`Uniform: [library/<category>](<link to manifests/library.manifest.json>)` and the duty
+sections that apply to that category, with the ids of their rows. The content is read
+from the library manifest and the package's own `oa.category`, the link is computed from
+the two paths, and `--check` exits 1 with a diff when a region on disk is not what the
+manifest renders. Marker shape and idea are `scripts/ci/sync-biz-facts.mjs`, so the
+workspace keeps one shape of generated region.
+
+Discoverability of the uniform was a header per file in 003 §17; 005 point 2 replaced it
+with one rendered pointer per repository, and 0 of 28 library READMEs carried one. A
+library declaring no `oa.category` is announced `NOT RUN` and never guessed at — that
+absence is the blocking finding `U-MISMATCH` of `oa-validate --library`, which owns it.
+
+### Changed — the verdict is a property of the uniform, not of the runner
+
+Which severities stop a bearer, and the two words its verdict is printed with, are
+now declared by the manifest: `blocking_severities` and
+`verdict: { blocked, clear }`, required by the manifest's check on itself
+(`M-BLOCKING`, `M-VERDICT`). `runManifest` reads them instead of a global constant
+and carries them in the result; `report.js` prints them.
+
+Before this, one list held `boot`, `deploy` and `publish`, so a service run ended
+with `NOT DEPLOYABLE — N finding(s) of severity boot|deploy|publish` — offering a
+consequence no service row can raise — and the library CLI kept its own second list
+to avoid the same sentence. That duplicate (`LIBRARY_BLOCKING` in
+`src/cli/oa-validate.js`) is gone. A service now reads `… of severity boot|deploy`
+and `DEPLOYABLE — no findings`; a library reads `… of severity publish` and
+`PUBLISHABLE — no findings`.
+
+### Changed — `L-CONNECTOR-ENV` exempts the config module in either shape
+
+The row's parameter is now `allowed: ["src/config/", "src/config.js"]` instead of
+`allowed_dir: "src/config"`: an entry ending in `/` exempts a directory, any other
+entry exempts that one file. The duty is about the concept — env reading lives in
+one config module — and a package small enough for a single `src/config.js` wears
+the same uniform as one with a directory. Measured over the workspace: the row falls
+from 2 findings to 1, and the one that remains
+(`conn-base-db/src/createSequelize.js`) is a real finding.
+
+### Changed — `L-README` asks a library README for `> Owns:` and `> Status:`
+
+The row used to demand `Parent:`, `Owns:` and a `Status` section, citing
+`api/docs/biz/DOC-STANDARD.md` — a header that standard reserves for the biz
+documentation tree, which `api/shared/**` is not part of. It now asks for the node
+header of `api/docs/standards/INFRA-DOC-STANDARD.md`: a `> Owns:` line carrying a
+value, and a `> Status:` line whose value is `current`, `draft` or `archived`.
+`Parent:` is neither required nor forbidden — a library's parent is the rendered
+category line, so a hand-written one would be a second owner of one fact.
+
+### Added — the uniform manifest and `npx oa-validate` (towards 8.0.0)
+
+`manifests/biz-service.manifest.json` is the machine-readable declaration of what a
+biz service is, shipped inside this package so that the manifest version IS the
+validator version — the pin decides the shape, and no version field exists in the
+file (confirmation `biz-service-manifest` 004).
+
+The core lands here; the rows that describe the whole uniform follow in the same
+major:
+
+- `src/manifest/` — loader, the manifest's check on ITSELF (required row fields,
+  unique ids, valid severity, a registered check with its parameters, a non-empty
+  `doc`, and no copied list of names), discovery of bearers from the disk with
+  `from:` references resolved against the workspace, a registry of checks, and the
+  report;
+- rows `X-HOOKS` and `X-PREVAL` (`files.forbidden`, severity `deploy`) — the hook
+  the owner deleted and the per-service pre-validation script the library command
+  replaced;
+- row `U-ORPHAN` — a directory under the discovery pattern that matches no pattern,
+  or that `api/config/services.json` does not declare;
+- `bin.oa-validate` — one table `id · severity · where · what · fix · owner`, the
+  `doc` pointer per reported row, `--json`, `--workspace`, exit `0` / `1` (`2` when
+  the run cannot start).
+
+Where the workspace is not reachable — inside a service container it is not — the
+rows that need it print `NOT RUN` with the reason, never a pass.
+
+Measured on the eight biz repositories the day it landed: converter clean, the other
+seven carrying `hooks/pre-commit`, `scripts/run-pre-validation.js` or both; zero
+`U-ORPHAN`.
+
+- **Step 7/7 "Manifest conformance", the banner and `ci/deployability.json`.** The
+  manifest now runs at every boot, against the service root the orchestrator was
+  constructed with (never `process.cwd()`). A `boot` finding fails the validation as
+  before; a `deploy` finding lets the service start and sets `results.deployable =
+  false` with the rows in `results.deployFindings`, prints the banner
+  `NOT DEPLOYABLE — N finding(s)` plus the table through the injected logger, and
+  writes the verdict to `ci/deployability.json` for `deploy-production` to refuse on.
+  A clean run says `DEPLOYABLE — manifest conformance: 0 finding(s), K not run`; the
+  signal carries the NOT RUN rows too, because a row that could not look is not a
+  pass. No timestamp in the file — an unchanged tree writes an unchanged file. A run
+  that stops at an earlier fail-fast step reports `deployable: null`, which is
+  "unmeasured", not "fine". `oa-validate --workspace <root>` without a service root is
+  the workspace run: every workspace-scoped finding, and the per-service rows NOT RUN.
+  In a single service's run those rows report only what lies under that service — and
+  where the service root does not lie under the workspace root at all, they are NOT RUN
+  with that reason rather than silently filtered to nothing.
+  Measured: hello-service 2 findings and `deployable: false`, converter 0 and
+  `deployable: true`.
+
+
+### Added — the library uniform and `npx oa-validate --library`
+
+`manifests/library.manifest.json` — the same concept for the 28 shared libraries, in
+the same package and therefore on the same version, so the two shapes cannot drift
+apart (confirmation `biz-service-manifest` 002 §10–§15). A library has no boot, so its
+rows carry one severity, `publish`: the choke point is `scripts/publish-library.sh`,
+and what fails there never becomes an artefact.
+
+- **Discovery, not a list.** `api/shared/**/package.json` minus `**/node_modules/**`
+  and `**/tests/fixtures/**`, bound to `api/config/libraries.json` by a `from:`
+  reference. `U-ORPHAN` reports both directions: a package the SSOT does not know, and
+  a name in the SSOT with no package. No library name appears in the manifest, and the
+  validator's own fixtures are excluded by a manifest row rather than by a branch in
+  the code (002 §13.1).
+- **Categories as definitions.** `core`, `connector`, `orchestration`, `runtime`,
+  `tooling`, each with the categories it `may_depend_on` — itself included, explicitly,
+  because within a layer is allowed and upward is not. The category is DECLARED
+  (`"oa": { "category": … }`) and verified against the dependency graph; a missing
+  declaration and a declaration the graph contradicts are both `U-MISMATCH` (005.3).
+  `orchestration` gets no row of its own: "depends only downward" is what `U-MISMATCH`
+  already decides.
+- **Rows.** Every library: `L-MAIN`, `L-ENGINES` (against the platform major,
+  referenced from `api/.nvmrc`), `L-TESTS`, `L-TEST-SCRIPT`, `L-PACK-TESTS`, `L-PINS`,
+  `L-NO-FILE-RANGE`, `L-CHANGELOG`, `L-README`, `L-CONSUMER`. Per category:
+  `L-CORE-DEPS`, `L-CORE-EXPORTS`, `L-CONNECTOR-ENV`, `L-RUNTIME-CLIENT`, `L-TOOLING`.
+  `L-PACK-TESTS` measures the effect (`files` allowlist, then `.npmignore`, then
+  `.gitignore`), never the presence of a file — eight packages keep `tests/` out with
+  an allowlist alone, and a row checking for `.npmignore` would report all eight as
+  broken. Falsified against `npm pack --dry-run` over all 28: both say clean, 28/28.
+- **What is deliberately not a row** is written into the manifest's `guidance` block
+  with its reason and its decision — `L-LINT` (002 §14), the logger/error contract, the
+  boot-phase messages, "a removed export bumps the major", and the canonical body of
+  the `test` script. A duty nothing can decide is guidance, not a rule (001 §6), and
+  the shape check fails the build if a guidance entry grows a `check`.
+- **`oa-validate --library <packageDir>` and `--library --all`** — one table
+  `id · category · where · what · fix`, the `doc` pointer per reported row, `--json`,
+  exit `0` / `1` (`2` when the run cannot start). `--library` with neither a package
+  nor `--all` is a usage error; nothing is guessed. `--all` runs every discovered
+  package plus one whole-set run, because a name in the SSOT with no package on disk
+  belongs to no package's root and no per-package run would ever show it.
+- `severity: publish` joins `boot` and `deploy` in the shape check; `from:` gained two
+  shapes for the two SSOTs that are not arrays of objects — `names: "keys"` for an
+  object map (`api/config/libraries.json`) and `text: true` for a file that is one
+  value (`api/.nvmrc`). The service manifest is unchanged and its self-test unchanged.
+- **`ok` now answers for a library too.** `runManifest.BLOCKING_SEVERITIES` carries
+  `publish` beside `boot` and `deploy`, so a run over a library returns `ok: false`
+  when a `publish` row fires; before, `ok` was computed from the service severities
+  alone and a library run reported `ok: true` with findings on the table. One fact,
+  one owner — a consumer no longer has to recompute the verdict per uniform.
+  `LIBRARY_MANIFEST_PATH` moved from the CLI to `src/manifest/loadManifest.js` beside
+  `DEFAULT_MANIFEST_PATH`, for the same reason: where the manifest lives is a fact
+  about the package, not about the CLI, and a boot step reads it without one.
+
+Measured over the 28 libraries the day it landed: 119 findings — `U-MISMATCH` 28 (no
+package declares a category yet), `L-ENGINES` 28 (no package declares the platform
+major), `L-README` 28, `L-CHANGELOG` 21, `L-PINS` 13 (all one uncommitted
+`logger-contract` 1.0.0 → 1.1.0 wave, not a defect of the pins), `L-CONSUMER` 1
+(`conn-base-db`, which nothing in the workspace depends on), `U-ORPHAN` 0. Nothing in
+the libraries was changed by this entry; that is the next batch.
+
+### Added — the platform env manifest and `bin.oa-sync-template` (towards 8.0.0)
+
+- `src/sync/sharedEnv.js` — `renderSharedEnv(manifest)` and `checkSharedEnv(manifest, text)`,
+  both pure: the file text `api/config/shared-env.json` describes, and whether a file on
+  disk is still that text. Nothing here reads the environment or a path; the caller loads,
+  reads and writes. `consumers` is deliberately not rendered — who reads a key is a fact
+  the code owns.
+- `bin.oa-sync-template` — `oa-sync-template shared-env --target <dir> [--workspace <root>]
+  [--check]` writes `<dir>/config/env-templates/shared.env` from that manifest, or exits 1
+  with the diff under `--check` (2 when the run cannot start). No flag points it at another
+  manifest: the shared key set has one owner, beside the SSOT.
+- Measured on the two copies this repository owns: the platform template and the
+  business-service template are now rendered output, key-for-key identical to the platform
+  file they came from. The business-service copy was 4 keys/values adrift (`LOG_LEVEL`
+  absent, `guest:guest` and two `minioadmin` values where the platform file says
+  `CHANGE_ME`).
+
+Decision: confirmation `biz-service-manifest` 003 §18, 004.
+
+### Changed — `verify-test-coverage` asks the DISK too, not only jest
+
+**BREAKING.** The gate compared what jest matches against what the `test:all`
+chain and the declared stack tiers run — and all three asked the same jest. A
+`testMatch` narrowed to `tests/unit` therefore hid `tests/integration/` from
+every side at once, and the run printed `OK … 1 file(s) matched, 1 run by the
+test:all chain` with a whole suite on disk running nowhere (measured 2026-09-08).
+
+`verifyTestCoverage` now also walks the repository for platform test files
+(`**/tests/**/*.test.js` — the `testMatch` `templates/business-service/jest.config.js`
+declares, used verbatim by all eight biz repositories) and reports every one the
+service's jest config does not match, as `TEST_NOT_MATCHED`. `node_modules` and
+`.git` are not walked; a file under `tests/` that is not a test file
+(`tests/helpers/*.js`, fixtures, `tests/setup-env.js`) is never reported.
+`TEST_COVERAGE_SCOPE` names the new side, so the printed scope still describes
+what the gate looked at.
+
+Repositories that already keep the platform `testMatch` are unaffected: the eight
+biz repositories return exactly the verdicts they returned before (7 × OK,
+hello-service `TEST_RUNS_NOWHERE`).
+
+### Changed — every error this package throws names the context that threw it
+
+Each thrown message now carries `[Context] Problem - Expected/Fix`, chained failures
+pass their origin as `cause` instead of interpolating its text, and a static guard
+(`tests/unit/error-message-contract.test.js`) fails the suite if a bare message returns.
+
+### Changed — `step.service` names a registered service, or the step fails
+
+**BREAKING.** `CookbookTestRunner._resolveServiceRoot` no longer falls back to
+`servicePath` for an unregistered name, so a typo in a cookbook's `step.service`
+is refused (`Unknown step.service "<x>" - Expected one of: <registered names>`)
+instead of quietly running the runner's own handler and reporting PASS.
+
+### Removed — the integration minimum no longer checks `test:all` by NAME
+
+`verifyIntegrationMinimum` required the literal substring `test:integration` in
+`test:all` — a rule about a name, which passed for `echo test:integration` and
+failed for a chain reaching the same files through another script; the fact it
+was standing in for is now measured by `verify-test-coverage`, so the second rail
+is gone. The other three checks stay: `test:integration` must exist, it must not
+carry `--passWithNoTests`, and `test:all` must exist.
+
+### Added — `verify-test-coverage`: every test runs somewhere, or says why it cannot
+
+**BREAKING (the check is folded into `verify-contract`).** A new command, and a
+new optional contract field `stackTiers`. The gate compares three sets, all of
+them answered by the service's own jest rather than by parsing its scripts:
+
+| | what | how |
+|---|---|---|
+| T | every file the service jest config matches | `jest --listTests` |
+| A | every file the `test:all` chain runs | the chain decomposed `npm run …` → jest, each invocation asked `--listTests` |
+| B | every file the declared stack tiers run | the same, per declared script |
+
+A file in T that is in neither A nor B is a suite that runs nowhere: green
+whenever somebody runs it by hand, in no pipeline, and reported by nothing.
+Measured over the eight biz repositories on 2026-09-07 — biz-hello matched 17
+files and ran 14.
+
+`stackTiers` is how a suite legitimately stands outside `test:all`:
+
+```json
+"stackTiers": [
+  { "script": "test:e2e", "requires": "needs a live biz-hello consumer on biz-hello.workflow; CI has no service runtime" }
+]
+```
+
+`requires` is mandatory, for the same reason `why` is mandatory in the `env`
+block: a tier nobody can justify is the one nobody dares delete. There is no
+exemption by directory name — `tests/e2e/**` is not self-evidently un-runnable,
+and a name cannot carry a reason.
+
+Five violations, each naming the fix: a test that runs nowhere; a declared
+script `package.json` does not have; a declared script that lists no test file
+(a declaration with no consumer); a declared script whose tests `test:all`
+already runs (the declaration states something untrue); and — refused when the
+contract loads — an entry without `requires`. A step in the chain the gate
+cannot decompose is reported too, never skipped: an unreadable step would make
+every count a guess.
+
+**BREAKING for repositories:** `verify-contract` now runs this check, so from
+8.0.0 a repo with a test file outside `test:all` and outside a declaration is
+RED. At the pin, that is biz-hello and only biz-hello
+(`tests/e2e/mq-invocation.test.js`, which needs a live consumer): it declares
+the tier, and goes green. The other seven repositories are already clean —
+measured 2026-09-07: converter 66/66, emailer 28/28, ingest 24/24, invoicing
+36/36, meta 51/51, pdfgen 17/17, property 163/163.
+
+**What the gate does not measure, and says so on every run:** whether a declared
+stack tier is ever RUN. The declaration says why the suite cannot run in
+`test:all`; it never claims something else runs it.
+
+### Added — `getForeignTestNamespace()`, and R8 accepts it
+
+**Minor, additive.** Beside `getTestNamespace()` the package now exports
+`getForeignTestNamespace()`: a namespace an integration test must NOT see rows
+from, for the isolation tests that prove a handler filters on tenant_id AND
+workspace_id. It returns another member of the allowed environment classes,
+chosen by position in that list and wrapping at its end — deterministic per
+environment, with the caller's own workspace, and validated by the same
+whitelist, the same refusal message and the same missing-variable message as
+`getTestNamespace()`.
+
+Why the library owns it (owner decision 2026-09-07, via BIZ-hello): the two
+alternatives a repo reaches for are both what deploy-contract R8 exists to
+refuse — a literal (biz-hello asserted against tenant 101, the live Meditest
+customer, so its isolation test wrote into real data) or arithmetic
+(`tenant + 1`, which turns the platform default 99 into 100, LIVE). Reading a
+second env variable per repo was rejected as a duplicate rail.
+
+R8's permit in `utils/deployContract.js` now recognises a call to either helper,
+on a line that executes; a mention in a comment still earns nothing.
+
+### Fixed — the deploy-contract gate reports the scope it actually checks
+
+**Patch — messages only, no rule changed.** `verify-contract`,
+`verify-deploy-contract` and the green line
+`[BizCiGate] OK deploy-contract (<service>) — … satisfied` all announced
+`R1-R7`, hand-written in four places. R8 (one source for tenant / workspace
+identity) had been part of the run for weeks, and R6 has never been part of it —
+it is the library-compatibility gate `verify-lib-compat`. So the gate claimed one
+check it does not run and hid one it does.
+
+The scope now has a single owner: `DEPLOY_CONTRACT_REQUIREMENTS` in
+`utils/deployContract.js`, the module's own list of the ids it can raise, with
+`DEPLOY_CONTRACT_SCOPE` (`R1-R5, R7-R8`) rendered from it. Both are exported for
+callers that need to name the scope. `verifyDeployContract` refuses an id that is
+not on the list, so the list and the code cannot drift apart again.
+
+Reported by BIZ-hello (`api/shared/TODO.md`, "biz-ci-gate hlásí menší pokrytí,
+než jaké odbaví").
+
+### BREAKING — `SETUP_DOCS` moves from `docs/setup/` to `docs/80-setup/`
+
+**Major, behavioural.** The installation contract now requires
+`docs/80-setup/{INSTALL,PLATFORM_MATRIX,VALIDATION}.md`. It required
+`docs/setup/{…}.md` before; the file names are unchanged, the branch is not.
+There is no tolerance of the old path and no fallback — a repo that still
+carries `docs/setup/` fails `verify-install-contract` (and `verify-contract`,
+which folds it in) with three `SETUP_DOCS` violations
+(`architecture-principles.md` §3, §11).
+
+The contract had been the reason seven biz repos violated `docs/biz/DOC-STANDARD.md`
+rule 7, which requires numbered branches `NN-name`: converter measured that
+renaming to a numbered branch satisfied lint S006 and immediately broke the CI
+gate. The owner decided the contract yields to the standard, not the other way
+round — `api/docs/governance/confirmations/docs-setup-branch-naming.md`
+confirmation 001, verdict "B — kontrakt: SETUP_DOCS přejmenovat na `NN-setup/`".
+The number `80` is BIZ-general's: property, the only numbered biz tree today,
+already carries `docs/80-setup/`; `30` would collide with property's
+`30-recurring`; and setup is an operational appendix sitting behind the contract
+nodes, in the same band as the platform tree's `80-decisions` / `90-migration`.
+
+**How a repo adopts it.** The rename and the pin of this package's new version
+land in the SAME commit of each repo (`git mv docs/setup docs/80-setup` plus the
+`@onlineapps/conn-orch-validator` bump). Between the publish and that commit the
+repo's CI is red, so the two halves are never split across commits
+(`automation-gates.md` §3 — a gate lands with its compliance, not ahead of it).
+The `Fix:` half of the violation message says so on every run: *"add
+docs/80-setup/INSTALL.md to the repository; a repo carrying the older
+docs/setup/ branch renames it to docs/80-setup/."*
+
+### Removed — the documented `url` tolerance in `ServiceReadinessValidator`
+
+**Patch — no behaviour changes.** The class docblock carried a paragraph
+explaining that the retired probe's `url` may still arrive from a stale caller,
+and a test asserted that tolerance. Neither had a subject, and the paragraph said
+so itself: the only caller that ever passed a url was Tier-1's readiness step,
+retired 2026-08-22, and the one consumer left —
+`helpers/createServiceReadinessTests`, and through it every biz
+`tests/bootstrap/` suite — passes name, version, operations, testCookbook and
+registry. A tolerance nobody exercises still tells the reader that some caller
+depends on it (`change-discipline.md` § Removing something removes its
+declaration).
+
+The docblock now states what `validateReadiness(service)` reads: `name`,
+`version`, `operations`, `testCookbook`, `registry`. Nothing replaced the
+tolerance — the method destructures the fields it needs and looks at no others,
+the same decision as `ValidationOrchestrator` for the same reasons (a
+per-class unknown-key rejection would be a second rail and a gate without its
+compliance sweep, `automation-gates.md` §3). A caller that still passes a `url`
+is unaffected, and the test that now stands asserts exactly that alongside the
+removal.
+
+### Removed — the documented `serviceUrl` tolerance in `ValidationOrchestrator`
+
+**Patch — no behaviour changes.** The class docblock promised that
+`options.serviceUrl` is "accepted-and-ignored: existing callers (ServiceWrapper,
+the biz `scripts/run-pre-validation.js`) still pass one". That sentence had gone
+false in both halves: `ServiceWrapper._createValidationOrchestrator()` says in
+its own comment that `serviceUrl` is NOT passed, and the biz
+`scripts/run-pre-validation.js` hand theirs to `CookbookTestRunner`, never to
+this class. A tolerance nobody exercises still tells every reader that some
+caller depends on it, which is the declaration `change-discipline.md` § Removing
+something removes its declaration exists to delete. The two tests asserting the
+tolerance, and the `serviceUrl` key in two test fixtures, went with it.
+
+**Nothing was added in its place, and that is a decision.** The constructor reads
+`serviceRoot`, `serviceName`, `serviceVersion` and `logger`, and looks at no
+other key — the same way `CookbookTestRunner` and every other component in this
+package treat their options. Rejecting unknown keys would put a new mechanism on
+one class only (a second rail), and would be a gate landing without the
+compliance sweep `automation-gates.md` §3 requires. A caller that still passes a
+`serviceUrl` is therefore unaffected, exactly as before.
+
+### Removed — `run-prevalidation` no longer loads the service config to fetch a URL nobody reads
+
+**Minor, behavioural.** `resolveServiceUrl()` is gone from `src/cli/biz-ci-gate.js`
+and the `serviceUrl` parameter is gone from `runPreValidation`
+(`src/utils/preValidation.js`).
+
+It resolved the service's own `@onlineapps/service-wrapper`, ran
+`ConfigLoader.loadAll()` and handed `config.service.url` to `CookbookTestRunner`
+— which never read it (`this.serviceUrl` appears nowhere in that class). And the
+value had stopped existing: the owner removed `port` and `url` from the service
+shape (`docs/governance/confirmations/biz-service-port-url.md` 001), so
+`loadAll()` does not return `service.url` any more. Measured against the
+installed loader with a `config.json` that still declares the field:
+
+```
+WITH url in config.json -> config.service.url = undefined
+service keys = name,version,specificationEndpoint,description,workspaceScoped,env
+```
+
+So the resolution had been yielding `undefined` for every service on the
+platform. What it still did was make an installed wrapper, a readable
+`package.json`, a declared `specificationEndpoint` and a resolvable `${ENV}`
+placeholder into preconditions of a cookbook run that depends on none of them —
+a required declaration with no consumer, which is worse than none
+(`change-discipline.md` § Removing something removes its declaration).
+
+Running cookbooks needs `tests/cookbooks/`, `operations.json` and the handler
+modules. A service that ships none of the rest now runs its gate; a service that
+still declares `service.url` is unaffected, because the field is ignored rather
+than refused. The test that asserted the old refusal (`@onlineapps/service-wrapper
+is not installed`) went with the code that produced it.
+
+### Added — `utils/handlerRef`: one definition of what a handler ref is and what resolving it means
+
+**Minor.** New exports on the package index: `HANDLER_REF_PATTERN`,
+`parseHandlerRef(ref)` and `resolveHandlerModule({ serviceRoot, handlerRef })`.
+
+The rule lived in five places. Four were copies of the same regex literal
+checking only the SHAPE — `ServiceReadinessValidator`, `ValidationOrchestrator`,
+`ServiceStructureValidator`, `helpers/createServiceReadinessTests`. The fifth,
+`CookbookTestRunner.resolveOperation`, actually resolved a ref, and did it more
+weakly than production. Measured against the new fixture before the change:
+
+```
+double-hash    -> { modulePath: '…/src/handlers/v3/good.js', exportName: 'run' }
+escapes-src    -> { modulePath: '…/v3-service-broken-handler/outside.js', exportName: 'run' }
+missing-export -> { modulePath: '…/src/handlers/v3/good.js', exportName: 'nope' }
+```
+
+`handlers/v3/good#run#extra` was silently truncated and dispatched;
+`../outside#run` loaded and ran a module from OUTSIDE the service source root;
+an export that does not exist got a descriptor. Cookbooks run at every biz
+service boot, so that was the loosest resolution on the platform sitting on the
+hottest path.
+
+The two functions are separate on purpose, and that is what lets
+`service-wrapper`'s `HandlerLoader` adopt them as an internal swap rather than
+an API change: `resolveHandlerModule` states exactly the rule the loader
+implements today (containment on the resolved location, `require`, the export is
+a function), while the stricter declared form — `handlers/<path>#<export>`, owned
+by `api/docs/biz/30-operations/schema-v3.md` § handler — stays in
+`parseHandlerRef`. Adopting the first narrows nothing the wrapper accepts.
+
+### Changed — the cookbook runner resolves handlers by that rule, which makes it stricter
+
+**Minor, behavioural.** `CookbookTestRunner.resolveOperation()` now refuses what
+it used to accept: more than one `#`, a ref outside the declared form (including
+anything reaching out of `src/`), a module that does not load, and an export that
+is missing or is not a function. The failures arrive at resolution instead of at
+the first invocation, and each names the ref, the resolved path and the fix.
+
+A service whose cookbooks pass today keeps passing — every conformant ref
+resolves exactly as before. One whose `operations.json` carries a malformed ref
+now fails its cookbook step where it previously dispatched something the author
+did not write. The descriptor gained `handler` (the resolved function), and the
+dispatch no longer requires the module a second time.
+
+### Added — the readiness suite verifies that every declared handler RESOLVES
+
+**Minor.** `createServiceReadinessTests` generates one more test: *every declared
+handler resolves to an exported function*, through `resolveDeclaredHandlers`,
+which is exported from the helper module. Matching the ref against a regex said
+nothing about whether the module is in the image, so an operation naming a module
+nobody shipped passed readiness in CI and failed at boot, where
+`HandlerRegistry.validate()` resolves every declared operation and fail-fasts.
+The verdict was right in the end; it arrived one environment too late. The check
+fail-fasts on the first unusable handler and names the operation.
+
+### Changed — the `getTestNamespace()` refusals name the CI half of the fix, not only the local file
+
+**Patch.** All three fail-fast messages of `utils/testNamespace` (missing value,
+non-integer value, refused tenant class) pointed at `config/env-active/shared.env`
+and nothing else. That file exists on a developer's machine and in no CI job: CI
+takes the testing pair from the pipeline variables, not from a file in the
+repository (`api/docs/standards/tenant-allocation.md` § Env variables). So the
+one place the message is read by somebody who cannot act on it — a red pipeline —
+was the one place its `Fix:` was unusable, which is the defect
+`architecture-principles.md` §5 names.
+
+Each message now names both: `locally in config/env-active/shared.env`, `in CI in
+the pipeline variables`, and the section of the standard that owns the rule. The
+verdicts are untouched — the same values are accepted and refused as before, and
+only the wording moved.
+
+### Added — an `expect.output` field name is a dot path into the output
+
+**Minor.** `CookbookTestRunner.validateOutput()` resolves a field name such as
+`"pdf.size"` through nested objects instead of looking up `actual["pdf.size"]`
+flat. Every matcher works over a path — `equals`, `contains`, `type`, `pattern`,
+`min`, `max`, `length`, `exists`.
+
+Why it had to change: a file descriptor lives under its own key inside the
+output (`{ pdf: <descriptor> }`), never at the root
+(`api/docs/biz/40-cookbooks/variable-references.md` § "File descriptors in
+outputs"). A cookbook that may only name root keys could therefore assert
+nothing at all about a generated file: `"pdf.size": { "min": 1000 }` came back
+as `Field pdf.size: missing in output` and failed the step — and, at Tier-1, the
+boot of a service returning exactly what the norm prescribes.
+
+Two rules, both decisions:
+
+- **The exact key wins, at every level.** `{ "a.b": 1 }` is legal output, so
+  `"a.b"` is looked up verbatim before the name is split; splitting is what
+  happens when the name does not exist as written. Nothing has to be escaped.
+- **Objects only.** A segment never indexes an array — `"items.0"` does not
+  reach the first element — and never reads a property off a scalar. No cookbook
+  asks for indices today, and the syntax would be this library's invention
+  rather than the norm's.
+
+A path that cannot be resolved reports the whole path AND the first segment that
+failed, because "no `pdf` at all" and "a `pdf` without a `size`" are different
+defects: `Field pdf.size: missing in output - segment "pdf" not found. Fix: …`.
+A name without a dot keeps its original wording, unchanged.
+
+Backwards compatible: a flat key resolves exactly as before, including the
+`Field <name>: missing in output` message it produced.
+
+### BREAKING — `getTestNamespace()` refuses tenant 97; the allowlist is 96 / 98 / 99
+
+**Major.** `ALLOWED_TENANT_CLASSES` in `utils/testNamespace` drops **97**. A run
+configured with `TESTING_TENANT_ID=97` now throws instead of returning a
+namespace, and the refusal message lists the classes that remain.
+
+97 was the `TESTING` environment class. The allocation retired it on 2026-08-31
+and the whitelist kept it, so the guard accepted at run time a class no row of
+`api/docs/standards/tenant-allocation.md` claimed — the document itself recorded
+the gap as "a residue, not a permission", waiting for exactly this change. A
+whitelist states the allocation; it does not outlive it.
+
+**Nothing in the workspace sets that value.** Every `TESTING_TENANT_ID` in `api`
+and `api_biz/*` is `99` in the env templates and `96` in CI, verified before the
+narrowing — compliance precedes the gate (`automation-gates.md` §3). Dependents
+that pin an older version keep the wider list until they bump; a repo that has
+adopted this version and still configures 97 fails fast at the first integration
+run, naming the value, the allowed classes and the document.
+
+Unchanged: 96, 98 and 99 are still accepted, 100 (LIVE) and 101+ (CUSTOMER) are
+still refused, and the workspace id is still not class-checked.
+
+
+### Added — R8 exempts an integration test that owns its database, and reports the half-done case
+
+**Minor.** `utils/deployContract` R8 gains a third permit for `tests/integration/`:
+a file that builds its own schema (`CREATE DATABASE` / `CREATE SCHEMA`) on a line
+that executes AND redirects `DB_NAME` to it (`process.env.DB_NAME = …`, bracket
+form included) no longer has to take its namespace from the shared test-namespace
+module. It targets no shared namespace, so the helper protects nothing it could
+reach, and the only assertion it could offer instead cannot fail —
+`getTestNamespace()` returns a value from `ALLOWED_TENANT_CLASSES` and nothing
+else. Reporting a state whose only compliance is an assertion that cannot fail is
+what `automation-gates.md` §3 forbids.
+
+The gate is not softened by it. A file that builds its own schema and does NOT
+redirect `DB_NAME` is still reported, now under a message of its own: its queries
+reach the live database while the file appears to own a throwaway. Both halves of
+the permit are read on lines that execute — a `CREATE DATABASE` or a redirect
+sitting in a comment earns nothing. Every file R8 reported before this change is
+still reported, and every file it reported for having no schema of its own keeps
+the message it had.
+
+The permit asks for the redirect rather than banning the live database's name:
+a test may legitimately name the live schema to assert it never touches it, and
+a ban would demand the deletion of that guard — the same reason the runtime guard
+is an allowlist rather than a comparison against a declared live id.
+Rule: `api/docs/standards/tenant-allocation.md` § Enforcement.
+
+### Changed — the logger check is `@onlineapps/logger-contract`, and the message case follows it
+
+`ServiceReadinessValidator`, `ValidationOrchestrator` and `CookbookTestRunner`
+each carried their own `LOGGER_METHODS` constant and their own validation loop —
+three byte-identical copies of one contract, which
+`change-discipline.md` § One rail per concern calls a defect. All three now call
+`assertLogger(context, logger, reason)` from `@onlineapps/logger-contract`
+(exact pin `1.0.0`), per owner confirmation
+`api/docs/governance/confirmations/connector-logger-contract.md` 004.
+
+What a caller sees: the same two states, refused at the same point in the same
+constructor, with the same `[Context] …` prefix and the same `Fix:` line. The
+only difference is the word after the prefix — `logger is required` /
+`logger is incomplete` where these three used to write `Logger` with a capital
+L. The other four adopters (`content-resolver`, `cookbook-template-helpers`,
+`conn-orch-registry`, `error-handler-core`) already wrote it lowercase, so this
+removes a divergence rather than creating one.
+
+### BREAKING — cookbook `steps` is an ARRAY, and the object shape is refused (DÁVKA 95a)
+
+**Major.** `utils/cookbookFormat.normalizeCookbookSteps` is renamed to
+`readCookbookSteps` and no longer normalises anything: a `steps` value that is
+present but not an array THROWS, with the object→array migration recipe in the
+message. `CookbookTestRunner.normalizeSteps()` is gone — the runner calls the one
+owner of the rule directly. `CookbookTestRunner.validateCookbook` throws
+`[CookbookTestRunner] Cookbook has no steps - …` where it used to throw
+`Cookbook must have steps (array or object)`.
+
+Owner decision, fully authoritative:
+`api/docs/governance/confirmations/cookbook-steps-shape.md` 001 (2026-09-05) —
+`steps` is an array of step objects carrying `step_id`, the only allowed shape;
+the object variant must not be permitted or used anywhere. It supersedes the
+2026-08-17 object directive, which never landed in any runtime.
+
+Why the tolerance had to go rather than stay as a convenience: the offline runner
+converted the object into an array, so Tier-1 passed a cookbook the production
+WorkflowOrchestrator — which only ever read arrays — threw on. That is a false
+green, and it is what kept object-shaped cookbooks alive in the tree. Order is
+the reason the shape matters at all: JS reorders numeric object keys and Postgres
+`jsonb` does not preserve key order either (measured M9,
+`infra/api_monitoring/src/consumer/cookbookSplit.js:32-37`).
+
+### BREAKING — the cookbook version needs all three components (DÁVKA 95a)
+
+**Major.** `checkCookbookFormatVersion` accepted 1 to 3 numeric components
+(`/^\d+(\.\d+){0,2}$/`); it now requires `major.minor.patch`
+(`/^\d+\.\d+\.\d+$/`). `"version": "2.1"` was accepted by this Tier-1 gate and
+rejected by the machine SSOT — `shared/cookbook/cookbook-core/schemas/cookbook.v2.schema.json:16`,
+`"pattern": "^2\\.\\d+\\.\\d+$"` — so the offline rail was the lenient one, which
+is the same false green as the object steps. Five fixtures in this package
+declared `"2.1"` and now declare `"2.1.0"`.
+
+### REMOVED — `WorkflowTestRunner` (DÁVKA 95a)
+
+**Major.** `WorkflowTestRunner` and its export are deleted. It was a second,
+parallel cookbook-execution rail with no consumer anywhere in the workspace
+(measured 2026-09-05: `api`, `api_biz/*`, `fe_adminui`, outside this package's
+own test and export), and it read `step.id` — the spelling `format.md` § Steps
+bans — so every key it wrote into the workflow context was `undefined`. A
+duplicate rail with no written justification is a defect, not redundancy
+(`change-discipline.md` § One rail per concern).
 
 ### BREAKING — standard level v1.1 "Multitenancy Standard" is removed (DÁVKA 88j)