docs(proposals): add How? section to #210 response-based token counting

[mkoushni]

docs(proposals): add How? section to #210 response-based token counting

Summary

Completes the graduation criteria for proposal #210 by adding the How? section — the design and implementation plan for the token_count filter that extracts token usage from AI provider response bodies and headers.

---

What changed

docs/proposals/00210_response-based-token-counting.md — 193 lines added, status updated from proposed → accepted.

Open questions resolved

All four open questions from the What?/Why? section are answered in the new How? section:

Question	Decision
Provider identification	Explicit provider: YAML key — no auto-detection. Azure and OpenAI share the same JSON schema so auto-detection would be ambiguous.
Streaming completion signal	BodyMode::StreamBuffer — proxy buffers all response body bytes and delivers them once with end_of_stream: true. Stream close is the authoritative trigger, covering providers that omit [DONE] (Google Gemini).
Streaming accumulation per provider	Per-provider strategy: single terminal-chunk scan for OpenAI/Azure/Google/Bedrock Converse; two-event scan (message_start + message_delta) for Anthropic; header-only for Bedrock InvokeModel.
Partial usage data	Only the final assembled payload is parsed — no summing of intermediate chunks — to avoid double-counting.

Design content added

• Requirements — 7 concrete implementation requirements.
• Filter struct and config — TokenCountConfig, ProviderKind enum, TokenCountFilter struct with YAML snippet.
• HttpFilter hook table — behaviour of each hook (on_request, on_response, response_body_access, response_body_mode, on_response_body).
• SSE extraction detail — dispatch tree: Anthropic two-event scan vs. last-valid-chunk scan for all other providers.
• Bedrock InvokeModel path — header-only extraction in on_response; BodyAccess::None prevents unnecessary buffering.
• FilterContext metadata keys — token.input, token.output, token.total written via ctx.set_token_usage.
• Module registration — step-by-step wiring for ai/mod.rs, http/mod.rs, builtins/mod.rs, and registry.rs.
• YAML configuration example — minimal working filter chain showing token_count with provider: openai.

---

Related

• Issue: #210 Response-based token counting from provider JSON
• Token counting epic: #20
• Provider mapping library: #216
• FilterContext metadata: #212
• Token header injection filter: #214
• Integration tests proposal: #220

[praxis-bot]

PR Review

Summary: Adds the How? section to the #210 proposal, transitioning status from proposed to accepted. Well-structured design that correctly addresses all four open questions and aligns with the existing token_usage library and FilterContext APIs.

Severity	Count
Medium	3

No critical or large issues found. The design decisions are sound -- StreamBuffer for body aggregation, explicit provider: key over auto-detection, and header-only path for Bedrock InvokeModel are all correct choices.