Skip to content

feat(context): Fleet Capabilities in startup context (capability plane Phase 1)#68

Merged
ProtocolWarden merged 1 commit into
mainfrom
feat/capability-context-consumer
Jun 16, 2026
Merged

feat(context): Fleet Capabilities in startup context (capability plane Phase 1)#68
ProtocolWarden merged 1 commit into
mainfrom
feat/capability-context-consumer

Conversation

@ProtocolWarden

Copy link
Copy Markdown
Owner

What

The first consumer of the capability registry. build_resume_prompt now appends a Fleet Capabilities section to the compiled .console/.context, so an operator/agent sees what the fleet can do — owner, target scope, risk, lane — before acting. This turns the registry from correct-but-inert into read.

How (deliberately dependency-free)

Reads PlatformManifest's capabilities.yaml directly via PyYAML — no platform_manifest/repograph import and no RepoGraph graph-compile. An adversarial review of the plan flagged that the obvious load_default_capabilities() path drags in a full RepoGraph compile + a sibling-checkout import assumption that OperatorConsole (not a pip package; only PyYAML+cxrp) cannot satisfy. The flat authoring YAML already carries owner_repo_id / target_scope / risk / routing.preferred_lane as fields, so a direct read needs none of that.

  • Located in-repo when anchored at PlatformManifest, else a sibling PlatformManifest checkout.
  • Fail-soft: missing / malformed / non-list / empty registry → section omitted, context compilation never blocked.
  • Private capabilities (visibility != public) are never surfaced.
  • Routing stays descriptive — read-only legibility, no execution wiring.

Rendered output (real registry):

## Fleet Capabilities
**context_lifecycle_protocol**
- Session Garbage Collection — fleet · mutates_fleet · lane: maintenance
**custodian**
- Repo Health Audit — repo_set(visibility=public) · read_only
**operations_center**
- Board Unblock — fleet · mutates_fleet · lane: maintenance

Tests

14 new tests: locator (in-repo + sibling), scope trichotomy (repo/repo_set/fleet), grouping+sort, private-exclusion, fail-soft (missing/malformed/non-list/empty), and integration with build_resume_prompt.

Note: two pre-existing test_pipeline.py failures (run-dir written_at timestamp-resolution flakes) are unrelated to this change — they reproduce on main with this diff reverted.

🤖 Generated with Claude Code

…ity plane Phase 1)

First consumer of the capability registry. build_resume_prompt appends a
"Fleet Capabilities" section to the compiled .console/.context (owner, scope,
risk, lane), so an operator/agent sees what the fleet can do before acting.

Reads PlatformManifest's capabilities.yaml directly via PyYAML — no
platform_manifest/repograph import, no RepoGraph compile (the flat authoring
YAML already carries the fields). Located in-repo when anchored at
PlatformManifest, else a sibling checkout. Fail-soft: missing/malformed registry
omits the section, never blocks context compilation. Private capabilities
(visibility != public) are never surfaced. Routing stays descriptive.

14 tests: locator (in-repo + sibling), scope trichotomy, grouping/sort,
private-exclusion, fail-soft (missing/malformed/non-list/empty), integration.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@ProtocolWarden ProtocolWarden merged commit 4c62563 into main Jun 16, 2026
5 checks passed
@ProtocolWarden ProtocolWarden deleted the feat/capability-context-consumer branch June 16, 2026 04:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant