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

New issue

Closed

opened 2026-09-10 21:18:18 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-09-10 21:18:18 +00:00

Owner

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.

~~nsaspy referenced this issue 2026-09-10 21:20:46 +00:00~~

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

nsaspy commented

2026-09-10 21:21:31 +00:00

Author

Owner

Duplicate of #170 (pre-existing Forgejo mirror). Closing this accidental duplicate created by today's open-state sync; #170 stays canonical on Forgejo.

nsaspy closed this issue

2026-09-10 21:21:31 +00:00