feat(kernel-agents): author built-in capabilities as pattern-guarded exos#959
Draft
grypez wants to merge 1 commit into
Draft
feat(kernel-agents): author built-in capabilities as pattern-guarded exos#959grypez wants to merge 1 commit into
grypez wants to merge 1 commit into
Conversation
4 tasks
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
grypez
force-pushed
the
feat/described-exo-combinators
branch
from
707aa13 to
d7220eb
Compare
grypez
force-pushed
the
feat/capabilities-as-discoverable-exos
branch
from
fc7d58e to
9e110e2
Compare
grypez
force-pushed
the
feat/described-exo-combinators
branch
from
d7220eb to
b8ac175
Compare
grypez
force-pushed
the
feat/capabilities-as-discoverable-exos
branch
2 times, most recently
from
6c6abee to
620c437
Compare
grypez
force-pushed
the
feat/described-exo-combinators
branch
from
b8ac175 to
6bc1fee
Compare
…exos
Rewrite the `math`, `end`, and `examples` capabilities as discoverable exos
built with the `described*()` combinators, so each capability's argument shape
is enforced by the exo's interface guard at invocation rather than only
advertised in the prompt. A mistyped argument now fails with a guard rejection
at the membrane instead of surfacing deep inside the capability.
Each module derives its `{ func, schema }` capability specs via a new
synchronous `makeInternalCapabilities` constructor, which builds the
pattern-guarded exo and projects a capability record from the just-authored
schemas — without round-tripping through `GET_DESCRIPTION`. The exo is kept
private as the in-realm enforcement membrane; internal capabilities are guarded
closures, not passable exos (to cross a boundary, publish an exo and `discover`
it). All existing consumers (example transcripts, e2e tests, the REPL
evaluator, prepare-attempt) keep the same spec shape and `makeEnd` stays
synchronous. `end`'s closed-over result object is intentionally left un-hardened
so the exo method can mutate it.
`getMoonPhase` loses its (already unsupported, `@ts-expect-error`'d) `enum`
return hint; `end`'s off-spec per-argument `required` flags are gone, with
`final` required and `attachments` optional expressed by the guard.
Install the endoify mock as a package-wide vitest setup so capability modules,
which now build exos at import, have a `harden` global before they load.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
grypez
force-pushed
the
feat/capabilities-as-discoverable-exos
branch
from
620c437 to
1812ca4
Compare
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
1 participant
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.
Explanation
Rewrites the
math,end, andexamplescapabilities as discoverable exosbuilt with the
described*()combinators (added in the base PR), so eachcapability's argument shape is enforced by the exo's interface guard at
invocation rather than only advertised in the prompt. A mistyped argument now
fails with a guard rejection at the membrane instead of surfacing deep inside
the capability.
Each module derives its
{ func, schema }capability specs from the exo via anew synchronous
discoverLocal, so all existing consumers (example transcripts,the REPL evaluator,
prepare-attempt) keep the same spec shape andmakeEndstays synchronous.
end's closed-over result object is intentionally leftun-hardened so the exo method can mutate it.
Installs the endoify mock as a package-wide vitest setup, since capability
modules now build exos at import and need a
hardenglobal before they load.Notable behavior changes
getMoonPhaseloses its (already unsupported,@ts-expect-error'd)enumreturn hint.end's off-spec per-argumentrequiredflags are gone;finalis required andattachmentsoptional, expressed by the guard.Note on the local-only agent e2e suite
Because the capability modules now build
@endo/patternsguards eagerly atimport — and those builders require frozen patterns — they must be loaded
under a freezing
harden. The unit suites get this via their endoify-mock setupand pass. The local-only
@ocap/kernel-test-localsample-agent.e2esuite,however, imports the agent factories directly into the vitest realm under
mock-endoify(a no-opharden), so it now fails to construct there. That suiteis not end-to-end enough to begin with — it should drive an agent inside a real
hardened kernel and assert via logs (the
@ocap/kernel-testpattern) rather thanimporting agents into vitest. Tracked in #961. These tests are local-only and
not part of CI (
kernel-test-localhas notest:e2e:ci), so this does notaffect the CI signal.
Test plan
yarn workspace @ocap/kernel-agents test:dev:quiet(50 pass)yarn workspace @ocap/kernel-agents-repl test:dev:quiet(178 pass)build+lintfor both packages; changelog validateskernel-test-localagent e2e: see Agent-layer e2e tests should run inside a hardened kernel and assert via logs (not import agents into vitest under mock-endoify) #961 (out of scope here)