Repository navigation
[ID01 F44] Add a governed generic activation path for qualified first-party microVM candidates #19
Description
Problem
First-party microVM candidate qualification deliberately produces host/runtime evidence with eligibleForPromotion=false. There is currently no maintained, generic authority that can activate a qualified candidate as a catalogue runtime.
The existing local-developer source-and-target pin update is a reviewed code change for a specific baseline. It does not provide a reusable activation mechanism for future qualified candidates.
Impact
Maintainers cannot promote a qualified candidate through a uniform, auditable route. Each successor requires a bespoke code change, making rollback and approval invalidation difficult to reason about across physical images.
Acceptance criteria
- Define a versioned activation authority that selects only an exact qualified candidate identity.
- Make catalogue revision, acquisition source, runtime profile fingerprints, and pending-approval invalidation atomic.
- Record predecessor-linked, forward-only rollback with crash recovery and cache-coherence checks.
- Preserve fail-closed refusal for unqualified, mismatched, or stale candidates.
- Keep candidate qualification as host/runtime evidence until activation is explicitly approved.
- Cover selected-entry drift, interrupted activation, rollback, stale approval, and cache mismatch with focused tests.
Out of scope
This issue does not request a project run, a provider change, an automatic promotion, or a change to engineering verdict semantics.
Fact-check scope
ID01 F44; reviewed on 2026-09-09. Source inspection, focused tests where relevant, and recorded evidence establish only the scope stated here.
Source pointers (local checkout; the public mirror may lag):
src/adapters/control-plane/first-party-microsandbox-image-candidate-qualification.ts:280-291, 420-440docs/reference/runtime/capability-packs/first-party-microvm-distribution.md:39-57, 66-79
Activity
superWorldSavior commentedon Sep 25, 2026
Analyse de cadrage (pas d'implémentation — décision mainteneur requise, voir fin).
État vérifié : aucune autorité d'activation n'existe. La chaîne s'arrête à
candidate-qualification/1.0(eligibleForPromotion=false,host-runtime-only, pas de L3/L4/L5). Le catalogue est purement code-owned (createFirstPartyCapabilityRuntimeCatalog+createFirstPartyMicrosandboxImageBootstrapDescriptors, pinstarget.manifestDigest+sourceen dur) : aucun overlay local n'est lu par le serveur. Il n'y a donc aujourd'hui aucun consommateur pour un état d'activation.Design proposé (pattern import/qualify : file authority + CLI plan/--run/--recover + how-to mainteneur) :
first-party-microsandbox-image-candidate-activation/1.0: identité exacte du candidat qualifié (physicalImageId + fingerprint import-record + fingerprint qualification + 3 digests OCI/msb), fingerprint du catalogue code auquel il s'applique, source d'acquisition post-activation, fingerprints des profils runtime, fingerprint d'activation prédécesseur (chaîne forward-only), approbation mainteneur explicite.unit.manifestFingerprint— le record d'activation nomme le catalogue remplacé pour que tout lecteur sur un fingerprint antérieur échoue fermé.Décisions mainteneur bloquantes :
local-capability-runtime-read-composition+ cache-preparation-registry) ? Sans consommateur, l'autorité écrit dans le vide ; avec, c'est un changement de composition runtime live pour tous les projets — décision conséquente, pas une implémentation agent autonome.Recommandation : garder OPEN ; trancher 1–2 (MRTR mainteneur) avant tout code. L'implémentation estimée ensuite : record + store + CLI + overlay + docs + tests ciblés (drift, interruption, rollback, stale, cache-mismatch).