🚀 User / Workload
Queue and agent workers append events to durable workspaces and may restart after an uncertain remote result.
🔎 Current Limitation
A replacement process cannot reliably identify the original append. A single immutable attempt can also remain stranded after a crash; deleting abandoned objects leaves a late-upload window.
💡 Desired Outcome
Persist one business operation ID and full intent across redelivery. Return the original committed receipt, reject intent drift, recover failed attempts safely, and inspect/recover by logical ID without a captured transcript or caller object credentials.
📦 Scope and Non-goals
Native CLI, Python/Rust clients, the metadata publication lifecycle, and failed-object sealing. Existing Workbench schemas remain stable. Cross-host HA, power-loss qualification, long-term capacity and performance SLOs are separate.
🔄 Alternatives Considered
Process-local IDs do not survive replacement. Payload hashes merge distinct events. One ID tied to one failed attempt cannot make progress. Caller-supplied cleanup verdicts require accident-time evidence that ordinary consumers do not retain.
⚖️ Compatibility, Durability, and Security Impact
The proposed RPC and persisted format changes intentionally reject older stores without mutation. No automatic migration or mixed-version writes are claimed. Metadata remains on locked Holt 0.8.6; immutable bodies remain in the object provider.
🛠 Possible Implementation (Optional)
A logical append parent with fenced publication attempts, atomic durable receipts, permanent failed-key seals, public inspection and token-bound owner cleanup retries.
🧐 Additional Context
Local exact-head acceptance at 13590c1 passed 21 core and 4 operations scenarios; these are local evidence, not yet remote CI. The real demo reproduced 13→26 bytes on the legacy path and 13→13 bytes after process death/redelivery on the stable path.
🚀 User / Workload
Queue and agent workers append events to durable workspaces and may restart after an uncertain remote result.
🔎 Current Limitation
A replacement process cannot reliably identify the original append. A single immutable attempt can also remain stranded after a crash; deleting abandoned objects leaves a late-upload window.
💡 Desired Outcome
Persist one business operation ID and full intent across redelivery. Return the original committed receipt, reject intent drift, recover failed attempts safely, and inspect/recover by logical ID without a captured transcript or caller object credentials.
📦 Scope and Non-goals
Native CLI, Python/Rust clients, the metadata publication lifecycle, and failed-object sealing. Existing Workbench schemas remain stable. Cross-host HA, power-loss qualification, long-term capacity and performance SLOs are separate.
🔄 Alternatives Considered
Process-local IDs do not survive replacement. Payload hashes merge distinct events. One ID tied to one failed attempt cannot make progress. Caller-supplied cleanup verdicts require accident-time evidence that ordinary consumers do not retain.
⚖️ Compatibility, Durability, and Security Impact
The proposed RPC and persisted format changes intentionally reject older stores without mutation. No automatic migration or mixed-version writes are claimed. Metadata remains on locked Holt 0.8.6; immutable bodies remain in the object provider.
🛠 Possible Implementation (Optional)
A logical append parent with fenced publication attempts, atomic durable receipts, permanent failed-key seals, public inspection and token-bound owner cleanup retries.
🧐 Additional Context
Local exact-head acceptance at 13590c1 passed 21 core and 4 operations scenarios; these are local evidence, not yet remote CI. The real demo reproduced 13→26 bytes on the legacy path and 13→13 bytes after process death/redelivery on the stable path.