refactor(scripts): single harness-identity owner for harness vocabulary - #46
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (20)
📝 WalkthroughWalkthroughThe change defines canonical Claude and Codex harness identities, maps qualification clients to those identities, and applies the shared metadata across plugin configuration, build validation, installation proofs, recovery, runtime scripts, documentation, and tests. ChangesCanonical harness identity
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to This refactor centralizes harness metadata without changing generated output or persisted behavior; normal checks are passing, and no actionable merge-blocking risk remains. Sequence Diagram(s)sequenceDiagram
participant CLI
participant proveHarnessInstall
participant HarnessIdentity
participant NativeProof
participant Recovery
CLI->>proveHarnessInstall: request harness proof
proveHarnessInstall->>HarnessIdentity: resolve harness metadata
proveHarnessInstall->>NativeProof: run harness-specific proof
NativeProof->>Recovery: validate post-mutation recovery
Recovery-->>NativeProof: recovery result
NativeProof-->>proveHarnessInstall: proof metadata
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
myagentdojo
deployed
to
hosted-canary-qualification
August 14, 2026 04:42 — with 
GitHub Actions
Active
GitHub Actions
Active
…gistry display names
… journey client type
myagentdojo
force-pushed
the
refactor/harness-identity
branch
from
August 14, 2026 07:12
7fddff6 to
0aa1006
Compare
myagentdojo
deployed
to
hosted-canary-qualification
August 14, 2026 07:12 — with
GitHub Actions
Active
GitHub Actions
Active
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
2 participants
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.
Summary
Harness knowledge in this repo was re-derived at roughly 70 sites across 12 script files, in three competing vocabularies — lowercase IDs, capitalized display names, and
-cliqualification clients — with the same hooks-path pair written four independent times. Any change to a harness path or name meant finding every copy. Now one leaf module,scripts/harness-identity.ts, owns the vocabulary: canonical lowercaseHarnessId, per-harness hooks/manifest paths, the plugin-root env vars (including the deliberate asymmetry —CLAUDE_PLUGIN_ROOTvs plainPLUGIN_ROOT), display names, and the qualification-client mapping. Every TypeScript branch site reads it; no script defines its own harness union, path template, or display mapping any more (verified by an orphan-union sweep).The migration is behavior-preserving by construction and by proof: generated
plugin/output is byte-identical (generate:checkclean), every asserted error message and persisted JSON shape is unchanged, and deliberate mutation checks were run — altering a registry value made generation checks and all four hooks-path assertion surfaces fail, then the module was restored byte-identically with a SHA-256 proof.Two surfaces can never import TypeScript: the POSIX shell hook and the CI workflows. Instead of generating them, validation-only parity tests pin them — the hook's
SessionStart:/Stop:case arms must cover exactly the module's harness IDs, and thebun add --globalCLI-install line must be byte-identical acrossplugin-ci.yml,hosted-canary.yml, andrelease.yml(version-agnostic, so routine bumps of all three together pass). Sensitivity was proven in both directions for both tests.The Claude install driver, previously inlined in
prove-harness-install.ts, now sits behindClaudeDriverDependenciesinscripts/harness-install-claude.ts— the same DI pattern asCodexDriverDependenciesbut a Claude-shaped surface (three-scope loop), serving both the local and hosted proof callers; the 12-export test surface is stable.This is PR 2 of 2 from the plan (stacked on the release-validation PR, its base branch); ADR 0009 and a
CONTEXT.mdglossary entry record the vocabulary decision, withdoc-targets.ymlrows binding both docs to the module.Session-settled decisions carried from planning: lowercase canonical harness IDs (user-directed, over the
-cliand capitalized vocabularies); two explicit per-harness records, never derivation templates (user-directed); validation-only parity for non-TypeScript surfaces (user-directed, over code generation); Claude-specific DI interface (user-directed, over leaving the driver inlined); persisted proof/receipt contracts frozen (user-directed).Testing
scripts/harness-identity.test.tspins the registry with golden values, including the env-var asymmetry, and asserts the client-to-harness mapping exhaustively in both directions.generate:checkclean;release:validateexit 0;prove:allgreen at head.codex-desktop, matching ADR 0009's frozen CLI vocabulary). One cross-model finding was rejected at validation — the pin-parity extractor already fails closed on anything but exactly one match — and is recorded as a hardening note.Post-Deploy Monitoring & Validation
Repo-internal refactor of authoring/proof scripts; the generated
plugin/payload is byte-identical (payloadHash unchanged0070438f...), so there is no production/runtime impact beyond CI.plugin-ciandhosted-canarygreen;generate:checkclean in CI.Summary by CodeRabbit
New Features
Documentation
Tests