v0.6.1 release notes
Reference from a reviewed Memory source revision.
v0.6.1 repairs the existing-store Steward upgrade regression in issue #5 and inconsistent receipt processing status after governance cancels dependent work. It preserves the versioned public APIs and schema ledger version 2.
Steward upgrade and recovery
Section titled “Steward upgrade and recovery”v0.5.2 and v0.6.0 accidentally published different policy content under
memory-default@1. v0.6.1 assigns the v0.6.0 policy to memory-default@2.
PutStewardProfile continues to reject different content at an existing key.
No historical profile is rewritten. No task or receipt is dropped.
After opening the store with v0.6.1, hosts use their normal
PutStewardProfile(BuiltInProfile()) then BindStewardProfile sequence. Existing
jobs retain their captured version-1 policy; new jobs use version 2. Repeating
registration or restarting is idempotent. Hosts must not hard-code version 1,
assign their own version to the built-in policy, swallow arbitrary conflicts,
or delete a database to recover. Custom profiles are unchanged.
A store already migrated to schema 2 cannot be rolled back by replacing the binary with v0.5.2. Preserve a verified pre-upgrade backup and follow the migration procedure.
Governance processing consistency
Section titled “Governance processing consistency”Deleting or correcting evidence can cancel active jobs that read its derived records. The cancellation now updates each affected receipt’s mutable processing state in the same transaction. ReceiptStatus, duplicate Remember, and duplicate SubmitEvidence agree that this work failed. Finished jobs and unrelated work are preserved; cancelled leases cannot apply a late proposal.
On first Open, a transactional data migration repairs historical accepted or
processing receipt rows only when a failed job, known governance failure code,
and persisted same-partition forgetting barrier/read-set dependency establish
the cause. It records data_migration:governance_receipt_processing:v0.6.1 in
metadata atomically; an interrupted repair retries on Open. Receipt evidence,
profiles, job state, Space/LabelSet authority, and schema version are unchanged.
Do not resume writes with v0.6.0 after repair; that binary still contains the bug.
Release evidence and limits
Section titled “Release evidence and limits”The validation record describes source provenance and executed gates. Frozen databases generated by v0.5.2 and v0.6.0 exercise real upgrades through the public Runtime and Runner. A second v0.6.0 fixture exercises correction/deletion status repair. Windows native regression now includes these cases; Linux and Darwin full suites include them as well.
make facts-consumer-gate tests an isolated external module, including both
released-store upgrades. After publication, verify the public module with:
GOWORK=off GOPROXY=https://proxy.golang.org \ go run ./scripts/facts_consumer_gate -version v0.6.1The published-version mode has no local replace or go.work dependency.
This patch does not claim new 100k hot-partition performance results, production model quality, or completion of Caelis Facts product integration. Those remain separate work in the v0.6.0 quality review. Memory continues to publish a Go source module, with no standalone binaries.