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.

[vbakke]

Okay. So the top-level uuid is an activityId, and the id property is an evidenceId.

That makes sense. And the second ID is important to handle evidence from yaml and localStorage. Thumbs up.

[] However, maybe we should create a type ActivityId = Uuid as well as type EvidenceId = Uuid to more easily distinguish them. (The Uuid type has only one purpose today.)

[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 :)

[vbakke]

Suggested change

	if (!meta.teamProgressFile) {
	if (!meta.teamEvidenceFile) {

[vbakke]

Okay. So the top-level uuid is an activityId, and the id property is an evidenceId.

That makes sense. And the second ID is important to handle evidence from yaml and localStorage. Thumbs up.

[] However, maybe we should create a type ActivityId = Uuid as well as type EvidenceId = Uuid to more easily distinguish them. (The Uuid type has only one purpose today.)

[vbakke]

The current setup will prioritize YAML fil over loaclStorage.

I think locally changed evidence should take priority over server side evidence. Otherwise you will not be able to see your own changes if you reload the page.