alkhttp/docs/reviews/006-alkcall-0.3.0-consequence-review.md

# Review 006 — alkcall 0.3.0 consequence review (WS-24/WS-25 upstream, alkhttp residual)

## Status

All units landed: Unit 2 + Unit 3 remediated and verified (`030c5ef`);
Unit 4 (docs reconciliation) landed with the 0.3.1 consumption
(`Cargo.lock` bump + the `services/list-peers` discovery gate). UP-02
decided (recorded below). UP-03 fixed in alkcall 0.3.1 (`fd21230`,
ADR-030) and asserted by the extended WS-path gate. See Remediation
log.

## Scope

Consequence review of alkcall 0.3.0 (published 2026-09-04 — the
remediation of alkcall reviews 004–005, which is the upstream
resolution of this repo's review-003 findings WS-24/WS-25) against
this crate. The pass answers three questions:

1. What does the 0.3 bump itself cost here (source breaks, behavior
   changes)?
2. Which review-003 findings are now resolved upstream, and which
   remain alkhttp-side work?
3. Did the upstream remediation introduce anything this crate must
   absorb (new protocol codes, new wiring contracts, new decisions)?

Sources read: alkcall review 004 (`docs/reviews/004-…md`, remediated)
and review 005 (`docs/reviews/005-…md`, resolved G-01..G-05), the
0.3.0 changelog, the ADR amendments (alkcall ADR-047 §4 amendment #2,
ADR-022 amendments 2026-09-03 + 2026-09-04), and the published
0.3.0 crate source. Every claim below verified in source at this
tree (`df86f89`, consuming alkcall 0.3.0) or the published crate.

Findings use the new prefix `UP` (upstream-consequence); review 003's
WS numbering is referenced for continuity.

## Baseline verification (this pass)

```
cargo test                                → 453 passed, 0 failed
cargo test --all-features                 → 575 passed, 0 failed
cargo clippy --all-targets -- -D warnings → clean
cargo clippy --all-features --all-targets -- -D warnings → clean
cargo fmt --check                         → clean
cargo doc --no-deps                       → clean
```

Verified after the 0.2 → 0.3 bump (`3dee46a`). The bump cost was
two source-break classes, both mechanical:

- `ChannelClient::take_call_connection` now returns
  `Option<Arc<CallConnection>>` (was a bare `CallConnection`) —
  `WssSession::connect` dropped its `Arc::new` re-wrap
  (`src/adapters/from_wss.rs:268-274`).
- `OperationRegistry::register`, `ChannelOperations::register_on`,
  and `ChannelCore::register_openable` now take
  `&OperationRegistry` (was `&mut`) — 51 stale `mut` bindings
  dropped via `clippy --fix` across `src/adapters/{from_wss,to_mcp,
  to_openapi}.rs`, `src/gateway/routes.rs`, `src/server/adapter.rs`,
  and `tests/`.

The `&self`-registration change is the interior-mutability change
that makes the per-session fork surface possible; for every existing
alkhttp call site it is source-compatible (reborrow). The
`registration()` → owned and `list_operations()` → owned return-type
changes required no edits here (call sites already cloned through
the borrow or consumed by value-compatible iteration — verified by
the clean build).

## Verdict

- **WS-24 and WS-25 are resolved upstream.** The two design gaps
  review 003 Part B identified are now mechanized in alkcall 0.3.0
  and decided in its ADRs: the per-session fork is the
  dispatch-registry mechanism (alkcall ADR-047 §4 amendment #2 —
  review-003 option (a), the wire-proven shape), and `op/register`
  is the client-side registration mechanism (alkcall ADR-022
  amendment 2026-09-03 — review-003's bootstrap-op candidate). The
  alkhttp-side consequences of review-003 Unit 1's candidates are
  exactly what landed.
- **One upstream remediation result lands here for free:** review
  005 Unit 1 mechanized the accept-side pending-resolution arms into
  `run_loop_single_stream` (the loop our WS channel-0 dispatch
  runs). Pre-0.3, an accept-side nested-composing handler (a
  `from_call` imported-op stub riding the WS connection) could
  deadlock against the inline dispatch; post-0.3 the loop spawns
  Once invocations and Sub pumps, so the G-01 hazard class is shut
  for WS sessions by the bump alone — no alkhttp code involved.
- **The remaining review-003 findings are all still open and now
  unblocked** (WS-20/21/22/26 mechanical, WS-27 cleanup, WS-23
  tests): the hook still discards the `ChannelManager`
  (`src/websocket/upgrade.rs:255`), no channel ops / openables /
  bootstrap discovery are registered, no deployment surface declares
  openable ALPNs, and no live connection handle is retained. All
  grep-verified at this tree.
- **One new finding** (UP-01): alkcall 0.3 introduced the
  `ALREADY_EXISTS` protocol code; this crate's gateway error table
  has no arm for it and would map it to 500. Unreachable today
  (only `op_register_handler` emits it), load-bearing the moment
  Unit 2 wires `op/register`.
- **One wiring contract Unit 2 must honor** (UP-02, recorded as a
  decision point, not a defect): the `op/register` collision policy
  binds the WS session's handler to the session fork.

## Severity legend

Same scale as review 003: **[major]** — a decided behavior is
missing/wrong or a real hazard; **[minor]** — drift, convention
violation, or doc/spec inconsistency with no correctness impact.

---

# Part A — What 0.3.0 resolves for this crate

## WS-24 [was major, cross-crate] — dispatch-resolution mechanism → RESOLVED upstream

alkcall ADR-047 §4 amendment #2 (2026-09-03) decides option (a): the
`install_channel_zero` hook forks the deployment's base registry,
registers the per-session ops on the fork (`ChannelOperations::
register_on`, `ChannelCore::register_openable`,
`install_bootstrap_discovery` — the last closed over the fork so
`services/list` sees per-session openables, review-004 F-06), and
dispatches channel 0 over the fork. The connection overlay remains
the peer-announced-op landing zone and nested-invocation target, not
the dispatch-resolution path. The reference shape is alkcall's
`fork_registry_open_op_resolves_and_is_discoverable` gate
(`alkcall/src/channels/client.rs:1994` — fork → `register_openable`
→ `install_bootstrap_discovery` → `Dispatcher::new(fork, …)`), which
is the shape Unit 2 must reproduce in `install_channel_zero`.

Upstream also resolved the fork's discovery half (review-004 F-06):
`install_bootstrap_discovery` registers `services/list`,
`services/list-peers`, and `services/schema` closed over the fork
itself, so per-session openables are discoverable without a
re-registration walk. The bootstrap set is closed at four with
`op/register` (alkcall ADR-022 amendment, `services/list-peers`
added 2026-09-04 per review-005 G-05).

**alkhttp consequence:** none to code yet; Unit 2 consumes it.

## WS-25 [was major, cross-crate] — client-side op registration → RESOLVED upstream

alkcall ADR-022 amendment (2026-09-03) decides the bootstrap-op
mechanism: `op/register` (`registry::op_register` module) — a peer
announces an op spec over channel 0; the hub's per-session handler
rebuilds the spec, wraps it as a forwarding stub that nested-calls
back over channel 0, and lands it in the connection overlay via
`register_imported` (forced `Visibility::Internal`, provenance
`FromCall`). The wire stays the six `call.*` envelope kinds.
Collision policy (2026-09-04 sub-amendment, review-005 G-03): an
announced op may replace other *announced* ops (`replace` governs)
but never the serving side's own registrations — `ALREADY_EXISTS`
regardless of `replace`; the handler gates on the serving registry
first, then the overlay.

The serving half it composes on (`Dispatcher::serve_single_stream`,
opt-in via `ChannelClient::from_connection_with_serving`) landed
with review-005 Unit 1's concurrency rework: Once invocations, Sub
pumps, and sink response writers are spawned in both single-stream
loops, so same-connection nested composition (the flagship
hub-composes-peer-op flow) resolves concurrently instead of
deadlocking to the 30 s sweeper (review-005 G-01, empirically
verified upstream with a since-removed probe, productized as two
5s-bounded gates).

**alkhttp consequences:** Unit 2 wires `op/register` on WS sessions
by registering `op_register_spec(acl)` +
`op_register_handler(connection, fork)` on the per-session fork
(the collision set is the fork — exactly what the session
dispatches over, mirroring the upstream gates' production shape).
Two additional facts from review 005 apply:

- The channel-0 `Connection` must carry the peer identity for
  `compose_root_env` to attach the connection's overlay (keyed by
  `identity.id`). alkhttp's hook already does this
  (`src/websocket/upgrade.rs:264` — identity propagated from the
  upgrade's `AuthContext`); verified correct as-is.
- The serving loop's concurrency means a hub handler that composes
  an announced op resolves live (no sweeper); no alkhttp-side
  scheduling work is needed.

ADR-048's browser bidirectionality promise is now mechanized on the
hub half; the browser half (announcing via WS framing) is a
client-side concern with no alkhttp code beyond serving the op.
The re-point edits in ADR-048/OQ-05 (committed `df86f89`) record
this.

## Fixed-upstream items this crate inherits

- **Accept-side nested-composition hazard** (review-005 G-01's
  second consequence): mechanized shut by the pending-resolution
  arms now in `run_loop_single_stream` — inherited by the bump, no
  alkhttp code.
- **`resource_id_path` wire round-trip** (review-005 G-04): a
  `from_call`-imported or announced op declaring ownership-scoped
  resource extraction previously rebuilt with `resource_id: None`
  (ACL checks ran without the resource id). Both round-trip halves
  now carry the field. `from_wss`'s import path inherits the fix.
- **Head-of-line blocking / interleaved directions**: a serving
  side's outbound calls resolve while it serves a Sub (the
  interleaved-directions gate upstream) — relevant to any future
  serving-enabled `from_wss` (see Part C).

---

# Part B — Findings at this tree

## UP-01 [minor] — The `ALREADY_EXISTS` protocol code is unmapped in the gateway error table

**Verified:** YES. alkcall 0.3 added `CallError::already_exists`
(`"ALREADY_EXISTS"`, non-retryable —
`alkcall-0.3.0/src/protocol/wire.rs:124`) for the `op/register`
collision policy; its own ADR-022 amendment records the code.
alkhttp's status map (`src/gateway/error.rs:57-80`) has no arm for
it: `NOT_FOUND`, `FORBIDDEN`, `INVALID_INPUT`,
`INVALID_OPERATION_TYPE`, `TIMEOUT`, `INTERNAL`, and `HTTP_*`
prefixed codes are mapped; anything else falls to `STATUS_INTERNAL`
(500). alkcall's ADR-016 code list (six codes) was not amended for
the seventh — upstream doc drift, noted for that repo.

**Reachability today:** none — the only emitter is
`op_register_handler`, which no alkhttp path invokes yet (grep
verified; the gateway dispatches base-registry ops directly). It
becomes reachable exactly when Unit 2 wires `op/register` on WS
sessions, at which point a collision rejection would surface to
wire callers as 500 with an `ALREADY_EXISTS` body instead of a
conflict status. Because the collision path is also how a peer
experiences the reconnect-reannounce contract (`replace` refused
for serving-registry names), fidelity matters there.

**Fix (Unit 2, ride-along):** map `ALREADY_EXISTS` → 409 Conflict in
`call_error_to_http_status_with_identity` (plus the test arm),
matching ADR-023's `HTTP_<status>` discipline for the new code.
One-line change + test; no consumer breaks (the code is new).

## UP-02 [minor, decision point] — `op/register`'s AccessControl on the WS surface needs a decided default

Not a defect — a decision Unit 2 cannot avoid. alkcall's
`op_register_spec(access_control)` takes the ACL as a parameter; its
doc notes the default (`AccessControl::default()`) lets any peer
register, and the op is `Mutation`/`External`-typed. This crate's
convention (AGENTS.md §13, ADR-015): adapter-registered ops are
`Visibility::Internal` by default — but `op/register` cannot be
Internal on the wire surface (the *peer* must call it; Internal ops
resolve spec-404 to wire callers). The analogous precedent here is
the built-in gateway's `NoCap` posture for channel opens (review-001
SRV-10: crate default is permissive, deployments gate via the
`ChannelsPolicy` extension). The consistent shape: register
`op/register` on the per-session fork with `AccessControl::default()`
on the built-in surface and let an assembly-layer override pass a
stricter ACL the same way `ChannelsPolicy`/`OpenableAlpn` flow —
record the posture in the Unit-2 task and in ADR-048's amendment
note when the wiring lands.

## WS-20/WS-21/WS-22/WS-26 [major] — unchanged, now unblocked

Re-verified at this tree; all four stand as review 003 found them:

- `install_channel_zero` still discards the manager
  (`src/websocket/upgrade.rs:255` — `_manager` unused); no
  `ChannelCore`, no `ChannelOperations::register_on` (grep: zero
  callers in this crate), no openables.
- No `OpenableAlpn` surface exists (`src/server/adapter.rs` builders
  unchanged: `with_decoy` / `with_extra_routes` /
  `with_ws_max_sessions` / `with_ws_idle_timeout`).
- No live `Arc<CallConnection>` handle is retained by the session
  (the hook moves channel 0's connection into the spawned task);
  `WsSessions` still tracks pump handles only.

The fix shape from review 003 Unit 2 stands, now with the upstream
mechanism named concretely: per-session `fork()` in the hook →
`ChannelOperations::register_on(&fork)` → openables via
`register_openable(spec, handler, &fork, auth)` →
`install_bootstrap_discovery(&fork)` → `op_register_spec` +
`op_register_handler(Arc<CallConnection>, fork)` → dispatch over the
fork (`Dispatcher::run_loop_single_stream` unchanged as the loop).
The `OpenableAlpn` list + `with_ws_openable_alpns` threading
(RouterState → SessionState → hook, request-extension fallback
mirroring `ChannelsPolicy`) is unchanged, as is the WS-26
handle-retention design (eviction hooks into `WsSessions`).

## WS-27 [minor] — unchanged; folds into the Unit-2 hook rework

`adapter_install_channel_zero` (`src/websocket/upgrade.rs:290-295`)
is still `#[allow(dead_code)]` with its only caller test-gated
(`src/adapters/from_wss.rs` test server). The rework gives both
callers a real hook; fold the cfg cleanup there.

## WS-23 [minor] — unchanged; Unit 3's e2e gates gain two upstream-mirroring gates

The browser-opened-channel e2e test is still absent (no test opens a
data channel through a live WS session). Unit 3's five scenarios
stand as written. Two gates to add, mirroring what review 005
taught: `services/list` on a live WS session lists the per-session
openable (the F-06 shape), and the `op/register` announce → hub
nested-composition → routes-back-to-consumer flow (the stub path —
the one review-005's original gate missed and G-02 called out).

---

# Part C — Noted, not findings

- **Connect-side serving for `from_wss`**: alkcall 0.3's
  `from_connection_with_serving` makes the WSS consumer half capable
  of serving inbound calls (the from_wss session could answer
  hub→consumer calls). `from_wss` keeps the pure-consumer default
  (`from_connection`, resolution-only pump — verified unchanged);
  opt-in serving is a deliberate later decision (it changes
  `from_wss`'s security posture: a dial would then execute inbound
  requests against a caller-chosen registry). Recorded here so the
  opportunity is visible; no finding, no unit.
- **`op/register` forced-Internal semantics vs AGENTS.md §13**: the
  announced op lands `Internal`/`FromCall` on the hub — consistent
  with the adapter-registered-ops-are-Internal convention (it is
  composition material, not wire-callable from the hub side). No
  conflict; noted to preempt an apparent tension.
- **`list_operations` returns `External` only** — the
  `to_openapi`/`to_mcp` projections and the gateway `/search`
  continue to see exactly the External set; unchanged from 0.2.
- **Upstream doc drift (alkcall-side, not ours)**: ADR-016's
  protocol-code list ("six codes", last amended by ADR-021) does not
  name `ALREADY_EXISTS`. The 2026-09-04 ADR-022 collision
  sub-amendment records the code's use; ADR-016's list is stale.
  Flagged for the next alkcall doc pass; UP-01 is the alkhttp-side
  half of the same gap.

---

# Remediation log

## Unit 2 — alkhttp wiring (WS-20/21/22/25/26/27 + UP-01) — LANDED (`030c5ef`)

**Hook rework (WS-20/21/25).** `install_channel_zero`
(`src/websocket/upgrade.rs`) now takes `(registry, sessions, policy,
openable_alpns)` and, per the alkcall ADR-047 §4 amendment #2 shape
(verified against alkcall's own e2e reference
`fork_registry_open_op_resolves_and_is_discoverable`):

1. Forks the deployment's base registry.
2. Registers on the fork: `ChannelOperations::register_on` (the
   generic `channel/close` / `channel/control` /
   `channel/resources/subscribe` — WS-21), the deployment's openables
   via `ChannelCore::register_openable` (WS-22),
   `install_bootstrap_discovery` closed over the fork (F-06 — the
   session's `services/list` sees its own openables), and
   `op/register` (WS-25 — `op_register_spec` +
   `op_register_handler(connection, fork)`; the collision set is the
   fork, the production shape review-005's gates use).
3. Dispatches over the fork (`Dispatcher::run_loop_single_stream`
   unchanged as the loop; the loop's pending-resolution arms are the
   review-005 G-01 mechanization the bump inherited).

**UP-02 decided.** `op/register` is registered with
`AccessControl::default()` on the built-in surface (the SRV-10
precedent: permissive crate default), and an assembly layer overrides
via a stricter policy passed through the hook — the posture mirrors
`ChannelsPolicy`. The override surface rides the existing `policy`
parameter; the assembly layer's `ChannelsPolicy` value is the same
object the open wrappers consult. *(Review 007 WS-29 correction: the
`ChannelsPolicy` object is an `Arc<dyn ChannelLifecyclePolicy>` — the
channel-cap policy — and cannot carry an operation `AccessControl`; at
this commit the hook hardcoded the permissive default and no override
surface existed. Remediation implemented the surface as decided:
`HttpAdapter::with_ws_op_register_acl` + the `OpRegisterAcl` request
extension, review 007 Unit 2. The posture above stands as recorded;
only the "rides the existing `policy` parameter" mechanism was wrong.)*

**Openable-ALPN surface (WS-22).** `OpenableAlpn { spec,
open_handler }` + `HttpAdapter::with_ws_openable_alpns(Vec<..>)`,
threaded `RouterState` → `SessionState` → `run_channels_session` →
hook, with the `OpenableAlpns` request-extension fallback on the
upgrade handler (mirroring `ChannelsPolicy`/`WsTimeouts`). Default:
no openables (channel 0 only).

**WS-26.** `WsSessions` gains a `connections` map +
`live_connections()` / `live_connection_count()`; the hook retains
the channel-0 `Arc<CallConnection>` under a self-removing
`ConnectionGuard` (dropped when the channel-0 task ends — any
teardown path). Shared only when a shared `WsSessions` instance is in
play (the bare-registry/test-server path passes `None`). *(Review 007
WS-28 correction: at this commit the guard was bound inside the `if
let` block and dropped microseconds after insertion — the retention
sentence above described the intended scope, not the landed one.
Remediation bound the guard as an `Option<ConnectionGuard>` in the
channel-0 task's frame; the gate
`live_connections_visible_mid_session_and_drain_after_teardown` pins
it.)*

**Policy threading.** The hook takes the session's resolved
`ChannelsPolicy` (the extension resolution, `NoCap` default) and
passes it to both `ChannelOperations` and `ChannelCore` — one policy
instance across the open wrappers and the demux-loop teardown path.
(First cut used a fresh `default_policy()` per hook; the
ledger-decrement gate caught it — the `ChannelsPolicy` extension was
never consulted. Fixed by threading; that interaction is exactly the
seam SRV-10's extension was built for.)

**UP-01.** `ALREADY_EXISTS` → 409 Conflict in
`call_error_to_http_status_with_identity` + the test arm; the module
doc names the seventh code.

**from_wss import exclusion (new in this unit, surfaced by the
gates).** The reworked hook serves the bootstrap + channel-lifecycle
set on every WS session, so a `from_wss` import's `services/list`
listing now carries them. Proxying session-scoped machinery would be
nonsense (`channel/close` proxied to the remote would forward a close
for *this* session's channel ids; `op/register` proxied duplicates
the import itself). `FromWss::import` now runs discovery first and
passes the listing minus the protocol-session ops
(`services/list`, `services/schema`, `services/list-peers`,
`op/register`, `channel/close`, `channel/control`,
`channel/resources/subscribe`) as the `operation_filter` — the
`from_call` filter surface, used for the first time by alkhttp. The
three from_wss discovery tests assert the original op sets and pass.

**WS-27.** `adapter_install_channel_zero` cfg-gated to exactly its
caller's cfg (`all(test, feature = "server", feature = "wss")`); the
`#[allow(dead_code)]` is gone; it inherits the reworked hook (the
from_wss test-server producer now serves the session ops too).

**Gate results (Unit 3, `tests/ws_upgrade_session.rs`):**

- `data_channel_open_discoverable_and_bytes_round_trip` —
  `services/list` lists the session's openable + generic channel ops
  + `op/register` (F-06 shape); open op returns an even `channel_id`;
  a data chunk echoes back through the `OpenHandler`'s `Connection`.
- `channel_close_resolves_and_decrements_the_opener_ledger` — close
  resolves `{"closed": true}`; the ledger drops to 0.
- `channel_cap_denies_open_over_the_limit` — the second open over the
  cap denies with the `channel:too_many_channels` code (the
  `ChannelsPolicy` extension is consulted).
- `disconnect_mid_open_tears_down_and_decrements` — hard disconnect →
  the demux teardown decrements the ledger, no leak.
- `too_large_data_channel_chunk_survives_demux_resync` — a
  `MAX_CHUNK_LEN + 1` declared chunk is skipped (the skip consumes
  the declared payload off the transport, so the gate sends the
  filler), the next chunk routes and echoes — resync through the WS
  path (scenario 5).
- `op_register_served_per_session_and_collision_is_already_exists` —
  announce resolves `registered: true`; a second announce without
  `replace` rejects with the overlay gate's `ALREADY_EXISTS`;
  announcing the serving side's own op name with `replace: true`
  rejects `ALREADY_EXISTS` (the G-03 gate, through the WS path).
- `disconnect_mid_call_does_not_hang_the_server` and the full
  pre-existing suite stay green.

Test-harness hardening the gates required (recorded so the next
pass doesn't re-derive it): `call_and_await` filters by request id
(a prior Sub's trailing `call.completed` may interleave) and
tolerates data-channel chunks; `await_envelope` is the same filter
for hand-built frames; `CallError`-payload envelopes serialize flat
(`env.payload["code"]`, not `env.payload["error"]["code"]`).

**Verification (post-fix):**

```
cargo test                                → 454 passed, 0 failed
cargo test --all-features                 → 582 passed, 0 failed
cargo clippy --all-targets -- -D warnings → clean
cargo clippy --all-features --all-targets -- -D warnings → clean
cargo fmt --check                         → clean
cargo doc --no-deps                       → clean
```

---

## Unit 4 — spec reconciliation (docs) — LANDED (with the 0.3.1 consumption)

As planned in this review's remediation plan: OQ-05 resolved,
ADR-067 v1-cut note + ADR-048 amendment note updated to the landed
state, websocket.md §"Data channels for browsers" status block removed
(the section now documents the landed surface: `with_ws_openable_alpns`,
the `OpenableAlpns` fallback, cap policy, discovery, gates), the
idle-knob deployment note surfaced (silent data channels make the 60 s
default bite more often; semantics unchanged), the `op/register` ACL
posture (UP-02's decision) recorded in ADR-048's landed note, and the
UP-03 alkcall-side gap closed by 0.3.1 and asserted alkhttp-side (the
extended `op/register` gate). The alknet-ADR-044 §5 pointer was
checked: not stale (the rationale lives in this crate's ADR-044 §5;
the alknet-ADR-043 pointers are correctly marked parked/not-ported).

---

## Findings added during remediation

### UP-03 [minor, alkcall-side] — `services/list-peers` cannot list peer-announced ops; `PeerCompositeEnv` does not override `peer_operations`

Discovered by the Unit-3 gates: the first draft asserted announced-op
discoverability through `services/list-peers` and failed — the peers
array carries only `peer_id` entries with empty operation lists.

**Verified in both the published 0.3.0 crate and the alkcall tree:**
`services_list_peers_handler` maps `ctx.env.peer_operations(&peer_id)`
per peer (`alkcall/src/registry/discovery.rs:347-351`), but
`PeerCompositeEnv` overrides `peer_ids` only — `peer_operations` falls
to the trait default (`Vec::new()`,
`alkcall/src/registry/env.rs:63-65`); the `connections` map and
`connection_order` it would list from are in scope but unused there.
`OverlayOperationEnv` likewise overrides `contains` only. Net effect:
the peer-keyed listing shows `peer_id` entries whose `operations`
array is always empty, and the ADR-022 amendment's "announced op is
discoverable via `services/list-peers`" promise does not resolve on
the wire today. The alkcall gates never caught it because the F-05
gate calls the announced op directly (bypassing discovery) and the
G-02 gate composes it — neither lists peers after announcing.

**Fix lives in alkcall** (one method override:
`PeerCompositeEnv::peer_operations(peer)` → the connection env's
overlay registration names, ACL-filtered like the local listing;
`OverlayOperationEnv` may want a matching helper). Flagged for the
next alkcall review pass; the alkhttp-side gate
(`op_register_served_per_session_and_collision_is_already_exists`)
asserts the overlay-landing + collision semantics instead, which is
the behavior Unit 2 actually wires, and is not blocked by UP-03.

**LANDED in alkcall 0.3.1** (2026-09-04, `fd21230`): implemented as
alkcall ADR-030 — `OperationEnv` gains a defaulted
`list_operation_names`; `OverlayOperationEnv` overrides it;
`PeerCompositeEnv::peer_operations` delegates to the peer overlay,
and its `list_operation_names` aggregates session + connections +
base. Upstream gate:
`announced_op_is_discoverable_via_services_list_peers`. The version
pin here is `0.3` (semver-compatible), so the fix arrives through a
`Cargo.lock` bump with no source change; the WS-path gate that
originally surfaced UP-03 now asserts the discovery promise —
`op_register_served_per_session_and_collision_is_already_exists`
gained the `services/list-peers` step (announce → the `alice` peer
entry lists `consumer/exec`) and passes against 0.3.1 (it fails
against 0.3.0, verified by the original draft).

### UP-02 decision (recorded)

`op/register` is served per WS session with
`AccessControl::default()` on the built-in surface (the SRV-10
posture: the crate default is permissive, deployments gate via the
`ChannelsPolicy` extension whose value the hook now consults). The
wire-callability tension in this review's UP-02 note resolves the
same way: the peer must call `op/register` (it is in the bootstrap
set), so Internal visibility was never an option; the ACL parameter
is the deployment's gate, not the visibility flag.

---

## Verification log (this pass)

- Bump verified empirically: `cargo check` (default + all-features)
  surfaced exactly the two break classes; post-fix gates all green
  (453 / 575 / clippy both / fmt / doc).
- WS-24/WS-25 resolutions read in the published 0.3.0 crate source
  (`registry::op_register` handler + collision gate;
  `Dispatcher::serve_single_stream`; `install_bootstrap_discovery`;
  `OperationRegistry::fork`) and in the upstream ADR amendment
  texts; the reference fork shape read at
  `alkcall/src/channels/client.rs:1988-2130`.
- Review-003 residual claims re-verified at this tree: hook
  discards manager (`upgrade.rs:255`), zero `register_on` callers,
  no openable surface, no retained connection handle, WS-27 caller
  census unchanged.
- UP-01 verified: no `ALREADY_EXISTS` arm in
  `src/gateway/error.rs:57-80`; emitter census in 0.3.0 = `op_register.rs`
  only; fall-through confirmed to `STATUS_INTERNAL`.
- UP-02 verified: `op_register_spec` signature and its
  default-ACL doc note; AGENTS.md §13 vs wire-callable tension
  resolved against the SRV-10 precedent (permissive crate default +
  extension override).
- Cross-repo state verified: alkcall review 005 resolved
  (G-01..G-05 remediation log), 0.3.0 published with
  `cargo semver-checks` 196 checks against 0.2.0 (changelog's
  Changed section matches the two source-break classes this crate
  experienced).