Alberto-Codes / Alberto-Codes/vramfit
Every sidecar date field is documented YYYY-MM-DD and validated by nobody
- Dominant language
- Python
- Stars
- 1
- Forks
- 1
- Avg merge
- 5h 57m
- Merged PRs (30d)
- 110
Description
## Problem
The evals sidecar carries up to eleven `date` fields. Every one is
documented as ``YYYY-MM-DD`` and validated by nobody.
`src/vramfit/domain/evals.py` checks one rule at `:153`, `:199`, and
`:291`:
```python
if not self.date:
raise ValueError("date must not be empty")
```
## Evidence
Measured 2026-08-15 through the new reader, on the published sidecar
`tests/data/published-evals/baseline-iq3-xs.gguf.evals.json`:
```
"date": "not-a-date" -> ACCEPTED, round-trips clean
"date": "2026-13-45" -> ACCEPTED, round-trips clean
```
## Why it matters
ADR-0025 decision 4 binds a card number to a sidecar entry, and the
card tooling renders or sorts these dates. That tooling gets a
`ValueError` from its own date parse, with no JSON path, no file name,
and no way to tell which of eleven fields is wrong.
The reader is the layer that knows the path. It is also the layer that
declined to check.
## Why this may be a decision
The format is prose in three docstrings today, not a record. Enforcing
it fixes the format for every published sidecar and for every future
one. Three questions the fix has to answer:
- Does the domain enforce it, so all three types inherit one rule?
- Is a date-only format right, or does a lane that crosses midnight
want a timestamp? ADR-0025 already notes that one artifact's windows
and tasks run on different days.
- Do the five published sidecars all pass? They must, or the rule
lands with a migration.
## Sequencing
Land after the `_built` hoisting in PR #259, or a
`date.fromisoformat` `ValueError` gets relabeled at the wrong JSON
path. PR #259 does that hoisting, so this is clear once it merges.
## Found by
The #137 review pass (PR #259).
Contributor guide
Research direction
Start in src/vramfit/domain/evals.py at the checks around lines 153, 199, and 291, then read ADR-0025 and the hoisting changes in PR #259. Inspect the five published sidecars under tests/data/published-evals/ before deciding the accepted date representation and migration needs. Done means the decision is recorded, published sidecars comply or have a migration, and invalid fields fail with useful JSON paths.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, data
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100