Skip to main content

preopen_reports

Function preopen_reports 

Source
pub fn preopen_reports<'a, I>(
    artifacts: I,
) -> Result<Vec<PreopenReport>, RuntimeError>
where I: IntoIterator<Item = (&'a str, &'a ArtifactRuntime, Option<&'a Capabilities>)>,
Expand description

The filesystem surface each of the given artifacts will be preopened into, resolved but not opened, one entry per artifact that has a guest.

Lives here, beside the two grant types whose Defaults it reports: [ToolCapabilityGrant] supplies the whole-workdir baseline a tool or driver falls back to, and [HookCapabilityGrant] the deny baseline a hook falls back to. Resolving the same question in a second place is how a report starts disagreeing with a launch.

Takes (artifact name, role, that artifact's operator-declared capabilities) triples rather than a concrete artifact type so the two callers that must agree can both satisfy it: stage_session holds crate::types::ArtifactRequests, and mur run --explain-scope and mur doctor hold murmur_artifact::RuntimeArtifacts and have staged nothing.

murmur_artifact::ArtifactRuntime::Skill produces no entry: a skill is markdown staged into the workdir, no component is instantiated for it, and it holds no descriptor to report.

Every declared scope is read through [declared_filesystem_scope], so a scope a launch would refuse is refused here too. Nothing is created — [resolve_scoped_dir] is the staging path’s job — so this stays usable from a read-only diagnostic.