@onlineapps/conn-orch-validator 6.0.1 → 8.0.0

package/manifests/biz-service.manifest.json

@@ -0,0 +1,658 @@
+{
+  "uniform": "biz-service",
+  "doc": "api/docs/governance/confirmations/biz-service-manifest.md §2",
+  "owner": "BIZ-general",
+  "blocking_severities": [
+    "boot",
+    "deploy"
+  ],
+  "verdict": {
+    "blocked": "NOT DEPLOYABLE",
+    "clear": "DEPLOYABLE",
+    "incomplete": "INCOMPLETE: {count} deploy row(s) not run ({ids}). Fix: run the uniform from the api checkout — npx oa-validate --workspace <workspace root>"
+  },
+  "discovery": {
+    "biz-service": {
+      "concern": "which directories wear this uniform, and who says they exist",
+      "pattern": "api_biz/*/package.json",
+      "from": {
+        "path": "api/config/services.json",
+        "list": "businessServices.services",
+        "key": "directory"
+      },
+      "rows": [
+        {
+          "id": "U-ORPHAN",
+          "check": "discovery-orphan",
+          "severity": "deploy",
+          "owner": "BIZ-general",
+          "why": "completeness is discovery: a directory no SSOT knows, or one that matches no pattern, wears no uniform and nothing checks it",
+          "fix": "declare the directory in api/config/services.json (businessServices.services[].directory), or remove it from api_biz/",
+          "doc": "api/docs/governance/confirmations/biz-service-manifest.md § Confirmation 20260909-biz-service-manifest-005"
+        },
+        {
+          "id": "U-IDENTITY",
+          "check": "ssot-identity",
+          "severity": "deploy",
+          "owner": "BIZ-general",
+          "why": "one service, one name: naming.md derives every spelling from a single short name, and the gateway compares service_code from the entitlement data against the service name in a cookbook step character by character - a second spelling is not untidiness, it is a request that is refused; directory, repo and container are the three spellings the SSOT owns, and this row reads the same reference U-ORPHAN does - the SSOT knows the directory, this asks whether it knows the service",
+          "fix": "make directory, repo and container in api/config/services.json read <shortname>, .../biz-<shortname> and api_service_<shortname>, where <shortname> is what the repository's config/service/config.json declares - or correct service.name if the SSOT is right",
+          "doc": "api/docs/biz/60-templates/naming.md"
+        }
+      ]
+    }
+  },
+  "files": {
+    "identical": [
+      {
+        "id": "F-INIT",
+        "check": "template-block",
+        "path": "init.sh",
+        "block": "oa-deps-guard v1",
+        "from": { "package": "templates/business-service/init.sh", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "one install decision for the whole platform; four versions of this block were measured across the repositories, and a copy is kept in sync by review only — this row is what api/tests/scripts/infra-init-scripts.bats already does for api/infra, reaching the biz repositories",
+        "fix": "npx oa-sync-template init.sh --target . — it splices the block and leaves this file's own oa_npm_install() untouched",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md §2"
+      },
+      {
+        "id": "F-JEST",
+        "check": "template-file",
+        "path": "jest.config.js",
+        "from": { "package": "templates/business-service/jest.config.js", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "how a suite is run is a platform decision, not a per-service one; eight of nine copies differed on 2026-09-09",
+        "fix": "npx oa-sync-template jest.config.js --target .",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md §2"
+      },
+      {
+        "id": "F-RUNNER",
+        "check": "compose-runner",
+        "path": "docker-compose.yml",
+        "block": "oa-test-runner v1",
+        "runner_memory": "1g",
+        "from": { "package": "templates/business-service/docker-compose.yml", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "suites run in the service's own one-shot runner, which shares its build, env and networks but never its memory budget — two loads in one cgroup killed the service mid-test; what it shares is compared against the service beside it, everything else against the template block",
+        "fix": "npx oa-sync-template docker-compose.yml --target . — it renders the block with this repository's build, env_file and networks, and inserts it under services: when the file carries none yet",
+        "doc": "api/docs/governance/confirmations/biz-test-container.md"
+      }
+    ],
+    "contains": [
+      {
+        "id": "F-GITIGNORE",
+        "check": "template-entries",
+        "path": ".gitignore",
+        "from": { "package": "templates/business-service/gitignore", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "every path this platform WRITES into a repository is a path git must not see, and the measured one is ci/deployability.json - oa-validate and the pre-push hook of confirmation 006 both write it, and in four of the eight services (converter, invoicing, meta, property) every run left it untracked while the template has carried the line since d.212. The class is contains and not identical because a repository ignores its own scratch directories too, and nine different files were measured across the eight; what has to be true here is a SET of paths, in any order, with every other line of the file left alone. A narrower pattern does not satisfy the entry it narrows: config/env-active/*.env leaves every non-.env file in a directory of live secrets committable",
+        "fix": "npx oa-sync-template .gitignore --target . - it appends the missing entries under one labelled block and rewrites nothing this repository wrote",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a72"
+      },
+      {
+        "id": "F-DOCKERIGNORE",
+        "check": "dockerignore-entries",
+        "path": ".dockerignore",
+        "from": { "package": "templates/business-service/gitignore", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "Dockerfile line COPY . . takes everything .dockerignore does not exclude, and being ignored by git excludes nothing: measured by BIZ-hello 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. A CI image is clean by accident, because a fresh checkout has no ignored file to copy, so the defect is invisible exactly where the image is built. The entries are DERIVED from the declaration .gitignore already reads rather than written a second time (change-discipline.md \u00a7 One rail per concern), and translated: a slash-less .gitignore pattern matches at every depth while a .dockerignore one is matched from the context root, so *.log there would catch debug.log and not logs/debug.log. The criterion is a comparison and never a list of directories - the files in /app of an image built from the working tree, node_modules aside, are the files of an image built from git archive HEAD",
+        "fix": "npx oa-sync-template .dockerignore --target . - it writes the derived entries under one labelled block and rewrites nothing this repository wrote",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a72"
+      }
+    ],
+    "own": {
+      "concern": "the files of the template whose CONTENT the service decides, and the reason each is not held to the platform's copy",
+      "why": "a file added to the template is a decision about who guards it, and this class is the decision written down: no row holds these to the template, because their content IS the service. Dockerfile is the exception that proves the rule - its one platform fact, the node major, is R-NODE's row, and everything else in it is this service's build. docs/README.md is the same decision for the map of the documentation tree: which branches a service has is the service's, and what the platform holds the tree to is not that prose but D-LINT, which asks the documentation lint whether the tree is clean. It is the map alone, not docs/ - the three installation documents under docs/80-setup/ ARE held to a skeleton, and a class covering them would exempt what a row requires. The class exists so that the completeness check of finding 18 has an answer other than silence for every file the template carries (automation-gates.md \u00a75)",
+      "allowed": [
+        "Dockerfile",
+        "index.js",
+        "package.json",
+        "src/",
+        "tests/",
+        "docs/README.md"
+      ],
+      "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a72"
+    },
+    "generated": [
+      {
+        "id": "G-PROD",
+        "check": "template-render",
+        "path": "docker-compose.production.yml",
+        "from": { "package": "templates/business-service/docker-compose.production.yml", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "one truth for the production topology: which networks the biz box has, which env files exist on it and what the image is called are facts of the platform, not of a service, so the file is RENDERED from the template and the service's name — measured 2026-09-10, the seven old-shape copies were byte-identical once the name was normalised, and adding or removing a service is then a scaffold plus an SSOT entry rather than a hand-written file",
+        "fix": "npx oa-sync-template docker-compose.production.yml --target .",
+        "doc": "api/docs/governance/confirmations/server-topology.md § Confirmation 20260910-server-topology-005"
+      },
+      {
+        "id": "G-CI",
+        "check": "delimited-block-render",
+        "path": ".gitlab-ci.yml",
+        "block": "oa-ci v1",
+        "from": { "package": "templates/business-service/.gitlab-ci.yml", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the platform half of a biz pipeline belongs to the platform, not to the service: it builds the same way, identifies the image by the FULL commit sha (R5), hands the deploy the digest CI itself pushed (R1/R2), and since confirmation 008 it runs the uniform gate before the SSH step - a service that edits any of that edits the gate that judges it. It is a BLOCK and not the whole file because the other half is genuinely the service's. Measured over the eight repositories on 2026-09-11: the template is 151 lines and 7 root keys, the services 176 to 198 lines and 9, and 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:. Which database and which gates an integration needs is a fact about the service. A whole-file fix would have deleted all of it and left eight integration tiers running against no database, which is a finding nobody can carry out (automation-gates.md §3, last bullet; controller finding 20)",
+        "fix": "npx oa-sync-template .gitlab-ci.yml --target .",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a7 Confirmation 20260910-biz-service-manifest-008"
+      },
+      {
+        "id": "G-PROD-IMAGE",
+        "check": "deploy-contract",
+        "requirement": "R1",
+        "path": "docker-compose.production.yml",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the production image is the one CI built and proved; a mutable tag makes the deploy nondeterministic and leaves a rollback no target",
+        "fix": "pin the image by digest: image: <repo>@${BIZ_IMAGE_DIGEST:?BIZ_IMAGE_DIGEST is required}",
+        "doc": "api/docs/operations/biz-rework-deployment-requirements.md"
+      },
+      {
+        "id": "G-README",
+        "check": "readme-uniform-current",
+        "path": "README.md",
+        "from": { "package": "manifests/biz-service.manifest.json", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "which uniform a repository wears, and which of its paths fall under which duty, is discoverability that is RENDERED from this manifest and never typed (005 point 2); a generated region with a generator and no gate goes stale the day a row moves, and nothing anybody runs on the repository says so",
+        "fix": "npx oa-sync-template readme-uniform --target .",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md § Confirmation 20260909-biz-service-manifest-005"
+      },
+      {
+        "id": "G-SETUP",
+        "check": "install-contract",
+        "requirement": "SETUP_DOCS",
+        "path": "docs/80-setup/",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "every repository carries the three installation documents an operator installs it from",
+        "fix": "add docs/80-setup/{INSTALL,PLATFORM_MATRIX,VALIDATION}.md; a repo on the older docs/setup/ branch renames it",
+        "doc": "api/docs/standards/repository-installation-sql-contract.md"
+      },
+      {
+        "id": "G-SETUP-INSTALL",
+        "check": "template-skeleton",
+        "path": "docs/80-setup/INSTALL.md",
+        "skeleton_only": true,
+        "from": { "package": "templates/business-service/docs/80-setup/INSTALL.md", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "an operator installs from the sections, not from the prose: a document missing \"Environment preparation\" leaves them to guess at the step, and the prose of every section is the service's own",
+        "fix": "npx oa-sync-template docs/80-setup/INSTALL.md --target . creates the document from the skeleton; an existing one gets the missing section added by hand, because its prose is this service's",
+        "doc": "api/docs/standards/repository-installation-sql-contract.md"
+      },
+      {
+        "id": "G-SETUP-MATRIX",
+        "check": "template-skeleton",
+        "path": "docs/80-setup/PLATFORM_MATRIX.md",
+        "skeleton_only": true,
+        "from": { "package": "templates/business-service/docs/80-setup/PLATFORM_MATRIX.md", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the matrix answers one question per platform the service is installed on; a section that is absent reads as a platform nobody has anything to say about",
+        "fix": "npx oa-sync-template docs/80-setup/PLATFORM_MATRIX.md --target . creates the document from the skeleton; an existing one gets the missing section added by hand",
+        "doc": "api/docs/standards/repository-installation-sql-contract.md"
+      },
+      {
+        "id": "G-SETUP-VALIDATION",
+        "check": "template-skeleton",
+        "path": "docs/80-setup/VALIDATION.md",
+        "skeleton_only": true,
+        "from": { "package": "templates/business-service/docs/80-setup/VALIDATION.md", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the document that says what a finished install must show is the one the owner found instructing a curl on a listener no biz service opens; its sections are what keep the answer complete",
+        "fix": "npx oa-sync-template docs/80-setup/VALIDATION.md --target . creates the document from the skeleton; an existing one gets the missing section added by hand",
+        "doc": "api/docs/standards/repository-installation-sql-contract.md"
+      }
+    ],
+    "tracked": [
+      {
+        "id": "X-IGNORED",
+        "check": "git-tracked",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "every file row above reads the WORKING TREE, and what reaches a clone, a CI checkout and the production image is what git TRACKS - measured 2026-09-10 on a copy of converter outside the repository: init.sh and jest.config.js added to .gitignore and left on disk gave F-INIT and F-JEST zero findings, and the same two files deleted (the state a clean clone is in) gave both, NOT DEPLOYABLE. Developer green, CI red, which is the class shared-working-tree.md already records one layer up. 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 (004 point 2). Measured 2026-09-11 over the eight services: zero violations, so the row lands with compliance rather than ahead of it (automation-gates.md \u00a73)",
+        "fix": "git add the file the finding names, and delete the .gitignore line covering it when the finding says one does",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a72"
+      }
+    ],
+    "forbidden": [
+      {
+        "id": "X-HOOKS",
+        "check": "file-absent",
+        "path": "hooks/pre-commit",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "owner 2026-09-05: deleted, weaker duplicate of the pre-push gate",
+        "fix": "rm -f hooks/pre-commit",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md §5"
+      },
+      {
+        "id": "X-PREVAL",
+        "check": "file-absent",
+        "path": "scripts/run-pre-validation.js",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "replaced by the library command: oa-biz-ci-gate run-prevalidation",
+        "fix": "rm -f scripts/run-pre-validation.js",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md §5"
+      },
+      {
+        "id": "X-DB-CONFIG",
+        "check": "file-absent",
+        "path": "src/config/database.js",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "owner 2026-09-10 (confirmation 009): a private connection factory beside @onlineapps/conn-base-db, which is the one factory",
+        "fix": "replace the importers with createSequelize from @onlineapps/conn-base-db and delete the file: rm -f src/config/database.js",
+        "doc": "api/docs/biz/70-contracts/database-contract.md \u00a710"
+      }
+    ]
+  },
+  "scripts": {
+    "concern": "how a suite is run, and what may never run without being named",
+    "required": [
+      {
+        "id": "S-TEST",
+        "check": "script-body",
+        "name": "test",
+        "body": "jest --config jest.config.js tests/unit --runInBand",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "one entry point to the unit suite, with the config and the worker count the platform runs it with",
+        "fix": "set scripts.test to the body this row names",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md §2"
+      },
+      {
+        "id": "S-ALL-C",
+        "check": "script-body",
+        "name": "test:all:container",
+        "body": "docker compose run --rm ${runner} npm run test:all",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the runner is the only rail a suite runs on; ${runner} is the compose service carrying profiles: [test], which is the one name that is per-repository",
+        "fix": "add scripts[\"test:all:container\"] wrapping the runner this repository declares",
+        "doc": "api/docs/governance/confirmations/biz-test-container.md"
+      },
+      {
+        "id": "S-INT-C",
+        "check": "script-body",
+        "name": "test:integration:container",
+        "body": "docker compose run --rm ${runner} npm run test:integration",
+        "only_with": "tests/integration",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the same rail for the integration suite, and only where there is one: 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",
+        "fix": "add scripts[\"test:integration:container\"] wrapping the runner this repository declares",
+        "doc": "api/docs/governance/confirmations/biz-test-container.md"
+      },
+      {
+        "id": "S-COOKBOOKS",
+        "check": "script-body",
+        "name": "test:cookbooks",
+        "body": "node node_modules/@onlineapps/conn-orch-validator/src/cli/biz-ci-gate.js run-prevalidation",
+        "bin": "oa-biz-ci-gate",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the cookbook run is the library's command; a per-service copy of it drifts from the library that owns the dispatch",
+        "fix": "set scripts[\"test:cookbooks\"] to the library command and delete the per-service script",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md §5"
+      }
+    ],
+    "forbidden": [
+      {
+        "id": "S-HOST",
+        "check": "script-forbidden",
+        "name": "test:host",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "owner biz-test-container 001: the runner is the only rail",
+        "fix": "remove scripts[\"test:host\"]; run the suite through test:all:container",
+        "doc": "api/docs/governance/confirmations/biz-test-container.md"
+      },
+      {
+        "id": "S-HOOKS",
+        "check": "script-implicit",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "a script that fires as a side effect of another command is invisible in the log that matters, and one whose target does not exist fires on nothing at all",
+        "fix": "delete the hook and call the script by name where it belongs",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md §2"
+      }
+    ]
+  },
+  "tooling": {
+    "concern": "the repository's own scripts/ \u2014 what a reader can learn about a script before running it",
+    "rows": [
+      {
+        "id": "S-SCRIPTS",
+        "check": "scripts-lint",
+        "path": "scripts/",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "a script nobody can understand is the failure this platform actually has: the five header fields say what it owns, how it is called, what it runs on and what its exit codes mean, and the two closed vocabularies keep a parseable-but-foreign value from reading as an answer \u2014 measured 2026-09-10 over the eight services, 86 scripts carry no header at all, and the rules had until then lived in a file of the api checkout, which a service image does not have",
+        "fix": "write the five header fields the finding names, in the order SCRIPTS-STANDARD \u00a71 gives them, immediately after the shebang; the lint's own message says which field it expected where",
+        "doc": "api/docs/standards/SCRIPTS-STANDARD.md"
+      }
+    ]
+  },
+  "config": {
+    "concern": "the files a service is configured by, and the declarations they must carry",
+    "applies_to": "*",
+    "required": [
+      {
+        "id": "C-IDENTITY",
+        "check": "service-identity",
+        "path": "docker-compose.yml",
+        "production_path": "docker-compose.production.yml",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "one service, one name: naming.md derives every spelling from a single short name, and the gateway compares service_code from the entitlement data against the service name in a cookbook step character by character - a second spelling is not untidiness, it is a request that is refused; measured 2026-09-10, one of the eight services wears four names and nothing said a word - this row holds every spelling INSIDE the repository (npm name, container_name in both composes, the env template and the env_file loading it, the database schema where one is declared) to the short name config/service/config.json declares",
+        "fix": "spell every one of them after the short name in config/service/config.json: npm name biz-<shortname>, container_name api_service_<shortname>, config/env-templates/<shortname>.env loaded as <shortname>.env, database.schema oagen_<shortname>",
+        "doc": "api/docs/biz/60-templates/naming.md"
+      },
+      {
+        "id": "C-SERVICE",
+        "check": "config-service",
+        "path": "config/service/config.json",
+        "severity": "boot",
+        "owner": "BIZ-general",
+        "why": "the three keys of this file a reader demands: service.name is the identity the platform knows the service by, service.workspaceScoped decides whether it must implement list-workspaces and the wrapper refuses to boot without an explicit boolean, service.specificationEndpoint is published in the service specification",
+        "fix": "declare service.name, service.workspaceScoped (an explicit true/false) and service.specificationEndpoint in config/service/config.json",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a72"
+      },
+      {
+        "id": "C-OPS",
+        "check": "config-operations",
+        "path": "config/service/operations.json",
+        "severity": "boot",
+        "owner": "BIZ-general",
+        "why": "the v3 dispatch table; the per-operation rules (handler, bundle_scope, forbidden v2 fields) are step 4 of the boot validation, which this row does not repeat",
+        "fix": "declare the service's operations in config/service/operations.json",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a72"
+      },
+      {
+        "id": "C-CONTRACT",
+        "check": "config-contract",
+        "path": "config/service/integration-contract.json",
+        "severity": "boot",
+        "owner": "BIZ-general",
+        "why": "the first file every platform gate reads: the connectors, the database, the env declaration and the integration minimum; the row does not restate its rules, it calls the validator that owns them (utils/bizCiGateContract.js), so the CI gate and this table can never disagree about the same document",
+        "fix": "add config/service/integration-contract.json, or repair the declaration the message names; the template in this package carries the shape",
+        "doc": "api/docs/biz/70-contracts/env-contract.md"
+      },
+      {
+        "id": "C-CONNECTORS",
+        "check": "connector-contract",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "a service declares its connections twice — config/service/config.json configures wrapper.cache / wrapper.state / wrapper.mq, config/service/integration-contract.json declares requiredConnectors — and the two describe one fact; while they disagree ci:gate:wait does not wait for a connector the service needs and the suite races it, which is how biz-converter shipped requiredConnectors.db=false while owning six migrations. The comparison has existed at boot since F12 and had no consequence there: the finding went into results.warnings, the service started, and no CI job ran it at all. This row is what acts on it (confirmation connector-contract-check 001); the boot keeps reporting and keeps starting. The environment half of that check — is REDIS_URL set — stays at boot, where an environment exists; this row asks only what a checkout can answer",
+        "fix": "make the two declarations agree: set requiredConnectors.<connector> to what the service really needs, or add the wrapper section that configures it / remove the one nothing requires",
+        "doc": "api/docs/governance/confirmations/connector-contract-check.md"
+      },
+      {
+        "id": "C-SERVICE-DEAD",
+        "check": "config-dead-keys",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "service.version (ConfigLoader overwrites it from package.json on every load), service.port (a biz service binds none), wrapper.registry.url (d.244: registration travels over MQ to registry.register and discovery reads the Redis projection, confirmation biz-discovery-redis 002), wrapper.tenantContext (its only consumer createTenantContextMiddleware and the runtime default were deleted in b5e36431, confirmation wrapper-tenant-middleware 001) and contractVersion have no reader anywhere in the platform; service.url joins them from wrapper 8.0.0 and not before \u2014 the published 7.0.0 still throws \"Missing configuration - service.url is required\", so that key travels WITH the pin (confirmation biz-service-port-url 001) and a rule claiming it has no reader today would send a service into a failed boot; a required-looking declaration nothing consumes tells the next author something depends on it, and every new service copies it forward",
+        "fix": "delete the key from the file that declares it",
+        "doc": "api/docs/governance/confirmations/biz-service-port-url.md"
+      },
+      {
+        "id": "C-ENV",
+        "check": "env-templates",
+        "path": "config/env-templates",
+        "severity": "boot",
+        "owner": "BIZ-general",
+        "why": "one platform template and one of the service's own, so a key has exactly one home; what the service's file is CALLED is the scaffold's rename, tested by api/tests/scripts/add-service.bats",
+        "fix": "keep config/env-templates/shared.env and exactly one <service>.env beside it",
+        "doc": "api/docs/biz/70-contracts/env-contract.md"
+      },
+      {
+        "id": "G-SHARED-ENV",
+        "check": "shared-env-generated",
+        "path": "config/env-templates/shared.env",
+        "from": { "package": "templates/business-service/config/env-templates/shared.env", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the shared key set is one fact with one owner; measured on 2026-09-09, none of the nine copies matched the platform file and one key existed in no copy at all. The owner is still api/config/shared-env.json: what this row reads is the render this package carries, kept equal to that manifest by the packaged template's own gate, so the row also answers inside a service container, where api/config/ is not there",
+        "fix": "npx oa-sync-template shared-env --target .",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a718"
+      },
+      {
+        "id": "C-ENV-READS",
+        "check": "env-contract",
+        "severity": "boot",
+        "owner": "BIZ-general",
+        "why": "an environment name the code reads and nothing declares is a key that is missing on the day the service moves, and nobody can say what it was for",
+        "fix": "declare the name in config/service/integration-contract.json under env.required or env.optional, each with its why",
+        "doc": "api/docs/biz/70-contracts/env-contract.md"
+      }
+    ]
+  },
+  "runtime": {
+    "concern": "what the service is allowed to be at run time — the platform's numbers, not this service's preferences",
+    "rows": [
+      {
+        "id": "R-NODE",
+        "check": "node-major",
+        "from": { "package": "package.json", "text": true },
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "R3 of the deploy contract compares CI, Dockerfile and engines.node against each other, so a service that is consistently on an older major is green there; this row is the comparison against the platform major, read from the engines.node of @onlineapps/conn-orch-validator itself - the library uniform's L-ENGINES holds that field equal to api/.nvmrc, so it is a checked projection of the SSOT and not a second copy of it, and it travels with the pin into the container and the service's own CI, where api/.nvmrc does not exist",
+        "fix": "build on the platform node major and declare the same range in engines.node - the number is api/.nvmrc, and node_modules/@onlineapps/conn-orch-validator/package.json carries it wherever the package is installed",
+        "doc": "api/docs/governance/confirmations/node-runtime-version.md"
+      },
+      {
+        "id": "R-MEM",
+        "check": "memory-limit",
+        "path": "docker-compose.yml",
+        "production_path": "docker-compose.production.yml",
+        "service_memory": "512M",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the platform norm for a resident biz service, in dev and in production alike; the runner's own budget is F-RUNNER's row, because the split is the point",
+        "fix": "set deploy.resources.limits.memory to 512M in both compose files",
+        "doc": "api/docs/governance/confirmations/biz-memory-limits.md"
+      },
+      {
+        "id": "R-PID1",
+        "check": "compose-command",
+        "path": "docker-compose.yml",
+        "service_command": "node index.js",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "PID 1 decides whether a stop is a shutdown or a kill: with command: [\"npm\",\"start\"] the process the container signals is npm, which does not forward SIGTERM, so docker waits its ten seconds and SIGKILLs a service that never closed a channel. Confirmation biz-compose-pid1 001 settled the substance and 002 settled the delivery - it is not a per-repo choice but part of the uniform biz service shape, so it is a row here rather than a sentence eight threads have to remember. Measured 2026-09-14 over the eight dev composes: six say npm, two say node. The one-shot test runner is outside this row - it declares no command because docker compose run supplies one, and its shape is F-RUNNER's",
+        "fix": "in docker-compose.yml set the service block's command to [\"node\", \"index.js\"] (the entrypoint init.sh execs it, so node becomes PID 1), then recreate the container and smoke it",
+        "doc": "api/docs/governance/confirmations/biz-compose-pid1.md"
+      },
+      {
+        "id": "R-PORTS-DEV",
+        "check": "compose-no-ports",
+        "path": "docker-compose.yml",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "R4 refuses a published port in the production compose and never reads the dev one, where a scaffolded service used to publish by default",
+        "fix": "remove the ports block from docker-compose.yml",
+        "doc": "api/docs/biz/00-model/service-shape.md"
+      },
+      {
+        "id": "R-PORTS",
+        "check": "deploy-contract",
+        "requirement": "R4",
+        "path": "docker-compose.production.yml",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "docker publishes past the firewall, so a published port is reachable from the internet; the only public entrypoint is doorman",
+        "fix": "remove the ports block from docker-compose.production.yml",
+        "doc": "api/docs/operations/biz-rework-deployment-requirements.md"
+      }
+    ]
+  },
+  "db": {
+    "concern": "whether this service has a database, and whether the repository agrees with what it declared",
+    "rows": [
+      {
+        "id": "D-DB-CONSISTENT",
+        "check": "db-consistent",
+        "forbidden_packages": ["mysql2", "mariadb", "sequelize", "pg"],
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "a contract that disagrees with the repository sends the installer the wrong way in both directions: nothing to install where a database was promised, and an unmanaged schema where none was declared",
+        "fix": "make requiredConnectors.db agree with the repository: add migrations/, or drop the declaration and the database client",
+        "doc": "api/docs/governance/confirmations/biz-service-manifest.md \u00a7 Confirmation 20260909-biz-service-manifest-005"
+      },
+      {
+        "id": "D-DB-COLLATION",
+        "check": "db-collation",
+        "path": "config/service/integration-contract.json",
+        "key": "collation",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "owner 2026-09-14: the collation a schema is created with is the service's own declaration, and the CI gate and the production runbook read the same key - without it each of them invents one, which is how six schemas came to carry the image default utf8mb4_general_ci while every table inside them declares utf8mb4_bin or utf8mb4_unicode_ci (measured 2026-09-14: 122 of 123 permanent tables declare their collation explicitly). The row asks only whether the key is THERE: whether the value is a collation name is the contract validator's rule, which C-CONTRACT calls, and refusing to build without it is the setup-db gate's - a row restating either would be the duplicate that already cost D-DB-DECL its place. It reads the database block rather than requiredConnectors.db, because the block is what the gate builds from",
+        "fix": "add \"collation\" to the \"database\" block of config/service/integration-contract.json - the collation this service's tables already declare, e.g. \"utf8mb4_bin\"; the CI gate then creates the schema with it and refuses one created with another",
+        "doc": "api/docs/biz/70-contracts/database-contract.md \u00a7 1"
+      },
+      {
+        "id": "D-DB-PACKAGE",
+        "check": "install-contract",
+        "requirement": "SQL_PACKAGE",
+        "path": "migrations/",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "a service with a database is installed from its own SQL package; an absent or empty one makes a fresh install undefined",
+        "fix": "create migrations/BASELINE and migrations/SEED/{production_like,test_only} with their SQL files",
+        "doc": "api/docs/standards/repository-installation-sql-contract.md"
+      },
+      {
+        "id": "D-DB-NAMING",
+        "check": "db-migration-naming",
+        "path": "migrations/",
+        "naming": "^\\d{3}_[a-z][a-z0-9]*(?:_[a-z0-9]+)*\\.sql$",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "what a migration is called is the only thing a reader has before opening it and the only thing the install order depends on. The shape is not this row's to invent: database-contract.md \u00a75 owns it, and the row reads that shape back - three digits, an underscore, a lowercase description, no second word demanded, which is why 000_baseline.sql is a name and not a finding (\u00a78 makes a regenerated baseline an applied migration). No leading verb is demanded either, because the measured counter-example is right - converter's 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 migrations/*.sql and stops there: what BASELINE/ and SEED/** must carry is the installation contract's \u00a74, which D-DB-HEADERS already checks, and that contract names no shape for their file names at all",
+        "fix": "rename the file to the shape database-contract.md \u00a75 prescribes - three digits, an underscore, the subject in lowercase snake_case; keep the ordinal the package is already installed in order of",
+        "doc": "api/docs/biz/70-contracts/database-contract.md \u00a7 5"
+      },
+      {
+        "id": "D-DB-README",
+        "check": "db-readme",
+        "path": "migrations/README.md",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the installation contract \u00a73 asks a repository with a database for four things, and D-DB-PACKAGE's SQL_PACKAGE requirement checks three of them - the BASELINE and the two SEED directories. The fourth is this document, the documented execution order that reproduces a working instance (\u00a75 point 4), and until this row nothing looked for it",
+        "fix": "add migrations/README.md saying in which order the package is run and what a finished install shows",
+        "doc": "api/docs/standards/repository-installation-sql-contract.md"
+      },
+      {
+        "id": "D-DB-ACCOUNT",
+        "check": "db-account",
+        "path": "config/env-templates",
+        "key": "DB_USER",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "owner 2026-08-28: every service reaches the database as its own account with grants on its own schemas, and root stops being an operational identity - it was the identity of nine containers across eight repositories, so rotating it was a cross-repo batch nobody could run. The name is the SAME derivation C-IDENTITY holds database.schema to, read from the same file with the same prefix, so the account and the schema cannot drift into two spellings of one service. A repository that declares a database and no DB_USER is a finding and not a silence: an account nobody declared is one somebody invents at install time",
+        "fix": "set DB_USER in this service's env template to oagen_<shortname>, where <shortname> is what config/service/config.json declares; the account and its grants are created by the operator installing the schema",
+        "doc": "api/docs/governance/confirmations/db-accounts-per-service.md"
+      },
+      {
+        "id": "D-DB-HEADERS",
+        "check": "install-contract",
+        "requirement": "SQL_HEADERS",
+        "path": "migrations/",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "test data that reads as production-safe is the one mistake that reaches a real database",
+        "fix": "add the Dataset-Class, Target-DB, Safe-For-Production and Idempotency headers to the SQL file the finding names",
+        "doc": "api/docs/standards/repository-installation-sql-contract.md"
+      }
+    ]
+  },
+  "docs": {
+    "concern": "what this service's own documentation tree may not say; every rule is the documentation lint's own, cited by id and never restated here",
+    "applies_to": "*",
+    "tree_config_row": "C-LINT",
+    "required": [
+      {
+        "id": "C-LINT",
+        "check": "file-present",
+        "path": "config/biz-docs-lint.tree.json",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the documentation lint refuses to run over a tree that declares no budget of its own, so a tree without this file is linted by nothing; the rows below are invoked with the budget this row's path names, which is why the path is written once and read from here",
+        "fix": "add config/biz-docs-lint.tree.json; node_modules/@onlineapps/conn-orch-validator/templates/business-service/config/biz-docs-lint.tree.json carries the shape",
+        "doc": "api/docs/biz/DOC-STANDARD.md"
+      }
+    ],
+    "rules": [
+      {
+        "id": "D-PORT",
+        "check": "docs-lint",
+        "rule": "F002:http-ports",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "no biz service listens on a port, so a document telling an operator to curl one sends them to a dead address and the install reads as broken; the ban carries a probe into the compose files, so it switches itself off the day a service does publish a port",
+        "fix": "delete the localhost:33xxx address from the document and say what the reader checks instead (the queue, the registry entry); node_modules/@onlineapps/conn-orch-validator/templates/business-service/docs/80-setup/VALIDATION.md carries the shape",
+        "doc": "api/docs/biz/00-model/service-shape.md"
+      },
+      {
+        "id": "D-NPM",
+        "check": "docs-lint",
+        "rule": "L016",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "an npm script a live document tells the reader to run, and the repository does not declare, is an instruction nobody can carry out; L016 resolves a cited name against the package.json above this tree, which for a service repository is exactly one file",
+        "fix": "cite the script this repository's package.json declares, or delete the instruction",
+        "doc": "api/docs/biz/DOC-STANDARD.md"
+      },
+      {
+        "id": "D-SCRIPT",
+        "check": "docs-lint",
+        "rule": "L007",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "a cited script that is not there is an instruction nobody can carry out; L007 resolves a bare scripts/... citation against THIS repository and an api/scripts/... one against the api checkout, so the row reaches both halves",
+        "fix": "correct the path the finding names, or delete the citation when the script is gone",
+        "doc": "api/docs/biz/DOC-STANDARD.md"
+      },
+      {
+        "id": "D-RETIRED",
+        "check": "docs-lint",
+        "rule": "F002",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "a retired concept taught by a live document sends the next author back to it; the words and their probes are the lint's banned_tokens, which this row cites and never copies (004 point 2) — D-PORT claims the one of them the owner gave its own fix sentence",
+        "fix": "rewrite the sentence in the terms the register names as the replacement; a document recording history rather than instructing belongs under 80-decisions/ or 90-migration/, where the ban does not apply",
+        "doc": "api/docs/biz/RETIRED-VOCABULARY.md"
+      },
+      {
+        "id": "D-HEADER",
+        "check": "docs-lint",
+        "rule": "S001,S002",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the two header lines are what make a tree navigable and a fact attributable: Parent: is the only way up, and Owns: is the sentence saying which fact this node — and no other — answers for",
+        "fix": "open the document with Parent: [text](link) on line 1 and Owns: <one line> on line 2 (DOC-STANDARD rule 5)",
+        "doc": "api/docs/biz/DOC-STANDARD.md"
+      },
+      {
+        "id": "D-LINT",
+        "check": "docs-lint-clean",
+        "severity": "deploy",
+        "owner": "BIZ-general",
+        "why": "the documentation lint reports nothing over this service's tree; the rows above name the five classes the owner gave a fix sentence of their own, and every OTHER finding the lint raises lands here — measured 2026-09-09 over the eight repositories, 80 findings of which 16 fell to a row, so a tree the documentation gate called broken came back deployable (automation-gates.md §5). The row cites no rule id, because a 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 (004 point 2: the manifest cites, it never restates). It counts only what the LINT graded error — the set its own --severity error prints — so a rule BIZ-DOCS adds at warn is visible in their run and blocks no deploy until they raise it on their dated transition, which is how a gate lands with compliance rather than ahead of it (automation-gates.md §3)",
+        "fix": "repair what the finding names, in the terms DOC-STANDARD sets for that rule; node scripts/ci/lint-biz-docs.mjs --root <service>/docs --tree-config <service>/config/biz-docs-lint.tree.json --skip-code-rules prints the same line",
+        "doc": "api/docs/biz/DOC-STANDARD.md"
+      }
+    ]
+  }
+}