Skip to content

v1.6.5 — fix 'panel still says 1.5.3 after restart'

Choose a tag to compare

View all tags
@dreamrec dreamrec released this 03 May 08:41
· 100 commits to main since this release
v1.6.5
8f16f8a

Two bugs, one release

User reported after the v1.6.4 release that TD's panel still showed TDPilot 1.5.3 / Tools 102 after a restart, even though ~/.tdpilot was synced to v1.6.4 and tdpilot_startup.py had been redeployed. Diagnosis surfaced two independent bugs:

Bug 1 — tdpilot_startup.py only managed /local/mcp_server

When users dragged the .tox into the visible network panel, it landed at /project1/tdpilot (containerCOMP, panel UI). project.save then baked that into the autoload .toe with all v1.5.3-era content embedded (no externaltox indirection — the COMP is frozen). Every TD launch:

  1. .toe restored /project1/tdpilot — frozen v1.5.3 COMP, full content embedded
  2. The COMP's WS DAT bound port 9981 immediately
  3. Startup script ran, looked for /local/mcp_server (legacy v1.3-era name — never matched because the user's COMP is named tdpilot), called loadTox into /local. The new instance's WS DAT couldn't bind 9981 → silent fail
  4. /project1/tdpilot kept serving its baked v1.5.3 forever

Live confirmation: td_get_capabilities returned component_version="1.5.3" even after sha256-verifying the on-disk .tox was the v1.6.4 binary. The Startup script was loading the right file, into the wrong location, behind the wrong COMP.

Fix: New _find_existing_tdpilot_comps() sweeps both /local AND /project1 for both names (tdpilot AND legacy mcp_server). New _load_tox_fast() destroys every match found, then loads the fresh .tox into the same parent the previous COMP lived at — preserving the user's UI position. Defaults to /local when no existing install found.

Result: every TD launch from v1.6.5 onward self-heals. .toe restores stale COMP → sweep destroys it → loadTox at same parent → fresh v1.6.5 content. No project.save needed from the user.

Bug 2 — v1.6.4 silently shipped without bumping API_VERSION

git show v1.6.4:td_component/mcp_webserver_callbacks.py confirmed the published .tox baked API_VERSION="1.6.3" despite shipping as v1.6.4. The Edit was lost in a parallel batch; nothing caught it because scripts/check_versions.py had an explicit "do not gate API_VERSION" comment dating back to a since-abandoned attempt at decoupling the TD HTTP protocol version from the package version.

Fix: scripts/check_versions.py now gates API_VERSION against __version__ (lockstep policy). New pytest test (TestAPIVersionLockstep) asserts the same invariant — defense-in-depth so CI script + pytest catch independently. API_VERSION now bumped 1.6.3 → 1.6.5 (catching up the lost v1.6.4 edit).

If a legitimate need for distinct TD-protocol vs package versions ever arises in the future, the right move is to introduce a separate TD_PROTOCOL_VERSION constant rather than re-decoupling API_VERSION.

What you need to do

  1. npx tdpilot@latest (or click "Update" in Claude Code plugins)
  2. Re-deploy tdpilot_startup.py to TD's Startup dir: 
    cp ~/.tdpilot/td_component/tdpilot_startup.py ~/Documents/Derivative/Startup/
  3. Restart TD. Panel will show TDPilot 1.6.5 / Tools 103 immediately — no manual .toe re-save needed.

Tests

  • +16 unit tests in tests/test_startup_sweep.py: 6 for _find_existing_tdpilot_comps, 8 for _load_tox_fast (including the actual bug case: stale at /project1 destroyed + reload at /project1), 1 for the backward-compat shim, 1 for API_VERSION lockstep.
  • 769 → 785 total tests, all green.
  • All 5 CI gates green: pytest, ruff check, ruff format, check_versions (now gating API_VERSION), check_tox_freshness.

Tool count

Unchanged at 103.

🤖 Generated with Claude Code

Assets 5
Loading