Feature/ppi data adapter

[David-Tenni]

Description

Adds the unit-level PPI data adapter layer, typed interfaces, a state resolver, and a service method — extending Gurwinder's existing task-level PeerProgressIndicator contract rather than replacing it. Gives the UI a stable boundary between backend data and display logic for unit-level peer progress, so a future unit-level visual component (PPI-F02) can consume typed data without wiring its own API/mock handling.

Fixes PPI-F01

Missing API field, documented per acceptance criterion 5: no real unit-level aggregate endpoint exists yet — getUnitSummary() is mock-only, same situation as the existing task-level service. Smallest reasonable backend follow-up: a GET endpoint returning the six-state-shaped cohort aggregate scoped by unitId + targetGrade (no taskDefinitionId), plus the caller's own studentPercentage computed server-side from that student's actual task completions — this specific field can't be meaningfully mocked, since it depends on real per-student data the frontend must never compute itself.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

21/21 passing, run twice. A pre-existing, unrelated file (peer-progress-indicator-state.spec.ts) hit the already-documented Vitest forks-pool timeout once during a full-suite run; confirmed unrelated by pairing it with a different file and getting a clean pass. npm run typecheck: clean. npx eslint on all touched files, --max-warnings 0: clean.

Testing Checklist:

• [ X] Tested in latest Chrome

• [ X] Tested in latest Firefox

(Not applicable — this PR is adapter/interface work only, no UI or visual component touched, per acceptance criterion 6.)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• [ X] I have requested a reviews from team members

[Clupai8o0]

Both of these are aimed at a base that cannot review them, and it is worth fixing before either gets any older.

thoth-tech/doubtfire-web development was last touched on 2026-06-04 and is 1,481 commits behind 11.0.x with nothing unique on it. Our branches descend from the 11.0.x line, so the diff GitHub renders is the entire Angular 17 to 22 migration plus your work. That is why #509 shows 1,113 files for what is a 649 line documentation change, and #513 shows 1,123 files for a 345 line adapter. Nobody can review that, which is why both have sat with zero reviews since 18 August.

This is the exact shape that closed all fifteen of our upstream PRs in T1, and it closed one of ours in the org this trimester too (doubtfire-web#8, +68930/-43235 across 1108 files into development).

Retargeting at Feature/Peers-Progress does not fix it, which I checked before suggesting it. That branch is 603 commits behind 11.0.x and its merge base with both of your heads is chore(release): 10.0.1-22 from March. It is stranded on the 10.0.x line. So neither existing thoth-tech branch is a viable base.

What that leaves:

1. A Feature/* branch on thoth-tech/doubtfire-web cut from current 11.0.x has to be asked for. The notifications stream hit the same wall, so this is one ask covering both.
2. Promote from origin/feature/peer-progress-indicator rather than from an individual work branch. Both of these are opened from docs/ppi-help-privacy and feature/ppi-data-adapter directly, which means they carry other contributors' PPI work uncredited and omit what has merged since. In particular Feature/ppi data adapter #513 promotes a version of peer-progress-unit-summary-state.ts that the org corrected on 20 August, with a spec asserting the superseded behaviour.

Two smaller things while these are open.

The CI is not missing, it is waiting on someone. Both head branches have workflow runs sitting at action_required, which is thoth-tech's approval gate for a run from an outside contributor. Somebody there has to click. Until then the "21/21 passing, run twice" line in #513 has no independent evidence attached, which is a lot to ask of a reviewer looking at 1,123 files.

#513's body names getUnitSummary(). No such symbol exists on the branch. The method is getMockUnitSummary(), which is the better name and the one the "mock-only" caveat should point at.

Happy to help get the branch request in, it is the same conversation for notifications.