blun-king-cli 9.1.597 → 9.1.600

package/standard-skills/translate-native/README.md

@@ -107,6 +107,1339 @@ For a translation, use `"task_kind": "translation"`, include the complete `sourc
 
 This covers every human language and writing system, not only German umlauts. The same contract protects Swedish `å/ä/ö`, Czech `č/ř/š/ž`, Spanish accents and punctuation, Vietnamese tone marks, Greek, Cyrillic, Arabic, Hebrew, Indic scripts, Chinese, Japanese, Korean, and languages not named here. Deterministic checks are intentionally conservative and cannot prove perfect native wording; the native-language workflow and human review remain necessary where consequences are material.
 
+### Version 6.155.0: durable general locale-policy invalidation
+
+Version 6.155.0 binds every signed CMS release proof to the exact current
+target-locale quality profile, including ordinary website copy. The compact
+`{locale, version, sha256}` binding makes the language-policy generation that
+governed translation and both review passes independently verifiable at the
+publication boundary.
+
+The release service and reference CMS receiver re-resolve that profile before
+approval lookup, host commit, active read, health, and idempotent replay. Locale
+substitution, profile drift, and resolver failure block fail-closed without
+overwriting the last known good content; obsolete content remains safely
+tombstonable. Commercial content keeps its separate commercial quality binding
+in addition to this universal language-profile proof.
+
+### Version 6.154.0: durable commercial locale-policy invalidation
+
+Version 6.154.0 revalidates the exact commercial quality-profile binding for
+the target locale whenever signed release evidence is consumed. A stored CMS
+bundle can no longer remain active after its CLDR, morphology, terminology, or
+evaluation generation has changed merely because its three-field binding is
+still structurally valid.
+
+The check applies before approval lookup, CMS commit, active read, health, and
+idempotent replay. Resolver failure and stale or substituted profile bindings
+block with the stable release-evidence error; non-commercial evidence remains
+strictly null and does not invoke the commercial resolver. The release-evidence
+capability contract advertises the exact-current-locale requirement.
+
+### Version 6.153.0: CMS-visible resolution policy
+
+Version 6.153.0 exposes the exact current public commercial-review resolution-
+contract SHA-256 in every commercial CMS release proof, including offers whose
+first-pass evidence was already `verified`. A CMS can therefore prove which
+human-review and independent-model escalation policy governed a signed approval
+without decoding opaque job identities or receiving private review data.
+
+Release evidence and its advertised capability contract advance together. The
+release service and reference receiver reconstruct the current content-free
+contract and reject missing, stale, substituted, or self-rehashed digests before
+host commit. Non-commercial evidence requires `null`; only unresolved offers
+continue to carry a separate resolution result.
+
+### Version 6.152.0: plan-bound resolution policy
+
+Version 6.152.0 binds the exact public commercial-review resolution-contract
+SHA-256 into every commercial plan, per-locale job, and idempotency identity.
+Resolution-policy changes therefore create new work identities instead of
+silently reinterpreting persisted jobs under newer human-review or independent-
+model rules.
+
+The queue revalidates the binding before leasing work, and the worker
+reconstructs the complete current content-free contract before loading assets
+or contacting the configured provider. The digest continues through the worker
+result, quality-evidence request, receipt verification, and signed approval.
+Missing, stale, substituted, or self-rehashed bindings fail closed; non-
+commercial jobs and results keep the field absent or `null` as their respective
+schemas require.
+
+### Version 6.151.0: reviewer-visible resolution contract
+
+Version 6.151.0 supplies unresolved commercial quality reviewers with the
+complete public, content-free resolution contract alongside its SHA-256. The
+contract declares the exact human and independent-model resolution methods,
+provider-separation rule, receipt binding, ordered offer scope, and excluded
+private content without exposing source text, target text, prices, brands,
+reviewer prose, or identities.
+
+The full contract and digest are bound into the deterministic evidence-request
+identity and canonical HTTP payload. The coordinator and transport adapter
+independently reconstruct the current contract before provider access, so a
+missing, stale, substituted, or merely self-rehashed object fails closed before
+authentication or network traffic. Verified commercial results and
+non-commercial requests require both fields to be `null`.
+
+### Version 6.150.0: reviewer-visible routing-contract lineage
+
+Version 6.150.0 supplies the exact public offer-routing-contract SHA-256 to
+the external quality-evidence provider for every commercial result, including
+already verified results that intentionally carry no private offer route. The
+digest is part of the deterministic evidence-request identity and the exact
+canonical HTTP payload. It therefore matches the field the provider must bind
+into its quality receipt without relying on separate capability discovery.
+
+The coordinator and HTTP adapter independently reconstruct the current public
+contract before provider access. A missing, stale, substituted, or merely
+self-rehashed digest fails closed; non-commercial evidence requests require
+`null`. The full routing contract and private Unicode spans remain conditional
+on targeted review, and no price, brand, source text, or target text becomes
+public evidence.
+
+### Version 6.149.0: signed routing-contract lineage
+
+Version 6.149.0 carries the exact public offer-routing-contract SHA-256 from
+each commercial locale job into the worker result, every quality-receipt
+binding, the immutable signed approval, and the content-free CMS release
+evidence. Each boundary reconstructs or compares the current contract before
+accepting the value. Missing, stale, substituted, or merely self-rehashed
+bindings therefore fail closed before signing or publication.
+
+Non-commercial results, receipts, approvals, and release evidence require the
+field to be `null`. The digest reveals no price, brand, source text, target
+text, offer identifier, or private route; the route itself remains confined to
+the authorized review path.
+
+### Version 6.148.0: routing-contract-bound job identity
+
+Version 6.148.0 binds the exact public offer-routing-contract SHA-256 into
+plan v4, every commercial locale job v4, and their deterministic job,
+idempotency, and plan identities. A change to Unicode offset, region coverage,
+privacy, or authority semantics therefore creates new work even when the
+commercial profile and review-evidence contract are otherwise unchanged.
+
+The worker reconstructs both installed contracts before the first provider
+call. Missing, stale, substituted, or merely self-rehashed routing bindings
+fail closed; queue health and lease validation inherit the same canonical job
+check. Non-commercial jobs omit both commercial digests, and private routes,
+prices, brands, source text, and target text remain outside queue metadata.
+
+### Version 6.147.0: exact routing contract for external review
+
+Version 6.147.0 sends the complete, content-free offer-routing contract with
+each unresolved commercial quality-evidence request. An independent reviewer
+therefore receives the exact Unicode code-point, exclusive-end, length,
+registry-order, overlap, privacy, and authority semantics together with the
+private route instead of relying on separate capability discovery.
+
+The coordinator and HTTPS adapter independently reconstruct the trusted
+contract before authentication or network access. The full contract enters the
+deterministic request ID; stale, substituted, or merely self-rehashed objects
+fail closed. Verified commercial and non-commercial requests require both the
+route and routing contract to be `null`, and no price, brand, offer ID, source
+text, target text, or reviewer prose enters the public contract.
+
+### Version 6.146.0: contract-bound private offer routing
+
+Version 6.146.0 publishes a separately versioned, content-free machine
+contract for the private offer-routing context. It defines exact Unicode
+code-point offsets, exclusive ends, complete text lengths, registry-order
+coverage, overlap rules, privacy, and the non-authoritative trust boundary.
+
+Every private route now carries the trusted contract SHA-256. The worker,
+evidence request, receipt verifier, release gate, benchmark boundary, and CMS
+capability reader independently reconstruct it; a stale, substituted, or merely
+self-rehashed contract blocks before provider access or approval. Only the
+contract is public. Actual spans, offer identifiers, texts, prices, brands, and
+reviewer prose remain private and are absent from CMS release evidence.
+
+### Version 6.145.0: actionable private offer review routing
+
+Version 6.145.0 turns each opaque review-required offer index into an
+actionable provider route without weakening the public CMS boundary. The
+worker derives a private context containing only ordered numeric indexes,
+exact source and target lengths, and validated Unicode code-point regions.
+
+The context is required only for unresolved commercial summaries. It is bound
+into the durable evidence request identity and every quality, independent-model,
+or qualified-human receipt verification, but is excluded from signed public
+release evidence. Missing, reordered, overlapping, empty, out-of-range, or
+extra-field routes block before provider access or approval; configured offer
+IDs, extracted text, prices, brands, and reviewer prose are never copied into
+the routing context.
+
+### Version 6.144.0: targeted per-offer commercial review
+
+Version 6.144.0 retains the exact unresolved offer scope after source-aware
+commercial review. The content-free summary identifies affected offers only by
+their zero-based registry positions for each dimension, and the independent
+model or qualified human resolution must echo that complete ordered scope.
+
+Configured offer identifiers, prices, brands, source text, target text, and
+reviewer prose remain private. Missing, reordered, duplicated, out-of-range, or
+cross-dimension scope fails closed through the provider-neutral HTTP adapters,
+signed release evidence, and CMS boundary. Dimension-level uncertainty without
+a registered offer remains routable without inventing an identity.
+
+### Version 6.143.0: complete per-offer commercial evidence
+
+Version 6.143.0 requires every commercial review dimension to carry exactly
+one verdict for every registered offer, in registry order. A dimension can no
+longer pass globally after reviewing only one price, discount, tax statement,
+term, or condition while silently omitting another offer.
+
+The validator derives the global dimension verdict from the per-offer matrix,
+requires equivalent, changed, and uncertain offer verdicts to have their own
+offer-bound evidence, and rejects duplicates, omissions, reordered offers, and
+inconsistent aggregate statuses. The separately hashed contract, commercial
+profile, evidence binding, and summary generation advance together, so queued
+or cached results under the previous shape fail closed without numeric regexes
+or source-locale formatting assumptions.
+
+### Version 6.142.0: stale-job quarantine without head-of-line blocking
+
+Version 6.142.0 quarantines a bounded batch of up to 24 consecutive obsolete
+queue jobs inside one claim transaction and continues to the first current job
+within that batch. A complete stale EU-locale plan therefore cannot consume 24
+service ticks or hold valid work behind it; every quarantined job remains
+content-free, terminal, and at zero attempts, with no cache, asset, or provider
+access.
+
+The batch decision remains fail-closed and atomic. If later validation is
+unavailable, raises unexpectedly, or mutates a decoded payload, all quarantine
+and lease changes roll back so recoverable work stays pending.
+
+### Version 6.141.0: current job bindings before lease
+
+Version 6.141.0 revalidates a durable queue job against the exact current
+planner and worker contract before granting a lease. A canonical but obsolete
+commercial job is marked terminal with the content-free
+`job_binding_invalid` reason without consuming an attempt, resolving assets,
+consulting translation memory, or reaching a provider.
+
+The queue uses its current local worker contract by default, while the runner
+injects the exact worker instance it will execute. Expected binding rejection
+is terminal; an unavailable, failing, or payload-mutating validator rolls back
+the transaction and leaves the job pending for safe operator recovery.
+
+### Version 6.140.0: current job bindings in read-only health
+
+Version 6.140.0 makes the content-free health monitor revalidate every durable
+queue job against the exact current planner and worker contract. A commercial
+job can no longer remain health-green after its review-evidence contract has
+changed merely because the stored JSON and its payload hash still agree.
+
+Stale or substituted bindings block overall health with
+`queue.job_binding_invalid` through local validation. The check is read-only,
+independent of provider health, keeps source and target text out of diagnostics,
+and leaves valid non-commercial and current commercial jobs unchanged.
+
+### Version 6.139.0: evidence-contract-bound commercial job identity
+
+Version 6.139.0 binds the exact public commercial review-evidence-contract
+SHA-256 into plan v3, every commercial job v3, its deterministic job and
+idempotency key, and the overall plan ID. A change to offer-registry, Unicode
+span, dimension, or verdict semantics now creates new work identity even when
+the parent commercial profile identifier remains stable.
+
+Before any provider access, the worker joins the job-bound digest to the
+separately verified full contract supplied to source-fidelity review. Missing,
+stale, or replaced bindings fail closed; non-commercial jobs remain free of
+commercial metadata and no provider is hardwired.
+
+### Version 6.138.0: exact provider-side commercial evidence contract
+
+Version 6.138.0 gives the source-aware commercial fidelity provider the exact,
+content-free, SHA-256-bound review-evidence contract rather than only an
+illustrative response object. The contract covers the offer registry, Unicode
+span semantics, ten commercial checks, limits, verdict invariants, and
+fail-closed trust boundary. It is part of the deterministic provider-request
+hash and remains absent from transcreation and source-blind native review.
+
+Before any provider call, the worker verifies the contract against the
+installed public commercial profile and rejects even a consistently rehashed
+substitute. This improves interoperability without hardwiring a provider,
+publishing project prices or brands, or treating structural validation as
+evidence of semantic truth.
+
+### Version 6.137.0: contract-bound commercial review lineage
+
+Version 6.137.0 binds the exact published commercial review-evidence-contract
+SHA-256 into the private evidence hash and content-free review summary. That
+closed summary now carries the same digest through worker results, durable
+quality-evidence requests and IDs, receipt verification, signed approvals,
+translation-memory lookups, and CMS release evidence.
+
+A prior report or summary cannot remain valid after the evidence structure,
+offer rules, Unicode span semantics, or verdict invariants change. Missing,
+stale, or substituted contract digests block fail-closed before network access,
+signing, cache reuse, or CMS publication; no private report content is exposed.
+
+### Version 6.136.0: public commercial evidence contract
+
+Version 6.136.0 publishes the complete commercial evidence shape as a
+separately versioned and SHA-256-bound machine contract. CMS backends,
+source-fidelity providers, and the portable checker now discover the same
+closed fields, limits, Unicode span semantics, offer-region rules, verdict
+invariants, and exact ten-dimension order from one provider-neutral source.
+
+The trusted CMS boundary rejects missing, altered, reordered, or merely
+self-rehashed evidence contracts before returning capabilities. The contract
+explicitly grants no publication authority and makes no semantic truth claim:
+uncertain amounts, conditions, or native interpretations still require an
+independent model or qualified native-domain reviewer.
+
+### Version 6.135.0: offer-bound commercial evidence
+
+Version 6.135.0 replaces free-form offer labels in commercial review evidence
+with a versioned registry of unique offer identifiers and their ordered,
+non-overlapping source and target regions. Every price, qualifier, interval,
+condition, and assignment span must be contained in the regions declared for
+that exact offer, so a reviewer cannot hide a cross-offer swap behind a valid
+but unrelated label.
+
+An offer may own multiple discontiguous regions for linked footnotes and
+conditions. Every declared offer still needs exactly one matched assignment
+item; unknown identifiers, overlapping ownership, missing assignments, and
+cross-offer spans block deterministically. The registry validates evidence
+ownership, not semantic truth: uncertain boundaries or equivalence continue to
+require an independent model or qualified native-domain review.
+
+### Version 6.134.0: durable CMS publisher authorization
+
+Version 6.134.0 retains the original canonical publisher signature beside
+every active CMS publication and revalidates it on commit, rendering, health,
+and idempotent replay. Rewriting stored payload and release evidence and then
+recomputing their unkeyed hashes can no longer create an apparently authorized
+bundle after receiver restart.
+
+The SQLite schema migrates from v1 to v2 without inventing missing authority.
+An active legacy row without its original signature remains stored but blocked
+and unhealthy until the trusted source replaces or tombstones it. Deletion uses
+the existing structural-only path, so unsafe legacy content cannot become
+undeletable. Superseded and deleted rows scrub the retained signature together
+with target prose.
+
+### Version 6.133.0: continuously authorized CMS bundles
+
+Version 6.133.0 closes the durable authorization gap after CMS acceptance.
+The reference receiver injects its canonical release-evidence validator into
+the SQLite store, which revalidates every active localization against the
+current contract and approval expiry on reads, health checks, and idempotent
+publication replay. Restarting or upgrading the receiver cannot silently keep
+serving a stale authorization.
+
+Expired or contract-stale target content remains blocked without replacing the
+last stored bytes. Tombstone registration and deletion use a structural-only
+path, so an invalidated bundle can still be removed atomically and cannot trap
+unsafe content behind the fail-closed gate.
+
+### Version 6.132.0: contract-bound release evidence
+
+Version 6.132.0 binds the exact SHA-256 of the machine-readable release-evidence
+contract into every signed approval and content-free CMS release proof. A delayed
+or archived approval therefore cannot be reinterpreted or rewrapped under a
+newer field, lineage, commercial-scope, or privacy contract.
+
+The v7 release-evidence validator rejects a missing, malformed, stale, or
+substituted contract digest before publication or receiver host commit. The
+durable receiver preserves the exact bound proof, and the same fail-closed rule
+applies to commercial and non-commercial localizations.
+
+### Version 6.131.0: machine-readable release-evidence contract
+
+Version 6.131.0 publishes a separately hashed, provider-neutral contract for
+the content-free release evidence inside the signed CMS capabilities. It fixes
+the exact field order, SHA-256 and lineage bindings, commercial nullability,
+signed container, and excluded private content so an integration does not need
+to reconstruct those rules from prose.
+
+The runtime validates the contract against its private canonical registry on
+every capability read. Missing, reordered, altered, or merely self-rehashed
+contracts block the complete capability response and publication remains
+fail-closed before any CMS commit.
+
+### Version 6.130.0: public evidence lineage
+
+Version 6.130.0 carries the canonical quality-evidence request ID and revision
+from the verified signed approval into the closed, content-free public release
+evidence. A downstream CMS can now audit and policy-gate the exact evidence
+generation without access to provider receipts or private review state.
+
+The release-evidence schema advances to v6. Missing or malformed lineage blocks
+before host commit, while any change to the already signed publication bytes
+fails authentication. The durable receiver preserves the exact fields and
+still exposes no source text, target text, raw receipt, reviewer identity, or
+reviewer prose.
+
+### Version 6.129.0: evidence-context-bound approval
+
+Version 6.129.0 carries the canonical quality-evidence request ID and evidence
+revision into every purpose-specific receipt-verification binding and into the
+signed durable approval. A provider cannot relabel an otherwise valid quality,
+qualified-human, or independent-model receipt under a newer evidence envelope.
+
+The receipt binding advances to v5 and the signed approval to v5. Missing,
+malformed, stale, or substituted evidence context blocks before verifier or
+signer access; changing either dimension also derives a new verifier HTTP
+idempotency key. Raw receipts remain outside durable translation memory.
+
+### Version 6.128.0: derived quality-evidence identity
+
+Version 6.128.0 makes the quality-evidence request ID independently
+derivable at every local and network boundary. The durable lease store and
+provider-neutral HTTPS adapter now recompute the ID from the same exact
+versioned field set after validating the complete source and target hashes.
+
+The evidence request advances to v8. A random ID, a stale ID retained after
+changing locale, policy, profile, provider, confidence, result or commercial
+contract, and an ID derived from an incomplete field set all block before a
+database row, authentication callback or network request. The request ID,
+canonical request digest and receipt binding remain separate proofs.
+
+### Version 6.127.0: contract-bound commercial evidence
+
+Version 6.127.0 binds every unresolved commercial evidence request and receipt
+to the exact advertised review-resolution contract SHA-256. The binding enters
+the deterministic request ID, the provider-neutral HTTPS request, each receipt
+verification context, and the signed durable approval.
+
+The evidence request advances to v7, the receipt binding to v4, and the signed
+approval to v4. A missing, stale, self-selected, or non-commercial contract
+digest blocks before authentication, provider transport, approval, or CMS
+publication. Verified commercial results and all other content types require a
+null binding, so the escalation contract cannot leak into unrelated work.
+
+### Version 6.126.0: independently verifiable commercial resolution
+
+Version 6.126.0 makes targeted commercial-review resolution independently
+verifiable at the CMS boundary. Each content-free resolution now binds the
+exact commercial profile, the advertised resolution-contract SHA-256, and the
+primary provider identity. An independent-model route also carries the second
+provider identity, whose provider ID must differ from the primary provider.
+
+The commercial profile advances to v8, the CMS capability generation to v7,
+the publication HTTP contract to v3, and release evidence to v5. Missing or
+altered profile, contract, primary-provider, or independence bindings block
+before CMS persistence. Qualified-human identity, raw receipts, credentials,
+reviewer prose, prices, brands, source text, and target text remain excluded.
+
+### Version 6.125.0: machine-readable commercial review resolution
+
+Version 6.125.0 publishes a separate, hashed contract for resolving uncertain
+commercial checks. It binds the exact ordered dimensions to the unresolved
+summary and distinguishes qualified-human review from an independent model,
+including the conditional provider fields and verified receipt hash without
+exposing the raw receipt, reviewer identity, prose, prices, brands, or content.
+
+The commercial profile advances to v7, the CMS capability generation to v6,
+and release evidence to v4. The release path now uses the same provider-neutral
+resolution schema advertised by discovery. Reordered or partial dimensions,
+an unexpected human provider, a non-independent model, raw-receipt exposure,
+or any rehashed contract drift blocks the entire capability response.
+
+### Version 6.124.0: locale-bound commercial review evidence
+
+Version 6.124.0 binds every commercial fidelity-evidence digest to the exact
+target locale and commercial locale-quality profile version and SHA-256, in
+addition to the commercial profile and exact source and target texts. Evidence
+from another locale or an older rendering, morphology, or evaluation generation
+therefore cannot be reused as if it covered the current job.
+
+The worker derives this binding only from the already validated job. The
+portable checker requires the same three explicit content-free inputs and
+reports them only after successful structural validation. Missing or malformed
+bindings block without provider, approval, or publication authority.
+
+### Version 6.123.0: end-to-end commercial acceptance binding
+
+Version 6.123.0 requires every accepted commercial submission to prove that
+the downstream website used the same 24-locale rendering-registry generation
+that the CMS acknowledged at enqueue. A merely well-formed and self-consistent
+website capability binding is insufficient when its commercial registry hash
+differs from the durable caller-owned contract.
+
+The equality is enforced before acceptance, revalidated from SQLite after
+restart and during health checks, and independently checked by the HTTP edge
+and provider-neutral reference client. The versioned capability and OpenAPI
+contracts advertise the invariant explicitly. Ambiguous or substituted
+generations remain fail-closed without exposing price, brand, source, or target
+content.
+
+### Version 6.122.0: durable commercial contract acknowledgement
+
+Version 6.122.0 carries the exact commercial profile and 24-locale registry
+acknowledgement through the caller-owned outbox, leases, retries, restarts,
+queue responses, status reads, lifecycle responses, OpenAPI contract, and
+reference client. The content-free binding is now durable evidence rather than
+an ingress-only check.
+
+Every stored row is revalidated against its canonical source payload and the
+installed commercial contract before work or status can proceed. Altered or
+missing bindings block fail-closed. An exact empty schema-v1 outbox is upgraded
+transactionally; any populated legacy outbox remains untouched and blocked
+because its historic commercial acknowledgement cannot be reconstructed.
+
+### Version 6.121.0: commercial contract acknowledgement at enqueue
+
+Version 6.121.0 closes the transition from commercial-profile discovery to
+durable CMS intake. Every enqueue envelope now carries an exact content-free
+commercial contract binding. A commercial change must acknowledge the active
+profile and 24-locale rendering-registry hashes; every other content type,
+cancellation, and tombstone must carry `null`.
+
+The authenticated HTTP body, capability generation, OpenAPI 3.1 conditional,
+and provider-neutral reference client all use the same closed binding.
+Missing, stale, altered, or cross-scope acknowledgements block before runtime
+enqueue and persistence. The acknowledgement contains no amount, brand,
+product, source text, target text, credential, or publication authority.
+
+### Version 6.120.0: public commercial localization contract
+
+Version 6.120.0 carries the existing brand-neutral price and offer profile to
+the outer public CMS dispatch edge. The capability generation, separately
+scoped body-free route, OpenAPI 3.1 document, runtime, and provider-neutral
+reference client expose the exact ten semantic dimensions and all 24
+locale-specific Unicode CLDR rendering references. No project price, brand,
+product, credential, source text, or target text is part of the response.
+
+The route fetches and revalidates the live downstream website capability
+generation before returning the local contract. Its commercial-rendering hash
+must equal the bundled canonical registry; a missing, stale, substituted, or
+malformed binding blocks before serialization. The result is explicitly
+content-free and grants neither linguistic approval nor publication authority.
+
+### Version 6.119.0: verified outer lifecycle read
+
+Version 6.119.0 completes the post-intake read path for non-Python CMS
+backends. A dedicated tenant-bound operation carries the full known request
+identity through the caller-owned outbox, process-guarded runtime,
+authenticated HTTP edge, capability generation, OpenAPI 3.1 profile, and
+provider-neutral reference client. It reads the already verified downstream
+source lifecycle only after durable website acceptance.
+
+Pending, retrying, leased, and failed outer records cause no downstream read.
+The returned lifecycle keeps local dispatch status, website generation,
+sidecar generation, source generation, and source processing state separate;
+acceptance remains explicitly non-publication. Missing, foreign, substituted,
+or internally inconsistent identities and bindings fail closed.
+
+### Version 6.118.0: visible accepted website generation
+
+Version 6.118.0 carries the complete verified website capability binding from
+durable intake into the outer CMS dispatch status, authenticated HTTP edge,
+capability snapshot, OpenAPI profile, and provider-neutral reference client.
+An accepted status now identifies the exact delivery, runtime, commercial
+rendering, and terminal receiver generations that accepted the request. An
+outer dispatch row that is still pending or has failed exposes no such binding.
+
+The projection is reconstructed only from the already validated canonical
+response stored by the outbox. Its inner binding hash and delivery capability
+pin are checked again at every status boundary. Missing, altered, partially
+substituted, or prematurely populated bindings fail closed. Tests cover all
+three operations, pre-acceptance absence, authenticated status serialization,
+client-side substitution, and validated restart recovery.
+
+### Version 6.117.0: receiver-bound website delivery generation
+
+Version 6.117.0 binds the website-side durable delivery generation to the
+terminal receiver capability SHA-256 already verified by the source runtime.
+The trusted host carries that pin through the sidecar adapter, its synthetic
+contract digest, the guarded SQLite binding, and the public submission
+capability snapshot. A missing, changed, or substituted receiver generation
+now blocks restart and queue access before any downstream network call.
+
+The binding table advances to v2 and the adapter contract to v3. An exact,
+empty v1 database can migrate transactionally only when its historical v2
+adapter digest is reconstructed from the same trusted inputs. A non-empty,
+ambiguous, altered, or unbound generation remains fail-closed. Tests cover
+restart drift, in-process mutation, exact empty migration, legacy work, and
+outer capability tampering.
+
+### Version 6.116.0: receiver-bound public source projections
+
+Version 6.116.0 carries the terminal receiver capability SHA-256 through the
+source service's status and health projections, the authenticated HTTP edge,
+the provider-neutral reference client, and the outer CMS lifecycle view. A
+healthy enabled monitor now exposes the same exact digest at both service and
+component level; disabled monitoring remains explicitly `null`.
+
+The source status, health, and capability schemas advance together so old
+deployment pins cannot silently accept the expanded contract. Missing,
+substituted, malformed, or internally inconsistent receiver bindings block
+before a caller can trust the projected processing state. Tests exercise the
+real WSGI path and reject altered status, health, and outer lifecycle views.
+
+### Version 6.115.0: durable terminal-monitor capability binding
+
+Version 6.115.0 binds the source CMS's durable terminal-processing monitor to
+one exact receiver capability SHA-256. The pin is stored in the monitor schema,
+returned in content-free health, checked before status, health, and worker
+progress, and required on every accepted receiver status response. A changed
+client pin or response generation now blocks before remote state can replace
+known state.
+
+An empty v1 monitor can be transactionally adopted into the bound v2 schema.
+Existing unbound monitoring work is never guessed or relabelled: startup stays
+fail-closed until the operator resolves it under verified deployment evidence.
+Tests cover response substitution, runtime pin mutation, restart drift, empty
+migration, and non-empty legacy rejection.
+
+### Version 6.114.0: race-free terminal receiver contract
+
+Version 6.114.0 closes the capability discovery-to-operation race across the
+terminal CMS callback boundary. Every notification, status, health, readiness,
+and OpenAPI request now carries the exact freshly verified receiver capability
+SHA-256 in the authenticated
+`X-Localization-Capabilities-SHA256` precondition header. Missing and stale
+generations return `428` and `412` before durable intake or operational access.
+
+The v3 receiver capability contract and v2 OpenAPI document publish this rule
+for every non-discovery operation. Both reference clients reserve and bind the
+header, including the one-attempt notifier's deployment-pinned capability
+digest. Tests prove stale generations cannot store a notification and that all
+control routes remain read-only when their precondition fails.
+
+### Version 6.113.0: verified terminal receiver OpenAPI client
+
+Version 6.113.0 completes the provider-neutral OpenAPI path through the
+terminal receiver reference client. `openapi()` performs fresh pinned
+capability discovery, fetches the separately authenticated document, and
+reconstructs the only acceptable OpenAPI 3.1 profile locally from that exact
+generation. A substituted document cannot become trusted by recomputing its
+own hash, and generation changes between the two requests fail closed.
+
+The bounded transport now distinguishes the 16-KiB request limit from the
+advertised 1-MiB response limit, allowing the complete closed contract without
+weakening request validation. Tests cover the real large response, custom
+notification paths, self-rehashed substitutions, capability races, oversized
+responses, and read-only runtime behavior.
+
+### Version 6.112.0: capability-bound terminal receiver OpenAPI
+
+Version 6.112.0 completes the machine-readable callback contract for the
+durable CMS terminal-notification receiver. Its authenticated, separately
+scoped OpenAPI 3.1 route publishes all six active operations, including a
+custom intake path, closed request and response schemas, required binding
+headers, fail-closed error forms, and degraded monitor responses.
+
+The v2 receiver capability generation pins the OpenAPI document schema and
+operation. Every returned document and envelope is bound to the complete
+capability SHA-256, and the envelope also carries the canonical document hash.
+The route reads no inbox content, claims no processing lease, and performs no
+model or publication work.
+
+### Version 6.111.0: capability-preconditioned CMS operations
+
+Version 6.111.0 closes the capability discovery-to-operation race at the
+public CMS sidecar. Every route except capability discovery now requires the
+authenticated `X-Localization-Capabilities-SHA256` header to equal the exact
+active complete capability generation. A missing precondition returns the
+contract-bound `428`; a stale or substituted generation returns `412` before
+enqueue, status lookup, monitor access, OpenAPI generation, or other runtime
+work. The reference client reserves and supplies the header automatically and
+includes the digest in its host-authentication context.
+
+The v8 capability contract and v7 OpenAPI document publish the required header
+per operation and bind both precondition failures to their exact status and
+error code. Capability discovery remains the single authenticated bootstrap
+route and does not require knowledge of its own response digest.
+
+### Version 6.110.0: exact CMS error reasons
+
+Version 6.110.0 binds every public CMS sidecar failure reason to its exact
+route and HTTP status. The ordered error-code maps participate in the
+capability SHA-256 and are reproduced as closed per-response enums in OpenAPI.
+Bodyless discovery and monitor routes now also advertise their real `411` and
+`413` framing outcomes, so generated clients do not mistake an oversized or
+invalid `Content-Length` for an undocumented server response.
+
+The provider-neutral reference client validates the complete error envelope
+against that pinned map before exposing its status and stable remote code as
+content-free exception metadata. Unknown codes, extra fields, mismatched
+statuses, malformed JSON, and stale capability generations remain blocked.
+Only a verified advertised server failure can influence the caller's retry
+decision; no source or target content is copied into the exception message.
+
+### Version 6.109.0: executable CMS state invariants
+
+Version 6.109.0 binds the public CMS sidecar's cross-field state rules into
+the live capability generation and its OpenAPI profile. Generated validators
+can now reject a leased submission without an expiry, a non-leased submission
+with one, or an accepted submission without all remote status, attempt and
+digest evidence. Relationships that JSON Schema cannot express portably, such
+as attempt ceilings and request-identity equality, remain explicit stable
+invariant identifiers rather than disappearing into prose.
+
+Health now proves that `ok` has neither failed work nor expired leases, while a
+blocked state must have at least one of them. Readiness is a closed union:
+`ready` requires a running worker, healthy outbox and no error; `not_ready`
+requires a content-free error code. Every operation publishes its exact
+response-invariant list, which participates in the capability SHA-256 and is
+copied unchanged into OpenAPI.
+
+### Version 6.108.0: exact CMS failure contracts
+
+Version 6.108.0 makes every public CMS sidecar outcome explicit in both live
+capabilities and OpenAPI. Each operation publishes its complete bounded set of
+HTTP error statuses alongside its success status; those lists participate in
+the capability SHA-256 and are reproduced as concrete OpenAPI responses rather
+than an ambiguous `default` branch. A stale client therefore cannot silently
+miss a conflict, tenant-safe not-found result, framing rejection, or runtime
+outage while still matching the active deployment pin.
+
+Health and readiness now model their real `503` behavior precisely. The body
+may be a validated content-free degraded monitor response or a fail-closed
+error envelope, expressed as a closed `oneOf`; all other advertised non-success
+statuses accept only the error envelope. Runtime tests compare every operation,
+status code, extension, and response schema with the live capability generation.
+
+### Version 6.107.0: self-describing CMS capabilities
+
+Version 6.107.0 closes the remaining untyped discovery boundary in the public
+CMS OpenAPI profile. `CapabilitiesResponse` now references a recursively
+closed schema for the complete active capability generation: all routes,
+methods, scopes, principals, request and response schemas, limits, retry
+owners, source-event schemas, downstream pin, and fail-closed semantics are
+fixed values rather than an open object.
+
+The capability document now also carries the exact OpenAPI document schema
+version. That field participates in the capability SHA-256, so an older or
+substituted API description cannot retain the same deployment pin. Runtime
+fixtures verify every nested property, leaf value, required field, and
+`additionalProperties: false` boundary without storing customer content.
+
+### Version 6.106.0: closed CMS source payload schemas
+
+Version 6.106.0 makes the capability-bound OpenAPI document directly usable
+for CMS client generation. Its enqueue body now contains a discriminated,
+closed union for one content change, cancellation, or tombstone instead of an
+opaque payload object. Every operation has its exact runtime schema ID,
+required identity fields, positive source generation, and no unknown fields.
+
+The content-change schema includes the complete provider-neutral localization
+request: source identity and NFC text, exact BCP-47 locale, content type,
+glossary, policy, model and software versions, and an optional unique target
+set restricted to all 24 current EU locale profiles. Runtime validation remains
+authoritative for UTF-8 byte limits, canonical locale casing, and exclusion of
+the source language. The v3 capability hash binds all three payload schema IDs,
+so stale generated clients fail closed before enqueue.
+
+### Version 6.105.0: capability-bound OpenAPI discovery
+
+Version 6.105.0 publishes an authenticated, origin-free OpenAPI 3.1 document
+for all six public CMS submission sidecar operations. The document is built
+from the freshly validated capability generation and fixes every method, path,
+scope, principal type, request and response schema, transport limit, retry
+owner, and fail-closed publication semantic. It contains no deployment origin,
+tenant identity, website content, provider choice, or credential value.
+
+The HTTPS reference client fetches the live capability document before the
+OpenAPI route and reconstructs the expected document from its two immutable
+deployment pins. A substituted document still blocks when an attacker changes
+it and recomputes its own hash. This gives CMS generators a machine-readable
+contract without allowing discovery to weaken authentication, idempotency,
+tenant isolation, or the rule that intake does not authorize publication.
+
+### Version 6.104.0: contract-pinned public submission sidecar client
+
+Version 6.104.0 gives non-Python CMS and website backends a provider-neutral
+HTTPS reference client for all five public-submission sidecar routes. Before
+every enqueue, status, health, or readiness operation, it discovers and exactly
+validates the live contract against separate immutable pins for the sidecar and
+the downstream public website capability generation. A self-rehashed old or
+altered contract therefore blocks before a write.
+
+Authentication receives the exact method, origin, path, scope, body hash, and
+request identity but cannot replace framing, idempotency, or source-payload
+headers. Every request has one bounded transport attempt, redirects are
+terminal, and retry scheduling remains with the caller. Responses are closed,
+content-free shapes bound to the full tenant identity, all three retry budgets,
+and both capability generations; private additions, substituted identities,
+or inconsistent health and readiness states fail closed.
+
+### Version 6.103.0: authenticated public submission sidecar
+
+Version 6.103.0 exposes the process-owned CMS submission runtime to non-Python
+backends through a strict HTTPS/WSGI boundary. Five separately scoped routes
+cover durable enqueue, tenant-bound status, operator health, worker readiness,
+and canonical capability discovery. Authentication receives the exact request
+body hash before JSON parsing; tenant writes additionally bind the authenticated
+site, idempotency key, and canonical source-payload hash.
+
+The enqueue route accepts work only while the supervised worker is ready and
+returns HTTP 202 only after the caller-side SQLite commit. Exact replay remains
+idempotent, while changed content or any changed retry ceiling conflicts.
+Status requires the complete operation, request, event, site, and payload
+identity; foreign tenants and mismatched identities are indistinguishable from
+missing work. All responses are independently shape-checked and content-free,
+and explicitly state that durable website intake grants neither localization
+approval nor publication authority.
+
+### Version 6.102.0: supervised public submission runtime
+
+Version 6.102.0 turns the caller-owned public submission outbox into a safe
+production composition root. It validates the client capability pin, retry
+policy, worker identity, clock, loop timing, and any existing SQLite generation
+before operational schema mutation. The resulting process-owned runtime uses an
+owner-only identity-guarded database, serializes connection access, and checks
+client, file, parent-directory, process, and schema identity around every call.
+
+The optional hosted factory owns one supervised non-daemon worker. Managed
+intake is accepted only while that worker is alive; readiness reports worker,
+outbox, and exact capability generation without content. Shutdown signals and
+joins the worker before closing SQLite, and a timed-out network call leaves the
+database open for deliberate recovery. Restarts resume committed requests,
+while permission changes, links, inode replacement, schema injection,
+capability drift, and post-fork use block before transport.
+
+### Version 6.101.0: durable public submission handoff
+
+Version 6.101.0 gives CMS and website backends a caller-owned durable outbox
+for the public submission client. Each complete change, cancellation, or
+tombstone is validated and committed to SQLite before network access, together
+with its canonical payload hash, idempotency identity, exact public capability
+generation, and three independent retry ceilings.
+
+One token-bound lease performs one client call. Explicitly retryable transport
+failures use bounded durable backoff; permanent failures and exhausted attempts
+remain visibly blocked. A crash after remote acceptance replays the identical
+request after lease expiry, while stale claims, changed contracts, altered
+payloads, database drift, and foreign response schemas fail closed. Local
+`accepted` means only that the website edge durably accepted the request; it
+never grants linguistic approval or publication authority.
+
+### Version 6.100.0: contract-pinned public submission client
+
+Version 6.100.0 makes the complete public website submission edge directly
+usable through one provider-neutral HTTPS reference client. Before every
+change, removal, tenant progress read, or operator probe, the client discovers
+and validates the exact live v5 capability snapshot against its deployment
+pin; path, scope, schemas, retry ownership, generation hashes, and explicit
+non-publication semantics cannot drift independently.
+
+All writes bind their canonical source-payload hash and idempotency identity;
+all reads bind the complete known tenant and payload identity. Health and
+readiness remain separate site-free operations. Authentication cannot replace
+transport-owned headers, responses are revalidated against every nested
+generation, and redirects or hidden client retries are forbidden. Invalid
+input and stale contracts block before the operational request, while network
+retry decisions stay content-free and caller-owned.
+
+### Version 6.99.0: authenticated public pipeline monitoring
+
+Version 6.99.0 exposes separate provider-neutral HTTPS operator reads for the
+complete website-to-source health and readiness projections. Both routes are
+body-free and content-free, use distinct scopes, and authenticate before any
+runtime, queue, or downstream access.
+
+The boundary independently validates the website and sidecar intake state,
+the source-service state, every capability generation and both runtime
+bindings. Health never substitutes for readiness, neither response identifies
+a tenant or includes website content, and neither grants publication
+authority. Malformed counters, contradictory component states, altered
+bindings, or unavailable downstream evidence block fail-closed.
+
+### Version 6.98.0: authenticated public submission progress
+
+Version 6.98.0 completes the public submit-and-observe path with separate,
+provider-neutral HTTPS reads for durable acceptance status and the full source
+localization lifecycle. Every lookup is bound to its authenticated site,
+operation, request and event identities, and exact source-payload SHA-256
+before runtime access.
+
+The boundary independently validates the complete content-free runtime
+projection, including retry counters and pinned capability generations. A
+foreign tenant is indistinguishable from a missing submission; malformed,
+substituted, or cross-bound downstream state fails closed. Acceptance and
+source processing remain separate, and neither response grants quality
+approval or publication. The v4 capability snapshot advertises both live
+read routes, scopes, request/result schemas, and response envelopes.
+
+### Version 6.97.0: authenticated public website submission
+
+Version 6.97.0 exposes the website-owned outer outbox through two provider-
+neutral HTTPS write routes for one change or one cancellation/tombstone. Each
+request binds its authenticated principal to the exact site, canonical body
+hash, source-payload hash, idempotency identity, and separate website-delivery
+and source-processing retry ceilings before touching runtime state.
+
+The hosted website worker and the pinned commercial capability generation must
+both be ready. HTTP 202 is returned only after the immutable outer-outbox row
+has been committed; exact retries reuse that row and changed content or retry
+policy conflicts fail closed. The content-free acknowledgement keeps website
+acceptance distinct from sidecar/source acceptance, quality approval, and
+publication. The v3 public capability snapshot now advertises these live paths,
+scopes, schemas, and precise acceptance semantics.
+
+### Version 6.96.0: authenticated website capability discovery
+
+Version 6.96.0 exposes the complete website submission capability as a strict,
+read-only WSGI route. The route at
+`GET /v1/localization/source-delivery/submission-capabilities` requires HTTPS,
+an exact host-authenticated read scope, an empty body, and no query. The
+provider-neutral authenticator receives only canonical request metadata and
+the empty-body hash before the runtime or downstream sidecar is contacted.
+
+The response admits only the exact V6.96 operation, retry, semantics, and
+durable-generation fields and rechecks their canonical SHA-256. Changed
+schemas, added private fields, altered publication semantics, stale hashes,
+runtime failures, and authentication failures therefore return only stable,
+content-free blocking envelopes.
+
+### Version 6.95.0: discoverable end-to-end website capabilities
+
+Version 6.95.0 adds one canonical, content-free capability snapshot at the
+outer website submission runtime. It advertises the exact change and removal
+schemas, every composed status, lifecycle, health and readiness projection,
+the three independently owned retry budgets, and the fail-closed publication
+boundary under one deterministic SHA-256. It explicitly states that this edge
+neither generates translations nor grants publication authority.
+
+The runtime validates its guarded website database generation before making a
+fresh authenticated sidecar capability request. The returned snapshot binds
+the exact live sidecar and source-service capability pins to that durable
+website generation. Local tampering therefore blocks without network access;
+remote contract substitution blocks without returning a weaker capability.
+
+### Version 6.94.0: observable website generation evidence
+
+Version 6.94.0 exposes the outer website outbox's exact, content-free durable
+generation as a canonical capability binding. The binding identifies the
+website database role, sidecar-adapter contract, source-runtime contract,
+commercial rendering registry, and their derived binding hash without
+including an endpoint, credential, tenant, source text, or target text.
+
+Every composed submission status, lifecycle, health, pipeline-health,
+readiness, and pipeline-readiness projection now carries that independently
+validated website binding alongside the existing sidecar and source evidence.
+The runtime derives it from the canonical SQLite row on every read. A changed
+adapter, malformed or substituted binding, or altered database generation
+blocks locally before any operational request reaches the sidecar.
+
+### Version 6.93.0: local-first website restart preflight
+
+Version 6.93.0 validates an existing outer website outbox locally and read-only
+before the authenticated sidecar preflight can make a network request. File
+ownership, mode and identity, the base outbox schema, the canonical generation
+table, its role-specific row, and its derived digest must all match the exact
+adapter, source-runtime, and commercial rendering-registry generation.
+
+A changed generation, altered schema, malformed binding, unsafe file, or
+non-empty unbound legacy outbox now blocks with a stable content-free reason and
+zero transport calls. A missing database is still created only after remote
+generation verification, while a provably empty unbound legacy database remains
+migratable and is bound only after that same verification succeeds.
+
+### Version 6.92.0: authenticated website generation preflight
+
+Version 6.92.0 closes the remaining durable generation gap at the public
+website edge. The owned HMAC submission composition now requires the expected
+source-runtime and commercial rendering-registry hashes, verifies both through
+the authenticated sidecar source-readiness route, and opens no website database
+until that exact content-free binding is proven.
+
+The verified values become part of the sidecar-adapter contract and the outer
+website outbox's role-specific SQLite binding. Missing, partial, malformed,
+stale, or substituted generations block fail-closed before database creation;
+pending website work can resume only with the same adapter, runtime, and price
+format generation. Direct low-level adapter use remains compatible and
+deliberately unbound unless both generation pins are supplied together.
+
+### Version 6.91.0: durable sidecar generation binding
+
+Version 6.91.0 durably binds the source-delivery sidecar database to the exact
+sidecar contract, verified source-runtime capability generation, and commercial
+rendering-registry generation. Every restart validates canonical role-specific
+metadata and its derived digest before queue or network access. Pending work can
+therefore resume only under the generation that accepted it.
+
+An empty unbound legacy outbox may be adopted atomically. A non-empty unbound
+outbox, changed capability generation, altered binding record, malformed table,
+or attempt to reopen a bound production database without generation pins blocks
+fail-closed. Version 6.92 extends the same generation guarantee to the outer
+website database.
+
+### Version 6.90.0: authenticated source runtime binding
+
+Version 6.90.0 carries the verified, content-free commercial capability
+generation across the authenticated source-service boundary. Production HTTP
+startup now requires the existing signed capability preflight before any
+database is created. Capabilities, writes, status, health, and readiness all
+return the exact durable runtime and commercial rendering-registry binding;
+the pinned source client verifies it on every response.
+
+The source-delivery sidecar and owned website runtime preserve that binding as
+separate evidence through lifecycle, pipeline health, and pipeline readiness.
+Missing, malformed, replaced, or drifting bindings block before acceptance is
+reported. This closes the gap between a statically pinned HTTP schema and the
+actual commercial policy generation operating the durable queues.
+
+### Version 6.89.0: durable commercial capability binding
+
+Version 6.89.0 preserves the verified commercial capability generation across
+CMS worker restarts. The change, removal, and lifecycle databases each retain a
+canonical, role-specific binding to the complete capability and commercial
+rendering-registry digests. A restart with the same binding resumes pending
+work, including recovery from a partially completed same-binding startup.
+
+Another generation, swapped database roles, altered metadata, and non-empty
+unbound legacy queues block before service schema changes, queue access, or
+provider traffic. Empty legacy stores may be adopted deliberately. This keeps
+old price and offer work from silently crossing a policy deployment while
+preserving a safe migration path and content-free operational evidence.
+
+### Version 6.88.0: pinned durable CMS startup
+
+Version 6.88.0 carries both commercial capability pins into the durable
+source-CMS composition root. An explicit production preflight performs one
+signed capability read before any queue database is created, requires the
+complete capability and commercial rendering-registry pins, and retains only
+their public digests.
+
+Missing pins, transport failure, contract substitution, and either mismatch
+leave persistent state untouched and return stable content-free errors. The
+runtime exposes the verified binding separately and rechecks it before every
+later state transition, so an altered client cannot enqueue or deliver website
+content under another commercial contract.
+
+### Version 6.87.0: pinned commercial capability client
+
+Version 6.87.0 completes the public commercial rendering registry at the
+source-side reference client. The client now compares the complete v5
+capability shape, commercial profile, all 24 locale bindings, and the exact
+canonical rendering registry with its installed contract. A substituted
+registry remains blocked even if an intermediary recomputes every public
+digest.
+
+Deployments may additionally pin the complete capability digest and the
+commercial rendering-registry digest in the client constructor. Malformed pins
+stop before transport; mismatches stop after one response with distinct,
+non-retryable error codes. This makes contract upgrades deliberate without
+embedding project prices, brands, credentials, or content in the public
+capability path.
+
+### Version 6.86.0: public commercial rendering registry
+
+Version 6.86.0 exposes the complete set of 24 locale-exact commercial
+rendering references through the signed CMS capability contract. Every entry
+is bound to its exact commercial locale-profile version and digest, and the
+whole content-free registry has its own canonical SHA-256 digest. CMS and
+website clients can therefore discover and deliberately pin the rules they
+need instead of guessing separators, grouping thresholds, currency placement,
+or range notation.
+
+The capability contract advances to v5. It reconstructs every advertised
+registry entry from the canonical locale profile before returning any data;
+missing, reordered, altered, or rehashed entries block the whole response.
+The registry contains no project prices, brands, source or target text, or
+credentials, and its CLDR guidance still does not claim semantic equivalence.
+
+### Version 6.85.0: locale-exact commercial rendering references
+
+Version 6.85.0 binds an exact Unicode CLDR 48 number-format reference into
+every one of the 24 commercial EU-locale profiles. Providers now receive the
+resolved CLDR locale, numbering system, grouping threshold, decimal and grouping
+symbols, and decimal, percentage, currency, ISO-currency, approximation, limit,
+and range patterns in all three ordered phases. Explicit regional data is used
+for `de-AT`, `en-IE`, and `pt-PT`; the other configured locales use their CLDR
+parent data.
+
+The reference is rendering guidance, never a language-independent semantic
+proof. Meaning-preserving number words, written percentages, and equivalent
+digit forms remain valid; rounding and currency conversion remain forbidden;
+ambiguous values still require an independent model or qualified native-domain
+review. The profile generation advances to v5/v2, invalidating stale jobs,
+caches, receipts, and publication authority.
+
+### Version 6.84.0: visible commercial escalation resolution
+
+Version 6.84.0 carries the outcome of every targeted commercial escalation to
+the CMS receiver. When the primary commercial review remains unresolved, the
+signed publication evidence now identifies the exact ordered review dimensions,
+whether a qualified human or independent model resolved them, the receipt hash,
+and the independent provider binding where applicable.
+
+The release-evidence contract advances to v3. Verified commercial results and
+non-commercial content keep a null resolution, while missing, unexpected,
+cross-scope, malformed, or method-inconsistent resolution evidence blocks before
+the receiver's commit callback. Raw receipts, prices, source or target text,
+qualified-human identity, and reviewer prose remain excluded.
+
+### Version 6.83.0: commercial evidence HTTP profile binding
+
+Version 6.83.0 carries the exact locale-specific commercial quality profile
+through the provider-neutral quality-evidence and receipt-verification HTTPS
+boundaries. Commercial requests now require the nested profile identifier,
+version and digest to match their content type, commercial policy and review
+summary before authentication or network access.
+
+The evidence request and receipt-binding contracts advance to v6 and v3, so
+durable retries and opaque receipts created before this binding cannot be
+silently reused. Non-commercial traffic retains the compact base locale
+profile and rejects injected commercial scope. A complete coordinator test
+drives a Finnish offer through both adapters to signed delivery readiness.
+
+### Version 6.82.0: locale-bound commercial publication evidence
+
+Version 6.82.0 carries each approved commercial locale's exact quality-profile
+version and digest through the signed, content-free release evidence to the CMS
+receiver. The receiver recomputes the current canonical binding independently
+for every locale and blocks stale versions, substituted digests, wrong profile
+IDs, missing evidence, and cross-locale reuse before any host commit.
+
+The release-evidence contract is now v2 and remains null-scoped for all
+non-commercial content. The durable receiver store also rechecks the compact
+binding inside its atomic write transaction, so a malformed commercial bundle
+cannot replace the last known good publication even when a callback is invoked
+directly.
+
+### Version 6.81.0: locale-bound commercial quality profiles
+
+Version 6.81.0 replaces the one-size-fits-all commercial prompt binding with
+24 distinct, canonical EU-locale evaluation profiles. Each profile inherits
+the exact locale's native, fidelity, adversarial and source-reference rules,
+then adds brand-neutral checks for prices, discounts, qualifiers, tax status,
+billing, commitment, renewal, cancellation, conditions and offer assignment.
+
+The complete profile is versioned and hashed into each commercial job. The
+worker recomputes it before any provider call and supplies it independently to
+transcreation, target-only native review and source-aware fidelity review. Its
+version and digest also enter the signed quality-profile result, so profile
+changes invalidate job IDs, cached results, review evidence and publication
+authority without introducing fixed brands, products or prices.
+
+### Version 6.80.0: end-to-end processing health
+
+Version 6.80.0 adds one authenticated `submission_pipeline_health()` probe
+from the website acceptance outbox through the sidecar to every durable source
+processing queue. Website intake, sidecar delivery, and source-service health
+remain separate content-free projections, including their own counters and
+stable error codes.
+
+The probe contacts the source layer only after website and sidecar intake are
+healthy. It binds both capability generations and revalidates the complete
+source health schema rather than trusting an aggregate flag. Degraded source
+registration remains visible, while blocked queues, malformed counters,
+transport failure, HTTP/status contradictions, and contract substitution fail
+closed without exposing website content, translations, or credentials.
+
+### Version 6.79.0: end-to-end processing readiness
+
+Version 6.79.0 adds one authenticated
+`submission_pipeline_readiness()` probe from the website worker through the
+sidecar to the source localization service. It reports intake readiness and
+source-processing readiness as separate content-free objects and returns
+overall `ready` only when all three operated layers are ready.
+
+If the website worker or sidecar is not ready, the probe does not contact the
+next layer. Every successful downstream read is bound to the current sidecar
+and source-service capability hashes and revalidated against the source
+readiness schema. Stopped workers, malformed state, network failures, and
+contract substitution therefore remain fail-closed without exposing website
+content, credentials, provider responses, or translated text.
+
+### Version 6.78.0: end-to-end localization lifecycle status
+
+Version 6.78.0 adds one authenticated `submission_lifecycle()` read from the
+website-owned outbox through the sidecar to the source localization service.
+The sidecar exposes the source status only after the exact site, event, and
+payload row has reached durable source acceptance; earlier stages remain local
+and perform no premature downstream lifecycle request.
+
+The result preserves the acceptance projection and the complete content-free
+source-service status as separate nested objects. Event and tenant identity,
+payload hash, retry state, required and blocked locales, publication state,
+terminal processing, and both capability generations are validated at every
+hop. Processing or review can therefore never be collapsed into publication,
+and missing, malformed, or stale lifecycle evidence blocks fail-closed.
+
+### Version 6.77.0: end-to-end submission health
+
+Version 6.77.0 adds one content-free `submission_health()` projection across
+the website and sidecar acceptance outboxes. It validates local storage before
+network access and then uses the owned authenticated, capability-pinned client
+to retrieve the downstream snapshot.
+
+Both health objects remain distinct with their counters, due work, expired
+leases, failures, contract mismatches, and stable error codes. Overall health
+is `ok` only when both outboxes independently report `ok`; malformed state or
+contract substitution blocks fail-closed.
+
+### Version 6.76.0: end-to-end submission readiness
+
+Version 6.76.0 adds one content-free `submission_readiness()` projection for
+the complete durable website-to-sidecar intake path. It validates the owned
+website worker and outbox first; only a locally ready runtime performs the
+authenticated sidecar readiness request.
+
+The result keeps website and sidecar worker state, outbox state, stable error
+codes, and both capability pins distinct. Overall readiness is positive only
+when both durable workers are running and both outboxes are healthy. A stopped
+or malformed local runtime causes no remote request, while a blocked sidecar
+can never be hidden behind a healthy website worker.
+
+### Version 6.75.0: bound submission progress
+
+Version 6.75.0 adds one content-free `submission_status()` projection across
+the website acceptance outbox and the sidecar delivery outbox. Before local
+acceptance it reads no remote state; afterwards it authenticates the status
+request and binds the returned operation, identities, tenant, payload hash,
+capability pins, and independent retry ceilings to the persisted submission.
+
+The result distinguishes `website_acceptance`, `sidecar_delivery`, and
+`source_acceptance`. An `accepted` result means only that the source service
+durably accepted the event; it never claims that localization, review, or
+publication completed. Stale local contracts, malformed remote status, and
+changed retry policy fail closed without exposing website content.
+
+### Version 6.74.0: owned authenticated submission runtime
+
+Version 6.74.0 composes the rotating HMAC client, sidecar adapter, private
+SQLite outbox, and optional supervised worker into one website-owned runtime.
+Invalid transport, retry, worker, or contract configuration fails before the
+outbox file is created or any request is sent.
+
+The runtime preserves separate website-acceptance, sidecar-delivery, and
+source-processing retry ceilings. It exposes local acceptance and downstream
+sidecar status as deliberately different operations, routes live credential
+replacement to the exact signer used by the worker, and blocks inherited or
+closed instances before storage or network access.
+
+### Version 6.73.0: durable authenticated sidecar submission
+
+Version 6.73.0 connects the contract-pinned, rotatable HMAC sidecar client to
+the existing website-owned SQLite outbox through an explicit adapter. A source
+event is durable before the first sidecar request, survives a client or process
+crash, and is replayed with the same immutable identity until the sidecar has
+durably accepted it.
+
+The adapter keeps three retry ceilings distinct: local sidecar-acceptance
+attempts, sidecar-to-source-service delivery attempts, and source-service
+processing attempts. Its synthetic capability digest binds both remote
+contract pins and the inner delivery policy, so a configuration change blocks
+old active rows instead of silently changing their semantics.
+
+### Version 6.72.0: source-bound commercial review evidence
+
+Version 6.72.0 binds every content-free commercial review digest to the exact
+UTF-8 source and target hashes, the commercial profile generation, and the
+complete canonical review evidence. Commercial profile v3 and review-summary
+contract v2 invalidate older plans, cache entries, approvals, and capability
+pins instead of letting a structurally valid digest move between texts or
+policies. The authenticated capability registry publishes the exact versioned
+binding recipe without exposing prices, copy, spans, brands, or reviewer prose.
+
+### Version 6.71.0: composed authenticated source-delivery client
+
+Version 6.71.0 provides one provider-neutral client surface for a website
+backend to call all six source-delivery sidecar operations. Origin, sidecar
+capability pin, and downstream capability pin are supplied once and shared by
+the private rotating HMAC signer and contract-pinned HTTPS client, eliminating
+duplicate security configuration.
+
+The composed client is bound to its creating process, performs no network call
+when construction fails, and routes credential replacement to the exact signer
+used by capabilities, changes, removals, status, health, and readiness. Invalid
+replacement state keeps the last valid credential, while representations and
+errors remain content-free and secret-free.
+
+### Version 6.70.0: uninterrupted source-delivery client rotation
+
+Version 6.70.0 lets a long-lived source-delivery client replace its HMAC
+credential without restarting its worker or rebuilding its HTTP adapter. The
+provider-neutral rotating signer validates a complete replacement, serializes
+the swap with proof creation, retains the last valid signer on failure, and
+rejects inherited use from a forked process.
+
+The origin and both capability-contract pins stay immutable throughout the
+client lifetime. A safe fleet rollout overlaps old and new generations on the
+server, rotates every client, drains proofs and requests already emitted under
+the old generation, and only then retires it server-side. The client lock does
+not claim to synchronize other processes or requests already in transport.
+
+### Version 6.69.0: uninterrupted source-delivery credential rotation
+
+Version 6.69.0 lets a running authenticated source-delivery sidecar replace
+its accepted HMAC credential generations without restarting the outbox worker
+or resetting replay protection. Operators may first overlap old and new
+generations, move clients, and then retire the old generation.
+
+The runtime materializes and validates the complete replacement before taking
+effect, serializes the swap with in-flight authentication, and retains the
+last valid verifier on every rejected update. The existing replay ledger stays
+authoritative across removal and later re-addition of a generation. Storage,
+process, and lifecycle guards are checked before a replacement; errors and
+representations expose neither credentials nor secret-manager detail.
+
+### Version 6.68.0: protected authenticated sidecar runtime
+
+Version 6.68.0 turns the source-delivery HMAC reference into one deployable
+host composition. It preflights the complete authentication, worker, retry,
+contract-pin, and path configuration in memory before opening either durable
+database, then owns the hosted delivery runtime and its separate replay ledger
+as one lifecycle.
+
+The replay database is created owner-only and bound to its process, inode, safe
+parent chain, and serialized connection. Permission drift, links, replacement,
+corrupt retained nonces, inherited pre-fork state, closed runtimes, or storage
+failure make authentication unavailable before the protected outbox is read or
+written. A content-free authentication health snapshot remains separate from
+website content and credentials. Shutdown closes the delivery worker and
+outbox before the replay ledger; if a worker exceeds its bound, authentication
+stays open for an explicit supervisor decision.
+
+### Version 6.67.0: rotatable source-delivery authentication
+
+Version 6.67.0 completes a deployable authentication path for the
+source-delivery sidecar without fixing one identity provider. The reference
+client signer and server verifier bind the exact origin, method, verified path,
+route scope, body hash, tenant identities, idempotency headers, and both active
+capability-contract digests into one canonical HMAC-SHA-256 proof.
+
+Credentials carry an explicit generation and allowlist of scopes, so several
+versions can overlap during controlled rotation without granting another site.
+A caller-owned durable SQLite replay store atomically consumes every random
+nonce before protected content is parsed or persisted. Expired, future,
+replayed, altered, retired, cross-tenant, or wrongly scoped proofs fail closed;
+store and clock outages remain distinguishable, content-free retryable server
+failures. No key, credential, website text, or provider response is represented
+or stored in the replay ledger.
+
+### Version 6.66.0: contract-pinned source-delivery sidecar client
+
+Version 6.66.0 gives CMS and website backends one provider-neutral HTTPS
+reference client for the source-delivery sidecar. Every write and operational
+read first verifies the complete live capability contract against a trusted
+sidecar pin, then uses only its freshly verified method and path.
+
+The client separately pins the downstream source-service contract, binds
+changes and removals to canonical inner-payload hashes and immutable
+idempotency identities, and requires complete known bindings for status reads.
+Authentication code cannot replace reserved transport headers. Redirects,
+hidden retries, tenant substitutions, changed retry ceilings, stale capability
+digests, malformed blocked states, and private transport failures remain
+content-free and fail closed.
+
+### Version 6.65.0: website-source delivery HTTP sidecar
+
+Version 6.65.0 lets non-Python websites and CMS backends use the protected
+source-delivery runtime through one provider-neutral HTTPS/WSGI boundary. Six
+separately scoped routes accept changes and removals or expose status, health,
+readiness, and a canonically hashed machine-readable contract.
+
+Authentication is bound to the exact method, path, headers, and request-body
+SHA-256 before JSON is parsed. Writes additionally require the immutable
+request ID, canonical source-payload hash, exact website tenant, both retry
+ceilings, and a live managed worker before new work is persisted. Responses are
+independently validated and contain only durable identities, hashes, counters,
+states, and stable errors; a missing or foreign website item is
+indistinguishable. The hosted factory can construct the runtime, worker, and
+sidecar as one preflighted unit without creating storage for an invalid
+authenticator.
+
 ### Version 6.64.0: hosted website-source delivery runtime
 
 Version 6.64.0 turns the durable website outbox into an owned production
@@ -1061,7 +2394,7 @@ No deterministic linter can prove that prose is genuinely native. That is why th
 
 ### Start the MCP server
 
-For Claude Code, use the persistent runtime shown in Version 6.3 together with the current Version 6.64.0 plugin. The HTTP MCP remains available in every project through user scope, while the plugin adds the mandatory lifecycle hooks and the operating-system monitor repairs its service path and enrolled plugin cache. Check the runtime at any time with:
+For Claude Code, use the persistent runtime shown in Version 6.3 together with the current Version 6.155.0 plugin. The HTTP MCP remains available in every project through user scope, while the plugin adds the mandatory lifecycle hooks and the operating-system monitor repairs its service path and enrolled plugin cache. Check the runtime at any time with:
 
 ```bash
 python3 installer/blun_language_guard.py mcp-service status