Add EvidenceStore for tracking activity evidence (#496)

[sawankshrma]

Description

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

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?

[vbakke]

Ah. I was not clear in my example.

The UUID on top level under the root node evidence: I was thinking would be the activity-uuid.

So unless we want to create an UUID as an ID for the evidence entry itself, I don't think this will be needed.

[sawankshrma]

No. I did understand in the issue example that the top level UUID was the activity-uuid.

It was my mistake that I did not point this extra design choice of the data-structure in the PR description.
Let me calrify this here.

• Since we are not going to tie evidence with progress (as specifically mentioned in the issue's comments). For the same team and the same activity we could have more than one EvidenceEntry (say entries for starting and partly implementing but not fully implementing, 2 here).

• For this I went for a unique id for each EvidenceEntry to identify them separately.

• I have updated the Format in the original PR description which showcases this. I just copy-pasted the Format form the issue earlier. my bad.!

If this design choice seems unnecessary, please suggest another way to uniquely identify multiple EvidenceEntry entries for the same team and activity.

• We could also consider linking them to the Progress name instead, this way each progress would have at-most one EvidenceEntry. Again, I leave this decision for maintainers.

[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