mirror of
https://github.com/hanzoai/datastore.git
synced 2026-10-30 14:48:37 +00:00
zlareb1andClaude Opus 4.7
9b6eb38dc9
Address review comment 3194583058: the date-range workflow promised
"between A and B" but only filtered ts >= '{{TS_FILTER}}', so a request
like "between 2026-04-01 and 2026-05-01" silently included every nightly
after 2026-05-01 and let cumulative deltas drift as new runs accumulated.
Add a parallel TS_FILTER_END / KEEPER_SKILL_THRESHOLD_END upper bound that
mirrors the existing lower bound at every layer:
- All 6 staging SQL queries: append `AND ts < '{{TS_FILTER_END}}'`.
- `rebuild.sh`: accept `$3` as the upper bound; sed-substitute both
placeholders; export both env vars for the Python pipeline.
- `_common.py`: parse `KEEPER_SKILL_THRESHOLD_END` (defaults to far-future
sentinel `9999-12-31`) so unbounded callers keep today's behavior.
- `build_pr_nightly_map.py` and `compute_deltas.py`: filter PRs against
the half-open `[THRESHOLD, THRESHOLD_END)` interval.
- `SKILL.md`: update Phase 2 invocation and Example 2 ("between
2026-04-01 and 2026-05-01") to pass both bounds.
- `tests/test_common.py`: 2 new cases for the `THRESHOLD_END` default
and explicit-env-var parse path. 23 -> 25 cases, all pass.
Backward-compat regression contract: invoking `rebuild.sh ... 2026-03-25`
(no upper bound) still produces `cumulative_gains.tsv` md5
e5a27e01008ef7e23597ee041f68103b and the `#99651` PR-branch isolation row
bit-identical. Bounded smoke (`... 2026-03-25 2026-04-15`) verified to
produce strictly fewer rows in `bench_summary.tsv` and `merged_metrics.tsv`,
with max `run_ended` < `2026-04-15` and all `pr_to_nightly.tsv` `merged_at`
< `2026-04-15`.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>