refactor(platform): one VeryfrontApiTransport under the canonical and token API clients

[kojiwakayama]

Summary

Candidate #5 from the architecture review — the last of the seven. Two adapter stacks talk to the same api.veryfront.com, each privately owning URL-building, Bearer-auth headers, trace injection, per-attempt timeout, and error mapping. This names the seam: one VeryfrontApiTransport owns the HTTP mechanics; both stacks become policy over it.

Design (reworked per review)

The first attempt wrapped requestWithRetry in a third layer (+228 lines) and was rejected. This version replaces it:

• veryfront-api-transport.ts (203 lines) absorbs the former requestWithRetry body — span-wrapped fetch, header assembly, injectContext, metrics, redacted timeout/retry logging, terminal-error wrapping — parameterized only where the token client genuinely differs (returns raw Response, 4xx pass-through, TOKEN_STORAGE_ERROR, no spans/metrics).
• retry-handler.ts: 165 lines → a 20-line backward-compat alias.
• Two layers total: transport → retryWithBackoff primitive (refactor(errors): unify five retry implementations onto one retryWithBackoff primitive #3046).

Accounting

+46 net (+289/−243, 5 files) — near-neutral, with the two private copies of HTTP mechanics gone. Bonus: module-boundary debt decreased by one broad import; the baseline is regenerated to lock the ratchet at the lower count.

Verification

• All existing adapter suites pass unmodified: 11 test files / 214 steps (canonical + token)
• deno task verify:quick exit 0 · deno task test:unit green · module-boundaries green at the tightened baseline · pre-push (fmt + full suite) passed
• Note: one pre-push attempt failed on cli/mcp/tools/deploy-tool.test.ts ("triggerDeploy happy path") — it passes in isolation, in its suite (260 steps ×2), and in the full-suite rerun; treating as parallel-run flake, unrelated to this diff

GitHub client deliberately untouched (different host; separateness is load-bearing).

[Copilot]

Pull request overview

This PR consolidates duplicated HTTP/retry behavior for calls to api.veryfront.com by introducing a shared VeryfrontApiTransport and routing both the canonical Veryfront API client and the token-storage client through it, while keeping each client’s policy differences (response handling, retry semantics, error wrapping) configurable.

Changes:

• Added createVeryfrontApiTransport plus a canonical wrapper (createCanonicalVeryfrontApiTransport) to centralize fetch, auth header assembly, trace-context injection, retry/backoff wiring, logging, and error mapping.
• Replaced the canonical client’s requestWithRetry implementation with a small backward-compatible alias that delegates to the canonical transport.
• Updated VeryfrontAPIOperations and TokenStorageApiClient to hold a transport instance and use it for requests; updated module-boundaries baseline accordingly.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/platform/adapters/veryfront-api-transport.ts	New shared transport implementing the common HTTP mechanics (retry/backoff integration, headers, tracing/metrics hooks, default response handling).
src/platform/adapters/veryfront-api-client/retry-handler.ts	Shrinks to a backward-compatible alias delegating to the canonical transport and re-exports compatible types.
src/platform/adapters/veryfront-api-client/operations.ts	Switches operations to use a cached canonical transport instance rather than calling requestWithRetry directly.
src/platform/adapters/token/veryfront/api-client.ts	Switches token-storage client to a transport instance with token-client-specific response/retry/error policy.
scripts/lint/module-boundaries-baseline.json	Updates baseline to reflect the reduced import surface after refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 90f28e713c

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (4)

src/platform/adapters/veryfront-api-transport.ts:176

• logTimeout() only redacts the first token= query parameter occurrence because the regex is missing the global flag. If the URL contains multiple token params (or repeated), later values will be logged unredacted.

function logTimeout(url: string, timeoutMs: number, attempt: number): void {
  log.warn("Request timed out", {
    url: url.replace(/token=[^&]+/, "token=***"),
    timeoutMs,
    attempt: attempt + 1,
  });

src/platform/adapters/token/veryfront/api-client.ts:78

• On the 404 fast-path, the Response body is not consumed or canceled before returning null. This can keep connections/buffers open longer than needed.

This issue also appears in the following locations of the same file:

• line 99
• line 121

      const response = await this.transport.request(url);

      if (response.status === 404) {
        return null;
      }

src/platform/adapters/token/veryfront/api-client.ts:125

• The early return on successful/404 DELETE does not consume or cancel the Response body. Cancel it before returning to avoid leaking resources.

      const response = await this.transport.request(url, { method: "DELETE" });

      if (response.ok || response.status === 404) {
        return;
      }

src/platform/adapters/token/veryfront/api-client.ts:103

• set() returns void and the response body is never consumed on success. Cancel the body after a successful PUT so the underlying connection/buffer can be released promptly.

      const response = await this.transport.request(url, {
        method: "PUT",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ value }),
      });