Update skill and tickets

tickets/074-timeline-sort-still-broken.md

@@ -0,0 +1,68 @@
+# 074 — Timeline sort-by-property still doesn't work after tickets 059-061
+
+## Summary
+
+Wishlist feedback, verbatim: "The sorting on the timeline still does
+not work. I have tried sorting things that I know are sorted (logs
+param timestamp) and things that arent (thread name or pid). It does
+not work (change view, index etc). If it's taking time to index, that
+needs to be visible."
+
+This is a regression/bug report against functionality that should
+already exist: sort-by-param was added in ticket 045, and tickets
+060/061 (resolved in commit `de9ba6f`, "Resolve tickets 059-061:
+generic log-stream columns + sort helper indexes") replaced the naive
+full-materialize-then-sort with an incremental helper-index scheme
+(`SortHelperIndexEntry`, `build_sort_helper_index`,
+`update_sort_helper_indexes`, `purge_stale_sort_helper_indexes` in
+`engine.rs:1332-1431`), wired into the `EngineQuery::Logs` sorted
+branch around `engine.rs:1598-1634`. On the frontend, `sortBy`/
+`sortMissingFallback` are threaded from `LogTimeline.tsx`'s settings
+through `App.tsx` (`:349-350`, `:505-506`) into `fetchLogs`
+(`webapp/src/lib/api.ts:256-266`). Nothing found in a static read of
+this wiring looks obviously broken, so this needs live reproduction,
+not just a code read — treat the below as an investigation, not an
+assumed root cause.
+
+## Scope
+
+- Reproduce with `make dev` against real piped input: declare a param
+  covering thread name or PID, set the timeline's sort dropdown to it,
+  and confirm whether results actually reorder. Also test sorting by an
+  already-monotonic value (`ottyl_ts` or a declared timestamp param) to
+  isolate whether the bug is "sort does nothing" vs. "sort scrambles an
+  already-correct order."
+- Check whether the helper-index rebuild triggers correctly on first
+  use per sort key (`engine.rs:1604`, `.entry(sort_by...).or_insert_with`)
+  — a stale/empty helper index reused across a param rename or
+  re-declaration (see the ticket-061-era comments at `engine.rs:225-233`
+  about helper indexes needing invalidation when a declaration changes)
+  is one plausible cause worth ruling in or out.
+- Check whether the frontend is actually sending `sort_by` on every
+  poll/refresh, not just the initial query — a poll path that omits it
+  (`webapp/src/lib/polling.ts`) would look exactly like "sorting
+  doesn't work" despite correct backend logic.
+- Add visibility for the "still indexing" case the wishlist explicitly
+  calls out: if a helper index is being built (or rebuilt) for a
+  newly-selected sort key and that's slow enough to be user-visible,
+  surface a loading/building state in the timeline UI rather than
+  silently returning unsorted or partial results while it builds.
+- Write a regression test once the actual defect is identified —
+  ticket 060's existing tests apparently didn't catch this, so identify
+  what scenario they miss.
+
+## Acceptance criteria
+
+- Sorting the timeline by a declared param (including thread
+  name/PID-style non-monotonic params) actually reorders displayed log
+  entries, verified live in the browser.
+- Sorting by a param that's already effectively time-ordered doesn't
+  regress (still displays in the expected order).
+- If a helper index build takes long enough to matter, the UI shows
+  that it's building rather than looking broken or stalled.
+
+## Depends on
+
+Builds on tickets 045, 060, 061 — read those and their resolving
+commits (`de9ba6f` and its predecessor implementing 045) before
+forming a hypothesis.