Observed behavior: During an optional V8-instrumented focused reconciliation suite, waits for a competing first-use reconciliation and then re-reads state failed with Error: file changed during validation while readLockOwner read a contended mutation-lock owner. The same test passed in the complete non-coverage focused run (244 tests). All four new #1048 metadata tests passed under both runs.
Expected behavior: Benign first-use lock contention should produce the intended bounded wait and state reread, while unsafe lock-owner evidence still fails closed. Determine whether the fixture or contention handling needs repair without weakening ownership admission.
Root cause: Not established. The observed stack is readBoundedRegularFileWithStat (src/security-files.ts:767) -> readBoundedRegularFile (811) -> readLockOwner (src/private-mutation-lock.ts:196) -> acquireMutationLock (359) -> withPrivateMutationLock (551) -> reconcileWorktrees (src/worktree-reconciliation.ts:2675). This concerns lock evidence, not the metadata-leaf read changed by #1048.
How to reproduce: At candidate ff568a0, run pnpm exec vitest run test/worktree-reconciliation.test.ts --coverage --coverage.include=src/worktree-reconciliation.ts --coverage.reporter=text --reporter=default with the pinned development toolchain. Failure was intermittent; reproduction frequency is unknown. Test fixture uses worker-private temporary HOME/state and a synthetic Git repository. No live daemon state was used. Raw stdout was not retained; the test name and stack above were captured from the implementer tool output.
Environment:
Discovered during #1048 / Epic #968. Separate follow-up outside frozen S4. No claim that #1048 introduced the behavior; not fixed by its two-option metadata change. Full exact-head CI remains required for the PR.
Originating metadata-leaf repair PR: #1115. This separate finding is not claimed fixed there.
Observed behavior: During an optional V8-instrumented focused reconciliation suite,
waits for a competing first-use reconciliation and then re-reads statefailed withError: file changed during validationwhilereadLockOwnerread a contended mutation-lock owner. The same test passed in the complete non-coverage focused run (244 tests). All four new #1048 metadata tests passed under both runs.Expected behavior: Benign first-use lock contention should produce the intended bounded wait and state reread, while unsafe lock-owner evidence still fails closed. Determine whether the fixture or contention handling needs repair without weakening ownership admission.
Root cause: Not established. The observed stack is
readBoundedRegularFileWithStat(src/security-files.ts:767) ->readBoundedRegularFile(811) ->readLockOwner(src/private-mutation-lock.ts:196) ->acquireMutationLock(359) ->withPrivateMutationLock(551) ->reconcileWorktrees(src/worktree-reconciliation.ts:2675). This concerns lock evidence, not the metadata-leaf read changed by #1048.How to reproduce: At candidate ff568a0, run
pnpm exec vitest run test/worktree-reconciliation.test.ts --coverage --coverage.include=src/worktree-reconciliation.ts --coverage.reporter=text --reporter=defaultwith the pinned development toolchain. Failure was intermittent; reproduction frequency is unknown. Test fixture uses worker-private temporary HOME/state and a synthetic Git repository. No live daemon state was used. Raw stdout was not retained; the test name and stack above were captured from the implementer tool output.Environment:
Discovered during #1048 / Epic #968. Separate follow-up outside frozen S4. No claim that #1048 introduced the behavior; not fixed by its two-option metadata change. Full exact-head CI remains required for the PR.
Originating metadata-leaf repair PR: #1115. This separate finding is not claimed fixed there.