test(e2e): browser-level spec for foldable Tasks-table columns

[wojciechszyjka]

Summary

Adds the browser-level e2e spec that PR #743 left as follow-up work. The foldable Tasks-table
columns are currently exercised only in jsdom — which does no layout at all — so nothing proved
that a folded column is actually narrower, that the choice survives a reload, or that persisting
it preserves unrelated ui-state.json siblings.

Closes #822

What it covers

packages/web/e2e/task-columns.e2e.ts, five tests, mapping to the issue's scenario:

Issue point	Assertion
2	Shipped defaults: th[data-column-id="branch"][data-folded="true"], no other foldable header folded, and no button inside the Status and Task headers
3	Folding Workflow sets data-folded / aria-pressed="false" and measurably shrinks the column (getBoundingClientRect().width)
4	The fold survives a reload, and $CEZ_HOME/ui-state.json really holds taskTable.expandedColumns.workflow === false
5	An unrelated appearance.accent written first still coexists with the column state after a toggle — the sibling-preservation regression an earlier review pass caught as a blocker
7	Below md the card list renders the same fields whatever the desktop fold choices are

The spec boots its own cezar over a throwaway dataRoot with a pinned fixture runs.json, the way
quick-list.e2e.ts does. Two reasons: the run store reads runs.json once, at startup, so a
task rich enough to render every column can only be seeded before boot; and fixtureServeEnv pins
CEZ_HOME inside that dataRoot, which is a stronger isolation than the shared .ai/qa/cez-home
— this suite mutates ui-state.json, and settings-appearance.e2e.ts save/restores that same
file. It runs under the existing npm run test:e2e glob; no new runner, no new CI wiring.

Scope — point 6 is deliberately excluded

Scenario point 6 (a queued run present while CPU and Mem are both folded, asserting the two columns
stay narrow) is not in this PR. It pins the defect tracked in #821, which is being fixed in
parallel on #861, so that assertion belongs with that fix rather than racing it here. Acceptance
on #822 is therefore partial on that one point; the three acceptance criteria are otherwise met.

Verification

• The new spec: 5/5 green, three consecutive runs (13.6s / 20.9s / 18.0s), and green inside the
  full suite.
• Mutation-checked. Dropping the folded 42px from the colgroup and rebuilding turns the
  width assertion red — the shrink falls to 15.42px against a > 20 floor. The assertion guards
  what it claims to.
• Two flakes were found and fixed before this landed, both in the spec, neither in the app. A
  direct API write was landing on a keep-alive socket the server had already closed (ECONNRESET),
  so the spec passed only when the whole run finished inside the ~5s keep-alive window — the
  first green run was 6.5s and hid it. And the card-parity test inherited the fold state earlier
  tests happened to leave behind, where a toggle clicked into the state it already held flipped it
  the wrong way and hung for the full 25s provider timeout.
• Validation gate: typecheck, test, test:unit, build, test:package — all green.
• ⚠️ npm run test:e2e as a whole is red on this machine, and was already red without this
  change. With the new spec: 11 failed files / 30 failed tests. Baseline in the same session with
  the new spec temporarily moved out of the glob: 11 failed files / 31 failed tests. The failing
  set is pre-existing and unstable between runs (workflows.e2e.ts and settings-monitoring.e2e.ts
  swap places); task-columns.e2e.ts appears in neither list. Flagging it rather than presenting a
  red suite as a pass.

Tracking plan: .ai/runs/2026-08-11-browser-e2e-foldable-task-columns.md

[wojciechszyjka]

🤖 Label rationale:

• review — pipeline state: implemented, verified, awaiting code review.
• testing — the diff is one new e2e spec plus its execution plan; no production code changes.
• skip-qa — nothing user-facing changes, so there is no UI for manual QA to look at. The spec's own browser run is the evidence, and its screenshots are attached to the PR.
• priority-low — carried over from Add a browser-level e2e spec for foldable Tasks-table columns #822: follow-up coverage work, not release-blocking.
• risk-low — additive test-only change; the worst case is a flaky spec, which is why it was run three times and mutation-checked before landing.
• in-progress — the chain lock, handed off from Add a browser-level e2e spec for foldable Tasks-table columns #822 and released when this run reports.

[wojciechszyjka]

🤖 Browser evidence captured by the new spec (npm run test:e2e, agent-browser provider): the
shipped defaults with Branch folded, Workflow folded on top of that, and the sub-md card list
still carrying every field the folded desktop columns hide.

task-columns-defaults

task-columns-workflow-folded

task-columns-mobile-cards

[wojciechszyjka]

🤖 om-auto-review-pr taking over the chain lock — code review. Started: 2026-08-11T15:11:51Z.

[wojciechszyjka]

🔍 Code Review

PR #866 — test(e2e): browser-level spec for foldable Tasks-table columns
Verdict: approve (posted as a comment — GitHub refuses a self-approving review, and this run authored the PR).

📋 Scope

Two files: the new packages/web/e2e/task-columns.e2e.ts, and its execution plan under .ai/runs/. No production code is touched, so the backward-compatibility surface is untouched by construction and BACKWARD_COMPATIBILITY.md has nothing to say here.

✅ Validation

npm run typecheck, npm test, npm run test:unit, npm run build, npm run test:package — all green. The new spec is 5/5 green across five separate runs. packages/web/tsconfig.json includes e2e/**/*.ts, so the spec is genuinely typechecked rather than merely parsed.

🐛 Findings

Minor (fixed in this pass, a55abbb) — two toggles were clicked on an assumed state. task-columns.e2e.ts:275 and :314 clicked the Workflow and Reference headers on the assumption that earlier tests had left them expanded. Clicked from the other state they fold the wrong way, and the waitForFunction that follows then burns the full 25-second provider timeout and reports what looks like a product hang. This is the same failure mode already fixed once in the card-parity test; leaving two instances of it unfixed would have made the spec's stability a function of test order. Both now assert the precondition, so a violated assumption fails instantly and names itself.

Nit (not fixed, deliberate). expect(expandedWidth - foldedWidth).toBeGreaterThan(20) is a magic threshold. The registry asks for 124px expanded against 42px folded, so 20px is a deliberately loose floor that auto table layout cannot accidentally satisfy — the mutation check below shows a broken fold landing at 15.42px, comfortably under it. Tightening it would trade real robustness for apparent precision.

🧪 Test quality

The assertion this PR exists for was mutation-checked rather than assumed: dropping the folded 42px from the colgroup and rebuilding turns the width test red at 15.42px. Worth recording that a source-only edit proves nothing here — the fixture server serves built assets, so the first attempt at this check silently tested the unmodified app.

Two flakes were found and fixed before the PR was opened, both in the spec and neither in the app: a direct API write landing on a keep-alive socket the server had already closed (ECONNRESET, which made the spec pass only when the whole run fitted inside the ~5s keep-alive window), and the ordering assumption above. That is why the spec was run repeatedly at varying durations rather than once.

⚠️ CI

The required check Unit, build, E2E, and package is still pending at review time. Per this pipeline's rules the verdict is not held for it — the CI result will be posted as a follow-up comment, and required checks still gate the merge regardless of this review.

📌 Scope note carried forward

Scenario point 6 of #822 is deliberately unimplemented (it belongs with the #821 fix on #861), so acceptance on the issue is partial on that one point. That is stated in the PR body and is a scoping decision, not an oversight.

[wojciechszyjka]

🤖 om-auto-fix-issue run complete: approved by the automated review pass, merge-ready pending a human approval and CI. Lock released.

What landed

One new e2e spec, packages/web/e2e/task-columns.e2e.ts, plus its execution plan. Five tests covering scenario points 2, 3, 4, 5 and 7 of #822. No production code was touched.

Commit	What
cd7329c2	Execution plan
8e6e0677	The spec: fixture-server boot, defaults, measured fold, persistence, sibling preservation, card parity
41170543	Fixed two flakes in the spec — the ECONNRESET keep-alive race and the test-order assumption
2b510cd4, 16532070	Plan progress and verification record
a55abbb7	Review follow-up: assert the fold preconditions instead of assuming them

Verification

• The new spec: 5/5 green across five runs, at durations from 3.6s to 20.9s — deliberately spanning the ~5s keep-alive window that was masking a bug earlier.
• Mutation-checked: removing the folded 42px from the colgroup and rebuilding turns the width assertion red (15.42px against a > 20 floor). The spec guards the behavior it claims to.
• Validation gate — typecheck, test, test:unit, build, test:package — all green.
• Browser evidence (three screenshots) is attached above.

Honest caveats

1. The full npm run test:e2e is red on the machine this ran on, and was already red without this change. With the new spec: 11 failed files / 30 failed tests. Baseline in the same session, the new spec temporarily moved out of the glob: 11 failed files / 31 failed tests. The failing set is pre-existing and unstable between runs (workflows.e2e.ts and settings-monitoring.e2e.ts trade places); task-columns.e2e.ts is in neither list. CI is the authority on whether that redness is local.
2. Scenario point 6 of Add a browser-level e2e spec for foldable Tasks-table columns #822 is not implemented — it pins the Fix: the queued-row note keeps CPU/Mem from folding in the Tasks table #821 defect being fixed on fix(ui): keep CPU/Mem folded on queued task rows (#821) #861. Acceptance on the issue is partial on that point alone.
3. No GitHub approval is recorded, because GitHub refuses a self-approving review and this run authored the PR. The pipeline label stays review rather than merge-queue for that reason — claiming the latter would assert an approval that does not exist. A human reviewer is still required.
4. A CI-result follow-up is still owed. The required check was pending when this reported; the repo has no ci-monitoring label to carry that state, so it is recorded here instead.

[wojciechszyjka]

🤖 om-auto-review-pr — CI result: green.

Unit, build, E2E, and package passed in 4m42s (run); license/cla passed. Publish npm snapshot is still running and is not a required check.

Worth recording, because it settles the caveat in the summary above: that required check runs the E2E suite, and it went green — including the eleven spec files that were failing locally. The local redness was environmental (a loaded laptop), exactly as the baseline comparison suggested, and not something this PR introduced. The new task-columns.e2e.ts passed in CI too.

No further follow-up will come from this agent.

[github-actions]

📦 npm preview published — 0.9.2-pr866.1247

Try this PR build (exact pinned version — copy-paste as-is):

npx cezar-cli@0.9.2-pr866.1247                                # cockpit at http://localhost:4321
npx cezar-cli@0.9.2-pr866.1247 run "…"                        # headless run
npx cezar-cli@0.9.2-pr866.1247 server-deploy --platform <id>  # roll a server to this exact build

Also tagged: npm install -g cezar-cli@pr-866 (moving tag for this PR).
Packages: cezar-cli@0.9.2-pr866.1247 → @open-mercato/cezar@0.9.2-pr866.1247 → @open-mercato/cezar-api-client@0.9.2-pr866.1247 (provenance attested).