coulomb/activity-core
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Implement offline recovery handoff within existing scheduling scope
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details
Build and Publish Container Image / build-and-push (push) Successful in 1m19s
Details

Browse source 
Apply the user-directed Emergent Security guidance to close the redundant role gate. Add closed request/receipt validation bound to run, cluster, implementation, mode and authority reference; preserve platform enforcement and operation admission gates.

Decision-Class: task-scoped-code-and-tests

Delegation: explicit-user-task; Emergent-Security-A6

Evidence: 653-tests-passed; 1-skipped; focused-43-passed; ruff-clean

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a100de-2e1c-7e23-9ae9-2da0e0499411
This commit is contained in:
tegwick 2026-10-03 14:32:50 +02:00
parent 5d499622e0
commit 7b38f05eb2
4 changed files with 316 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

41
docs/platform-recovery-scheduling-plan.md
View file

@ -1,17 +1,19 @@
# Platform recovery scheduling — reviewed proposal
# Platform recovery scheduling — scoped delivery plan
Reviewed 2026-10-03 for ACTIVITY-WP-0042. This is a proposed delivery contract,
not admission of a new operation or permission to run it.
Reviewed 2026-10-03 for ACTIVITY-WP-0042. Offline implementation is authorized
within the existing scheduling role by the user's task and explicit Emergent
Security guidance. The runner contract remains a candidate for platform review;
no new operation or live execution is admitted.
## Recommended decision
## Scheduling boundary
Accept **scheduling ownership only** for activity-core: Temporal triggers,
Continue within activity-core's existing **scheduling-only ownership**: Temporal triggers,
bounded dispatch, run correlation, missed-run visibility, and normalized result
evidence. Railiance Platform retains recovery implementations, acceptance
validators, cadence/freshness policy, destinations, retention, and credential
custody. Existing ACT-ADR-007 operations remain unchanged.
Approve offline design and tests of the invocation contract now. Admit each
Proceed with offline design and tests under C4/A2/A6. Admit each
new mutating operation separately after its owner supplies the contract and
ACT-ADR-007 is amended or superseded. No new generic shell executor, restore
schedule, retention action, or production rollout follows from role acceptance.
@ -87,8 +89,9 @@ successful restore.
## Implementation and verification sequence
1. Founder accepts the scheduling-only boundary (T01). This resolves only
ACTIVITY-WP-0042's role choice, not the other decisions bundled in D2.
1. T01 is complete: the explicit user task and Emergent Security guidance
authorize development within the existing scheduling boundary. The other
decisions bundled in D2 remain unchanged.
2. Agree the fixed runner contract above with railiance-platform (T05).
3. Build offline adapter/admission tests within T02. Cover unknown operation,
target drift, absent/expired/wrong-scope authority, duplicate dispatch,
@ -108,3 +111,25 @@ issuance/deployment record identifying the actual execution unit, or a founder
ruling that it is an unused example to retire. Scheduling development does not
need to claim this historical actor. No owner message has been sent by this
review; the contract and identity questions are recorded as workplan tasks.
## Candidate contract implementation
`src/activity_core/recovery_contract.py` provides a pure request parser and
receipt validator; `tests/test_recovery_contract.py` exercises it offline.
It deliberately has no executor, transport, credential access, or registration
in the bounded-operation allowlist. It is not imported by the runtime workflow.
An apply request must name a per-run authority UUID, but UUID presence never
proves permission. The platform enforcement point must verify scope, expiry and
consumption before an effect. The receipt envelope checks only the owner's
assertions and correlation; platform validators remain authoritative for backup
contents and recovery correctness. Digests require verification against the
owner evidence store by the future authenticated transport, not trust by format.
The supplied freshness window must come from accepted owner policy.
A successful apply receipt requires validated recovery and completed cleanup;
a dry-run may only describe a plan without recovery effects. Failed/rejected/
unknown results remain visible for reconciliation and do not trigger retries.
Malformed input errors suppress raw validation values. This contract is an
implementation candidate, not an assertion of platform-owner acceptance.