I3838 — The plan page renders within the audit budget at every width, because a finding is counted rather than printed once per pair
Bound the size of /plan/ (served at /docs/plan/) by what a reader needs rather than by the size of the backlog: site/templates/plan-section.html shows the plan's findings grouped by level and code, each group with its count and a few examples, and leaves the whole list to the data it is projected from (plan.json's findings_by_code beside findings, written by scripts/generate-site-data); and a case holds the page's element count to a declared ceiling, so ui-audit visits it at every width within VISIT_DEADLINE_MS (scripts/lib/ui-audit.mjs, 60 s) on a loaded machine.
READY wave 0 · p1 · implementation profile · parallel safe
Ready. Every dependency is done, so majordomus plan start I3838 will be accepted.
Objective
Bound the size of /plan/ (served at /docs/plan/) by what a reader needs rather than by the size of the backlog: site/templates/plan-section.html shows the plan's findings grouped by level and code, each group with its count and a few examples, and leaves the whole list to the data it is projected from (plan.json's findings_by_code beside findings, written by scripts/generate-site-data); and a case holds the page's element count to a declared ceiling, so ui-audit visits it at every width within VISIT_DEADLINE_MS (scripts/lib/ui-audit.mjs, 60 s) on a loaded machine.
Why
On 2026-10-21 #1760 (I3018, alpha.2) went red on one ui-audit timeout: /docs/plan/ at 1536 px over 60 s, and with it the release path waited. Measured that day (6a2e) with headless Chrome and the audit's own axe run (the same wcag2a/2aa/21a/21aa/22aa tags) against majordomus.dev at load ~68: /plan/ has 35,516 elements and is 154,693 px tall at 1536 (252,114 at 390); axe takes 14.4 s at 1536 and 13.4 s at 390, where the home page (1,545 elements) takes 0.3 s; a full-page screenshot does not finish within 30 s. In the tree of 573df967bb5 the page is 1,900,705 bytes, 22,831 elements, 2,899 <tr> and 11,888 <td>; on 2026-10-08 it was 360,014 bytes. Half of it, 932,562 bytes and 2,797 rows, is the findings table (the template's loop over every finding), and 2,774 of those rows are WARN scope_conflict, which `plan validate` reports once per pair of issues sharing a scope path: the table grows with roughly the square of the backlog, so a rerun that passes only postpones the next timeout. The next block is the waves list (an <ol> of 159,031 bytes, ~1,800 <li>); the milestone table is 68,881 bytes. Raising the deadline would hide the growth; the page has to stop growing with it. It is the page's standing size and not a regression of #1760 (2b, relayed by 9c): site/data/generated/plan.json went from 801 to 802 issues and from 3,442,258 to 3,457,862 bytes (+0.45%) between 905159df7cc and 573df967bb5, the one record being I3018's; 2b could not time /docs/plan/ locally, the fresh worktrees lacking node_modules and the rustdoc artifact at 35 GiB free. If #1760's second attempt times out on /docs/plan/ again it waits for this issue or a bound decision, not a third rerun. Id I3838 and case 3848 from 9c (board id-I3838-6a2e); 2b's local timing of /docs/plan/ for #1760 is to be added here rather than filed twice. The grouping took /plan/ at 1536 px from 35,516 DOM elements and 14.4 s of axe to 21,589 and 4.6 s (the same build, before and after, 2026-10-21). The known remainder is the plan graph mermaid draws in the browser from the page, about 12,700 SVG elements of the 21,589: within the budget, and the next block to bound if the page approaches it again, not part of this issue.
Current state
plan-section.html prints every plan finding as its own table row and every wave's issues in full; /plan/ is 1.9 MB with 35,516 elements live, axe takes 14 s on it, and its audit visit at 1536 exceeded the 60 s deadline in #1760.
Desired state
/plan/ shows the findings as one row per (level, code) with a count and at most a few examples linking to their subjects, the full list stays in site/data/generated/plan.json, and a case fails when the page's element count passes its declared ceiling; the audit visits /plan/ at every width well inside the deadline.
Scope
- site/templates/plan-section.html
- scripts/generate-site-data
- test/cases/3848_the_plan_page_fits_the_audit_budget.sh
- site/content
- site/data/generated
- docs/generated
Out of scope
- Raising VISIT_DEADLINE_MS or excluding /plan/ from the audit
- Changing how plan validate computes scope_conflict (whether a shared directory is a conflict is the planning model's question, not the page's)
- The /plan/dag/ page (1.18 MB), unless the same bound reaches it for free
- The waves list: one entry per issue, it grows with the backlog linearly, not with its square; the case's ceiling is what notices if it ever matters
Dependencies
None. This issue is a root of the graph.
Acceptance criteria
- /plan/ renders the findings grouped by (level, code), each group with its count, and the count of rows does not grow with the number of scope_conflict pairs
- Every finding remains reachable from the data the page is projected from (site/data/generated/plan.json), and the page says so
- A case fails when /plan/ in the built site passes its declared element ceiling, and passes at the tree it lands with
- scripts/ui audit visits /plan/ at every declared width within VISIT_DEADLINE_MS on a loaded machine
Validation
- bash test/run.sh 3848_the_plan_page_fits_the_audit_budget
- scripts/ui audit --report
Evidence required
- case_the_plan_page_fits_the_audit_budget
Evidence
None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.
Timeline
- started
- —
- verified
- —
- completed
- —
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I3838.yaml. Read it back with majordomus plan show I3838.