Skip to content

Reconsider field naming alignment with crit (captured_at, snapshot status enum) #174

@tomasz-tomczyk

Description

@tomasz-tomczyk

Context

While shipping the per-round timeline in crit, we audited the data-model alignment between crit's local JSON storage and crit-web's Postgres schema. Most fields agree, but two areas have minor drift worth revisiting once the dust settles.

Drift items

1. `captured_at` (crit) vs `inserted_at` (crit-web)

Snapshots in crit carry a `CapturedAt time.Time` field, surfaced as `captured_at` in the `/api/rounds` JSON. The crit-web `review_round_snapshots` table uses the `timestamps(updated_at: false)` macro, which produces `inserted_at`. Same intent, different name.

The wire format is already aligned at the API boundary (Stage 3 Phoenix layer would map `inserted_at` → `captured_at` when serializing). This issue is just to track that the internal naming should converge eventually for clarity. Pick whichever side is more consistent with broader conventions.

2. Snapshot `status` enum

crit-web has `Ecto.Enum [:added, :modified, :deleted, :renamed, :removed]` on `review_round_snapshots.status`. crit currently always emits `"modified"`. Since crit-web sources its snapshots from crit's share payload, the richer enum values may not be populated in practice today.

Decide whether to:

  • Have crit start emitting the full enum (added/deleted detection at round-complete is cheap), then crit-web stores accurately; OR
  • Drop the enum on crit-web's side if it's effectively unused; OR
  • Keep as-is and document the behavior.

Priority

Low. Both items are alignment polish, not bugs. Worth revisiting after the round timeline ships and we have real-world feedback on what the UI/API actually consumes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions