pub struct DeploymentCapabilities {
pub mail_relay: bool,
pub wallet_link_ceremony: bool,
pub email_magic_link_ceremony: bool,
pub payments_proxy: bool,
pub mandate_issuer: bool,
}Expand description
The deployment-configuration facts Requirements are checked against.
Resolved ONCE at control-plane startup from the same Option/Arc
configuration each ceremony/proxy already builds for its own use (never a
second, independent env read that could drift from what the ceremony
itself decided), mirroring ConfiguredBackends in the harness’s
main.rs: a struct of independent configuration facts, not states of one
state machine — hence the flat bools below rather than a nested
enum/state-machine shape.
Carried across the control-plane/harness wire as
TurnInput.viable_requirements (the Requirement::as_str names this
deployment satisfies) because the facts live in control-plane-only
configuration (mail relay credentials, ceremony URLs, the payments
signer) the harness sandbox cannot read for itself — the harness never
resolves this struct locally; it reconstructs the viable subset with
Self::from_names from the wire strings each turn.
Fields§
§mail_relay: boolRequirement::MailRelay is met.
wallet_link_ceremony: boolRequirement::CeremonyPage is met.
email_magic_link_ceremony: boolRequirement::CeremonyPage is met.
payments_proxy: boolRequirement::PaymentsProxy is met.
mandate_issuer: boolRequirement::MandateIssuer is met.
Implementations§
Source§impl DeploymentCapabilities
impl DeploymentCapabilities
Sourcepub const fn all() -> Self
pub const fn all() -> Self
Every Requirement viable — the standalone/dev/test posture, and
the explicit choice a caller that genuinely does not care about
deployment viability (a test scoping only builtin_allow, the
in-process whole-conversation test transport) reaches for by name
instead of hand-listing every field true. NOT the type’s
Default — Default stays fail-closed (nothing viable), so a
caller that forgets to thread the real wire-resolved value hides
every requirement-gated built-in instead of silently over-advertising
one whose deployment prerequisite is actually unmet.
Sourcepub const fn is_viable(self, requirement: Requirement) -> bool
pub const fn is_viable(self, requirement: Requirement) -> bool
Whether this deployment currently satisfies requirement.
Sourcepub fn all_viable(self, requirements: &[Requirement]) -> bool
pub fn all_viable(self, requirements: &[Requirement]) -> bool
Whether every member of requirements is viable — the join
build_tool_executor folds into granted ∩ owned ∩ viable. An empty
slice (a built-in with no deployment prerequisite) is always viable.
Sourcepub fn viable_names(self) -> Vec<&'static str>
pub fn viable_names(self) -> Vec<&'static str>
The stable kebab-case names of every Requirement this deployment
satisfies, in Requirement::ALL order — what the control plane
puts on the wire. Inverse of Self::from_names.
Sourcepub fn from_names<'a, I: IntoIterator<Item = &'a str>>(names: I) -> Self
pub fn from_names<'a, I: IntoIterator<Item = &'a str>>(names: I) -> Self
Reconstruct from the wire’s stable-name list (TurnInput.viable_requirements)
— the harness’s side of Self::viable_names. An unrecognized name
(a newer control plane’s requirement an older harness doesn’t know)
is silently ignored rather than failing the turn: an unknown
requirement can never be satisfied by an older binary’s is_viable
match anyway, so any built-in that needs it stays hidden either way.
Trait Implementations§
Source§impl Clone for DeploymentCapabilities
impl Clone for DeploymentCapabilities
Source§fn clone(&self) -> DeploymentCapabilities
fn clone(&self) -> DeploymentCapabilities
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more