fix: snap period-start URL dates; fix Trends chart height and x-axis labels

[TimeToBuildBob]

Fixes for bugs found during v0.14.0 marketing screenshot generation (#1058).

Changes

Activity.vue — snap URL dates to period start

/#/activity/@all/year/2026-10-05 previously queried 2026-10-05→2027-10-05 because _date used the raw URL date. Now snaps to startOf(period) for week/month/year so arbitrary URL dates always produce canonical period-aligned queries. Week snapping honours startOfWeek: Saturday (moment's locale week start is Sunday).

TimelineBarChart.vue — fix height prop, x-axis labels, and y-axis scale

• Height prop ignored: height was not a declared prop (hardcoded to 330px), so :height="100" from callers (Trends, Report) was silently dropped. Added the prop with default 330.
• responsive/maintainAspectRatio misplaced: these were in chartData instead of chartOptions, so chart.js ignored them and the height prop had no effect. Moved to chartOptions.
• Multi-day x-axis labels: for multi-day periods (e.g. Trends 7/30/90-day), labels showed 1, 2, ..., N or hour ticks; now shows actual month-day dates when timeperiod_start is provided.
• Y-axis scale for multi-day: suggestedMax: 1 (1 hour) and fine step size were incorrectly applied to multi-day periods where daily totals can reach 12+ hours. Now only applied for single-day views.

Trends.vue — pass timeperiod props to barchart

Passes currentStart and [periodDays, 'days'] so the barchart can compute correct date labels and scale. Also sets a reasonable height (200px).

Remaining items from #1058

• Work report host select — fixed on master by fix(work-report): name hosts by bucket hostname and query their real bucket ids #1067
• Timeline row label format inconsistency
• Dark theme stripe and color contrast
• Minor: browser apps uncategorized, sunburst label clipping, multi-device note, category palette

Fixes #1058 (partial)

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Fixes date snapping and chart display in activity and trends views.

The PR appears safe to merge; no new actionable issues remain.

What we checked:

• Language shifts the selected week: periodStartDate calculates the boundary from startOfWeek. Both URL dates and period switching call it, so the language no longer chooses the first weekday.

Summary

The PR aligns Activity dates with calendar periods and fixes Trends chart sizing, date labels, and scale.

• The latest change shares periodStartDate across URL dates and period switching.
• Week boundaries now follow startOfWeek, independent of language.
• Tests cover all three week starts in English and German.
• All six earlier threads were rechecked. Their concerns are addressed or were correctly withdrawn; none supplied a comment number.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  URL[Activity URL date] --> Snap[periodStartDate]
  Switch[Period switch] --> Snap
  Setting[Configured week start] --> Snap
  Snap --> Date[Calendar start date]
  Date --> Offset[Apply day-start offset]
  Offset --> Query[Activity query period]

Loading

_{Reviews (6) · Last reviewed commit: "fix(activity): snap weeks to the configu..."}

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

@greptileai review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.45%. Comparing base (ac2c277) to head (b2c7916).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1059      +/-   ##
==========================================
- Coverage   64.58%   64.45%   -0.13%     
==========================================
  Files          55       55              
  Lines        3803     3821      +18     
  Branches      963      963              
==========================================
+ Hits         2456     2463       +7     
+ Misses       1332     1268      -64     
- Partials       15       90      +75     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[TimeToBuildBob]

CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click.

This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted.

[TimeToBuildBob]

Rebased onto master (now at #1068). The conflicts needed real choices:

• TimelineBarChart.vue: kept master's clamp_hourly prop and the clamped datasets from fix(timeline): clamp hourly bar stacks to 1h (fixes y-axis > 1h) #1021, and kept this PR's height prop. responsive/maintainAspectRatio stay in chartOptions.
• workReport.ts: dropped this PR's host-select commit and its AFK-matching follow-up, plus that follow-up's regression test. fix(work-report): name hosts by bucket hostname and query their real bucket ids #1067 replaced the same code with hostname grouping and real bucket ids. That made the synced-AFK test wrong: on master, a synced AFK bucket does make the host selectable, which is correct.
• The Saturday week-snap fix in Activity.vue is kept, now as its own commit.

The PR now touches only Activity.vue, Trends.vue and TimelineBarChart.vue. Unit tests: everything passes except 4 in validate.test.node.ts, which this PR doesn't touch. CI is re-running on 15668bb.

[ErikBjare]

@greptileai review

[TimeToBuildBob]

@greptileai review

[ErikBjare]

@TimeToBuildBob conflicts

[TimeToBuildBob]

Confirmed the conflict with current master. Another Bob session already holds the branch and has fresh local conflict-resolution work; I'm coordinating that handoff rather than racing a second push. I'll verify the resulting diff and tests before reporting the updated head.

[TimeToBuildBob]

Conflicts are cleared: the branch owner rebuilt this on current master as 741d01f, and GitHub now reports it mergeable. I independently checked the resulting diff; the existing week-start helper and its tests are preserved.

The check also caught two chart fixes described above that were missing from the rebuilt diff: responsive/maintainAspectRatio were still in chartData rather than options, and multi-day charts still used the single-day scale/tick settings. I reproduced both with failing tests and prepared the correction in b2c7916: this commit is on fix/pr1059-chart-options-881d, not yet on this PR's branch. I've handed it to the active branch owner for integration rather than racing another push.

Focused chart/timeperiod tests: 32 passed; ESLint and commit hooks passed. The full local suite has 565 passing tests and four failures caused by the shared dependency install missing @unicode/unicode-13.0.0/Names; CI on 741d01f is still queued. Please don't treat this as the final merge-ready verdict until the correction is integrated and CI completes.

[TimeToBuildBob]

Integrated the pending chart correction into this PR's branch: head is now b2c7916, and GitHub reports it mergeable. No force-push was needed; the conflict-resolution commit and master's week-start/clamping changes are preserved.

Verification: 32 chart/timeperiod tests passed, ESLint passed, and the production Vite build passed after preparing the media assets. The full local suite still has the same four missing-Unicode-dependency failures (565 tests pass). Fresh CI is pending; the old Greptile 5/5 is for the previous head, not this revision.

[TimeToBuildBob]

🤖 AI code review

Safe to merge — 1 P1 disposed (rejected)

_{Updated after inline dispositions on finding threads — this is the current state; the verdict below is frozen at review time and is kept as the historical record of that pass.}

Finding disposition

Finding	Severity	State
src/views/Trends.vue:59	P1	rejected — The verification says "For timezones behind UTC, the date will be shifted back one day. Checked the timezone logic with
test/unit/timelineBarChart.test.node.ts:16	P2	rejected

This PR fixes several issues in the Activity and Trends views and the TimelineBarChart component. It adds a height prop to TimelineBarChart, moves responsive/maintainAspectRatio from chartData to chartOptions, changes the y-axis scale logic to only apply single-day settings for single-day charts, and updates the month-resolution label formatting. It also snaps URL dates to period starts for week/month/year in Activity.vue, and passes timeperiod props from Trends.vue to the barchart. A new unit test file for TimelineBarChart options is added.

Not safe to merge — 1 P1 open

Confidence 3/5

1 finding · ❌ 1 P1

❌ P1 high — src/views/Trends.vue:59

In Trends.vue, the barchart is now passed :timeperiod_start="currentStart.toISOString()". currentStart is a moment object representing the start of the current period, which is today - (periodDays - 1). The timeperiod_start prop is a String, and toISOString() returns an ISO string with timezone offset, e.g., '2024-01-01T00:00:00.000Z'. In TimelineBarChart.vue, the labels computed for the 'day' resolution with count > 1 does const date = new Date(start); where start is this ISO string. new Date('2024-01-01T00:00:00.000Z') creates a Date in UTC, but the local timezone may be different. Then it does date.setHours(12, 0, 0, 0) which sets the local hours to 12, but the date may be off by one day if the timezone is behind UTC. For example, if the user is in UTC-5, new Date('2024-01-01T00:00:00.000Z') is 2023-12-31T19:00:00-05:00. Setting hours to 12 gives 2023-12-31T12:00:00-05:00, which is still Dec 31. Then date.setDate(date.getDate() + d) adds days, so the labels will be off by one day. The timeperiod_start should be a local date string like '2024-01-01' or a moment object, not an ISO string with timezone. The PR description says 'snap period-start URL dates' but this is about the Trends view. The currentStart is a moment object, and toISOString() converts to UTC. The labels computed uses new Date(start) and then sets hours to 12, which is a common pattern to avoid timezone issues, but it assumes the start is a local date string. Using an ISO string with timezone breaks this assumption. This is a bug because the x-axis labels will be shifted by one day for users in timezones behind UTC. The fix is to pass currentStart.format('YYYY-MM-DD') or a local date string.

Use `currentStart.format()` or `currentStart.toDate().toISOString()`? Actually, better to pass the local date string like `currentStart.format('YYYY-MM-DD')` and have the component parse it as local. Or change the component to use `new Date(start + 'T12:00:00')` to avoid timezone issues.

_{How this was verified: Traced the timezone handling: currentStart is a moment in local time, toISOString() converts to UTC. The labels computed in TimelineBarChart uses new Date(start) and setHours(12) in local time. For timezones behind UTC, the date will be shifted back one day. Checked the timezone logic with a concrete example.}

_{Consensus: 3/3 passes agreed}
Distinct keys: 1 (general)

Files changed (4) — the diff as I read it

• src/views/Trends.vue — Passes timeperiod_start and timeperiod_length props to the barchart, and sets height to 100.
• src/views/activity/Activity.vue — Snaps _date to period start for week/month/year using periodStartDate.
• src/visualizations/TimelineBarChart.vue — Adds height prop, moves responsive options to chartOptions, changes y-axis scale logic, and uses format_date_short for month labels.
• test/unit/timelineBarChart.test.node.ts — Adds unit tests for chartOptions and chartData computed properties.

Previous review passes

commit	score	findings	engine	when
b2c791667f80	4/5	1	llm	2026-10-07 13:23 UTC
b2c791667f80	5/5	0	llm	2026-10-09 04:49 UTC

_{Reviewed b2c791667f80 · openrouter/deepseek/deepseek-v4-flash-0731 · llm engine · 156s · about this reviewer}

_{Maintainer commands}

_{@TimeToBuildBob review (own line) — fresh review · @TimeToBuildBob fix — a worker acts on the findings. Once per comment; 👀 = received.}