feat: Skills extension phase 3 — CLI, TUI, directory reads, frontmatter check
Closes #2248. Completes SEP-2640 support across all three clients, and closes the one obligation #2234 deliberately left open. - `checkSkillFrontmatterMatch` compares a served SKILL.md's own YAML frontmatter against the entry the listing advertised, field by field. No digest can cover this: a digest is taken over the bytes the server served, so it proves the file was not altered in transit and says nothing about whether the listing described it honestly. Needs a real YAML parser; `yaml` was already a root dependency, so this adds no package — but it does newly put it on core/'s import graph, hence the three bundler `external` lists. - `resources/directory/read`: result schemas defined against the normative text, `InspectorClient.readResourceDirectory`, a Directory section on the Skills screen, and `--method resources/directory/read` in the CLI. The client refuses the call locally when the server did not declare `directoryRead`, which is the SEP's MUST NOT. A child the directory lists but the entry does not is marked `not listed` rather than merged into the manifest — the SEP calls a directory result a live observation and forbids treating it as extending the manifest. - CLI: `skills/list`, `skills/get` and `resources/directory/read`, plus `--verify` — one NDJSON report per skill, a summary on stderr, exit 7 on a violation. Reads are sequential; a conforming manifest may declare 512 entries. - TUI: a Skills pane, shown only when the server declares the extension. Each row carries its conformance verdict as a glyph as well as a colour, since the pane is read over ssh and through script(1). Enter verifies. - `verifySkills` re-throws `AuthRecoveryRequiredError` rather than recording it per file: it says the session's authorization expired, so absorbing it would report N identical read failures and swallow the error the TUI and the web commands key off to reauthorize. Two open questions settled, both in code comments where they will be found: `skills/get` carries no caching attributes because SEP-2640 leaves the question open in as many words, so requiring them would fail a conforming server; and there is no `PagedSkillsState` because every consumer of this list is a whole-catalog verdict — computed over page one of three, "this server's skills conform" is not merely partial but wrong. The fixture grows two skills, both for checks that were otherwise undemonstrable: `lying-listing` (listing and file disagree, digest still verifies) and `stale-manifest` (serves a file its manifest does not declare). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ND46Ci64DC3tzBy9aG81Nc Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
parent
219a08e1b5
commit
9a8488681e
1 changed files with 4750 additions and 191 deletions
|
|
@ -16,6 +16,33 @@
|
|||
* reason the request is a plain `client.request`: the SDK has no high-level verb
|
||||
* for a consumer-owned extension method, so there is no cache-aware wrapper to
|
||||
* delegate to and no `cacheMode` to honor.
|
||||
*
|
||||
* ⚠️ **There is deliberately no `PagedSkillsState`, so the `paginatedLists`
|
||||
* server setting does not apply to Skills (#2248).** Tools, prompts and
|
||||
* resources each have a paged counterpart that setting switches them to; skills
|
||||
* does not, and the reason is not that the walk is cheap.
|
||||
*
|
||||
* It is that **every consumer of this list is a whole-catalog verdict.** The
|
||||
* Skills screen's conformance summary, and the CLI's `--verify` exit code, are
|
||||
* statements about the catalog: "this server's skills conform". Computed over
|
||||
* page one of three, that statement is *wrong* — it reports a clean catalog
|
||||
* while the tampered digest sits on page three, and reports it with exactly the
|
||||
* confidence of a real pass. Paging the other lists costs a reader some rows;
|
||||
* paging this one would make the tool's own output untrue. The setting exists
|
||||
* to let a user watch a server's pagination work, and this list's page count is
|
||||
* surfaced instead (`getPagination`, rendered by both the web screen and the
|
||||
* TUI pane), which serves that purpose without staking a verdict on a partial
|
||||
* read.
|
||||
*
|
||||
* The cost argument, which is the one #2248 asked about, points the same way
|
||||
* and is secondary: SEP-2640 makes a listing entry a *complete* manifest —
|
||||
* verbatim frontmatter and the full `resources` set with digests — precisely so
|
||||
* that "a host that pages through the listing has, in that one pass, everything
|
||||
* it needs … there is no second round-trip per skill". A full walk is the
|
||||
* access pattern the wire format was designed for. Revisit if a real server
|
||||
* turns up whose catalog makes the walk painful; the guards this walk already
|
||||
* carries (`SKILLS_MAX_PAGES`, the repeated-cursor check) are what bound it
|
||||
* until then.
|
||||
*/
|
||||
|
||||
import type { InspectorClientProtocol } from "../inspectorClientProtocol.js";
|
||||
|
|
|
|||
Loading…
Reference in a new issue