o2r: standalone Go CLI repo (otel-a2a-relay-cli) to replace coily channel #44

Closed
opened 2026-06-02 21:35:58 +00:00 by coilysiren · 2 comments
Owner

The o2r-owned operator CLI that replaces coily channel. This is the migration target the coily-side removal (coilyco-bridge/coily#172) merges into, and the operator surface the doc-purge (#43) points at. Currently unowned - filing it so the cleanup chain has a real keystone.

Shape: standalone Go repo, not in this repo

Per Kai's CLI/language tech preference (no Python CLIs, no polyglot repos, prefer Go, avoid cli-guard by default):

  • New single-language Go repo, e.g. otel-a2a-relay-cli. This repo (the relay) stays pure Python. The CLI repo stays pure Go. No polyglot repo anywhere.
  • Plain standalone binary. No cli-guard / ward import. It talks HTTP to the channels server and does JWS sign/verify in Go directly.
  • This is "coily channel done right": the same Go-CLI ergonomics, o2r-owned and standalone instead of buried in coily.

Cross-language contract: a published schema, not shared code

The CLI cannot import the Python channels lib, and should not. The contract is a published JSON Schema artifact plus a standard crypto primitive:

  • The envelope schema (agent-channel-requests.md) is emitted as a JSON Schema artifact, the same way scripts/emit_protocol_artifacts.py already emits docs/generated/o2r-attributes.schema.json from protocol.md.
  • The Go CLI issues + signs envelopes against that schema. The Python relay verifies against the same schema. Both use standard JWS (RFC 7515) over JCS-canonicalized JSON (RFC 8785), so each side uses off-the-shelf libs - no FFI, no cross-language import.

Refines #42: the envelope "schema + sign + verify lib" in #42 splits into - envelope schema as a published artifact (shared), Python verify in the relay (#42), Go sign + verify in this CLI repo. Update #42 to reference this split.

Verbs (two families, from coily channel + the trust design)

  • Channel coordination (from channels-protocol.md, lifted from coily's channel.go): list, create, post, read, state, spec, events, close. HTTP calls to the deployed channels server (#29).
  • Trust issuance (from agent-channel-requests.md + #42): request / issue (produce a JWS-signed envelope, interactive verbatim acknowledgment prompt when destructive), verify.

Carry-over from coily channel

  • SSM bearer auth. coily resolved a bearer token from SSM (/coilysiren/backend/datastore-token) per call. The Go CLI needs equivalent SSM resolution (AWS SDK for Go).
  • Config. Base URL of the channels deployment, SSM token path - the config.example.yaml channel: block that leaves coily lands here.

Scope / sequencing

  • Coordination verbs first. They unblock coilyco-bridge/coily#172's removal sooner (the removal repoints coily channel callers at this CLI).
  • Trust issuance verbs land with #42 (they need the envelope schema artifact + JWS, which #42 produces).

Dependencies

  • Blocks: coilyco-bridge/coily#172 (removal repoints callers here) - the removal cannot fully land until this exists.
  • Pointed at by: #43 (doc-purge names this as the o2r-owned replacement).
  • Refines: #42 (the schema/sign/verify split above).
  • Consumes: #29 (channels server it drives), #31 (if the schema artifact ships via core).
  • Consumers to repoint when it lands: the ops-eng-o2r-agent-channel skill and any coily channel references in agentic-os / agentic-os-kai.

Open question

Where does the JSON Schema artifact live so both Python and Go consume it cleanly - committed under docs/generated/ here (Go repo fetches/vendors it), or published via otel-a2a-relay-core (#31)? Decide before wiring the Go side.

The o2r-owned operator CLI that replaces `coily channel`. This is the **migration target** the coily-side removal (coilyco-bridge/coily#172) merges into, and the operator surface the doc-purge (#43) points at. Currently unowned - filing it so the cleanup chain has a real keystone. ## Shape: standalone Go repo, not in this repo Per Kai's CLI/language tech preference (no Python CLIs, no polyglot repos, prefer Go, avoid cli-guard by default): - **New single-language Go repo**, e.g. `otel-a2a-relay-cli`. This repo (the relay) stays pure Python. The CLI repo stays pure Go. No polyglot repo anywhere. - **Plain standalone binary.** No cli-guard / ward import. It talks HTTP to the channels server and does JWS sign/verify in Go directly. - This is "coily channel done right": the same Go-CLI ergonomics, o2r-owned and standalone instead of buried in coily. ## Cross-language contract: a published schema, not shared code The CLI cannot import the Python channels lib, and should not. The contract is a **published JSON Schema artifact** plus a standard crypto primitive: - The envelope schema (`agent-channel-requests.md`) is emitted as a JSON Schema artifact, the same way `scripts/emit_protocol_artifacts.py` already emits `docs/generated/o2r-attributes.schema.json` from `protocol.md`. - The Go CLI **issues + signs** envelopes against that schema. The Python relay **verifies** against the same schema. Both use standard **JWS (RFC 7515)** over JCS-canonicalized JSON (RFC 8785), so each side uses off-the-shelf libs - no FFI, no cross-language import. **Refines #42:** the envelope "schema + sign + verify lib" in #42 splits into - envelope schema as a published artifact (shared), Python **verify** in the relay (#42), Go **sign + verify** in this CLI repo. Update #42 to reference this split. ## Verbs (two families, from coily channel + the trust design) - **Channel coordination** (from `channels-protocol.md`, lifted from coily's `channel.go`): `list`, `create`, `post`, `read`, `state`, `spec`, `events`, `close`. HTTP calls to the deployed channels server (#29). - **Trust issuance** (from `agent-channel-requests.md` + #42): `request` / `issue` (produce a JWS-signed envelope, interactive verbatim acknowledgment prompt when `destructive`), `verify`. ## Carry-over from coily channel - **SSM bearer auth.** coily resolved a bearer token from SSM (`/coilysiren/backend/datastore-token`) per call. The Go CLI needs equivalent SSM resolution (AWS SDK for Go). - **Config.** Base URL of the channels deployment, SSM token path - the `config.example.yaml` `channel:` block that leaves coily lands here. ## Scope / sequencing - **Coordination verbs first.** They unblock coilyco-bridge/coily#172's removal sooner (the removal repoints `coily channel` callers at this CLI). - **Trust issuance verbs land with #42** (they need the envelope schema artifact + JWS, which #42 produces). ## Dependencies - Blocks: coilyco-bridge/coily#172 (removal repoints callers here) - the removal cannot fully land until this exists. - Pointed at by: #43 (doc-purge names this as the o2r-owned replacement). - Refines: #42 (the schema/sign/verify split above). - Consumes: #29 (channels server it drives), #31 (if the schema artifact ships via core). - Consumers to repoint when it lands: the `ops-eng-o2r-agent-channel` skill and any `coily channel` references in agentic-os / agentic-os-kai. ## Open question Where does the JSON Schema artifact live so both Python and Go consume it cleanly - committed under `docs/generated/` here (Go repo fetches/vendors it), or published via `otel-a2a-relay-core` (#31)? Decide before wiring the Go side.
Author
Owner

Build issue filed in the CLI repo: coilyco-flight-deck/otel-a2a-relay-cli#1 (bootstrap + Phase 1 coordination verbs + Phase 2 trust verbs). This issue (#44) stays the design / cross-repo tracking home; the implementation lands there.

Build issue filed in the CLI repo: **coilyco-flight-deck/otel-a2a-relay-cli#1** (bootstrap + Phase 1 coordination verbs + Phase 2 trust verbs). This issue (#44) stays the design / cross-repo tracking home; the implementation lands there.
Author
Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.
coilysiren 2026-06-17 08:23:47 +00:00
Commenting is not possible because the repository is archived.
No description provided.