Repository navigation
feat: add collaborative Skill evolution - #109
Merged
al2wang merged 9 commits intoOct 12, 2026
Merged
Conversation
al2wang
added this pull request to stack #110
September 29, 2026 04:42
al2wang
force-pushed
the
alex/collaborative-skill-evolution
branch
from
October 1, 2026 01:57
9421016 to
165ef9b
Compare
al2wang
force-pushed
the
alex/collaborative-skill-evolution
branch
from
October 1, 2026 03:21
165ef9b to
3661bd8
Compare
A shared Skill's text is written by one agent and read by another, so it is an attack surface as much as a lesson. The shop had length bounds and a secret screen; collaborative refinement adds a much larger surface, because a challenge, a fork and a comparison all carry prose that other agents will read. The sanitizer is now its own module with an explicit contract: shared text is normalised, then refused when it carries invisible or bidirectional characters, look-alike scripts, letter streams that imitate a different alphabet, references that point outward, or the markers that have always been unsafe. Each rule is versioned, every version is held to a shared floor, and a stored text is re-checked against the current rules before it reaches a prompt, so a text that was acceptable under an older version cannot slip through unexamined. The domain grows the shapes the Forum needs - challenge, fork, lineage and comparison - and keeps judging them by rules both the daemon and the registry share. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
This is the Forum: the part that lets a verified Skill be improved by someone other than its author, without anyone editing anyone else's artifact. A challenge is evidence-backed: it names the skill, the claim and the evidence, and it is refused without them. A fork is immutable - a new candidate whose parent, version, scope and visibility the registry derives - so refining a Skill never mutates the one it came from, and lineage is a fact the registry computes rather than a field a client asserts. A comparative evaluation decides between a parent and its fork on receipts from authorized evaluators, and only that gate may supersede: supersession is never a client's claim. Authority is checked on current standing for every write, and every link a change can affect is re-checked when the deciding authority changes, so a lineage cannot be moved by an evaluator who has since lost standing, and a safety veto cannot be overtaken by a later ordinary receipt. Six migrations, 0005 to 0010, follow the shop's 0004 in this crate's own migrator. The challenge and lineage views are served by the registry itself, escaped and visibility-aware, like the catalog. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
Whether a turn follows a Skill's lineage to the version that currently supersedes it is a deployment decision, not a default. The setting is validated with the rest of the daemon configuration, and the conservative value keeps the old behaviour: the exact skill that was requested, and nothing else. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
A refined Skill is worthless if agents keep retrieving the superseded one. When lineage resolution is enabled, a request for a skill resolves to the version that currently supersedes it, and the turn receives that version once - never the parent and the child together. Every resolution is audited: what was requested, what it resolved to, which version was injected, and why a version was refused. A refused version is recorded as refused rather than silently dropped, so a retrieval decision can be reconstructed afterwards from the event trail alone. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
The guide now covers the second half of the shop: how a challenge must carry evidence, how a fork keeps its parent intact, how a comparative evaluation supersedes a version, how lineage is resolved at retrieval, and what the sanitizer contract refuses in shared text. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
al2wang
force-pushed
the
alex/collaborative-skill-evolution
branch
from
October 1, 2026 19:17
3661bd8 to
825ba43
Compare
Brings #100's review, already merged into the Skill Shop branch, down one level. Two conflicts, both additive: `AppState`'s builder keeps this branch's `with_skill_shop_lineage` beside the review's test-only decision barrier, and the empty-evidence literal the review extended had already been removed here, so this branch's side stands. Two test helpers that still took a bare store now take the test's `AppState`, for the reason recorded upstream: one audit sequencer per store. Gate on the merged tree: `cargo fmt --all -- --check`, `cargo clippy --locked --workspace --all-targets -- -D warnings`, daemon experience (15) and skill (22) suites pass. The same three approval-resume tests fail on this host as on pristine #100, and pass in CI. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
al2wang
added a commit
that referenced
this pull request
Oct 9, 2026
Brings #100's review, already propagated through #101 and #109, down to the demo branch. No conflict: this branch touches no daemon code, and its lock was already consistent once the upstream disambiguation of the two `sha2` versions arrived. Gate on the merged tree: `cargo fmt --all -- --check`, `cargo clippy --locked --workspace --all-targets -- -D warnings`, daemon experience (15) and skill (22) suites pass. The same three approval-resume tests fail on this host as on pristine #100, and pass in CI. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
…n branch Signed-off-by: al2wang <lightever131@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…anch Signed-off-by: al2wang <lightever131@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
al2wang
merged commit Oct 12, 2026
5bca789
into
alex/verified-self-evolving-experience
12 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lets agents challenge, refine, compare, and supersede verified Skills. Stacked on #101
(the verified Skill Shop); parent of #111. S-Code now implements an end-to-end verified
self-evolution stack.
What it adds
verified Skill → challenge / counterexample → fork / refinement → comparative evaluation → supersession
The Forum is a structured discourse layer over immutable Skills, not a chat board. A
challenge is an immutable, evidence-backed claim against an exact Skill version, with
counterexamples. A fork is a refinement that never edits a Skill in place: a new
candidate whose lineage the registry derives and nobody can claim. A fork does not replace
its parent by passing the ordinary gate; it must win a comparative evaluation on matched
held-out tasks judged by the registry, after which the registry records the
supersession, and challenge and lineage views show which version stands. Derived content
stays advisory and untrusted throughout; sanitizer and retrieval protections are unchanged.
Off by default.
Endpoints:
POST /v1/skills/{id}/challenges,POST /v1/skills/{id}/forks,POST /v1/skills/{fork_id}/comparisons, plus challenge and lineage reads; seedocs/guides/skill-shop.md("Forum").This update
Carries the current #101 head (which integrates #100's review). Two additive conflicts
resolved; two test helpers now take the test's
AppStatefor the same one-audit-sequencerreason as upstream. The delta over #101 is the Forum feature and those helper lines only.
Non-goals
No demo (#111); no research routers or allowlists; no change to publication or
verification semantics from #101.
Parent: #101. Child: #111.
🤖 Generated with Claude Code