diff --git a/.gitignore b/.gitignore
index 9912f41615..a125dafc9f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,6 +5,7 @@
.DS_Store
build/
dist/
+coverage/
bin/
node_modules/
vendor/
@@ -13,6 +14,7 @@ vendor/
tmp.scss
.tscache
a.env
+.env
dist/
.angulardoc.json
.nx
diff --git a/.prettierignore b/.prettierignore
index d541041bd2..2b82fb1787 100644
--- a/.prettierignore
+++ b/.prettierignore
@@ -7,9 +7,5 @@ e2e
CHANGELOG.md
JPlag-Report-Viewer/
.github/
-karma/
-Gruntfile.js
-karma.conf.js
polyfills.ts
-test.ts
main.ts
diff --git a/angular.json b/angular.json
index 029aa7eafc..6c5694d24c 100644
--- a/angular.json
+++ b/angular.json
@@ -79,7 +79,7 @@
}
],
"optimization": true,
- "outputHashing": "bundles",
+ "outputHashing": "all",
"sourceMap": false,
"extractLicenses": true,
"serviceWorker": "ngsw-config.json"
@@ -87,7 +87,8 @@
"development": {
"optimization": false,
"extractLicenses": false,
- "sourceMap": true
+ "sourceMap": true,
+ "serviceWorker": "ngsw-config.json"
},
"testing": {
"aot": false,
diff --git a/docs/ISSUE-1290-testing-strategy.md b/docs/ISSUE-1290-testing-strategy.md
new file mode 100644
index 0000000000..c28b993de1
--- /dev/null
+++ b/docs/ISSUE-1290-testing-strategy.md
@@ -0,0 +1,130 @@
+# Vitest coverage and next integration checks (#1290)
+
+This records the September 2026 test audit for
+[doubtfire-web #1290](https://github.com/doubtfire-lms/doubtfire-web/issues/1290).
+The application uses Angular's unit-test builder with Vitest, a jsdom environment,
+and the setup file in `src/vitest-setup.ts`. The normal pull request suite does not
+require a running API, browser installation, production account, or secrets.
+
+## Running the checks
+
+Use the Node version in `.nvmrc` (Node 22.22.3 or later in the supported Node 22
+line), then run:
+
+```sh
+npm ci
+npm run test:ci
+npm run build
+```
+
+For a focused iteration, keep Angular's compilation step and select the spec:
+
+```sh
+npm run test:ci -- --include='src/app/common/file-downloader/file-downloader.service.spec.ts'
+```
+
+Run the whole suite before opening a PR. A focused run cannot detect interactions
+with module registration, template compilation, or the rest of the application's
+shared fixtures. Existing GitHub `Test CI` and `Node.js CI` workflows run the full
+unit suite and application build on pull requests.
+
+## Recorded validation
+
+On the FL-22 / #1290 branch based on `11.0.x` commit `a35f2826d`, a clean
+`npm ci`, `npm run build`, and the full `npm run test:ci` passed with Node 22.23.2.
+The suite contains 146 files and 1107 passing tests. Targeted ESLint also passed.
+The runner reports an existing nested `vi.mock` warning in the PDF viewer spec;
+it is not a test failure. These results cover this branch, not future merges or
+the longer-term browser/API jobs below.
+
+## Gaps addressed
+
+The audit found 143 existing spec files under `src/app`. The new tests focus on
+observable behaviour in shared code that previously had no dedicated tests:
+
+| Area | Regression checks | Defect caught |
+| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| File downloader | Complete and multipart responses, requested byte bounds, missing/malformed ranges, gaps/duplicates, changing totals, interrupted transfers, and a server ignoring Range | Invalid ranges could leave the caller waiting or publish corrupt data; continuation end indexes were one too large; a full response was appended to already received bytes |
+| Authentication interceptor | API and LTI credentials, anonymous requests, external/static requests, preservation of caller headers and immutable requests | These cases now protect the shared request boundary |
+| Authentication return URL | Blocked browser storage, malformed persisted entries, future timestamps, exact expiry boundary, and one-use consumption | Extends existing unsafe URL, SSO, logout, and expiry checks |
+
+The downloader tests use `HttpTestingController` to assert the real `HttpClient`
+request and response contract, without reaching an actual server. They verify the
+assembled Blob contents rather than only checking that a callback ran. Every
+case verifies no unmatched requests remain. The auth tests use harmless fixture
+tokens and exercise the interceptor/service's public methods.
+
+## Remaining coverage to prioritise
+
+This is a risk-based audit, not a claim of complete statement or branch coverage.
+Add tests with each change rather than treating creation-only specs as evidence
+that every interaction works.
+
+1. **Authentication refresh concurrency:** several simultaneous expired requests,
+ failed refresh releasing every waiting subscriber, retry headers, and logout
+ while a refresh is in flight. `HttpErrorInterceptor` currently has error-body
+ extraction coverage but needs these stateful scenarios.
+2. **Submission state transitions:** combine the upload modal, processing/retry API
+ response, and selected task route to show that failed uploads retain the user's
+ context and a successful upload returns to the intended dashboard.
+3. **Staff workflows:** task-sheet navigation, tutorial changes, bulk portfolio
+ operations, and permission refusals. Prefer DOM events and rendered state over
+ direct calls to private component methods.
+4. **Real browser behaviours:** focus restoration, drag/drop, recorded audio,
+ actual CSS breakpoints, Blob downloads, and service workers. jsdom does not
+ establish visual layout, accessibility, or browser permission behaviour.
+5. **API compatibility:** serialization of deadlines, extensions and upload errors
+ across the web/API boundary. A frontend mock cannot prove the server emits the
+ expected data or enforces permissions.
+
+## Longer-term API test approach
+
+Keep deterministic frontend contract tests in the normal Vitest suite using
+[`provideHttpClientTesting` and `HttpTestingController`](https://angular.dev/guide/http/testing).
+Assert request methods, authorization conditions, query/body formats, and error
+responses; do not simply return whatever object the component expects. Keep
+fixture payloads near the consuming feature and link the corresponding API
+endpoint/regression test in its PR.
+
+Add a separate integration CI job for contracts that require the real API. Boot
+pinned web/API/deploy revisions against an isolated disposable database, run
+migrations and a small deterministic seed, wait for readiness, then authenticate
+through the same endpoints used by the client. Use two fixture students and a
+staff member in distinct units to test both allowed requests and cross-user
+refusals. Run API model/request tests in the API repository as well; frontend
+integration checks supplement them. Tear down the database after each job and
+avoid production credentials or public notification delivery.
+
+Start with three contracts: loading a student's enrolled units; reading the same
+task's actual effective deadline; submitting a small fixture file and polling its
+processing status. Add an explicit assertion for each relevant 4xx error. This
+job should have its own failure report so an API startup failure is not presented
+as a frontend assertion failure.
+
+## Longer-term headless browser approach
+
+Use two separate layers with a documented purpose:
+
+- **Browser component tests:** Angular supports
+ [Vitest browser mode](https://angular.dev/guide/testing) for interactions requiring
+ a real DOM/browser. Pilot focus and download behaviours before moving large
+ numbers of otherwise fast jsdom tests.
+- **Student journey tests:** a Playwright suite against the built application.
+ Its [`webServer` configuration](https://playwright.dev/docs/test-webserver) can
+ manage an isolated local server. For fast PR checks,
+ [route mocks](https://playwright.dev/docs/network) should cover login, loading a
+ unit, selecting a task, submitting a file, and the resulting dashboard state.
+ Add failures for rejected credentials, unavailable units, and failed uploads.
+ Start with Chromium, then add Firefox/WebKit for browser-specific controls.
+
+The real API job should reuse the same journeys without route mocks, against the
+seeded stack. Keep mocked and real API runs explicitly named; passing a mocked
+journey does not prove server compatibility. Use role/name locators and web-first
+assertions rather than fixed sleeps. Store a trace/screenshot only on failure,
+redact test authorization headers, and keep fixture users' data synthetic. A
+service-worker-specific test must run separately from tests that block service
+workers for reliable network interception.
+
+These longer-term jobs are an investigated implementation plan, not new CI
+requirements in this PR. They need their own pinned runtime fixtures and review
+before becoming required checks.
diff --git a/docs/cross-project-ui.md b/docs/cross-project-ui.md
new file mode 100644
index 0000000000..f71bcf92e6
--- /dev/null
+++ b/docs/cross-project-ui.md
@@ -0,0 +1,68 @@
+# Cross-project UI handover
+
+Tickets: CPD-FB02, CPD-FB03, CPD-UI03–06, PR-XU-12, PR-XU-13 and PR-XU-20.
+The API's projects logging and access-control tests are maintained separately.
+Calendar features are unchanged.
+
+## Feedback and filtering
+
+`has_feedback` maps to `Task.hasFeedback`. `true` means staff feedback exists;
+`false` means none exists; missing metadata stays unavailable. No feedback body,
+marker note or additional student identity is fetched for a card. The unread
+comment count is separate: it cannot establish whether staff feedback is new.
+The UI therefore labels it **unread comments**, never **new feedback**.
+
+The Staff feedback selector combines with status, grade, date range and the
+existing global/per-unit searches. Search includes the displayed phrases
+`staff feedback available`, `no staff feedback`, `feedback unavailable`, and
+`unread comments` where applicable. Searching just `feedback` can match any of
+these states; use the selector to ask specifically for available feedback.
+Clear all restores all feedback states while preserving per-unit controls.
+
+The Staff feedback action navigates to
+`/projects/:projectId/dashboard/:abbreviation/feedback`, which opens the existing
+feedback pane on narrow screens even after comments have been read. The normal
+task title links to task details. Neither route bypasses API authorisation.
+
+## Layout, controls and recovery
+
+The grid wraps cards in DOM order using a minimum bounded by the available width.
+Project name, task completion count, deadline warning and project link remain
+available in phone summaries. Comfortable/compact density changes spacing,
+not data. Long names wrap. Task controls and focus outlines retain their size.
+
+The local `panelState` template accepts `title`, `message` and optional `busy`.
+It gives each panel a named section, minimum height and polite status text.
+Use plain messages without response bodies or stack traces. Active units,
+previous units and recommended order have separate busy/error state. Failed
+refreshes retain the last successful data; initial empty results get explicit
+messages. Refresh buttons remain mounted and keyboard-focusable while busy,
+use `aria-disabled`, and guard repeat activation in their handlers.
+
+Active projects initially come from the application's global loading contract.
+The dashboard does not replace the app's sign-in/bootstrap error handling.
+Previous projects use a separate cache so loading history cannot contaminate
+the active project cache. All component-owned requests stop on destruction.
+
+Filter/sort menus use native buttons with checked states. The result count is
+announced in one polite live region; input focus remains on the control that
+changed the results. Phone disclosures retain their toggle and `aria-expanded`.
+Count badges use the existing `#3939ff` token with white text (6.56:1 contrast),
+and explicitly name the count and task. Unread comments are not exposed as an
+unexplained digit.
+
+## Validation
+
+Use synthetic projects for browser checks at 320, 390, 768, 1024 and 1440 px,
+in both density modes, with long names and enough tasks to scroll. Exercise
+available/no/unavailable feedback, no matches, empty units, previous-unit
+failure/retry, and a failed refresh with existing data. Tab through every
+control; open filters with the keyboard; verify focus survives refresh. At
+200% zoom check wrapping and the continued availability of the project link.
+
+The focused component tests cover combined filters, missing metadata, actual
+task/feedback hrefs, stale data and recovery, duplicate refresh suppression,
+focus retention, counts and density. Route tests cover student access and
+scope restoration. Browser, test and build results for this change are recorded
+in the [validation record](evidence/cross-project-ui/README.md) and PR. Real screen-reader sign-off remains
+a reviewer activity; automated accessible-name assertions do not claim it.
diff --git a/docs/cross-unit-dashboard.md b/docs/cross-unit-dashboard.md
new file mode 100644
index 0000000000..9648e4f317
--- /dev/null
+++ b/docs/cross-unit-dashboard.md
@@ -0,0 +1,36 @@
+# Cross-project dashboard
+
+The student-only `/dashboard` route shows authorised tasks across active and
+previous units. It supports combined unit/task search, status, grade, date and
+staff-feedback filters, task ordering, and direct project/task/feedback links.
+
+The dashboard was ported from the old 10.x cross-unit branch onto 11.0.x and
+translated from UI-Router to Angular Router. It is now implemented and tested
+on `11.0.x`; the original root-level skeleton status is retired.
+
+## Sources and verification
+
+- `src/app/dashboard/f-cross-dashboard.component.{ts,html,scss}` owns mapping,
+ filters, grid, density and panel states.
+- `src/app/dashboard/list-item/` owns task rows and expanded actions.
+- `src/app/app.routes.ts` owns student route access and feedback destinations.
+- `src/app/projects/states/index/global-state.service.ts` loads active projects;
+ `ProjectService` requests previous units with task definitions in a separate cache.
+- The API's `GET /projects` scopes project/task metadata to the authenticated user.
+
+Run `npm run test:ci -- --include='src/app/dashboard/**/*.spec.ts'` using the
+repository's Angular Vitest builder. See [UI handover](cross-project-ui.md) for
+current validation results, state behaviour and feedback semantics. Review
+[privacy-safe evidence guidance](CPD-Q06-privacy-safe-screenshot-checklist.md)
+before capturing examples.
+
+## Sample data
+
+These values are entirely synthetic and are intended only as a visual reference for dashboard
+mockups. They are not an API schema or an automated-test fixture. Dates use `DD/MM/YYYY`.
+
+| Unit code | Example task due date | Unit completion | Example task status |
+| --------- | --------------------- | --------------- | ------------------- |
+| COS10001 | 17/10/2026 | 10% | `not_started` |
+| COS20007 | 19/08/2026 | 100% | `complete` |
+| COS30046 | 25/08/2026 | 90% | `working_on_it` |
diff --git a/src/app/account/edit-profile/edit-profile.component.html b/src/app/account/edit-profile/edit-profile.component.html
index 43c2d6788c..6fb40b647e 100644
--- a/src/app/account/edit-profile/edit-profile.component.html
+++ b/src/app/account/edit-profile/edit-profile.component.html
@@ -1,9 +1,13 @@
-