Problem
The current logging approach writes per-run timestamped files to reports/rename-log-{timestamp}.json. The reports/ directory is empty (no real runs have produced files there), so no prior state is ever loaded. Every run starts with $lastOdometer = $null, meaning photo 1 always passes validation unconditionally — if its OCR reading is wrong, it poisons the entire chain.
Plan
Prior state — 3-level fallback chain (on startup)
logs/rename-state.json (primary) — tiny file with just { Odometer, DateTimeOriginal, Location, OdometerConfidence }. Overwritten after every real rename. Fast and reliable after the first run.logs/rename-log.json (secondary) — full audit log. Scan for the last ok/recovered entry. Used when state file is absent or unreadable.- Output directory scan (tertiary) — recurse
$outputFolder for files matching yyMMdd-hhmm * *.jpg, sort by name (alphabetical = chronological for this format), extract odometer from the last space-delimited token before .jpg.
On each successful rename (real run only, not -WhatIf)
- Overwrite
rename-state.json with current odometer/datetime/location
- Append the entry to
rename-log.json; deduplicate on OriginalFile before writing to prevent duplicate entries if a photo is somehow reprocessed
Bootstrapping with no prior data — -StartOdometer parameter
When all three fallbacks fail, $lastOdometer stays $null and photo 1 passes unconditionally. A bad first read poisons the chain. Fix: add an optional -StartOdometer [int] parameter. When provided, it seeds $lastOdometer before processing begins — photo 1 is validated like every other photo.
.\Rename-Photos.ps1 -StartOdometer 224570
After the first real run completes, rename-state.json is written and -StartOdometer is never needed again.
Removals
$reportsDir setup and the rename-log-{timestamp}.json approach removed entirely$logFile variable removed; Write-Information "Log: $logFile" in summary updated accordingly
Scope
Changes confined to scripts/Rename-Photos.ps1 main body (startup state loading block and per-rename write block). No changes to pipeline functions.
Problem
The current logging approach writes per-run timestamped files to
reports/rename-log-{timestamp}.json. Thereports/directory is empty (no real runs have produced files there), so no prior state is ever loaded. Every run starts with$lastOdometer = $null, meaning photo 1 always passes validation unconditionally — if its OCR reading is wrong, it poisons the entire chain.Plan
Prior state — 3-level fallback chain (on startup)
logs/rename-state.json(primary) — tiny file with just{ Odometer, DateTimeOriginal, Location, OdometerConfidence }. Overwritten after every real rename. Fast and reliable after the first run.logs/rename-log.json(secondary) — full audit log. Scan for the lastok/recoveredentry. Used when state file is absent or unreadable.$outputFolderfor files matchingyyMMdd-hhmm * *.jpg, sort by name (alphabetical = chronological for this format), extract odometer from the last space-delimited token before.jpg.On each successful rename (real run only, not -WhatIf)
rename-state.jsonwith current odometer/datetime/locationrename-log.json; deduplicate onOriginalFilebefore writing to prevent duplicate entries if a photo is somehow reprocessedBootstrapping with no prior data —
-StartOdometerparameterWhen all three fallbacks fail,
$lastOdometerstays$nulland photo 1 passes unconditionally. A bad first read poisons the chain. Fix: add an optional-StartOdometer [int]parameter. When provided, it seeds$lastOdometerbefore processing begins — photo 1 is validated like every other photo.After the first real run completes,
rename-state.jsonis written and-StartOdometeris never needed again.Removals
$reportsDirsetup and therename-log-{timestamp}.jsonapproach removed entirely$logFilevariable removed;Write-Information "Log: $logFile"in summary updated accordinglyScope
Changes confined to
scripts/Rename-Photos.ps1main body (startup state loading block and per-rename write block). No changes to pipeline functions.