feat(capabilities): land the typed capability catalog of sixteen fleet capabilities (CFVC-09) - #78
Merged
Conversation
… of upstream kunchenguid#1919) Land CFVC-09 on the fork trunk, which is the code this fleet actually runs. The same change was contributed upstream as kunchenguid#1919 and merged there, but a merged upstream PR is a contribution rather than a landing, so capabilities/catalog.json was still absent from the running trunk. The catalog is harness-neutral and definitions ONLY: nothing is bound, nothing executes, and no runtime reads the file. Each of the sixteen rows names an existing owner in this repo plus the existing check that pins that owner's behavior. network.request is deliberately unowned and captain-required, because nothing here mediates general outbound network access and naming an owner would invent one. authority_class reuses loopspecs/schema.json's already-validated enum verbatim rather than growing a second vocabulary, and the file certifies in its own text that it is a capability boundary and NOT a security boundary: it constrains a mistaken agent, never a hostile one. Binding and enforcement are CFVC-10's work, deliberately not built here. Rollback is deleting the file.
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.
Intent
Land CFVC-09, the typed capability catalog, on the fork trunk — the code this fleet actually runs.
The identical change was contributed upstream as kunchenguid#1919 and merged there, but a merged upstream PR is a contribution, never a landing:
capabilities/catalog.jsonwas still absent from the trunk. This PR closes that gap. Nothing was rewritten — the closure audit confirmed the catalog satisfies every property it was specified against.What this is
A harness-neutral catalog of the typed capabilities a Firstmate work identity may be said to hold. Definitions ONLY: nothing is bound to an agent, nothing executes, and no runtime reads the file. It renames a prose capability list as typed rows without changing what any agent can do.
Each of the sixteen rows carries
{name, input_schema, output_schema, owner, authority_class, verifier}:owneris an existing file in this repo, and everyverifieris an existing check that pins that owner's behavior. Both are enforced by test, so a row cannot name something that does not exist.network.requestis deliberately unowned andcaptain-required. Nothing here mediates general outbound network access, so naming an owner would invent one. The row records the intent and admits, in the file, that nothing enforces it.authority_classreusesloopspecs/schema.json's already-validated enum verbatim rather than growing a second vocabulary. A capability needing a new class is a change to that schema, decided there.CapabilityRegistryand must not be merged into it — that answers which service implementation handles a call; this answers what a work identity is permitted to do.The certification, stated in the artifact itself
The catalog carries a
not_a_security_boundaryblock so the point can never be assumed away:Every crewmate on every harness is currently launched with permission enforcement disabled, and the supported harnesses do not share a sandbox. No decision anywhere may treat a row here as containment. That changes only when an enforcement point exists that refuses rather than truncates — CFVC-10's work, deliberately not built here.
Expected red check — disclosed, not worked around
The structural attestation check ("PR must be raised via no-mistakes") will be red on this PR. That is expected on the fork-landing route: this branch was cut fresh from the trunk to land an already-validated contribution, so it carries no pipeline attestation marker. The marker was not forged and must not be. Every non-structural check should be genuinely green.
Base note
Cut from the current fork trunk
cda5a75rather than720f06e2a685, which the audit named — the trunk advanced four commits in the interim and720f06e2a685is its ancestor. Same lineage, current tip, so the PR is not born stale.capabilities/catalog.jsonis absent from both.AGENTS.mdandbin/fm-test-run.shhad drifted on the trunk, so the change was applied as a three-way patch rather than by copying files: each gains exactly one line, and the trunk's own entries are preserved.Verification
bin/fm-lint.shclean (ShellCheck 0.11.0, pinned).fm-test-run,fm-documentation-audiences, andfm-ensure-agents-mdpass — the tests covering the two shared files touched.Rollback
Delete
capabilities/catalog.json. No runtime reads it.Upstream PR
kunchenguid#1919 — left exactly as it is. That branch and the upstream PR are the same ref; it was not rebased or force-pushed.