chore(reports): regenerate stale Public-derived report artifacts - #70
Merged
juemerson-at-purestorage merged 1 commit intoAug 2, 2026
Conversation
PR dmann000#68 (d42a22f, "Add user & group quota policy cmdlets") added cmdlets without regenerating the committed report artifacts, and PR dmann000#66 (18f8ed7) regenerated from a base that predated it. The committed Reports/PfbApiDriftReport.json has been stale on main since, which fails Tests/Build-PfbApiDriftReport.Tests.ps1's assertion that the in-memory report matches the committed one exactly. Regenerates only the Public/-derived artifacts: tools/Build-PfbFieldCmdletMap.ps1 tools/Build-PfbApiDriftReport.ps1 Data/PfbCapabilityMap.json is spec-derived and already covers all 29 cached specs (2.0-2.28), so it needs no rebuild; tools/Update-PfbApiSpecs.ps1 was deliberately NOT run, so no new REST version is pulled in and the before/after comparison stays clean. Net effect -- the quota cmdlets are now recognised as covered, which exposes their parameter gaps: uncovered endpoints 117 -> 98 endpoints with gaps 417 -> 436 query-parameter gaps 924 -> 954 body-property gaps 403 -> 408 No field was lost: every field present in the previous report is still present. Verified deterministic -- regenerated to a second path and the SHA256 of both the .json and .md match byte-for-byte. No logic change; Reports/ only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
juemerson-at-purestorage
added a commit
to juemerson-at-purestorage/fb-powershell
that referenced
this pull request
Aug 2, 2026
…section Adds the `contextCardinality` manifest key and its Markdown section, which Build-PfbApiDriftReport.ps1 has emitted since the cardinality-rule change but which no committed artifact carried yet. PR dmann000#70 regenerated Reports/ from main, so this is the same regeneration re-run on top of this branch. Measured against fb2.28: 376 endpoints declare `context_names`, 135 satisfy the rule, 9 signal disagreements (4 component-says-multi-value-but-no-allow-errors, 4 rule-says-capable-but-declares-no-207, 1 size-1-component-but-declares-allow-errors) and no unresolved components. Content only -- no tool or rule changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
juemerson-at-purestorage
added a commit
that referenced
this pull request
Aug 2, 2026
…the spec (#73) * feat(tools): verify the Fusion context_names verb rule against the spec Adds a new drift-report category that asks a question none of the existing ones do: "is an assumption baked into the module still true?" The module's context cardinality rule -- GET is multi-context-capable, POST/PUT/PATCH/DELETE are single-context-only -- is ground truth (live-tested plus upstream confirmation), but it is about to be hardcoded and nothing would notice if the API changed underneath it. The spec expresses cardinality only through which component context_names $refs (Context_names_get vs Context_names); those components have identical schemas and there is no maxItems, so the component name is the sole mechanical signal available. - Private/Test-PfbContextMultiValueCapable.ps1 is now the ONE declared home of the rule. Context injection (PR #22) should call it rather than testing the verb inline. It throws on a verb it has no verdict for rather than assuming size-1. - tools/lib/PfbContextRuleTools.ps1 dot-sources and EXECUTES that predicate rather than re-deriving it -- a check that re-implements its own rule verifies nothing. Reuses Resolve-PfbRef via Get-PfbSpecCapabilities; no second resolver. - allow_errors co-occurrence anomalies are reported as a SEPARATE subsection, scoped to endpoints where rule and spec already agree, so one defect is never double-counted as both a disagreement and an anomaly. - The section renders even when clean: for this category "nothing to report" is itself the finding, and a section that vanishes is indistinguishable from one that never ran. Version-scoped findings: fb2.26 and fb2.27 each contain exactly one disagreement, DELETE /management-access-policies referencing Context_names_get -- a confirmed upstream documentation defect, never given an exception in the module. REST 2.28 corrected that reference, so the check reports zero against the current capability map. Both states are pinned as tests, which is what proves the check tracks the spec rather than reporting a constant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(tools): replace the withdrawn verb rule with the ratified cardinality rule Supersedes 26f33ef, whose commit message and code documentation both described the verb rule as "GROUND TRUTH -- live-tested against a FlashBlade plus upstream confirmation". That claim was false and is withdrawn. It came from verb-rule-verification-brief.md and was restated here without being verified. Live testing on 2026-08-01 against FB-A (REST 2.26, coordinator of cc-test-fleet with FB-C as a remote member) disproved it: four fleet-scoped GETs reject any two-name context with 400 code 15 "Multiple location contexts are not allowed." -- GET /presets/workload and the three /topology-groups endpoints. code 15 fires before the cross-array authorization gate that yields code 20 on control endpoints, so it is structural to the endpoint, not a permission artifact. The ratified replacement (rev 3 of docs/design/fusion-context-injection.md, section 8): an endpoint is multi-context-capable if and only if its context_names resolves to component Context_names_get AND the endpoint declares allow_errors. The verb survives only as a fallback for an endpoint absent from the capability map, where no signal exists. - Test-PfbContextMultiValueCapable becomes a pure three-argument predicate (-Method, -ContextComponent, -DeclaresAllowErrors). No I/O, so the drift check and the future injection path can each feed it from their own source while still executing one shared rule. - Get-PfbContextVerbRuleDisagreement becomes Get-PfbContextSignalDisagreement: a cross-signal agreement check rather than rule-vs-component. The old two-signal shape was structurally blind to the defect that exists -- rule and component agreeing while both are wrong -- and reported ZERO against fb2.28 while four endpoints were wrong. Findings are classified by shape. - HTTP 207 joins as a corroborating signal, read from tools/specs because the capability map holds no response data. An unknown 207 is carried as $null and excluded from comparison, never scored as "does not declare". - MultiValueWithoutAllowErrors is no longer a co-occurrence curiosity; under the new rule it is a cardinality finding and folds into the disagreement list. The size-1-declaring-allow_errors mirror stays named, as a documented SUBSET of that list rather than an additional finding. - Deleted the clean-path paragraph asserting "The module rule was right and was left untouched" -- against fb2.28 it printed a false all-clear. Two PowerShell collection bugs found and fixed while wiring this up: assigning a HashSet from an if-expression ENUMERATES it (turning an empty 207 set into "unknown" and a populated one into an array that has lost its OrdinalIgnoreCase comparer), and an empty array emitted as a scriptblock value collapses to $null (which handed a null $contextFacts to the report). Both are now plain if-statements with direct assignment, and both are covered by tests. Verified: fb2.27 yields 139/135/124/134 and fb2.28 four remaining defective endpoints, all matching rev 3's Appendix A independently. Tests assert specific endpoints and structure, never population totals, since the capability map is being regenerated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(reports): regenerate drift report with the context cardinality section Adds the `contextCardinality` manifest key and its Markdown section, which Build-PfbApiDriftReport.ps1 has emitted since the cardinality-rule change but which no committed artifact carried yet. PR #70 regenerated Reports/ from main, so this is the same regeneration re-run on top of this branch. Measured against fb2.28: 376 endpoints declare `context_names`, 135 satisfy the rule, 9 signal disagreements (4 component-says-multi-value-but-no-allow-errors, 4 rule-says-capable-but-declares-no-207, 1 size-1-component-but-declares-allow-errors) and no unresolved components. Content only -- no tool or rule changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Regenerates the
Public/-derived report artifacts, which have been stale onmain.Why
PR #68 (
d42a22f, "Add user & group quota policy cmdlets") added cmdlets without regenerating the committed report artifacts. PR #66 (18f8ed7) did regenerate, but from a base that predated #68.The result is a currently-failing test on
main:Tests/Build-PfbApiDriftReport.Tests.ps1:780asserts the in-memory report matches the committedReports/PfbApiDriftReport.jsonexactly, and it reports a 47-item divergence on an unmodified checkout. This will fail CI for any PR branched frommain, not just this one.What was run
Data/PfbCapabilityMap.jsonis spec-derived and already covers all 29 cached specs (2.0-2.28), so it needs no rebuild.tools/Update-PfbApiSpecs.ps1was deliberately not run -- without-Forceit still re-hits the network for the version index, and a newly published REST version would silently change every count and confound the before/after comparison this verification depends on.Net effect
The quota cmdlets are now recognised as covered, which exposes their parameter gaps:
Every newly-reported field is on a
user-group-quota-policies/ quota endpoint -- i.e. exactly PR #68's surface.Verification
.jsonand the.mdmatch the committed artifacts byte-for-byte.Build-PfbApiDriftReport.Tests.ps1+PfbApiDriftTools.Tests.ps1: 165 passed, 0 failed (was 1 failed before this change). Full-suite coverage is CI's job per the repo convention.Public/orPrivate/change and no runtime surface -- this isReports/only. The equivalent verification is the whole-report diff plus the determinism check above.Scope
Reports/only. No logic change. No version bump, no CHANGELOG entry -- those are maintainer decisions.Found while establishing a clean baseline for upcoming response-shape drift work.
🤖 Generated with Claude Code