## Summary #2767 (`GET /tasks/` p95 tripled 683 → 2225 ms between the 2026-08-04 and 2026-08-05 nightlies) is **closed**, but it was closed by !1913 — a query-**count** guard whose own description states it cannot detect this class of regression. No root-cause commit exists. The endpoint is still ~2x its pre-regression baseline on the latest nightly, and because that is *under* the 2000 ms threshold, nothing fires and nothing will. - 2026-08-01 … 2026-08-04 nightlies: `task_list` p95 **683–851 ms** - 2026-08-05 nightly: **2225 ms** (threshold breach, `allow_failure: true`) - 2026-08-09 nightly (job 15793812011): **1330 ms** — no breach, ~2x baseline !1913 asserts *query count is invariant in row count*. That catches a new N+1. It cannot catch a plan change, an index change, a per-request fixed-cost change, or anything that makes the same number of queries slower. Its own "Why" section says as much. Closing #2767 on it recorded the coverage gap as fixed and the regression as fixed, when only the first is true. ## The finding that reframes the whole investigation **The nightly measures a project with exactly ONE task.** `perf:load` seeds with `python manage.py seed_integration_fixtures` (`.gitlab-ci.yml`), and that command creates a single `Task`: ```python # One seed task so the schedule view renders a non-empty state on first load. Task.objects.create(project=project, name="CI Seed Task", duration=1, wbs_path="1") ``` (`packages/api/src/trueppm_api/apps/projects/management/commands/seed_integration_fixtures.py`) `load.js` `setup()` reads `/api/v1/projects/` and takes `results[0].id`; the seeded user is a member of exactly that one project, and every iteration then requests `GET /api/v1/tasks/?project=<that project>`. So the measured `task_list` p95 is the latency of **serializing one row**. Consequences, in order of importance: 1. **Both standing hypotheses for #2767 are structurally untestable by this harness.** The partial-index theory (migration 0134's `task_untouched_seeded_idx`) and the missing-ordering-btree theory (`Task.Meta.ordering = ["wbs_path","name"]` with no btree serving `(project, wbs_path, name)`) are both *data-scale* effects. Neither can move a one-row query by 1.5 seconds. Whatever moved the nightly is **per-request fixed cost** or **concurrency behaviour** (20 VUs against one in-pipeline uvicorn worker on a shared runner), not a scan or a sort. 2. **The harness cannot detect the regressions it is described as protecting against.** Its own header claims the tripwires catch "a new N+1, a dropped index, an accidental full-table scan". On one row, a dropped index and a full-table scan are the same plan, and an N+1 is one extra query. The endpoint the product cares about — a 500–5,000-task Gantt fetch — is not measured anywhere. 3. **`sizing.md`'s task-list envelope was measured before the regression window** and has not been re-measured since. ## What is actually worth fixing Two separable things. This issue tracks (a); (b) is called out so it does not get lost. **(a) The ordering index is a real, production-scale defect on its own merits.** Independent of what moved the nightly: the list query is ``` WHERE is_deleted = false AND project_id IN (<membership subquery>) AND project_id = X ORDER BY wbs_path, name LIMIT <page_size> OFFSET n ``` `Task.Meta` has `Index(["project"])` plus composites on `(project, early_start, early_finish)`, `(project, server_version)`, `(project, sync_seq)` and partials on unrelated predicates. **Nothing serves `(project, wbs_path, name)`.** The only `wbs_path` index is the GiST ltree index, which cannot provide an ordering. So every page of every Gantt fetch sorts the whole project's task set and discards the rows before `OFFSET`. That is worse than a plain sort here, because `annotate_tasks_queryset` attaches several correlated-subquery annotations (`is_summary`, `parent_id`, `percent_complete_rollup`, …) to the target list. With a `Sort` node in the plan those subplans are evaluated **below** the sort — i.e. once per project row — rather than once per returned row. Confirm/deny with `EXPLAIN (ANALYZE, BUFFERS)`. **(b) The perf harness needs a task-scale fixture.** A one-row `task_list` reading is not a regression tripwire for the Gantt fetch; it is a fixed-cost measurement wearing that label. Seeding a realistically-sized project (or a second, larger fixture project the harness targets by name rather than `results[0]`) is what would make the nightly able to catch the class everyone has been trying to bisect. Filed separately if this issue lands first. ## Scope of this issue 1. `EXPLAIN (ANALYZE, BUFFERS)` the real paginated list SQL against a realistic dataset, in an isolated DB. Record the plan. 2. Add the btree index that serves the filter + ordering, shaped to the predicate actually emitted (`wbs_path` is `ltree`, which has a btree opclass — verify in the plan that it is used for the ordering and not just as a filter). 3. Re-`EXPLAIN`; the `Sort` node should be gone. 4. Add a dated caveat to the `sizing.md` task-list rows naming the regression window and this fix, so the published envelope is not silently wrong before a re-measure. Refs #2767, !1913.