Skip to content

Fix tasks not nesting/collapsing under Changes in tree views - #47

Merged
VeryComplexAndLongName merged 3 commits into
mainfrom
fix/tree-item-stable-ids
Aug 18, 2026
Merged

VeryComplexAndLongName merged 3 commits into
mainfrom
fix/tree-item-stable-ids

Conversation

@VeryComplexAndLongName

Copy link
Copy Markdown
Owner

Summary

  • Reported from live use: task items in the Changes/Archive trees rendered flush with their parent Change instead of nested under it, and didn't collapse/expand.
  • Root cause: no TreeItem subclass in changes-tree.ts or templates-tree.ts sets an explicit .id. Per VS Code's own API contract, omitting .id falls back to a label-derived identity that "cannot be kept stable" once items are recreated across refreshes — exactly what every provider in this codebase does on every getChildren() call (never reuses object references, by design).
  • Adds stable, scope-unique .ids to every tree item in both files. templates-tree.ts gets the same fix even though it wasn't reported — identical latent defect (real nested collapsible groups, no ids anywhere).
  • No behavior change to what the trees show, purely a rendering-identity fix.
  • Disclosed limitation: the actual visual symptom can't be directly re-verified in this environment (no desktop-UI automation tool available — same gap already noted in this session's other tree-feature smoke tests). The fix is grounded in VS Code's documented .id semantics and verified indirectly via id-distinctness unit tests, not a before/after screenshot. If the symptom persists after this ships, the root cause is something else and needs a fresh live report.

Test plan

  • npm run verify (typecheck/lint/english-policy/test) passes repo-wide — extension 89/89
  • New id assertions across changes-tree.test.ts, archive-tree.test.ts, templates-tree.test.ts, including explicit regression checks that a task's id differs from its parent Change's id
  • Real Extension Host run (npm run test:integration) — 6/6 passing
  • openspec change validate --strict tree-item-stable-ids passes

🤖 Generated with Claude Code

VeryComplexAndLongName and others added 3 commits August 18, 2026 09:57
Reported from live use: task items rendered flush with their parent
Change instead of nested under it, and didn't collapse/expand. Root
cause: no TreeItem subclass in changes-tree.ts or templates-tree.ts
set an explicit .id. Per VS Code's own API contract, omitting .id
falls back to a label-derived identity that "cannot be kept stable"
once items are recreated across refreshes — exactly what every
provider in this codebase does on every getChildren() call. Adds
stable, scope-unique ids to every tree item in both files (the
Templates tree has the identical latent defect, not yet reported,
fixed here too).

The actual visual symptom can't be directly re-verified in this
environment (no desktop-UI automation tool available, a limitation
already disclosed in this session's other tree-feature smoke tests)
— the fix is grounded in VS Code's documented behavior and verified
indirectly via id-distinctness unit tests, not a screenshot.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
# Conflicts:
#	README.md
#	packages/extension/CHANGELOG.md
#	packages/extension/package.json
#	packages/extension/src/tree/changes-tree.test.ts
Cover the two RepoBootstrapRootTreeItem/RepoBootstrapActionTreeItem
classes that landed via repo-bootstrap-tree-ui after this change was
written, and record the 0.12.2 -> 0.13.1 version rebase forced by
merging updated main.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@VeryComplexAndLongName
VeryComplexAndLongName merged commit 872d506 into main Aug 18, 2026
6 checks passed
@VeryComplexAndLongName
VeryComplexAndLongName deleted the fix/tree-item-stable-ids branch August 18, 2026 14:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant