[runner]: formalize opt-in self-hosted LV32/NI capability contract

[svelderrainruiz]

Summary

Formalize a specialized, opt-in self-hosted runner capability contract for host-native LabVIEW 32-bit / NI-path lanes.

Why

The repo already has a generic self-hosted Windows contract, but the LV32/NI surfaces are still implicit and path-based. That makes host-native 32-bit execution useful but not governable.

We need a first-class capability contract so jobs can explicitly require the specialized host surface without making it the default execution surface for the repository.

Current State

• generic self-hosted Windows jobs still route through labels like [self-hosted, Windows, X64]
• host-native 32-bit / NI assumptions still live mostly in docs, path heuristics, and install expectations
• template distribution work will eventually need an optional downstream capability expectation for VI History, but compare should publish the authoritative runner contract first

Goal

Define a specialized, opt-in runner capability for LV32/NI-path work that:

• keeps hosted and generic self-hosted Windows as the default surfaces
• makes LV32/NI-path requirements explicit and machine-readable
• routes only the jobs that actually need the specialized host capability
• adds health validation for the specialized host surface before jobs trust it

Likely Scope

• document the specialized runner capability and labels
• add a runner-label contract validator surface
• add runner health validation for LV32/NI path availability
• update only the workflows that truly require the specialized capability
• keep the capability non-default and opt-in

Candidate Surfaces

• docs/SELFHOSTED_CI_SETUP.md
• docs/ENVIRONMENT.md
• .github/actionlint.yaml
• tools/Assert-RunnerLabelContract.ps1
• selected workflows for VI History / host-native NI paths

Acceptance

• the specialized LV32/NI runner capability is explicitly named and documented
• the contract is validated in-repo
• jobs that need it declare it explicitly
• generic hosted/self-hosted jobs remain on their current default surfaces
• no workflow silently depends on Program Files (x86) heuristics alone for LV32/NI execution

[svelderrainruiz]

Queued behind #1877. Prewarming a clean compare lane for the specialized LV32/NI self-hosted runner contract so the next architecture slice is ready once publication pressure clears.

[svelderrainruiz]

Architecture note from operator direction:

The specialized LV32/NI self-hosted runner contract should also account for repeatable host services that background agents can rely on locally, especially Docker-backed LabVIEW/tooling surfaces.

Current recommendation for #1905:

• keep one explicit specialized host capability contract for GitHub Actions routing
• layer dedicated local per-agent service slots or daemonized service identities on top of that host capability for repeatable infrastructure access
• avoid treating every background agent as an unconstrained generic runner; use labeled capability + leased local service surfaces instead
• make Docker/LabVIEW image access, NI-path tooling, and other repeatable host services explicit and health-checked

This keeps the host governable while still letting multiple background agents work against repeatable infrastructure safely.

[svelderrainruiz]

Isolated Docker Lane Direction

The approved end goal is not one permanent GitHub runner service per background agent.
It is one governed host fabric where each background agent can lease an isolated Docker lane on demand.

Working model:

• keep a small set of coarse GitHub runner labels for ingress
• back those labels with leaseable local services instead of ambient workstation state
• treat Docker access as a capability lane with explicit ownership, health, and teardown

Recommended first compare slice under this issue:

1. make the runner/self-hosted capability contract explicit and testable
2. define the Docker-lane capability labels and expected host-health receipts
3. keep per-agent isolation as leased runtime state, not as a permanent runner-per-agent registration model

Why this is the right seam:

• it matches the user goal that each background agent can have an isolated Docker lane
• it avoids turning one workstation into many fragile long-lived runner registrations
• it gives us a clean place to account for host usage, operator-equivalent labor, and future lane contention

Planned follow-on after the contract slice:

• Docker lane lease receipt and health contract
• runtime supervisor / delivery-agent integration for lease acquisition and release
• cost accounting for host service usage alongside token and labor cost
• template capability metadata that can declare when a generated consumer expects host-native or Docker-backed vi-history execution

Constraint to preserve:

• LabviewGitHubCiTemplate should distribute the vi-history capability contract, not inherit compare's full internal platform.
• the compare repo remains the platform producer and host-fabric governor.

Budget hook: blended lower bound $0.020100; operator $0.000000 of $50000.000000 cap (remaining >=$50000.000000); window invoice-turn-2026-03-HQ1VJLMV-0027 spent $0.020100 remaining $399.979900; turns 1 total (0 live, 0 background); 1 turn(s) still pending labor timing; calibration reserve $100.000000 across 1 held window(s). Receipt: tests/results/_agent/cost/github-comment-budget-hook.json.

[svelderrainruiz]

Adding one more host-fabric contract seam here from live operator guidance:

• the canonical host lane group should record an explicit OS fingerprint
• future isolated lane groups should be able to compare their host OS against that canonical fingerprint
• upgrades need clear attribution to a specific OS version/build so failures are not misattributed to Docker, LabVIEW, or lane orchestration changes

I am folding this into the same host-fabric direction as runner capability contracts and leased isolated Docker lanes.

Target shape:

• machine-readable host OS identity receipt
• captured for the canonical host lane group
• projected into handoff/governor state for isolated lane groups
• used later to attribute regressions across host OS upgrades

Budget hook: blended lower bound $0.020100; operator $0.000000 of $50000.000000 cap (remaining >=$50000.000000); window invoice-turn-2026-03-HQ1VJLMV-0027 spent $0.020100 remaining $399.979900; turns 1 total (0 live, 0 background); 1 turn(s) still pending labor timing; calibration reserve $100.000000 across 1 held window(s). Receipt: tests/results/_agent/cost/github-comment-budget-hook-issue-1905-os.json.

[svelderrainruiz]

Canonical host OS fingerprint is now wired into the LabVIEW 2026 host-plane report in the clean #1905 lane.

Current observed baseline from tests/results/_agent/host-planes/labview-2026-host-plane-report.json:

• isolated lane group id: host-os-fingerprint:169035c976919d857f049a6248757794008ae5a44fd0d63aafa4ebb180faa37e
• canonical version: 10.0.26200
• build / UBR: 26200 / 8037
• display version: 25H2
• edition: Professional
• architecture: 64-bit

Important host truth this locks in:

• CIM branding is Microsoft Windows 11 Pro
• registry product branding is Windows 10 Pro
• the contract now treats branding as advisory and uses the canonical comparison fields plus SHA for upgrade attribution

This is now the reference surface future isolated lane groups should compare before attributing regressions to LabVIEW, Docker, or workflow drift.

Budget hook: blended lower bound $0.020100; operator $0.000000 of $50000.000000 cap (remaining >=$50000.000000); window invoice-turn-2026-03-HQ1VJLMV-0027 spent $0.020100 remaining $399.979900; turns 1 total (0 live, 0 background); 1 turn(s) still pending labor timing; calibration reserve $100.000000 across 1 held window(s). Receipt: tests/results/_agent/cost/github-comment-budget-hook.json.

[svelderrainruiz]

Budget hook: blended lower bound $0.020100; operator $0.000000 of $50000.000000 cap (remaining >=$50000.000000); window invoice-turn-2026-03-HQ1VJLMV-0027 spent $0.020100 remaining $399.979900; turns 1 total (0 live, 0 background); 1 turn(s) still pending labor timing; calibration reserve $100.000000 across 1 held window(s). Receipt: tests/results/_agent/cost/github-comment-budget-hook.json.

[svelderrainruiz]

Budget hook: blended lower bound $0.020100; operator $0.000000 of $50000.000000 cap (remaining >=$50000.000000); window invoice-turn-2026-03-HQ1VJLMV-0027 spent $0.020100 remaining $399.979900; turns 1 total (0 live, 0 background); 1 turn(s) still pending labor timing; calibration reserve $100.000000 across 1 held window(s). Receipt: tests/results/_agent/cost/github-comment-budget-hook.json.