Skip to content

Issue — claude-code-chat-browser — Refactor _parse_tool_result dispatch table (5 pt) #29

@clean6378-max-it

Description

@clean6378-max-it

Issue — claude-code-chat-browser — Refactor _parse_tool_result dispatch table (5 pt)

Sprint: Wednesday, May 6 — Claude-code Refactor + Exclusion Consolidation (8 pt total; this item = 5 pt, task 1 of 2)
Repo: cppalliance/claude-code-chat-browser
Audit: claude-cursor.md CCC1 (structural half) + claude-code-browser-eval.md §5.1 / §5.4. (Both audit docs are internal; not on GitHub.)
(After opening on GitHub, paste the issue URL here.)


Background — what CCC1 actually asks for

CCC1’s Fix column in claude-cursor.md has two prongs:

  1. Add direct tests for jsonl_parser.py covering schema variants, malformed entries, and exception paths.
  2. Refactor _parse_tool_result’s if/elif chain to a dispatch table so new tool types are a single-site change.

Yesterday closed prong (1). This issue closes prong (2).

Prong Status Where
(1) Direct parser tests (14 dispatch arms, malformed inputs, helpers, integration) Done Issue #21 · PR #22
(2) Dispatch table refactor (this issue) Open This PR

Problem

utils/jsonl_parser.py::_parse_tool_result classifies Claude Code toolUseResult blobs through a ~140-line if/elif chain across 14 result families (eval §5.1; arms enumerated in Issue #21 Gap 1 table).

Consequences (eval §5.4):

  • High cognitive load for any contributor reading or modifying tool-result classification.
  • Schema evolution (new tool, renamed key, new variant of task / web_fetch) requires editing the chain in place — error-prone, merge-conflict-prone.
  • The “add a tool type” path is not localized.

The tests landed in PR #22 protect existing behavior; this refactor changes structure only, not semantics.


Goal

Replace the pattern-matching chain with an explicit dispatch table / ordered registry of (predicate, handler) (or equivalent), so that:


Scope (in)

  • Refactor _parse_tool_result only in utils/jsonl_parser.py. Internal helpers may be added in the same module if they aid clarity.
  • Preserve the arm ordering / matching semantics documented in Issue #21 Gap 1: bash, file_edit, file_write, glob, grep, file_read, web_search, web_fetch, four task variants, todo_write, user_input, plan, unknown fallback.
  • Keep non-dict / null toolUseResultNone behavior intact (Gap 9 in PR test(jsonl): add jsonl_parser schema coverage and harden null usage #22).
  • Add a short docstring or README-level note showing how to register a new tool family (one place to add).

Scope (out) — explicit

  • CCC2: GitHub Actions pytest workflow.
  • CCC3: rewriting other modules’ tests off cross-module _-prefixed imports.
  • _process_assistant exception strategy — the “no exception handling” phrase in CCC1’s finding text. PR test(jsonl): add jsonl_parser schema coverage and harden null usage #22 verifies no-crash behavior on bad inputs; adding real try/except + safe error surface is a separate follow-up.
  • Any change to what a tool result classifies as (semantics).

Acceptance criteria

  • _parse_tool_result is implemented via an explicit dispatch table / registry, not a long if/elif ladder.
  • All tests added in PR test(jsonl): add jsonl_parser schema coverage and harden null usage #22 (tests/test_jsonl_parser.py::TestParseToolResult + integration) pass without modification.
  • Adding a hypothetical new tool family is demonstrably a single primary registration site (verifiable by reading the diff or the new module-level docstring).
  • pytest green locally.
  • PR description references this issue, CCC1 (structural prong), eval §5.1 / §5.4, and yesterday’s Issue #21 / PR #22.

Coverage map (CCC1 closure)

CCC1 piece Closed by
Tests for 14 dispatch arms, helpers, integration, malformed inputs PR #22
_parse_tool_result if/elif → dispatch table (eval §5.4) This PR
_process_assistant exception strategy (CCC1 finding text) Deferred follow-up
CCC2 CI runs pytest Deferred follow-up
CCC3 non-parser modules importing _-prefixed parser symbols Deferred follow-up

After this PR ships, the Fix column of CCC1 is satisfied; the residual three rows above remain as separate tickets.

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions