Skip to content

feat: capability handshake contract for Aegis and Claude Code (#885)#899

Merged
OneStepAt4time merged 1 commit intomainfrom
feat/885-capability-handshake
Apr 2, 2026
Merged

feat: capability handshake contract for Aegis and Claude Code (#885)#899
OneStepAt4time merged 1 commit intomainfrom
feat/885-capability-handshake

Conversation

@OneStepAt4time
Copy link
Copy Markdown
Owner

Summary

Introduces a formal protocolVersion + capabilities handshake endpoint so Aegis and Claude Code clients can explicitly negotiate feature support before using advanced integration paths. Prevents version-drift breakage and enables safe feature gating.

New endpoint

POST /v1/handshake
Content-Type: application/json

{
  "protocolVersion": "1",
  "clientCapabilities": ["session.create", "session.transcript.cursor"],
  "clientVersion": "1.0.0"
}

Response (200 when compatible, 409 when not):

{
  "protocolVersion": "1",
  "serverCapabilities": ["session.create", "session.resume", ...],
  "negotiatedCapabilities": ["session.create", "session.transcript.cursor"],
  "warnings": [],
  "compatible": true
}

Negotiation rules

  • negotiatedCapabilities = intersection of server and client capabilities (client omits → get full server set)
  • clientVersion < minProtocolVersioncompatible: false, negotiatedCapabilities: []
  • clientVersion > serverVersion → compatible with forward-compat warning
  • Unknown client capabilities → ignored with a warning in the response

Changes

  • src/handshake.ts (new): negotiate(), AEGIS_CAPABILITIES, AEGIS_PROTOCOL_VERSION, HandshakeRequest/Response types
  • src/server.ts: POST /v1/handshake route
  • src/__tests__/capability-handshake-885.test.ts: 7 tests

Tests

  • 7/7 tests pass
  • Typecheck clean

Closes #885

Aegis version

Developed with: v2.5.3

Copy link
Copy Markdown
Contributor

@aegis-gh-agent aegis-gh-agent bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

REGRESSION: This PR removes the #842 ordering fix in handleInbound's kill case — channels.sessionEnded is now called BEFORE sessions.killSession instead of after. Fix: preserve #842 ordering: killSession first, then channels.sessionEnded. The approve/reject handler refactor is fine, but the kill case must NOT change the ordering.

@OneStepAt4time
Copy link
Copy Markdown
Owner Author

Addressed the same ordering concern on this branch as well. In inbound kill handling, sessions.killSession() now executes before channels.sessionEnded() to preserve the #842 contract.\n\nValidation run:\n-
px vitest run src/tests/capability-handshake-885.test.ts\n-
px tsc --noEmit\n\nFix commit: 94ffb12

@OneStepAt4time OneStepAt4time self-assigned this Apr 2, 2026
@OneStepAt4time OneStepAt4time force-pushed the feat/885-capability-handshake branch from 94ffb12 to 67870e5 Compare April 2, 2026 11:51
Copy link
Copy Markdown
Contributor

@aegis-gh-agent aegis-gh-agent bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Well-designed capability handshake. Clean negotiation logic, solid test coverage (7 cases), proper input validation. No docs/superpowers leaks. Fixes #885.

@OneStepAt4time OneStepAt4time merged commit e46d0eb into main Apr 2, 2026
5 checks passed
@OneStepAt4time OneStepAt4time deleted the feat/885-capability-handshake branch April 2, 2026 11:54
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.

[Interop] Capability handshake contract for Aegis and Claude Code

1 participant