Qualification Lineage And Known Answer Job

Qualification Lineage And Known-Answer Job

Resolve the engine release target once to a full 40-character lowercase commit SHA. Each lane uses a new qualification UUIDv4 and a fresh VM and fresh mutable guest storage created through the candidate's actual provisioning path from verified inputs. Reusing an already provisioned guest or restored saved state is not a fresh creation proof. Verify the created VM UUID independently and bind it and its protected generation to every later phase. Do not equate a VM name, network port, screenshot, or runner label with that identity.

For each end-to-end lane:

1. Record the candidate commit, qualification ID, lane, workflow and exact phase, run ID and attempt, verified VM UUID and generation, and actual dependency identities in protected evidence.
2. Verify the created guest's required bootstrap and checkpoint. For Ubuntu, independently confirm the exact current snapshot name and UUID and safe power state, then start the same VM; do not restore a snapshot or substitute another VM as an implicit shortcut.
3. Under separately authorized Actions access, independently match the intended repository, unique online runner ID and expected labels to the local runner registration reached through that verified guest. Reject duplicate names, incomplete inventories, unavailable permissions, and any mismatch. Capture this historical observation before cleanup; the runner need not remain online after authorized deregistration.
4. Dispatch a non-secret job to the intended runner and independently verify its exact candidate workflow, run ID and attempt, job ID, terminal conclusion, runner ID, and challenge response. Labels select work but are not proof of runner or VM identity.

Before live execution, the approved proof plan must specify a finite, positive integer deadline in seconds for cleanup reconciliation in every lane and, for each end-to-end lane, for runner-online observation, job queueing, and job execution. No default or increase is assumed by this draft. Use a monotonic clock and retain the exact run and operation identities. A missing applicable deadline blocks execution; expiry is UNKNOWN, not proof that a queued or accepted operation stopped. Do not silently extend a deadline, repeat an ambiguous dispatch, or interrupt a healthy snapshot to satisfy it. A result observed after the deadline may reconcile an obligation but cannot retroactively turn that timed-out attempt into a pass.

For the job, generate a fresh 16-byte cryptographically random challenge and encode it as exactly 32 lowercase hexadecimal ASCII characters C. If randomness, uniqueness across recoverable qualifications, or the challenge's provenance is unverified, the result is UNKNOWN. The job computes SHA-256 over the UTF-8 bytes of projectbuddy-runner-proof/v1: followed by C and one LF byte. Its application result is exactly one ASCII line projectbuddy-runner-proof/v1:<C>:<64-lowercase-hex-digest> followed by LF. The verifier obtains C from the protected qualification intent and computes the expected digest independently; it does not trust a digest supplied by the job as its own expected value.

For the offline fixture only, C is 00000000000000000000000000000001, the message is 62 bytes, and the expected digest is 3f4251ffea125e0eac4da72c5bd16a46249b8da04c040e14dac8c5fe59b53a33. This fixed value is never a live challenge. The job receives no guest password, personal access token, license value, or consumer configuration; its GitHub token permissions are empty. This probe demonstrates only the specified calculation on the independently identified runner. A nonce, hash, runner label, or job exit alone is not guest attestation, an anti-rollback mechanism, or proof against a hostile host process.