Skip to content

feat(revalidate): add pdca revalidate — re-gate a frozen bundle (#11) - #39

Merged
eduralph merged 1 commit into
mainfrom
feat/pdca-revalidate
Jun 13, 2026
Merged

feat(revalidate): add pdca revalidate — re-gate a frozen bundle (#11)#39
eduralph merged 1 commit into
mainfrom
feat/pdca-revalidate

Conversation

@eduralph

Copy link
Copy Markdown
Owner

A bundle's check-gates.json is frozen at Check time, but the gates run against a moving substrate (engine, ruleset, deps). A frozen FAIL the current engine would never reproduce is otherwise indistinguishable from a real accepted failure. pdca revalidate <id> re-runs the gates against the current engine and records the staleness — without re-deciding §9.

What

  • gates.run_gates_dry — same single-sourced _run_checks as pdca gates but write_to=None, so re-gating a COMPLETE bundle never overwrites its frozen check-gates.json / .md. (The crux: run_gates writes via _finalize(write_to=d) and would clobber the frozen record.)
  • revalidate.py — diffs frozen vs fresh rows by (element, rule_id, check), writes an additive revalidation-<date>.json recording {date, engine_rev, per-row old→new, changed, regression}. Never touches the frozen files or §9.
  • CLIpdca revalidate <id> [--date]; refuses a non-COMPLETE bundle (rc 2), exits nonzero on any delta (rc 1), quiet confirmation otherwise.
  • Act — the bundle index surfaces revalidation deltas (read-only) so Act can tell a stale frozen FAIL from a real failure where it already looks.

Tests

7 new cases in test_revalidate.py using deterministic true/false gates: stamp written + frozen files byte-identical; regression (frozen PASS now FAIL); unchanged = quiet confirmation; rc on delta; refuses non-COMPLETE; missing bundle; act-index surfaces the delta. Full suite green.

Note

Evidence is n=1 (the gramps-testbed-v2 bundle 11786 case in the issue); filing the full command per the issue's "if pursued" acceptance criteria.

Closes #11

🤖 Generated with Claude Code

A bundle's check-gates.json is frozen at Check time, but the gates run
against a moving substrate (engine, ruleset, deps). A frozen FAIL the
current engine would never reproduce is otherwise indistinguishable from a
real accepted failure. `pdca revalidate <id>` re-runs the gates against the
current engine and records the staleness, without re-deciding §9.

- gates.run_gates_dry: same single-sourced _run_checks as `pdca gates` but
  write_to=None, so re-gating a COMPLETE bundle never overwrites its frozen
  check-gates.json / .md.
- revalidate.py: diffs frozen vs fresh rows by (element, rule_id, check),
  writes an additive revalidation-<date>.json {date, engine_rev, per-row
  old→new, changed, regression}. Never touches the frozen files or §9.
- cli: `pdca revalidate <id> [--date]`; refuses a non-COMPLETE bundle
  (rc 2), exits nonzero on any delta (rc 1), quiet confirmation otherwise.
- act: the bundle index surfaces revalidation deltas (read-only) so Act can
  tell a stale frozen FAIL from a real failure where it already looks.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@eduralph
eduralph force-pushed the feat/pdca-revalidate branch from af731ee to 766bacf Compare June 13, 2026 11:50
@eduralph
eduralph merged commit 73923b0 into main Jun 13, 2026
1 check passed
@eduralph
eduralph deleted the feat/pdca-revalidate branch June 13, 2026 11:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add pdca revalidate: re-run gates on a frozen bundle against the current engine (additive, never re-decides §9)

1 participant