docs: specify Epic 250 native qualification gates
Split governed specification hubs into linked pages
Restructure the four governed hubs (System Requirements Specification,
Software Requirements Specification, Requirements Traceability Matrix,
Architecture Packet) into index-only hubs plus one page per SYS-REQ,
REQ, and TEST ID and one page per architecture section, so the wiki
reads as a linked graph in Obsidian and on GitHub.
scripts/Assemble-WikiSpec.py (VITechnologies/projectbuddy#171) rebuilds
all four hubs byte-identically from these pages for the standards scan.
Home gains a Structure section describing the layout and link rules.
Refs VITechnologies/projectbuddy#169
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add governed system requirements specification
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Specify Docker-bracketed release conveyor
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add REQ-039: release gate requires VM-creation + runner-registration proof
Per ADR-0006 (revised after 3-model consensus review). Planned until
#110 (Windows register-runner live-proof) completes and the gate's
actual release.yml implementation lands.
Add REQ-038: Ubuntu register-runner phase parity with Windows
Implementation merged via VITechnologies/projectbuddy#106 (issue #105).
Marked 'implementation complete; live verification pending' until a real
workflow_dispatch produces a runner independently confirmed online via
gh api (dispatch in progress: a fresh disposable VM build, upstream run
42400820191, is running specifically for this purpose).
- SRS REQ-038 added
- RTM row added
- Architecture Packet Component View row added (install-actions-runner.sh,
complete-runner-registration.sh)
Promote REQ-037 to Active: Decode-LbaCapture.py implemented and verified
- scripts/Decode-LbaCapture.py implemented per #102, 23 synthetic-fixture
pytest tests (99% line coverage), real verification run against the
genuine run-1794072448721 capture (reproduces the 31.724 MB/s peak-write
finding at frame 432, reports zero false anomalies on this healthy
capture per ADR-0005's Addendum correction)
- Architecture Packet: Container View row for 'Agent diagnostics' no
longer 'planned'; added matching Component View row
- RTM REQ-037 row updated to Verified (live)
Add ADR-0005: agentic decoding of labview-benchmark-actor capture output
- REQ-037 (Planned): dedicated read-only decoding tool for
labview-benchmark-actor capture output, agent/operator diagnostic use
only, schema-pinned to labview-benchmark-actor/launch-capture@1
- RTM row for REQ-037, tracked via #102
- Architecture Packet: ADR-0005 index entry + planned Container View row
for 'Agent diagnostics'
Grounded in this session's real capture analysis (run-1794072448721):
found the MCP viewer tools show fixed demo data regardless of new
captures, no upstream 'latest capture' pointer exists, resources.disk is
a flat array (richer per-disk/per-frame data lives in the top-level
frames[] array instead), and all 631 frames had a null dhashHex.
Record #94 verification review findings and #97 fix-round re-verification
REQ-034/REQ-035/REQ-036: append fresh upstream re-verification evidence
after #97's fix round (missing engineCommit, report-completeness gap,
suite-commit validation, Linux VIPM-detection paths, installMethod
manifest value, ADR-0004 waiver authorization, Xvfb documentation
overclaim). Fresh runs reproduce the same PASS results as before the fix,
now also recording engineCommit correctly.
Refs VITechnologies/projectbuddy#94, #95, #96, #97
Correct SRS/Architecture Packet per ADR-0003's pre-implementation consensus review
Rewrites REQ-033/034/035, adds REQ-036 (Linux feasibility spike split from
execution), to fix: embedded implementation detail in requirement text,
REQ-035's non-self-contained dependency on REQ-034, the premature
'verified-working' claim, and the undecided runner-class gap -- all
independently flagged by 3 models (Claude Opus, GPT-6-astra,
Gemini-4-argon) reviewing ADR-0002 before any implementation began.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add REQ-033/034/035: ephemeral-container LUnit release gate (planned, ADR-0002)
Spec-first per this wiki's own Constraints section: requirements added
before the corresponding code change (tracked in #87) is merged. Also
adds a planned Container View entry for the new capability.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Register ADR-0002 in the ADR Index and Related links
Adopts ephemeral-container LUnit test execution as a release gate,
modeled on ni/labview-icon-editor#575. See docs/architecture/adr/ADR-0002
in the main repo for full context.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Operator-resolve wiki-side findings from all 9 milestone issues
- REQ-001: formally scoped to exclude 2 disclosed narrow-purpose
exceptions; marked Verified (manual), no longer NOT met.
- REQ-003/004/005/021/024: reworded to accurately scope real guarantees.
- REQ-010/REQ-013: fixed sibling-location drift (SRS vs RTM).
- REQ-018/REQ-019: merged (REQ-019's own Fit Criterion read 'Same
evidence as REQ-018', failing 29148 Necessary); REQ-019 formally
retired, every cross-reference updated.
- Added Notation + Glossary sections to the SRS.
- Architecture Packet: added 7 missing components + 2 new containers
(Release automation, Agent orientation); fixed Context View staleness
(feature/* branch claim, SHA-pinning overclaim); reframed the
validate-vm-provisioning-dispatch.py evidence citation to not rely on
a single ephemeral run ID, contradicting the SRS's own stated
principle; disclosed vm-fleet-status.yml's distinct fork-specific
failure mode; fixed the renamed projectbuddy/* schema namespace
reference; fixed the Test-SbomArtifact.ps1 'only unit-tested code'
stale claim.
- Home.md + cm-plan.md (main repo) + SRS Constraints: corrected the
wiki's own 'branch-then-push, reviewed' overclaim -- real git history
shows zero branches were ever used; disclosed honestly.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix round-6 semantic-audit findings in wiki (Architecture Packet, SRS, RTM)
- Deployment View: reframe the validate-vm-provisioning-dispatch.py
restoration evidence to cite the script's own reproducible code/logic
as primary evidence, not a single historical run ID -- this SRS's own
evidence-citation principle explicitly says a run ID 'is ephemeral and
does not, by itself, prove anything about the current state of the
code', which round 5's own fix had directly contradicted.
- Deployment View: disclose vm-fleet-status.yml's distinct fork-specific
failure mode (no vm-provisioner runner registered, so scheduled runs
queue and are cancelled), separate from upstream's clean no-op.
- Document Control: fix stale 'Initial draft... v0.3.10'/'Draft' status;
fix 2 references to a v0.3.11 tag that was never actually released.
- REQ-010 (SRS): reflect the v0.3.28 exception already in its RTM row.
- REQ-013 (RTM): cite the actually-invoked build-virtualbox.sh instead
of its never-called .ps1 sibling, matching its own SRS row.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix round-5 semantic-audit findings in wiki (Architecture Packet, SRS, RTM)
- Deployment View: fix self-contradiction with round-4's own code fix
(said validate-vm-provisioning-dispatch.py 'does not exist' in the
same round that restored it); cite a real, first-ever successful
validate-phase dispatch as positive evidence.
- Component View: fix the shared VIPM-exit-codes/schema validation row
(Linux container pipeline does its own separate inline check, not
pipeline-config.schema.json); fix the build-virtualbox no-default row.
- REQ-001: stop asserting 'Verified (manual)' against a Fit Criterion
now known false (#68). REQ-002: remove the stale 'ISO paths, etc.'
no-default overclaim (round 4 fixed this in README/Architecture
Packet but not here). REQ-010: reflect the one disclosed v0.3.28
GitFlow exception. REQ-013: cite the actually-invoked
build-virtualbox.sh instead of the orphaned .ps1 sibling.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix round-4 semantic-audit findings in wiki (Architecture Packet, SRS)
- Deployment View: all Ubuntu phases were unreachable, not just
package-ready (#62's full scope); VIPM activation is not actually
LabVIEW-gated at runtime (REQ-032 correction propagated here).
- Component View: Pipeline.Stages.ps1 has 6 stage functions, not 8,
and the policy gate is a helper inside Publish-DependencyTrack, not
a preceding stage; no package-ready receipt verifier exists;
pipeline-config.schema.json is not validated against by the Linux
container pipeline; build-virtualbox.ps1/.sh no-default claim
corrected; added 6 previously-undocumented components.
- REQ-010: Fit Criterion now accounts for the no-op merge-back
exception.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix round-3 semantic-audit findings (REQ-007/032, Architecture Packet)
A verification-focused re-run of this session's multi-model semantic
audit found real residual gaps from the previous round's wiki fixes:
- REQ-032: corrected a false claim that VIPM's automated activation is
"gated on the operator having already completed LabVIEW's own
interactive activation" -- 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.
- REQ-007: still listed Run-Pipeline.sh as a "native SBOM pipeline
script" with Dependency-Track fail-closed behavior it doesn't
implement (it's a separate, unrelated LabVIEWCLI tool -- the same
class of gap already fixed in README.md/docs/ in the previous round,
just missed in this specific SRS row).
- Architecture Packet Container/Component Views: 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 tool it actually is.
- Architecture Packet 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
(VITechnologies/projectbuddy#62, open).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix semantic-audit findings: REQ-013/017/018/019/025/030 + add REQ-032
Corrects 6 real spec-accuracy gaps found by this session's multi-model
semantic audit (projectbuddy#52), each independently verified against
the real repo source before fixing:
- REQ-013: Fit Criterion/Verification referenced the wrong check
(provision-windows-labview-vm.yml's VIPM-installer hash, not the
Requirement's own claim about build-virtualbox.ps1/.sh's base-OS ISO
hash). Now cites the real, matching check in both scripts.
- REQ-017: broadened Fit Criterion/Verification to the now-complete
guest/WinRM-password-file + PAT-file cleanup (see the matching code
fix in VITechnologies/projectbuddy#52 finding 2).
- REQ-018/REQ-019: narrowed from "LabVIEW/VIPM" to "LabVIEW" -- VIPM
activation on the Ubuntu-LabVIEW family is genuinely automated via
activate-vipm.sh's non-interactive activation call, which contradicted
the broader wording. Fixed REQ-019's broken cross-reference (was
"Same evidence as REQ-017", should be REQ-018) and its Verification
column's inaccurate claim that complete-activation never performs
activation itself (true for LabVIEW, false for VIPM).
- REQ-025: Requirement wording now matches its own Fit Criterion's real
logic (completed failed-gate state, not an in-progress running stage).
- REQ-030: Requirement/Fit Criterion/Verification now describe the real
fix (filter all matching entries before appending, not a first-match
lookup) so duplicate pre-existing entries are actually guaranteed to
collapse to one.
- New REQ-032 documents VIPM's deliberate, narrower automated-activation
exception to REQ-018/REQ-019, so the SRS no longer has an unscoped
LabVIEW/VIPM claim that one real code path contradicts.
Corresponding code fixes shipped in VITechnologies/projectbuddy
(fix/semantic-audit-findings-req017-req030 branch): guest/WinRM
password-file shredding added to every write site in
provision-windows-labview-vm.yml, and add-project.yml's upsert logic
now filters all matching entries instead of a first-match lookup.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Correct previous commit's mistaken 'known gap' framing for project registration
The previous commit (efe497f) incorrectly characterized Add-Project.ps1
calling .github/scripts/validate-project-registration.py and
project_runtime.py as a bug ('both scripts are missing, registration
cannot work'). This missed Add-Project.ps1's own explicit design
comment: those two validators 'stay local-only to each consumer (never
published here)' -- deliberately, since credential-reference and
runtime-compatibility rules are consumer-specific, not generic. This
engine intentionally ships add-project.yml as a template a consumer
vendors into their own repo alongside their own validator scripts, not
something run directly from this repo with generic validators baked in.
Corrected the Architecture Packet's Component View row to describe this
template/by-convention relationship accurately instead of implying a
broken call chain. REQ-030/REQ-031 (added in the previous commit) are
unaffected -- they describe the upsert and Issues-enablement logic,
which is genuinely implemented and working regardless of this
correction.
The operator caught this mistake live; VITechnologies/projectbuddy#48
(filed on the same incorrect premise) is being corrected/closed
separately.
Add REQ-030/031 (project registration upsert + Issues-enablement safety); disclose broken validator call chain in Architecture Packet
Found while applying the spec-driven reproducibility audit to project
registration (VITechnologies/projectbuddy#48): add-project.yml and
Add-Project.ps1 both call a credential-reference validator and a
runtime validator that have never existed in the repository, meaning
registration cannot currently succeed for any input. Not something the
SRS can honestly claim as a verified 'shall' (it doesn't work), so
instead:
- Added REQ-030/REQ-031 for the two genuinely-verified parts of the
registration flow this audit also confirmed (name-keyed upsert logic;
the Issues-enablement side effect's never-fail-the-registration
guarantee), each single-shall-verified against the real code.
- Updated the Architecture Packet's Component View to show the real
call graph (Add-Project.ps1 does call a credential validator and a
runtime validator) while pointing at the main repo's new
docs/project-registration/procedure.md for the current-state detail,
matching this wiki's existing split (verified structure/requirements
here; known-gap disclosure in the main repo's procedure docs, same as
#38's handling in docs/vm-provisioning/procedure.md).
Verified locally via the assurance-workbench Docker image before
pushing: all 5 required gates still PASS/High, requirements_quality_check.py
reports zero findings.
Fix #35: resolve stale CI-integration text + remove ephemeral run-ID citations
Closes VITechnologies/projectbuddy#35: the SRS's Assumptions section
pointed readers to the Architecture Packet's Correspondence And
Rationale section for 'the wiring question still open at
ci_integration=not_yet_sure' -- but that section never actually
discussed it. Added the real resolution there (standards-assurance-
scan.yml, merged v0.3.11) and updated the SRS's own text to stop
describing it as open.
Also acts on new operator guidance: workflow run logs/summaries are
ephemeral and must never be cited as 'the evidence' in persistent
documentation. Replaced the one bare workflow-run-ID citation
(REQ-011's Verification/TestArtifact columns, run 42196529270) with a
description of the reproducible mechanism itself (re-runnable via
workflow_dispatch) instead. Updated the RTM's 'Verified (live)' legend
definition to state this principle explicitly, so future additions
follow it without re-litigating the question.
Add real SBOM-pipeline requirements/architecture coverage (VITechnologies/projectbuddy#32)
Closes the same shallow-coverage pattern #29 closed for VM provisioning,
this time for the native + containerized SBOM pipeline (~2900+ lines
across Run-Pipeline.ps1, Build-Sbom.ps1, internal/Pipeline.Stages.ps1,
plus 19 files under docker/linux-sbom/ and docker/windows-sbom/).
- SRS: 8 new requirements (REQ-022 through REQ-029), each single-shall
(verified programmatically), grounded directly in the real code:
the full-mode live-preflight fail-fast behavior, the security-gate
non-disableable guarantee, the lastOccurrence BOM-binding check, the
policy/reporting/build failure-categorization mechanism underlying
Test-SbomArtifact.ps1's exit codes, the path-traversal-hardened
source-checkout stage, the full immutable-release + in-toto attestation
+ tag-chain + manifest cross-match verification chain for LVLIBP
release dependencies, and the deliberate native-vs-container difference
in whether Grype's own findings are a gate.
- RTM: matching Req->Test->Code rows for all 8.
- Architecture Packet: Component View expanded with the real stage
library, shared schemas, and the narrow Build-LvlibpCandidate.ps1
script correctly scoped out of the main pipeline flow.
Verified before committing: single-shall discipline (all 29 total
requirements pass), all 7 ARCH text rules still match, RTM rtm-link
signal still present.
Add real VM-provisioning requirements/architecture coverage (VITechnologies/projectbuddy#29)
Closes the gap the operator flagged directly: VM provisioning had only 2
narrow REQ rows and 3 shallow architecture-table rows despite being ~37
scripts and 1200+ lines of real, dispatch-proven workflow behavior across
2 distinct families (Windows single-VM 5-phase lifecycle, Ubuntu
snapshot-based 10-phase dual-adapter lifecycle).
- SRS: 9 new requirements (REQ-013 through REQ-021), each single-shall
(verified programmatically), each grounded in real, already-proven
behavior read directly from the workflow YAML and its own inline
comments -- fail-closed SHA-256 verification, the triple-fallback
shutdown sequence, real WinRM round-trip readiness polling, credential
hygiene, the deliberate human-only activation boundary, vm-fleet-status's
active-verification design (fixing a real incident where self-reported
success masked a wrong-name runner registration), and the dual
Linux/Windows orchestrator-host adapter model.
- RTM: matching Req->Test->Code rows for all 9.
- Architecture Packet: Component View expanded with the real VM
provisioning components (manifest/inventory schemas, snapshot-receipt
verification chain, NSIS bootstrap installers); Deployment View expanded
with the actual node/lifecycle model for both VM families and the
active-verification pattern.
Verified before committing: single-shall discipline (regex-checked, all
21 total requirements pass), all 7 ARCH text rules still match.
Initial SRS, RTM, and Architecture Packet (spec-driven design)
Satisfies repo-standards-review's REQ and ARCH gates
(VITechnologies/projectbuddy#9, #10). Structured as an Obsidian vault
(.obsidian/ config) using native [[wiki-link]] syntax, which both
Obsidian and GitHub's own wiki renderer (Gollum) understand -- unlike the
main repo, where GitHub doesn't render [[...]] and repo-standards-review's
own lychee-based link checker doesn't support it either (confirmed via
lycheeverse/lychee#1650, open/unresolved).
- Software-Requirements-Specification.md: 12 REQ-### requirements, each
satisfying the single-shall discipline (verified programmatically, not
just by inspection), grounded in real, verified codebase behavior --
each cites its actual verification evidence (live smoke test, code
review, or "no automated check yet", never overstated).
- Requirements-Traceability-Matrix.md: Req -> Test -> Code linkage for
all 12 requirements, following repo-standards-review's
rtm-template.csv column shape.
- Architecture-Packet.md: all 4 required views (Context, Container,
Component, Deployment), named stakeholders and concerns, ADR Index
(cross-referencing ADR-0001, which stays in the main repo's
docs/architecture/adr/ since that's what repo-standards-review's own
ARCH:path:adr rule scans for).
ADR-0001 and the compliance stamp (docs/architecture/standards-compliance.md)
deliberately stay in the main repo, not this wiki -- see Home.md's
Related section.