v0.3.31

Operator-authorized resolution of all 9 issues in the "Semantic Audit
Follow-ups (Rounds 1-6)" milestone, acting with full authorization to
make the judgment calls each issue was filed needing.

• (#68) REQ-001 hardcoded-identifier violations: genericized every real, accidental violation -- renamed the sandbox-sbom-reporting/* schema-namespace prefix to projectbuddy/* across 17 real producer/consumer file pairs (verified every pair still matches post-rename with a dedicated script); renamed the /SandboxSBOMReporting/SshHostEd25519Fingerprint guest-property path to /ProjectBuddy/... (4 files, plus the guestproperty enumerate --patterns call that searched for the old pattern); renamed /var/lib/sandbox-sbom-reporting to /var/lib/projectbuddy and the matching ~/.local/state/... path; genericized Register-WslRunnerKeepAlive.ps1's default shortcut name, unattended-template.xml's 4 <Description> fields, pipeline-config.schema.json's 2 self-referential field descriptions, and removed Run-WindowsSbom.ps1/Run-LinuxSbom.ps1's false "VIT Super Network Streams is the default" claim. Formally scoped REQ-001's wording to exclude the 2 already-disclosed, intentional, narrow-purpose consumer-vendored exceptions (Build-LvlibpCandidate.ps1, provision-ubuntu-vm.yml's package-build template) instead of treating them as bugs. Marked REQ-001 "Verified (manual)" in the wiki, no longer "NOT met."
• (#69) batch-provision.sh hostname collision: added optional guestHostname/guestFullName fields to runner-inventory.json (schema bumped to @4), wired through to each VM's create-vm dispatch; when omitted, derives a unique, deterministic fallback (an 11-character hash-based hostname, well under Windows's 15-character NetBIOS limit). Live-verified via a real 2-VM dry-run batch (one explicit, one derived, both distinct, full dispatch chain completing for both).
• (#70) 3 sub-findings, all resolved: (1) aligned both containerized SBOM pipelines' ALLOW_PACKAGE_DRIFT default from lenient ("1") to strict ("0"), matching the native pipeline's already-documented fail-closed-by-default behavior -- a real default-behavior change for any consumer relying on the old lenient container default without explicitly setting the variable; (2) wired ci-assurance.yml's new toolchain-smoke-test job to call this repo's own reusable toolchain-smoke-test.yml against itself (uses: ./.github/workflows/toolchain-smoke-test.yml, projectbuddy-ref: ${{ github.sha }}), making REQ-008's "validated via real CI dispatch" claim genuinely true in this repo; (3) authored real Pester fixture tests for Test-SbomArtifact.ps1 (scripts/tests/Test-SbomArtifact.Tests.ps1, 6 tests covering all 3 documented failure classes plus success and a self-contradiction guard), wired into a new pester-tests CI job.
• (#76) Install-VerifiedNugetPackage.ps1 falsely removed: restored the script (confirmed generic/reusable -- a SHA-512-verify-then-extract utility, nothing signing-specific) with a corrected header comment explaining the real history. Added 4 real Pester tests (success, hash-mismatch refusal, missing-archive, already-exists-destination), all passing; also manually verified end-to-end with a real .nupkg. Did not re-wire it into the Dockerfile (the signing toolchain it originally supported stays correctly removed). Courtesy fix in SandboxSBOMReporting itself: updated its stale pin-warning comment (private repo, PR #310, merged).
• (#77) remaining formal-completeness + smaller REQ gaps: added a lightweight Document Control block (Status/Last-update/Owner) to 6 docs lacking one, plus a real Notation + Glossary section to the wiki SRS -- deliberately scoped out a full ISO 29119-3 test-plan rewrite of CONTRIBUTING.md/ci-assurance.yml (risk register, staffing, schedule) as disproportionate for this repo's current maturity. Fixed Enable-RepoIssueTracking.ps1 (REQ-004: gh label create --force, real failures now surfaced, not silently swallowed -- live-verified against the real repo) and New-HumanEscalation.ps1 (REQ-005: verifies the marker is actually present in the returned issue body client-side, not trusting GitHub's search index alone; a search failure now warns instead of silently falling through -- live-verified: real create + real update-in-place on the same issue, confirmed via gh issue view, test issue closed after). Reworded REQ-003/REQ-021/REQ-024 to accurately scope their actual guarantees instead of overclaiming.
• (#80) more Architecture Packet gaps + practice-vs-document gaps: added 7 missing components (Run-WindowsSbom.ps1, Run-LinuxSbom.ps1, Test-Environment.ps1, Test-RunnerAdministrator.ps1, winrm-service-bootstrap-installer.nsi disclosed as an unwired research prototype, Install-VerifiedNugetPackage.ps1) plus 2 new containers (Release automation, Agent orientation) to the Component/Container Views. Fixed the Context View's stale feature/*-only claim and SHA-pinning overclaim. Decision: adopt wiki release-tagging going forward -- added a new Release Flow step tagging the wiki repo at the same vX.Y.Z as each main-repo release (this release is the first, v0.3.31). Reworded Release Flow Step 2 to disclose that CHANGELOG.md is typically already on develop before the release branch is cut. Corrected the wiki's own "branch-then-push, reviewed" claim (cm-plan.md, the wiki's Home page, the SRS) -- real git history shows zero branches were ever used; disclosed honestly instead of left overclaiming.
• (#52/#63) REQ-018/REQ-019 merge + configuration-schema.md dangling refs: merged REQ-019 into REQ-018 (its own Fit Criterion read "Same evidence as REQ-018," failing ISO/IEC/IEEE 29148 §5.2.5's "Necessary" characteristic) -- REQ-019's ID formally retired, every cross-reference updated (REQ-032, the RTM, the Architecture Packet). Repointed configuration-schema.md's 3 dangling references instead of authoring a new doc: Run-Pipeline.ps1's pipeline-config error now cites pipeline-config.schema.json (the real, validated schema); its VIPM_TOML_CONFIGS errors now describe the expected shape inline; add-project.yml's error summary now links to Add-Project.ps1 itself.
• (#62) triaged, not closed: the critical all-phases-blocking bug was already resolved in round 3/4 (restored script, confirmed intentional package-build exception). Explicitly scoped the remaining work (live-dispatch-proving the other 9 phases, which requires a real multi-hour VM-provisioning cycle including a human-interactive LabVIEW activation step) as out of scope for this documentation-focused round -- a good candidate for a dedicated future VM-provisioning session.
• All 6 validation/syntax checks (JSON/YAML/XML/Python/bash/PowerShell) pass across every changed file; the full Pester suite (10 tests) and pytest suite (17 tests) pass; the local release-gate assurance scan shows all 5 required gates still PASS (High confidence, 99-100%), matching the established baseline.

v0.3.30

• fix a real, previously-unnoticed ADR-immutability violation: round 5's own commit edited docs/architecture/adr/ADR-0001-adopt-gitflow-for-release-governance.md's accepted Decision/Consequences text in place, directly contradicting docs/information-item-map.md's own stated Decision Record convention ("a new ADR-NNNN file is added, never edited after acceptance"). Reverted the original accepted text to be byte-identical to its first acceptance commit, and moved round 5's genuinely useful content (the v0.3.28 GitFlow-exception disclosure, the stamp-condition clarification) into a new, clearly-marked, append-only "Addendum" section instead
• fix 2 remaining dangling docs/projectbuddy-consumption.md references round 5 missed when it fixed 2 sibling instances of the identical gap: Run-Pipeline.ps1, Run-Pipeline.sh, Run-WindowsSbom.ps1, and Run-LinuxSbom.ps1 (4 files, all repointed to README.md's real "Consumption model" section)
• fix .github/skills/projectbuddy-identity/ (SKILL.md, agents/openai.yaml): both still asserted the unqualified "ships with zero pre-committed... state" claim after README.md was already corrected in round 5 to honestly disclose the real, tracked violations (#68) -- the same class of sibling-location drift this session keeps finding in this specific file pair
• fix .github/workflows/standards-compliance-recheck.yml's header comment: still said public upstream "deliberately carries zero private infrastructure state" after docs/architecture/standards-compliance.md was corrected for the identical overclaim in round 5 (a real, online vm-provisioner-labeled runner is in fact registered against it)
• fix docs/sbom-pipeline/procedure.md: still claimed both containerized pipelines validate against pipeline-config.schema.json uniformly, contradicting the wiki Architecture Packet's own already-corrected disclosure that the Linux container does its own separate, narrower inline validation instead
• fix docs/vm-provisioning/procedure.md: (1) the receipt-verification-chain paragraph claimed a package-build receipt verifier exists; it doesn't (package-vagrant-box.py validates its input vagrant-box receipt but produces no independently-reverifiable receipt of its own output); (2) the Shared Schemas section implied both VM families' provisioning-manifest.json pin the same binary-hash categories, when Ubuntu's manifest has no Actions-runner/PowerShell/NSSM equivalents (Windows-specific concepts) -- clarified both are family-specific schemas, not one shared shape
• fix docs/release/release-procedure.md's Hotfix Flow: added an explicit disclosure that this flow has never actually been exercised in this repo's real history (zero hotfix/* branches or PRs, ever), matching the same honesty standard already applied elsewhere in this document
• fix the wiki SRS's stale Document Control (Version: Initial draft... as of v0.3.10, Status: Draft) and 2 references to a v0.3.11 tag that was never actually tagged or released (confirmed: tags jump from v0.3.10 to v0.3.13) -- both now cite the real, verifiable commit (c3a36ae) that resolved the spec-to-CI wiring question
• fix the wiki Architecture Packet's Deployment View: round 5's own fix cited one specific, ephemeral historical workflow run ID as its sole evidence for validate-vm-provisioning-dispatch.py's restoration -- directly contradicting this same SRS's own stated evidence-citation principle ("never at one specific historical workflow run ID -- a run ID is ephemeral and does not, by itself, prove anything about the current state of the code"). Reframed to cite the restored script's own reproducible code/logic as the primary evidence, with the historical dispatch noted only as a same-day live confirmation, not the proof itself
• fix the wiki Architecture Packet: disclose that vm-fleet-status.yml's scheduled runs fail differently on the fork (svelderrainruiz/projectbuddy, which has no vm-provisioner-labeled runner at all, so every scheduled run queues and is cancelled) versus on public upstream (which now cleanly no-ops per round 5's fix) -- same root cause as the already-documented standards-review-local pattern, just not previously disclosed for this specific workflow
• fix REQ-010 (wiki SRS) and REQ-013 (wiki RTM): round 5 updated one of each requirement's two sibling locations (SRS or RTM) but not both, leaving the un-updated sibling stale -- REQ-010's SRS row now reflects the same v0.3.28 exception already in its RTM row; REQ-013's RTM row now cites the actually-invoked build-virtualbox.sh instead of the orphaned, never-called .ps1 sibling, matching its own SRS row
• added 2 new, previously-uncited #68 (REQ-001 hardcoded-identifier) violation sites as evidence: vm/windows-labview/unattended-template.xml (a Windows-family instance, 4 hardcoded <Description> fields -- all prior evidence in that issue was Ubuntu-family), vm/ubuntu-labview/provision-guest.sh, and a broader, distinct "sandbox-sbom-reporting/..." schema-namespace-identifier pattern spanning 11 files (flagged with an important nuance: these are versioned, already-publicly-documented schema identifiers, not secrets -- likely an unfortunate namespace-naming choice rather than the same class of bug as the other sites, but still worth a deliberate decision)
• deleted 1 more already-merged stale branch on the fork
• filed #80 (remaining lower-severity findings: more Architecture Packet Component/Container View gaps, Context View staleness around feature/* branch naming and consumer SHA-pinning precision, CM/release-procedure practice-vs-document gaps including the wiki's own lack of tag/commit-SHA binding to main-repo releases, and further ISO 29119-3/15289 formal-completeness instances compounding the already-open #77)
• all findings from this round's --mode semantic-audit pass (same 3-model delegation, explicitly asked to verify whether v0.3.29's fixes held up and hunt for anything neither prior round caught): significantly fewer new defects than prior rounds (expected, 6 rounds deep into hardening the same spec/doc surface), but still real, previously-uncaught sibling-location drift and one genuine process violation (the ADR in-place edit) -- GPT found no new severe issues beyond already-tracked baselines; Gemini and Claude each independently caught several real, previously-missed sibling-drift defects, with meaningful overlap between the two (both independently found the ADR-0001 edit and the standards-compliance-recheck.yml staleness)

v0.3.29

• fix vm-fleet-status.yml's round-4 fix, which was itself incomplete: emitting an empty matrix ({"include":[]}) stopped the jq crash, but GitHub Actions marks the entire workflow run failure whenever a dependent job's strategy.matrix resolves to zero combinations -- a platform behavior the round-4 fix didn't account for (confirmed via real run history: 12 total runs since this workflow existed, 0 successes ever, including runs after the round-4 fix landed). Added an explicit has-vms output so check-vm is skipped entirely via if: when there are no VMs, instead of being handed an empty matrix
• fix .github/workflows/release.yml's "Tag already exists" duplicate-tag check: actions/checkout's default fetch-tags: false meant git rev-parse "$VERSION" could never see a real remote tag, making this safety check dead code since the very first version of this workflow. Replaced with git ls-remote --exit-code --tags origin, verified against both a real existing tag and a nonexistent one
• fix .github/workflows/standards-assurance-scan.yml: it cloned repo-standards-review at floating HEAD instead of the exact SHA this repo's compliance stamp is assessed against (silent drift risk), and its failure condition only checked the req/arch gates, silently ignoring a cm/coverage/doc regression. Pinned the clone to the stamped SHA and widened the failure check to all 5 required gates
• fix the wiki Architecture Packet's Deployment View: round 4's own fix (restoring .github/scripts/validate-vm-provisioning-dispatch.py) was never reflected here -- this section still said the script "does not exist" and every phase fails, directly contradicting round 4's own code change. Corrected to reflect the restoration, cited a real, first-ever successful validate-phase dispatch (VITechnologies/projectbuddy run 42335965127) as positive evidence, and noted package-build remains blocked by design (consumer-vendored script), not by a missing file
• fix 2 new dangling docs/projectbuddy-consumption.md references introduced by round 4's own fix (a file already known-missing and tracked in #63) -- repointed both to README.md's real "Consumption model" section instead of making the same gap worse
• fix .github/skills/projectbuddy-identity/ (SKILL.md and agents/openai.yaml): both still described Run-Pipeline.sh as a native SBOM pipeline entry point, claimed nonexistent teardown/enable-vrde phases for provision-windows-labview-vm.yml (the real phases are validate/create-vm/install-vipm/install-labview/register-runner, exactly 5), and showed the reusable-workflow consumption pattern as @<tag> instead of @<commit-sha> # <tag> -- the same class of defect fixed elsewhere in rounds 1-4, never caught in this agent-orientation file specifically until now
• fix docs/architecture/standards-compliance.md: it conflated two separate workflows, attributing standards-compliance-recheck.yml's "Compare Stamped Version Against Latest" step to standards-assurance-scan.yml (which doesn't have that step); and claimed public upstream VITechnologies/projectbuddy "carries zero private infrastructure state" when it in fact has a real, online vm-provisioner-labeled self-hosted runner registered directly against it (the zero-state claim was about pre-committed configuration, not every runner ever registered)
• fix REQ-002 (wiki): still listed "ISO paths" as a required-with-no-default identity value after round 4 corrected this same overclaim in README.md/the Architecture Packet; fix REQ-001 (wiki): stopped asserting "Verified (manual)" against a Fit Criterion now known false (#68); fix REQ-010 (wiki RTM): reflects the one disclosed v0.3.28 GitFlow exception rather than an unqualified "Verified"; fix REQ-013 (wiki): its cited evidence script (vm/windows-labview/build-virtualbox.ps1) is never actually called by any real workflow (confirmed via a repo-wide reference search) -- provision-windows-labview-vm.yml calls the sibling .sh script instead, which independently implements the same ISO SHA-256 guard the requirement describes
• fix provision-windows-labview-vm.yml's guest_full_name/guest_hostname inputs: their own description text read "...no built-in default); required for create-vm" directly beside required: false and a real default value -- a literal self-contradiction in the same file. Also noted the cross-workflow inconsistency with provision-ubuntu-vm.yml, which marks the same conceptual fields required: true
• fix docs/vm-provisioning/procedure.md's opening paragraph: claimed both VM families "share one discipline" requiring every identity value as workflow_dispatch-required, which is false (the two families disagree on guest_full_name/guest_hostname required-ness) and incorrectly grouped the ISO path in with identity values despite it having a legitimate generic default
• fix docs/cm/cm-plan.md: added v0.3.0 to the tag/CHANGELOG mismatch disclosure (round 4 only caught v0.2.2); disclosed the v0.3.28 GitFlow release-flow exception (a non-release PR landed directly on main after its release branch's own promotion, discovered mid-round while testing this round's own release.yml fix); noted the Hotfix Flow has never actually been exercised in this repo's real history; added a cross-reference for ISO/IEC/IEEE 12207 configuration-audit outcome (e) to this repo's own semantic-audit pipeline
• fix docs/release/release-procedure.md and docs/architecture/adr/ADR-0001-adopt-gitflow-for-release-governance.md: added the same v0.3.28 exception disclosure and an explicit tagging-order rule to reduce recurrence; clarified ADR-0001's "every document carries a stamp" condition means coverage by the one canonical stamp, not N independent copies, and added real cross-references from cm-plan.md/release-procedure.md to that canonical stamp
• live-verified this round's provision-ubuntu-vm.yml/release.yml/standards-assurance-scan.yml fixes via real dispatches, not just local simulation (first-ever successful provision-ubuntu-vm.yml dispatch; a real draft-then-published release created end-to-end by the fixed release.yml; a fresh, successful standards-assurance-scan.yml run against current content)
• filed #76 (round-4's v0.3.24 CHANGELOG entry falsely claimed Install-VerifiedNugetPackage.ps1 had "zero consumers anywhere in the pipeline" -- SandboxSBOMReporting's batch-pipeline.yml calls it directly for a legitimate, unrelated purpose; added a protective warning at that repo's PROJECTBUDDY_REF pin site) and #77 (remaining lower-severity findings: formal ISO 29119-3/15289 document-template completeness, further Architecture Packet component gaps, and 4 smaller REQ-level precision gaps)
• cleaned up 10 already-merged, undeleted sync branches on the fork
• all findings from this round's --mode semantic-audit pass (same 3-model delegation, explicitly asked to verify whether v0.3.28's fixes held up and hunt for anything neither prior round caught): both GPT and Gemini independently found the same critical vm-fleet-status.yml empty-matrix regression and the same wiki self-contradiction; Claude independently confirmed both via real run-history queries and found 2 additional previously-uncaught defects (release.yml's dead tag-check, REQ-013's orphaned evidence citation)

v0.3.28

• fix a real, residual gap in v0.3.27's own REQ-017 fix: only 1 of the 5 credential-cleanup sites in provision-windows-labview-vm.yml (create-vm) had actually been moved trap-before-write despite the v0.3.27 CHANGELOG/compliance stamp claiming all 5 were fixed; the other 4 (Attach Installer Media And Restart, install-vipm, install-labview, register-runner) still wrote credential file(s) before installing the trap -- fixed all 5, re-verified with an automated step-boundary scanner (not manual re-reading, since manual reading had already missed this once) plus a live bash simulation of the exact failure scenario
• fix .github/scripts/validate-vm-provisioning-dispatch.py: restored this genuinely generic dispatch-contract validator to this engine, which was missing from the original ProjectBuddy extraction (confirmed by its real, unmodified presence in the VITechnologies/SandboxSBOMReporting consumer repo) -- provision-ubuntu-vm.yml's "Validate Dispatch Contract" step previously failed unconditionally on every phase for every dispatch because this script did not exist here; local simulation confirms the step now passes for representative validate-phase inputs. vm/ubuntu-labview/build-vip-package.sh remains deliberately absent (confirmed as an intentional, disclosed, consumer-vendored exception, not a dropped file like the validator was) -- added an explicit doc comment to the package-build phase clarifying this (#62 updated with the corrected root cause)
• fix .github/workflows/release.yml: it interpolated ${{ steps.changelog.outputs.notes }}/${{ inputs.version }} directly into run: script bodies -- an expression-injection anti-pattern under a contents: write token, reproduced as a real bash syntax error using v0.3.27's own CHANGELOG entry (18 embedded double quotes). Rewrote to pass all inputs via env: and write release notes to a file for gh release create --notes-file, verified end-to-end against the real v0.3.27 entry
• fix vm-fleet-status.yml: its generate-matrix job called jq directly on runner-inventory.json, which is never committed in this public engine repo by design -- every scheduled run failed with a jq: error: Could not open file (confirmed via real run logs). Now emits an empty matrix and a clear ::notice:: instead of failing when the file is absent
• fix README.md: (1) the "every VM identity value... no built-in default" claim (script-level build-virtualbox.ps1/.sh parameters) didn't account for Iso/GuestUser/WinRmHostPort genuinely having generic, non-identity defaults; (2) vm-fleet-status.yml was incorrectly grouped with the two provisioning workflows as taking "every real identity value" as an explicit input, when it actually takes zero workflow_dispatch inputs; (3) the "zero pre-committed project configs" claim is contradicted by real, tracked violations (#68) -- added an explicit caveat; (4) the "never vendored/copied script files" claim omitted the already-accepted #48 exception for workflow_dispatch-only workflows, which a consumer genuinely vendors its own copy of
• fix Run-Pipeline.ps1: its own Linux-guard error message said "On Linux, use Run-Pipeline.sh", actively pointing users at a script this same session already established is not a SBOM pipeline at all
• fix docker/linux-sbom/linux_sbom_pipeline.py: the Grype gate stage recorded gate="passed" even when GRYPE_FAIL_ON=none (i.e. not actually gated), diverging from the Windows container pipeline's more honest "not-gated" status for the same situation -- aligned Linux's reporting to match
• fix .github/workflows/ci-assurance.yml: pinned previously-unversioned pip/pytest/pytest-cov/pyyaml installs to the exact versions a real recent CI run proved against, and fixed a dangling docs/requirements/srs.md reference (that path only exists ephemerally during an active standards-assurance-scan.yml run, not as a permanently committed file) in both this workflow and scripts/tests/test_convert_vipb_json.py's docstring, pointing both at the wiki's real, permanent SRS location instead
• fix docs/cm/cm-plan.md, CONTRIBUTING.md, and wiki REQ-010: the merge-back-to-develop no-op exception added in v0.3.27 was only documented in docs/release/release-procedure.md -- propagated the same caveat to the other 3 places that described merge-back as unconditional
• fix docs/cm/cm-plan.md's "every release" audit-trail claim: didn't account for pre-GitFlow releases (before v0.3.9), which were tagged under the prior trunk-based model per ADR-0001 and have no release/* branch ancestry
• fix docs/release/release-procedure.md: (1) the GitFlow Branch Rules summary's hotfix merge-back bullet read as an either/or between develop and an active release branch, when the detailed Hotfix Flow steps are additive (always develop, plus an active release branch if one exists); (2) the Feature Flow only documented the older sync-from-fork-<date> branch-naming pattern, omitting the sync-upstream-develop-*/sync-upstream-main-vX.Y.Z patterns actually used in recent practice, and never explained the post-release fork-sync step that is why develop/main are usually already content-identical by the merge-back step
• fix the wiki Architecture Packet: (1) the Deployment View's Ubuntu-lifecycle caveat only said the package-ready snapshot was unreachable, when in fact every phase was unreachable (same root cause, now partly fixed above); (2) still called VIPM activation "LabVIEW-gated" after v0.3.27's own REQ-032 correction established it isn't; (3) the Component View's internal/Pipeline.Stages.ps1 row claimed 8 ordered stage functions including a preceding "policy gate" stage, when there are 6, and the policy-gate check is a helper called at the end of Publish-DependencyTrack, not a separate preceding stage; (4) the package-vagrant-box.py/receipt-scripts row claimed a package-ready receipt verifier exists; it doesn't; (5) the vipm-exit-codes.json/pipeline-config.schema.json row claimed both the native and both containerized pipelines validate against the schema, but the Linux container pipeline does its own separate, narrower inline validation instead; (6) the build-virtualbox.ps1/.sh rows repeated the same no-default overclaim fixed in README above; (7) added 6 previously-undocumented components to the Component View (batch-provision.sh, Register-WindowsRunner.ps1, Register-WslRunnerKeepAlive.ps1, Test-SbomArtifact.ps1, scripts/Test-ToolchainPresence.ps1+toolchain-smoke-test.yml, scripts/Convert-VipbJson.py)
• fix docs/vm-provisioning/procedure.md: resolved a dangling "tracked as a follow-up gap" reference for the hostname-collision risk (no issue actually tracked it) by filing #69 and linking it; added a reachability caveat to the Ubuntu lifecycle phase list matching the Architecture Packet fix above
• file #68: a broader, previously-untracked REQ-001 violation -- hardcoded project-specific identifiers in Register-WslRunnerKeepAlive.ps1, vm/ubuntu-labview/base-bootstrap.sh and 5 other scripts sharing its /SandboxSBOMReporting/SshHostEd25519Fingerprint guest-property path, and Run-WindowsSbom.ps1/Run-LinuxSbom.ps1's own .DESCRIPTION text -- beyond what #62 already tracked
• file #69: batch-provision.sh gives every VM in a batch the same in-guest hostname/full name (a real collision risk, not safely auto-fixable given Windows's 15-character NetBIOS hostname limit)
• file #70: ALLOW_PACKAGE_DRIFT's default is opposite between the native pipeline (off) and both containerized pipelines (on); REQ-008/REQ-009's "validated via real CI dispatch instead" justification doesn't hold for toolchain-smoke-test.yml (never actually called in this repo) or Test-SbomArtifact.ps1 (pure offline code, never fixtured); compliance-scan "Known tradeoffs" correspondence overclaims its own evidence strength for physical-host/PDF-corpus claims
• all findings from this round's --mode semantic-audit pass (same 3-model delegation, explicitly asked to verify whether v0.3.27's fixes held up and hunt for anything neither prior round caught): 2 real regressions found and fixed (the REQ-017 trap-ordering miss above, and this round's own corrected root-cause for #62); #62/#63 updated with corrected evidence

v0.3.27 — round-3 semantic-audit findings (verification pass)

v0.3.27

• fix a real, residual gap in v0.3.26's own REQ-017 fix: 2 of the 5 trap ... EXIT installations wrote their credential file(s) before installing the trap, so a failure during file creation itself (e.g. the register-runner step's PAT-file creation) could still leave an earlier-written file behind -- moved every trap installation to the very first executable line of its step, before any file is created, since rm -f/shred -u on a not-yet-created file are safe no-ops
• fix REQ-032 (wiki) and docs/vm-provisioning/procedure.md: the previous round claimed VIPM's automated activation is "gated on the operator having already completed LabVIEW's own interactive activation" -- this is false. capture-activation.sh runs VIPM activation unconditionally whenever a VIPM env file is supplied, with no check of LabVIEW's actual activation state; the precondition is a documented operator convention (the phase's usage text), not a runtime-enforced gate. Also corrected the real call chain (activate-vipm.sh is invoked by capture-activation.sh, not directly by complete-activation.sh)
• fix README.md: a second, still-present instance of the "LabVIEW/VIPM activation is human-only" overclaim (line 78, a different passage than the one already fixed) and a reintroduced "every ... required input" overclaim contradicting the same round's own "no built-in default" fix
• fix the wiki Architecture Packet: the Container/Component View tables still described Run-Pipeline.ps1/.sh together as the "Native SBOM pipeline" -- split into two rows, with Run-Pipeline.sh correctly described as the unrelated LabVIEWCLI tool it actually is (README.md/docs/sbom-pipeline/procedure.md were fixed in v0.3.26, the wiki was not)
• fix the wiki Architecture Packet's Deployment View: no longer asserts the Ubuntu package-build/signed-.vip capability is proven, since provision-ubuntu-vm.yml's package-build phase cannot currently succeed (#62, open)
• fix wiki REQ-007: still listed Run-Pipeline.sh as a "native SBOM pipeline script" with Dependency-Track fail-closed behavior it doesn't implement (same class of gap as the Architecture Packet fix above)
• fix docs/vm-provisioning/procedure.md's "no built-in default" wording: disclosed a real gap the previous round's correction didn't go far enough to catch -- batch-provision.sh never overrides guest_hostname/guest_full_name per VM, so every VM it creates in a single batch gets the identical in-guest hostname (vm-builder.local), a real same-hostname collision risk, not just a cosmetic placeholder
• fix docs/sbom-pipeline/procedure.md's ALLOW_PACKAGE_DRIFT default claim: it said =1 was the default; the real code only treats it as true when explicitly set to the literal string "1", so the real default is off
• fix docs/cm/cm-plan.md's unrendered [[Home]] wiki-link syntax (only the wiki itself supports [[...]]; replaced with a real link)
• fix docs/release/release-procedure.md: documented the already-practiced, legitimate no-op exception for the release/vX.Y.Z -> develop merge-back step when develop/main are already content-identical (this is what v0.3.24-v0.3.26 actually did, correctly, but the procedure didn't say so)
• fix the published v0.3.26 GitHub release notes, which were truncated by one bullet relative to the full CHANGELOG.md entry (a copy/paste range error, not a code change -- release notes text is editable, unlike the tag/assets)
• fix docs/information-item-map.md's baseline (bumped to this version)
• all findings from this verification-focused re-run of repo-standards-review@v0.2.23's --mode semantic-audit (same 3-model delegation, explicitly asked to verify whether v0.3.26's fixes actually held up): most of v0.3.26's fixes were confirmed genuinely SOLID this round (REQ-013/017/018/025/030, the Run-Pipeline.sh fix in README/sbom-pipeline docs, the CM Change Control disclosure); the gaps above are what a single-pass fix missed. #62/#63 updated with additional evidence (a REQ-001-violating hardcoded package name in the same broken package-build phase; a missing docs/projectbuddy-consumption.md; REQ-013's dangling "tracked separately" reference, now actually linked)

v0.3.26 — round-2 semantic-audit fixes

v0.3.26

• fix REQ-017 (again): provision-windows-labview-vm.yml's credential-file cleanup only ran on the success path (set -euo pipefail means an earlier failure skips the end-of-step shred line entirely) -- replaced every end-of-step cleanup with a trap ... EXIT right after each file is written, so cleanup now fires on any exit path, success or failure, verified locally that explicit exit codes are preserved through the trap
• fix a real, 3-model-consensus documentation defect: docs/sbom-pipeline/procedure.md and README.md both mischaracterized Run-Pipeline.sh as "the native Linux SBOM pipeline" -- it is actually a separate, unrelated LabVIEWCLI MassCompile/VI Analyzer tool for NI's own example VIs, with zero SBOM/VIPM/Grype/DT stages (confirmed directly against the script's own header comment); there is no native Linux SBOM pipeline in this repo today, only the containerized one
• fix docs/sbom-pipeline/procedure.md's native-pipeline stage list: added the missing "Packages" stage (build.packages, vipm lock, signed builds), and corrected the Policy-gate/Publish stage ordering (Publish-DependencyTrack calls Test-PipelinePolicyGate internally as its last action, not as a separate preceding stage)
• fix docs/vm-provisioning/procedure.md's Ubuntu-LabVIEW complete-activation description: VIPM activation is genuinely automated (activate-vipm.sh's vipm activate --direct-vipm-io, per REQ-032), only LabVIEW activation stays human-only -- the doc previously claimed both stayed human-only, the same scope error already fixed in the wiki SRS
• fix docs/vm-provisioning/procedure.md's overclaimed "no built-in default" wording: several workflow_dispatch inputs do carry generic placeholder defaults (e.g. vm_name's example-windows11-labview2026-myproject); none default to any real fork's actual identity, which was the real intent, but the literal wording was inaccurate
• fix docs/cm/cm-plan.md's Change Control table: disclosed the real gh pr merge --admin bypass mechanism already documented in CONTRIBUTING.md, which the CM plan's "Operator review of the PR" claim omitted entirely
• fix docs/information-item-map.md's stale Baseline: v0.3.11 (14 releases stale)
• fix README.md's reusable-workflow pinning-format claim to match the real, recommended @<commit-sha> # <tag> format (it said @<tag> only, contradicting its own adjacent "Directly-invoked scripts" bullet and toolchain-smoke-test.yml's own canonical example)
• narrow wiki SRS REQ-013's wording to the base-OS ISO specifically (the auxiliary NSIS/service-bootstrap bootstrap media it also implied coverage for is only existence-checked, not hash-verified -- a known, separately-tracked gap, #63)
• all findings from this round found by repo-standards-review@v0.2.23's --mode semantic-audit, run across all 5 areas (REQ/ARCH/TEST/CM/DOC) with 3 independent models (Claude Opus, GPT-6-astra, Gemini-4-argon); the single most significant finding (provision-ubuntu-vm.yml has zero total dispatches ever and references 3 scripts that have never existed in this repo) needs an operator decision before it can be fixed -- filed as #62; #63 tracks 2 smaller follow-ups

v0.3.25 — verify LabVIEW installer ISO SHA-256 before attaching

v0.3.25

• fix install-labview: verify the supplied LabVIEW installer ISO's SHA-256 against provisioning-manifest.json's pinned labview.installer.sha256 before attaching it, fail-closed on mismatch -- previously this phase attached the operator-supplied ISO with no verification at all, unlike install-vipm's existing fail-closed check, even though the manifest already pinned the exact expected hash (#38). Real-dispatch validated against an actual VM: confirmed the valid-hash path installs LabVIEW successfully end to end, and the mismatched-hash path fails closed before any VM is touched

v0.3.24 — remove unused signing toolchain + document VIPM activation

v0.3.24

• remove docker/windows-sbom/'s unused code-signing toolchain (Install-SigningTools.ps1, Install-VerifiedNugetPackage.ps1, and their Dockerfile COPY/RUN lines): a complete, self-verifying SignTool/Azure-Artifact-Signing install with zero consumers anywhere in the pipeline since the very first commit (v0.2.0) -- the .lvlibp output this would plausibly sign is already trusted downstream via GitHub's in-toto release attestation chain, not a code-signing certificate, so this was unconnected scaffolding adding real image-build time and an unused native-DLL load for no current benefit. Removing it in favor of adding it back deliberately, with real wiring and tests, if a genuine signing requirement ever materializes (#44 finding 1)
• document the containerized pipeline's VIPM Pro activation flow in docs/sbom-pipeline/procedure.md: both docker/linux-sbom/entrypoint.sh and docker/windows-sbom/entrypoint.ps1 require VIPM_SERIAL_NUMBER/VIPM_FULL_NAME/VIPM_EMAIL and activate VIPM Pro via vipm activate --direct-vipm-io on every container start unless SBOM_SOURCE=manifest, redacting the serial number from error output and unsetting all 3 variables before the pipeline itself runs -- previously undocumented (#44 finding 2)

v0.3.23 — REQ-017/030 fixes + semantic-audit SRS corrections

v0.3.23

• fix REQ-017: the guest/WinRM password file written during Windows LabVIEW VM provisioning was never shredded/removed anywhere in the workflow (only an unrelated PAT file was) -- added a shred (with rm -f fallback) cleanup line to every step in provision-windows-labview-vm.yml that writes it
• fix REQ-030: add-project.yml's upsert only replaced the first matching entry by project name, so a pre-existing duplicate entry would survive a re-registration instead of collapsing to one -- now filters out every matching entry before appending the fresh one
• correct REQ-013, REQ-018/REQ-019 (narrowed "LabVIEW/VIPM" to "LabVIEW" -- VIPM activation on the Ubuntu-LabVIEW family is genuinely automated and deliberately so, now its own REQ-032), and REQ-025 wiki SRS/RTM/Architecture-Packet wording to match the real code they cite -- all found by this session's multi-model semantic audit (#52) cross-checking the SRS against the real ISO/IEC/IEEE 29148:2018 clause text and the real repo source, not just the heuristic repo-standards-review pattern-match score
• fix a second instance of the same self-referential DoD false-positive bug class: CHANGELOG.md's own v0.3.22 entry (describing the first fix) quoted the exact literal CI-context string the DoD rule detects, re-triggering a false DoD PASS -- rephrased the same way, without reproducing the matched string
• re-certify the compliance stamp against repo-standards-review@v0.2.23 (adds the canonical multi-model semantic-audit mode used to find the REQ findings above): all 5 required gates still PASS, High confidence (99-100%); DoD correctly back to its real FAIL (not required)/60% state once the self-referential false positive above was fixed

v0.3.22 — Re-certify against repo-standards-review v0.2.22

• fix a self-referential false-positive: docs/architecture/standards-compliance.md's own explanatory prose quoted the literal DoD Gate / dod CI-context string, which was itself matching repo-standards-review's detection rule and producing a false DoD PASS -- rephrased without reproducing the exact matched string, same class of bug already fixed in repo-standards-review's own references/scoring-rubric.md
• re-certify the compliance stamp against repo-standards-review@v0.2.22 (two releases stale at v0.2.20): all 5 required gates still PASS, now with genuinely differentiated High confidence (99-100%) instead of a flat ceiling, following v0.2.22's fix for confidence_score's saturation flaw