[P1] Add immutable skill lifecycle, promotion, supersession, and rollback #170

New issue

Open

opened 2026-08-22 01:52:34 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

2026-08-22 01:52:34 +00:00

(Migrated from github.com)

Parent: #167
Related: #117, #168, #169, #74-#77

Goal

Add a generic first-class lifecycle for skill candidates and active versions without turning skill files into mutable ambient state.

Target semantics:

draft/candidate
-> validated
-> evaluated
-> active/promoted
-> superseded | rejected | disabled

Requirements

immutable candidate/version identity and content fingerprint;
provenance, origin, parent lineage and creation evidence;
references to selection/outcome evaluation evidence;
deterministic active-version resolution;
explicit trusted promotion/rejection/disable operations;
rollback to a previously evaluated version without deleting history;
supersession preserves ancestry and evaluation records;
no model or skill body can self-promote;
malformed/stale lifecycle state fails structurally;
reuse existing artifact/scoped-state/persistence contracts where they fit instead of creating a second database.

Promotion policy must be separable from candidate content. A candidate may propose text/configuration; trusted runtime policy owns whether that candidate becomes active.

Acceptance

two versions of one logical skill can coexist with distinct immutable identities;
exactly one effective active version resolves deterministically per applicable scope/policy;
promotion references concrete evaluation evidence;
rejection/disable/supersession does not destroy historical evidence;
rollback restores a prior eligible version without mutating its identity;
model-produced candidate data cannot mutate active state directly;
restart/persistence semantics are deterministic where persistence is enabled;
lifecycle events are traceable and suitable for AgentProlog downstream inspection.

Non-goals

no skill-content generation;
no evaluator implementation;
no product-specific skill store/UI;
no capability/authority grants through lifecycle state.

Inspect current main and existing scoped-state/artifact contracts before designing storage. Do as much coherent work as possible per cycle.

Parent: #167 Related: #117, #168, #169, #74-#77 ## Goal Add a generic first-class lifecycle for skill candidates and active versions without turning skill files into mutable ambient state. Target semantics: ```text draft/candidate -> validated -> evaluated -> active/promoted -> superseded | rejected | disabled ``` ## Requirements - immutable candidate/version identity and content fingerprint; - provenance, origin, parent lineage and creation evidence; - references to selection/outcome evaluation evidence; - deterministic active-version resolution; - explicit trusted promotion/rejection/disable operations; - rollback to a previously evaluated version without deleting history; - supersession preserves ancestry and evaluation records; - no model or skill body can self-promote; - malformed/stale lifecycle state fails structurally; - reuse existing artifact/scoped-state/persistence contracts where they fit instead of creating a second database. Promotion policy must be separable from candidate content. A candidate may propose text/configuration; trusted runtime policy owns whether that candidate becomes active. ## Acceptance - [ ] two versions of one logical skill can coexist with distinct immutable identities; - [ ] exactly one effective active version resolves deterministically per applicable scope/policy; - [ ] promotion references concrete evaluation evidence; - [ ] rejection/disable/supersession does not destroy historical evidence; - [ ] rollback restores a prior eligible version without mutating its identity; - [ ] model-produced candidate data cannot mutate active state directly; - [ ] restart/persistence semantics are deterministic where persistence is enabled; - [ ] lifecycle events are traceable and suitable for AgentProlog downstream inspection. ## Non-goals - no skill-content generation; - no evaluator implementation; - no product-specific skill store/UI; - no capability/authority grants through lifecycle state. Inspect current `main` and existing scoped-state/artifact contracts before designing storage. Do as much coherent work as possible per cycle.

lost-rob0t commented

2026-08-22 02:56:04 +00:00

(Migrated from github.com)

RAGE cross-connection from #173: keep lifecycle/version history here, not in the active skill graph. #173's graph should represent the deterministic precedence-resolved active skill view used by rlm_prompt_compiler; declared metadata.version is informational, while immutable identity/fingerprint is host-derived. Shadowed/older/candidate package versions belong to this lifecycle surface so rollback/eval lineage does not force the compiler graph to become a second persistence/version database. No coding in this pass.

RAGE cross-connection from #173: keep lifecycle/version history here, not in the active skill graph. #173's graph should represent the deterministic precedence-resolved active skill view used by `rlm_prompt_compiler`; declared `metadata.version` is informational, while immutable identity/fingerprint is host-derived. Shadowed/older/candidate package versions belong to this lifecycle surface so rollback/eval lineage does not force the compiler graph to become a second persistence/version database. No coding in this pass.