Remove legacy p95 demand fallback from parseEmporia.js #9

New issue

Open

opened 2026-07-17 01:17:55 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-17 01:17:55 +00:00

Contributor

docs/implementation-audit.md notes: The older p95-style demand fallback still exists in src/lib/parseEmporia.js for parametric rate inputs.

The percentile peak work in src/lib/analytics.js supersedes this - it provides p95/p99/p99.5 bands with timestamps and circuit context. Two code paths computing demand peaks differently is a correctness hazard.

Confirm the analytics path fully covers the parametric case, then remove the fallback. If parametric mode genuinely still needs it, document why it differs instead of removing.

Audit note (2026-07-16)

While in this code, three adjacent cleanups belong in the same pass:

src/lib/rates.js:37-42 — isHoliday is exported but never called, and its no-year branch uses a 4-date holiday list that contradicts isHolidayDate's real calendar. Any future caller gets wrong answers. Delete it (or make it delegate to isHolidayDate).
src/lib/parseEmporia.js:279 uses floor(n*0.95) while src/lib/analytics.js:237 uses ceil(n*p)-1 — two rank conventions for the same concept. When removing the legacy fallback, standardize on the analytics convention.
src/lib/simulation.js:508 — getTieredBlendedRate's 0.10 fallback is unreachable (only anytime/eveningMorning ever signal null); replace with a thrown error or a comment so a future plan addition doesn't silently bill at 10¢. Also simulation.js:77-87 pre-computes Ultimate monthly peaks that the main loop recomputes identically at :127-129 — delete the pre-scan.

Acceptance criteria (audit additions):

isHoliday removed or delegating; no divergent holiday list remains
One percentile convention across parseEmporia/analytics
Dead blended-rate branch and duplicate peak pre-scan removed

(Audit finding F-18, 2026-07-16)

`docs/implementation-audit.md` notes: *The older p95-style demand fallback still exists in `src/lib/parseEmporia.js` for parametric rate inputs.* The percentile peak work in `src/lib/analytics.js` supersedes this - it provides p95/p99/p99.5 bands with timestamps and circuit context. Two code paths computing demand peaks differently is a correctness hazard. Confirm the analytics path fully covers the parametric case, then remove the fallback. If parametric mode genuinely still needs it, document why it differs instead of removing. ## Audit note (2026-07-16) While in this code, three adjacent cleanups belong in the same pass: 1. `src/lib/rates.js:37-42` — `isHoliday` is exported but never called, and its no-year branch uses a 4-date holiday list that contradicts `isHolidayDate`'s real calendar. Any future caller gets wrong answers. Delete it (or make it delegate to `isHolidayDate`). 2. `src/lib/parseEmporia.js:279` uses `floor(n*0.95)` while `src/lib/analytics.js:237` uses `ceil(n*p)-1` — two rank conventions for the same concept. When removing the legacy fallback, standardize on the analytics convention. 3. `src/lib/simulation.js:508` — `getTieredBlendedRate`'s 0.10 fallback is unreachable (only anytime/eveningMorning ever signal null); replace with a thrown error or a comment so a future plan addition doesn't silently bill at 10¢. Also `simulation.js:77-87` pre-computes Ultimate monthly peaks that the main loop recomputes identically at :127-129 — delete the pre-scan. Acceptance criteria (audit additions): - [ ] isHoliday removed or delegating; no divergent holiday list remains - [ ] One percentile convention across parseEmporia/analytics - [ ] Dead blended-rate branch and duplicate peak pre-scan removed *(Audit finding F-18, 2026-07-16)*

claude-bot added this to the v1.1.0 - Test & Ops Hardening milestone

2026-07-17 01:17:55 +00:00

claude-bot added the

tech-debt

label

2026-07-17 01:17:55 +00:00

claude-bot referenced this issue

2026-07-17 03:06:44 +00:00

Harden Emporia CSV import: validate mains, fix zero-peak fallback, define dedup policy #26

claude-bot referenced this issue

2026-07-17 15:21:13 +00:00

Server-side calculations are computed in the container timezone, shifting all TOU windows #22