fix(agents): break the hedging-at-the-root pattern — deferred(unclear), impacts field, reviewer detection

Address the root cause of rework-causing hedging: the architect was
put in a logical bind where it couldn't express justified uncertainty
('the pieces exist but the shape isn't clear yet'). The only options
were 'decide now' (premature) or 'deferred(scope)' (false — the
information isn't missing, it's un-synthesized). The agent picked
deferred(scope) with a circular blocking condition (OQ-64 blocked on
OQ-55, OQ-55 needs OQ-64) because there was no honest way to say 'I
can see the pieces but I can't see the shape.'

Changes to the architect role spec:
- Add deferred(unclear) state: the pieces exist but the composition
  isn't clear; resolution requires investigation (work through
  examples, POC), not waiting. Has an investigation target and an
  impacts field.
- Add 'Impacts' field to the OQ format: what does this block
  downstream? Be specific ('blocks the first hub deployment because
  the hub dials workers' not 'blocks the hub crate'). The triage
  signal that makes deferral urgency visible — the field that would
  have made the AlknetClient circular hedge visible.
- Add circular-reasoning guard to self-review: 'check that your
  blocking condition isn't a prerequisite of the thing you're
  deferring.'
- Trim anti-patterns #9-#11 (hedging synonyms catalog, ~40 lines):
  detection belongs in the reviewer, not the architect's self-review.
  The architect is too close to its own reasoning to see its own
  circular hedges.
- Trim door-types section (30→10 lines): keep the one-paragraph
  summary, cut the elaboration.

Changes to the architecture-reviewer role spec:
- Add Decision Quality (F) category: false-deferral check
  distinguishing three cases — (1) hedging on a resolved decision, (2)
  false deferral / circular hedge (the blocking condition is a
  prerequisite of the thing being deferred), (3) legitimate deferral.
- Add Impacts Field Coverage (G) category: check that unresolved OQs
  have specific impacts fields.
- Note: the Decision Quality category is often the highest-value
  check on poorly-defined projects — the architect cannot self-review
  it (circular reasoning is invisible from inside the circle).

Retrofit existing OQs:
- Add Impacts field to all 16 unresolved OQs (10 deferred, 6 open).
- Update OQ-63 (TlsError shape) to reflect ADR-087's client-side
  addition — the error type now covers both server and client
  variants.
- Move OQ-65 (WebSocket carrying channels) to alknet-http theme
  (done in prior commit; this commit adds its impacts field).
- Verified: no circular reasoning found in existing deferrals. The
  AlknetClient hedge (OQ-64) was the circular one; it's already
  resolved by ADR-087.

docs/architecture/questions/032-multi-hop-federation.md

@@ -4,6 +4,9 @@
 - **Status**: deferred(scope)
 - **Door type**: One-way (federation model), two-way (mechanism)
 - **Priority**: low
+- **Impacts**: None currently — the one-hop model covers all current use
+  cases. Would impact peer-graph routing if a multi-hop topology becomes
+  needed (e.g., chained hubs).
 - **Blocked on**: A concrete use case for multi-hop federation. The one-hop model covers all current use cases (head→worker, runner→hub).
 - **Resolution**: The model is **one-hop** — worker A does not transitively
   see worker B's ops through the head unless the head explicitly re-exports

docs/architecture/questions/038-webtransport-standalone-relay-service-scope.md

@@ -5,6 +5,8 @@
 - **Status**: open (scope, not deferral)
 - **Door type**: One-way (crate boundary), two-way (mechanism)
 - **Priority**: low
+- **Impacts**: None — the browser path uses WebSocket (ADR-044). Would
+  impact a browser-to-P2P-peer relay use case if one arises.
 - **Resolution**: There are two distinct "WebTransport proxy" concepts
   that must not be conflated:
 

docs/architecture/questions/041-stream-operators-library.md

@@ -6,6 +6,8 @@
 - **Door type**: Two-way (additive utility library; no protocol or API-surface
   change)
 - **Priority**: low
+- **Impacts**: None — handlers produce streams today without it. Would
+  reduce boilerplate in stream-transforming handlers when added.
 - **Blocked on**: A handler that needs stream operators and finds the existing
   combinators (`Box::pin(stream::iter(...))`, `async_stream::stream!`,
   `futures::stream`) insufficient. The operators library is a convenience, not

docs/architecture/questions/044-terminal-modes-tty-modes.md

@@ -6,6 +6,8 @@
 - **Status**: deferred(scope)
 - **Door type**: Two-way
 - **Priority**: low
+- **Impacts**: None — the `modes` field is reserved as `{}` and backends
+  use their defaults, which work for the common terminal case.
 - **Blocked on**: a concrete mode-control use case (a deployment that
   needs to set echo/raw/canonical/etc. modes on a PTY, beyond the backend's
   defaults).

docs/architecture/questions/046-runner-api-surface.md

@@ -6,6 +6,9 @@
 - **Status**: deferred(scope)
 - **Door type**: Two-way
 - **Priority**: low
+- **Impacts**: None — the runner *mechanism* (pipe mode) is in alknet-tty.
+  Would impact a future `alknet-runner` crate if job management / log
+  persistence / task graph integration becomes needed.
 - **Blocked on**: a concrete runner-policy use case that forces the API
   surface (job management, log persistence, task graph integration).
 - **Resolution**: Not yet decidable. The runner *mechanism* (pipe mode —

docs/architecture/questions/048-network-and-volume-operation-surface.md

@@ -6,6 +6,10 @@
 - **Status**: deferred(scope)
 - **Door type**: Two-way
 - **Priority**: low
+- **Impacts**: None — dev containers use the default bridge network;
+  hosted services declare networks/volumes in docker compose. Would
+  impact a fleet coordinator or dev-container orchestrator if one is
+  built.
 - **Blocked on**: a concrete use case for network or volume management
   over the call protocol. The two container use cases (disposable dev
   containers, hosted services) don't currently require

docs/architecture/questions/049-image-build-buildkit-scope.md

@@ -7,6 +7,9 @@
 - **Status**: deferred(scope)
 - **Door type**: Two-way
 - **Priority**: low
+- **Impacts**: None — current use cases pull pre-built images. Would
+  impact any use case that builds images via alknet rather than
+  operator-side `docker compose build`.
 - **Blocked on**: a concrete use case for building images over the
   call protocol. The two container use cases (disposable dev
   containers, hosted services) pull pre-built images (`docker/image/pull`)

docs/architecture/questions/051-container-create-options-surface.md

@@ -8,6 +8,11 @@
 - **Status**: deferred(scope)
 - **Door type**: Two-way
 - **Priority**: medium
+- **Impacts**: Blocks the full `docker/container/create` input schema —
+  v1 uses the high-frequency fields; the long tail (mounts, port
+  bindings, networks, volumes, capabilities) is deferred to the
+  implementation pass. Does not block the `create` operation itself
+  (ADR-060 §5 is decided); blocks the schema detail.
 - **Blocked on**: v1 implementation. The v1 `create` input schema
   accepts the common fields (image, command, env, labels, name) and
   the full `CreateContainerOptions` surface (mounts, port bindings,

docs/architecture/questions/052-callconnection-wait-for-close.md

@@ -4,6 +4,9 @@
 - **Status**: open
 - **Door type**: Two-way
 - **Priority**: medium
+- **Impacts**: Blocks clean supervision loop implementation — the hub's
+  `supervise_worker` currently polls `accept_bi()` until `ConnectionClosed`
+  (the interim). A `closed()` method would make this event-driven.
 - **Resolution**: Not yet decided.
 
 The hub's worker supervision loop needs a way to await connection close so it

docs/architecture/questions/053-backoff-config-defaults.md

@@ -4,6 +4,9 @@
 - **Status**: open
 - **Door type**: Two-way
 - **Priority**: low
+- **Impacts**: None — the struct shape is committed and the defaults are
+  a starting point. Would affect production tuning if operational
+  experience shows the defaults are wrong.
 - **Resolution**: Not yet decided.
 
 The `BackoffConfig` struct provides configurable backoff for worker

docs/architecture/questions/055-alknetclient-establishment-extraction.md

@@ -8,6 +8,13 @@
 - **Status**: deferred(scope)
 - **Door type**: two-way
 - **Priority**: medium
+- **Impacts**: Does NOT block individual transport dials — each
+  transport-specific dial helper builds its `TlsClientConfig` (ADR-087)
+  and its own connector standalone. Blocks only the *shared*
+  `AlknetClient::dial()` extraction (one entry point that picks the
+  transport and calls the right connector). Low impact until a second
+  transport's dial exists and the duplicated dial boilerplate becomes
+  worth extracting.
 - **Blocked on**: a **second transport's** real dial existing, not just a
   second QUIC dial. The blocking condition is met when, e.g., the SSH
   crate's raw-TCP dial or the HTTP-wrapped call dial exists — so the

docs/architecture/questions/056-full-channel-level-flow-control-windowing.md

@@ -6,6 +6,10 @@
 - **Door type**: two-way (additive — per-channel window tracking does not
   change the wire format)
 - **Priority**: low
+- **Impacts**: None — bounded-buffer backpressure (ADR-076) is the v1
+  mechanism and handles the intended use cases (TTY, SSH, tunnels).
+  Would impact high-throughput channel use cases (e.g., file transfer
+  over a tunnel) if HOL blocking is observed in practice.
 - **Blocked on**: a real deployment observes head-of-line blocking on a
   saturated channel where the bounded-buffer's stop-reading mitigation is
   insufficient. The trigger is specific: a channel whose consumer is

docs/architecture/questions/057-two-pump-helper-extraction.md

@@ -6,6 +6,9 @@
 - **Door type**: two-way (additive — a helper function does not change any
   API surface; handlers that inline the pattern continue to work)
 - **Priority**: low
+- **Impacts**: None — the two-pump *contract* is decided (ADR-078) and
+  handlers implement it inline. Would reduce ~10 lines of copy-paste
+  per handler when extracted; not a capability gate.
 - **Blocked on**: a second two-pump handler existing, so the shape
   convergence is observable. The tunnel handler is the first two-pump
   consumer; the SSH `direct-tcpip` channel will be the second. Extracting

docs/architecture/questions/058-worker-registration-flow.md

@@ -9,6 +9,10 @@
   workers are provisioned against them is a breaking change for every
   deployment)
 - **Priority**: high
+- **Impacts**: Blocks worker provisioning — a freshly-provisioned worker
+  has no way to enroll its key with the hub until the registration
+  endpoint exists. Blocks the first hub deployment that provisions
+  workers (web + native use case).
 - **Blocked on**: nothing structural — the identity machinery
   (`resolve_from_token`, `PeerEntry.auth_token_hash`, ADR-030/034)
   and the HTTP substrate (`HttpAdapter` on `h2`/`http/1.1` over

docs/architecture/questions/063-tlserror-shape.md

@@ -2,9 +2,10 @@
 
 - **Origin**: `docs/architecture/crates/tls/README.md`
   (`TlsError` is referenced as the `Result` error type in
-  `TlsServerConfig::new`, `for_quinn()`, and the crate's public
-  signatures, but is never sketched or defined); ADR-082 (same —
-  `TlsError` in signatures, no shape).
+  `TlsServerConfig::new`, `TlsClientConfig::new`, `for_quinn()`, and the
+  crate's public signatures, but is never sketched or defined); ADR-082
+  (same — `TlsError` in signatures, no shape); ADR-087 (extends the
+  surface to `TlsClientConfig::new` — the client-side error variants).
 - **Status**: open
 - **Door type**: one-way (the error type is the public API surface of
   `alknet-tls`; changing it after consumers exist is a breaking change
@@ -12,8 +13,14 @@
 - **Priority**: high (an implementer cannot write the crate without
   deciding this; guessing produces divergent shapes — one thin
   `rustls::Error` wrapper vs a 10-variant enum with per-path context)
+- **Impacts**: Blocks `alknet-tls` implementation — both
+  `TlsServerConfig::new` and `TlsClientConfig::new` reference `TlsError`
+  in their signatures. Blocks the hub's assembly-layer wiring (which
+  calls both). This is the next decision needed before the TLS crate
+  can be implemented.
 - **Resolution**: Not yet decided. The shape needs to cover the failure
-  modes across all four identity paths:
+  modes across all server identity paths **and** the client verifier
+  paths (ADR-087):
 
   - **Cert/key loading** (`X509`: file read + PEM parse;
     `SelfSigned`: rcgen generation) — currently `io::Error`-wrapped in
@@ -30,6 +37,14 @@
     returned from `new`), so `new`'s ACME path may only need to cover
     "ACME feature not enabled but `TlsIdentity::Acme` configured"
     (currently an `io::ErrorKind::Unsupported`).
+  - **Client verifier construction** (ADR-087) — `TlsClientConfig::new`
+    builds a `rustls::ClientConfig` with ADR-034's verifier selection.
+    Failure modes: verifier construction error (bad fingerprint format,
+    CA store init failure), unknown-remote fail-closed (not an error to
+    return — it's a `Result::Err` the caller gets for trying to connect
+    to an unknown raw-key remote), provider init failure. These
+    overlap with the server-side rustls-build errors but have
+    client-specific context (verifier selection inputs).
 
   The open question is the granularity: a single `TlsError` enum with
   variants per failure category (cert-load, rustls-build, quinn-wrap,

docs/architecture/questions/065-websocket-carrying-channels.md

@@ -23,6 +23,10 @@
   the simplification is worth the one-way-door commitment now, or
   whether the call-protocol-only path suffices until a concrete
   browser-needs-a-data-channel use case arrives.)
+- **Impacts**: Does not block the browser path (ADR-048 works). Would
+  simplify the hub relay (one model, not two) and unblock browser
+  access to data-channel ALPNs (TTY, tunnels) over a single WebSocket
+  if resolved to "WebSocket carries channels."
 - **Resolution**: Not yet decided. The two options:
 
   **Option A — WebSocket carries call only (ADR-048 unchanged).** The