Repository navigation
Conversation
sl-7qx
reviewed
Sep 22, 2026
sl-7qx
left a comment
sl-7qx
left a comment
Collaborator
There was a problem hiding this comment.
I found one verification issue specific to this PR. The existing Skill Shop and registry tests passed, but an added test showed that one developer can fabricate independent evaluation receipts. The separate Experience findings are on #100.
al2wang
force-pushed
the
alex/online-verified-skill-shop
branch
from
September 24, 2026 06:42
17cef7d to
a5a6eed
Compare
Collaborator
Author
|
Addressed the review finding in |
al2wang
added this pull request to stack #110
September 29, 2026 04:42
al2wang
force-pushed
the
alex/online-verified-skill-shop
branch
2 times, most recently
from
October 1, 2026 03:21
8d84469 to
7f9b812
Compare
A verified Experience is private to the actor that learned it. Sharing one safely needs a domain of its own: what a shared skill is, what may be said in it, who may evaluate it, and what an evaluation has to prove. This crate holds that domain, with no storage and no transport. A skill carries a lesson and an applicability bounded in length and screened for secrets, repository-specific references and unsafe advice; a sanitization version records which contract produced it. Evaluation evidence is described here too - tasks, arms, evaluator identity, the poisoning probe and the gate that turns raw counts into a verdict - so the daemon and the registry judge by the same rules rather than each inventing their own. The registry client lives here as well, and refuses redirects: a shared skill is fetched from the host that was named, or not at all. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
Shared skills need the same durability guarantees as experiences. A skill row is sealed at publication: its content digest is computed once and never rewritten, so an evaluation always refers to the artifact that was evaluated. Evaluations are immutable rows bound to the skill and the evaluator that produced them, with the origin recorded so an imported receipt can never be mistaken for a local one. Status is not stored as an opinion. It is recomputed from the receipts this shop holds, which is what makes importing a skill from another shop safe: the importing daemon recomputes the status from the evidence it can see rather than trusting what it was sent. Two migrations follow PR1's experience migrations, 0053 and 0054. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
The registry is the only place several agents meet. It is a service of its own, with its own migrator starting at 0001, and it authenticates every request: tokens are random, prefixed and stored only as hashes, and a publication never trusts the identity in its own body. Evaluation effects are authorized against current standing, not against the moment a receipt was written: an evaluator whose authority is withdrawn cannot promote anything afterwards, and a community receipt is never promoted by a later grant. Receipts are immutable and independent; a skill verifies once, under concurrency, from receipts by distinct authorized evaluators. Safety deprecation is terminal: ordinary receipts that arrive later cannot undo it. The catalog is served by the registry itself, escaped and visibility aware: candidates and team skills stay invisible to outsiders. Browser sessions are opaque server-side records, so a bearer token never reaches a cookie jar. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
Retrieval of shared skills is off unless a deployment asks for it, the skills a turn may receive are named explicitly, and the remote registry is configured by URL and credential handle rather than by an inline secret. Every value is validated at load time with the rest of the daemon configuration. 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 daemon half of the shop. An approved Experience can be published as a shared skill candidate: the lesson is sanitized and bounded before it leaves the actor that learned it, and the candidate is visible to the team, never retrieved, until evidence promotes it. Evaluation receipts are recorded and verification is recomputed from them, locally or against the online registry when one is configured. Retrieval is deliberately narrow: only verified skills, only of the turn's own organization and team, only when the shop is enabled, and only the skill ids the turn explicitly asked for. A retrieved skill enters the context as an advisory, derived-untrusted item of its own kind, alongside experiences and never above the user, the system rules or policy, and every retrieval is audited. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
The guide covers the whole path an agent's lesson takes to another agent: sanitized publication, the registry's authentication and visibility rules, independent receipts, the deterministic verification gate, retrieval by a fresh agent, and how safety deprecation ends a skill's life. The testing notes record what the shop's regression tests establish. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
The verified-experience review established that a file-protection change is a context reset: content persisted before it must not cross the model or network boundary again merely because a row still holds it. The shop had two paths where it could. Retrieval now applies the same boundary. A skill this daemon published is judged by its own `created_at`, which is written locally when the skill is created; a skill imported from another shop carries the publishing shop's timestamps, so it has no acquisition time this daemon can trust, and an artifact fetched from a remote registry has no local record at all. Both are refused while a reset stands, before the registry is contacted, and the refusal is audited through the existing refusal event rather than being dropped silently. A skill acquired after the reset retrieves exactly as before, and visibility, scope, status and mode semantics are unchanged. Publication is the same kind of egress. An approved Experience recorded at or before the reset is refused before its lesson is sanitized, stored as a skill or sent to a registry, and the refusal leaves the Experience's own lifecycle untouched. No remote timestamp is trusted anywhere in this change, and no parallel privacy model was introduced. AI-assisted drafting was used; the resulting changes were reviewed and verified by the author. Signed-off-by: al2wang <lightever131@gmail.com>
The deterministic gate verifies a candidate once two independent evaluators have each filed a complete, clean receipt. The local shop treated every stored receipt as authoritative because the shop is team-scoped. That holds for a receipt an evaluator filed itself, but not for one copied in: importing takes each receipt's evaluator identity from the importer's own body, so a single authenticated importer could carry in two receipts naming two other actors and promote its candidate to verified alone. Authority now follows the identity this daemon authenticated for the receipt. A direct receipt is authoritative, and its evaluator is the actor the grant names. An imported receipt stays as immutable provenance and counts for nothing: it cannot reach the independent-evaluator floor, cannot verify a candidate, cannot deprecate one through the safety veto, and a later direct receipt never makes it authoritative after the fact. An evaluator has to file with the shop that counts it, which is what the registry already required and what the documented trust model already promised. The regressions cover the reported attack and its neighbours: an importer fabricating two evaluators, a publisher fabricating external ones, one authenticated actor filing under another's name or twice under its own, imported receipts left out of both verification and the veto while an authenticated safety failure still deprecates, an imported receipt that stays provenance once its evaluator files directly, and a revoked grant that can no longer file at all. Two real authenticated evaluators still verify. 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/online-verified-skill-shop
branch
from
October 1, 2026 19:16
7f9b812 to
83a673b
Compare
The Skill Shop branch was based on #100 before its review. Twenty-two review commits moved underneath it, and this merge brings them in. Conflicts, resolved: * `AppState`'s builder: the shop's `with_skill_shop` and `with_skill_shop_registry` and the review's test-only `experience_decision_barrier` are independent additions; both kept. * `maybe_resume_turn`: the shop carried an older variant of the approval-resume observation. The reviewed one supersedes it -- it classifies the approved call's execution before anything is externalised, guards the checkpoint's tool call id, takes the approved arguments from the checkpoint rather than from the message history, and carries transient tool media -- so the function is now byte-identical to #100's, and the shop's orphaned `checkpointed_tool_call_arguments` helper is gone. `skills.rs`, ported to the reviewed APIs: * publishing cites the evaluation the approval was bound to (`approval_evaluation_id`), falling back to the newest eligible one for a record approved before bindings existed, and refuses when neither is eligible; * `ExperienceEvidence` gained a privacy boundary; * the test helpers write evaluations and decisions through the audit path, as production does, and share the test's own `AppState` so one sequencer owns the chain -- two states seeded at zero on one store collided on `audit_events.sequence`. `Cargo.lock` is refreshed minimally: the workspace now carries two `sha2` versions and two entries needed the version to disambiguate, which is what `cargo ... --locked` had been failing on in CI. Gate on the merged tree: `cargo fmt --all -- --check`, `cargo clippy --locked --workspace --all-targets -- -D warnings`, and the daemon's experience (15) and skill (19) suites pass. Three approval-resume tests fail here exactly as they do on pristine #100 on this host -- they need a sandbox-capable runner, and #100's CI passes them. 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>
Signed-off-by: al2wang <lightever131@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…esume contract tests) into the Skill Shop branch 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
10 of 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.
Turns approved local Experience into independently verified shared Skills. Stacked on
#100 (the verified local learning loop); parent of #109. S-Code now implements an
end-to-end verified self-evolution stack.
What it adds
approved Experience → sanitized Skill candidate → independent evaluation receipts → verified Skill → fresh-agent reuse
An approved Experience can be published to a Skill Shop as a sanitized candidate that
carries the lesson, its applicability and provenance — no evidence, workspace key, session
or turn id, or machine path. Independent evaluators file immutable receipts under their
authenticated identity; imported receipts are provenance and count for nothing. A
deterministic gate over the receipts on record promotes the candidate to verified
inside the transaction that records the last receipt. A fresh agent in another scope may
then be sent that Skill, still as advisory derived-untrusted context; every retrieval and
refusal is an audit event. Verified means the gate passed, not that the Skill is
universally beneficial. Off by default.
Kept from the design: authenticated receipt authority; imported receipts non-authoritative;
the bounded sanitizer contract; independent verification; safety deprecation (never
injectable); team/organization visibility and scope-bound retrieval; privacy-reset
behaviour; fail-closed remote transport; web catalog and session protections.
This update
Integrates the current #100 head (
5ec1b02) with its reviewed approval-resumeimplementation kept as reviewed (approved call observed once from checkpointed arguments;
denial is not a verifier failure; the wrong pending call cannot resume the checkpoint);
this layer's older implementation of the same path was removed. Skill publication cites
the approval-bound evaluation; tests write through the real audit path with one
AppStateper store. The stale
Cargo.lockthat reddened CI is fixed once (twosha2versionsdisambiguated).
Storage
crates/storage/migrations: 0055_shared_skills, 0056_skill_evaluations (on top of#100's 0053/0054/0057).
crates/skill-registry/migrations: 0001–0004, an independentnamespace.
Configuration
Non-goals
No challenges, forks, comparisons or supersession (#109); no demo (#111); no learned
routing or evaluation-only allowlists.
This PR covers the feature implementation and its engineering validation; it does not claim improved held-out task performance.
Parent: #100. Child: #109.
🤖 Generated with Claude Code