@onlineapps/mq-client-core 4.2.0 → 5.1.0

package/CHANGELOG.md

@@ -4,6 +4,751 @@ All notable changes to this package. Follows [Keep a Changelog](https://keepacha
 
 ## [Unreleased]
 
+## [5.1.0] — 2026-10-03
+
+### Added
+
+- `publish(queue, message, { bufferOnFailure: false })` — volba pro jedno volání: zpráva, jejíž
+  publikace selhala přechodně (vyčerpané pokusy, `publishRetryEnabled: false`, selhaný reconnect,
+  na který retry čekal), se NEuloží do bufferu, takže ji žádný reconnect znovu neodešle. Výchozí
+  `true` = chování beze změny. Pro volajícího, který zprávu drží trvale jinde (orchestrátor,
+  `publish_pending`, conf `step-publish-failure` 001; d.1122). Hodnota jiná než boolean se
+  odmítne `ValidationError` před prvním pokusem.
+- Chyba ze tří přechodných cest nese `buffered` (boolean) — na chybě `PublishLayer` i na obalu
+  `PublishError` z `BaseClient.publish()`: `true` jen když buffer zprávu opravdu drží. Trvalé
+  odmítnutí `buffered` nenese. Věta `Fix:` chyby už neslibuje „is buffered“ tam, kde zpráva
+  v bufferu není (volba `false`, nebo buffer zprávu nepřijal).
+- Chyba publishe nese `sent` (boolean) — zda rámec zprávy OPUSTIL klienta (`sendToQueue()` /
+  `publish()` kanálu vrátil bez výjimky), vedle `buffered` z d.1122: na obalu `PublishError`
+  z `BaseClient.publish()` i na chybě `PublishLayer` (`true`, když ho odeslal KTERÝKOLI pokus
+  volání); chyba jednoho pokusu transportu (`_publishOnce()`) nese `sent` toho pokusu. Záznam
+  bufferu nese totéž. Neříká nic o tom, zda broker zprávu uložil: při memory alarmu broker
+  odeslané rámce doručí sám po jeho zrušení (d.1143: 3 kopie publishe na exchange, 1 kopie
+  prvního publishe do fronty, 0 u neodeslaného). Rozhodnutí vlastníka
+  `docs/governance/confirmations/mq-publish-buffer.md` 001 (D); orchestrátor ho kopíruje do
+  záznamu `publish_pending` (`step-publish-failure` 003). Chyba transportu bez booleovského
+  `sent` je vada souseda: `PublishLayer` ji odmítne jménem a zprávu nebufferuje (d.1145).
+
+### Changed
+
+- Každé čekání na odpověď brokera má limit `brokerAnswerTimeout` — jedna kolej, žádný nový klíč
+  (rozhodnutí vlastníka, `docs/governance/confirmations/mq-broker-answer-budget.md` 001, verdikt A;
+  d.1135). Dosud ho mělo jen potvrzení publishe a `close-ok` při `disconnect()`; `assertQueue`,
+  `checkQueue` (veřejné i kontrola před publishem do fronty), `bindQueue`, `assertExchange`,
+  `purgeQueue`, `deleteQueue`, `consume`, `cancelConsumer`, prefetch a otevření kanálu
+  (`createChannel` / `createConfirmChannel`, při `connect()`, obnově i reconnectu) čekaly bez
+  limitu. Změřeno d.1126 na izolovaném brokeru platformního obrazu: při alarmu paměti (spojení
+  žije, heartbeat teče) visela po 300 s, u zmrazeného brokeru je ukončil až heartbeat po ~90 s.
+  Co se mění pro volajícího — hodnotami:
+  - volání, na které broker v limitu neodpoví, skončí po `brokerAnswerTimeout` chybou
+    `ConnectionError` s větou `The broker did not answer <operace> <cíl> within
+    brokerAnswerTimeout (<N>ms)`; kanál, který požadavek nesl, se vyřadí a příští operace otevře
+    nový (kanál, který broker otevře až po limitu, se hned zavře);
+  - publish do fronty, jehož kontrola `checkQueue` (nebo obnova kanálu) nedostala odpověď, je
+    přechodné selhání: `TransientPublishError` → retry → buffer, s `bufferOnFailure: false`
+    `PublishError(cause=TransientPublishError)` a `buffered: false` (D2, conf
+    `step-publish-failure` 001);
+  - holé `Channel ended, no reply will be forthcoming` z amqplibu (kanál nebo spojení skončilo
+    dřív, než broker odpověděl) se na těchto voláních vrací jako `ConnectionError` s původní
+    chybou v `cause`; číslované odmítnutí brokera (404, 406, …) zůstává beze změny;
+  - `connect()`, jemuž broker neodpoví na otevření kanálu, skončí do limitu a zavře spojení
+    v témže limitu (neodpovězené zavření zahodí socket jako `disconnect()`).
+  Heartbeat, potvrzení publishe a teardown beze změny.
+- Klient poslouchá `blocked`/`unblocked` svého spojení (broker v memory/disk alarmu blokuje
+  spojení, které publikuje; d.1143 změřil na obrazu platformy). `blocked` = `warn` s důvodem
+  brokera; `unblocked` = `warn` a flush bufferu jednou kolejí `PublishLayer.flushBuffered('unblocked')`:
+  znovu se pošle JEN záznam, jehož rámec nikdy neopustil klienta; záznam s `sent: true` se vyřadí
+  s `warn` (fronta/exchange, stáří v bufferu), protože broker podržené rámce po alarmu doručí sám.
+  Flush po reconnectu beze změny — `flushBuffered('reconnected')` pošle všechno. Změřeno na
+  izolovaném brokeru d1145-rmq: po uvolnění alarmu u brokera 3 kopie odeslaného publishe na
+  exchange (beze změny, žádná navíc), 1 kopie odeslaného prvního publishe do fronty (beze změny)
+  a nově 1 kopie publishe, který se neodeslal (dřív 0 a tichá expirace); buffer po uvolnění
+  prázdný (dřív 2 a 1). Rozhodnutí vlastníka `docs/governance/confirmations/mq-publish-buffer.md`
+  001 (D), d.1145.
+- `PublishLayer.flushBuffered(trigger)` — jediný argument je nově POVINNÝ spouštěč
+  `'reconnected'` | `'unblocked'` (rozhoduje, co se stane se záznamem, jehož rámec už odešel);
+  jiná hodnota se odmítne jménem. `InMemoryBuffer.flush(flushFn, { sentEntries })` totéž
+  (`'resend'` | `'drop'`). Uvnitř balíčku jediný volající je transport (d.1145).
+  Druhý argument `flushOptions` (slučoval se do voleb každé znovu poslané zprávy) je PRYČ:
+  nikdo ho nepředával (0 volajících v `shared/**`, `infra/**`, `api_biz/*/src`); znovu poslaná
+  zpráva nese přesně volby, se kterými ji buffer držel (d.1145).
+- Vypršení zprávy v bufferu je `error`, ne `info`: jeden řádek na cíl (fronta nebo exchange)
+  a hodnotu `sent`, s počtem, stářím nejstarší a TTL; `sent=false` = zpráva je ZTRACENÁ,
+  `sent=true` = broker ji mohl doručit sám. Dřív „Removed N expired buffered messages“ bez
+  fronty i stáří. Rozhodnutí vlastníka `docs/governance/confirmations/mq-publish-buffer.md`
+  001 (D), d.1145.
+- Publish, jehož potvrzení ještě čekalo, když broker zavřel spojení nebo kanál (`320
+  CONNECTION_FORCED`, restart či stop brokeru, výpadek spojení), končil `PermanentPublishError`
+  bez bufferu a bez retry — zpráva byla ztracena, ač o ní broker nic neřekl (měřeno d.1126).
+  Příčina: amqplib odpovídá nepotvrzeným publishům `Error('channel closed')` ze svého `close`
+  posluchače registrovaného v konstruktoru kanálu, tedy DŘÍV, než klient kanál označil za
+  mrtvý; callback pak četl živý kanál. Klientův `close` posluchač send kanálu se nyní
+  registruje `prependListener` a běží první, takže tahle cesta je přechodná
+  (`TransientPublishError`) a jde dnešní cestou retry/buffer, včetně `bufferOnFailure: false`
+  (`buffered: false`). `nack` brokeru a číslovaný close frame této zprávy zůstávají trvalé
+  (d.1134).
+- Hláška `PublishError` větve fronty při zavření kanálu s čekajícím potvrzením tvrdila „and not
+  reconnecting“ — v S3 nepravda: spojení v tu chvíli ještě neohlásilo `close` a reconnect
+  následuje. Nově: „Channel closed during publish to queue "<q>" before the broker confirmed the
+  message …“, bez tvrzení o reconnectu, `Fix:` odkazuje na `error.buffered` (d.1134).
+- Re-registrace konzumentů po obnově kanálu se ptá na živost konzumentského kanálu před KAŽDÝM
+  konzumentem (a znovu po kroku fronty), ne jednou před smyčkou. Kanál, který zemřel uprostřed
+  smyčky (zavřel ho broker, nebo ho vyřadil `brokerAnswerTimeout`, d.1135), dřív vedl
+  u dalšího konzumenta na `TypeError: Cannot read properties of null (reading 'consume')`
+  a na zbytečnou deklaraci jeho fronty. Nově `ConnectionError` „Cannot re-register the consumer
+  of <q>: consumer channel is not available …“ v `consumer:re-registration:failed`; konzument
+  zůstává sledovaný bez tagu a obnoví ho příští obnova, jako dosud (d.1138).
+- Hláška `_waitForReconnection()` po vypršení jmenovala env `RABBITMQ_RECONNECT_WAIT_TIMEOUT`,
+  který nic nečte. Nově jmenuje, co se čte: klíč konfigurace `reconnectWaitTimeout` („set in the
+  client configuration“), nebo odvození `max(60000, maxReconnectAttempts × reconnectMaxDelay)`,
+  když klíč zadaný není; `Fix:` odkazuje na tentýž klíč. Chování beze změny (d.1138).
+- Přechodná chyba cesty publishe (`_publishPathTransient()`) tvrdila „queue channel is not
+  available (connection may be closed)“ i při ŽIVÉM spojení blokovaném memory alarmem (d.1143,
+  nález 3; od d.1135 končí touto chybou i neodpovězená kontrola `checkQueue`). Věta se nově
+  volí ze stavu klienta: zavřené spojení → „the connection is closed“; blokované → „the broker
+  has blocked this connection (reason: …)“; jinak „the queue channel is not available on a
+  live, unblocked connection“ s příčinou v `error.cause`. Třída beze změny (d.1145).
+
+### Fixed
+
+- Spojení, které obnova navázala až po `disconnect()` volajícího, se zavírá v rozpočtu
+  `brokerAnswerTimeout` (`_closeWithinTeardownBudget()`, jedna kolej, conf
+  `mq-broker-answer-budget` 001). Dřív `await revived.close()` bez limitu: broker, který v tu
+  chvíli neodpovídal, držel kolo obnovy (`_reconnecting: true`) a socket otevřené navždy.
+  Neodpovězené zavření nově zahodí socket jako teardown (d.1138).
+
+### Documentation — JSDoc a popis klíče na pravdu, docblock jedné koleje `workflow_initiated` bez smazané cesty (d.1134, d.1138, d.1176)
+
+- JSDoc `workflowIdOf()` tvrdil, že alias `workflowId` dosud píše webhook submit gatewaye.
+  Nepravda: žádný producent v `shared/**` ani `infra/**` alias nepíše (hlavičky gatewaye nesou
+  jen `workflow_id`, `infra/api_gateway/shared/workflowMessageHeaders.js`); čtení aliasu
+  v transportu neexistuje od d.416, chování beze změny (d.1134).
+- Popis klíče `heartbeat` v `configSchema.js` na pravdu: hodnota se navrhuje brokeru v URL
+  spojení (ne „předává se amqplibu“) a `0` heartbeat NEVYPNE — vyjednávání amqplibu vezme
+  stranu, která limit stanoví, tedy hodnotu brokera (změřeno d.1126: pauza zjištěna po 179 s).
+  Chování beze změny (d.1138).
+- Docblock `src/monitoring-initiated.js` popisuje rozhodnutí o jedné koleji události
+  `workflow_initiated` (conf `scheduler` 009 a 024) bez cesty na smazaný soubor gatewaye
+  a bez vyprávění o kopiích, které to rozhodnutí rušilo; chování beze změny (d.1176).
+
+### Tests — sady bez nástěnného času a s pravdivým popisem bloku (d.1174, d.1138)
+
+- Test, ne chování: sada `connect-timeout-closes-late-handshake.test.js` čekala nástěnný čas
+  (`connectTimeout` 20 ms, pak `setTimeout` 80 ms na druhý pokus reconnectu) a pod zátěží runneru
+  `oa-staging` (pipeline 2904670335) četla `amqp.connect` 2× místo 3×, proto hodiny teď řídí
+  test (`jest.useFakeTimers()` + `advanceTimersByTimeAsync`) a výsledek nezávisí na zátěži
+  stroje (d.1174).
+- Popis bloku testu `connection-parameters-reach-the-broker.test.js` („…one name for its two
+  consumers“) srovnán s d.1135: budget `brokerAnswerTimeout` platí pro každé čekání na odpověď
+  brokera, ne pro dva konzumenty (d.1138).
+- Test, ne chování: akceptační sada čekací koleje `waiting-helper.test.js` měřila vzorkování
+  `waitForValue`/`waitForEvent` na nástěnných hodinách a pod loadem 17–30 (pre-K sweep
+  `release/w4`) vzorek rastru 20 ms zpožděný o víc než 40 ms minul okno 150–190 ms, takže
+  „s `pollMs: 20` tentýž stav VIDÍ" četl `true`; hodiny teď řídí test (`jest.useFakeTimers()`
+  + `advanceTimersByTimeAsync`, čas čte `jest.now()`); hodnoty a počty v tvrzeních beze změny,
+  podlahy pauzy přesně podle pravidla, bez rezervy na plánovač; kolej `tests/waiting.js`
+  nedotčena (d.1192).
+
+## [5.0.0] — 2026-09-27
+
+### Removed — BREAKING — fronta `workflow.control` (d.1061)
+
+Sekce `workflow` v `src/config/queueConfig.js` už nedeklaruje položku `control` (TTL 30 s,
+max 10 000, DLX → `workflow.failed`). Rozhodnutí vlastníka:
+`docs/governance/confirmations/cookbook-execution-owner.md` 002.
+
+Co to znamená pro volajícího — hodnotami, ne větou:
+
+- `queueConfig.getInfrastructureQueueConfig('workflow.control')` a
+  `queueConfig.getDeadLetterRoute('workflow.control')` hází
+  `[queueConfig] Infrastructure queue config not found: workflow.control …`;
+- `queueConfig.queueName('workflow', 'control')` hází
+  `[queueConfig] Cannot compose a name: queueConfig declares no "control" under "workflow" …`,
+  takže publikace na to jméno se odmítne dřív, než cokoli odejde;
+- konzument, který frontu dosud kontroloval při startu, ji v deklaraci nenajde.
+
+Co se **nemění**: `workflow.init` (deklarace, jméno, trasa do `workflow.failed`) a
+`workflow.failed` jako konec řetězu, který `workflow.init` jmenuje. Počty deklarací klesly
+o jednu frontu (36 položek / 29 front / 7 exchange); křížový součin prefix × šablona se
+nemění, prefix `workflow` zůstává.
+
+Odebrání deklarace frontu z běžícího brokeru nesmaže (fronta je durable) — to je krok
+nasazení, ne knihovny.
+
+### Tests — `workflow.control` není deklarovaná (d.1061)
+
+Nová sada `tests/unit/workflow-control-queue-not-declared.test.js` tvrdí nepřítomnost
+hodnotami (žádný klíč `control`, tři odmítnutí se jménem fronty) a kontrolní případy
+`workflow.init` a `workflow.failed`. Případy, které `workflow.control` používaly jako
+deklarovanou frontu (`queueConfig-workflow-failed`, `dead-letter-topology`,
+`consume-dead-letter-route-required`, `consume-terminal-queue`), ji už nejmenují; počty
+deklarací v `queue-name-collision` a `d712-registry-changes-exchange-type` jsou srovnané.
+
+### Documentation — README: příklad publikace na `workflow.control` nahrazen `workflow.completed` (d.1061)
+
+### Fixed — `getChannelState()` hlásí i telemetrický kanál (d.1007)
+
+`getChannelState()` hlásil `publisher`, `queue` a `consumer`, ale telemetrický kanál z d.724
+(`_telemetryChannel`, vlastní události klienta) vynechával, přestože klíče téhle zprávy jsou
+dokumentované jako seznam kanálů klienta. Teď nese čtvrtý klíč `telemetry` ve stejném tvaru
+`{ exists, closed, ready }`. Kanál se otevírá prvním telemetrickým publishem; do té doby čte
+`{ exists: false, closed: true, ready: false }`, stejně jako každý dosud neotevřený kanál.
+
+Aditivní klíč. Čtenář, který tvrdí přesný tvar tří klíčů (`toEqual`), se musí srovnat: v balíčku
+`connection-liveness-single-source` (unit i IT) je srovnaný v téže změně, kořenové
+`api/tests/integration/channel-recovery.test.js` se srovná s re-pinem kořene na tuto verzi.
+
+### Added — `deliveryPolicy.validateConsumeOptions`: pravidla voleb `consume()` mají jednoho exportovaného vlastníka (d.1005)
+
+Čtyři pravidla voleb `consume()` dosud žila inline v transportu (`rabbitmqClient.js` `consume()`):
+- `requeueOnError` je boolean;
+- `requeueOnError: false` znamená jeden pokus a jiné `maxAttempts` s ním je rozpor;
+- rozpočet je celé číslo ≥ 1;
+- `classify` je funkce.
+
+Dvojník konzumenta (service-wrapper `MockMQConnector`) je proto mohl jen opsat, tedy druhá kolej
+(nález d.998c). Teď bydlí v `src/config/deliveryPolicy.js` `validateConsumeOptions(options,
+resolveDefaultMaxAttempts)`, transport ji volá a balíček ji exportuje jako
+`deliveryPolicy.validateConsumeOptions`. Vrací `{ maxAttempts, classify }`, nebo hází `ValidationError`
+se stejnými texty jako dosud `consume()`: `[RabbitMQClient] Invalid requeueOnError …`,
+`… Contradictory delivery policy …`, `… Invalid delivery budget …`, `… Invalid error classifier …`.
+
+Výchozí rozpočet se předává funkcí a volá se jen tehdy, když ho volby nechávají otevřený. Jeho
+čtení sahá do konfigurace (env `RABBITMQ_MAX_DELIVERY_ATTEMPTS`), která může sama odmítnout, a
+explicitní `maxAttempts` ani `requeueOnError: false` ho nikdy nepotřebovaly. Chování `consume()` se
+nemění. Pro dvojníky konzumentů: volat `deliveryPolicy.validateConsumeOptions(options, () =>
+<rozpočet dvojníka>)` místo vlastní kopie pravidel.
+
+### Removed — BREAKING — `RecoveryWorker` a posluchač kanálu `error`, který ho krmil (d.971)
+
+Pryč je `src/workers/RecoveryWorker.js` (`handleQueueNotFound()`, `handleTransientError()`)
+a v `src/transports/rabbitmqClient.js` jeho instance `_recoveryWorker` i vlastní posluchač
+transportu `this.on('error', …)` („Recovery worker - handle QueueNotFoundError via error
+event“). Čerstvě postavený transport na svém kanálu `error` neposlouchá nic.
+
+BREAKING pro každého, kdo si worker bral hlubokou cestou
+`require('@onlineapps/mq-client-core/src/workers/RecoveryWorker')` — z `src/index.js` se
+nikdy neexportoval; ve workspace to dělaly jen dvě sady `conn-infra-mq`, přepsané v téže
+vlně na veřejný kontrakt.
+
+Co zmizí z logu: při publikaci do chybějící fronty už nevznikne řádek
+`[RecoveryWorker] Cannot create infrastructure queue '<q>' …`,
+`[RecoveryWorker] Cannot create business queue '<q>' …` ani
+`[RecoveryWorker] Cannot create queue '<q>' - no section of queueConfig declares it …`.
+Po d.811b (výše) už ho stejně nic nespouštělo.
+
+Kde volající verdikt dostane (beze změny): `publish()` odmítne `PublishError`
+(`error.queue` = cílová fronta) s `cause` = `QueueNotFoundError` — `queueName`,
+`isInfrastructure`, `kind` (`infrastructure` / `business` / `unowned`) a pro každou třídu
+věta s vlastníkem fronty a `Fix:`. Nic se nedeklaruje.
+
+Čtyři otázky (`change-discipline.md` § Removing): (1) vznikl v `3588b148` jako zakladač
+chybějící fronty pro business scope; (2) nesla ho hlavička workeru § Queue Creation, kterou
+nahradila conf `mq-consumer-contract` 006 („queues come into being only from
+declarations“) — od d.419 nic nezakládal, jen logoval a znovu házel do posluchače, který
+chybu spolkl; (3) funkci mu vzal d.419, vstup d.811b; (4) náhrada je konceptuálnější —
+jeden verdikt jednou kolejí, k volajícímu, místo druhé kopie téže věty do logu.
+Sada `tests/unit/recovery-worker-removed.test.js` (kontrolní případ: `publish()` do
+chybějící business fronty dál odmítá `PublishError` s `QueueNotFoundError` v `cause`).
+
+### Changed — BREAKING — verdikt o odmítnuté publikaci jde jen odmítnutím `publish()`, ne kanálem `error` (d.811b)
+
+`RabbitMQClient._publishOnce()` končil každé selhání pokusu dvěma tvrzeními jednoho
+verdiktu: `this.emit('error', classifiedErr)` a `throw classifiedErr`. Emit je pryč,
+zůstává `throw classifyPublishError(err, queue)` (`src/transports/rabbitmqClient.js`,
+větev `catch` v `_publishOnce()`). Kanál `error` zůstává tomu, k čemu ho používá zbytek
+klienta — spojení a kanálům.
+
+Co konzument vidí jinak:
+
+- **`BaseClient.onError(callback)`** (jediná veřejná cesta ke kanálu `error` transportu,
+  `BaseClient.connect()` na něj věší `_handleError`) už nedostává `TransientPublishError`
+  (`retryable: true`), `PermanentPublishError` (`retryable: false`) ani `QueueNotFoundError`
+  (`kind`, `queueName`, `isInfrastructure`). Dřív je dostával za KAŽDÝ neúspěšný pokus,
+  tedy i za transientní pokusy, které `PublishLayer` následně zopakoval nebo zabufferoval.
+  Ostatní emity na `error` se nemění: spojení (`CONNECTION_CLOSED_UNEXPECTEDLY`), konec
+  cyklu obnovy spojení, chyby kanálu vydavatele (406 dál ne — tu odpovídá odesílateli
+  publikace) i konzumenta, odmítnutí `consume()`, selhání `ack`/`nack` a odmítnuté zavření
+  kanálu či spojení v `disconnect()`.
+- **`publish()` se nemění:** odmítá stejně jako dřív — `PublishError` z `BaseClient.publish()`
+  s klasifikovanou chybou v `error.cause`. Čísla o publikacích hlásí dál
+  `getPublishMetrics()` / `getPrometheusMetrics()` (plní je události `publish:retry`,
+  `publish:success`, `publish:failed`, `publish:buffered`, beze změny).
+- **`RecoveryWorker.handleQueueNotFound()` už na cestě publikace neběží.** Transport ho volal
+  z vlastního posluchače kanálu `error` (`_setupPublishMonitoring()`, „Recovery worker -
+  handle QueueNotFoundError via error event") a žádné jiné místo v `src/**` ho nevolá; žádný
+  zbývající emit na `error` `QueueNotFoundError` nenese. Při publikaci do chybějící fronty
+  proto z logu mizí řádek `[RecoveryWorker] Cannot create infrastructure queue '<q>' …` /
+  `Cannot create business queue '<q>' …` / `Cannot create queue '<q>' - no section of
+  queueConfig declares it …`. Fronta se nezakládá ani dál (nezakládal ji ani ten řádek) a
+  volající dostane odmítnutí jako dosud; ubyla jen druhá, logová zpráva o téže události.
+- Filtr v `_waitForReconnection()` (`if (error.retryable !== undefined) return;`) zůstává:
+  knihovna do kanálu klasifikovanou chybu už nedává, ale kanál je veřejný a kdo drží
+  transport, emitovat na něj může.
+
+Dopad ve workspace (změřeno 2026-09-26 nad `api/infra/*`, `api/shared/**` mimo tento balíček
+a `api_biz/*/src`): v produkčním kódu nevolá `onError()` nikdo a nikdo neposlouchá `error` na
+MQ klientovi ani na jeho transportu — pět míst, která sahají na `mqClient._transport`
+(gateway, dispatcher, scheduler, wrapper, `conn-infra-mq` `QueueManager`), berou z něj
+`queueChannel`, `connection` nebo `onChannelClose`, ne kanál `error`. Integrační sady v
+`api/tests/integration` a `api/infra/api_gateway/tests` registrují `onError(() => {})`, který
+nic netvrdí. Proto BREAKING podle kontraktu `onError()`, bez čtenáře, kterého by to zlomilo.
+
+### Changed — BREAKING — `serviceName` je povinný, knihovna si ho nevyrábí (d.770)
+
+`src/defaults.js` už nenese `serviceName: 'oa-service'` a `src/config.js` deklaruje klíč
+jako `required: true`. Jméno má dvě nohy, obě volajícího: explicitní `serviceName`
+v konfiguraci klienta, nebo ENV `SERVICE_NAME`. Třetí není. Chybí-li obě,
+`new BaseClient(…)` se odmítne postavit hláškou, jejíž znění vlastní
+`@onlineapps/runtime-config` (`[RuntimeConfig] Missing environment variable - SERVICE_NAME
+is required for config key "serviceName". Fix: …`). Dřív klient postavený bez klíče
+publikoval události monitoringu a pojmenovával fronty pod službou `oa-service`, která
+neexistuje — v `workflow_traces.service_name` pak stálo jméno nikoho.
+
+Druhý čtenář téhož faktu je srovnaný: `BaseClient` rozřešené jméno (ať přišlo kteroukoli
+nohou) zapisuje zpět do `config.serviceName` a transport z něj skládá jméno spojení
+`oa-client:<serviceName>:<pid>`, když volající nedal `connectionName` ani `clientName`.
+Dřív ho transport bral z runtime konfigurace, takže explicitní `serviceName` volajícího se
+tam vůbec nečetl. Transport postavený bez jména se odmítne `ValidationError` místo spojení
+pojmenovaného `oa-client:undefined`.
+
+Migrace: předejte `serviceName` v konfiguraci klienta, nebo nastavte `SERVICE_NAME`
+v prostředí služby. Změřeno v dávce: service-wrapper, conn-orch-registry,
+api_delivery_dispatcher a api_meta_reader jméno předávají; api_delivery_endpoint stojí na
+noze `SERVICE_NAME`.
+
+### Changed — BREAKING — zprávu, kterou broker pozdě odmítl, vrstva publishe už neposílá znovu (d.801c)
+
+`PublishLayer` po dobu jednoho publishe poslouchá událost `publish:refused-late` (d.801b,
+níže) a před každým dalším pokusem se ptá, zda pro tuto frontu nedorazil pozdní
+PERMANENTNÍ verdikt. Pokud ano, smyčka končí: `warn` `[PublishLayer] The broker refused
+this message while attempt <n> was in flight, so attempt <n+1> of <max> is not made …`,
+událost `publish:failed` s `retryable: false` a `refusedLate: true`, a volající dostane ten
+verdikt — `PermanentPublishError` s brokerovým rámcem v `cause`. Žádný další pokus, nic do
+bufferu. Posluchač se odhlašuje v `finally`; nevzniká žádný nový časovač ani evidence. Číslo
+pokusu jde transportu v options jako `attempt` (do AMQP vlastností se nedostane).
+
+Co se mění pro konzumenta: zpráva, kterou broker odmítl až poté, co `brokerAnswerTimeout`
+odpověděl volajícímu, se dřív opakovala `publishMaxRetries`krát a skončila v bufferu,
+odkud ji `InMemoryBuffer.flush()` nabízel při každém reconnectu do vypršení TTL. Nově
+skončí jedním pokusem a trvalou chybou. Dopad popsaný v dávce: api_delivery_dispatcher
+takovou zásilku přestane opakovat a pošle ji deklarovanou dead-letter cestou; RPC odpověď
+service-wrapperu změní třídu z transientní na permanentní; kdo počítá pokusy z
+`publish:retry`, uvidí u takové zprávy jeden místo N. Zpráva, u níž potvrzení nedorazí
+vůbec a žádný rámec není, se opakuje beze změny.
+
+### Changed — BREAKING — očíslované odmítnutí odeslání je trvalý verdikt o TÉTO zprávě (d.685a, d.693, d.696, d.723)
+
+Broker, který odmítne `basic.publish`, zavře kanál očíslovaným rámcem (`classId 60`,
+`methodId 40`). amqplib ho předá události `error` kanálu, kde ho handler publisher kanálu
+zapíše do `channel._closeError`; callback publishe dostane jen holé `'channel closed'`.
+`_publishOnce()` ten rámec nově čte na obou nohách, frontové i výměnové:
+
+- **Číselný kód je odpověď** (d.685a, d.693): 403 ACCESS-REFUSED, 406 PRECONDITION-FAILED
+  i 404 NOT-FOUND za publish přes výměnu, kterou nikdo nedeklaroval, končí
+  `PermanentPublishError` s rámcem v `cause` — jeden pokus, nic do bufferu. Dřív
+  `TransientPublishError`: `publishMaxRetries` pokusů, pak buffer a nabídka při každém
+  reconnectu do TTL. Věty má jeden producent, `refusedSendMessage(kind, target, code)`
+  v `utils/publishErrors.js`; u 404 nad výměnou říká, že ji nikdo nedeklaroval, a `Fix:`
+  posílá do `queueConfig`. Chybějící FRONTA se nemění — dál `QueueNotFoundError`
+  z předkontroly.
+- **Rámec patří jedné publikaci** (d.723): nese-li kanál v okamžiku rámce víc
+  nepotvrzených publikací, trvalý verdikt dostane jen ta, jejíž výměnu či frontu rámec
+  jmenuje; ostatní dostanou `TransientPublishError` s rámcem v `cause`
+  (`collateralCloseMessage()`), takže je vrstva zopakuje a mezitím bufferuje. Jméno, které
+  se v rámci nenajde, znamená „nepřisouzeno" — přechodný verdikt, tedy nanejvýš duplicitní
+  zpráva, nikdy zahozená.
+- **Důvod se zapisuje dřív, než handler větví** (d.696): i rámec `406` „unknown delivery
+  tag" handler publisher kanálu zapíše do `channel._closeError`, takže publish na kanálu
+  zabitém tímto rámcem je trvalý stejně jako každé jiné očíslované odmítnutí. Na kanál
+  `error` klienta rámec dál nejde.
+- Smrt kanálu BEZ číselného kódu (výpadek spojení, soketový `code` jako `'ECONNRESET'`)
+  zůstává přechodná: o osudu zprávy se nic neví.
+
+Migrace: kdo spoléhal na to, že vrstva odmítnutou zprávu zopakuje nebo zabufferuje,
+dostane ji nově hned jako odmítnutí `publish()`. Oprava je u příčiny, kterou rámec
+v `error.cause` jmenuje — právo účtu ve vhostu, `user_id` zprávy, deklarace výměny.
+
+### Changed — BREAKING — `publishMaxRetries: 0` se odmítá jménem (d.684, d.685b)
+
+Klíč počítá POKUSY včetně prvního. `0` proto nebylo „bez opakování", ale publish, ke
+kterému nedojde: smyčka `_publishWithRetry()` neproběhla ani jednou, zpráva se brokeru
+nenabídla, cestou ven se nezabufferovala a závěrečná hláška svalovala vinu na
+`PublishLayer`. Tři komentáře, které `0` vykládaly jako „do not retry", jsou opravené.
+
+Nově: `configSchema.js` deklaruje `minimum: 1`, takže `new BaseClient({ …,
+publishMaxRetries: 0 })` padne už při stavbě klienta (`/publishMaxRetries: must be >= 1`
+s `Fix:`); konstruktor `PublishLayer` hodnotu pod 1 odmítá i tam, kam schéma nedosáhne
+(transport postavený přes `transportFactory`, vlastní `options.maxRetries` volajícího),
+`ValidationError` `[PublishLayer] publishMaxRetries must be at least 1 - …`.
+
+Migrace: jeden pokus bez opakování je `publishMaxRetries: 1`, opuštění retry koleje
+`publishRetryEnabled: false`. Změřeno v dávce d.685b: jediný zápis klíče mimo balíček je
+`api/tests/integration/message-buffer.test.js` s hodnotou 2.
+
+### Changed — vytíženost prefetch okna se hlásí na přechodu, oběma směry (d.736a)
+
+`_checkPrefetchUtilization()` dřív mluvil pokaždé, když podmínku našel platnou (produkce
+18. 9.: tři řádky za 68 ms o jedné stojící podmínce), a návrat pod práh neřekl nikdy. Nově
+padá verdikt jen na přechodu: nad práh jeden `warn` `Prefetch utilization high: …` a s ním
+jednou událost `prefetch:high-utilization` a jednou `prefetchAlertCallback`; pod práh
+jeden `info` `Prefetch utilization back below threshold: …`; mezi tím ticho, ať se čítač
+nad prahem hýbe jakkoli. Stav drží `tracking.utilizationHigh` a verdikt se bere i při
+snížení čítače. Kdo počítal volání callbacku nebo události, dostane jedno za epizodu místo
+jednoho za každou kontrolu nad prahem. Práh se nemění, hystereze ani druhý callback nevznikají.
+
+### Changed — fronta instance registru vyprší 60 s po posledním konzumentovi (`x-expires`, d.1036)
+
+Šablona `registry.{instance_id}` (`src/config/queueConfig.js`) nese `'x-expires': 60000`.
+Každý start kopie služby pojmenuje novou frontu `<svc>.registry.<instance_id>` (UUID na proces,
+pokud `SERVICE_INSTANCE_ID` neurčí jinak) a nic starou nemaže — `deregister()`, shutdown
+wrapperu ani registr, který frontu před odpovědí jen ověří (měřeno d.1032). Bez životnosti by
+po každém restartu, pádu i čistém stopu zůstala trvalá fronta bez konzumenta, kterou monitoring
+hlásí jako `no_owner`. Živá kopie má konzumenta, takže jí fronta nevyprší; po odchodu kopie ji
+broker smaže do 60 s — pod oknem sirotka monitoringu (`min_orphan_minutes`, seed 5), takže
+epizodu neotevře. Sdílená `<svc>.registry` životnost nemá a nemění se. Rozhodnutí vlastníka:
+otázka 14, varianta A (`registry-instance-identity` 003).
+
+Není to BREAKING vůči vydané 4.2.0: ta šablonu `registry.{instance_id}` nemá vůbec, takže
+žádný vydaný klient frontu tohoto tvaru nezaložil (konzumaci by odmítl bez dead-letter cesty).
+Změřeno na brokeru (`tests/integration/registry-instance-queue-expires.integration.test.js`):
+fronta tohoto tvaru, kterou dřív kdokoli založil BEZ `x-expires`, se teď při `consume()` odmítne
+`406 PRECONDITION-FAILED` („inequivalent arg 'x-expires'") — týká se jen front z nevydaného
+buildu (na dev brokeru jich je 0, d.1032 bod 5); oprava = frontu smazat, klient ji při
+konzumaci založí znovu.
+
+### Added — fronta jedné instance registru `{service}.registry.{instance_id}` je deklarovaná (d.817b)
+
+Odpovědi registru na registraci jdou instanci na `<svc>.registry.<instanceId>` (conf
+`registry-instance-identity` 001); sdílená `<svc>.registry` nese jen podněty registru. Pro
+takové jméno dosud `queueConfig.getDeadLetterRoute()` i `parseBusinessQueue()` vracely `null`
+a `consume()` frontu bez deklarované dead-letter cesty odmítá (conf `mq-consumer-contract`
+002).
+
+Nová šablona v sekci `business` (`src/config/queueConfig.js`):
+
+    'registry.{instance_id}': {
+      durable: true,
+      arguments: {
+        'x-dead-letter-exchange': DEAD_LETTER_EXCHANGE,   // 'dlx'
+        'x-dead-letter-routing-key': '{service}.dlq'
+      }
+    }
+
+tedy stejná dead-letter cesta jako u sdílené `{service}.registry`:
+`getDeadLetterRoute('biz-hello.registry.7f3a9c21')` = `{ exchange: 'dlx', routingKey:
+'biz-hello.dlq' }`. Životnost fronty doplnila d.1036 (`x-expires`, viz Changed níž).
+
+Rozhodčí pravidlo `matchBusinessTemplate()`: `<svc>.registry.events` sedí na doslovnou
+šablonu `registry.events` i na zástupnou `registry.{instance_id}`. Doslovná šablona nově
+vyhrává nad zástupnou; dvě shody šablon TÉHOŽ druhu jsou dál vada a jméno se odmítá
+`ValidationError` („matches more than one template"). Stávající šablony, jejich argumenty ani
+cesty se nemění (`registry.events` si drží TTL i strop, sdílená `registry` je beze změny,
+`registry.register` zůstává platformní); jméno, na které nesedí žádná šablona, je dál
+odmítnuto.
+
+### Added — `scheduler.SCHEDULER_REQUEST_INVALID`: odmítnutí builderu se pozná podle kódu, ne podle textu (d.943)
+
+Boot fáze 0.7b wrapperu má podle conf `scheduler` 020 izolovat záznam, který builder odmítne
+(selhaný zdroj), a dál zastavit boot, když se požadavek nepodaří ODESLAT (selhání služby). Obě
+cesty dosud házely holé `Error`, takže je šlo rozlišit jen podle znění hlášky. Nově každé
+odmítnutí builderu nese `error.code = 'SCHEDULER_REQUEST_INVALID'` (konstanta pod jmenným
+prostorem `scheduler`, jediný vlastník). Kód nesou: kontrola klíčů v `registerRecurring`,
+`validateRecurrences` (chybějící `source`, dokument není objekt, dokument nedrží tvar, dvakrát
+stejné `id`), `requireIdempotencyKey`, `requireRequestedBy`, `requireTenancy` (tenant i
+workspace) a `buildEventRequest` (chybí `event`, `event.service`/`event.name` mimo vzor) —
+tedy i `buildRecurringRequest` a `buildCancelRequest`, které je volají. NEnesou ho:
+`publishSchedulerRequest` (chybí klient, klient není připojen, cizí druh požadavku, publikace
+odmítnutá brokerem) a stavba portu v `createSchedulerPublisher`. Znění hlášek beze změny.
+Sada `tests/unit/scheduler-request-invalid-code.test.js` (kontrolní případy: selhaná publikace
+a nepřipojený klient kód nemají).
+
+### Added — událost `message_dlq` jmenuje operaci, která umřela (d.641)
+
+Mrtvý dopis dosud říkal, ve KTERÉ frontě zemřel (`queue`, `attempts`,
+`classification`, `error`), ale ne CO umřelo. Operátor tak u běhu s víc kroky
+neměl z události jak poznat, která operace to byla; jméno bylo přitom celou dobu
+v obálce, kterou `_emitDeadLetterEvent()` už rozbaluje kvůli `workflow_id`.
+
+Nově událost nese `operation` — **jen když ho obálka nesla**, v jediném
+pravopisu invokační obálky (`docs/biz/10-invocation/mq-envelope.md` § Inbound
+envelope). Workflow zpráva (`docs/biz/70-contracts/workflow-message.md` §3.2)
+`operation` nikdy nenese, takže u ní klíč v události prostě chybí; žádný
+`unknown`, žádný `null` — stejně jako se zachází s chybějícím `workflow_id`.
+Hodnota, která není neprázdný řetězec (`''`, číslo, objekt), se bere jako
+nepřítomnost.
+
+Konzument existuje už dnes a nový klíč čte beze změny: monitoring bere
+`readReported(data.operation)` (`api/infra/api_monitoring/src/consumer/
+apiflow-extension.js`) a posílá ji do řádku v Loki jako `operation` — u události
+`message_dlq` tam do téhle dávky chodilo `null`. Identita běhu zůstává **jeden
+klíč**, `workflow_id`: `correlation_id` na `monitoring.workflow` nejezdí
+(`docs/biz/70-contracts/monitoring-events.md` § Rules) a tahle dávka ho tam
+nezavádí.
+
+Doklad proti realitě: integrační tier posílá přes živý broker obálku s
+`operation`, nechá ji dojít do `<service>.dlq` a čte událost z vlastní kopie
+fanoutu `monitoring.workflow.fanout`; kontrolní případ je tatáž cesta s
+workflow zprávou bez `operation` — klíč v události chybí.
+
+### Added — `decodeMessage()`: jedna veřejná kolej z doručení na zprávu (d.789)
+
+Nový export z kořene balíčku (`src/utils/decodeMessage.js`). `consume()` předává handleru
+syrovou zásilku amqplib, takže si překlad psal každý konzument sám — dávka d.788 změřila
+čtyři kopie (dispatcher, plánovač, service-wrapper, registr), které se neshodnou právě
+v tom, co se stane s vadnou zprávou. Dekódování samo dělá `utils/serializer.js`
+`deserialize()` odjakživa; chyběly veřejné dveře.
+
+`decodeMessage(raw)` vrací `{ body, headers, properties, fields }` — dekódované tělo
+a všechno ostatní tak, jak přišlo. Odmítá `ValidationError`em, jménem toho, co přišlo:
+zásilku, která není objekt; `content`, který není `Buffer` ani řetězec; prázdné tělo;
+deklarovaný `contentType` jiný než `application/json` (typ se kontroluje, jen když ho
+zpráva deklaruje — obálka platformy ho nevyžaduje). Tělo, které není JSON, propouští
+`SerializationError` z `deserialize()` beze změny (`payload`, `cause`). Pole `retryable`
+nenese: na cestě konzumace ho nic nečte, osud zprávy rozhoduje `classify(error)`
+volajícího podle třídy chyby.
+
+Aditivní: `consume()` se nemění a v balíčku funkci nic nevolá. Převod čtyř konzumentů
+mění osud vadné zprávy a jde vlastní dávkou.
+
+### Added — `topology.telemetryExchange` (d.708b)
+
+Zmrazený export `topology` nese `telemetryExchange: 'telemetry.exchange'`, složený
+`queueConfig.queueName('telemetry', 'exchange')` ze šablony, kterou výměna má
+v `queueConfig` (d.708) — stejným tvarem jako tři `telemetry*Queue` nad ním. Monitoring
+konzument řeší každé platformní jméno, které sám nevlastní, přes `topology`, a
+`src/config/queueConfig` je interní cesta, ne kontrakt; deklarované, ale nevyexportované
+jméno si proto dosud musel držet jako literál. Přejmenování v `queueConfig` export posune
+s sebou, chybějící záznam selže hned.
+
+### Added — `BaseClient.publishTelemetry()`: vlastní události klienta mají vlastní kanál (d.724)
+
+Kanál umírá na první odmítnutí, které potká, a bere s sebou každou nepotvrzenou publikaci.
+Klient přitom vlastní události (`message_dlq` na `monitoring.workflow.fanout`) posílal po
+tomtéž ConfirmChannelu, na kterém čekaly zprávy volajícího — ve vhostu bez toho fanoutu
+tak 404 kvůli události shodil obchodní zprávu (změřeno d.711: tři ze sedmi běhů
+nesouvisející sady).
+
+- `publishTelemetry(queue, message, options?)` publikuje stejně jako `publish()`, ale po
+  druhém CONFIRM kanálu s rolí `telemetry`. Ten vzniká až s první takovou publikací (u
+  klienta, který žádnou neposílá, nikdy) a `disconnect()` ho zavírá spolu s ostatními.
+  `getChannelState()` ho hlásí jako čtvrtý klíč `telemetry` (d.1007, výše).
+- Kanál se vybírá výslovně, nikdy podle jména fronty.
+- `publishToMonitoringResilient()` (a `publishToMonitoringWorkflow()` /
+  `publishToMonitoringServices()`, které ho volají) publikuje přes
+  `mqClient.publishTelemetry()`. Klienta, který tu metodu nemá, ohlásí `warn`
+  (`Monitoring publish skipped: the client has no publishTelemetry() …`) a vrátí `false`,
+  místo aby publikoval po obchodním kanálu. `BaseClient` i jeho podtřídy (např.
+  `ConnectorMQClient` z `@onlineapps/conn-infra-mq`) ji dědí.
+
+### Added — pozdní odmítnutí od brokeru se ohlásí: `warn` a událost `publish:refused-late` (d.801b)
+
+Když `brokerAnswerTimeout` odpoví volajícímu dřív než broker, callback publishe běží dál
+a sestaví správný verdikt — a dřív ho předal už vyřízené promise, kde zmizel. Nově se
+takový verdikt ohlásí: `warn` v tvaru `[Context] Problem - Expected/Fix` (cíl, kód brokeru,
+třída verdiktu; `Fix:` říká, že vrstva publishe zprávu brala jako nepotvrzenou, a nabízí
+zvednout strop nad změřenou latenci) a událost `publish:refused-late` s `queue`,
+`exchange`, `target`, `kind`, `code`, `verdict`, `error` (verdikt jako objekt), `attempt`
+a `budgetMs`. Strop ani výsledek promise se tím nemění; podle události jedná `PublishLayer`
+(d.801c, výše).
+
+### Fixed — `_ensureConsumerChannel()` hlásí změřené počty a obnova s nepřipojeným konzumentem není „✓" (d.1003d)
+
+- **Počty**: nad kanálem, který už žil (i po obnově, která ho vytvořila), vracela metoda
+  `{ reRegistered: <počet sledovaných>, failed: 0 }` — konzument, jehož re-registraci broker
+  odmítl (zůstává sledovaný bez tagu, d.262 a d.386b), se počítal jako re-registrovaný.
+  Nově se počítá podle `_isConsumerAttached()`: `reRegistered` = připojení, `failed` =
+  sledovaní bez připojení. Tvar výsledku beze změny; v produkčním kódu ho nikdo nečte
+  (`consume()` a handler zavření kanálu ho zahazují), čtou ho testy.
+- **Souhrn obnovy**: `✓ Consumer channel recreated (re-registered: N, failed: M)` stál na
+  INFO se značkou ✓ i při `failed > 0`. Nově je to `warn` bez ✓, který jmenuje fronty bez
+  konzumenta; úspěšná obnova má dál ✓ na INFO. Odmítnutí jednotlivé fronty zůstává řádkem
+  `error` jako dosud.
+- **Souhrn obnovy spojení** (d.1003e): reconnect logoval `✓ Consumer channel recreated` na INFO
+  bez počtů i při `failed > 0`. Totéž pravidlo jako výš — při `failed > 0` `warn` bez ✓ se jmény
+  front, jinak ✓ na INFO nově i s počty.
+
+### Fixed — handler zavření frontového kanálu trvalé selhání obnovy nespolkne (d.1003c)
+
+Handler `'close'` frontového kanálu logoval selhání okamžité obnovy vždy jen jako `warn`,
+přechodné i trvalé. Nově čte totéž pravidlo jako send a consumer kanál
+(`_connectionIsGoingAway()` nad `cause` chyby z `_ensureQueueChannel()`): spojení, které
+odchází, zůstává `warn`; cokoli jiného jde řádkem `error` do logu a na kanál `error` klienta.
+Líná obnova se nemění — kanál zůstane prázdný a příští operace nad frontou
+(`_requireQueueChannel()`) ho vytvoří jako dosud. Nová událost ani nový tvar chyby nevznikl.
+
+### Fixed — handler zavření obnovuje kanál té role, která zemřela, a consumer kanál už trvalé selhání obnovy nespolkne (d.1003b)
+
+- **Role send kanálu**: handler zavření visí na publisher i telemetry kanálu, ale obnovu
+  volal bez role — po smrti telemetry kanálu „obnovil" živý publisher (nic) a telemetry
+  zůstal prázdný až do příští události. Handler teď nese roli kanálu, na kterém visí, a
+  obnoví tu. Smrt publisher kanálu se chová jako dosud.
+- **Consumer kanál**: jeho handler zavření polykal každé selhání obnovy jako `warn`.
+  Přechodné (spojení odchází) zůstává `warn`; jakékoli jiné jde na kanál `error` klienta
+  a řádkem `error` do logu — konzumenti už tiše nepřestanou dostávat zprávy.
+- **Jedno pravidlo** „odmítnuté otevření kanálu je přechodné" (`IllegalOperationError`,
+  nebo spojení, které už ohlásilo `'close'`) má jedno tělo, `_connectionIsGoingAway()`,
+  a čtou ho obnova send kanálu i handler consumer kanálu. Nová událost ani nový tvar chyby
+  nevznikl.
+
+### Fixed — obnova send kanálu: spojení, které spadlo uprostřed otevírání, je přechodné; trvalé selhání obnovy už handler zavření nespolkne (d.1003)
+
+- **`_ensurePublisherChannel()`**: spadne-li spojení UPROSTŘED `createConfirmChannel()`,
+  amqplib odmítne čekající RPC holým `Error('Channel ended, no reply will be forthcoming')` —
+  bez třídy i `code` — a obnova z něj dělala `PermanentPublishError`, takže PublishLayer
+  zprávu zahodil místo aby ji podržel do reconnectu. Nově rozhoduje i STAV: odmítnutí, které
+  dorazí, když `_connectionAlive` už říká, že spojení je pryč, je `TransientPublishError`.
+  Změřeno nad živým brokerem: zavření spojení brokerem během otevírání dalo tuto chybu 8× z 12,
+  pokaždé až po ohlášeném `'close'`. Táž věta nad živým spojením zůstává trvalá — text dál
+  nerozhoduje.
+- **Handler zavření publisher kanálu**: selhání obnovy kanálu polykal celé jako `warn`.
+  Přechodné (`TransientPublishError`) zůstává `warn` — příští publish kanál po reconnectu
+  obnoví; jakékoli jiné jde na kanál `error` klienta (kolej nehlášeného selhání, jako
+  v `_reportRecoveryFailure()`) a řádkem `error` do logu. Nová událost ani nový tvar chyby
+  nevznikl.
+
+### Fixed — `getBufferState()` hlásí změřené číslo, ne vymyšlenou nulu (d.645)
+
+Buffer je jeden a `MessageBuffer.size()` JE `_inMemory.size()` (o dva řádky
+vedle, `src/buffer/MessageBuffer.js`). Hlásící strana přesto brala druhé číslo
+ze soukromého členu toho soukromého členu, za dvěma operátory, které dohromady
+uměly jen zakrývat:
+
+    inMemory: this._publishLayer._buffer._inMemory?.size() || 0
+
+`?.` nemůže zafungovat — konstruktor `MessageBuffer` staví `_inMemory` vždy a
+řádek nad tím volá `_buffer.size()` bez ochrany, takže chybějící buffer spadne
+dřív, než se k výrazu dojde. Co ta dvojice ale uměla vyrobit pro buffer, jehož
+vnitřek není ten předpokládaný, je `inMemory: 0` vedle nenulového `size`:
+„drženo, ale nikde" — stav, ve kterém žádný skutečný buffer být nemůže, ohlášený
+bez hlásky a pro čtenáře nerozeznatelný od prázdného bufferu
+(`architecture-principles.md` §3 No Fallbacks, §8 Explicit Over Implicit;
+`automation-gates.md` §5 mlčení je vada).
+
+Nově obě čísla pocházejí z jednoho čtení veřejného `size()`. Tvar odpovědi ani
+hodnoty pro skutečný buffer se nemění — `{ size, inMemory }` dál, stejná čísla —
+takže žádný čtenář se nepřepisuje.
+
+Doklad: jednotkový tier RED→GREEN nad bufferem, který na `size()` odpoví 2 a
+`_inMemory` nemá (dřív `{ size: 2, inMemory: 0 }`, nově `{ size: 2, inMemory: 2 }`),
+s kontrolními případy nad skutečným bufferem (držená zpráva 1, prázdný 0).
+Integrační tier drží zprávu ve skutečném `InMemoryBuffer` na klientu živého
+brokeru a hlášené číslo měří proti tomu, co broker po flushi opravdu převzal; je
+zelený na obou stranách téhle dávky a říká to ve své hlavičce — živý běh tenhle
+rozdíl vyrobit neumí, protože skutečný `MessageBuffer` `_inMemory` vždycky má.
+
+### Fixed — o chybě rozhoduje třída a kód, ne text hlášky (d.676, d.677, d.683, d.685c, d.696, d.698, d.711, d.1000)
+
+Kontrakt `docs/biz/70-contracts/error-handling.md` §6: větvit podle `err.code`, nikdy podle
+znění. Přeformulovaná věta dosud tiše měnila osud zprávy. Tyto větve nově rozhodují třídou
+a kódem:
+
+- **`classifyPublishError()`** (d.677, d.683): už otypovaná chyba projde beze změny;
+  `code === 404` → `QueueNotFoundError` se jménem od volajícího; `IllegalOperationError`
+  z amqplib, `ConnectionError` a `PublishError` → `TransientPublishError`; všechno ostatní
+  `PermanentPublishError`. Textová větev nezbyla ani jedna: holé chyby amqplib
+  (`'channel closed'`, `'Channel ended, no reply will be forthcoming'`) typuje místo, kde
+  přijdou — výměnová noha `_publishOnce()` odpoví na mrtvém kanálu vlastním `PublishError`
+  s původní chybou v `cause`, předkontrola fronty odliší očíslované odmítnutí (např. 405
+  RESOURCE_LOCKED — trvalé) od bezkódové chyby na mrtvém kanálu (přechodná). Mění se dva
+  tvary, které dřív rozhodovala náhoda: chyba se správnou třídou a jiným zněním dostane
+  verdikt podle třídy; cizí chyba, jejíž věta obsahuje některé z dřívějších klíčových slov,
+  je trvalá.
+- **`isQueueUnavailableError()`** (d.676): prochází řetěz `cause` (nejvýš 8 článků,
+  smyčka na sebe sama se zastaví) a ptá se jen na `QueueNotFoundError`, `ConnectionError`,
+  `TransientPublishError`, `code === 404` a soketové kódy `ECONNREFUSED` / `ENOTFOUND` /
+  `ETIMEDOUT`. Mění se tři vstupy: fronta bez vlastníka (`kind: 'unowned'`) a publikace po
+  vyčerpání pokusů jsou nově `true`, chyba, která `404`/`NOT_FOUND` jen zmiňuje v textu, je
+  nově `false`.
+- **Synchronní výjimka odeslání** v `_publishOnce()` (d.685c): o tom, zda počkat na
+  reconnect a zprávu poslat znovu, rozhoduje `_isChannelAlive()` kanálu, který odesílal,
+  ne slova `'Channel ended'` / `'Channel closed'`. Chyba, která ta slova jen obsahuje,
+  vyhozená na živém kanálu, se už znovu neposílá, ale vrací volajícímu.
+- **Vypořádání a zavírání** (d.696, d.698): automatický ack v `consume()`, veřejné `ack()`
+  a `nack()` poznají zavřený či zavírající se kanál podle `instanceof IllegalOperationError`;
+  handler publisher kanálu pozná odmítnutí podle `code === AMQP_PRECONDITION_FAILED` (406,
+  nová konstanta v `utils/publishErrors.js` vedle `AMQP_NOT_FOUND`); `disconnect()` bere
+  odmítnuté zavření spojení za očekávané jen při `IllegalOperationError` BEZ zapsané
+  poruchy (`connection._closeError`, nově zapisované stejně jako u kanálů); obnova
+  frontového kanálu čte `err.cause instanceof IllegalOperationError`. Chyba, která větu
+  `'Connection closed (by client)'` jen cituje, už se nespolkne jako čekaná. Nedosažitelná
+  větev confirm callbacku („unknown delivery tag" / `PRECONDITION_FAILED` → čekat na
+  reconnect a publikovat znovu) je smazaná. `_isBrokerRefusal()` textovou půlku drží
+  a komentář říká proč: odmítnutý handshake (403 při špatném hesle) přijde jako holý
+  `Error` bez `code`.
+- **Kód 404 má jednoho vlastníka** (d.711): `monitoring-publish.js` a
+  `transports/rabbitmqClient.js` čtou `AMQP_NOT_FOUND` z `utils/publishErrors.js` místo
+  vlastní konstanty a holé `404`. Chování beze změny.
+- **Obnova send kanálu** (d.1000) — poslední textová větev publikační klasifikace:
+  `_ensurePublisherChannel()` dávala `TransientPublishError` podle slov `'Connection
+  closing'` / `'Connection closed'`, nově podle `instanceof IllegalOperationError`
+  (amqplib 0.10.9 tu třídu vydá z `createConfirmChannel()` nad zavírajícím i zavřeným
+  spojením, bez `code` — změřeno nad živým brokerem). Mění se dva tvary: jiná chyba, jejíž
+  věta ta slova jen obsahuje, je nově `PermanentPublishError`; `IllegalOperationError`
+  s jiným zněním (`'Channel closed'` nového kanálu, který zavřelo odcházející spojení) je
+  nově přechodná. Text v rozhodování zůstal jen v `_isBrokerRefusal()`, z důvodu, který
+  tam stojí (odmítnutý handshake nemá `code`).
+
+### Fixed — odmítnutá konfigurace transportu není nedostupný broker (d.736b)
+
+`BaseClient.connect()` stavěl transport uvnitř `try`, jehož `catch` balil všechno do
+`ConnectionError` „a reachable broker … check the MQ url, credentials and network" —
+i odmítnutí, která vydal konstruktor transportu, tedy vady konfigurace (cíl, který není
+neprázdný řetězec, URL s vlastním `heartbeat`, `onFatal`, který není funkce, nepodporovaný
+`type`). `ServiceWrapper._initializeMQ()` takovou chybu četl jako přechodnou a opakoval
+`connect()` podle `wrapper.mq.connectionRetries` (~200 s čekání). Stavba transportu je nově
+před `try` a odmítnutí projde tak, jak je — se svou třídou a hláškou, která jmenuje klíč
+i opravu. `ConnectionError` zůstává tomu, co se stalo na spojení (ECONNREFUSED; odmítnutí
+brokerem dál nese `MQ_CONNECTION_FATAL` / `broker-refused`).
+
+### Fixed — čítač zpráv v letu je svázaný s doručením (d.680)
+
+Produkce 20. 9. (dispatcher): `Prefetch utilization high: queue 'workflow.completed' has
+43/5 messages in-flight (860%)` a číslo rostlo s každým workflow. Snížení čítače sedělo ve
+větvích, které zprávu vypořádají přímo v `consume()`; handler, který si zprávu vypořádá
+sám (`ack()`/`nack()`), konzument s `noAck` a předčasné návraty po smrti kanálu nechaly
+zvýšení stát. Nově jedno zvýšení na začátku callbacku doručení a jedno snížení v jeho
+`finally`. Veřejné API ani tvar události `prefetch:high-utilization` se nemění.
+
+### Fixed — každý časovač klienta je v jedné evidenci `_activeTimers` (d.759e)
+
+Opakující se časovače health a prefetch monitoringu vznikaly holým `setInterval`, mimo
+evidenci, kterou `_clearAllTimers()` při teardownu smete a kterou sady tvrdí
+(`_activeTimers.size`). Nově jdou přes `_setInterval()` / `_clearInterval()`;
+`_clearAllTimers()` nejdřív zastaví oba monitory (aby jejich reference nezůstaly ukazovat
+na mrtvý handle a příští start je neodbyl jako „already started"). `connect()` po
+neúspěšném spojení ruší svůj časovač `_clearTimeout()`, takže v evidenci nezůstane handle,
+který už nic nehlídá.
+
+### Tests — komentáře v `src/**` k sadám publishe a prefetch (d.738, d.766)
+
+`layers/PublishLayer.js` říká, proč spánek mezi pokusy publishe je holý `setTimeout`
+a ne `_setTimeout()` transportu (čeká `publish()` volajícího, ne smyčka klienta, a
+teardown ho ukončit nemá), se strážní sadou (d.766); `transports/rabbitmqClient.js`
+popisuje, co po d.736a zbývá říct periodické kontrole prefetch (d.738, spolu s převodem tří
+integračních sad na čekací kolej tieru). Chování beze změny.
+
+### Documentation — komentáře v `src/**` bez čísel řádků a ručních verzí (d.646, d.668, d.981)
+
+Hlavička `src/index.js` už neuvádí verzi ručně (d.646); komentáře `config/queueConfig.js`
+už netvrdí, že `initInfrastructureQueues()` odvozuje seznam front ze sekcí (od d.668
+vyžaduje `queues`); čísla řádků v komentářích `src/**` nahradily symboly (d.981). Chování
+beze změny.
+
+### Documentation — README: routing key telemetrie má tvar `telemetry.<signal>.<service_name>` (d.994b)
+
+Řádek `telemetryLogsQueue` v tabulce `topology` tvrdil, že služby publikují na
+`telemetry.exchange` „se svým jménem jako routing key". Změřeno: `monitoring-core` publikuje
+logy pod `telemetry.logs.<serviceName>` (`src/logger.js`) a exportér pod
+`telemetry.<type>.<service_name>` (`src/exporters/rabbitmq.js`), monitoring konzument váže
+fronty vzorem `telemetry.<type>.*`. Pravdu měl komentář exportu v `src/index.js`; opravena je
+věta v README.
+
+### Changed — tarball už nenese `jest.config.js` ani `jest.integration.config.js` (d.1020)
+
+- `.npmignore` je vylučuje. Spouštějí jen sady balíčku (`tests/` se nebalí) a po instalaci je nic nečte;
+  `npm pack --dry-run` ubral právě tyto dva soubory.
+
 ## [4.2.0] — 2026-09-25
 
 ### Added — služba deklaruje své rekurence a mluví s plánovačem jednou kolejí (d.833, d.840)
@@ -94,6 +839,7 @@ Při té příležitosti se rozšířil tvar `id` v záznamu rekurence: schéma
 na malá písmena a pomlčky, což je přísnější než konzument (jakýkoli řetězec 1–255 znaků) a
 odmítalo by to konvenci prvního volajícího `<source_uuid>:<cookbook_ref>`. Nově se odmítá
 jen bílé místo, které by z klíče udělalo větu.
+
 ### Changed — port `registerRecurring()` klíč, který požadavek nedeklaruje, odmítne (d.864b)
 
 `createSchedulerPublisher(…).registerRecurring()` bral jen pojmenované klíče a cokoli
@@ -224,6 +970,28 @@ deklarace není pokyn k vytvoření — zakládá ji dál vlastník prefixu). Pr
 z toho plyne, že povinný klíč `MONITORING_RESOURCE_EXCHANGE` může po re-pinu
 zmizet stejně jako pět jmen před ním.
 
+### Added — výměna `telemetry.exchange` má šablonu v `queueConfig` (d.708) — doplněno 27. 9. 2026, změna vyšla bez záznamu
+
+`telemetry.exchange` žila v `src/config/queueConfig.js` jen v komentáři, zatímco jméno mělo
+tři vlastníky: konstantu v monitoring konzumentu (`infra/api_monitoring/src/consumer/topology.js`)
+a výchozí hodnotu v obou publikátorech `@onlineapps/monitoring-core`. Sekce `telemetry` nese
+nově záznam `exchange` = `{ type: 'exchange', exchangeType: 'topic', durable: true }`, bez
+argumentů a bez dead-letter cesty; jméno se skládá `queueConfig.queueName('telemetry',
+'exchange')`. Typ a trvanlivost jsou změřené na všech zakládajících stranách, které volaly
+`assertExchange(<jméno>, 'topic', { durable: true })` — broker obě vlastnosti porovnává při
+každé deklaraci, jiná hodnota by byla 406 PRECONDITION-FAILED. Klasifikace prefixu
+`telemetry.` se nemění; producenty ani konzumenta tahle změna nepřepíná. Veřejný export
+jména (`topology.telemetryExchange`) přišel až po vydání — viz `[Unreleased]`, d.708b.
+
+### Changed — šablona výměny `registry.changes` nese typ `fanout` (d.712) — doplněno 27. 9. 2026, změna vyšla bez záznamu
+
+`registry.changes` byla jediná výměna v `queueConfig` bez `exchangeType`, takže z ní
+zakladatel deklarovat nemohl — typ je jedna ze dvou vlastností, které broker porovnává při
+každém `assertExchange`. Šablona nově nese `exchangeType: 'fanout'`, hodnotu změřenou
+u jediného zakladatele (`@onlineapps/conn-orch-registry`, `src/registryEventConsumer.js`:
+`assertExchange(<jméno>, 'fanout', { durable: true })`, binding vzorem `''`). Argumenty ani
+dead-letter cestu výměna nezískává; zakladatele změna nepřepíná.
+
 ## [4.0.1] — 2026-09-17
 
 ### Fixed — zrušení konzumenta brokerem přestalo být tiché (d.605)