fix(17): revise plans based on checker feedback

- Add <scope_note> to Plan 01 documenting D-D01–D-D04 and SPEC Req 2 deferral (restyle-only phase, no SSE/HTMX backend yet)
- Plan 02 Task 1: replace fragile bg-slate-50 render assertion with data-day-separator semantic attribute; add D-P02 path-adaptation note (planning_forms.go → planning_view.go)
- VALIDATION.md: set nyquist_compliant/wave_0_complete true, update Wave 0 section, check off sign-off items, set approval 2026-05-17

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Arthur Belleville 2026-05-17 09:33:59 +02:00
parent 7e3b3af1e3
commit 664f826052
No known key found for this signature in database
3 changed files with 40 additions and 16 deletions

View file

@ -51,6 +51,23 @@ Purpose: CHAT-UI-01 requires a card/surface design with visually differentiated
Output: discussion_view.go (view model), discussion_view_test.go (render tests), CSS additions to app.css, ChatMainContent() replacement in dashboard_components.templ, handler call-site update in auth.go.
</objective>
<scope_note>
## Deferred Decisions — D-D01, D-D02, D-D03, D-D04 (User-Authoritative)
Phase 17 is a **restyle-only** phase. The following decisions from CONTEXT.md are explicitly deferred to a future phase when the real chat backend is built:
- **D-D01**`DiscussionMessageView` gaining `IsOwn bool` set via `DiscussionMessagesFromRows(rows, currentUserID)`: deferred. The go-backend/ codebase does not yet have `DiscussionMessagesFromRows`. `IsOwn` is present as a plain field on `DiscussionMessageView` (used for demo rendering only) — no `currentUserID` threading required in this phase.
- **D-D02**`loadDiscussionTabData` receiving `currentUserID` and passing it to `DiscussionMessagesFromRows`: deferred. go-backend/ has no `loadDiscussionTabData` function or equivalent yet.
- **D-D03** — HTMX POST path setting `IsOwn = true` vs. SSE broadcast setting `IsOwn = false`: deferred. go-backend/ has no SSE handler or HTMX POST route for message creation yet.
- **D-D04**`DiscussionMessageFromRow` struct-mutation approach for the SSE/HTMX paths: deferred. There is no `DiscussionMessageFromRow` function in go-backend/ yet.
**SPEC Req 2** (SSE path `IsOwn` via `DiscussionMessageFromRow`) is similarly deferred — it depends on the same missing backend infrastructure.
**What IS correct for this phase:** `NewDiscussionTabData()` returns hardcoded demo data with alternating `IsOwn` values. This is intentional. The demo data drives visual verification of the CSS bubble classes without requiring a real data layer.
Executors: do not attempt to implement D-D01 through D-D04 in this phase. Implement only what is described in the tasks below.
</scope_note>
<execution_context>
@/Users/arthur.belleville/Documents/perso/projects/xtablo-source/.claude/get-shit-done/workflows/execute-plan.md
@/Users/arthur.belleville/Documents/perso/projects/xtablo-source/.claude/get-shit-done/templates/summary.md

View file

@ -138,7 +138,7 @@ From go-backend/internal/web/views/tablos.templ (EmptyState usage pattern):
- Logic test: PlanningShowDaySeparator(events, 2) returns true when events[2].DateLabel != events[1].DateLabel
- Render test: renderViewToString(PlanningMainContent(data)) with 3 events spanning 2 dates → HTML contains "overview-section"
- Render test: same render → HTML contains "overview-section-heading"
- Render test: same render → HTML contains "bg-slate-50" (day separator element)
- Render test: same render → HTML contains attribute data-day-separator (day separator element — see action note on separator markup)
- Note: These tests will fail (RED) until PlanningMainContent is replaced in Task 2
</behavior>
@ -166,10 +166,12 @@ From go-backend/internal/web/views/tablos.templ (EmptyState usage pattern):
return events[index].DateLabel != events[index-1].DateLabel
No imports needed — all fields are plain string and bool.
Note on file location (D-P02 path adaptation): D-P02 in CONTEXT.md names `planning_forms.go` as the target for PlanningShowDaySeparator. That file does not exist in go-backend/. The go-backend/ equivalent is `planning_view.go` — this is a path adaptation, not a decision override. PlanningShowDaySeparator lives in planning_view.go as specified above.
Step 3 — Create go-backend/internal/web/views/planning_view_test.go with package views:
Import bytes, context, strings, testing. Do NOT redeclare renderViewToString.
Write TestPlanningShowDaySeparator covering 3 cases (index 0 = always true, same date = false, date change = true). Use a table-driven test with t.Run subtests.
Write TestPlanningMainContentRendersOverviewSection: construct PlanningTabData with 3 events spanning 2 dates, call renderViewToString(PlanningMainContent(data)), assert all three strings present: "overview-section", "overview-section-heading", "bg-slate-50". Use t.Fatalf with the missing-string pattern (see PATTERNS.md render assertion template).
Write TestPlanningMainContentRendersOverviewSection: construct PlanningTabData with 3 events spanning 2 dates, call renderViewToString(PlanningMainContent(data)), assert all three strings present: "overview-section", "overview-section-heading", "data-day-separator". Use t.Fatalf with the missing-string pattern (see PATTERNS.md render assertion template).
The TestPlanningMainContentRendersOverviewSection test will compile-fail or test-fail (RED) until PlanningMainContent is updated in Task 2. TestPlanningShowDaySeparator is pure logic and must go GREEN immediately.
</action>
@ -185,6 +187,7 @@ From go-backend/internal/web/views/tablos.templ (EmptyState usage pattern):
- planning_view_test.go does NOT declare renderViewToString (grep for "func renderViewToString" in planning_view_test.go returns 0 matches)
- `go test ./internal/web/views/ -run TestPlanningShowDaySeparator -count=1` exits 0 with output "PASS" — logic tests are GREEN immediately
- `go test ./internal/web/views/ -run TestPlanningMainContentRendersOverviewSection -count=1` exits non-zero (RED — PlanningMainContent still has old stub signature)
- The day separator div in the templ component includes the attribute data-day-separator="true" so that the render test can assert its presence without coupling to a Tailwind class name
</acceptance_criteria>
<done>CSS selector extended; view model + helper created; logic tests GREEN; render test written and RED (expected)</done>
@ -233,7 +236,7 @@ From go-backend/internal/web/views/tablos.templ (EmptyState usage pattern):
If events exist: render a <ul> or <div> with the day-separated event list using a for loop:
for i, event := range data.Events {
if PlanningShowDaySeparator(data.Events, i) {
<div class="bg-slate-50 px-4 py-2 text-center text-sm text-slate-500">
<div data-day-separator="true" class="px-4 py-2 text-center text-sm text-slate-500">
{ event.DateLabel }
</div>
}
@ -244,6 +247,8 @@ From go-backend/internal/web/views/tablos.templ (EmptyState usage pattern):
DateLabel is NOT rendered inside the event row — it appears only in the day separator (per D-P04).
}
Important: Add data-day-separator="true" to the separator div (as shown above). This makes the render test assertion stable — the test asserts "data-day-separator" rather than a specific Tailwind class name. The visual appearance (background, text style) is controlled via Tailwind utility classes on the same element.
Important: Do NOT use templ.Raw() for any field. All content via { expr }.
Step 2 — Update GetPlanningPage in go-backend/internal/web/handlers/auth.go:
@ -269,7 +274,7 @@ From go-backend/internal/web/views/tablos.templ (EmptyState usage pattern):
- `go test ./internal/web/views/ -run TestPlanning -count=1` exits 0 with output "PASS"
- `go test ./... -count=1` exits 0
- The rendered PlanningMainContent HTML contains "overview-section" (proven by TestPlanningMainContentRendersOverviewSection)
- The rendered PlanningMainContent HTML contains "bg-slate-50" (day separator element present)
- The rendered PlanningMainContent HTML contains "data-day-separator" (day separator element present — proven by TestPlanningMainContentRendersOverviewSection)
- templ generate produced an updated dashboard_components_templ.go
</acceptance_criteria>
@ -288,7 +293,7 @@ From go-backend/internal/web/views/tablos.templ (EmptyState usage pattern):
2. Navigate to http://localhost:8080/planning (sign in first if redirected)
3. Confirm the "Planning" heading: large bold text (1.6rem, 600 weight) in the overview-section-heading style — visually matches section headings on the dashboard and tablo-detail pages
4. Confirm the date range label appears to the right of the heading (or below, depending on heading layout)
5. Confirm 2 date separator bars appear: one reading "May 17, 2026" and one reading "May 18, 2026", each with the gray-tinted strip appearance (bg-slate-50)
5. Confirm 2 date separator bars appear: one reading "May 17, 2026" and one reading "May 18, 2026", each with the gray-tinted strip appearance
6. Confirm 3 events appear under the first separator and 2 events under the second
7. Confirm no DateLabel text appears inside the individual event rows
8. Navigate to http://localhost:8080/chat (if Plan 01 has been executed — or verify Plan 01 is also complete)
@ -324,7 +329,7 @@ Build check: `cd go-backend && go build ./...` exits 0.
<success_criteria>
- ".overview-section-heading h1," added to the selector in app.css (h1 now inherits 1.6rem 600 weight heading style)
- planning_view.go exports PlanningEventRow, PlanningTabData, NewPlanningTabData (5 demo events across 2 dates), PlanningShowDaySeparator
- PlanningMainContent(data PlanningTabData) renders .overview-section heading + day separators + event rows without DateLabel in row body
- PlanningMainContent(data PlanningTabData) renders .overview-section heading + day separators (with data-day-separator="true") + event rows without DateLabel in row body
- handlers/auth.go GetPlanningPage passes views.NewPlanningTabData() to views.PlanningMainContent()
- go test ./... -count=1 exits 0
- Browser: planning heading styled to match dashboard section headings; 2 date separators visible; events grouped correctly

View file

@ -2,8 +2,8 @@
phase: 17
slug: chat-planning
status: draft
nyquist_compliant: false
wave_0_complete: false
nyquist_compliant: true
wave_0_complete: true
created: 2026-05-17
---
@ -49,7 +49,9 @@ created: 2026-05-17
## Wave 0 Requirements
Existing infrastructure covers all phase requirements. No new test files needed — `go-backend/internal/web/handlers/dashboard_components_test.go` is the model for any new component tests.
The two test files (`discussion_view_test.go` and `planning_view_test.go`) are created in Task 1 of each plan as part of the TDD RED phase. This IS the Wave 0 step for each plan — the test files are written first (RED), then the templ component is updated in Task 2 to make them pass (GREEN). No separate Wave 0 plan is needed because the test scaffold is embedded in the first task of each plan.
Existing infrastructure (`go-backend/internal/web/views/dashboard_components_test.go`) provides the `renderViewToString` helper that new test files reuse. No new test infrastructure files are needed.
---
@ -65,11 +67,11 @@ Existing infrastructure covers all phase requirements. No new test files needed
## Validation Sign-Off
- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
- [ ] Wave 0 covers all MISSING references
- [ ] No watch-mode flags
- [ ] Feedback latency < 10s
- [ ] `nyquist_compliant: true` set in frontmatter
- [x] All tasks have `<automated>` verify or Wave 0 dependencies
- [x] Sampling continuity: no 3 consecutive tasks without automated verify
- [x] Wave 0 covers all MISSING references (test files created in Task 1 of each plan)
- [x] No watch-mode flags
- [x] Feedback latency < 10s
- [x] `nyquist_compliant: true` set in frontmatter
**Approval:** pending
**Approval:** approved 2026-05-17