From recipe to verified package#

The lifecycle has three claims. Treating them as one is the main source of incorrect status reports.

Claim 1: resolves#

A package resolves when every requested profile has:

  • a validated canonical manifest and planned SBOM;

  • a jointly feasible Resolvo lock under the selected hierarchy and stack policy;

  • a deterministic EasyBuild recipe generated from that lock.

package plan and package bump can establish this claim. package inspect cannot, because it has no lock or recipe.

Resolution catches missing candidates, incompatible constraints, locked pin violations, known exclusions, hierarchy mistakes, and invalid recipe metadata. It does not download or compile software.

Claim 2: builds#

A package builds when every emitted recipe completes through EasyBuild on the configured target. This exercises source downloads, checksums, patches, configure, compile, link, tests, install, and EasyBuild sanity checks.

Only campaign run can establish this claim. A version range or prior recipe is not build evidence for a new toolchain, platform, runtime, or product profile.

Claim 3: binary-verified#

A package is binary-verified when all verification commands declared by its profiles succeed after the EasyBuild recipes build. These commands can load the module, invoke binaries, inspect versions/features, or perform site-specific RPATH/link checks.

A campaign with no verification commands may establish builds but leaves binary-verified false.

Lifecycle sequence#

  1. Parse the foreign or EasyBuild source into PackagePlan.

  2. Review the planned SBOM and residuals.

  3. Materialize each product profile.

  4. Apply stack preferences/exclusions inside Resolvo and write locks.

  5. Emit one conventional EasyBuild recipe per profile.

  6. Format, lint, and robot-check the recipes.

  7. Resolve target layers and probe them with target doctor.

  8. Run the campaign on the EasyBuild host/runtime.

  9. Claim, repair, and resolve typed findings; rerun the same state.

  10. Hand the recipe set and evidence to the human operator for repository/PR publication.

Repair ownership#

  • Parser/provenance defects belong in syntax adapters.

  • Product choices belong in profile TOML.

  • Distribution/site versions and known bad candidates belong in stack policy.

  • Mechanical version selection belongs in Resolvo.

  • Recipe syntax, checksums, patches, build logic, and sanity paths belong in the generated/authored easyconfig.

  • Host, scheduler, runtime, paths, modules, and environment belong in target configuration.

  • Empirical failures and repair evidence belong in campaign state.

This structure lets Hermes own the build-evaluation loop without turning every failure into unstructured prompt text. OMP workers can coordinate by finding class and ownership while preserving the exact command and evidence.