[JSdotNet]

Summary

Refs #743. This is the second slice of step 2: one more module's settings move out of the shell. #805 moved the Inbox, and this moves the Dashboard's weekly usage reset. #743 stays open for the remaining modules, so this uses Refs, not Closes.

What could not be proved — read this first

• One user-visible change, by design. Until now the usage reset sat on the always-present Storage tab. It now has its own Dashboard tab, after Inbox, and that tab shows only while the Dashboard feature switch (Dev status) is on. Decide whether that gating is what you want. To keep it reachable at all times, pass null as the section's feature key instead.
• The rendered settings UI. Open /settings in the desktop web harness (and ideally the MAUI desktop app) and check four things:
  1. The Storage tab's working-week card no longer shows Weekly usage reset, and its note names only the working-hours file.
  2. With the Dashboard feature on, a Dashboard tab follows Inbox. It holds the reset day select, the time field, the status and the Back to detecting it button, styled as before.
  3. Setting a day and a time persists to usage-reset.json, and the dashboard's weekly columns follow it.
  4. With the Dashboard feature off, the tab is gone.
• Three criteria are properties of the diff, not tests:
  • Settings.razor lost the IUsageResetSettings inject and the members. A grep checks this; the rendered markup is tested.
  • Backlog.Modules.Dashboard.UI gains no project reference.
  • MauiProgram.cs, the harness Program.cs, DesktopCompositionRegistration.cs and every Devbook file are unchanged. That keeps this PR clear of refactor(devbook): register the module once and share one path helper #933.

Changes

• New src/Modules/Dashboard/Backlog.Modules.Dashboard.UI/Settings/DashboardSettings.razor. Its markup, data-testids, copy and @code are moved unchanged from Settings.razor. Its own private HH:mm helpers are named FormatTime/TryReadTime.
• New Extensions/DashboardSettingsRegistration.cs. AddDashboardSettings() registers SettingsSection("dashboard", "Dashboard", 200, typeof(DashboardSettings), DashboardFeatures.Dashboard), and AddDashboardUi() calls it. Both hosts get the section through the shared composition, so no host file changed.
• Settings.razor loses the usage-reset inject, markup, SyncUsageResetDraft() and members, about 120 lines. Its Storage note now names only WorkingWeek.SettingsPath.
• Modules still in Settings.razor:
  • Tasks: the GitHub accounts and the repositories list.
  • Devbook: the snapshot folder and the per-repository source.
  • Sync: Devices.
  • Dashboard: the activity-cache row and the usage-metrics credentials. Both are infrastructure stores.
  • Roadmap/productivity: the working week. ADR 0019, which is proposed, would make it Roadmap's.

Acceptance criteria

#	Criterion	Verified by
1	Settings.razor no longer holds the usage reset	Partly by test: DashboardSettingsTests.The_storage_tab_no_longer_carries_the_usage_reset. The removed members are checked by grep only.
2	DashboardSettings.razor renders the reset with the same data-testids, copy and note	DashboardSettingsTests
3	Exactly one SettingsSection, ordered after Inbox, behind DashboardFeatures.Dashboard, reached through AddDashboardUi	DashboardUiRegistrationTests.The_pane_registers_its_settings_page_after_the_inbox_behind_the_dashboard_switch, WebHarnessHostTests.The_desktop_harness_registers_the_dashboard_settings_section_through_the_shared_composition
4	Dashboard tab after Inbox when on, absent when off	DashboardSettingsTests.With_the_dashboard_on_…, With_the_dashboard_off_…
5	Behaviour unchanged (day, time, malformed time, clearing)	four DashboardSettingsTests
6	The working week stays on Storage; its note names only its file	SettingsWorkingHoursTests
7	No new project reference	the diff
8	No host, composition or Devbook file touched	the diff
9	Builds clean, tests green	below

Testing

dotnet build Backlog.sln
dotnet build Backlog.WithoutAppHeads.slnf --configuration Release -p:TreatWarningsAsErrors=true --no-incremental
dotnet test --solution Backlog.WithoutAppHeads.slnf --no-build --configuration Release --max-parallel-test-modules 1 --parallel none

• Builds: 0 warnings and 0 errors for both. The full Debug solution build includes the Desktop and Android heads.
• Tests: 10,770 passed, 0 failed, 1 skipped. The skip is the AppHost-only ConferenceDayTests.
• Repair attempts: 0.
• One earlier flake: in an earlier full Debug run, SearchBoxTests.Typing_reports_the_query_once_the_debounce_has_elapsed hit a debounce timeout. That test is in a project this change does not touch, and the project passed 2,723 of 2,723 when re-run alone.

Review

Two lenses ran and found no blocker or major issue. Two minor findings are left open:

• DashboardSettings.razor:9: the header comment copies the Inbox's "shadowing" reason for the root namespace. That reason does not hold here. Reword the comment, or use the …Dashboard.UI.Settings folder namespace.
• SettingsWorkingHoursTests.cs:182 repeats the "no usage reset on Storage" assertion that DashboardSettingsTests already makes.

Assumptions

These were taken instead of asking:

• The slice is the Dashboard-owned usage reset, not the working week. ADR 0019 contests the working week.
• AddDashboardUi() registers the section, rather than a separate call in DesktopCompositionRegistration.cs as the Inbox does. This keeps the composition untouched while refactor(devbook): register the module once and share one path helper #933 rewrites it.
• The section is gated behind DashboardFeatures.Dashboard, as the Inbox section is gated behind its own switch.
• No devbook edit. .devbook/domain/productivity/context.md says the reset is set "on the settings screen", which is still true.

Checklist

• Scope is focused and excludes unrelated changes
• Documentation or instruction files were updated when governance or behavior changed. Not needed; see the last assumption.
• Running Aspire instances for this checkout were stopped before PR creation. No Aspire run was started.
• Follow-up work is captured when the implementation is intentionally partial. The remaining modules stay on Split Settings.razor into per-module settings sections #743.
• Issues this PR closes are linked with a closing keyword, or there are none. It closes none: it is partial, so it uses Refs #743.

---

An unattended run of delivery-schedule:schedule-issue-sweep (2026-10-02) opened this pull request as a draft. Validate it by hand before marking it ready.

🤖 Generated with Claude Code