blun-king-cli 9.1.587 → 9.1.588

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

@@ -0,0 +1,136 @@
+# Website localization quality-evidence HTTP contract
+
+`integrations/website_localization_evidence_http.py` connects the production
+release coordinator to a host-owned quality service without choosing a model,
+review vendor, or credential format. It performs exactly one HTTP attempt for
+one already leased locale-evidence job. The durable
+`QualityEvidenceStateStore` remains the only retry and crash-recovery owner.
+
+Transport conformance proves request integrity and fail-closed behavior. It
+does not prove that a translation is native, publishable, or better than an
+external baseline.
+
+## Host configuration
+
+Construct `HTTPEvidenceProviderAdapter` with:
+
+- one fixed HTTPS endpoint;
+- a callback returning authentication headers at call time;
+- an optional host transport and timeout;
+- `allow_loopback_http=True` only for an explicit `localhost`, `127.0.0.1`, or
+  `::1` development endpoint.
+
+The endpoint cannot contain user information, a query, or a fragment.
+Redirects are never followed, so credentials cannot be forwarded to another
+origin. Authentication values must be ASCII control-free strings. The host
+cannot override `Host`, framing, content, idempotency, or binding headers.
+Neither credentials nor remote response prose appears in adapter errors.
+
+## Request
+
+The adapter accepts only the coordinator's exact immutable
+`blun.localization-quality-evidence-request.v5` object. It validates the
+complete field set, request ID, SHA-256 values, locale profile, model identity,
+confidence decisions, optional commercial profile and its exact content-free
+targeted-review summary, UTF-8 size, Unicode NFC, and the source and target text
+hashes before authentication or transport.
+
+It sends one canonical UTF-8 JSON document:
+
+```json
+{
+  "schema": "blun.localization-quality-evidence-http-request.v1",
+  "request_id": "blun-l10n-evidence-<64 lowercase hexadecimal characters>",
+  "request_sha256": "<SHA-256 of the canonical inner request>",
+  "request": {
+    "schema": "blun.localization-quality-evidence-request.v5",
+    "request_id": "<same request ID>",
+    "source_locale": "en-IE",
+    "target_locale": "fi-FI",
+    "source_text": "<complete source>",
+    "target_text": "<complete candidate>",
+    "result_sha256": "<validated durable worker-result hash>",
+    "source_sha256": "<source-text hash>",
+    "target_sha256": "<target-text hash>",
+    "content_type": "headline",
+    "quality_profile": {
+      "locale": "fi-FI",
+      "version": "<locale profile version>",
+      "sha256": "<locale profile hash>"
+    }
+  }
+}
+```
+
+The abbreviated example omits other required inner fields for readability.
+Production requests always contain exactly the full v5 field set. Commercial
+requests include `commercial_profile` and the matching `commercial_review`
+summary; non-commercial requests require both fields to be `null`. Source and
+target text are intentionally present because this external step verifies the
+existing source-blind native review and the separate source-aware fidelity
+review. The service must preserve their confidentiality.
+
+The adapter adds:
+
+```text
+Content-Type: application/json; charset=utf-8
+Accept: application/json
+Idempotency-Key: <request_id>
+X-Localization-Evidence-Request-Id: <request_id>
+X-Localization-Evidence-Request-Sha256: <request_sha256>
+```
+
+The receiver must treat the idempotency key and canonical request digest as one
+immutable operation. Reusing the ID for different bytes must fail closed.
+
+## Response
+
+A successful service returns HTTP 200, JSON content type, and exactly:
+
+```json
+{
+  "schema": "blun.localization-quality-evidence-http-response.v1",
+  "request_id": "<same request ID>",
+  "request_sha256": "<same canonical request hash>",
+  "result_sha256": "<same validated worker-result hash>",
+  "evidence": {
+    "schema": "blun.localization-quality-evidence-response.v2",
+    "request_id": "<same request ID>",
+    "result_sha256": "<same validated worker-result hash>",
+    "quality_receipt": "<host-verifiable purpose-bound receipt>",
+    "human_review_receipt": null,
+    "independent_model_review": null
+  }
+}
+```
+
+The adapter rejects extra or missing fields, duplicate JSON keys, non-finite
+numbers, a UTF-8 byte-order mark, wrong bindings, ambiguous content types,
+incorrect lengths, and oversized bodies. The release coordinator then applies
+its existing independent receipt checks. Each opaque receipt must verify
+against the complete canonical
+`blun.localization-quality-receipt-binding.v2` object supplied by the release
+coordinator, including the review purpose, job and result hashes, both texts
+and locales, content type, glossary and policy versions, provider/model and
+software identities, locale quality and commercial profiles, the exact
+commercial review scope, confidence, and escalation requirements. Reuse across
+a changed field or between quality,
+qualified-human, and independent-model review purposes must fail closed.
+Legal content still requires a
+separately verified qualified-human receipt. Low-confidence non-legal content
+still requires exactly one qualified-human receipt or a differently identified
+and independently verified second model review.
+
+## Failure and retry contract
+
+The adapter raises only stable, content-free `HTTPEvidenceProviderFailed`
+codes. Network errors, HTTP 408/425/429, HTTP 5xx, malformed transport data,
+and response parsing failures are retryable. Redirects, other HTTP statuses,
+unsafe requests, and binding mismatches are permanent. Every invocation makes
+at most one transport attempt.
+
+The coordinator records the stable code, releases or terminates the exact
+token-bound evidence lease, and applies its configured bounded exponential
+backoff. A retry uses the same deterministic request ID. A last known good
+translation is never replaced, and no publication is prepared until all
+policy-required locales hold valid signed approvals.

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

@@ -0,0 +1,130 @@
+# Authenticated localization health HTTP contract
+
+`WebsiteLocalizationHealthHTTPApplication` exposes the composed runtime's
+existing read-only health monitor to an explicitly authorized operator. It is
+provider-neutral and returns identifiers, lifecycle states, stable reasons,
+and counts only. It never repairs state, advances a lease, retries work, signs
+an approval, calls a model, publishes content, or returns source text, target
+text, reviewer prose, credentials, receipts, or transport exceptions.
+An explicitly configured publisher probe may make one content-free callback
+challenge as part of the read.
+
+This is an operator endpoint, not a tenant CMS status endpoint. Its response
+can contain site and website-version identifiers from the complete configured
+runtime. Do not grant a normal site credential access. Tenant-scoped progress
+continues to use the separately signed endpoint documented in
+[`WEBSITE_LOCALIZATION_API.md`](WEBSITE_LOCALIZATION_API.md).
+
+## Runtime configuration
+
+Pass a callable `health_http_authenticator` to
+`WebsiteLocalizationRuntime`. The runtime then exposes `runtime.health_http`.
+Without that explicit capability the attribute is `None` and no operator
+reader exists. Optional `health_provider_probe` and `health_publisher_probe`
+values must implement `check` and are accepted only together with the
+authenticator. Invalid or partial settings block before any SQLite schema is
+created or migrated. The publisher probe must be the exact same capability as
+the runtime's delivery publisher. The built-in HTTPS publisher implements it
+with a fresh probe ID and the exact advertised callback-contract digest; its signed
+response contains no website or locale data.
+
+Mount the WSGI callable behind a production server and trusted TLS terminator.
+The application requires `wsgi.url_scheme == "https"`; only the trusted server
+may derive that value. It accepts one empty, query-free request:
+
+```http
+GET /v2/localization/health HTTP/1.1
+Authorization: <operator-owned credential>
+Content-Length: 0
+```
+
+Bodies, transfer encoding, duplicate or malformed headers, plaintext
+transport, queries, other methods, and other paths are rejected before the
+authenticator or monitor runs. Request headers are bounded and passed only to
+the host authenticator in this canonical envelope:
+
+```json
+{
+  "schema": "blun.localization-health-http-auth-request.v1",
+  "method": "GET",
+  "path": "/v2/localization/health",
+  "headers": [["authorization", "<operator-owned credential>"]],
+  "body_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
+}
+```
+
+The host owns credential lookup, rotation, rate limiting, network policy, and
+audit redaction. On success it returns exactly:
+
+```json
+{
+  "schema": "blun.localization-health-reader-principal.v1",
+  "reader_id": "operations-1",
+  "credential_id": "health-reader-1",
+  "credential_version": "2026-09-09",
+  "scope": "service-health"
+}
+```
+
+The adapter validates every field and requires the exact `service-health`
+scope. It does not include principal or credential values in the response.
+Invalid principals return `401`; an authenticator outage returns a retryable
+`503`, with no exception text.
+
+## Response and status semantics
+
+A valid report is wrapped without changing the monitor's signed-state
+decisions:
+
+```json
+{
+  "schema": "blun.website-localization-health-http.v1",
+  "report": {
+    "schema": "blun.website-localization-health.v1",
+    "checked_at": 1788962400.0,
+    "status": "degraded",
+    "components": [{
+      "component": "supervisor",
+      "status": "degraded",
+      "reasons": ["supervisor.heartbeat_stale"],
+      "counts": {"consecutive_blocked": 0}
+    }],
+    "providers": [],
+    "website_versions": []
+  }
+}
+```
+
+The real monitor supplies non-empty component data. `healthy` and `degraded`
+reports return HTTP `200`; a structurally valid `blocked` report returns HTTP
+`503` while retaining the complete content-free report for diagnosis. Thus a
+load balancer cannot mistake known corruption for health, while an operator
+can distinguish a valid blocked assessment from an unavailable monitor.
+
+Before delivery, the HTTP boundary independently validates the exact report
+schema, finite check time, overall and component states, unique component and
+event identities, non-negative counts, provider bindings, website lifecycle
+states, locale failures, stable reason grammar, exact current check time, and a
+four-megabyte response ceiling. Extra fields, free-form
+reason prose, duplicate identities, impossible approval counts, invalid
+provider output, malformed reports, or serialization failures produce only:
+
+```json
+{
+  "schema": "blun.website-localization-health-http-error.v1",
+  "error_code": "health.http.response_invalid",
+  "retryable": true
+}
+```
+
+All responses use `Cache-Control: no-store`, `X-Content-Type-Options: nosniff`,
+and `Referrer-Policy: no-referrer`. The host must additionally prevent access
+logs from retaining operator credentials.
+
+Premortem: an unauthenticated probe could enumerate sites, a malformed monitor
+could leak customer prose, a blocked report could be returned as an ordinary
+healthy response, authentication failure could fall through to state access,
+or an external probe could be enabled without an operator boundary. Explicit
+service-wide scope, authentication-before-monitor ordering, strict output
+revalidation, HTTP `503` for blocked state, and pre-schema runtime validation
+keep those paths fail-closed.

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

@@ -0,0 +1,175 @@
+# HTTP localization-provider contract
+
+`integrations/website_localization_http_provider.py` connects the
+provider-neutral website worker to a host-owned model gateway. It does not
+assume a particular vendor, SDK, model, or authentication scheme. A deployment
+can place its own LLM, a commercial provider, or an internal routing service
+behind the same endpoint.
+
+This adapter is a transport boundary, not a quality certificate. Its tests
+prove request isolation, integrity binding, parsing, and failure behavior. They
+do not prove that any connected model writes native-quality translations.
+
+## Security and retry model
+
+- Use HTTPS. Plain HTTP is accepted only for an explicitly enabled loopback
+  endpoint such as `127.0.0.1`.
+- Supply authentication headers through a host callback. Do not put secrets in
+  the endpoint URL, source content, repository, job, or model response.
+- The adapter performs exactly one HTTP request for one worker phase. The
+  durable queue owns bounded retries and crash recovery, preventing hidden
+  retry multiplication and uncontrolled provider cost.
+- Redirects are never followed. A redirect is a non-retryable failure because
+  it could send customer content or credentials to an untrusted destination.
+- Response bodies are bounded, UTF-8 without a byte-order mark, strict JSON,
+  and free of duplicate keys or non-finite numbers.
+- Every response must echo the exact request ID and canonical request hash.
+  Network, status, parser, header, size, or binding failures return only stable
+  error codes; provider prose and credentials are not exposed.
+- Failure is closed per locale. No failed call produces a candidate, approval,
+  publication, or replacement for a last-known-good translation.
+
+## Host configuration
+
+The authentication callback is invoked immediately before each request, so a
+host can rotate short-lived credentials without rebuilding jobs:
+
+```python
+from integrations.website_localization_http_provider import HTTPProviderAdapter
+
+provider = HTTPProviderAdapter(
+    "https://model-gateway.example/v1/localize",
+    authentication_headers=lambda: {
+        "Authorization": load_short_lived_authorization_header()
+    },
+    timeout=60,
+)
+```
+
+The callback must return at least one header. It cannot replace transport or
+binding headers such as `Host`, `Content-Type`, `Content-Length`,
+`Idempotency-Key`, or `X-Localization-Request-Sha256`. Header names and values
+containing control characters are rejected before any network call.
+
+A deployment that uses mutual TLS can implement the small `HTTPTransport`
+protocol and inject a transport configured with its own trusted certificate
+context. Custom transports must still make one request and return `HTTPResult`;
+all response validation remains inside the adapter.
+
+## Request
+
+Each locale has its own queue job. Each of its three stages—`transcreation`,
+`target_native`, and `source_fidelity`—makes a separate request. No request asks
+for several target languages.
+
+The adapter sends canonical UTF-8 JSON with these headers:
+
+```text
+Accept: application/json
+Content-Type: application/json; charset=utf-8
+Idempotency-Key: <request_id>
+X-Localization-Request-Id: <request_id>
+X-Localization-Request-Sha256: <request_sha256>
+```
+
+The JSON envelope has exactly four fields:
+
+```json
+{
+  "schema": "blun.localization-provider-request.v1",
+  "request_id": "<deterministic phase request ID>",
+  "request_sha256": "<SHA-256 of canonical request JSON>",
+  "request": {
+    "schema": "blun.website-localization-worker.v4",
+    "request_id": "<same deterministic phase request ID>",
+    "phase": "transcreation",
+    "provider_id": "customer-llm",
+    "model_id": "configured-model",
+    "model_version": "configured-model-version",
+    "system_instruction": "<versioned phase instruction>",
+    "input": {}
+  }
+}
+```
+
+The gateway must treat `system_instruction` as the instruction and every value
+inside `input` as untrusted data. It must not combine phases. In particular,
+the `target_native` input intentionally excludes the source text and
+source-language glossary terms; reconstructing or fetching that source would
+invalidate the independent, source-blind review.
+
+`request_sha256` is the lowercase hexadecimal SHA-256 of `request` encoded as
+UTF-8 JSON with keys sorted, no insignificant whitespace, native Unicode
+characters unescaped, and non-finite numbers forbidden. The bundled adapter
+computes it. A gateway only needs to echo the received value after associating
+it with the processed request.
+
+For an exact replay, the gateway should return the already completed exact
+response or safely resume its own in-progress operation. If it has previously
+seen the same `request_id` with a different request hash, it must reject the
+call. It must never silently reuse output from another source, locale, phase,
+policy, glossary, provider, model, or software version.
+
+## Response
+
+A successful endpoint returns HTTP `200`, `Content-Type: application/json`
+(optionally with `charset=utf-8`), and this exact envelope:
+
+```json
+{
+  "schema": "blun.localization-provider-response.v1",
+  "request_id": "<exact request ID>",
+  "request_sha256": "<exact request hash>",
+  "response": {}
+}
+```
+
+The `response` value is passed to the existing worker validator. For
+`transcreation`, it must be exactly:
+
+```json
+{
+  "schema": "blun.website-localization-candidate.v1",
+  "phase": "transcreation",
+  "locale": "fi-FI",
+  "candidate": "<complete localized content>"
+}
+```
+
+For either review, it must be exactly:
+
+```json
+{
+  "schema": "blun.website-localization-review.v2",
+  "phase": "target_native",
+  "locale": "fi-FI",
+  "status": "PASS",
+  "confidence": "high",
+  "blocking_defects": [],
+  "major_defects": []
+}
+```
+
+Use `phase: source_fidelity` for the second review. A `PASS` requires both
+defect arrays to be empty. A failed review must report structured defects in
+the worker's existing schema; the pipeline hashes those findings instead of
+retaining reviewer prose in queue status. The worker independently validates
+the exact phase, locale, shape, Unicode NFC, protected syntax, completeness,
+and review ordering.
+
+## Status behavior
+
+HTTP `408`, `425`, `429`, and `5xx` responses are retryable by the queue.
+Other non-`200` statuses and redirects are non-retryable. Transport exceptions
+and malformed successful responses are retryable because a later bounded queue
+attempt may reach a healthy gateway; a request/response binding mismatch is
+non-retryable because repeating an untrusted or incorrectly implemented
+endpoint is unsafe.
+
+Premortem: assume a production gateway leaked an authorization token, followed
+a redirect, charged three times for one transient failure, or returned a good
+Finnish answer for the wrong request. Host-only headers, rejected redirects,
+one-attempt transport, queue-owned retries, deterministic idempotency, and the
+exact echoed request hash are the corresponding preventive controls. End-to-end
+deployment tests should additionally stop the gateway mid-stage, replay the
+same ID, rotate credentials, and return deliberately stale locale output.

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

@@ -0,0 +1,86 @@
+# Localization receipt-verifier HTTPS contract
+
+`integrations/website_localization_receipt_verifier_http.py` is a
+provider-neutral network implementation of the release store's receipt
+verifier boundary. It does not issue evidence, choose a model, hold a signing
+key, approve a locale, or publish content. It asks one host-configured service
+whether one opaque receipt authenticates one exact canonical release binding.
+
+## Host configuration
+
+Construct `HTTPReceiptVerifierAdapter` with:
+
+- one fixed absolute HTTPS endpoint;
+- a callback returning authentication headers at call time;
+- an optional transport implementation; and
+- a timeout from 0 to 300 seconds.
+
+Plain HTTP is rejected except for an explicitly enabled loopback endpoint used
+for local development. User information, fragments, queries, control
+characters, ambiguous paths, unsafe authentication headers, redirects, and
+authentication attempts to replace protocol headers are rejected. The adapter
+makes exactly one transport attempt. Durable release coordination owns every
+retry and its attempt limit.
+
+## Request
+
+The adapter canonicalizes the complete
+`blun.localization-quality-receipt-binding.v2` object and validates its native
+Unicode text, hashes, locales, content type, glossary and policy versions,
+provider/model identities, software version, two-pass confidence, locale
+quality profile, optional commercial profile and exact targeted-review summary,
+escalation requirements, and review purpose. It then sends HTTP POST with JSON content type and these
+protected headers:
+
+- `Idempotency-Key`;
+- `X-Localization-Receipt-Request-Id`; and
+- `X-Localization-Receipt-Request-Sha256`.
+
+The body is exactly:
+
+```json
+{
+  "schema": "blun.localization-receipt-verification-http-request.v1",
+  "request_id": "blun-l10n-receipt-<sha256>",
+  "binding_sha256": "<canonical binding hash>",
+  "receipt_sha256": "<opaque receipt hash>",
+  "binding": {"schema": "blun.localization-quality-receipt-binding.v2"},
+  "receipt": "<opaque receipt>"
+}
+```
+
+The deterministic request ID is derived from both hashes. Identical retries
+therefore address the same verification operation, while any changed receipt
+or binding dimension receives a different identity. The remote service must
+treat an idempotency-key collision with different bytes as a terminal error.
+
+## Response
+
+Success uses HTTP 200 and JSON content type with exactly:
+
+```json
+{
+  "schema": "blun.localization-receipt-verification-http-response.v1",
+  "request_id": "<same request ID>",
+  "request_sha256": "<exact request-body hash>",
+  "binding_sha256": "<same binding hash>",
+  "receipt_sha256": "<same receipt hash>",
+  "verified": true
+}
+```
+
+`verified: false` is a valid negative decision and permanently blocks release.
+Wrong bindings, duplicate keys, non-finite values, a UTF-8 byte-order mark,
+incorrect content lengths, oversized bodies, extra fields, redirects, and
+terminal HTTP statuses fail closed. Responses never carry reviewer prose.
+
+Network failures, HTTP 408/425/429 and HTTP 5xx, malformed successful response
+transport, and temporary parser failures are classified as retryable but are
+not retried inside the adapter. The release coordinator records only a stable,
+content-free failure code and applies its existing durable backoff and maximum
+attempt policy. Authentication, invalid requests, redirects, other HTTP
+statuses, binding mismatches, and explicit negative verdicts are terminal.
+
+The same adapter can be configured separately for quality, qualified-human,
+and independent-model receipts. Purpose is part of the signed binding, so a
+receipt accepted for one route cannot satisfy another route.

package/standard-skills/translate-native/integrations/AGENT_RULES.md

@@ -0,0 +1,32 @@
+# BLUN Language Guard — mandatory agent rules
+
+Apply these rules as always-on instructions in `AGENTS.md`, `CLAUDE.md`, or the equivalent global instruction file of the host CLI.
+
+1. Treat every user-visible natural-language answer—including ordinary chat—as an untrusted candidate.
+2. For an agent's own answer, call `release_response` with the complete final text, the exact host-supplied language tag, and truthful nativeness and orthography attestations.
+3. Load `translate-native/SKILL.md` for every translation, localization, transcreation, translated rewrite, translation review, or user-visible i18n edit.
+4. For a translation, never call `release_response`. Call `release_translation` with the complete source, complete target, exact language tag, and seven truthful attestations.
+5. Never claim an attestation passed unless that pass was actually performed. Never fabricate, reuse, edit, or switch the purpose of a release token.
+6. If either gate returns `BLOCK`, revise the candidate and call the correct gate again. Do not release blocked text.
+7. Release text only when `verify_release_token` confirms the signed receipt for the exact current text, task kind, source when applicable, locale, version, and expiry.
+8. Do not print the internal release token to the user unless debugging was explicitly requested.
+9. Never choose `task_kind`, omit a translation source, or substitute `auto`, `all`, or another language to obtain a pass. Those values belong to the trusted host adapter.
+10. If mandatory mode is enabled and the gateway is unavailable, fail closed. A direct MCP call without a host output interceptor is advisory because an agent can skip it.
+11. When `BLUN_LANGUAGE_GUARD_MANDATORY=1`, write exactly one JSON object to final stdout with only `target_text` and the valid `release_token`. Do not add Markdown fences, commentary, logs, host policy, source text, language, or task kind. The trusted host unwraps and delivers the verified target.
+12. Never call Telegram, email, HTTP response, queue, publishing, deployment, or another user-visible sender directly in mandatory mode. Return the signed envelope to the host-owned adapter instead.
+13. Read the host-supplied `BLUN_LANGUAGE_GUARD_TASK_KIND`, `BLUN_LANGUAGE_GUARD_LANGUAGE`, and `BLUN_LANGUAGE_GUARD_CONTENT_TYPE` values when present. Use them for the MCP release call, but never echo them into the final envelope.
+14. The isolated guard service owns signing and verification. Never read its token file, connect to its socket directly, or retry through local-key mode when the host requires the service.
+15. Streaming candidate prose is delivery. In mandatory mode the host buffers `text-delta` and `done` events until the complete envelope has been verified; agents must not place candidate text in tool progress, logs, reasoning, or error fields.
+16. In Claude Code, use the installed user-scoped HTTP `blun-language-guard`. If it reconnects or reports unavailable, retry only through the same guarded MCP after health is restored. Never switch to raw output or an unguarded local signer.
+
+The server injects the same policy through MCP initialization instructions and exposes a `translate-native` prompt. Hosts that support an installed skill/plugin must activate it for translations. Hosts that do not support skills still receive the MCP workflow, but deterministic checks alone cannot prove fidelity or fluency.
+# Mandatory BLUN Language Gateway
+
+- Route every user-visible natural-language answer through the host's BLUN Language Gateway.
+- Set `task_kind: response` for an agent's own answer and `task_kind: translation` for every translation, localization, transcreation, target-language rewrite, or user-visible i18n change.
+- For translations, supply the complete source and activate the installed `translate-native` skill/plugin before drafting. Never downgrade a translation to `response`.
+- Do not print, save, commit, publish, or deploy a candidate until the gateway returns `release_allowed: true` for the exact target, task kind, locale, and source when applicable.
+- Treat an unavailable gateway as `BLOCK` whenever mandatory mode is enabled.
+- Never read, request, log, or handle the gateway signing key.
+- In mandatory mode, accept that raw text or an unsigned envelope is discarded. Do not retry through an alternate delivery channel.
+- Never fabricate attestations. The host—not the agent—controls final release.