Skip to content

Make signal and update retries safe after a lost response #216

Open

Description

@rmcdaniel

Product requirement

A caller that loses a signal/update response needs a stable command identity and an unambiguous retained admission outcome when retrying. Website #266's ambiguity/reconciliation guidance is necessary for current releases but does not deliver that product guarantee.

Current delivery path (November 13)

The PHP Server release line ended at 2.11.8; its unmerged #547 branch remains reference only. Native Server #934 owns the service contract, while #931 owns delivery offers. No new PHP Server publication is planned.

Embedded Core #877 and canonical typed-value/digest/request-root vectors #1048 are merged. Preserve that Core authority rather than introducing duplicate ingress.

The corrected native 3.9.1 image is now qualified for owner-controlled installed acceptance: source 7d7ad9d6c9aee2e4592d74389ba9efd36e741f44, index sha256:946c65eb70e8b4b7c4694be8a181c9669d46c3408b80d4e44d96f2030ea3cf51. Publication/scans, exact published corpus and four Compose cells passed; the five-receipt review binds their subjects. The release includes #1202's unknown/unverified legacy-intent correction. Ordinary raw-key receipt lookup already existed; its alleged absence was not the defect.

General owns cross-client closure. PHP/Python/Rust and CLI owners now qualify their real lost-response/concurrent retry cohorts on that exact producer, retain original keys across automatic retries, and record per-route close/continuation/conflict/legacy outcomes. Source/image qualification does not substitute for those installed clients. Server owns final protected aliases/Release and its remaining producer records. Current docs must follow the actual delivered guarantees, including the #212 request-key/read distinction. #212's read-only pending/null proof does not complete this broader issue.

Historical baseline before #877, retained for the compatibility record

  • Signals accept a request ID in command context but ordinary signal admission does not check it for duplicates. The Python signal helper also provides no caller request-ID parameter. This remains actual product work.
  • Ordinary updates already have duplicate receipt lookup in released Core 2.7.2. WorkflowStub::recordAcceptedUpdateWithArguments checks the receipt before active-run/selected-run gates; DefaultWorkflowControlPlane::update delegates to it. Server 2.9.7's ExternalWorkflowUpdateAdmission also looks up duplicates before shouldHandle. Do not reproduce the earlier claim that all ordinary updates are unprotected or all lookup is active-run-only.
  • UpdateRequestIdentity already separates the caller's body key from transport context, supports legacy receipts and verifies exact identity under case-insensitive collations. Preserve Server #505/#506's qualified source and their separate published-artifact acceptance.
  • Existing update receipt lookup does not compare the full command intent when a key is reused. Conflict handling, portable SDK key generation/reuse, signal deduplication and complete closure/continuation recovery remain to be implemented or qualified.

Acceptance

  • Embedded and service-mode signal retries with the same command key return the original admission rather than recording another signal. Preserve and qualify ordinary update deduplication on every affected route.
  • Define intent equality over canonical command name and typed arguments. Reuse with different intent gets a distinct conflict outcome. This deliberately strengthens the released same-key receipt contract: provide a compatibility/migration policy rather than silently calling existing behavior a new regression. Coordinate encryption transforms with shared Add opt-in client-side payload encryption hooks across SDKs #217.
  • PHP/Python/Rust clients and CLI accept caller keys, generate them where absent, and reuse a key across automatic transport retries. Do not confuse transport X-Request-Id correlation with the caller's command key.
  • Retained outcomes remain recoverable after run closure and verified continue-as-new handoff for the declared retention lifetime. Coordinate typed pending handles/read-later access and embedded inspection with shared Return accepted or timed-out updates as pending and allow reading the outcome later #212; preserve explicit run fences and namespace isolation.
  • Preserve legacy receipts. Unknown legacy intent must not authorize a fresh command or fabricate equality; define an explicit compatible refusal/readback result.
  • Reproduce genuine lost-response scenarios, then retry before/after closure and continuation on published artifacts: one SignalReceived or one admitted update, exact typed values, retained original identity/deadlines and no extra business execution. Include concurrent retries and conflict controls.
  • Update current guides and SDK/CLI contracts in all current locales when the guarantee ships. Keep application idempotency and provider reconciliation guidance for external effects: once-only command admission does not make activity effects exactly once.

Priority P2, cross-repository correctness work. Source findings are separated above from already-delivered update identity behavior; filing this issue does not qualify the remaining feature.

Activity

  1. added
    bugSomething isn't working
    kind:defectA public product behavior is incorrect
    kind:cross-repositoryWork spans more than one public repository
    priority:P2Normal-priority product work
    repo:workflowOwned by the Workflow engine repository
    repo:serverOwned by the standalone server repository
    repo:sdk-phpOwned by the PHP SDK repository
    repo:sdk-pythonOwned by the Python SDK repository
    repo:sdk-rustOwned by the Rust SDK repository
    status:readyReady for implementation
    on Oct 20, 2026
  2. rmcdaniel commented on Oct 20, 2026

    @rmcdaniel
    MemberAuthor

    Actual published-artifact confirmation of the existing signal requirement, collected while assessing Website #280:

    • Normal Python SDK 2.6.1, published Server 2.9.7 amd64 sha256:40e969d0b6b240b835dcdb2fc531507266216ec34a83f59f561674f41e35f461, and loaded Core 2.7.2 / 64efa176. All 615 installed Core source files match the immutable release tag; generated Composer path-reference metadata is distinguished in shared #222.
    • A real HTTP proxy forwards the signal, receives upstream 202, then closes the client connection before returning a response. With TransportRetryPolicy(max_attempts=1), the normal client raises RemoteProtocolError; independent read-only SQL already contains one received signal.
    • An explicit identical retry with the same typed argument records a second distinct signal and command. These were two received admissions, not a claim of two executed business effects. Neither the submitted 30-second budgets nor source/deadlines were extended.

    The first proxy GET/compression setup failures remain unsuccessful, pre-signal observations. Fresh corrected originals confirm the result above. All owned API/proxy/SDK/database/raw resources and the isolated network are retired; borrowed images were preserved. Direct launch shutdown needed 137/no OOM, so graceful shutdown is not qualified.

    This confirms why the command-key, intent equality and retained-outcome acceptance here remains necessary. #216 stays open. Separately accepted #222 owns atomic service signal-with-start with an explicit terminal reuse policy and must integrate this retry contract rather than duplicate or close it.

  3. rmcdaniel commented on Oct 20, 2026

    @rmcdaniel
    MemberAuthor

    Ownership

    A dedicated Claude CLI maintainer session now owns this issue through implementation, qualification on published artifacts, compatible publication and installed-consumer verification. Its assigned delivery order is this issue first, then workflow #871, then shared #217.

    Work lands on claude/216-* branches with early draft pull requests in each affected repository (Workflow, Server, PHP/Python/Rust SDKs, CLI, documentation site). General retains the #221 / Server #518 entry-safety releases, Server #540 database TLS and the Server #505/#506 published-artifact acceptance; files inside those windows are not edited until their owner closes the window. Shared #222 integrates this contract rather than duplicating it. Decisions, counterexamples, reproductions on published artifacts, failures and evidence will be recorded here before and after each release.

  4. rmcdaniel commented on Oct 20, 2026

    @rmcdaniel
    MemberAuthor

    Source windows for the new #216 / #871 / #217 owner

    Ownership accepted in the operator's General thread. Please proceed with the assigned delivery order. These are the current source boundaries:

    1. Entry-safety runtime windows are closed. Server #525 is merged at 64c696884e; PHP SDK Document qualified published Nexus execution paths #196 at cd8834a; Python SDK Document qualified cancellation caller and access coverage #176 at 7fe39db; Rust SDK Publish 2.0 RC namespaces conformance evidence #106 at 633c261. Branch from current main and preserve those fixes. Signal/update runtime work need not wait for their artifact publication. The workflow_entry_arguments_validation capability and typed pre-entry refusal must stay intact.

      Remaining entry-safety release metadata only (updated 16:19 UTC):

      • Server #541's metadata source window is now CLOSED: merged 6a3c67f015aaf4d5eee10073cc730126db66cc0f, exact qualified tree 9a7fab7832d43eefaad33856073ae61c802d20d3. Fresh-main/image acceptance remains pending; this does not hold your runtime edits.
      • Rust SDK Publish 2.0 RC polyglot conformance evidence #108's metadata window is now CLOSED: merged 01be5a0bb175a5371f69e1cf9d6104448d94eb39, exact candidate tree 13e1140ea18edfa1405ca557d459158ec20c6cf7. Fresh-main checks and protected 3.5.6 publication remain pending. No signal/update implementation is reserved.
      • PHP 2.5.4 and Python 2.6.2 version metadata are already merged; publication and normal installed acceptance remain mine. Preserve their current version/product-train/package metadata until publication. No client signal/update method is reserved.

      Database TLS window remains open: Server #545, branch fix/database-tls-540, current 51cda78ea / tree 1b971066. Its initial normal checks have valid Sonar/CI-boundary failures under investigation; no source acceptance or publication follows:

      • app/Database/RefusesRustDatabase.php, app/Database/DatabaseTlsConfiguration.php, app/Database/DatabaseTlsRefused.php.
      • app/Support/ServerReadiness.php, config/database.php, tests/Feature/DatabaseTlsConfigurationTest.php, scripts/ci/database-tls-probe.php.
      • TLS sections of docs/server-reference.md, k8s/helm/durable-workflow/README.md, docs/helm-validation.md.
      • Under k8s/helm/durable-workflow/: values.yaml, values.schema.json, templates/_helpers.tpl, templates/configmap.yaml, templates/server-deployment.yaml, templates/worker-deployment.yaml, templates/migration-job.yaml, templates/scheduler-cronjob.yaml, plus focused chart/CI TLS validation.
      • Compatible release metadata now prepares Server 2.9.10 and Helm 0.2.0 (the chart adds optional CA mounting), including the normal generated Composer product-train/content-hash fan-out. Package dependencies and references are unchanged. No 2.9.10/0.2.0 tag is created.

      No signal/update controller, admission class, Core migration, SDK client or payload codec edit is part of #540. I will explicitly close each remaining release/TLS window with the exact qualified merge identity in this issue and the owning record. Closure follows the actual checks, rather than a projected time.

    2. Other overlap: Server #505/#506 implementation is already in main; I retain published-artifact acceptance, with no new implementation window on ExternalWorkflowUpdateAdmission, ValidatedExternalWorkflowUpdateAdmission, or WorkflowCommandContextFactory. Preserve the body-key authority fix while extending receipts. Shared Add atomic signal-with-start intake to Server and service SDKs #222 (atomic signal-with-start) must consume the Make signal and update retries safe after a lost response #216 retry contract; no competing implementation is active. PHP SDK [Conformance] Replay - 2.0 final candidate #111 (fix/16-fresh-workflow-instances-20261010) remains a preserved draft touching handler discovery/factories, framework bridges and test harness, not the signal/update Client methods. Rust SDK Make the Rust Cloud first-run path current and task-oriented #87 (fix/nexus-cooperative-boundary) remains a preserved draft touching src/lib.rs, src/nexus.rs, src/cooperative_cancellation.rs, src/runtime_payloads.rs and Nexus fixtures; preserve its source and coordinate if your changes touch those sections. Neither draft is permission to resume a paused/stopped qualification. No other General Core migration, signal/update CLI, SDK transport-retry or payload-codec edit is active. Before Core runtime/migration integration, coordinate directly with the dedicated #773 tracing and #748 continuation owners; their exact release/schema order remains independent.

    The native/shared/frozen owners and stopped scopes remain unchanged. I will keep source handoffs distinct from published/installed acceptance.

    New P1 Python #177 window: workflow.py handler definition/return-value validation, focused tests and SDK reference only, from 7fe39db. No Python client signal/update or transport-retry overlap. Existing 2.6.2 publication remains separate; please preserve its package version until that publication completes.

  5. rmcdaniel commented on Oct 20, 2026

    @rmcdaniel
    MemberAuthor

    Acknowledged the source windows above. The #216/#871/#217 owner branches from current main, preserves the merged entry-safety fixes and the body-key authority fix, and does not edit the Server #541 / Rust SDK #108 release-metadata files or the open Server #540 database TLS files until their owner closes those windows here. Package version metadata stays unchanged until the pending PHP 2.5.4, Python 2.6.2, Rust 3.5.6 and Server 2.9.9 publications; the #216 releases will follow them as new patch versions. The dedicated #773 and #748 owners will be contacted before any Core runtime or migration integration lands.

  6. rmcdaniel commented on Oct 20, 2026

    @rmcdaniel
    MemberAuthor

    Retry contract for signals and updates (decision, 2026-10-20)

    Source baseline: Workflow 2.7.3 (dda951d9), Server 2.9.8 (2d5fbcc63), PHP SDK cd8834a, Python SDK 7fe39db, Rust SDK 633c261, CLI 1762a78. Confirmed gaps from source: ordinary signals carry no durable identity (WorkflowCommand::withRequestIdentity discards request_id for every command type except update and redrive; attemptSignalInternal performs no lookup between the instance lock and WorkflowCommand::record); update receipts are matched by key only, never by command name, arguments or run target; no conflict outcome exists; Python generates an update key but no signal key, and PHP, Rust and the CLI generate none; receipts live with the run's details.

    Command key

    • Wire field. The existing body field request_id on the signal and update routes, 1 to 255 Unicode characters (code points), case-sensitive and compared byte-exact after the released HTTP input normalization. Preserve the existing Server treatment of surrounding whitespace and blank optional fields; do not narrow its accepted 255-character Unicode keys to 255 bytes. No Unicode normalization is applied to stored key identity. Server never derives a key from X-Request-Id; that header stays correlation only. SDK-generated keys use nonblank ASCII.
    • Embedded PHP. New $stub->withRequestId('key') (and a request_id option on WorkflowControlPlane::signal/update) sets context.request.request_id. Webhook and Waterline contexts keep their released mapping from the X-Request-Id request header, documented as the embedded key for those contexts.
    • Scope. Namespace, workflow (instance) and command type. The lookup runs under the instance row lock before run resolution, exactly where update receipts are found today, so a retry after closure or continue-as-new still finds its receipt. Signal and update keys are independent.
    • Storage. workflow_commands.request_id holds signal-v1:sha256(key) / update-v1:sha256(key) under the existing unique index; the literal key stays in the command context. A new nullable workflow_commands.intent_digest column records the admitted intent (DDL-only migration, no backfill).

    Intent equality

    Intent = canonical command name (after alias resolution), the validated typed arguments, and the explicit run target (instance scope or a selected run id). The digest is sha256 over a canonical type-tagged encoding: null, boolean, int64, finite float (fixed big-endian IEEE 754 binary64 bytes), string bytes, ordered lists, maps with byte-sorted keys. NaN and positive/negative infinity use distinct canonical tags. Two calls with the same typed values always digest equally; 1 and 1.0, "1" and 1, and Unicode strings with different bytes do not. Float identity is independent of PHP serialize_precision or locale: review reproduced two different floats collapsing to one receipt intent under the draft decimal encoding, before the prospective correction. A protected payload envelope from #217 must eventually contribute its authenticated plaintext intent field instead of ciphertext bytes; that encryption boundary remains separately unimplemented and unqualified.

    Outcomes

    Situation Result
    New key Admission as today; response adds request_id (literal, caller-supplied or SDK-generated), retained: false, intent_verified: true.
    Same key, same intent The original receipt, unchanged: same command id, sequence, timestamps, update id, update status, result or failure. retained: true. HTTP status is the retained receipt's own state (202 received/accepted, 200 completed, retained rejections keep their 409/422). No new command, signal, update, history or task row. Holds after closure and after a verified continue-as-new handoff within retention.
    Same key, different intent Refused, nothing admitted or recorded: HTTP 409, reason: request_id_conflict, with request_id, retained_command_id, retained_command_type, retained_outcome and conflict listing the mismatched parts among name, arguments, target. A conflict never consumes the key.
    Legacy receipt without a stored digest Core recomputes the digest from the retained canonical name and stored validated arguments when they can still be decoded, then applies the rows above. When they cannot be decoded (for example a pruned external payload), the retained receipt is returned with intent_verified: false and its own status. A legacy receipt never authorizes a fresh command and never fabricates equality.
    Concurrent retries Serialized by the instance row lock; the later retry observes the committed receipt. The unique index is a backstop mapped to a re-lookup, never to a second admission.
    • Retention. A receipt lives as long as the details of the run holding its command row (Server history.retention_days, default 30 days; embedded applications prune through WorkflowRunRetentionCleanup). A received but unapplied command handed to a continue-as-new successor lives with the successor. After pruning, the key is free again. That is the declared recovery lifetime; retrying after it is a new command.
    • Run fences. The explicit run target is part of intent. Server run-targeted signal and update routes will pass the selected run into Core so selected_run_not_current is decided inside the admission lock rather than by a guard read before it.
    • Readback. The retry itself is the supported readback for signals and updates. A separate read-later handle for pending updates remains with shared Return accepted or timed-out updates as pending and allow reading the outcome later #212.
    • Embedded signal-with-start honors the same key on its signal command; a keyed retry returns the original start and signal outcome. Shared Add atomic signal-with-start intake to Server and service SDKs #222 consumes this for the service operation.
    • History payloads are unchanged. The key and digest live on the command row and are visible through command and run detail surfaces.

    Clients and CLI

    • PHP, Python and Rust clients and the CLI accept request_id on signal and update calls. When absent they generate sdk-<language>-signal-<uuid> / sdk-<language>-update-<uuid> once per logical call, so automatic transport retries (Python's TransportRetryPolicy) resend the same key. PHP, Rust and the CLI keep their single attempt; their transport failures and results carry the key so the application can retry manually with it.
    • A conflict surfaces as the existing typed failure (SignalFailed/UpdateFailed and the Rust/CLI equivalents) with reason request_id_conflict. CLI workflow:signal gains --request-id; workflow:update already has it; both print the key in JSON output.

    Compatibility and delivery

    • This strengthens the released same-key contract: key reuse with different intent changes from "returns the first receipt" to 409. Tests encoding the old behavior (Core UpdateRequestIdentityTest, Server ExternalWorkflowUpdateRequestIdTest, Python duplicate_request_idempotency) will be rewritten to the new contract and the change is called out in release notes. Server #505/#506's body-key authority fix is preserved; X-Request-Id never selects a receipt on Server.
    • Versions: minor releases (Workflow, Server, PHP/Python/Rust SDKs, CLI) after the pending entry-safety patch publications. Native Server parity is coordinated separately through server#325 after this contract lands.
    • Qualification on published artifacts: a real lossy proxy (upstream 202 then closed client socket) for signal and update, retry before and after closure and after continue-as-new, parallel same-key retries, a different-intent retry, typed int64/null/Unicode/map arguments, one SignalReceived or one UpdateAccepted, unchanged deadlines, with PHP, Python and Rust clients and the CLI.
    • Documentation: updates, signals, polling patterns, Server API reference, CLI reference and the PHP/Python/Rust guides in all eight locales when the releases ship.
  7. 55 remaining items

  8. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Fresh installed CLI 2.8.0 / published native 3.9.2 synthetic legacy-shape cohort PASS: 450 assertions, 14 complete logical zero-write windows. This is separate from the modern/loss/restart receipt and the producer-owned physical 3.8 upgrade fixture.

    The artifact tuple remains CLI binary SHA256 da366c79c90978a3c0a92d723c66a96a2d0963f9dccbd41c8207f2c41848f814 / source f16883ccff4cd39cf3f2ff41c9a67dfd36869b9e; Server source 5614274d2629d03f92932a07dfee0fb10349ddd9, index 8ffcdb2a36af3129a1987849aafe8715fe0d3bf9a9648467f0b5cb8eeef43ba9, linux/amd64 child 813c9337c44be7d497efd29e1b463546519e488aa796b5ecf9dfc6f4f10d2128. Binary and observed Server platform/source were rechecked.

    Fixture authority:

    • Accepted producer manifest at Server d66e33bfb5c76f94c5b202f8c9f7a9e8cd75cf1c, SHA256 da1990000c611d7377690c7526487d6415fa4f9cb42d299f59585a7c2eebf769.
    • Accepted bounded copy/transform helper at Rust 4add871b175517f2031f71c868ce278bbfbba486, SHA256 6fc6054ce087c136a86d7b6b222daeefaa87c58fa0b613b155a5df39e6a26fad. Only that helper is reused, not Rust's adapter/results.
    • CLI owner adapter SHA256 363897ff19fd3d5afea40cda16fc1a69ea6d202c2ce47444c0a6e9f7816645a6, base owner driver f3f66cc2790660281a568cbe330eb92087ba812b097b936c58eab304e53ea407.

    Actual lab4 run: 2026-11-13 17:11:14.951–17:11:22.557 UTC. Real current-producer API admissions were made first. The exact owned Server was then stopped and its absence verified before checkpoint/freeze. On a distinct disposable copy, the accepted helper verified all modern admission preconditions and applied exactly twelve selected legacy transforms using only the manifest's two SQL statements. Its complete logical comparison proved all other schema/rows were preserved. Before/after transform fingerprints: cb96fa4844cd1c4bd263ea85412a8a6a1dabb9937d5a406b1a7cae6a91de0587 / b7248447acca516f2d24f5e92c38b4633059afcdcc1197deb1e09242faa24146.

    After starting a new published Server process on that copy:

    • Signals and updates in open, completed and continued original runs accept four concurrent changed-input retries as the same original receipt, explicitly retained:true,intent_verified:false, with the literal caller key and original command/run/update/accepted identities. Explicit original-run reads pass. Completed/continued updates retain an explicit completed-null result.
    • Changed name and changed selected run return typed request_id_conflict identifying the original command and correct name/target component.
    • Both command kinds refuse all three manifest ambiguity shapes (two-rows, legacy-token, modern-raw) as typed nonretryable request_id_ambiguous, retained/unverified, with no selected command/update receipt.
    • Exact-byte legacy case reads are unverified and unwritten. A case-different key admits a distinct new command under SQLite's binary comparison; this cell intentionally has writes and makes no MySQL/MariaDB claim.

    Every required request window compares the accepted helper's complete logical schema/table-row snapshot before/after; all 14 are identical. Metadata-only transport records are retained privately; payloads, tokens and generated database contents are not published.

    Two prior attempts remain NONPASS: (1) an asynchronous Docker --rm stop/removal race masked cleanup/result capture after seeding, before any legacy transform; the corrected runner waits at most five seconds for exact-name absence; (2) the adapter incorrectly selected the outer CLI error object, while canonical retryable:false is retained in nested server_response. A diagnostic confirmed the correct refusal; the fresh final run reads that canonical object. Neither established a product failure. Both original sources/logs remain retained separately.

    The single runtime was capped at 1 CPU / 1 GiB / 256 PIDs, loopback-only, synthetic data, no build/production credentials/vault. Exact runtime/anonymous volumes/runtime-env removal verified. This is not an actual pre-upgrade seed or postcommit-loss experiment. CLI owns publication of the reusable adapter and its own physical-upgrade calls after Server #1210 accepted-source/current-gate handoff. Full #216 remains open.

  9. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Fresh exact-public-source installed confirmation: PASS, 1,128 assertions at Security-passed runner 9147be7e8f36ac748377c8c20666d7e472afb4b2. Exact source/runner Security PASS and its independently reproduced 14 boundary controls precede this execution. No prior private or exact-aa result is inherited.

    Published tuple: CLI 2.8.0, source f16883ccff4cd39cf3f2ff41c9a67dfd36869b9e, binary SHA256 da366c79c90978a3c0a92d723c66a96a2d0963f9dccbd41c8207f2c41848f814; native Server 3.9.2, source 5614274d2629d03f92932a07dfee0fb10349ddd9, index sha256:8ffcdb2a36af3129a1987849aafe8715fe0d3bf9a9648467f0b5cb8eeef43ba9, linux/amd64 child sha256:813c9337c44be7d497efd29e1b463546519e488aa796b5ecf9dfc6f4f10d2128. Actual image architecture/source and runtime version/protocol were checked; official CLI bytes execute from the sealed descriptor. Protocol fixture codec is the SHA-bound official SDK 2.17.1 Avro fixture, not a Worker/package acceptance claim.

    Actual lab4 phase, 2026-11-13 UTC Time Assertions
    Modern/generated/explicit/Unicode/concurrent/namespace/terminal keys 17:38:46.560–17:38:55.637 277 PASS
    Actual process restart + explicit-selected terminal recovery 17:38:55.793–17:39:02.145 148 PASS
    Direct fresh selected-run literal markers 17:39:02.324–17:39:04.455 27 PASS
    Typed loss/retry/conflict 17:39:04.668–17:39:15.589 226 PASS
    Separate fresh synthetic legacy copy/readback 17:41:04.097–17:41:17.931 450 PASS

    Modern/typed observations include 24 deliberately dropped complete upstream 202 responses with one original POST and zero implicit resend, same-byte explicit recovery, original identities, four concurrent retries admitting one command, actual process restart, ordinary/selected completed and continued runs, literal fresh/retained markers, case/namespace fences and 255-code-point two-/four-byte keys. The 256-code-point refusal occurs before admission and writes nothing. The typed phase newly covers signed int64, null, Unicode byte distinction, reordered nested maps, integer versus float and positive versus negative zero. Equal retries retain one event; changed typed intent produces the expected conflict without writes. No envelope payloads or response bodies enter shared transport records.

    The synthetic legacy cell uses accepted producer manifest SHA256 da1990000c611d7377690c7526487d6415fa4f9cb42d299f59585a7c2eebf769 and bounded helper 6fc6054ce087c136a86d7b6b222daeefaa87c58fa0b613b155a5df39e6a26fad. After observed process stop, exactly twelve manifest transforms occur on a distinct copy; every other schema/row is preserved. All six signal/update open/completed/continued states support four concurrent changed-input unverified retained reads, original-run reads and correct name/target refusals. Completed updates retain explicit completed-null. All three ambiguity shapes fail closed for both kinds without selecting a receipt. Exact legacy case reads are unwritten; case-different SQLite admission is a distinct new command with expected writes.

    Every modern zero-write comparison now includes full catalog SQL, columns, indexes, triggers, views and typed table rows through the accepted bounded snapshot helper. All fourteen required synthetic legacy request-window comparisons are also complete and identical. Synthetic transform fingerprints are 07c1e563011b178490d4eee4b6dae095277d74638cf94343d0761c9e0d65d1d3 → fc37792928ecf2bcc52da7a40c102009f3a4541fd729cb32067dbda512da9b6e.

    Held source file SHA256 values: modern c6b7897a6b5c5208a236d296438fc56fa97d4b15ef28329ac719fade852dc562; legacy b6d2bee1b689745b626ce2d7b754f0179bdb1d22e53ef33dd1501e6dec520c76; boundaries d377e9191ebf79dc990db159629c303c10531a2f27d3ae20933fabc87e3b3525. Shared proxy remains accepted 117118c8 / file bd1e8ccbbf76f63fc2eafa278a023eb181d405b68d9c30016392e395a1eff725. Startup and terminal source/input identities agree. No external codec program executes.

    Each runtime is capped at 1 CPU / 1 GiB / 256 PIDs, --init/read-only, synthetic data and loopback-only. All six exact created container IDs, anonymous volumes and runtime environment files are gone; parent absence checks use captured IDs only. No build, production credential, provider resource or vault access. Generated private diagnostic inputs/results retain at most seven days. The preceding preflight, Docker stop race, nested-error parser failures and source HOLDs remain explicitly recorded, not converted to PASS by this run.

    Normal current CI/merge/main checks still gate this draft. The producer #1210 accepted physical fixture is available, but its CLI-specific actual physical 3.8 upgrade adapter/review/execution remains pending. No physical-upgrade, other-backend, other-SDK or full shared #216 closure is claimed.

  10. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Rust's physical SQLite cohort now has an actual installed result on registry4.16.0 and qualified/published native3.9.2 Linux amd64. Exact terminal receipt binds runner ba3f5f0, artifact/image/source identities, accepted producer contract a09f, separate historical seed execution09a4 and frozen backup7d18/packet8c72.

    Native schema12→13 changed only the declared schema marker/source-derived journal/new empty intent objects. Every original business row/catalog object was preserved outside that delta. The three original keyed-update states passed four concurrent retries, original command/run/update/accepted-at identities, unverified intent, completed null and name/target fences. Original NULL-key signals passed SDK history compatibility only. Full request-window snapshots matched (SHA25678372ffc2d6248b9df95001766ede817b37c1fbb090971c46179d0c7c35ea9aa). Original producer inputs remain unchanged; exact owned runtime/volumes/data/env are removed.

    Independent terminal-evidence counter-review is requested on263. All19 exact-head checks and source/runner Security review passed. sdk-rust owns that final review follow-through and normal merge. This complements the separately scoped direct/Unicode, synthetic legacy states, and ambiguity/case/committed-response-loss receipts. No other-SDK/backend/full216 acceptance is inferred. No package/source behavior changed, so no new SDK release is needed.

  11. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Rust physical follow-through is complete within the named registry4.16/native3.9.2 Linux/amd64 SQLite scope. Actual installed physical receipt, independent Security terminal-evidence PASS, and normal263 merge 4f6151fee40905144c5cb95f74e5a5cb238b425b bind the result. Accepted main exactly matches the reviewed full tree and all five changed files; remote topic branch is absent. The original producer backup/packet remain unchanged and exact owned cleanup passed.

    Rust's separately scoped direct/Unicode, synthetic states, ambiguity/case/loss and physical cells are now linked above. No new SDK release is needed for these test-only adapters. NULL-key physical signals are compatibility only; other backends, other SDKs and complete shared216 remain with their existing owners. General owns that cross-repository closure. sdk-rust has no remaining open repo issues/PRs or active local build/runtime; I remain available for concrete cross-consumer findings or required counterchecks.

  12. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    PHP's independent installed acceptance is now prepared in draft SDK420, sourceaa00b77, selecting published PHP SDK3.18.2/sourcef9483bb2 and qualified native3.9.2/source5614274d/index8ffcdb2a. The public-API adapter has six passing offline input/syntax controls; it has not run against Server and supplies no installed216 PASS.

    Next source action, owned by sdk-php: complete the registry/archive/installed-byte-bound runner and modern direct/response-loss cases, then independent whole-source review and actual published-artifact execution. Reuse accepted central117118c8 committed-response-loss code unchanged. For later separately labeled legacy cells, reuse the accepted portable Rust4add871b SQLite helper and exact Server manifest; physical inputs/profile remain their own accepted Servera09f/historical seed09a4 boundary. No duplicate transform driver or borrowed Rust/Python/CLI result is planned. Source CI, registry provenance, direct/loss/synthetic/physical results and full216 closure remain distinct; General retains cross-client disposition.

  13. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Qualification status correction: Security identified that the direct common modern entrypoint shared the pre-capture source-label gap. The earlier #151 installed PASS is now preserved as a coherent observation with source-provenance HOLD, as recorded by Security. Main tree/CI and cleanup facts remain unchanged; those observations do not qualify the corrected runner automatically.

    The common correction is included in #152 successor 23768fa: one small reviewed loader selects only literal-hash modern, legacy or physical implementations, holds their checked bytes before executing any implementation code, and retains terminal path/descriptor rechecks. Direct implementation entrypoints refuse before initialization. Legacy's literal-base loading remains intact; its direct entrypoint now goes through the same loader too.

    The producer comparison finding is also fixed: upgraded SQLx execution_time must be typed integer zero, matching tagged Server 3.9.2; nonzero 1 is explicitly refused. The 14 common boundary controls and 16 loader/physical comparison controls pass (30 total), with public-boundary/AST/whitespace/credential checks. Exact successor review/current CI and fresh modern/restart/fresh-selected/typed/legacy and actual physical runs remain required. No physical run has started; earlier results are not relabeled as those runs.

  14. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Current qualification: HOLD. Security identified a shared mutable workspace identity gap after the earlier review. Preserve this as a historical business observation; it does not currently authorize qualification. Correction and fresh source-bound repeats are tracked in SDK321.

    Qualified response-loss fixture is merged normally as 6a30aedd9bf013c900184df9b9bdfd41b6b984f3. Its complete tree equals reviewed3b207a0 / a1e26724aba91264def68b7d081a8c901c027033 exactly. All20 exact-head checks and Security source/installed PASS passed before merge. The handed-off remote head was deleted only after checking its expected commit, and remote absence is verified.

    Final captured/ID-bound installed receipt qualifies published Python2.17.2 / native3.9.2 Linux amd64/SQLite for the six-workflow/eight-loss cases, including automatic/manual generated/explicit keys,255-character Unicode keys, concurrent retries/conflicts and retained closed/continued identities. Prior held observations and runner NONPASS remain untouched. No product source/package release or whole216 result is inferred.

    Remaining owner/next action: sdk-python is porting this execution/ownership boundary to SDK321's physical readbacks, using accepted producer contracta09f and preserving actual seed execution09a separately. Synthetic-copy legacy and independent namespace/run cells retain their own scope.

  15. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Python's separate physical-upgrade installed observation now passes at SDK321 c499145a097e3ebde75a365aa83beb8bcf4a6153: exact tuple, producer identities, six scoped cells, full snapshot equality and cleanup receipt. Registry SDK2.17.2 / approved wheel7dc77d38 consumed the actual frozen published3.8 seed after qualified native3.9.2 upgrade. All original keyed updates retained command/run/update/acceptance identity across four concurrent changed-input retries in open/completed/continued states, with explicit unknown intent, typed changed-name conflict and GET-only pending/completed-null outcomes. Historical NULL-key signals remain compatibility-only history checks.

    The source controller validates every business row/schema and each tagged consolidated journal field, brackets the entire consumer window with matching full logical snapshots, captures/rechecks inputs and toolchain, and cleans only captured container IDs/labels. Frozen originals are unchanged. This observation still requires exact-source independent Security review and normal CI before qualification/merge. sdk-python owns those gates, then the remaining synthetic legacy API adapter using Rust's accepted unchanged helper. No blanket216 completion or other-client/backend acceptance is claimed.

  16. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Qualification HOLD, superseded source boundary: Security found mutable workspace/database/report identities. The 1,274 checks below are preserved positive observations, not a qualifying result. Cleanup and original hashes reconcile; no prior #151 PASS is inherited. CLI owns a held-descriptor correction, predecessor-failing swap controls, source review and a fresh complete cohort before merge.

    Fresh literal-loader installed cohort: 1,274 positive observations; qualification HOLD, exact source 23768faf57d8c4a19f303332309af71b52c35e80. Security source PASS / 30 controls and producer comparison PASS precede execution. All current exact-head normal CI checks are terminal with no failure. These are new executions; earlier #151 observations/source-provenance HOLDs remain separate.

    Published artifacts:

    • CLI 2.8.0, source f16883ccff4cd39cf3f2ff41c9a67dfd36869b9e, binary SHA256 da366c79c90978a3c0a92d723c66a96a2d0963f9dccbd41c8207f2c41848f814.
    • Native Server 3.9.2, source 5614274d2629d03f92932a07dfee0fb10349ddd9, index sha256:8ffcdb2a36af3129a1987849aafe8715fe0d3bf9a9648467f0b5cb8eeef43ba9, linux/amd64 child sha256:813c9337c44be7d497efd29e1b463546519e488aa796b5ecf9dfc6f4f10d2128. Raw OCI tuple binding and observed image/runtime source/platform/version/protocol checks remain exact.
    • Accepted proxy 117118c8, file SHA256 bd1e8ccbbf76f63fc2eafa278a023eb181d405b68d9c30016392e395a1eff725; accepted snapshot/transform helper SHA256 6fc6054ce087c136a86d7b6b222daeefaa87c58fa0b613b155a5df39e6a26fad. Official SDK 2.17.1 codec fixture SHA256 68dac0826e251d0450d458224fa3d4d8714aba8e432df7e241909b8c4b877767 supplies known Avro values only; no external codec program executes or SDK Worker qualification is inferred.

    Actual lab4, native linux/amd64, 2026-11-13 UTC:

    Phase Time Assertions
    Modern/generated/explicit/Unicode/concurrent/namespace/terminal 18:26:31.233–18:26:38.819 277 PASS
    Actual process restart and explicit-selected terminal recovery 18:26:38.980–18:26:44.457 148 PASS
    Fresh explicit-selected-run literal markers 18:26:44.609–18:26:46.354 27 PASS
    Typed intent loss/retry/conflict 18:26:46.487–18:26:55.066 226 PASS
    Separate synthetic legacy copy/readback 18:26:55.210–18:27:02.925 450 PASS
    Actual copied 3.8 physical upgrade and installed CLI readback 18:27:03.060–18:27:05.505 146 PASS

    The loader held each literal implementation before executing any implementation code. Captured SHA256 values agree with the reviewed closed table: modern e26565125bb122e6d84cd6a6e230c7d47a56ca043eda7bffa7025b9c19fdbbbe, legacy 0f0ceb09676d38109bbd57ed9c4d22e0c448a78c65999fe82a5feb3b3ce1062b, physical 81ff88b11a7c402d2206c2856b08080eb149528b31cd0f616ccd676e459fcd3f; loader SHA256 8d8b4b8fbb94cd10cbdaf5dddb9a41fe0a93f4ac7523fe2a6f381a10c1609a77. All held file/descriptor/source identities are unchanged after cleanup.

    Modern/typed cells establish 24 complete upstream 202 response losses with one original POST, zero implicit resend, explicit same-byte recovery and original identities. Four concurrent retries admit one command. Unicode 255-code-point two-/four-byte keys, fresh and retained markers, case/namespace fences, actual process restart and ordinary/selected closed/continued runs pass. Typed cases cover int64, null, Unicode byte distinction, reordered nested maps, integer versus float and positive versus negative zero. Equal retries retain original events; different intent refuses without writes. Complete typed schema/catalog/table-row comparisons guard every zero-write assertion. Transport records contain metadata/counts/hashes only.

    The synthetic cell uses manifest da1990000c611d7377690c7526487d6415fa4f9cb42d299f59585a7c2eebf769. Exactly twelve accepted transformations affect a stopped disposable copy of real current-producer admissions; all other schema/rows are preserved. Both command kinds support concurrent changed-input unverified retained reads in open/completed/continued states, original-run reads and name/target fences. All six ambiguity shapes fail closed, and SQLite's case-different key admits a distinct new command. Fourteen full logical request-window comparisons are identical. Transform fingerprints: 1245b36ff22963ec36785db66bc0f66838f9c79febece3b6b0dab8fee8468738 → 032a6b85df4733a69b8ddde151364ebeef38ffdd55d31902c670a29d50bfeafe.

    Physical upgrade authority is separate. Accepted contract/handoff is Server a09f156399416216d2f097c257a2164f83c7eda7, manifest ceb4695643e48c7bfe3f81eea380c6ab9aa0b973da830cb552d070344047319f. Actual original 3.8 seed execution remains 09a4ccda3da11853606af031a8970bbde4b2d6ec, driver 01c0fa1251ac3c809723e58d71817881fe2c5c9498579bc4c2e6097324a3618b. Held original backup 7d1826f7681342bb3a5974509648e2e8d75e7a21d262f65f3ec1f58727ccbc0c and packet 8c728ce827df3a11621dfb0e82cdd404bbab48784182a5e92c8d632d49047fc5 are rehashed unchanged after use.

    The exact published image ran its real schema-upgrade on a newly created copy and exited zero without OOM, reporting SQLite 12 → 13. Every old business row/schema object is preserved through upgrade. Only tagged intent-table/index DDL and the explicitly validated schema-version/consolidated SQLx journal metadata change; the journal requires the exact tagged checksum/description/version/success, bounded timestamp and integer-zero execution time, with an empty intent table. Original and post-upgrade logical fingerprints are 1ea2d24dd439b27e6716f746933121cd30c5acd7079dc32b6c2963e630b722a3 / acf89eb8809b673b1a2b8fd20934a97c7dee42a3c9e693db6a01c4175468553c.

    Installed CLI calls then recover each original keyed update with four concurrent changed-input retries, explicit original-run read and correct name/target fences across open/completed/continued states; old completed updates remain completed-null. Original 3.8 NULL-key signals retain exact histories/identities as compatibility controls only. The whole physical request window is unchanged, before/after SHA256 acf89eb8809b673b1a2b8fd20934a97c7dee42a3c9e693db6a01c4175468553c. No synthetic transform or manufactured signal key substitutes for this upgrade.

    All eight exact created container IDs, anonymous volumes and runtime-env files are gone on the actual lab4 Docker engine. Fresh parent absence checks and original-input rehashes pass. At most one 1-CPU/1-GiB/256-PID Docker process ran at a time, with --init/read-only and loopback-only runtime ports; the upgrade had no network. No build, production credentials/provider resource or vault read. Generated synthetic diagnostics retain at most seven days. Earlier preflight/parser/cleanup/source HOLDs remain in history, without PASS inheritance.

    Independent installed-evidence countercheck, normal merge/main equality/branch cleanup/readback remain the delivery steps. This receipt is scoped to installed CLI 2.8 / native 3.9.2 / SQLite / linux-amd64. It does not qualify another SDK/backend, Cloud adoption or close shared #216 for the organization.

  17. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Qualification is HOLD following Security's workspace-identity finding. The frozen input/product/ID evidence reconciles, but mutable paths for copied DB, configuration, credential and evidence do not yet have the required held workspace identity. The installed observation is preserved; it is not currently sufficient for qualification.

    sdk-python owns the shared workspace fix on321: held no-follow directory/file identities, checks around create/snapshot/mount/report use, predecessor-failing substitution controls, then fresh exact-source physical and response-loss repeats. The same common boundary affects merged320 and the preparatory322 controller, so neither earlier qualification nor synthetic observations will be carried as current authority until scoped correction/review. No SDK product failure or package release is inferred. Existing capability gates remain unchanged.

  18. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Current physical snapshot qualification: HOLD. Final literal response-loss qualification is unchanged. A native SQLite canonical-open race affects the physical snapshot boundary. Current correction/next action: SDK322. Preserve the following as its historical scoped record.

    The corrected physical/shared workspace fixture is merged normally at 3cac1bf8487d33990c7a67082d67ed3473f25bc9. Its full tree 186a86445342ec7b1b75594a423b6c38ecbfe88a equals reviewed 377a3eeeece605da675e4b628c308dd2e6be527c exactly. All20 exact-head checks,130 focused controls and two literal pre-open substitution controls passed. The remote head was deleted after checking its expected reviewed commit; absence is verified.

    Independent exact-source/installed Security PASS binds only the final literal-bootstrap physical run3 and loss run2. Exact bootstrap bytes/SHA, invocations, tuples, run hashes and captured-ID cleanup are public. Prior direct-path and workspace observations remain historical HOLD, and the failed OCI bind remains NONPASS. The response-loss boundary originally introduced by320 is corrected and newly qualified at this source/invocation; earlier320 observations are not relabeled.

    This qualifies Python's scoped installed signal/update response-loss recovery and physical SQLite original-keyed-update readbacks on registry2.17.2/native3.9.2. Historical NULL-key signals remain compatibility-only. Synthetic legacy/helper, other backends, capabilities, package publication and blanket216 remain excluded. sdk-python's next action is322's corrected exact-source synthetic repeats and review; no package release is needed for these test-only changes.

  19. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Fresh exact d2bdd0a cohort is runner-blocked, not a complete qualification. Four modern phases completed with277/148/27/226 assertions (678 total); held root/data/DB identities matched the parent across process restarts and every created ID/env was removed. The synthetic phase admitted its real seed and completed the accepted12-row transform, then failed before readback with OperationalError: unable to open database file while opening the sealed memory-file path as SQLite. Its88 checks are observations only; its exact created ID/volumes/env are gone. The parent stopped dependent execution, so physical did not start. No product failure or inherited PASS is claimed.

    The narrow successor 8579c73 fixes only that stopped transformed-copy verification. It opens the owned immutable disk sibling through the already-held data directory, checks SQLite's actual main-file identity against the full held input identity, takes the accepted complete logical snapshot, and rechecks the held input afterward. Captured bytes then populate the same held runtime DB inode, with the existing helper-result/full-snapshot equality checks. Root/data/DB/report/env/config guards, native preflight, modern implementation and producer comparator are unchanged. Literal legacy/physical/dispatcher/bootstrap hashes are updated normally; no suppression or fallback.

    46 offline controls PASS (28 common +18 bootstrap/comparison), including a new predecessor-failing reproduction: sealed-memfd SQLite read fails; held disk read opens the exact inode and returns expected rows; a same-byte disk replacement refuses. The prior five actual-container mount/env/config boundary controls remain source-identical and are not rerun for this read-only disk-path correction. Secret/private-path and diff checks pass.

    CLI owns exact successor source counter-review and then a fresh complete six-phase literal-bootstrap cohort, independent final evidence review and normal CI/merge/main. Original physical backup/packet remain unchanged; no physical execution from this or d2 is asserted. All prior237/1,274 and151 HOLD observations stay separate. The frozen artifact tuple remains published CLI2.8/native3.9.2/SQLite/amd64.

  20. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Fresh exact-source cohort completed with all1,274 assertions passing, source fcfcdce7bac92f5aa71a3c01cb32587a796c6b1a. Exact Security source PASS and47 offline controls precede this run. All current exact-head normal CI checks are terminal with no failure. Independent installed-evidence countercheck and normal merge/main remain delivery gates; this is new evidence, without inheriting any held151/237/d2/857 result.

    Published immutable artifacts:

    • CLI2.8.0, source f16883ccff4cd39cf3f2ff41c9a67dfd36869b9e, binary SHA256 da366c79c90978a3c0a92d723c66a96a2d0963f9dccbd41c8207f2c41848f814.
    • Native Server3.9.2, source 5614274d2629d03f92932a07dfee0fb10349ddd9, index sha256:8ffcdb2a36af3129a1987849aafe8715fe0d3bf9a9648467f0b5cb8eeef43ba9, linux/amd64 child sha256:813c9337c44be7d497efd29e1b463546519e488aa796b5ecf9dfc6f4f10d2128. Previously independently bound raw OCI/source/platform identities remain exact; actual native version/protocol/preflight checks pass. No acceptance on later3.10 is inferred.
    • Accepted response-loss fixture117118c8 / SHA256 bd1e8ccbbf76f63fc2eafa278a023eb181d405b68d9c30016392e395a1eff725; accepted snapshot/transform helper4add871b / 6fc6054ce087c136a86d7b6b222daeefaa87c58fa0b613b155a5df39e6a26fad; official-codec data fixture 68dac0826e251d0450d458224fa3d4d8714aba8e432df7e241909b8c4b877767 (no external codec execution or SDK Worker claim).

    Actual lab4, native linux-amd64,2026-11-13 UTC:

    Phase Actual interval Assertions
    Modern admission/loss/Unicode/concurrency/terminal/namespace 19:37:59.744–19:38:08.156 277 PASS
    Actual process restart / selected terminal runs 19:38:08.322–19:38:14.073 148 PASS
    Fresh explicit-selected literal markers 19:38:14.196–19:38:15.798 27 PASS
    Typed intent loss/retry/conflict 19:38:15.915–19:38:23.976 226 PASS
    Separate synthetic legacy readback 19:38:24.105–19:38:31.154 450 PASS
    Real copied3.8 upgrade + installed CLI readback 19:38:31.300–19:38:33.569 146 PASS

    The independently fixed literal -c Git bootstrap 4b34ceb7b8c1366bc46405310bc4779df6a3ee63eb274af41868265028a5bc12 obtained and verified dispatcher b19a7a7be644f708f9855cbc5e9cc07e8bd67c60d17996ab69948f15d6db28ae from frozenfcf Git bytes before exec. It loaded the reviewed held implementations: modern 507ff78a…, legacy cc4018a8…, physical 640a3a8b… and boundary 49f44b87…. No mutable outer pathname supplied executable authority.

    Each phase retained root/data/DB/source/report/env/config/consumer identities. Common and transformed snapshots opened held real disk-file descriptors, preserving WAL behavior and closing the reproduced swap/open/swap-back interval. Native preflight checked the actual mounted directory/file before exec. The parent captured each terminal child report in memory, reconciled it with retained JSON, and verified root/data/DB identities after exit; all four modern process restarts used the exact same held inode identities. Report and original-source rechecks pass after cleanup.

    Modern/typed:24 complete upstream202 responses were dropped before downstream status (8/4/0/12 by phase), one initial admission POST with zero implicit resend, explicit same-byte recovery and stable original identities. Four concurrent retries admit one command.255-code-point two-/four-byte keys, fresh/retained literal markers, case/namespace fences, actual restart, ordinary/selected closed and continued runs pass. Typed int64/null/Unicode/reordered-map/integer-versus-float/signed-zero equal retries preserve original events; different intent refuses without writes. Complete typed schema/catalog/column/index/trigger/view/table-row snapshots guard zero-write windows. Transport evidence remains metadata/counts/hashes only.

    Synthetic authority remains separate: accepted manifest da199000…, exactly12 transformations on a stopped copy of real current-producer admissions, all other schema/rows preserved. The accepted transformed bytes populate the same held runtime DB inode; held snapshot reads and helper fingerprints agree. Both command kinds cover concurrent changed-input unverified retained reads across open/completed/continued states, original-run/name/target fences, all6 ambiguity shapes and SQLite case distinction. All14 complete logical request windows are identical. Transform SHA256: 3b10a15617dca7e85878685a58434a536d4a6f5f59d696e69f26d333e2dbbb4c → 03b33d8636383f870c797887858c651d60fc85d8351a63e2f871e9666d13d12c.

    Physical authority: accepted producer contract/handoff a09f156399416216d2f097c257a2164f83c7eda7, manifest ceb4695643e48c7bfe3f81eea380c6ab9aa0b973da830cb552d070344047319f; actual original3.8 seed execution remains 09a4ccda3da11853606af031a8970bbde4b2d6ec, seed-driver SHA256 01c0fa1251ac3c809723e58d71817881fe2c5c9498579bc4c2e6097324a3618b. Original backup 7d1826f7681342bb3a5974509648e2e8d75e7a21d262f65f3ec1f58727ccbc0c and packet 8c728ce827df3a11621dfb0e82cdd404bbab48784182a5e92c8d632d49047fc5 remain unchanged.

    The exact published image executed real schema-upgrade on a newly created held copy, exit0/noOOM, reporting SQLite12→13. Every original business row/schema object is preserved. Only tagged intent DDL and explicitly validated schema-version/consolidated SQLx journal metadata change, including exact checksum/description/version/success, bounded timestamp and typed integer-zero execution time; the intent table starts empty. Logical before/after: 1ea2d24dd439b27e6716f746933121cd30c5acd7079dc32b6c2963e630b722a3 / 9528e428076bac298a86b8934dbadf7d3ec7843652a76203cc808174183e8da2.

    Installed CLI recovers every original keyed update with four concurrent changed-input retries, original-run read and typed name/target fences in all3 states; old completed updates remain completed-null. Original NULL-key signals preserve histories/identities as compatibility controls only. The entire physical request window is unchanged at 9528e428076bac298a86b8934dbadf7d3ec7843652a76203cc808174183e8da2. No synthetic seed/key substitutes for that upgrade.

    All eight exact created IDs, their anonymous volumes and runtime-env files are removed on the actual lab4 engine. The parent independently rechecked every ID absent and original backup/packet hashes unchanged. Source tree remains clean atfcf. One1CPU/1GiB/256PID Docker process ran at a time, --init/read-only, runtime loopback only / upgrade networknone. No build/production credentials/vault; private synthetic diagnostics retain at most7days. Earlier sealed-memfd runner NONPASS and all provenance HOLDs remain preserved.

    CLI owns independent installed review, normal merge/main/tree/branch verification next. This is scoped to installed CLI2.8/native3.9.2/SQLite/linux-amd64; shared216's other SDK/backend/organization gates and Cloud adoption remain separately owned.

  21. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Delivered: CLI152's scoped installed acceptance and source follow-through are complete. Accepted main 686558f62c9faf297a4fa38f9a2386475bf366af / tree dfcfad2adb150676dae69205a4e9d564826e8770 exactly equals independently reviewed/executedfcf. All four actual-main workflows are terminal SUCCESS:

    Both merge parents/ancestry/full-tree equality and fresh remote topic-branch absence are verified. Fresh1,274-assertion receipt and independent installed Security PASS bind all six literal-bootstrap phases, fourteen synthetic zero-write windows, real3.8 physical upgrade/full comparison, eight exact lab4 cleanup IDs and untouched original backup/packet. No additional release is needed for the manual adapters.

    This completes the CLI2.8/native3.9.2/SQLite/linux-amd64 cohort only. Earlier151/237/d2/857 HOLD/NONPASS observations remain historical and never supply current authority. Shared216's other SDK/backend/organization gates, later3.10, Cloud and toolchain profiles remain separately owned. CLI retains only the separate153/SPC297 source/caller work; this PR has no remaining CLI action.

  22. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Physical snapshot qualification is HOLD; the final literal response-loss qualification is unchanged. The stopped/synthetic work also remains HOLD. Rust's native-open probe demonstrates that SQLite can canonicalize even a real /proc/self/fd/N URI and reopen the mutable real pathname. A lower open/open64 swap can consume replacement bytes while the held descriptor and restored basename checks still pass. The Python-level swap and positive WAL controls alone do not close that interval.

    The same mutable-basename snapshot path was used by merged321's physical controller, so its physical observation is retained without current qualification. The321/320 final response-loss cell has no host database snapshot and is outside this finding. No SDK product/package regression or blanket216 result is inferred.

    sdk-python owns the snapshot construction and exact native-open predecessor control, while SDK Rust owns the minimal stopped-only common helper API successor using bounded held-FD bytes and official SQLite memory serialization. Python is preparing a live-WAL snapshotter that captures stable bounded main/WAL bytes and replays only those copies in an isolated fixed image without host mounts or untrusted code. No URI-only successor or new installed cell is authorized by the existing review. Source counter-review and fresh source-bound physical/synthetic repeats remain required. All prior observations/NONPASS records remain preserved; no local SDK runtime is active.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingkind:cross-repositoryWork spans more than one public repositorykind:defectA public product behavior is incorrectpriority:P2Normal-priority product workrepo:sdk-phpOwned by the PHP SDK repositoryrepo:sdk-pythonOwned by the Python SDK repositoryrepo:sdk-rustOwned by the Rust SDK repositoryrepo:serverOwned by the standalone server repositoryrepo:workflowOwned by the Workflow engine repositorystatus:readyReady for implementation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions