o2r: purge coily from docs (operator surface) + check coily repo for o2r-aware verbs #43

New issue

Closed

opened 2026-06-02 21:14:30 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-06-02 21:14:30 +00:00

Owner

Per the repo dependency architecture, coily must not be aware of o2r at all - and the reverse, o2r must not document coily as part of its surface. Today o2r's docs bake coily channel into the protocol and operator surface. This purges it, and checks the coily side for o2r-aware verbs that also have to go.

This is the cleanup half of the trust-integration work. The impl half is #42, which should not land documented against a tool that must not exist here.

o2r-side purge (this repo)

docs/protocol.md - the "Operator surface" section states coily channel <verb> lives in the coily repo and lists send / stream / tasks-get / tasks-cancel / view. Replace with o2r's own operator surface (an o2r-owned CLI / entrypoint), or describe the operator surface tool-agnostically. Drop the coily naming.
docs/agent-channel-requests.md - uses coily channel verify and coily channel request throughout (Verification, Issuance sections), and the coily channel verify <url-or-issue-ref> recipe. Rewrite around the in-process verify lib + an o2r-owned issuer, per #42. Keep the "trust substrate is open" framing - that part is correct and stays.
AGENTS.md (this repo) - "Operator surface lives in coily" under the operator-surface note. Rewrite to point at o2r's own surface. Also sweep the "See also" / command-routing notes for any coily-as-o2r-operator implication.
Grep the whole repo for coily channel and coily to catch stragglers (README, FEATURES, channels docs, examples).

Note: this is distinct from routing dev commands through the cli-guard gate (ward / .ward/ward.yaml, with .coily/coily.yaml as the transition bridge). That gate is a generic build-tool wrapper and is not o2r-specific knowledge in coily - leave it. The thing to purge is coily knowing about o2r's channel / relay operator verbs.

coily-side check (reverse direction)

Check whether coily's own repo ships coily channel verbs that reach the relay (send, stream, tasks-get, tasks-cancel, view, request, verify). If so, that is coily being aware of o2r - exactly what the dep arch bans. Those move out of coily into an o2r-owned CLI.
File the coily-side removal as its own issue on the coily repo and cross-link here, since it is a separate repo with its own release path.

Where the operator surface goes instead

The replacement for coily channel is an o2r-owned surface - a thin CLI / entrypoint shipped from this repo or otel-a2a-relay-core, importing the same channels lib the relay uses. Single-sourced schema, no coily. Exact placement is a #42 / follow-up decision; this issue just removes the coily references and points at the o2r-owned replacement.

Done when

No coily channel (and no coily-as-o2r-operator) references remain in this repo's docs or code.
The coily-side reverse-direction issue is filed and linked.
protocol.md, agent-channel-requests.md, and AGENTS.md describe an o2r-owned operator surface (or a tool-agnostic one), consistent with #42.

Per the repo dependency architecture, **coily must not be aware of o2r at all** - and the reverse, o2r must not document coily as part of its surface. Today o2r's docs bake `coily channel` into the protocol and operator surface. This purges it, and checks the coily side for o2r-aware verbs that also have to go. This is the cleanup half of the trust-integration work. The impl half is #42, which should not land documented against a tool that must not exist here. ## o2r-side purge (this repo) - **`docs/protocol.md`** - the "Operator surface" section states `coily channel <verb> lives in the coily repo` and lists `send / stream / tasks-get / tasks-cancel / view`. Replace with o2r's own operator surface (an o2r-owned CLI / entrypoint), or describe the operator surface tool-agnostically. Drop the coily naming. - **`docs/agent-channel-requests.md`** - uses `coily channel verify` and `coily channel request` throughout (Verification, Issuance sections), and the `coily channel verify <url-or-issue-ref>` recipe. Rewrite around the in-process verify lib + an o2r-owned issuer, per #42. Keep the "trust substrate is open" framing - that part is correct and stays. - **`AGENTS.md`** (this repo) - "Operator surface lives in `coily`" under the operator-surface note. Rewrite to point at o2r's own surface. Also sweep the "See also" / command-routing notes for any coily-as-o2r-operator implication. - Grep the whole repo for `coily channel` and `coily` to catch stragglers (README, FEATURES, channels docs, examples). Note: this is distinct from routing dev commands through the cli-guard gate (`ward` / `.ward/ward.yaml`, with `.coily/coily.yaml` as the transition bridge). That gate is a generic build-tool wrapper and is **not** o2r-specific knowledge in coily - leave it. The thing to purge is coily knowing about o2r's *channel / relay operator verbs*. ## coily-side check (reverse direction) - Check whether coily's own repo ships `coily channel` verbs that reach the relay (`send`, `stream`, `tasks-get`, `tasks-cancel`, `view`, `request`, `verify`). If so, that is coily being aware of o2r - exactly what the dep arch bans. Those move out of coily into an o2r-owned CLI. - File the coily-side removal as its own issue on the coily repo and cross-link here, since it is a separate repo with its own release path. ## Where the operator surface goes instead The replacement for `coily channel` is an **o2r-owned** surface - a thin CLI / entrypoint shipped from this repo or `otel-a2a-relay-core`, importing the same `channels` lib the relay uses. Single-sourced schema, no coily. Exact placement is a #42 / follow-up decision; this issue just removes the coily references and points at the o2r-owned replacement. ## Done when - No `coily channel` (and no coily-as-o2r-operator) references remain in this repo's docs or code. - The coily-side reverse-direction issue is filed and linked. - `protocol.md`, `agent-channel-requests.md`, and `AGENTS.md` describe an o2r-owned operator surface (or a tool-agnostic one), consistent with #42.

coilysiren referenced this issue

2026-06-02 21:14:40 +00:00

o2r: implement gen_ai.authorization.* trust-boundary attributes + A2A->MCP span link (impl of #35) #42

coilysiren commented

2026-06-02 21:17:00 +00:00

Author

Owner

Reverse-direction issue filed: coilyco-bridge/coily#172.

Confirmed coily is concretely o2r-aware - cmd/coily/channel.go implements the full Agent Channel verb tree (list/create/post/read/state/spec/events/close) and hardcodes a link to this repo's docs/channels-protocol.md, plus a Channel config block in cfg.go / config.example.yaml. All of it moves to the o2r-owned CLI; the generic cli-guard gate import stays.

Reverse-direction issue filed: **coilyco-bridge/coily#172**. Confirmed coily is concretely o2r-aware - `cmd/coily/channel.go` implements the full Agent Channel verb tree (`list/create/post/read/state/spec/events/close`) and hardcodes a link to this repo's `docs/channels-protocol.md`, plus a `Channel` config block in `cfg.go` / `config.example.yaml`. All of it moves to the o2r-owned CLI; the generic `cli-guard` gate import stays.

coilysiren referenced this issue

2026-06-02 21:35:58 +00:00

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

coilysiren added the

label

2026-06-04 08:16:40 +00:00

coilysiren commented

2026-06-17 08:23:47 +00:00

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