## Backlog

- [ ] [63td] 2026-03-03: We would need buttons to delete this worktree and at the project level to delete all unused worktrees.
- [ ] [ar9l] 2026-03-03: Buttons to send Git PR and a way to keep checking its status.
- [ ] [6bdn] 2026-03-03: Buttons to control the 'wt-* workflow' - using wt-create to create a new worktree etc
- [ ] [oibl] 2026-03-14: unable to scroll terminal on mobile
- [ ] [rkx4] 2026-03-20: The text input dialog - show buttons at the bottom of that dialog in a section that represent 'most used commands' - Clicking on them enters that text in the input box - later parts of this list may also be exposed in the dashboard cards - a quick way send commands to different session. This could be used to send the text 'Create PR' or 'Merge PR' to sessions that are ready to do so
- [x] [a36m] 2026-06-02: Add a build-time 'help-dump' step that emits rk's CLI help tree as help/run-kit.json and PRs it into sahil87/shll.ai (the shll.ai landing site renders it as an expandable 'Command reference' on the run-kit tool page). CONTRACT (frozen — copy the reference sample at sahil87/shll.ai path help/wt.json): JSON shape is {tool, version, captured_at (ISO-8601 UTC), schema_version: 1, root: Node} where Node = {name, path (full invocation e.g. 'rk riff'), short (one-line desc), usage, text (the RAW -h output byte-for-byte, newlines preserved), commands: Node[] (recursive; empty array = leaf)}. NOTE the file is named help/run-kit.json (matches the tool's repo/site slug) even though the binary is 'rk' — set the top-level tool field to 'rk' (the invoked name). rk has genuine NESTED subcommands (e.g. rk riff ...), so the recursive commands[] is exercised here — capture the full depth. PRODUCER (rk is Cobra/Go, binary 'rk', module 'rk', main at app/backend/cmd/rk): walk the cobra command tree programmatically (rootCmd.Commands() recursively), NOT regex-parsing -h text; per node capture cmd.Name / cmd.CommandPath() / cmd.Short / cmd.UseLine() and cmd.UsageString() (or Long+UsageString) as 'text'. FILTER OUT cobra's auto-generated 'completion' and 'help' subcommands and any cmd.Hidden==true (rk has serve/internal-ish commands — audit which are user-facing). VERSION: read from the built binary (rootCmd.Version / embedded ldflags) — do NOT hardcode. PUSH: in CI after the Go build, run the dump, write help/run-kit.json, validate it parses, then open a PR into sahil87/shll.ai using the existing repo secret SHLLAI_TOKEN (contents + pull-request write) with auto-merge enabled (PR, not direct push to main, to avoid the multi-repo push race). This is rk's slice of a 7-tool rollout; the shll.ai site-side consumer (Astro loader + reference UI) is tracked separately in the shll.ai repo.
- [x] [72oq] 2026-06-02: sync-latency.spec.ts:162 ('3. Create window via sidebar + button') is a no-op latency test: it does a hardcoded waitForTimeout(3_000) then record()s the elapsed ~3012ms, so it ALWAYS reports the action as SLOW/SSE-dependent regardless of reality. It can neither detect a latency regression nor prove the optimistic win — the sidebar + button create path IS optimistic today (app.tsx:477-484 fires onOptimistic -> addGhostWindow with rollback; window-store.ts has full ghost-window-on-create + unit tests), yet the audit summary still prints '[SLOW] Create window (UI, + button): 3012ms ← SSE-dependent', a false signal. Fix: replace the fixed sleep with a measurement of time-to-first-ghost-appearance — wait for the ghost window row to appear in the sidebar (poll/expect with a short timeout) and record THAT latency, so the test fails if create regresses to SSE-dependent (>500ms threshold). Audit the other sync-latency.spec.ts actions for the same fixed-sleep anti-pattern while there. Distinct from sl03 (that optimistic-create work is DONE); this is purely test-quality.
