Skip to content

orchestrator: add Recovery capability trait - #463

Draft
chrysh wants to merge 1 commit into
OpenPRoT:mainfrom
9elements:add-recovery
Draft

chrysh wants to merge 1 commit into
OpenPRoT:mainfrom
9elements:add-recovery

Conversation

@chrysh

@chrysh chrysh commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

The Recovery capability trait: rewrite one managed device's active image from
its board-configured recovery source. This is the seam
Effect::RecoverComponent needs, which currently falls through to
Err(EffectError) in the platform driver.

Ok means the mechanism completed, not that the image is good. Judging the
restored image stays with the verifier on the re-walk, so a restore can never
forge a verdict. Errors are actuation faults only and are treated fail-closed.

restore takes the attempt count straight from the effect, so an implementor
holding several sources can pick a different one each try (slot A on 0, slot B
on 1, golden on 2). A count kept by the device would drift, because it never
sees which attempt succeeded.

Trait only: no driver executor, no BoardCapabilities change, no board wiring.
Those come in a follow-up once the open question below is settled.

Open question, asked in #382: what should the driver do when it runs out of
sources before the core runs out of attempts? This PR says exhausted is an
actuation error, which fail-closes and lets the board's source count silently
set the real retry cap. The alternative is clamping to the last source.

Draft until #382 is answered.

Related: #48.

One managed device's restore mechanism: rewrite the active image from
the board-configured recovery source. Ok means the mechanism completed,
not that the image is good - judging the restored image stays with the
verifier on the re-walk, so a restore can never forge a verdict. Errors
are actuation faults only and are treated fail-closed.

restore takes the attempt count from Effect::RecoverComponent so an
implementor holding several sources can pick a different one each try.
A count kept by the device would drift, because it never sees which
attempt succeeded.

Assisted-by: Claude:claude-fable-5
Signed-off-by: Christina Quast <christina.quast@9elements.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant