blun-king-cli 9.1.597 → 9.1.600

package/standard-skills/translate-native/docs/PREMORTEM.md

@@ -1,5 +1,868 @@
 # Version 6 premortem
 
+## Durable general locale-policy invalidation (15 September 2026)
+
+Assume a CMS accepts correctly signed localized content and the installed
+target-locale quality policy changes before a later read or replay.
+
+- Release evidence could prove the review receipt while omitting the exact
+  language-profile generation that governed it.
+- A coherently substituted locale, version, and digest could pass a shape-only
+  check after restart.
+- Reusing the commercial-only binding would leave ordinary content uncovered
+  or incorrectly couple it to the price-and-offer policy.
+- A missing or failing general profile resolver could escape as an internal
+  error or allow an old bundle to remain active.
+
+Every release proof will carry the exact current target-locale quality profile
+and will be revalidated before approval lookup, CMS commit, active read, health,
+or idempotent replay. The general binding applies to all content; the commercial
+binding remains a separate add-on. Tests will cover all 24 EU locales, ordinary
+content, profile drift and substitution, resolver failure, durable
+read/health/replay blocking, and safe tombstone deletion.
+
+## Durable commercial locale-policy invalidation (15 September 2026)
+
+Assume a CMS accepts correctly signed commercial copy and the installed
+locale-specific quality policy changes before a later read or replay.
+
+- The stored three-field quality binding could remain structurally valid while
+  its CLDR, morphology, terminology, or evaluation generation is obsolete.
+- A coherently substituted version and digest could pass a shape-only release-
+  evidence check after restart.
+- Applying the commercial lookup to ordinary content could incorrectly block
+  unrelated active localizations.
+- A missing or failing profile resolver could escape as an internal exception
+  instead of a stable fail-closed validation result.
+
+Every commercial release proof will be compared with the exact current target-
+locale commercial quality profile before approval lookup, CMS commit, active
+read, health, or idempotent replay. Non-commercial evidence retains strict null
+bindings without invoking the commercial resolver. Tests will cover all 24 EU
+locales, profile generation drift, resolver failure, durable read/health/replay
+blocking, and safe tombstone deletion of obsolete content.
+
+## Exact routing contract at the reviewer transport (15 September 2026)
+
+Assume an independent review adapter accepts the digest on a private offer
+route but the remote reviewer never receives the contract that defines it.
+
+- Separate capability discovery could be unavailable, stale, or associated
+  with a different commercial generation when the review attempt runs.
+- A reviewer could interpret indexes or span ends differently while still
+  returning a structurally valid receipt for the supplied route.
+- A self-rehashed substitute could appear internally consistent unless the
+  trusted adapter compares the complete contract with its local canonical one.
+- Sending the contract for verified commercial or non-commercial work could
+  create an unintended review surface and weaken strict request nullability.
+
+The quality-evidence request will carry the complete, content-free routing
+contract alongside its private route only when commercial review is required.
+The coordinator and HTTPS adapter will independently reconstruct and compare
+the canonical object before authentication or transport, and request identity
+will cover the full contract. Verified commercial and non-commercial requests
+will require both route and contract to be `null`. Tests will cover exact
+transport, stale and self-rehashed substitutions, request-ID invalidation,
+strict nullability, and zero network access on rejection.
+
+## Contract-bound private offer routing (15 September 2026)
+
+Assume a host and an independent reviewer both accept a syntactically valid
+private routing object but disagree about whether offsets are bytes, Unicode
+code points, inclusive ends, registry positions, or arbitrary labels.
+
+- A schema name alone does not expose the complete routing semantics to a
+  provider-neutral adapter.
+- A changed span, ordering, privacy, or text-length rule could reinterpret an
+  archived route without changing its apparent profile.
+- A self-reported digest could legitimize a substituted routing contract unless
+  the trusted runtime reconstructs it independently.
+- Publishing the actual private spans while advertising the contract would
+  leak project structure across the CMS boundary.
+
+The public commercial capability will advertise a separately versioned,
+content-free routing contract with deterministic SHA-256. Every private route
+will carry that exact digest, and each worker, evidence adapter, receipt
+verifier, release gate, benchmark boundary, and capability reader will
+reconstruct and compare it. The advertised contract describes shapes and
+semantics only; actual spans remain private and absent from CMS release
+evidence. Tests will cover contract tampering, self-rehashing, stale route
+digests, privacy, request invalidation, and zero provider access on failure.
+
+## Private offer routing for targeted commercial review (15 September 2026)
+
+Assume a commercial summary correctly says that offer index 1 has an
+unresolved tax claim, but the independent reviewer receives only the complete
+source, target, and opaque index.
+
+- An opaque index without its source and target regions is not an actionable
+  review route and can make the reviewer inspect the wrong offer.
+- Reordered, overlapping, empty, or off-by-one Unicode spans could silently
+  relabel an offer while leaving the public summary unchanged.
+- A routing context changed after evidence acquisition could be verified under
+  the original request or receipt identity.
+- Publishing configured offer IDs, extracted text, or reviewer explanations
+  would break the content-free CMS boundary.
+
+The worker now derives a private routing context from the already validated
+offer registry: ordered numeric indexes, exact source/target lengths, and
+non-overlapping Unicode code-point regions only. The context is required only
+for unresolved commercial summaries, enters the evidence request identity and
+every receipt-verification binding, and is revalidated before network access
+and approval. Public release evidence explicitly excludes it. Tests cover
+index and span drift, out-of-range regions, request-ID invalidation, receipt
+binding, and the absence of IDs, text, and explanations.
+
+## Targeted per-offer commercial review scope (15 September 2026)
+
+Assume one offer has an unresolved tax or cancellation claim while a second
+offer in the same page is already fully verified.
+
+- A dimension-only summary cannot tell the independent reviewer which offer
+  remains uncertain and can cause either incomplete review or needless replay.
+- Publishing configured offer identifiers would disclose project product or
+  brand labels through otherwise content-free operational evidence.
+- A resolution could echo the right dimensions while silently covering a
+  different subset of offers.
+- Global evidence uncertainty and an empty offer registry still need a safe
+  route without inventing an offer identity.
+
+The content-free summary now carries ordered zero-based offer indexes for every
+dimension with offer-local uncertainty. The resolution must echo that exact
+scope, while dimension-level uncertainty remains valid with an empty index list
+when no private offer can be named. Validators reject duplicates, reordering,
+out-of-range indexes, non-required dimensions, and scope changes at every HTTP
+and CMS boundary; no price, brand, offer identifier, or reviewer prose leaves
+the private evidence.
+
+## Stale-job quarantine without head-of-line blocking (15 September 2026)
+
+Assume several durable locale jobs outlive the worker contract while valid
+work is already waiting behind them.
+
+- One stale head job per service tick could delay every current locale.
+- A 24-locale plan could require many ticks merely to expose known drift.
+- Quarantining stale rows must not consume attempts or resolve assets/providers.
+- A later validator outage must not leave a partially committed batch decision.
+
+One claim now quarantines a bounded batch of up to 24 consecutive stale jobs
+inside the same transaction and leases the first current job reached within
+that batch. This covers one complete EU-locale plan without an unbounded write
+transaction. Proven stale rows become terminal and content-free with zero
+attempts, while valid work proceeds in that same call. If any later validation
+raises or mutates a payload, the whole batch rolls back and all work remains
+recoverable.
+
+## Current job bindings before lease (15 September 2026)
+
+Assume a canonical durable job outlives the planner or worker contract that
+created it and a worker starts without first consulting service health.
+
+- The stale job could consume a lease and retry attempt before local rejection.
+- Translation memory or host-owned asset resolution could run against obsolete
+  identity before the worker validates the job.
+- A validator outage could be mistaken for proven staleness and destroy
+  recoverable work.
+- A validator could mutate the decoded payload between integrity checking and
+  execution.
+
+Every claim now replays the current job binding inside the lease transaction.
+Expected mismatch becomes terminal and content-free without incrementing the
+attempt counter; unexpected validator failure or mutation rolls the complete
+transaction back. The runner supplies its exact worker validator, and the queue
+loads the same current contract by default for direct trusted-host claims.
+
+## Per-offer commercial dimension coverage (15 September 2026)
+
+Assume a commercial page contains two offers but the source-fidelity provider
+records one global equivalent verdict and evidence only for the first.
+
+- A global pass can hide the omitted price, discount, tax statement, renewal,
+  cancellation term, or footnote of the second offer.
+- Free-form offer lists can be incomplete, duplicated, or reordered while the
+  dimension result still looks internally plausible.
+- A caller can label the aggregate status independently of its offer-level
+  findings and weaken a known defect into a pass.
+- Regex comparison cannot safely repair the gap across number words, native
+  digits, locale separators, or equivalent time expressions.
+
+The v2 evidence contract requires one ordered verdict per registered offer for
+every dimension. The validator derives the aggregate status, requires local
+evidence for every non-absent offer verdict, and rejects missing, duplicate,
+reordered, or inconsistent matrices. Contract/profile/hash generation changes
+invalidate old jobs and summaries without treating numeric spelling as proof.
+
+## Current job bindings in read-only health (15 September 2026)
+
+Assume a durable commercial job remains queued across an evidence-contract
+deployment change.
+
+- Its stored JSON and unkeyed payload hash could still be internally valid.
+- Health could report the queue as healthy until a worker leases the stale job.
+- Operators could see a green service immediately before deterministic worker
+  rejection, delaying safe replanning.
+- Drift detection must not depend on a provider response, mutate the queue, or
+  disclose source or target text.
+
+The read-only health monitor now revalidates every stored job through the exact
+current planner and worker contract. A stale or substituted binding emits only
+`queue.job_binding_invalid`, blocks overall health through local validation, and
+leaves durable state unchanged. Tests exercise a contract-only commercial
+generation change while keeping the profile identifier and stored bytes valid.
+
+## Commercial evidence-contract identity at planning (14 September 2026)
+
+Assume the public commercial review-evidence contract changed while its parent
+commercial profile identifier remained stable.
+
+- A queue could deduplicate the new work against a job created under the old
+  evidence semantics.
+- A translation-memory lookup could reuse a candidate whose source-fidelity
+  review followed stale offer, span, or verdict rules.
+- A caller could replace the job's contract digest while preserving all other
+  valid profile and locale-quality bindings.
+- The provider request could carry the current full contract without proving
+  that it is the contract that created the job identity.
+
+The v3 plan and job contracts bind the exact canonical review-evidence-contract
+SHA-256 into every commercial job, idempotency key, and plan ID. The worker
+joins that stored digest to the separately validated full fidelity contract
+before any provider access. Tests cover contract-only generation changes,
+tampered job bindings, stale jobs, and unchanged non-commercial payloads.
+
+## Commercial contract acknowledgement at enqueue (14 September 2026)
+
+Assume a CMS discovered the public price and offer profile but enqueued work
+under a different or unspecified commercial generation.
+
+- A commercial change could omit the discovered profile acknowledgement.
+- A caller could substitute one syntactically valid profile or rendering hash.
+- An ordinary content change, cancellation, or tombstone could inject
+  commercial scope and later be mistaken for reviewed offer content.
+- OpenAPI and the reference client could disagree with the runtime-only rule.
+
+The v12 public dispatch contract carries one exact, content-free commercial
+binding in every enqueue envelope. It must equal the current profile and
+24-locale rendering-registry generations for commercial changes and must be
+`null` for all other operations. The authenticated raw body, runtime,
+capability response, OpenAPI conditional, and reference client bind the same
+value; omission, substitution, stale discovery, and cross-scope injection all
+block before durable intake.
+
+## Public commercial profile at the outer CMS edge (14 September 2026)
+
+Assume a CMS discovered a price and offer contract but still published under
+the wrong commercial rules.
+
+- The public response could accidentally include project prices, brands,
+  products, credentials, or website content.
+- A locally valid profile could be returned while the live website is pinned
+  to another commercial-rendering generation.
+- A caller could skip capability discovery or reuse an earlier generation
+  between discovery and the commercial-profile read.
+- OpenAPI or a reference client could accept a merely similar profile and miss
+  a removed locale, changed semantic dimension, or added publication flag.
+
+The v11 public dispatch capability exposes the exact content-free commercial
+profile and all 24 locale rendering bindings through one separately scoped
+body-free route. The dispatcher revalidates the live website capability and
+requires its commercial registry hash to equal the canonical local registry;
+the HTTP edge, OpenAPI profile, and client then independently require exact
+closed values. Tests cover Maltese and Finnish presence, profile and registry
+tampering, capability preconditions, project-content exclusion, and explicit
+non-publication semantics.
+
+## Verified outer CMS lifecycle read (14 September 2026)
+
+Assume a non-Python CMS safely submitted an edit but learned the wrong
+downstream localization state afterward.
+
+- A lifecycle read could contact the website service before durable outer
+  acceptance, duplicating uncertainty during retries or recovery.
+- A guessed request identifier could reveal another tenant's processing state.
+- A substituted nested lifecycle could retain the request ID while changing
+  the website, sidecar, source, or terminal-receiver generation.
+- A CMS could mistake durable acceptance or a processing state for linguistic
+  approval and publication authority.
+- The runtime, OpenAPI profile, and reference client could disagree about the
+  new route or its exact fail-closed errors.
+
+The v10 public dispatch capability adds one separately scoped lifecycle read
+bound to the complete known request identity and exact capability
+precondition. The durable dispatcher permits its one downstream read only
+after a fully revalidated accepted row, and the runtime, HTTP edge, OpenAPI
+profile, and client each validate the complete nested lifecycle independently.
+Tests cover pre-acceptance zero-I/O blocking, tenant isolation, generation
+parity, content-free output, exact errors, and non-publication semantics.
+
+## Exact CMS error reasons (13 September 2026)
+
+Assume a CMS handled the advertised success and failure statuses but made an
+unsafe decision from an unverified error body.
+
+- A peer could return a real status with an invented or stale error code.
+- An open error object could carry private fields into logs or user interfaces.
+- A transient `503` and terminal `409` could receive the wrong retry treatment.
+- Bodyless routes could still emit undocumented `411` or `413` framing errors.
+- A code-map change could escape the active capability and OpenAPI hashes.
+
+The v7 capability generation binds the complete error-code set for every
+route and status. The v6 OpenAPI document emits closed status-specific enums,
+including the real bodyless framing outcomes. The reference client accepts
+remote status and code metadata only after exact envelope validation and keeps
+unknown, extra, malformed, or mismatched errors fail-closed. Tests exercise
+valid terminal and retryable errors plus forged-code and private-field probes.
+
+## Executable CMS state invariants (13 September 2026)
+
+Assume a generated CMS client rejected malformed fields but accepted a
+cross-field contradiction as a real queue or monitor state.
+
+- `leased` could be paired with no lease expiry, or another state with one.
+- `accepted` could omit one of the remote binding digests or attempt fields.
+- Health could claim `ok` while reporting failures or expired leases.
+- Readiness could claim `ready` with a stopped worker, blocked outbox, or error.
+- Portable-schema limits could leave important remaining relationships hidden.
+
+The v6 capability generation now binds an exact response-invariant list per
+operation. The v5 OpenAPI document enforces leased, accepted, health and
+readiness relationships with JSON Schema 2020-12 conditionals and publishes
+stable identifiers for non-portable attempt, identity and aggregate rules.
+Tests prove exact capability-to-OpenAPI parity and inspect every executable
+branch rather than accepting descriptive text as enforcement.
+
+## Exact CMS failure contracts (13 September 2026)
+
+Assume a generated CMS client handled successful requests correctly but made
+an unsafe retry or parsing decision on a non-success response.
+
+- A single OpenAPI `default` branch hid which failures each route can emit.
+- Conflict and tenant-safe not-found results could be mistaken for outages.
+- Health and readiness can return a valid degraded monitor body at `503`, not
+  only the ordinary error envelope.
+- New failure behavior could appear without changing the capability pin.
+
+Every operation now carries an exact ordered `error_statuses` list inside the
+v5 capability generation. OpenAPI emits only the success and those concrete
+statuses; health and readiness use an explicit `oneOf` for their two valid
+`503` bodies. Tests prove route-by-route parity, reject a catch-all response,
+and bind the new OpenAPI document generation into the capability digest.
+
+## Self-describing CMS capability schema (13 September 2026)
+
+Assume a CMS generated correct source payload types but still accepted a stale
+or structurally altered capability response.
+
+- The capability response was an open object in the OpenAPI document.
+- A generator could silently ignore missing operations, limits, or semantics.
+- An older OpenAPI document could retain the same external capability pin.
+- Nested unknown fields could disguise a route, scope, retry, or publication
+  policy change.
+
+The OpenAPI profile now describes the complete capability object recursively:
+every object is closed, every field is required, and every scalar is fixed to
+the active generation. The OpenAPI document schema itself is included in the
+v4 capability hash. Tests walk the independent runtime capability fixture and
+prove exact nested parity, closure, the response reference, and the document
+version binding.
+
+## Closed CMS source payload schemas (13 September 2026)
+
+Assume a CMS generated a client from the authenticated OpenAPI document, but
+the generated enqueue type still accepted a partial or ambiguous payload.
+
+- An opaque payload object could omit localization policy or model bindings.
+- A change could be confused with a cancellation or tombstone.
+- Unknown fields or a non-positive source generation could reach transport.
+- A stale generator could retain old payload schema IDs while discovery looked
+  current.
+
+The OpenAPI profile now publishes a closed discriminated union for all three
+runtime payloads and a complete closed localization request with the 24 exact
+EU target locales. The v3 capability generation binds each payload schema ID.
+Tests compare required and allowed fields with real runtime-valid fixtures,
+pin every discriminator mapping, and verify locale uniqueness and source-
+language exclusion metadata.
+
+## Capability-bound OpenAPI discovery (13 September 2026)
+
+Assume a CMS generated a client from the public API description, but silently
+used a stale route, wrong scope, or weaker publication and retry semantics.
+
+- A hand-maintained document could drift from the live capability generation.
+- A valid document hash could be paired with a different sidecar or downstream
+  capability digest.
+- A deployment origin, tenant identity, website content, provider, or
+  credential value could leak through discovery.
+- A substituted document could be modified and rehashed by the same untrusted
+  peer.
+
+The sidecar now builds one origin-free OpenAPI 3.1 document from the exact
+freshly validated capability object and returns hashes for both artifacts under
+a separate operator scope. The pinned reference client reconstructs and
+compares the complete document rather than trusting its advertised hash.
+Tests cover every route, method, scope, principal, generation and success
+status, absence of private values, and a self-rehashed substitution.
+
+## Contract-pinned public submission sidecar client (13 September 2026)
+
+Assume a remote CMS successfully called the durable submission sidecar, but
+used a stale contract, duplicated a write, or trusted a response belonging to
+another deployment or tenant.
+
+- A modified capability document could be rehashed and presented as current.
+- The sidecar contract hash could be confused with its downstream public
+  website capability pin.
+- Credential construction could overwrite framing, idempotency, or canonical
+  source-payload headers.
+- Redirects or implicit transport retries could duplicate a durable enqueue.
+- A plausible status, health, or readiness response could carry a substituted
+  tenant identity, retry budget, generation, or private field.
+
+The reference client now reconstructs the complete canonical sidecar contract
+from a separately supplied downstream pin and requires its digest to equal the
+deployment pin before any transport. It rediscovers that exact contract before
+each operation, reserves security-sensitive headers, performs one bounded
+attempt without redirects, and validates closed response shapes plus all
+identity, retry, state, and generation invariants. End-to-end WSGI tests cover
+all three submission kinds, exact replay, tenant isolation, altered contracts,
+response substitution, reserved-header injection, and terminal versus
+retryable failures.
+
+## Public end-to-end pipeline monitoring (13 September 2026)
+
+Assume the composed runtime was safe, but its public operational view leaked
+tenant data or let a plausible partial state appear production-ready.
+
+- A shared monitoring credential could be mistaken for a site principal and
+  expose request identities or website content.
+- A healthy intake queue could conceal a blocked source queue, or a health
+  response could be accepted as readiness.
+- Changed counters, nested bindings, or capability generations could survive
+  superficial envelope validation.
+- Authentication, transport, or source-service failure could still return a
+  stale success response.
+
+The outer WSGI boundary now provides separate body-free health and readiness
+routes with distinct operator scopes and no tenant identity. It authenticates
+before runtime access, validates every intake and source component with its
+canonical contract, preserves component state instead of averaging it, and
+requires all repeated generation bindings to agree. Tests cover live
+end-to-end success, wrong scopes and request shapes, rebound capability hashes,
+contradictory readiness, content-free failures, and strict separation from
+publication authority.
+
+## Public website capability discovery (13 September 2026)
+
+Assume the in-process website runtime had the correct end-to-end capability,
+but a public discovery boundary exposed a weaker or private variant.
+
+- A body, query, insecure transport, or wrong scope could reach the runtime.
+- Authentication could occur after the runtime had already read its database
+  or contacted the downstream sidecar.
+- A replaced runtime could add an endpoint, tenant, credential, or website
+  content under a nested field and recompute the outer hash.
+- A plausible but stale schema or changed publication semantic could be served
+  as if it were the active contract.
+
+The read-only WSGI adapter now requires exact HTTPS GET semantics and validates
+the host-supplied principal before any runtime access. It accepts only the
+closed V6.96 capability shape, exact nested operations and semantics, bounded
+retry policy, verified durable binding, and matching canonical digest. Tests
+prove authentication-before-runtime ordering, reject every alternate request
+shape and substituted contract, and require stable content-free failures.
+
+## Authenticated source runtime binding (12 September 2026)
+
+Assume a sidecar reached a healthy source API whose static HTTP contract was
+correct, but whose durable worker used another price and offer capability
+generation.
+
+- A static API digest could remain unchanged while the internal commercial
+  profile or locale-rendering registry changed.
+- A capability check followed by a write could lose the verified runtime
+  binding at the response boundary, leaving the caller unable to prove which
+  generation accepted the work.
+- Health and readiness could report a plausible service state without exposing
+  whether all three durable databases still carried the same verified binding.
+- A sidecar could accidentally discard or reshape the binding while forwarding
+  operational evidence, hiding a partial deployment mismatch from the website
+  host.
+
+The source HTTP application now requires a verified durable binding before it
+can be hosted, returns the exact content-free binding with capabilities and
+every operation, and revalidates it after runtime work. The contract-pinned
+source client requires both internal deployment pins and rejects missing,
+stale, malformed, or substituted bindings. Source delivery independently
+revalidates and forwards the same binding through health and readiness, so a
+single mismatch blocks fail-closed rather than being reduced to a healthy
+aggregate state.
+
+## Locale-exact commercial rendering references (12 September 2026)
+
+Assume every commercial provider phase received the correct language profile,
+but rendered amounts, percentages, ranges, and currency labels with conventions
+from a different EU locale.
+
+- A language name alone cannot distinguish Austrian grouping or Portuguese
+  spacing from a generic parent-language default.
+- Treating one punctuation spelling as semantic proof would reject equivalent
+  number words, native digits, or safely reformatted values.
+- An unversioned external reference could change without invalidating queued
+  jobs, cached targets, review evidence, or publication approvals.
+- Copying a formatting table by hand could silently transpose two locales or
+  normalize non-breaking spaces into ordinary spaces.
+
+Embed a canonical CLDR 48 number-format reference in each of the 24 commercial
+locale profiles, including the resolved CLDR locale, numbering system, decimal
+and grouping symbols, minimum grouping threshold, decimal, percent, currency,
+ISO-currency, approximation, limit, and range patterns. Bind the complete
+reference and its official tagged source URL into the profile digest and every
+provider phase. Treat these values as rendering guidance only: semantic review
+must accept meaning-preserving surface variants and route ambiguous values to
+independent model or qualified native-domain review. Tests cover all locales,
+exact Maltese and Finnish conventions, Austrian and Portuguese region overrides,
+Unicode spacing, profile tampering, and the ban on deterministic regex proof.
+
+## Commercial escalation evidence at publication (12 September 2026)
+
+Assume a locale reached the CMS with a commercial review summary that still
+said `review_required`, while the publication evidence did not say whether the
+targeted dimensions were resolved by an independent model or a qualified human.
+
+- A valid approval could conceal which escalation path actually satisfied the
+  unresolved amount, tax, renewal, cancellation, or condition checks.
+- A receiver that accepts `review_required` without a matching resolution could
+  mistake an unresolved primary review for publishable evidence.
+- A generic receipt hash could be copied to a different ordered dimension scope
+  unless the scope and review method remain inside the signed publication.
+- Exposing raw receipts or reviewer prose would leak sensitive review material.
+
+Advance the publication-evidence contract, add one content-free resolution only
+when the commercial summary is unresolved, and bind its exact ordered dimensions,
+review method, receipt hash, and independent provider identity when applicable.
+Require the receiver to reject missing, unexpected, cross-scope, malformed, or
+method-inconsistent resolution evidence before its commit callback. Prove both
+allowed escalation paths and keep verified commercial and non-commercial traffic
+compact with a `null` resolution.
+
+## Commercial evidence HTTP profile binding (12 September 2026)
+
+Assume a valid commercial worker result could not reach the remote quality
+service, or a remote receipt was accepted without the exact locale-specific
+commercial profile that produced it.
+
+- The worker's nested commercial profile could be rejected by an older HTTP
+  validator that only permits the three base locale-profile fields.
+- Accepting an optional nested object would let commercial requests omit it or
+  let non-commercial requests smuggle unrelated commercial scope.
+- Checking only token and digest shapes would allow a different commercial
+  profile identifier to travel beside an otherwise valid review summary.
+- Keeping the old evidence and receipt schema generations would let durable
+  retries silently reuse pre-binding requests or receipts.
+
+Version both contracts, require the exact compact commercial profile binding
+inside `quality_profile` only when `content_type` is `commercial`, and require
+its profile identifier to match the top-level commercial policy and review
+summary before any authentication or network access. End-to-end tests carry a
+real commercial coordinator request through both HTTPS adapters and prove that
+missing, extra, stale-shaped, or cross-profile bindings fail closed locally.
+
+## Locale-bound commercial publication evidence (12 September 2026)
+
+Assume a CMS replaced its current localized offer with a signed bundle whose
+generic commercial profile was correct but whose locale-specific profile was
+stale or belonged to another EU language.
+
+- A generic profile ID cannot prove that Finnish, Maltese, or another locale
+  used the intended native-language commercial quality generation.
+- Adding an optional digest would let old senders silently bypass the binding.
+- Comparing only well-formed tokens and hashes would accept a valid-looking but
+  obsolete or cross-locale profile.
+- Applying commercial requirements to ordinary content would create false
+  publication blocks.
+
+Version the release-evidence schema, require a compact commercial quality
+binding only for commercial content, and derive it from the already approved
+worker result. The CMS receiver recomputes the canonical binding for each exact
+locale before its commit callback; the durable store independently rejects
+missing or structurally inconsistent bindings during its atomic recheck. Tests
+cover all 24 EU locales, non-commercial compatibility, malformed evidence, and
+stale version, digest, and profile substitution before commit.
+
+## Locale-bound commercial quality profiles (12 September 2026)
+
+Assume a commercial job advertised one of 24 EU locales while every provider
+phase still received the same universal pricing prompt.
+
+- A locale label without locale-specific evaluation guidance could accept
+  source-shaped price labels, interval wording, CTAs or contract terms.
+- A profile omitted from the job digest could change without invalidating cache
+  entries, review evidence or publication authority.
+- A caller-controlled profile could weaken one difficult language while still
+  presenting a valid generic commercial profile identifier.
+- Passing the source into the target-only phase through profile data would
+  destroy the required independence of the native-language review.
+
+Derive one canonical commercial profile from each existing locale quality
+generation, bind the generic commercial policy plus locale profile version and
+digest, and hash the complete object into the job identity. Recompute it before
+provider access, pass the content-free profile to all three ordered phases, and
+retain its version and digest in signed release evidence. Tests cover all 24
+locales, Maltese and Finnish risk markers, phase separation, profile drift,
+mutation before provider access, cache invalidation and release tampering.
+
+## End-to-end processing health (12 September 2026)
+
+Assume every intake worker appeared healthy while the source processing queues
+were blocked or damaged.
+
+- A healthy website outbox and sidecar could hide exhausted source retries,
+  corrupt queue counters, or incomplete terminal processing.
+- One aggregate health flag could erase which operated boundary is degraded or
+  blocked.
+- Continuing to the source layer after an earlier intake failure could create
+  misleading secondary network errors.
+- A structurally valid health response from another capability generation could
+  be accepted after configuration drift.
+
+The sidecar exposes a distinct authenticated, body-free source-health operation
+and validates the complete source response against its pinned contract. The
+website runtime first validates website and sidecar intake health, stops before
+the source call when intake is blocked, preserves both projections and their
+error details separately, binds both capability hashes, and fails closed on
+every transport, schema, status, or contract inconsistency.
+
+## End-to-end processing readiness (12 September 2026)
+
+Assume a website accepted localization work while the source service could not
+actually process it.
+
+- A healthy website worker and sidecar could hide a stopped or blocked source
+  worker.
+- Combining all readiness data into one object could erase which operated
+  boundary is unavailable.
+- A local failure could still trigger an unnecessary downstream request and
+  create misleading network noise.
+- A valid source readiness response from another capability generation could
+  be accepted after configuration drift.
+
+The sidecar exposes a distinct authenticated, body-free source-readiness
+operation and validates the complete source response against its pinned
+contract. The website runtime first verifies local and sidecar intake; it
+contacts the source layer only when both are ready, preserves both readiness
+objects separately, binds both capability hashes, and fails closed on every
+transport, schema, status, or contract inconsistency.
+
+## End-to-end localization lifecycle status (12 September 2026)
+
+Assume a website followed a durably accepted submission into localization but
+read the wrong tenant, an event that had not reached the source service, or an
+obsolete status contract.
+
+- A source-status request before sidecar acceptance could probe or invent
+  downstream state for work still owned by an upstream outbox.
+- A valid response for another site, event, payload, or capability generation
+  could be attached to the local submission.
+- Collapsing source acceptance and the localization lifecycle into one success
+  could make processing, review, or publication appear complete too early.
+- Reformatting the rich source status at each hop could silently omit a failed
+  locale, retry counter, terminal notification, or receiver state.
+
+The sidecar exposes a distinct authenticated source-status operation only for
+an exact locally succeeded outbox row. Every hop binds the site, event, stored
+payload hash, sidecar capability hash, and source-service capability hash. The
+website runtime keeps acceptance and localization as separate nested status
+objects, validates the complete source payload without lossy normalization,
+and fails closed on missing, premature, malformed, or stale state.
+
+## End-to-end submission health (12 September 2026)
+
+Assume one durable submission outbox appeared healthy while the other was
+blocked, corrupt, or bound to a changed sidecar contract.
+
+- A website-only health check could stay green while sidecar delivery is
+  permanently failed or holding an expired lease.
+- A healthy sidecar could hide failed or stale work in the website outbox if a
+  deployment reduced both states to one averaged signal.
+- Malformed counters or a substituted capability hash could be normalized into
+  a plausible healthy response.
+- Probing the sidecar before validating local storage could send an
+  authenticated request from a runtime whose own state cannot be trusted.
+
+The combined projection validates the local health snapshot before network
+access, then uses the owned authenticated client and requires the exact
+sidecar schema and capability binding. It preserves both complete content-free
+snapshots and reports `ok` only when both independently report `ok`.
+
+## End-to-end submission readiness (12 September 2026)
+
+Assume the website worker appeared healthy while the authenticated sidecar
+worker was stopped, blocked, or reporting an incompatible state.
+
+- A local-only readiness check could allow an operator to declare the complete
+  submission path available while accepted work cannot advance downstream.
+- Querying the sidecar when the website worker is already unavailable could
+  waste credentials and present an irrelevant remote success as overall health.
+- Averaging two states could let one healthy outbox conceal the other boundary's
+  blocking error.
+- A malformed readiness response or changed capability contract could be
+  normalized into a positive result.
+
+The combined projection validates local readiness first and remains offline
+unless that boundary is ready. It then uses the owned authenticated client,
+requires the exact response schema and capability binding, preserves both
+worker and outbox states independently, and reports ready only when both
+durable intake workers are running with healthy outboxes.
+
+## Bound submission progress (12 September 2026)
+
+Assume an operator polled a successfully queued website event and mistook one
+durable boundary for completion at the next boundary.
+
+- Reading the sidecar before local acceptance could disclose or manufacture a
+  remote state for work that the website still owns.
+- A status response for another event, tenant, payload, or contract generation
+  could be attached to the local row.
+- Collapsing the three retry ceilings could hide which queue exhausted its
+  attempts and make an unsafe retry appear available.
+- Sidecar-to-source acceptance could be reported as finished localization or
+  publication even though those later stages have not run.
+
+The combined status projection stays local until website acceptance, then uses
+the owned authenticated client and revalidates all immutable identities,
+payload and capability hashes, and both downstream retry ceilings. It exposes
+three explicit acceptance stages, carries only content-free error codes, and
+defines final `accepted` as durable source-service acceptance rather than
+localization completion.
+
+## Owned authenticated submission runtime (12 September 2026)
+
+Assume a website operator assembled the valid HMAC client, sidecar adapter,
+SQLite outbox, and worker separately but still lost a source event or confused
+durable acceptance with downstream completion.
+
+- The rotating client could omit the public immutable contract needed by the
+  outbox adapter and fail only when production wiring starts.
+- A credential replacement could update a signer other than the one used by
+  the durable worker.
+- Invalid worker or middle-retry configuration could create persistent state
+  before failing, or trigger an early network request.
+- A local succeeded row could be presented as completed source processing even
+  though the sidecar still reports pending or failed work.
+
+The owned submission runtime constructs one rotating signer, pinned client,
+adapter, guarded outbox, and optional worker from one configuration. It exposes
+the client's immutable contract to the adapter, validates hosted delays before
+opening SQLite, routes rotation through the owned client, and gives local
+acceptance and authenticated sidecar lifecycle reads separate method names.
+Process and close guards run before either storage or transport access.
+
+## Durable authenticated sidecar submission (12 September 2026)
+
+Assume a website persisted an event but mixed the retry policy for reaching the
+sidecar with the sidecar's delivery policy or the source service's processing
+policy.
+
+- A transient sidecar outage could exhaust the downstream source retry budget.
+- A changed sidecar pin or inner retry ceiling could alter an already queued
+  event after restart.
+- Treating sidecar acceptance as a direct source-service response could let a
+  malformed acknowledgement satisfy the existing outbox validator.
+- Translating a client exception could accidentally turn an unknown failure
+  into a retryable one.
+
+The sidecar outbox adapter gives each boundary its own explicit retry ceiling
+and hashes both capability pins plus the inner delivery policy into the
+outbox's immutable contract binding. It accepts only the exact validated
+sidecar envelope before producing a private completion projection, preserves
+declared retryability, and makes every unknown or malformed failure permanent
+and content-free.
+
+## Source-bound commercial review evidence (12 September 2026)
+
+Assume a structurally valid, content-free commercial review summary was copied
+to a different source, target, or policy generation.
+
+- A digest covering only the evidence object could remain unchanged when the
+  reviewed source or candidate changed outside an evidence span.
+- Updating the digest recipe without the commercial profile could leave old
+  plan, cache, and approval identities apparently current.
+- A worker and authenticated capability registry could enforce different hash
+  recipes while sharing the same summary schema.
+- Mutation tests could cover changed reviewer evidence but miss exact Unicode
+  text or profile changes.
+
+Commercial profile v3 and summary-contract v2 now hash a versioned binding of
+the exact UTF-8 source hash, exact UTF-8 target hash, profile, and complete
+canonical evidence. The profile bump invalidates earlier derived identities;
+the capability registry validates and publishes the same recipe. Independent
+tests mutate source, target, profile, and evidence and require distinct digest
+changes for every input.
+
+## Single-source authenticated client composition (12 September 2026)
+
+Assume a website backend wired a valid rotating signer to a valid HTTPS client,
+but duplicated their security configuration incorrectly.
+
+- The signer and client could receive different origins or capability pins and
+  fail only after the service entered production.
+- An adapter could rotate one signer while a different signer still protected
+  outgoing operations.
+- A convenience wrapper could omit status, health, readiness, or removal and
+  encourage an unprotected alternate path.
+- A forked worker could reach the network through an inherited client before
+  the signer rejected its first proof.
+
+The composed client now accepts origin and both capability pins exactly once,
+constructs its private rotating signer and HTTP client together, and exposes
+all six contract operations through one process-bound surface. Configuration
+failure performs no network call. Credential replacement reaches the exact
+signer used by every operation and retains its previous credential on failure.
+
+## Uninterrupted source-delivery client rotation (12 September 2026)
+
+Assume the server accepted an overlap generation, but a long-lived source
+worker could not move its HMAC signer safely without a restart.
+
+- Concurrent requests could observe a partially replaced credential or change
+  generation halfway through proof creation.
+- Invalid secret-manager output could destroy the last working client signer.
+- A forked process could inherit signer state and silently reuse parent-owned
+  secret material and synchronization.
+- Retiring the old server generation immediately after one client swap could
+  reject proofs already emitted or leave other client instances behind.
+
+The client now owns one process-bound rotating signer. It validates a complete
+replacement under the same lock used for proof creation and swaps only after
+success, preserving the previous signer on failure. Rotation never changes the
+fixed origin or capability pins. Deployments overlap generations server-side,
+rotate every client instance, drain already emitted requests and the proof
+validity window, and only then retire the old generation.
+
+## Uninterrupted source-delivery credential rotation (12 September 2026)
+
+Assume a running source-delivery sidecar rotated credentials but briefly
+accepted an incomplete set, lost its last working verifier, or weakened replay
+protection.
+
+- An in-flight request could race the replacement and observe a partially
+  updated credential map.
+- Invalid secret-manager output could remove every valid generation before the
+  configuration error became visible.
+- Removing and later re-adding a generation could make an already consumed
+  proof usable again if rotation also reset replay state.
+- A failed update could bypass storage, process, or lifecycle guards, while its
+  private exception or secret value escaped through a stable error.
+
+The runtime now materializes and validates one complete replacement verifier,
+then swaps it atomically under the same lock used by authentication. The prior
+verifier remains active until the replacement and replay-path guard both pass.
+All generations share the unchanged durable nonce ledger, so retirement and
+re-enrollment do not restore consumed proofs. Closed, inherited, replaced, or
+permission-weakened runtimes reject the update; failures are reduced to stable
+content-free codes.
+
 ## Durable terminal-processing reconciliation (11 September 2026)
 
 Assume the source CMS received a valid intake acknowledgement but later lost
@@ -274,6 +1137,7 @@ Assume the Version 6 response-and-translation gateway and automatic updater ship
 
 | Failure | Early warning | Mitigation | Proof required |
 | --- | --- | --- | --- |
+| A commercial acknowledgement is validated at ingress but discarded before retry or restart | A queued pricing change survives while its accepted profile and 24-locale registry generation cannot be proven from durable status | Persist the exact content-free binding beside the immutable payload hash, revalidate it before claims and reads, migrate only exact empty legacy stores, and leave populated legacy stores untouched and blocked | Queue, claim, retry, restart, HTTP, OpenAPI, and reference-client tests prove the same binding; tampering blocks; exact empty v1 upgrades; populated v1 remains unchanged and fail-closed |
 | Signed commercial benchmark evidence preserves only totals, so an operator cannot see which offer dimension failed | The final report blocks, but amount, tax, renewal, cancellation, and conditions remain indistinguishable without reopening private reviewer output | Unblind only the four content-free dimension statuses into each signed case, bind them to the exact source-fidelity response hash, aggregate every dimension separately, and block a dimension on any candidate major/blocking status | Case and report tests prove exact A/B-to-origin rebinding, ten ordered dimension summaries, per-status counts, no reviewer prose, a visible candidate-defect block, and rejection of a re-signed response-hash mismatch |
 | A commercial benchmark reviewer receives all ten dimensions but returns only a generic preference | The request looks complete while tax, renewal, cancellation, or target-only inventions were never explicitly decided; uncertainty is averaged into a win | Require an ordered per-dimension acknowledgement for both anonymous variants, link major/blocking decisions to exact defect entries, reject uncertainty, and enforce the same conditional contract in the runner, HTTPS adapter, and durable store | Positive end-to-end and HTTPS/store tests cover ten decisions per variant; missing, additional, reordered, uncertain, unbound, and preferred-defect responses fail closed without becoming benchmark evidence |
 | Commercial benchmark tags drift from the public offer profile or leak semantic source scope into the source-blind pass | A pricing case omits tax or cancellation review, accepts an invented target-only claim, or native review receives source-aware dimensions | Bind all ten ordered dimensions from the shared commercial registry to every commercial suite case, include the scope in the suite digest, validate it before any reviewer call, and expose it only during source-fidelity review | Manifest tests cover eight cases by all ten dimensions; missing, additional, and reordered scope block with zero reviewer calls; request tests prove native scope isolation and fidelity exposure |
@@ -485,5 +1349,42 @@ Assume the Version 6 response-and-translation gateway and automatic updater ship
 | Website backends must hand-build requests for the source-CMS ingress | A stale route accepts a different schema, a deployment swaps after discovery, an idempotency identity is reused with altered content, a response belongs to another site, or client retries multiply a write | Provide one provider-neutral, contract-pinned HTTPS client; validate immutable payloads before discovery, derive each operation from the freshly verified contract, bind every operational response to its capability digest and request identity, and leave bounded retries to the host | End-to-end WSGI tests cover all write and read operations, exact auth and body hashes, idempotent replay, pre-write contract drift, payload and tenant tampering, redirects, stable retryability, and content-free status data |
 | A website process calls the one-attempt source client without a durable handoff | A crash before the request loses a source change; a crash after remote acceptance causes uncertainty; an old lease overwrites a newer result; or nested retry policies multiply writes and hide exhausted work | Persist one immutable change, cancellation, or tombstone before network access; bind its capability digest and two separate retry ceilings; claim one token-bound attempt; replay the same idempotency identity after lease expiry; prioritize removals; and block health on tampering, drift, expiry, or terminal failure | Tests prove persist-before-call, exact replay, removal priority, durable backoff, bounded permanent failure, crash recovery after remote acceptance, stale-lease rejection, capability drift, short-lease rejection, and no client call after database tampering |
 | The website-source outbox is durable but deployment glue owns its connection and worker lifetime | Invalid configuration creates a database before failing; concurrent threads overlap transactions; a prefork child inherits a locked connection; linked or replaced storage receives trusted work; a dead worker still accepts events; or shutdown closes SQLite beneath a slow provider call | Add one preflighted composition root with an owner-only identity-guarded file, process binding before every lock, serialized connection access, a supervised non-daemon worker, managed-intake gating, content-free readiness, and signal-before-join shutdown that preserves the open database on timeout | Tests cover no-file invalid preflight, mode `0600`, restart recovery, automatic delivery, stopped-worker intake rejection, permission drift, links, inode replacement, process drift, 24 concurrent enqueues, redacted worker failure, bounded blocked-provider shutdown, and shared durable claims |
+| Non-Python website backends cannot use the protected source-delivery runtime without custom deployment glue | A local endpoint parses hostile content before authentication, accepts another site's event, leaks source text through status, queues work behind a dead worker, rehashes a weakened contract, or serializes a forged runtime result | Add one authenticated HTTPS/WSGI sidecar with route-specific scopes, exact body and payload hashes, tenant-bound writes and reads, managed-worker readiness, independently validated content-free responses, and a canonical contract digest | End-to-end tests cover change, cancellation and tombstone intake through remote delivery, exact authentication and idempotency bindings, cross-site indistinguishability, stopped workers, damaged storage, malformed framing, contract drift, response substitution, private failures, and concurrent replay |
+| Website and CMS backends must hand-build requests for the source-delivery sidecar | A stale route is used after discovery, credential code overwrites binding headers, sidecar and downstream contracts are confused, a response substitutes another tenant or payload, or hidden redirects and retries duplicate work | Provide one provider-neutral HTTPS reference client with fresh exact capability validation, separate sidecar and downstream pins, reserved headers, complete known status bindings, one transport attempt, and stable retryability | End-to-end WSGI tests cover all six routes, changes, cancellations, tombstones, exact inner-payload hashes, stale and downstream contract pins, response tampering, cross-site status, reserved-header injection, redirects, timeouts, malformed input, and parallel idempotent replay |
+| Every source-delivery deployment must invent authentication around the public callback contract | A signature authenticates only the body but not its route or tenant, a captured proof is replayed, an old credential survives rotation, another site's scope is accepted, altered replay state is trusted, or a failure leaks a key or customer content | Supply a provider-neutral HMAC signer and verifier that bind origin, route, scope, body, tenant, idempotency, payload, and both capability pins; atomically consume random nonces in a durable content-free SQLite ledger; allow only explicit credential generations and scopes | End-to-end tests cover all six routes, exact proof fields, replay, expiry and future skew, wrong keys and pins, retired generations, tenant and scope separation, altered bindings, replay-ledger tampering, clock failure, redaction, and concurrent idempotent writes |
+| The HMAC contract is correct but its caller-owned replay connection is deployed unsafely | The replay database is shared or replaced, permissions weaken, a forked worker inherits its connection, shutdown closes authentication beneath a live request, invalid configuration leaves operational state, or auth failure is invisible beside outbox health | Add one preflighted composition root with separate owner-only databases, safe-parent and inode guards, process binding before locks, serialized replay access, content-free auth health, and delivery-before-auth shutdown ordering | Tests cover no-file invalid preflight, mode `0600`, end-to-end hosted requests, durable replay after restart, permission drift, links, inode replacement, process drift, closed state, corrupt replay rows, parallel idempotent writes, redacted health, and blocked-worker shutdown |
+| CMS clients know that locale-specific commercial rendering exists but cannot retrieve the exact rules they must pin | A client guesses separators or currency placement, accepts a partial locale set, or silently follows tampered CLDR metadata while the server still advertises healthy capabilities | Publish one canonical content-free registry for all 24 locale rendering references, bind every entry to its commercial quality-profile version and digest, hash the complete registry, and validate exact canonical equality before returning signed capabilities | Capability tests require the exact 24-locale registry, CLDR 48 Maltese/Finnish/Austrian/Portuguese references, detached payloads, no project content, and fail-closed rejection of missing, reordered, or altered entries |
+| The server publishes a complete commercial rendering registry but the source-side reference client accepts a self-rehashed substitute or silently crosses a deployment upgrade | A proxy or incompatible service replaces the registry and recomputes its public hashes, or a legitimate profile change reaches production before the CMS host deliberately accepts new rules | Make the reference client validate the exact v5 capability shape and canonical 24-locale registry against its installed contract, then support immutable overall-capability and rendering-registry deployment pins with distinct non-retryable failures | End-to-end client tests accept exact current pins and reject malformed pins before transport, wrong deployment pins after one response, plus missing, reordered, altered, or obsolete registries even when every public hash is recomputed |
+| Deployment configures both commercial capability pins but the durable CMS source runtime never exercises them before accepting work | A host assumes constructor pins are active, opens persistent queues without a successful capability read, or the client binding changes after startup while queued website content continues toward the wrong contract | Add an explicit startup preflight that requires and verifies both immutable pins before creating any database, retains only their content-free hashes, and rechecks the client binding before every runtime transition | Runtime tests prove successful pinned startup, zero database creation for missing pins or remote mismatch, one bounded capability request, content-free status, and blocking before persistence or delivery when the client binding changes |
+| A pinned CMS runtime restarts over durable queues that were created for another commercial capability generation or database role | Pending work silently crosses a price/offer policy deployment, swapped change/removal files acquire new tables, an unbound legacy queue with work is adopted, or a partially written/tampered binding is trusted after a crash | Persist the exact two-pin binding and database role independently in all three SQLite files, precheck existing metadata before service schema writes, adopt only provably empty unbound stores, and revalidate canonical rows on every operation | Restart tests preserve same-binding work, reject a coherent different binding and swapped roles before schema mutation, reject non-empty unbound stores, safely adopt empty legacy stores, recover same-binding partial writes, and block altered rows before queue access |
+| The outer website outbox remains unbound while the sidecar and source queues pin a commercial generation | Website retries can resume under a different runtime or price-format policy, a stale sidecar can be trusted, or the website database is created before any authenticated proof of the downstream generation | Require both host-owned generation pins together, verify them through authenticated sidecar source readiness before opening SQLite, include them in the adapter contract, and persist the exact role-specific binding in the outer outbox | Tests prove exact signed preflight and persisted hashes, reject mismatch or outage before database creation, bind adapter-digest changes, preserve direct unpinned compatibility, and keep local status reads offline |
+| A website runtime contacts the sidecar before discovering that its existing outer outbox is locally unsafe or belongs to another generation | A restart leaks operational traffic, consumes authentication nonces, or depends on an unavailable network even though a changed pin, tampered schema, unsafe file, or non-empty unbound queue already makes safe recovery impossible | Validate the existing file identity, base schema, canonical generation row, and derived digest through a read-only local preflight before the authenticated sidecar request; preserve remote-first creation and migration for missing or provably empty stores | Restart tests require zero transport calls for generation mismatch, schema tampering, unsafe permissions, and non-empty unbound work; same-generation state resumes, and an empty legacy store binds only after the unchanged authenticated preflight |
+| The outer website generation is durable but invisible in composed operational projections | Operators see healthy website, sidecar, and source states without proof that the website outbox is still bound to the generation that accepted its work; a cached or reconstructed hash can hide database tampering | Project one canonical, content-free website capability binding directly from the guarded SQLite row and carry it independently through status, lifecycle, health, and readiness contracts before any downstream read | Exact binding and defensive-copy tests cover every projection; altered generation metadata blocks health and readiness locally with zero additional transport calls; payloads contain no endpoint, credential, tenant, source, or target text |
+| The owned website runtime has many safe methods but no single discoverable end-to-end contract | An integrator pins only the sidecar, assumes stale projection schemas, collapses the three retry budgets, or treats durable source acceptance as publication; local generation drift is found only after an operational call | Publish one canonical content-free capability snapshot that binds every outer operation and projection schema, retry ownership and publication semantics to the guarded website generation plus freshly verified sidecar and source pins | Exact snapshot and defensive-copy tests prove deterministic hashing; local generation tampering blocks before network, and remote contract substitution blocks without returning partial capabilities or private data |
+| A public website write endpoint authenticates the transport but not the durable request identity | Another site's payload reaches readiness or storage, a replay changes content or retry policy under one ID, a dead worker acknowledges stranded work, or HTTP 202 is mistaken for source acceptance or publication | Bind the authenticated principal to the exact site, body hash, canonical payload hash, route-specific scope and idempotency key before runtime access; require the hosted worker and pinned generation; return only after the outer SQLite commit with explicit non-publication semantics | Change, cancellation and tombstone tests cover exact auth/body/header bindings, cross-site and wrong-scope rejection with zero runtime calls, worker failure, one-row replay, collision conflict, malformed transport, tampered runtime status, and a real hosted-runtime durable write |
+| A public progress endpoint leaks another tenant or collapses durable acceptance into publication | A guessed request ID returns another site's status, a substituted payload hash or nested source projection is serialized, or `accepted` is presented as linguistically approved and publishable | Require distinct site-bound read scopes; bind operation, request, event, site and source-payload hash before lookup; independently validate status and lifecycle envelopes with separate capability generations; preserve every stage and explicit non-publication semantics | Tests prove wrong-scope and foreign-site rejection before runtime access, not-found equivalence, status/lifecycle separation, valid source-state projection, and fail-closed rejection of changed payload hashes and cross-site nested source state |
+| Website backends hand-build calls to the complete public submission edge | A stale path or scope survives deployment, credential code overwrites an idempotency binding, a response is rebound to another tenant or generation, or an implicit redirect/retry duplicates a durable write | Provide one provider-neutral reference client that validates the complete pinned v5 capability before every operation, owns reserved headers, binds full known identities, independently validates nested responses, and leaves retry scheduling outside the transport | End-to-end WSGI tests cross capability discovery, all writes and tenant reads, separate operator health/readiness, exact body and payload hashes, replay, stale or rehashed capabilities, tenant/private-field substitution, invalid input, reserved-header injection, redirects, and single-attempt retry metadata |
+| A CMS backend uses the safe one-attempt public client without a durable local handoff | A crash loses an unsent edit, remote HTTP 202 is lost before local commit, nested retry ceilings are collapsed, a new deployment resumes old-generation work, or altered SQLite state reaches the network | Persist each immutable change, cancellation, or tombstone with its complete identity, capability pin, and three separate retry ceilings before transport; lease one attempt, back off only explicit retryable failures, replay identically after expiry, and revalidate every stored row | Real hosted-runtime tests cover all operations, persist-before-send, lost-response replay, bounded transient and permanent failures, full idempotency binding, capability drift before claim, payload and response tampering, stale claims, restart generation binding, and competing workers |
+| The CMS-side public submission outbox is durable but deployment glue owns its file, connection, and worker lifetime | Invalid policy creates or mutates storage before failure, a prefork child inherits a locked connection, linked or replaced state reaches the network, a dead worker accepts stranded edits, or shutdown closes SQLite under a slow transport call | Add one preflighted process-owned runtime with an owner-only identity-bound file, read-only restart validation, serialized connection access, exact client-pin checks, a supervised non-daemon worker, managed-intake gating, content-free readiness, and signal-before-join shutdown | Tests prove zero-file invalid preflight, mode `0600`, restart delivery, live-worker gating, permission, symlink, inode, schema, capability and process drift blocking before transport, concurrent idempotent intake, and database preservation after a bounded shutdown timeout |
+| Non-Python CMS backends cannot reach the protected caller-side submission runtime safely | A local endpoint parses hostile JSON before authentication, accepts another site's event, exposes stored source text through status, acknowledges work behind a dead worker, collapses three retry budgets, or serializes a forged runtime result | Add one authenticated HTTPS/WSGI sidecar with route-specific tenant and operator scopes, exact body and source-payload hashes, full-identity status, supervised-worker write gating, independently validated content-free responses, and a canonical capability digest | Tests prove authentication-before-parse, commit-before-202, full retry preservation, replay and collision behavior, foreign-site not-found equivalence, stopped-worker rejection, separate health and readiness, unsafe-storage blocking before downstream transport, malformed framing rejection, exact capabilities, and zero-file invalid configuration |
+
+| A commercial CMS acknowledgement and a website acceptance each verify but refer to different rendering registries | A self-consistent downstream capability binding is accepted because only its delivery generation and internal hash are checked, allowing an offer localized under unacknowledged price, tax, or term rules to appear durably accepted | Require the accepted website binding's commercial-registry hash to equal the durable enqueue contract; recheck the equality before commit, after restart, at health, at HTTP serialization, and in the reference client | A self-rehashed foreign registry fails before acceptance; a coherently altered accepted row fails health; HTTP and client reject the same cross-registry substitution while the exact live generation succeeds |
+| Commercial fidelity evidence is replayed across locales or locale-quality generations | The source, target and generic commercial profile are unchanged, so an opaque evidence digest from another locale or an older rendering, morphology or evaluation profile appears reusable | Include the exact target locale plus commercial locale-quality profile version and SHA-256 in the versioned evidence-hash binding; derive them from the validated job and require them explicitly in the portable checker | Changing only locale, quality-profile version or quality-profile digest changes the evidence hash; missing, noncanonical or malformed bindings block before a result, approval or publication |
+| A CMS or review adapter guesses how unresolved commercial checks were cleared | Prose documentation and the runtime disagree about dimension ordering, qualified-human provider privacy, model independence, or receipt handling; a self-rehashed partial contract looks valid | Publish one separately hashed resolution contract inside the commercial capability profile and use the same provider-neutral result schema in release evidence | Exact-contract tests cover both methods and excluded content; reordered dimensions, a human provider, a non-independent model, raw-receipt exposure, or rehashed drift makes the complete capability response unavailable |
+| A signed commercial resolution cannot prove which contract and primary model it resolved | The CMS sees the second model but not the primary provider or resolution-contract digest, so it cannot detect the same provider on both sides or a result created under an older self-consistent contract | Bind the exact commercial profile, resolution-contract SHA-256 and primary provider identity into the closed resolution result; require an independent provider ID to differ before release, CMS validation and durable commit | Tests accept both valid resolution methods and reject profile drift, contract drift, missing or altered primary-provider fields, and equal primary/secondary providers before CMS persistence |
+| Commercial review evidence is verified without the exact resolution-contract generation | The evidence provider and receipt verifier see unresolved dimensions but not the contract digest they must satisfy, so an old receipt can be interpreted as approval under a changed escalation contract | Bind the canonical resolution-contract SHA-256 into the commercial evidence request, deterministic request ID and every receipt-verification context; require null outside unresolved commercial review and recompute the installed contract before transport | Contract drift changes the request ID and receipt binding; missing, stale, cross-scope or self-selected digests fail before authentication, provider transport, approval or publication |
+| A quality-evidence request supplies a well-formed but self-selected request ID | Changed locale, profile, provider, confidence or commercial-contract bindings can enter an existing lease and idempotency namespace because the durable store and HTTPS adapter trust the ID instead of deriving it | Define one exact versioned identity field set, recompute the request ID from its canonical JSON after validating the source and target hashes, and enforce the same derivation before persistence and before authentication or transport | A stale, random or recomputed-under-the-wrong-field-set ID fails without a database row, credential callback or network call; coordinator and HTTPS identity-field registries must remain exactly equal |
+| A quality service relabels an old receipt with a current evidence request ID | The response envelope matches the current request, but the opaque quality, human or independent-model receipt was issued for another evidence revision or request and still verifies against the older release-only binding | Carry the canonical evidence request ID and revision into every purpose-specific receipt-verification binding and the signed approval; reject missing, malformed or substituted context before verifier or signer access | Replaying one otherwise valid receipt under a changed evidence request or revision fails at verification; HTTP verifier requests expose the exact context, signed approval lookup detects tampering, and no raw receipt enters durable state |
+| A downstream CMS receives a signed approval hash without the evidence generation it represents | The localization service can detect a stale evidence request internally, but the public release proof omits its request ID and revision, so a CMS cannot audit or policy-gate that exact generation without private state | Advance the closed release-evidence schema and carry the canonical content-free evidence request ID and revision from the verified signed approval through publication, receiver validation and durable CMS storage | End-to-end tests expose and persist the exact lineage at the host commit; missing or malformed lineage fails closed, signed-byte substitution fails authentication, and raw receipts and reviewer prose remain absent |
+| CMS integrators know the release-evidence schema name but must reconstruct its semantics from prose | A client omits the evidence generation, accepts an obsolete field set, publishes private review material, or treats a self-rehashed partial contract as current because no machine-readable contract enumerates lineage, hashes, commercial scope and excluded content | Publish one exact, separately hashed release-evidence capability contract inside the signed publication-HTTP capabilities; reconstruct and validate it from runtime constants before returning any capability response | Contract tests cover the closed ordered field set, hash and lineage bindings, commercial nullability, content exclusions and digest; missing, altered, reordered or self-rehashed contracts make the complete capability response and reference-client result fail closed |
+| A signed release proof names its evidence schema but not the exact machine-readable contract generation | Archived or delayed evidence can be interpreted under a newer field, scope or privacy contract even though its signature and schema name remain valid | Bind the canonical release-evidence-contract SHA-256 into every signed approval and release proof, validate it before publication and CMS commit, and persist the exact bound proof unchanged | Missing, malformed, stale or substituted contract digests fail before signing, publication or host commit; non-commercial and commercial paths carry the same canonical digest through restart and durable CMS retrieval |
+| A durable CMS bundle outlives its approval or the release-evidence contract that authorized it | The receiver validates on initial delivery but keeps serving and reporting an active localization after approval expiry or a runtime contract upgrade; blindly applying the same rule to deletion could then trap the stale content | Inject the canonical release-evidence validator into the durable store and re-run it with expiry checks on active reads, health and idempotent publication replay, while structural-only tombstone paths remain able to remove stale content | Restart and time-advance tests make stale active reads, health and replay fail closed; the same expired and contract-stale bundle can still be tombstoned atomically without exposing target text in errors |
+| A database rewrite replaces an accepted CMS bundle and recomputes its unkeyed hashes after the receiver process restarts | The durable store retains payload and release-evidence fields but not the verified outer publication signature, so internally consistent replacement bytes could appear authorized without proving their publisher | Persist the exact canonical publication signature beside every active bundle, inject the configured publisher authority into the store through a closed validator, and reverify the signed canonical payload on commit, active reads, health and replay; migrate legacy rows without inventing missing signatures | Rehashed payload-and-evidence tampering fails only at signature verification, signed file-backed bundles survive restart, and migrated signatureless active rows remain unrenderable and unhealthy while structural tombstones can still remove them |
+| A commercial reviewer labels several offers with one arbitrary identifier | Every price and condition has a formally valid span, but the free label does not prove which source and target offer own it, so swapped prices or conditions could hide inside an apparently complete report | Add a versioned offer registry with unique identifiers and ordered, non-overlapping source and target regions; require every proposition span and every offer-assignment item to resolve inside its declared offer regions | Cross-offer spans, overlapping ownership, missing offer assignments, unknown labels and relabelled propositions fail deterministically; multiple discontiguous regions remain possible for linked footnotes, while unresolved semantic boundaries still route to independent review |
+| CMS and provider adapters infer the commercial evidence shape from a prompt example or prose | An integration can silently omit the offer registry, accept overlapping regions, or reinterpret one-sided evidence while still pinning the summary contract and commercial profile digest | Publish a separately versioned and hashed evidence contract with the exact closed fields, limits, span semantics, verdict invariants, offer-assignment coverage and structural-only trust boundary; bind it into the public commercial profile | Capability, OpenAPI, discovery-client and portable-checker tests consume the same canonical contract; missing, altered or self-rehashed evidence contracts block the complete capability response before content or provider access |
+| A commercial review summary outlives the evidence contract under which its private report was accepted | The summary retains the evidence hash but not the exact evidence-contract digest, so a cached result, evidence request, receipt or approval could be replayed after structural rules change while the commercial profile identifier stays constant | Bind the canonical review-evidence-contract SHA-256 into the private evidence hash and content-free summary, then carry that closed summary through worker result, evidence request, receipt verification, signed approval and CMS release evidence | Stale or self-selected contract digests fail at summary validation and every outer boundary; contract changes derive new evidence, request, receipt, approval and release hashes without exposing private report content |
+| A commercial source-fidelity provider receives only an illustrative evidence example | The provider guesses offer limits, Unicode span semantics, verdict invariants or trust boundaries differently from the validator, so a formally plausible report fails late or silently omits required reasoning | Resolve and verify the complete separately hashed public evidence contract before provider access, then bind it only into the source-aware fidelity request and its deterministic request hash | Exact-contract tests prove the fidelity provider sees the current canonical contract and resulting summary digest; a self-rehashed substitute blocks before any provider call, while transcreation and source-blind native review remain contract-free |
+| A global commercial dimension verdict covers only one of several registered offers | A reviewer supplies correct evidence for one tier while silently omitting another tier's price or condition; a global equivalent result still appears complete | Require exactly one ordered per-offer verdict for every dimension, derive the aggregate status by fixed severity, and require evidence within each non-absent offer region | Missing, duplicate, reordered, cross-offer, or aggregate-inconsistent matrices fail deterministically; uncertain semantics still route to independent review without numeric regex proof |
+| A CMS cannot prove the escalation policy behind an already verified commercial approval | The resolution-contract digest is hidden inside opaque internal identities and only an unresolved result exposes it, so downstream policy checks cannot distinguish approval generations | Carry the exact current content-free resolution-contract SHA-256 in every commercial release proof; require `null` outside commercial content and retain the detailed resolution object only for unresolved offers | Release, CMS, receiver and capability tests accept the current digest for verified and escalated paths, reject stale or substituted values before host commit, and expose no private route, receipt, reviewer prose, price or brand |
 
 No heuristic is allowed to claim that it proves native fluency. Cryptographic proof covers process integrity, not linguistic truth.