chore(conformance): pin reachable Windows quarantine authority - #88
Merged
Conversation
#85 changed two governed harness files -- scripts/windows-job-supervisor.cs and the conformance workflow that embeds it byte-for-byte -- so the harness authority now names its merge commit 55071f4 and that commit's tree, along with the blob and SHA-256 of every governed file as it exists there. This has to be a separate commit, as #79 was for #78 and #76 for #75. The authority records the tree of the commit it names, and a commit cannot record its own tree, so the pin always trails the change it pins by exactly one commit. `keeps workflow producer HEAD distinct from the historical executable harness` asserts precisely that: the pinned revision must be an ancestor of the working HEAD, never the HEAD itself. The reviewed literal in phase1-conformance-lock.test.ts moves with the lock. It is deliberately a second copy -- the lock is data the harness reads and the literal is what review approves, so a pin that changed in only one of them is a test failure rather than a silent re-authorization. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KacEJmkX5GhkViPUhx9Mie
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The repin values are consistently updated across the lock file and its corresponding exact-value test, with no remaining references to the previous revision/tree or governed object digests.
Pull request overview
This PR advances the Phase 1 conformance harness “authority” pin so it points to a reachable (post-merge) revision and tree, and updates the governed file object digests accordingly. It fits the repo’s established pattern of following a governed harness change with a separate “reachable pin” update that records immutable Git object identities.
Changes:
- Repins
harness.revisionandharnessAuthority.{revision,tree}to55071f4…/d4d0d38…. - Updates the governed blob and SHA-256 digests for
scripts/windows-job-supervisor.csand.github/workflows/client-v1-conformance.ymlin both the lock data and the lock test’s approved literal.
File summaries
| File | Description |
|---|---|
| src/phase1-conformance-lock.test.ts | Updates the approved expected harness authority revision/tree and governed blob/SHA-256 values used by the heavy-suite lock validation tests. |
| phase1-conformance.lock.json | Repins the harness authority revision/tree and updates the governed file object identities recorded in the lock. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This was referenced Sep 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
#85 changed two governed harness files —
scripts/windows-job-supervisor.csand.github/workflows/client-v1-conformance.yml, which embeds it byte-for-byte. The harness authority now names #85's merge commit55071f4and that commit's tree, along with the blob and SHA-256 of every governed file as it exists there.Why it is a separate PR
The authority records the tree of the commit it names, and a commit cannot record its own tree. So the pin always trails the change it pins by exactly one commit.
keeps workflow producer HEAD distinct from the historical executable harnessasserts precisely that — the pinned revision must be an ancestor of the working HEAD, never the HEAD itself.This is the repository's established rhythm, not a new invention:
0bf1387(#78)cac7d8e(#79)d7245fc(#75)b406570(#76)Two copies, on purpose
phase1-conformance.lock.jsonis data the harness reads; the literal inphase1-conformance-lock.test.tsis what review approves. Both move together here, so a pin that changed in only one of them is a test failure rather than a silent re-authorization.Validation
pins the behavior commit and each changed governed Git object,keeps workflow producer HEAD distinct from the historical executable harness,accepts the exact detached harness authority…, and the launcher test all pass now.phase1-schema-v2-evidence— innerspawnSync ETIMEDOUTagainst a 5 s budget at machine load ~22, in a file this diff does not touch. Reproduces on unmodifiedorigin/main.Note for reviewers
I had been running only
test:unit:normallocally, which excludes these files — they live invitest.heavy.config.ts. That is why the repin surfaced on #85's CI rather than before it. Running both suites is now part of my checklist for anything touching governed harness files.