Skip to content

fix(standards): generate the evaluability capture and make its guard read Core - #279

Merged
beyondnetPeru merged 2 commits into
developfrom
claude/nice-cohen-249671
Jul 29, 2026
Merged

fix(standards): generate the evaluability capture and make its guard read Core#279
beyondnetPeru merged 2 commits into
developfrom
claude/nice-cohen-249671

Conversation

@beyondnetPeru

Copy link
Copy Markdown
Contributor

Pull Request Summary

src/rulesets/standards/native-evaluability-snapshot.json was 12 rules behind Core, and the guard that should have caught it structurally could not.

The snapshot's own validation field promised it reproduced the class counts pinned by rule-corpus-triage.spec.ts. The only guard over it — the test literally named "the evaluability snapshot still matches the class counts pinned by Core" — asserted evaluability.counts against six literals typed into the test file. It compared the snapshot with a second copy of the snapshot and never with Core, so it stayed green while the pin moved 139 → 151 and the published handler backlog overstated the remaining work by twelve rules.

1. Recaptured from the live triage

was now
corpus (classes) 379 386
native-handler 139 151
documentation-only 129 136
unimplemented-native 60 48

The per-rule diff is real closures, not a renumbering: HXA-01/02/04/05 (GT-632) and MTN-05, GIT-08, SEC-RL-01/02, ED-R04..06, DAM-R05 (GT-595) are native-handler now. The +7 on the corpus is the ADR rulesets 0118..0124, which were absent from the capture entirely.

handlerBacklog re-derives with them: realBacklogSize 60 → 48, remainderToAuthor → 38, not-in-snapshot back to 2 (was 9).

2. The guard now reads Core — neither end is a copy

  • rule-corpus-triage.spec.ts renders the snapshot from the same CLASSIFIED array its assertions measure, and pins it byte-for-byte — the --check shape build-iso-5055-mapping.mjs already uses for its own outputs. A hand-edit now fails jest. Recapture with UPDATE_EVALUABILITY_SNAPSHOT=1.
  • iso-5055-mapping.test.mjs parses the pinned expect(SUMMARY.byClass) object out of Core's suite instead of restating it. A pin it cannot find is a failure, never a skip — the test cannot go green by losing its authority.

Both were verified to go red by injecting drift from each side (moving Core's pin; hand-editing the snapshot).

Also in this PR

Both READMEs published the same stale figures in prose (60-rule backlog, "17 of 60", 381 rules) — corrected, with the reason the backlog moved stated so it does not read as a re-cut denominator.

Note: build-iso-5055-mapping.mjs --check was already failing before this change — the corpus had grown by seven rulesets and the table had not been regenerated. That is fixed here too.

Evolith Core Quality Gates

  • Bilingual Parity: Both README.md and README.es.md updated with the same figures.
  • Validation Scripts: node .harness/scripts/ci/01-validate-docs.mjs — passed (1491 files).
  • Bilingual Validation: node .harness/scripts/ci/04-check-bilingual-parity.mjs — passed (524 docs checked).
  • Agnosticism: No new technology dependency; test/tooling and generated artifacts only.

Verification

node --test src/rulesets/standards/iso-5055-mapping.test.mjs          # 7/7 pass
npx jest src/application/validators/rule-corpus-triage.spec.ts        # 22/22 pass
node src/rulesets/standards/build-iso-5055-mapping.mjs --check        # up to date

Linked ADRs / Issues

  • Link to ADR: —
  • Link to Issue: GT-595, GT-632 (numbers this capture had fallen behind)

Conventional Commits

  • PR title and commit follow Conventional Commits (fix:).

🤖 Generated with Claude Code

beyondnetPeru and others added 2 commits July 29, 2026 14:00
fix: three P0s, and twelve rules that promised enforcement and delivered nothing (GT-572, GT-595, GT-604)
…read Core

`native-evaluability-snapshot.json` was 12 rules behind Core and nothing said
so. Its own `validation` field promised it reproduced the counts pinned by
`rule-corpus-triage.spec.ts`, but the only guard over it — the test named "the
evaluability snapshot still matches the class counts pinned by Core" — asserted
`evaluability.counts` against six literals typed into the test file. It compared
the snapshot with a second copy of the snapshot and never with Core, so it
passed while the pin moved 139 -> 151 and the published handler backlog
overstated the work by twelve rules.

Recapture, from the live triage rather than by hand:
  corpus              379 -> 386   (the 7 ADR rulesets 0118..0124 were absent)
  native-handler      139 -> 151
  documentation-only  129 -> 136
  unimplemented-native 60 ->  48

The per-rule diff is closures, not a renumbering: HXA-01/02/04/05 (GT-632) and
MTN-05, GIT-08, SEC-RL-01/02, ED-R04..06, DAM-R05 (GT-595) are `native-handler`
now. `handlerBacklog` re-derives with them — realBacklogSize 60 -> 48,
remainderToAuthor -> 38, `not-in-snapshot` back to 2 from 9.

The guard is rebuilt at both ends, and neither end is a copy:

 - `rule-corpus-triage.spec.ts` RENDERS the snapshot from the same `CLASSIFIED`
   array its assertions measure, and pins it byte-for-byte — the `--check`
   shape `build-iso-5055-mapping.mjs` already uses for its own outputs.
   Recapture with UPDATE_EVALUABILITY_SNAPSHOT=1. A hand-edit now fails jest.
 - `iso-5055-mapping.test.mjs` parses the pinned `expect(SUMMARY.byClass)`
   object out of Core's suite instead of restating it. A pin it cannot find is
   a failure, never a skip, so the test cannot go green by losing its authority.

Both were verified to go red by injecting drift from each side.

Also corrects the two READMEs, which published the same stale figures in prose
(60-rule backlog, "17 of 60", 381 rules), and states why the backlog moved so it
does not read as a re-cut denominator. Note that `build-iso-5055-mapping.mjs
--check` was already failing before this change: the corpus had grown by seven
rulesets and the table had not been regenerated.

Verified: node --test src/rulesets/standards/iso-5055-mapping.test.mjs (7/7),
npx jest src/application/validators/rule-corpus-triage.spec.ts (22/22),
build-iso-5055-mapping.mjs --check.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@beyondnetPeru
beyondnetPeru requested a review from a team as a code owner July 29, 2026 20:48
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@github-actions

Copy link
Copy Markdown

📊 Bilingual Coverage Impact

PR Changes

  • Paired EN/ES files modified: 1
  • New EN files needing ES translation: 0

Repository Coverage

Metric Value
Total EN files 524
Total ES files 498
Paired files 0
Coverage 0%

Good: All EN changes have ES counterparts.


Generated by GitHub Actions

@beyondnetPeru
beyondnetPeru merged commit d11b989 into develop Jul 29, 2026
29 of 33 checks passed
@beyondnetPeru
beyondnetPeru deleted the claude/nice-cohen-249671 branch July 29, 2026 20:57
beyondnetPeru added a commit that referenced this pull request Jul 29, 2026
…rsion (GT-634)

Third and last version-pinned artifact the 1.2.2 bump moves.
`generate-product-inventory.mjs` stamps `@beyondnet/evolith-cli@<version>` into
`product/products/smart-cli/product-inventory.{md,es.md}`, and
`11-validate-product-docs.mjs` runs its `--check`, so `Validate documentation`
went red at "Validate product documentation synchronization". Regenerated: the
diff is the version and the counts the generator recomputes.

The staleness was reported with an EMPTY detail — `Product inventory is stale: `
— because the guard interpolates the child's stdout and the child writes its
reason to stderr. Not fixed here (it is not a release change) but worth naming:
a guard that says something is stale without saying how is a guard you have to
re-derive by hand.

WHAT I DELIBERATELY DID NOT COMMIT. `coverage-dashboard.mjs --check` also reports
drift locally, and regenerating it replaces MEASURED coverage — "88.09% statements
· 88.38% lines" — with "pending a coverage run", because this machine has no
coverage data. That is a regression dressed as a fix. The docs job on the runner
runs a build and the exploration suite before that check and passed green on
develop at 20:56Z, so the report is current where it is measured. Same for
`inventory-summary.{md,es.md}`, whose 167 -> 174 ruleset count belongs to whoever
landed #279, not to this release.

Verified with only this staged: 11-validate-product-docs OK (CLI 1.2.2, no
placeholders), 10-validate-contract-conformance OK (4 schemas), 09-reconcile
--check OK.

Honest note on method: I ran the docs job's fifteen validators in one local loop
to find every pin at once instead of one CI round each. Three of them reported
failure inside that loop and pass individually, including under the same output
redirection — so the loop, not the checks, is what was wrong. I have not explained
it, and the runner is the oracle for this job, not my loop.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.

1 participant