CI: emit provisional vNext conformance evidence slices

[mark-e-deyoung]

Consumes the canonical provisional classification markers from mark-e-deyoung/winebot-contracts without changing WineBot runtime behavior or the existing legacy full-suite gate.

Adds a non-gating diagnostic CI step that, after the ordinary conformance run, executes the currently classified subsets separately:

• portable-core candidate;
• capability-extension candidate;
• implementation-specific;
• obsolete-contract;
• unresolved.

Each subset writes its own machine-readable result file and all result files are uploaded with the existing conformance artifact. The diagnostic step preserves all five slices even when one subset fails, and records exit codes in the workflow summary.

Boundaries:

• classification is intentionally incomplete and provisional;
• capability-extension classification does not assert WineBot claims the capability;
• implementation-specific/obsolete/unresolved results are evidence, not instructions to add compatibility shims;
• obsolete-contract preserves legacy-v1 reconstructability while making retirement candidates visible separately from legitimate implementation-specific behavior;
• the existing full conformance command remains unchanged and authoritative for current v1 release behavior;
• no native-Windows acceptance is inferred from Linux/Wine CI.

Tracks #114 and consumes winebot-contracts#11 / merged PRs #16-#19.

[mark-e-deyoung]

Blocking result: stale WinInspect acquisition pin prevents classified conformance execution

CI run 34599478871 did not reach the new conformance evidence slices. Pre-flight failed while building the existing WineBot image because docker/Dockerfile still pins WinInspectPortable-v0.4.0.zip with SHA-256 83b64999...3e416; the downloaded artifact no longer matches that pin. The checksum gate correctly failed closed.

Do not weaken or bypass integrity verification. Existing Foundry evidence provides the adopt-first replacement fixture:

• repo/tag: SemperSupra/WinInspect@v0.4.4
• source SHA: b2d07ae3ff1df53a62c27ec3fa27f1452ff5926a
• portable: WinInspectPortable-v0.4.4.zip
• portable SHA-256: 6ac0a65f774ffe69672f1c459254931ebfddb1e52c9fbec14b5db1348ccaad04
• Foundry status for that fixture remains RDTE/non-promoted; use the exact immutable release artifact as an acquisition input, not as a package-promotion claim.

This is a real upstream blocker to #114 evidence generation, independent of the PR's diagnostic workflow changes. Required repair: replace the stale v0.4.0 Docker pin with the exact v0.4.4 release/hash, preserve checksum verification, then rerun cloud CI. No Linux/Wine result may be interpreted as native-Windows acceptance.

[mark-e-deyoung]

Classified run result: acquisition blocker resolved; portable core is clean

Run 34602783376 reached the intended evidence slices after adopting the exact Foundry WinInspect v0.4.4 portable artifact/hash. The integrity gate passed; pre-flight and integration smoke also passed.

Exact evidence binding:

• WineBot PR merge ref: ff4c6fd87f7f49ee8328af4f945d0d06bb5bb3fb
• winebot-contracts: 34d1c87a523c67f4a8a263a2408e099f0e420369
• venue/evidence class: GitHub Actions Ubuntu / cloud-linux+Wine
• native acceptance: not claimed
• result artifact: 10265427327, SHA-256 4af4c0c13303f1568eaf6e7be82f2c880978fb3a1d3a45e2616a74a3a0783bf0

Decision-changing result by provisional classification:

• portable-core candidate: 16/16 PASS
• capability-extension candidate: 28/40 pass, 8 fail, 4 skip
• implementation-specific: 2/9 pass, 7 skip (expected WinBot gating dominates)
• unresolved: 7/9 pass, 1 fail, 1 skip

The remaining failures are concentrated in window/focus/inspect response shape, lifecycle shutdown mechanics, screenshot state, and the unresolved /health/system.memory shape. These are evidence to keep those surfaces extension/unresolved; they are not justification for WineBot compatibility shims. WineBot already reports memory as mem_total_kb / mem_available_kb, so adding a synthetic nested memory object only to raise the legacy score would be the wrong direction.

The raw v1 run remains 54/71 and red. Preserve it as current-v1 compatibility evidence; do not reinterpret it as vNext architecture acceptance. This PR should remain draft while current-v1 gate policy and the versioned migration remain distinct.

[mark-e-deyoung]

Classification authority advanced after this run: winebot-contracts PR #19 merged as fe3efd1, adding vnext_obsolete_contract and moving test_version_has_winbot_version out of vnext_implementation_specific. The next classified WineBot evidence run should emit this marker as its own non-gating slice rather than folding it into implementation-specific results. This is a taxonomy/evidence-alignment delta only; do not alter runtime behavior or the legacy v1 gate to accommodate it. The existing 16/16 portable-core result remains valid for the exact prior contract revision recorded by the run.

[mark-e-deyoung]

Post-#19 classified evidence is now complete on run 34612406017 against winebot-contracts@fe3efd1f7adeb559c276873349f680c318343042.

Results:

• portable-core candidate: 16/16 PASS
• capability-extension candidate: 28/40 pass, 8 fail, 4 skip
• implementation-specific: 1/8 pass, 7 skip
• obsolete-contract: 1/1 PASS (winbot_version compatibility assertion)
• unresolved: 7/9 pass, 1 fail, 1 skip
• legacy v1 full suite remains 54/71 and red

Artifact 10269375957, SHA-256 387be946c1c83dd57c3682ef547c47f90c146ca727a2fdf8e0df6057ec9ba113.

This validates the #19 taxonomy split: WineBot satisfying winbot_version is legacy compatibility leakage that belongs in the obsolete-contract retirement bucket, not legitimate implementation-specific vNext semantics. The extension/unresolved failure clusters remain evidence for their current classifications and do not justify compatibility shims. Keep the legacy v1 gate and versioned migration distinct; this PR remains appropriately draft. No native-Windows acceptance is claimed.

[mark-e-deyoung]

Evidence-quality finding: classified slices are not yet state-isolated

Run 34612406017 confirms the post-#19 taxonomy split, but the diagnostic slice results also expose a harness limitation that affects how individual extension failures should be interpreted.

The legacy v1 suite runs first against the same live WineBot service and exercises destructive lifecycle behavior including shutdown. The subsequent classified slices then reuse that mutated runtime. In this run the full v1 screenshot tests passed, while a later capability-extension screenshot assertion observed HTTP 500 after the preceding lifecycle activity. That discrepancy is evidence of cross-slice runtime-state contamination, not sufficient evidence of a stable screenshot capability defect.

Decision consequence:

• retain the clean portable-core 16/16 result and the obsolete-contract 1/1 classification evidence;
• keep the extension/unresolved buckets provisional at the per-test-failure level where prior destructive tests may affect state;
• do not add runtime compatibility shims based on a contaminated classified rerun;
• before using classified slices as independent capability evidence, reset/restart the existing service (or otherwise reuse the existing test/runtime mechanisms to provide a clean state) between destructive suites/slices. Do not build a new harness framework for this.

The legacy v1 gate remains unchanged. This is an evidence-harness qualification issue, not a vNext semantic change, and no native-Windows acceptance is claimed.

[mark-e-deyoung]

Cloud-ready repair applied for the state-isolation finding: commit 663cf5fc5c6365f405ec65b1c95b0c5902f492fd now restarts the existing WineBot service, waits for health, and reacquires its API token before each provisional vNext slice. This reuses the current Docker/test lifecycle rather than adding a harness abstraction. The legacy v1 gate remains unchanged. Treat extension/unresolved per-test failures as provisional until a fresh run confirms the slices are cleanly isolated. No native-Windows acceptance is claimed.

[mark-e-deyoung]

Isolated classified-slice rerun resolves screenshot evidence contamination

Run 34665179573 validates the smallest repair for the prior evidence-quality blocker: each provisional vNext slice now starts from a restarted, healthy WineBot service with a freshly read API token.

Current isolated cloud/Wine results at WineBot 663cf5fc5c6365f405ec65b1c95b0c5902f492fd + winebot-contracts fe3efd1f7adeb559c276873349f680c318343042:

• portable core: 16/16 PASS;
• capability extension: 29/40 PASS, 7 FAIL, 4 SKIP;
• implementation-specific: 1/8 PASS, 7 SKIP;
• obsolete-contract: 1/1 PASS;
• unresolved: 7/9 PASS, 1 FAIL, 1 SKIP.

Decision-changing result: the screenshot assertion now passes in the isolated capability-extension slice. The prior screenshot failure was therefore cross-slice runtime-state contamination, not sufficient evidence of a stable screenshot capability defect.

Remaining isolated extension failures now cluster around window response shape/focus/inspect semantics and lifecycle shutdown behavior; the unresolved failure is the health-memory response shape (memory vs mem_total_kb/mem_available_kb). Treat those as classification/migration evidence, not instructions to add compatibility shims.

Disposition consequence:

• KEEP the existing WineBot/WinInspect screenshot path; do not replace or shim it based on the contaminated result;
• retain portable core as empirically supported on cloud/Wine;
• keep winbot_version in the obsolete-contract / vNext retirement bucket;
• preserve the legacy v1 gate separately (still 54/71 in this run) while vNext semantics migrate deliberately.

Artifact 10288637248, SHA-256 6763a9717cd6c6910ad20fb78ac319e2738c99c458a096a963d2956ff6e7f6e9.

No native-Windows acceptance is claimed.

[mark-e-deyoung]

Red/blue-team lessons-learned qualification from the classified WineBot reps:

Promote only the following narrowed program-level invariants:

1. Classify before architectural repair. Before adding compatibility behavior, changing an abstraction, or changing preserve/replace/retire disposition, classify the observed failure as portable semantic defect, capability-qualified behavior, implementation-specific assertion, contract defect/obsolete requirement, or unresolved. Exception: obvious low-risk deterministic repairs may proceed without ceremony when they cannot change architecture or contract meaning.

2. Control state before attributing failure. Evidence used to change architecture, contract, or disposition must either come from an adequately isolated/reset experiment or explicitly carry contamination/state-dependence as a limitation. This is narrower than requiring fresh instances for every test; the requirement is sufficient state control for the claim being made. The screenshot reversal after service restart is the concrete falsification case.

3. Scope every acceptance claim to the evidence envelope. Record at minimum artifact/revision, capability or contract slice, executor/substrate, relevant environment, and evidence result. Generalize only when an additional argument/evidence supports generalization. Linux+Wine/cloud conformance therefore cannot establish native-Windows acceptance.

Supporting heuristics, not invariants:

• prefer capability claims over embodiment-name gating where the capability can be stated independently;
• treat legacy/raw aggregate conformance scores as evidence sources rather than architecture objectives;
• prefer the smallest experiment that can falsify an architectural hypothesis before adding new machinery;
• negative evidence may legitimately support PRESERVE/no-change.

Red-team cautions retained:

• classification can become ceremony/confirmation bias if categories harden prematurely; keep an unresolved bucket and allow taxonomy revision;
• isolation can destroy realism for genuinely stateful/lifecycle behavior; isolate only enough to support the intended causal claim, and separately test stateful sequences when state is itself the subject;
• evidence envelopes can become so specific that nothing generalizes; qualification should distinguish direct acceptance from evidence-backed generalization rather than prohibit generalization;
• capability declarations can lie or drift, so claimed capability must remain testable rather than trusted metadata.

This is a methodology refinement only; it does not change WineBot runtime behavior or native-Windows acceptance status.

[mark-e-deyoung]

Reconciliation: state-isolation blocker is repaired in the cloud lane

Latest head 663cf5fc5c6365f405ec65b1c95b0c5902f492fd reran as Actions run 34665179573 on 2026-09-12. Pre-flight and integration smoke passed. The conformance job remains red at the existing legacy-v1 full-suite step, but the provisional vNext classified evidence step completed successfully after the PR was changed to restart/health-check WineBot before each classified slice.

Decision consequence:

• the cross-slice state-contamination finding from the prior run is no longer a harness blocker for subsequent classified evidence on this head;
• do not reinterpret the overall red job as a new vNext regression: the authoritative legacy v1 gate is still intentionally distinct and still fails before the non-gating classified diagnostic step;
• keep PR CI: emit provisional vNext conformance evidence slices #123 draft until the versioned migration / current-v1 gate policy is resolved separately;
• no compatibility shim is justified by the legacy aggregate score;
• no native-Windows acceptance is claimed from this Ubuntu/Wine venue.

Durable run evidence: workflow 34665179573; conformance artifact 10288637248, digest sha256:6763a9717cd6c6910ad20fb78ac319e2738c99c458a096a963d2956ff6e7f6e9. Exact per-slice semantic dispositions should continue to come from the artifact/results, not the aggregate workflow conclusion.