Team Evidence Store and UI

[sawankshrma]

Description

• Adds an EvidenceStore.ts to let users record that activities have been completed. Evidence is stored separately from progress in localStorage.

• Also adds the UI changes disscussed in the issue to add and view evidences.

• Report Page is modified too, to contain and view the evidences.

  Refer to comments after dc3b309 (Team Evidence Store and UI #501 (comment)) for UI related changes/disscussions.

Format:

evidence:
  11111111-1111-1111-11111111111111111:
    - id: 9d7c1b0e-5a0d-4c13-a8e6-2b9e0d8a7c11                       # Added in edit
      teams: ["Team A", "Team B"]
      title: Example Evidence 1
      evidenceRecorded: 2024-01-15
      reviewer: reviewer-123
      description: This is an example piece of evidence.
      attatchment:
        - type: document
          externalLink: https://example.com/evidence1.pdf
    - id: 9d7c1b0e-5a0d-4c13-a8e6-2b9e0d8a7c12                        # Added in edit
      teams: ["Team C"]
      title: Example Evidence 2
      evidenceRecorded: 2024-02-15
      reviewer: reviewer-123
      description: This is a second example piece of evidence.
      attatchment:
        - type: document
          externalLink: https://example.com/evidence2.pdf
  22222222-2222-2222-2222-222222222222:
    - id: 9d7c1b0e-5a0d-4c13-a8e6-2b9e0d8a7c13                       # Added in edit
      teams: ["Team A", "Team B"]
      title: Example Evidence 3
      evidenceRecorded: 2024-02-15
      reviewer: reviewer-123
      description: This is evidence for another activity
      attatchment:
        - type: document
          externalLink: https://example.com/evidence2.pdf

What's New?

• evidence-store.ts — new store with add, update, delete (by id), merge, rename team, import/export functions.
• team-evidence.yaml — empty placeholder for YAML-based evidence.
• wired EvidenceStore into the existing DataStore.

---

• Follows existing pattern of existing progress-store.ts.
• Design Choice:- Evidence is stored separately from progress in the localStorage as a separate key for simplicity purpose (atleast for now). This, can be reverted back to the same key with two blobs (as in the issue), in follow-up UI PRs. I leave this decision for the maintainers.

Resolves (Partially) : #496

[vbakke]

At first glance this looks good. But how do you execute the code? I didn't see how to initialize anything? Do you read the yaml file, or from localStorage?

[sawankshrma]

At first glance this looks good. But how do you execute the code? I didn't see how to initialize anything? Do you read the yaml file, or from localStorage?

Earlier, I was trying to mimic the structure of the ProgressStore class mainly to show the intended data format.

• Now with 4bf1a80 , evidence is initialized during the LoaderService bootstrapping, similar to ProgressStore. Evidence is loaded from the YAML file and subsequently hydrated from localStorage.

• Currently, with change in the isDuplicateEntry function in this commit, merge strategy is “first writer wins”: YAML evidence is loaded first, and entries from localStorage with the same id are treated as duplicates and therefore ignored, no matter it's contents.

I don't know if this is the approach/merge-strategy we should go for. So I would genuinly like your opinion here @wurstbrot , @vbakke.

1. Should each EvidenceEntry have a stable UUID?
2. If so, what merge semantics should we apply when the same id exists in both YAML and localStorage (e.g., override, skip, or conflict resolution)?

2026-02-26-08-45-49_BglElByh.mp4

[vbakke]

😊 I struggled with that, too, @sawankshrma :) Made an obese solution, with timestamp for what was stored when etc. Ended up scrapping it. Kept it simple.

I'd say normal workflow would be:

• User starts with nothing
• User enters (progress or evidence) in the browser
• User may export this, and may save thins on server as a YAML file
• User may add more progress/evidence. These should in that case be shown next time user opens the browser.

In other words, I think that:

• localStorage should take priority over server side storage

If we want to go overboard with new functionality, we can somehow display what is newer in the localStorage vs server side yaml. Do say what should be exported, and saved to the server.

But I think that is a separate issue, which is better solved after the evidence issue has been implemented.

[sawankshrma]

Here's a quick summary of what this PR does end to end:

1. Data Model — EvidenceStore is introduced as a new store, separate from ProgressStore, holding evidence entries keyed by activity UUID. Each EvidenceEntry has a stable UUID to support multiple entries per activity per team.

2. Loading — Evidence is initialized during LoaderService bootstrapping. YAML evidence loads first, then localStorage evidence is merged on top with localStorage taking priority on duplicate ids.

3. Storage — Evidence is persisted separately in localStorage under its own key, keeping it decoupled from progress for now.

---

I believe this is ready to merge. Once merged, I'll start on the UI layer implementation. Plz let me know :)

[vbakke]

Looks good. Just some smaller comments. Feel free to continue with the UI :)

[sawankshrma]

Looks good. Just some smaller comments. Feel free to continue with the UI :)

Addressed the comments in the last two commits. Will be opening a UI PR shortly.

[sawankshrma]

UI related changes in dc3b309

• Added three new components AddEvidenceModalComponent, EvidencePanelComponent, and ViewEvidenceModalComponent to view and add Evidences in the UI.

• The EvidencePanelComponent is used at three different places: CircularHeatmap, ActivityDescription, and ReportPage. Also included are some changes in these components too, which are very straightforward: The EvidencePanelComponent is used in ActivityDescriptionComponent as well as ViewEvidenceModalComponent. The ViewEvidenceModalComponent is used in circluarheatmap and reportPage.

@vbakke, @wurstbrot feel free to review and suggest changes if needed anywhere.

• Closes Team evidence #496