feat(viewer): group IDS panel results by requirement - #3037
Conversation
…2933) The in-app IDS results panel had the same defect confirmed in the concurrent HTML export rework: requirement results were only visible by expanding one entity at a time, so a user could not see, per requirement, how many checks passed/failed or which elements failed without clicking into every entity. Add apps/viewer/src/hooks/ids/idsRequirementGrouping.ts — pure helpers that re-slice a specification's entityResults by requirement (keyed on requirement.id, stable across entities within a spec since the validator reuses the same IDSRequirement object per requirement) and compute a check-level pass rate (one check = one entity x one requirement). not_applicable is excluded from both numerator and denominator of every rate, matching how the validator itself treats applicableCount/passedCount/failedCount. IDSPanel's SpecificationCard now renders a "Requirement Breakdown" section (facet type, description, pass/fail/n-a counts, failing elements with type/name/GlobalId/reason, click-to-select) above the existing per-entity list, and a check-level rate line next to the existing entity-level PassRateBar — the two legitimately differ whenever one entity fails more than one requirement. This module is standalone, not shared with idsExportService.ts (owned by a concurrent HTML/JSON export rework) — no shared grouping helper existed between the two before this change.
`computeCheckStats`'s docblock, the IDSPanel comment beside the rendered figure, and a test title all said the check-level rate is "always <=" the specification's entity-level `passRate`. The relation runs the other way: `spec.passRate` is passing ENTITIES over total entities, and an entity is failed by its FIRST failing requirement while its remaining requirements still count as passes here. Entity A passing 1 of 2 checks and entity B passing both give 50% entity-level against 75% check-level. It is not "always >=" either, so the prose now says "normally": the two rates have different denominators, and an entity whose requirements are all `not_applicable` counts as a passing entity while contributing no applicable check at all. Both directions are now arithmetic rather than prose. Mutation-checked: collapsing a failing entity's checks into failures, and substituting the entity-level formula outright, each turn the new tests red.
|
Warning Review limit reached
Next review available in: 56 minutes Limit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Viewer benchmark✅ No threshold regressions detected. 01_Snowdon_Towers_Sample_Structural(1).ifcBaseline recorded 2026-07-01T20:31:05.538Z on github-actions ubuntu-latest, viewer-benchmark-ci (headless Chrome, SwiftShader ANGLE), production build.
AC20-FZK-Haus.ifcBaseline recorded 2026-07-01T20:30:59.972Z on github-actions ubuntu-latest, viewer-benchmark-ci (headless Chrome, SwiftShader ANGLE), production build.
Refresh the baseline from a CI run: dispatch the Benchmark workflow with |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
2 participants
Groups the in-app IDS panel's results by requirement, mirroring what #2979 does for the HTML export. Disjoint files — this is
IDSPanel.tsx+ a newidsRequirementGrouping.ts; #2979 is confined toidsExportService.ts.RED — surgical, regressing the grouping key from
reqResult.requirement.idback to the entity id: 3 pass / 3 fail. Unmutated 6/6.A docblock claim that was wrong in both directions
computeCheckStatssaid the check-level rate is "distinct from (and always<=) the specification's own entity-levelpassRate".That is inverted.
spec.passRate = passedCount / totalEntities(validator.ts:359-360), andpassed: allPassedis false as soon as one requirement fails (validator.ts:479-496) — so an entity passes only when all its checks pass, and the check rate normally sits above. Measured: entity A passes 1 of 2 checks, entity B passes both → entity-level 50%, check-level 75%.But "always
>=" is also wrong, so that is not what it now says. Counter-example, verified by running: entity A with a singlenot_applicablerequirement counts as a passing entity while contributing zero applicable checks; entity B fails its only check. Entity-level 50%, check-level 0%.The two rates have different denominators, so neither direction holds unconditionally. The docblock now says "normally above", names the mechanism, and names the exception.
The inverted claim appeared in three places, not one: the docblock, the comment beside the rendered figure in
IDSPanel.tsx:242, and a test title asserting<=.Two tests added pinning both directions as arithmetic — the 50%/75% case and the
not_applicableexception. Mutation-checked, both killed: collapsing a failing entity's checks into failures → 2 fail; substituting the entity-level formula forcheckPassRate→ 3 fail.idsRequirementGrouping.test.ts6 → 8, all pass. Fullapps/viewer5344 pass / 0 fail / 6 skipped.tsc --noEmit0 errors.🤖 Generated with Claude Code