Bring the accumulated local work onto main - #191
Merged
Conversation
shouldRunGitStage reads openspec/changes/<name>/harness.json, and it ran after the archive stage had moved that directory to openspec/changes/archive/. The read therefore always found nothing, always resolved to "not configured", and the git stage was always skipped. It could never have run at the end of a real chain, under any configuration. The unit tests could not see it because mockArchiveSucceeds only returned success - nothing moved, so the file was still there when the gate read it. A mock that reports success without doing what success does certifies the wrong thing. The mock now performs the move, and the gate is read immediately before archive runs, which is the last moment the file exists. Verified by reverting the source fix and re-running: the test fails with zero push calls and passes with the fix. Checked deliberately, because two tests found earlier today passed no matter what the code did. A side effect worth naming: a malformed harness.json now fails the chain before archive rather than after, which is the better order for an irreversible step. This sat exactly inside the boundary drawn yesterday in task 4.4a. The live run recorded under 4.4 verified push, pull request, checks and merge through the real git and gh; it did not verify the chain's own wiring, and that is where the defect was. Also in this commit, two corrections to things I wrote. harness-config.test.ts matched fenced JSON blocks with a bare \n. On Windows HARNESS.md is checked out CRLF - 500 pairs, no bare LF - so the pattern found zero blocks and the assertion failed, while CI's Linux checkout found both and passed. Green in CI and red on the machine of whoever edits the document is the worst of the two, and it is the third line-ending or path-separator assumption found in tests today. core-test-worker-contention said a single fork makes git.push.test.ts pass. A full packages/core run with that flag still fails it at the 5000 ms default, so "parallel workers contend" is too narrow: something accumulates over a long run regardless. The two-file experiment behind that claim was too small to see it, and the proposal now says so - its first task is to name the cause rather than to apply the workaround. harness-mechanical-checks 6.6 is closed by the repository owner's own live run, recorded in that change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…d not Twelve of twenty-three, and the three that matter most are marked open with the reason rather than skipped. 2.3 and 2.5: activate() still awaits a read of every retained checkpoint, bounded now at ten rather than unbounded, which is what made the window usable again - deferral is not what fixed it. 2.4: details() is synchronous and answers delta, coverage and canRollback out of the checkpoint, so nothing there can be deferred without making it async and taking that through the transport protocol and both surfaces. The design that would work is written down - persist the small parts in the reference, read the large after snapshot only on rollback - along with the fact that it needs a journal version bump and its own change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Everything accumulated locally, brought onto
main.The branch held three commits — two of them named "Many different changes. Sorry." and "Another changes" — and was simultaneously four commits behind
origin/main.origin/mainis merged in; no conflicts.What is in it
openspec/changes/archive/2026-09-02-*, with their specs synced intoopenspec/specs/(agentic-harness+387,execution-core+124,persistent-workbench-runs+88).harness-git-stage-no-agentimplemented, 18/20 —stepAgents.gitno longer offers an agent for a stage that never reads one.agentic-harness-documentationcomplete;HARNESS.mdrefinements and regenerated screenshots.checkpoint-retention-and-lazy-loadtask record (see below).Two phantom changes removed
openspec/changes/harness-config-strictness/andopenspec/changes/agent-usage-accounting/were left behind as empty directories when those changes were archived. Both are correctly present underarchive/, butopenspec listreported the husks as active changes with "No tasks".Git does not track empty directories, so they were never going to reach
main— but they were live in the local listing and the panel, which is the same "presents itself as real and is not" pattern this repository has spent the week removing. Deleted locally.checkpoint-retention-and-lazy-load: 12/23, and the open ones are the pointThree tasks are marked open with the reason written down rather than quietly ticked:
activate()still awaits a read of every retained checkpoint. It is bounded at ten now instead of unbounded, and that is what made the window usable again. Deferral is not what fixed it, and the task should not claim otherwise.details()is synchronous and answersdelta,coverageandcanRollbackout of the checkpoint, so nothing there can be deferred without making it async and taking that through the transport protocol and both surfaces. The design that would work is recorded: persist the small parts in the reference, read the largeaftersnapshot only on rollback. It needs a journal version bump and its own change.Test plan
npm run typecheck— cleannpm run lint— cleanpackages/extension17 files / green,packages/webui35 / 232,packages/server3 / 61packages/core— one failure,git.push.test.ts, already tracked ascore-test-worker-contentionand untouched herenpm run lint:english— passed🤖 Generated with Claude Code