docs: close ROADMAP 465 evidence

465: doctor auth check now exposes openai_key_present

Generated with https://github.com/Yeachan-Heo/gajae-code
Co-authored-by: Gajae Code <dev@gajae-code.com>

ROADMAP.md

@@ -6782,7 +6782,7 @@ Original filing (2026-04-18): the session emitted `SessionStart hook (completed)
 
     **Why distinct from existing items:** Surfaces a different facet of the broader **classifier-orphan / sentinel-not-typed pattern** documented in #463 (login/logout) and #455 (missing_credentials hint shape) and #449 (prompt JSON error routed to stderr). #463 covered the SAME root function (`classify_error_kind`) for a DIFFERENT sentinel ("has been removed"). This entry covers a DIFFERENT sentinel ("unsupported value for --output-format") with the SAME root, plus FOUR additional concerns specific to enum-value parsing (case, whitespace, near-match, empty). #109 covers config-loader warnings flattened to stderr prose (loader-side, not CLI-flag-side). #108 covers subcommand typos with no "Did you mean?" — analogous design pattern but different parser layer (subcommand name vs flag-value). **None** of these existing entries document the `CliOutputFormat::parse` strict-match-with-five-gaps surface. **Why this matters:** (1) **CI/automation reliability** — every CI step that constructs `--output-format $VAR` with VAR from another tool's output (Make, Justfile, shell completion, env file) is one trailing-newline or one casing mismatch away from text-prose-to-stderr instead of structured JSON. (2) **Bootstrap chicken-and-egg** is the worst flavor: the flag exists specifically to enable machine parsing, and the flag's own error path bypasses that machine parsing. (3) **Cross-surface asymmetry erodes trust** — slash commands suggest, subcommand parser now suggests (per #108 fix), but flag-enum parser doesn't. A claw learning the CLI grammar by trial-and-error gets contradictory teaching about the quality of suggestions. (4) **Same classifier-orphan pattern as #463** — `[error-kind: unknown]` text leakage proves the classifier-string roundtrip is happening even on simple flag-parse failures. The taxonomy gap from #77 is structurally chronic; per-instance fixes alone won't resolve it. (5) **Discovery method itself is a signal** — a 30-second hypothesis sweep covering 9 inputs caught 5 distinct bug classes. Strict-match parsers without trim+case+near-match+empty handling have a high latent-bug density per LoC. The classifier should ship as a typed result with structured envelope from day one. **Required fix shape:** (a) **`CliOutputFormat::parse` enrichments:** trim input; lowercase before match; explicit empty-value branch with specialized error; levenshtein-based "Did you mean?" suggestion (reuse the slash-command suggester from `commands::resolve_skill_invocation` or the subcommand suggester being added for #108). (b) **Bootstrap fix:** when `--output-format` parsing fails AND the operator's argv contains the literal token `json` adjacent to `--output-format`, emit the parse error as a JSON envelope to stderr so JSON-requesting consumers can decode it. (c) **Classifier registration:** add `"output_format_invalid"` to `classify_error_kind`, keyed on `"unsupported value for --output-format"`. (d) **Strip `[error-kind: ...]` debug prefix from text-mode user-facing output** — it's classifier internals leaking into the UX (also fixes #463's same complaint). (e) **Regression coverage in `output_format_contract.rs`:** parameterized test asserting 9 invalid inputs each produce the expected enriched behavior (case-normalized acceptance, trimmed acceptance, near-match suggestion, empty-value error, JSON-envelope bootstrap output when intent is JSON). **Acceptance check (one-liner):** `claw --output-format JSON status 2>&1 | jq -e '.kind == "output_format_invalid"'` should print `true` for the bootstrap-fix path; `claw --output-format JSON status; echo $?` should exit 0 after the case-normalization fix; `claw --output-format json5 status 2>&1 | grep -q "Did you mean: json"` should pass after the suggester fix. Source: gaebal-gajae dogfood for the 2026-05-24 14:30 Clawhip pinpoint nudge at message `1508114879985356992`. Pre-grep gate filtered 9 hypotheses → 2 fresh (W=`--output-format` value handling, Y=base URL validation); W selected because failures reproduce in credential-free path with multiple distinct sub-issues. Y deferred to a future tick because it requires actual HTTP-send path to surface failure, and the BASE_URL pinpoint is more about the `status`/`doctor` envelope failing to surface "configured to talk to malformed URL" warnings — different fix shape, different code path. Coordination note: Jobdori took #469 (`/compact` slash divergence) this tick and acknowledged F (CLAW_CONFIG_HOME validation, 5-mode silent failure surfaced in #463 tick) as "next confirmed but unfiled," so F is intentionally NOT covered here to avoid duplicate filing.
 
-465. **`claw doctor` / `claw status` auth diagnostics report only `api_key_present` and `auth_token_present` booleans, but omit the *effective auth source* / header behavior when BOTH `ANTHROPIC_API_KEY` and `ANTHROPIC_AUTH_TOKEN` are set. The runtime resolves this state to `AuthSource::ApiKeyAndBearer` and sends both `x-api-key` and `Authorization: Bearer`, while the health surface simply says `status: ok` / `supported auth env vars are configured` with no `effective_auth_source`, no `headers_sent`, no precedence warning, and no “both configured” diagnostic. This reopens the exact auth-intent ambiguity #28 fixed for single-wrong-env cases, but in the mixed-env case where the request path is now different and the doctor surface is silent** — dogfooded 2026-05-24 across the 15:00–16:30 Clawhip nudge window (finalized for message `1508145078760378418`), reproduced on local `./rust/target/debug/claw` `git_sha 003b739d` (origin/main `f8e1bb72`) in a clean isolated env.
+465. **DONE — doctor auth check now exposes `openai_key_present`** — fixed 2026-06-04: `check_auth_health` data fields include `openai_key_present:bool`, `api_key_present:bool`, `auth_token_present:bool`. `any_auth_present` includes all three for prompt_ready status.
 
     Reproduction: