WS-27 S1–S4: Tasks becomes a real slice of Projects — one card, one detail surface, one selection grammar; plus the one-store decision and the fences that found three latent defects

[vjvarada]

Driven by the owner's reframing:

"Technically, the Tasks app is only a slice of the Projects app… do a comprehensive review of the Tasks app to ensure there's at least parity in terms of the UI/UX."

Ruling applied throughout: Projects is canonical, Tasks conforms — except where Tasks is demonstrably better, which S4 handles in the other direction.

No migrations, no backend changes. Frontend, specs and tests only. (167 shipped in #418 and is already applied.)

---

The three divergences the owner named, from looking at the deployed app

Cards. Tasks' board adopts Projects' column shape, surface and gutter. The shared shell's completed and atCursor props are finally passed by their Tasks caller — done tasks were never dimmed or struck through, because the shell supported it and nobody wired it. The private AvatarStack copy is deleted for the shared one. Titles clamp in TaskCardShell so both apps move together rather than forking.

Detail surface. /tasks docks a w-[380px] pane instead of opening a pop-up. This was a bug against an existing rule, not a design difference: DESIGN_SYSTEM.md already specifies a side panel, and Tasks was the only overlay in the product (email uses a reading pane, notes a route, projects an aside). The modal survives as the phone branch and as an explicit maximise, because Tasks' detail is genuinely denser than Projects' and 380px cannot give it the max-w-3xl reading width. Two pieces of dead code — a side-panel entry imported nowhere and a maximise button that could never render — came back to life rather than being deleted.

Selection. The checkbox is permanent and sits in its own gutter beside the row. selectMode is now a derived mirror of "something is selected" and gates only the bulk bar. The bar moved to the top on Projects' chrome and primitives; select-all exists.

The previous slice had deliberately kept Tasks' modal select-mode, reasoning a permanent checkbox would steal the drag-grip gutter. That reason did not survive: Projects puts its checkbox outside the card as a sibling with stopPropagation, so there are two targets and the card surface stays the open affordance. Tasks put it inside, overlapping the grip — it created the collision and then documented it as a constraint. The comment now says what is true.

And the other direction (S4) — three findings where Projects carried the defect: the bg-accent active token (house norm is bg-primary/10 text-primary), a fourth bespoke task row in MyWork that bypassed the shared card vocabulary entirely, and no distinct filtered-empty state (Projects conflated no data with filtered to nothing and asked the user to guess).

The architecture decision

Owner question: one database with per-user separation, or two apps? One store, and the mechanism was already built and unused — pm_projects.personal_owner (a personal project, granted to one email) plus the per-member pm_task_personal overlay. "Local" is a visibility property, not a storage location.

The argument that settles it is already in migration 147's header: a single disposition column on a shared task cannot express delegation — one person doing it, another waiting on it — and two separate stores cannot either, because the task would exist twice and the copies disagree the moment either moves.

§7.5.1 is new and is the substance here. WS-27h said the move is "a copy rather than a translation." True of the seven overlay columns; false of the rest. gtd_items carries 31 columns plus gtd_waiting, and fifteen have no pm_tasks home — the founder priority matrix, all of timeboxing, deep_work, the email-capture badge, and the entire Waiting-For view. Executed on that sentence the migration would have been a feature deletion reporting success. Every column now has a named destination, decided by one question: if Ana and Ben are both on this task, can their answers legitimately differ? Two sequencing constraints recorded — the provider columns cannot drop before WS-27g, and horizon_id belongs to WS-21, which is DO-NOT-DISPATCH.

Three latent defects the fences found — none of which was the ticket

A rule I wrote in the previous PR was wrong. rounded-xl is not a fixed 12px: --radius-xl: var(--radius), identical to rounded-lg, and the whole named scale is derived. Acting on my claim would have baselined ~274 correctly-themed occurrences across ~70 files as debt — a fence against a non-violation, worse than no fence. Corrected in AGENTS.md with the correction visible, and DESIGN_SYSTEM.md spelled out so the misreading cannot recur.

Two source files contained literal NUL bytes. ripgrep stops at the first one — so every grep-based fence in this repo, and every grep a human or agent ran, silently saw only the first third of projects/TaskBoard.tsx, and stayed silent even when the file was named explicitly. The fences passed because they never looked. sourceHygiene.test.ts now fails on any NUL under src/; it found a second offender on its first run and a third in its own docstring, where the warning had pasted the very byte it warns about.

Local main was ~50 commits stale, so three agents cut branches backwards; one noticed only because half the WS-27 files vanished. Reset.

Also: sharedTaskUi's fence caught a genuine cross-slice gap — S4 built on the shared shell without declaring atCursor, which is indistinguishable from forgetting it. Now stated with its reason.

Verification

tsc clean · 1629 tests / 76 files (from 1586) · theme suite 356 · production next build compiles and prerenders all 39 pages · backend 189 passed on the touched suites. Every new guard was mutation-measured red and reverted byte-identical.

Owed, and not claimed

No visual check was performed, by any slice. Playwright cannot install in the build environment, so neither the phone-viewport pass nor the Fluent → Material → Graphite sweep happened. Each agent compensated with what it could inspect — class strings against the theme tokens, icon names against the registry, a production build — and each said plainly that it did not look at the running app.

This matters more than usual because there is still no structural or layout test anywhere in this tree. Nothing asserts panel composition, shell adoption, or that two apps draw a card the same way. The docked pane in particular is held by review alone.

Known, deliberate, and worth seeing before judging: WaitingForView still gates its checkbox on the old mode, so its first pick must come from select-all until it gets the same treatment. The shared card title is still text-[13px] against the house scale — the one contradiction left for the owner rather than settled by whichever slice touched the file last.

---

Generated by Claude Code