Metabuilder-Labs/tokenjam

tokenjam/mcp/server.py's cost-row serializer and _HttpDB both enumerate CostRow's fields by hand, so a field added to CostRow and to the REST route can be dropped by MCP with nothing failing. That is the exact shape of #565, which this would let recur. Established by experiment during the #751 review. Two directions: A — the _HttpDB half IS gated. Added reasoning_tokens: int = 0 to CostRow, wired it into the REST /cost row dict and the MCP serializer, deliberately not into _HttpDB. Result: test_get_cost_summary_http_mode_preserves_complete_rows fails. Good. B — the serializer half is NOT. Same field on CostRow and the REST route, omitted from the MCP serializer (and _HttpDB). Result: 80 passed across test_mcp_server.py, test_storage_backend_parity.py and test_data_access_parity.py. Nothing fails, and MCP silently under-reports. B is #565 happening again. The reason A catches anything is incidental — the hand-written fake_response lacks the field, so _HttpDB not setting it makes t

Problem #729 added a shared guard in TjCommand.invoke that raises a clean ClickException when a DB-requiring leaf runs with ctx.obj["db"] is None, and replaced optimize's hand-rolled version with the shared db_required_message(). #727 asked for one copy of that message rather than two. There were more than two. Fifteen hand-rolled db is None errors are still in tokenjam/cli/, each with its own wording: cmd_backfill.py — lines 54, 180, 277, 339, 387, 436 ("backfill requires a database connection.") cmd_report.py — lines 77, 134 ("tj report requires a database connection.") cmd_route.py — lines 118 and 134 cmd_context.py:70, cmd_quota_audit.py:67, cmd_session_story.py:92, cmd_tokenmaxx.py:92 data_access.py:242 Two of these are worth more than a wording cleanup. cmd_route.py:134 is a verbatim copy of the shared message. It reads "route requires either a direct DuckDB connection or a running tj serve at the configured api.{host,port}" — the same sentence db_required_message() now

The test matrix job is the CI bottleneck — ~7 min typical, up to ~12 min on a loaded runner. Step-timing on a 3.10 job shows it's almost entirely test execution, not setup: Step Time Install deps ~23s Lint (ruff) ~1s Type check (mypy) ~14s Run tests ~7 min (up to ~12) Root cause: 5,037 tests run serially, single-process — only pytest + pytest-asyncio are installed (no pytest-xdist, no -n). Not redundancy per se; volume × no parallelism. Cost note: public repo → Actions is free/unmetered, and parallelizing within a job reduces wall-clock (fewer billed minutes on any private repo too) — no added cost. Prioritized fixes 1. Parallelize the test run — add pytest-xdist to [dev] and run pytest -n auto --dist loadscope. Ubuntu runners have multiple cores → realistically ~7 min → ~2-3 min. Caveat (validate carefully): this repo has global-state-sensitive tests — the OTel set-once TracerProvider and DuckDB single-writer paths (see the tracer-isolation history)

Severity: Low Where: four helpers that exist, are unit-tested, and have ZERO product callers: _package_uninstall_hint (cli/cmd_uninstall.py:64), session_token_cost_rollup (core/db.py:963), four_type_token_total (core/optimize/accounting.py:57), SchemaValidator.infer_schema_from_outputs (core/schema_validator.py:140). Observed: surfaced by the dead-code reachability sweep behind #599. Each was deliberately LEFT IN PLACE by that PR because none reads as leftover cruft — each reads as a wiring gap, i.e. a function that plausibly SHOULD have a caller and does not: _package_uninstall_hint returns the correct pipx/uv tool/pip uninstall command for how the user installed. Its sibling _package_reinstall_hint IS called; this one never is, so tj uninstall likely never tells the user the package-removal command it already knows how to compute. session_token_cost_rollup is the documented fix for a real accounting bug (fan-out harnesses posting raw OTLP whose cost spans carry only agent_id+trace

Severity: Medium Where: pyproject.toml (requires-python = ">=3.10", no upper bound), .github/workflows/ci.yml (python-version: ["3.10", "3.11", "3.12"]). Observed: On Python 3.13.2, pytest tests/unit tests/synthetic tests/agents tests/integration gives 95 failed, 3624 passed on a clean main. The same commit is fully green on all three CI versions. Failures cluster across unrelated modules — test_optimize_threshold_rendering (16), test_quickstart (10), integration/test_cli (9), test_onboard_* (19 across 5 files), test_cache_root_cause_render (5), test_ping (4), test_optimize_trim_provenance (4), test_optimize_resend_render (4) — which is the shape of an environment/dependency incompatibility rather than one broken feature. Why it matters: requires-python = ">=3.10" admits 3.13, so a user can pip-install onto an untested interpreter. Worse for development: a contributor on 3.13 sees a red suite and cannot distinguish their own regressions from the noise without first capturing a full