Use one Berlin business date in #106 scheduling and default-SPA E2E

[alexeygrigorev]

Use one Berlin business date in #106 scheduling and default-SPA E2E

Status: code/reviews/checks complete on main; sandbox acceptance is blocked on successful normal CI deployment by #136 pending #143 ownership remediation; #140 is complete and #141 is not a blocker
Tags: bug, testing, frontend, P1
Depends on: #140 completed; successful normal CI deployment after #136, which awaits #143 ownership remediation
Blocks: None — #128 uses the shipped repair; #134 awaits the same normal deployment
Next owner: On-Call after #136 clears
Resume condition: sanitized On-Call evidence that normal main CI/CD terminally succeeds with the accepted #134 repair and completes relevant deployed smoke
Context: first cancelled #128 workflow; second failed pre-deploy workflow

Scope

Keep the accepted production correction and finish the missed default-SPA test migration exposed across the Jul 30 → 31 Europe/Berlin boundary.

1. Accepted production UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 correction. backend/src/public/app.js now uses one explicit Europe/Berlin business-calendar formatter for app “today” and bundle.createdAt scheduling comparisons. At Berlin 00:xx while UTC is still on the prior day, all nine pre-creation Newsletter tasks remain Scheduled rather than one leaking into due/overdue risk. Preserve this behavior.
2. Accepted original E2E correction. backend/e2e/bundle-detail.spec.js and backend/e2e/home-dashboard.spec.js use the shared Berlin helper, timezone, and fixed midnight-boundary clock. Preserve this coverage.
3. Required comprehensive repair. Six other default-SPA specs still derive UI-facing “today” or offsets from the Node runner local/UTC calendar and can disagree with the production Berlin date:
   • backend/e2e/accessibility.spec.js
   • backend/e2e/follow-up-actions.spec.js
   • backend/e2e/intake-inbox.spec.js
   • backend/e2e/operations-smoke.spec.js
   • backend/e2e/task-list.spec.js
   • backend/e2e/template-editor.spec.js

Migrate those six specs to backend/e2e/helpers/business-date.js. Where an assertion depends on the UI meaning of “today”, install the explicit Europe/Berlin browser timezone and a fixed clock before deriving fixtures, navigating, or asserting. Use the canonical boundary 2026-07-30T22:30:00.000Z (UTC Jul 30, Berlin Jul 31), or an equivalently frozen 23:xx UTC/Jul 31 Berlin instant when a scenario requires it. Do not add sleeps, retries, skipped assertions, or duplicate local date helpers.

Acceptance Criteria

• The frontend has one explicit Europe/Berlin business-calendar date formatter for instants; app “today” and bundle.createdAt scheduling comparisons use that same formatter.
• taskIsScheduled compares a template task’s date-only value with the bundle creation calendar date in Europe/Berlin, without truncating the creation timestamp to its UTC ISO date. Invalid task/bundle dates remain fail-safe.
• At a fixed Berlin 00:xx instant whose UTC timestamp is still on the previous date, a newly instantiated UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 bundle classifies all nine pre-creation tasks as scheduled and does not expose one as due/overdue risk.
• The original UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 scenarios in bundle-detail.spec.js and home-dashboard.spec.js install one deterministic clock/time zone before deriving, seeding, rendering, or asserting dates; API fixtures and browser expectations use the same Berlin calendar day.
• The original focused regression explicitly exercises the UTC/Europe-Berlin date divergence and both specs pass with retries disabled, not as flaky retry recoveries.
• All six newly affected default-SPA specs use the shared Berlin business-date/offset helpers for UI-facing current dates; none retains a runner-local or UTC helper for expectations about the production UI “today”.
• Every migrated scenario whose UI expectation depends on “today” freezes the browser clock and sets timezoneId: Europe/Berlin before fixture derivation/navigation, so API fixtures and browser output share one date.
• Deterministic boundary assertions prove the chosen instant is UTC Jul 30 and Berlin Jul 31; task-list seeds rows for the date the UI opens, and template-editor produces the Berlin-dated default title.
• template-editor.spec.js and task-list.spec.js pass together with --retries=0.
• All six affected default-SPA specs pass together with --retries=0, with no skipped or flaky recovery.
• An automated static audit of default-SPA specs rejects ad hoc runner-local “today” helpers/live date derivation for UI-current-date expectations. Deliberate UTC API specs are explicitly excluded and remain unchanged.
• CI=true npm --prefix backend run test:e2e passes 352/352 with exit code 0 and zero retry/flaky results.
• The repair changes no unrelated UI, API, persistence, workflow, rollout, or date behavior; normal daytime UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 scheduled/overdue behavior and deliberate UTC API semantics remain intact.
• [HUMAN] One normal main CI/CD deployment completes successfully after Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 clears, and On-Call records sanitized sandbox acceptance; no manual deployment substitutes for this gate.

Test Scenarios

Scenario: Task list opens on the seeded Berlin day

Given: the browser clock is fixed at the UTC-Jul-30/Berlin-Jul-31 boundary
When: task-list scenarios seed work for “today” and open the default task route
Then: the route and fixtures both use Jul 31 and every expected task row is present on the first attempt.

Scenario: Template title uses Berlin today

Given: the same fixed boundary
When: the template editor creates its default generated title
Then: the suffix is the Berlin date Jul 31, not the runner/UTC date Jul 30.

Scenario: Remaining default-SPA specs share the calendar

Given: accessibility, follow-up-actions, intake-inbox, and operations-smoke contain UI-facing current-date fixtures
When: they run at the fixed boundary
Then: their fixtures and browser expectations use the shared Berlin helper and pass without retry.

Scenario: Intentional UTC API coverage stays UTC

Given: an API spec deliberately validates UTC timestamp/date behavior rather than browser “today”
When: the default-SPA audit runs
Then: that documented API spec is excluded and its semantics remain unchanged.

Verification

Run from the repository root and record exit codes plus Playwright pass/flaky counts:

CI=true npm --prefix backend run test:e2e -- \
  e2e/template-editor.spec.js e2e/task-list.spec.js --retries=0
CI=true npm --prefix backend run test:e2e -- \
  e2e/accessibility.spec.js \
  e2e/follow-up-actions.spec.js \
  e2e/intake-inbox.spec.js \
  e2e/operations-smoke.spec.js \
  e2e/task-list.spec.js \
  e2e/template-editor.spec.js --retries=0
CI=true npm --prefix backend run test:e2e
npm --prefix backend test
npm --prefix backend run typecheck
npm --prefix backend run build
git diff --check

Add a focused automated static/source audit covering the default-SPA spec inventory and the shared-helper rule. Screenshots are unnecessary unless rendering changes beyond corrected dates/counts; this repair must not redesign the UI.

Out of Scope

• Roll out and cut over the Telegram conversational MVP #128 rollout controls, Playwright server environment/readiness, Telegram/provider behavior, or HUMAN canaries. Roll out and cut over the Telegram conversational MVP #128 remains open with its HUMAN criterion unchanged.
• Deliberate UTC API specs and server-side UTC timestamp semantics. Do not mechanically convert every Date or toISOString() use.
• The separate frontend/src application local-time-versus-Berlin gap; capture/handle that independently rather than expanding this pre-deploy repair.
• Re-designing UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 scheduled/overdue UX, changing stored schemas, or migrating persisted data.
• Workflow changes, broader E2E retry increases, sleeps, skipped assertions, AWS changes, or manual deployment.
• Source repositories outside DataTalksClub/dataops.

[alexeygrigorev]

GROOMED — AGENT READY

This is a separate test-determinism bug from #128. The minimal repair is confined to backend/e2e/bundle-detail.spec.js, backend/e2e/home-dashboard.spec.js, and optionally one shared E2E-only helper.

Product decision: bind each affected #106 scenario to one fixed test clock and explicit Europe/Berlin-local calendar basis before deriving seed dates or browser expectations. Prove the UTC/local-date divergence directly, run the two specs with retries disabled, then run the full suite in CI mode. Do not change production date semantics, weaken assertions, add sleeps/retries, or modify the deployment workflow.

This issue blocks #128 full CI verification, but it does not reopen #106 product behavior and must not absorb #128 test-server environment/readiness work.

[alexeygrigorev]

PM CORRECTION — production Berlin-date bug included

This supersedes the earlier “test-only/no production behavior change” constraint. Further diagnosis separates the two failures:

• bundle-detail.spec.js has a test UTC-versus-local expectation mismatch.
• home-dashboard.spec.js exposes a real UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 product defect: taskIsScheduled truncates bundle.createdAt to its UTC date while dashboard “today” uses a local calendar. During Europe/Berlin 00:xx with UTC still on the prior day, one -1 task equals the UTC creation date, so the new workflow reports eight scheduled tasks instead of nine.

The corrected agent-ready contract requires one explicit Europe/Berlin business-calendar formatter for both app “today” and instant-to-date scheduling comparisons, plus fixed-clock/time-zone E2E fixtures in both affected specs. The boundary regression must prove all nine pre-creation tasks are scheduled. Focused specs must pass with retries disabled and the full CI-mode E2E suite must pass without flaky recovery.

Scope remains narrow: no schema/data migration, workflow/AWS/#128 rollout change, broad date refactor, sleeps, skipped assertions, or retry increase.

[alexeygrigorev]

ARCHITECT / ASSISTANT ENGINEER SPECIALIST REVIEW — PASS

Reviewed the uncommitted five-path #134 candidate on base 9595361a0546a52a5cb90ace7df0bbdeb524866a. No edits, commit, push, workflow, or AWS action performed.

Architecture and behavior evidence:

• Production code defines one Europe/Berlin Intl.DateTimeFormat and routes both app today and bundle createdAt instant conversion through berlinBusinessDate.
• Date-only task validation stays separate from instant conversion. Impossible task dates and malformed/impossible creation timestamps fail closed to legacy active/overdue semantics; they are not classified as Scheduled.
• taskIsScheduled retains the narrow UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 contract: template + todo + valid task date + valid Berlin creation date + strict pre-creation comparison.
• The fixed boundary 2026-07-30T22:30:00.000Z explicitly proves UTC Jul 30 versus Berlin Jul 31. Both affected scenarios set the browser clock before fixture derivation/seeding/navigation and use the same Berlin date basis.
• The E2E GET override is scoped to /api/bundles and the one target detail path, passes every non-GET through without fetch/fulfill, changes only the target bundle in copied response JSON, and is removed in finally. API setup and cleanup use the separate request context, so the seam neither changes persisted state nor leaks into cleanup.
• Calendar-day offsets use date-only UTC arithmetic after Berlin conversion, avoiding DST-length arithmetic. Independent checks covered winter midnight, spring-forward, fall-back, and day offsets across both DST boundaries.

Independent verification:

• Focused backend source-contract test: 1/1 passed.
• Boundary E2E with retries disabled: 2/2 passed.
• Invalid task/bundle fallback E2E with retries disabled: 1/1 passed.
• Helper boundary/DST assertions: 11/11 passed.
• GET override scope/method/target/non-mutation assertions: 9/9 passed.
• git diff --check including the untracked helper: exit 0.

The first browser attempt inherited host provider configuration and correctly hit the existing #128 fail-closed rollout guard (two API 503 results). Re-running with the documented all-off conversational E2E environment passed; this is environment isolation outside the five #134 paths, not a #134 defect.

Candidate identity:

• Tracked binary diff SHA-256: d71ea569f26fbb41af2a2bbc624d6961bd27140f18182b82bf0dfadef47a164f
• Full patch SHA-256, tracked binary diff followed by the untracked helper no-index diff: 8b50ed5623e680b6224bc1e9fd6cd81eb65025bf36ab24b147b7ed9c4b89809c
• Paths: backend/src/public/app.js, backend/tests/home-dashboard.test.ts, backend/e2e/helpers/business-date.js, backend/e2e/bundle-detail.spec.js, backend/e2e/home-dashboard.spec.js

Specialist verdict: PASS. No architecture, date-safety, DST/calendar, portability, test-realism, or interception-boundary blocker found. Lifecycle Tester still owns the issue-required full E2E verification and PM owns final acceptance.

[alexeygrigorev]

TEST PASS

Formal Tester review of the final uncommitted #134 candidate on base 9595361a0546a52a5cb90ace7df0bbdeb524866a.

Candidate identity and scope:

• Use one Berlin business date in #106 scheduling and default-SPA E2E #134 five-file full patch SHA-256: 8b50ed5623e680b6224bc1e9fd6cd81eb65025bf36ab24b147b7ed9c4b89809c
• Combined Roll out and cut over the Telegram conversational MVP #128/Use one Berlin business date in #106 scheduling and default-SPA E2E #134 seven-path candidate: 4e69474a8557b36c964e6f6d2aaf06d56427311d6ae1276d59ff47280b17af1b
• Use one Berlin business date in #106 scheduling and default-SPA E2E #134 paths are exactly backend/src/public/app.js, backend/tests/home-dashboard.test.ts, backend/e2e/helpers/business-date.js, backend/e2e/bundle-detail.spec.js, and backend/e2e/home-dashboard.spec.js.
• Final checkout contains only the seven reviewed combined-candidate paths; no unexpected tracked or untracked file was present.

Acceptance evidence:

• Production frontend code declares one Europe/Berlin instant formatter and uses berlinBusinessDate for app today and bundle createdAt scheduling comparisons.
• Date-only task validation remains separate and fail-safe. Invalid task dates or malformed/impossible creation timestamps are not classified as Scheduled.
• Both affected UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 browser scenarios install the explicit Berlin timezone and fixed 2026-07-30T22:30:00.000Z clock before deriving fixtures or expectations. The test proves UTC July 30 versus Berlin July 31.
• The boundary dashboard scenario proves all nine pre-creation Newsletter tasks are Scheduled, not Overdue; the bundle-detail scenario uses the same calendar basis.
• The scoped GET response override is removed in finally, while non-GET setup/cleanup stays on the separate request context.

Commands and results, all exit 0 against the final fingerprint:

• Focused bundle-detail.spec.js and home-dashboard.spec.js boundary plus invalid-date fallback selection with all six parent rollout controls unset and --retries=0 — 3/3 passed, no flaky recovery.
• npm --prefix backend test — 1,359 total; 1,358 passed; 1 expected skip; 0 failed. This includes the focused frontend source-contract regression.
• npm --prefix backend run typecheck — PASS.
• npm --prefix backend run build — PASS.
• git diff --check plus no-index checks for both new files — PASS.
• CI=true npm --prefix backend run test:e2e under a deliberately hostile/missing parent rollout environment with no dark values supplied — 352/352 passed in 3.0 minutes. The final output reported no retry/flaky recovery; both affected scenarios passed on their first execution.

No unrelated UI, API, persistence, workflow, rollout, or date behavior was added. Screenshots are not required under the groomed issue because the existing UI is unchanged; this is a corrected business-date classification and deterministic fixture repair.

[alexeygrigorev]

PM ACCEPTED — exact five-file #134 candidate

I accept the #134 product and operator behavior on base 9595361a0546a52a5cb90ace7df0bbdeb524866a, after the specialist PASS and formal Tester PASS.

Accepted identity:

• Use one Berlin business date in #106 scheduling and default-SPA E2E #134 patch: 8b50ed5623e680b6224bc1e9fd6cd81eb65025bf36ab24b147b7ed9c4b89809c
• combined seven-path candidate: 4e69474a8557b36c964e6f6d2aaf06d56427311d6ae1276d59ff47280b17af1b
• paths: backend/src/public/app.js, backend/tests/home-dashboard.test.ts, backend/e2e/helpers/business-date.js, backend/e2e/bundle-detail.spec.js, and backend/e2e/home-dashboard.spec.js

Acceptance evidence:

• One explicit Europe/Berlin instant formatter now owns app “today” and bundle-creation business dates. Date-only task validation remains separate and malformed/impossible values fail safe.
• The fixed 2026-07-30T22:30:00.000Z boundary proves UTC Jul 30 versus Berlin Jul 31; all nine pre-creation Newsletter tasks remain Scheduled rather than leaking into due/overdue risk.
• Both affected UX: freshly-started workflows show all-red at t=0 — add scheduled/not-started state + richer bundle cards #106 browser scenarios install the Berlin timezone and fixed clock before fixtures or assertions. The GET-only response seam is scoped to the target bundle and removed in finally; persisted state and cleanup are unaffected.
• Focused boundary/fail-safe E2E passed 3/3 with retries disabled. Backend passed 1,358 with one expected skip; typecheck/build/diff checks passed. Full hostile-parent CI-mode E2E passed 352/352 in 3.0 minutes with no retry/flaky recovery.
• No unrelated UI, API, persistence, workflow, rollout, or date behavior changed. Existing UI needs no new screenshot.

All seven #134 acceptance checks are now checked. Status is PM accepted, awaiting commit/push and mandatory On-Call CI verification.

Commit instruction: stage exactly the five paths above first and commit with subject Fix Berlin business-date scheduling and E2E determinism and body Refs #134. Use Refs, leaving #134 open until the pushed full CI/On-Call result is green; then it may be closed. Do not include either #128 path in this commit.

[alexeygrigorev]

ON-CALL CI/CD — FAILED BEFORE DEPLOYMENT

Exact pushed SHA: fe030ad3b36e73df2542ca8c2bf42afa7ed3277e
Workflow: https://github.com/DataTalksClub/dataops/actions/runs/30589519557
Check job: https://github.com/DataTalksClub/dataops/actions/runs/30589519557/job/91028515288

Terminal evidence:

• checkout, dependency install, backend tests, typecheck, and build passed;
• full Playwright E2E failed: 344 passed, 8 failed after retries;
• SAM setup/validation/build were skipped;
• deploy job was skipped, so no application or AWS state changed.

The failures are deterministic calendar-basis gaps adjacent to #134:

• seven e2e/task-list.spec.js scenarios create/filter tasks with a Node-side local/UTC todayString() resolving to 2026-07-30, while the product now correctly opens the task view on the Europe/Berlin business date 2026-07-31; the seeded task rows are therefore absent;
• e2e/template-editor.spec.js:743 expects a default title ending in 2026-07-30, while the product correctly renders 2026-07-31 in Berlin.

This is not flaky recovery: all eight failed through both retries. Keep #134 open. Route the missed E2E date helpers/fixtures back through SWE, independent Tester, and PM acceptance; then push a reviewed repair and let normal CI retry. Do not rerun this unchanged SHA or deploy manually.