feat(deletion): execute graceful and forced lock deletion

[dzdidi]

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

1. publishes and verifies the public tombstone;
2. starts and drains frozen payment obligations;
3. drains existing credentials;
4. issues final credentials;
5. drains final reads;
6. verifies and removes frozen guarded content;
7. verifies the retained tombstone;
8. stops before the separately deferred operational-state purge.

The change also:

• adds exact external-action ownership;
• uses storage-authoritative time after the relevant fence;
• executes public-first active-force deletion;
• persists permanent force receipts;
• adds operation-specific dependency readiness;
• supervises deletion and verification workers;
• adds bounded shutdown and worker-failure handling;
• covers PostgreSQL crash/reclaim boundaries;
• removes duplicate executor and test-fixture paths;
• migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Migration:

• 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

• graceful deletion now executes through its durable phase machine;
• force=true executes or escalates active-force deletion;
• destructive external actions require exact live-claim ownership;
• dependency readiness recovers only from operation-specific healthy evidence;
• Compose secrets schema v2 persists locksRuntimeMasterKey;
• schema v1 local-demo state fails closed and requires the documented destructive reset;
• PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

• cargo fmt --all -- --check — passed
• cargo test --workspace --all-targets --all-features — passed
• cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
• npm --prefix examples/js-sdk run check — passed
• npm --prefix examples/js-sdk run smoke:paykit-compose — passed
• npm --prefix locks-sdk/bindings/js test — passed
• bash scripts/test-compose-bootstrap.sh — passed
• git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

• locks-service library: 355 passed
• deletion integration: 29 passed
• tombstone integration: 6 passed
• PostgreSQL E2E: 12 passed
• JS/WASM generated-package and example smoke checks: passed
• Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

• Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
• Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
• Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
• Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

• Bitkit and Compose integration;
• semantic safety of the code reduction;
• stack topology and preservation.

Documentation

Updated:

• docs/API.md
• docs/RUNTIME.md
• docs/plans/2026-08-10-graceful-content-lock-deletion.md
• examples/js-sdk/README.md

The documentation covers:

• graceful and active-force behavior;
• public failure and lifecycle projection;
• the accepted Pubky GET-to-PUT overwrite race;
• worker readiness and supervision;
• Compose runtime-master-key schema v2;
• fail-closed handling and destructive reset requirements for schema v1.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.

[dzdidi]

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

1. publishes and verifies the public tombstone;
2. starts and drains frozen payment obligations;
3. drains existing credentials;
4. issues final credentials;
5. drains final reads;
6. verifies and removes frozen guarded content;
7. verifies the retained tombstone;
8. stops before the separately deferred operational-state purge.

The change also:

• adds exact external-action ownership;
• uses storage-authoritative time after the relevant fence;
• executes public-first active-force deletion;
• persists permanent force receipts;
• adds operation-specific dependency readiness;
• supervises deletion and verification workers;
• adds bounded shutdown and worker-failure handling;
• covers PostgreSQL crash/reclaim boundaries;
• removes duplicate executor and test-fixture paths;
• migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Migration:

• 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

• graceful deletion now executes through its durable phase machine;
• force=true executes or escalates active-force deletion;
• destructive external actions require exact live-claim ownership;
• dependency readiness recovers only from operation-specific healthy evidence;
• Compose secrets schema v2 persists locksRuntimeMasterKey;
• schema v1 local-demo state fails closed and requires the documented destructive reset;
• PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

• cargo fmt --all -- --check — passed
• cargo test --workspace --all-targets --all-features — passed
• cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
• npm --prefix examples/js-sdk run check — passed
• npm --prefix examples/js-sdk run smoke:paykit-compose — passed
• npm --prefix locks-sdk/bindings/js test — passed
• bash scripts/test-compose-bootstrap.sh — passed
• git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

• locks-service library: 355 passed
• deletion integration: 29 passed
• tombstone integration: 6 passed
• PostgreSQL E2E: 12 passed
• JS/WASM generated-package and example smoke checks: passed
• Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

• Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
• Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
• Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
• Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

• Bitkit and Compose integration;
• semantic safety of the code reduction;
• stack topology and preservation.

Documentation

Updated:

• docs/API.md
• docs/RUNTIME.md
• docs/plans/2026-08-10-graceful-content-lock-deletion.md
• examples/js-sdk/README.md

The documentation covers:

• graceful and active-force behavior;
• public failure and lifecycle projection;
• the accepted Pubky GET-to-PUT overwrite race;
• worker readiness and supervision;
• Compose runtime-master-key schema v2;
• fail-closed handling and destructive reset requirements for schema v1.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.

[dzdidi]

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

1. publishes and verifies the public tombstone;
2. starts and drains frozen payment obligations;
3. drains existing credentials;
4. issues final credentials;
5. drains final reads;
6. verifies and removes frozen guarded content;
7. verifies the retained tombstone;
8. stops before the separately deferred operational-state purge.

The change also:

• adds exact external-action ownership;
• uses storage-authoritative time after the relevant fence;
• executes public-first active-force deletion;
• persists permanent force receipts;
• adds operation-specific dependency readiness;
• supervises deletion and verification workers;
• adds bounded shutdown and worker-failure handling;
• covers PostgreSQL crash/reclaim boundaries;
• removes duplicate executor and test-fixture paths;
• migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Migration:

• 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

• graceful deletion now executes through its durable phase machine;
• force=true executes or escalates active-force deletion;
• destructive external actions require exact live-claim ownership;
• dependency readiness recovers only from operation-specific healthy evidence;
• Compose secrets schema v2 persists locksRuntimeMasterKey;
• schema v1 local-demo state fails closed and requires the documented destructive reset;
• PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

• cargo fmt --all -- --check — passed
• cargo test --workspace --all-targets --all-features — passed
• cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
• npm --prefix examples/js-sdk run check — passed
• npm --prefix examples/js-sdk run smoke:paykit-compose — passed
• npm --prefix locks-sdk/bindings/js test — passed
• bash scripts/test-compose-bootstrap.sh — passed
• git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

• locks-service library: 355 passed
• deletion integration: 29 passed
• tombstone integration: 6 passed
• PostgreSQL E2E: 12 passed
• JS/WASM generated-package and example smoke checks: passed
• Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

• Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
• Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
• Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
• Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

• Bitkit and Compose integration;
• semantic safety of the code reduction;
• stack topology and preservation.

Documentation

Updated:

• docs/API.md
• docs/RUNTIME.md
• docs/plans/2026-08-10-graceful-content-lock-deletion.md
• examples/js-sdk/README.md

The documentation covers:

• graceful and active-force behavior;
• public failure and lifecycle projection;
• the accepted Pubky GET-to-PUT overwrite race;
• worker readiness and supervision;
• Compose runtime-master-key schema v2;
• fail-closed handling and destructive reset requirements for schema v1.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.

[dzdidi]

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

1. publishes and verifies the public tombstone;
2. starts and drains frozen payment obligations;
3. drains existing credentials;
4. issues final credentials;
5. drains final reads;
6. verifies and removes frozen guarded content;
7. verifies the retained tombstone;
8. stops before the separately deferred operational-state purge.

The change also:

• adds exact external-action ownership;
• uses storage-authoritative time after the relevant fence;
• executes public-first active-force deletion;
• persists permanent force receipts;
• adds operation-specific dependency readiness;
• supervises deletion and verification workers;
• adds bounded shutdown and worker-failure handling;
• covers PostgreSQL crash/reclaim boundaries;
• removes duplicate executor and test-fixture paths;
• migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Migration:

• 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

• graceful deletion now executes through its durable phase machine;
• force=true executes or escalates active-force deletion;
• destructive external actions require exact live-claim ownership;
• dependency readiness recovers only from operation-specific healthy evidence;
• Compose secrets schema v2 persists locksRuntimeMasterKey;
• schema v1 local-demo state fails closed and requires the documented destructive reset;
• PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

• cargo fmt --all -- --check — passed
• cargo test --workspace --all-targets --all-features — passed
• cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
• npm --prefix examples/js-sdk run check — passed
• npm --prefix examples/js-sdk run smoke:paykit-compose — passed
• npm --prefix locks-sdk/bindings/js test — passed
• bash scripts/test-compose-bootstrap.sh — passed
• git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

• locks-service library: 355 passed
• deletion integration: 29 passed
• tombstone integration: 6 passed
• PostgreSQL E2E: 12 passed
• JS/WASM generated-package and example smoke checks: passed
• Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

• Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
• Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
• Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
• Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

• Bitkit and Compose integration;
• semantic safety of the code reduction;
• stack topology and preservation.

Documentation

Updated:

• docs/API.md
• docs/RUNTIME.md
• docs/plans/2026-08-10-graceful-content-lock-deletion.md
• examples/js-sdk/README.md

The documentation covers:

• graceful and active-force behavior;
• public failure and lifecycle projection;
• the accepted Pubky GET-to-PUT overwrite race;
• worker readiness and supervision;
• Compose runtime-master-key schema v2;
• fail-closed handling and destructive reset requirements for schema v1.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.

[dzdidi]

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

1. publishes and verifies the public tombstone;
2. starts and drains frozen payment obligations;
3. drains existing credentials;
4. issues final credentials;
5. drains final reads;
6. verifies and removes frozen guarded content;
7. verifies the retained tombstone;
8. stops before the separately deferred operational-state purge.

The change also:

• adds exact external-action ownership;
• uses storage-authoritative time after the relevant fence;
• executes public-first active-force deletion;
• persists permanent force receipts;
• adds operation-specific dependency readiness;
• supervises deletion and verification workers;
• adds bounded shutdown and worker-failure handling;
• covers PostgreSQL crash/reclaim boundaries;
• removes duplicate executor and test-fixture paths;
• migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Migration:

• 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

• graceful deletion now executes through its durable phase machine;
• force=true executes or escalates active-force deletion;
• destructive external actions require exact live-claim ownership;
• dependency readiness recovers only from operation-specific healthy evidence;
• Compose secrets schema v2 persists locksRuntimeMasterKey;
• schema v1 local-demo state fails closed and requires the documented destructive reset;
• PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

• cargo fmt --all -- --check — passed
• cargo test --workspace --all-targets --all-features — passed
• cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
• npm --prefix examples/js-sdk run check — passed
• npm --prefix examples/js-sdk run smoke:paykit-compose — passed
• npm --prefix locks-sdk/bindings/js test — passed
• bash scripts/test-compose-bootstrap.sh — passed
• git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

• locks-service library: 355 passed
• deletion integration: 29 passed
• tombstone integration: 6 passed
• PostgreSQL E2E: 12 passed
• JS/WASM generated-package and example smoke checks: passed
• Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

• Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
• Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
• Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
• Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

• Bitkit and Compose integration;
• semantic safety of the code reduction;
• stack topology and preservation.

Documentation

Updated:

• docs/API.md
• docs/RUNTIME.md
• docs/plans/2026-08-10-graceful-content-lock-deletion.md
• examples/js-sdk/README.md

The documentation covers:

• graceful and active-force behavior;
• public failure and lifecycle projection;
• the accepted Pubky GET-to-PUT overwrite race;
• worker readiness and supervision;
• Compose runtime-master-key schema v2;
• fail-closed handling and destructive reset requirements for schema v1.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.

[dzdidi]

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

1. publishes and verifies the public tombstone;
2. starts and drains frozen payment obligations;
3. drains existing credentials;
4. issues final credentials;
5. drains final reads;
6. verifies and removes frozen guarded content;
7. verifies the retained tombstone;
8. stops before the separately deferred operational-state purge.

The change also:

• adds exact external-action ownership;
• uses storage-authoritative time after the relevant fence;
• executes public-first active-force deletion;
• persists permanent force receipts;
• adds operation-specific dependency readiness;
• supervises deletion and verification workers;
• adds bounded shutdown and worker-failure handling;
• covers PostgreSQL crash/reclaim boundaries;
• removes duplicate executor and test-fixture paths;
• migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Migration:

• 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

• graceful deletion now executes through its durable phase machine;
• force=true executes or escalates active-force deletion;
• destructive external actions require exact live-claim ownership;
• dependency readiness recovers only from operation-specific healthy evidence;
• Compose secrets schema v2 persists locksRuntimeMasterKey;
• schema v1 local-demo state fails closed and requires the documented destructive reset;
• PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

• cargo fmt --all -- --check — passed
• cargo test --workspace --all-targets --all-features — passed
• cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
• npm --prefix examples/js-sdk run check — passed
• npm --prefix examples/js-sdk run smoke:paykit-compose — passed
• npm --prefix locks-sdk/bindings/js test — passed
• bash scripts/test-compose-bootstrap.sh — passed
• git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

• locks-service library: 355 passed
• deletion integration: 29 passed
• tombstone integration: 6 passed
• PostgreSQL E2E: 12 passed
• JS/WASM generated-package and example smoke checks: passed
• Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

• Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
• Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
• Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
• Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

• Bitkit and Compose integration;
• semantic safety of the code reduction;
• stack topology and preservation.

Documentation

Updated:

• docs/API.md
• docs/RUNTIME.md
• docs/plans/2026-08-10-graceful-content-lock-deletion.md
• examples/js-sdk/README.md

The documentation covers:

• graceful and active-force behavior;
• public failure and lifecycle projection;
• the accepted Pubky GET-to-PUT overwrite race;
• worker readiness and supervision;
• Compose runtime-master-key schema v2;
• fail-closed handling and destructive reset requirements for schema v1.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.

[dzdidi]

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

1. publishes and verifies the public tombstone;
2. starts and drains frozen payment obligations;
3. drains existing credentials;
4. issues final credentials;
5. drains final reads;
6. verifies and removes frozen guarded content;
7. verifies the retained tombstone;
8. stops before the separately deferred operational-state purge.

The change also:

• adds exact external-action ownership;
• uses storage-authoritative time after the relevant fence;
• executes public-first active-force deletion;
• persists permanent force receipts;
• adds operation-specific dependency readiness;
• supervises deletion and verification workers;
• adds bounded shutdown and worker-failure handling;
• covers PostgreSQL crash/reclaim boundaries;
• removes duplicate executor and test-fixture paths;
• migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Migration:

• 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

• graceful deletion now executes through its durable phase machine;
• force=true executes or escalates active-force deletion;
• destructive external actions require exact live-claim ownership;
• dependency readiness recovers only from operation-specific healthy evidence;
• Compose secrets schema v2 persists locksRuntimeMasterKey;
• schema v1 local-demo state fails closed and requires the documented destructive reset;
• PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

• cargo fmt --all -- --check — passed
• cargo test --workspace --all-targets --all-features — passed
• cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
• npm --prefix examples/js-sdk run check — passed
• npm --prefix examples/js-sdk run smoke:paykit-compose — passed
• npm --prefix locks-sdk/bindings/js test — passed
• bash scripts/test-compose-bootstrap.sh — passed
• git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

• locks-service library: 355 passed
• deletion integration: 29 passed
• tombstone integration: 6 passed
• PostgreSQL E2E: 12 passed
• JS/WASM generated-package and example smoke checks: passed
• Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

• Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
• Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
• Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
• Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

• Bitkit and Compose integration;
• semantic safety of the code reduction;
• stack topology and preservation.

Documentation

Updated:

• docs/API.md
• docs/RUNTIME.md
• docs/plans/2026-08-10-graceful-content-lock-deletion.md
• examples/js-sdk/README.md

The documentation covers:

• graceful and active-force behavior;
• public failure and lifecycle projection;
• the accepted Pubky GET-to-PUT overwrite race;
• worker readiness and supervision;
• Compose runtime-master-key schema v2;
• fail-closed handling and destructive reset requirements for schema v1.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.

[dzdidi]

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

1. publishes and verifies the public tombstone;
2. starts and drains frozen payment obligations;
3. drains existing credentials;
4. issues final credentials;
5. drains final reads;
6. verifies and removes frozen guarded content;
7. verifies the retained tombstone;
8. stops before the separately deferred operational-state purge.

The change also:

• adds exact external-action ownership;
• uses storage-authoritative time after the relevant fence;
• executes public-first active-force deletion;
• persists permanent force receipts;
• adds operation-specific dependency readiness;
• supervises deletion and verification workers;
• adds bounded shutdown and worker-failure handling;
• covers PostgreSQL crash/reclaim boundaries;
• removes duplicate executor and test-fixture paths;
• migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Migration:

• 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

• graceful deletion now executes through its durable phase machine;
• force=true executes or escalates active-force deletion;
• destructive external actions require exact live-claim ownership;
• dependency readiness recovers only from operation-specific healthy evidence;
• Compose secrets schema v2 persists locksRuntimeMasterKey;
• schema v1 local-demo state fails closed and requires the documented destructive reset;
• PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

• cargo fmt --all -- --check — passed
• cargo test --workspace --all-targets --all-features — passed
• cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
• npm --prefix examples/js-sdk run check — passed
• npm --prefix examples/js-sdk run smoke:paykit-compose — passed
• npm --prefix locks-sdk/bindings/js test — passed
• bash scripts/test-compose-bootstrap.sh — passed
• git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

• locks-service library: 355 passed
• deletion integration: 29 passed
• tombstone integration: 6 passed
• PostgreSQL E2E: 12 passed
• JS/WASM generated-package and example smoke checks: passed
• Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

• Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
• Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
• Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
• Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

• Bitkit and Compose integration;
• semantic safety of the code reduction;
• stack topology and preservation.

Documentation

Updated:

• docs/API.md
• docs/RUNTIME.md
• docs/plans/2026-08-10-graceful-content-lock-deletion.md
• examples/js-sdk/README.md

The documentation covers:

• graceful and active-force behavior;
• public failure and lifecycle projection;
• the accepted Pubky GET-to-PUT overwrite race;
• worker readiness and supervision;
• Compose runtime-master-key schema v2;
• fail-closed handling and destructive reset requirements for schema v1.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.