Skip to content

Start Run with Agentic Harness on the change it was opened for - #202

Merged
VeryComplexAndLongName merged 3 commits into
mainfrom
feat/run-with-harness-prefills-v2
Sep 3, 2026
Merged

Start Run with Agentic Harness on the change it was opened for#202
VeryComplexAndLongName merged 3 commits into
mainfrom
feat/run-with-harness-prefills-v2

Conversation

@VeryComplexAndLongName

Copy link
Copy Markdown
Owner

Two commits: the archive move that was blocking npm run lint, and the prefill itself.

The prefill — one defect, three symptoms

Right-clicking a change and choosing Run with Agentic Harness opened a panel with nothing filled in: command list, no change selected, default agent.

Everything needed was already there. runWithHarness passes the change:

revealAiPanel({ ...dashboardContext(workspaceRoot, item.changeDir), startChain })

and AiPanel takes changeDir as a prop. It simply started from useState<CommandKind>("list") and useState<string>("") and never consulted it.

The agent is the same fact one step further on. AiPanel already pre-selects from stepAgents, keyed on the command kind through COMMAND_KIND_TO_HARNESS_STAGE. With the kind stuck at list there is no stage, so no entry is looked up and the picker keeps DEFAULT_AGENT_ID.

Seeding the kind fixes the agent as a consequence — the configured agent was never unavailable, only unreachable.

What the test caught

Seeding the selection alone was not enough:

expected '' to be 'demo'

A <select> cannot hold a value it has no <option> for, so the seeded change silently fell back to empty until a list had run. The option list is seeded too now, and the existing reconciling effect replaces it with the real list while keeping the selection.

Nothing is enforced — every seeded value stays editable, the same way the stepAgents recommendation already was. The chain path is untouched: runChange is set only for the picker target, since HarnessChainPanel has one button and nothing to pre-select.

The archive move

dispatch-to-chat-integration-coverage was implemented and its directory moved to archive/ on disk, but the deletion of the original path was left unstaged — so the old files stayed git-tracked while missing from the working tree, and check-english.mjs died with ENOENT before eslint ever ran.

That is the same failure that made npm run lint expected-red for days earlier this week, from the same cause: an archive move committed halfway. Staged both halves; 31/31 tasks complete, archive copy verified intact.

Staging it also surfaced a real no-useless-escape error in my own new test, which had been hidden behind that ENOENT — the precise reason this matters.

Test plan

  • npm run typecheck — clean
  • npm run lint — clean (0 errors), once the archive move was staged
  • AiPanel 43/43, extension-context 7/7
  • openspec change validate --strict — valid
  • Only failing suite is git.push.test.ts, tracked as core-test-worker-contention
  • CI green
  • Human: right-click a change → Run with Agentic Harness → confirm the change, implement and the configured agent are already selected, and that changing any of them still works

🤖 Generated with Claude Code

The change was implemented and its directory moved to archive/ on disk,
but the deletion of the original path was left unstaged - so the old
files stayed git-tracked while missing from the working tree, and
check-english.mjs died with ENOENT before eslint ever ran.

That is the same failure that made npm run lint expected-red for days
earlier this week, from the same cause: an archive move committed
halfway. Staging both halves together is what keeps the check meaningful.

31 of 31 tasks complete, archive copy verified intact.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Right-clicking a change and choosing Run with Agentic Harness opened a
panel with nothing filled in: command `list`, no change selected, default
agent. The user re-entered what they had just said by right-clicking.

Everything needed was already there. runWithHarness passes the change -
revealAiPanel({ ...dashboardContext(workspaceRoot, item.changeDir),
startChain }) - and AiPanel takes changeDir as a prop. It simply started
from useState("list") and useState("") and never consulted it.

The agent is the same fact one step further on. AiPanel already
pre-selects from stepAgents, keyed on the command kind through
COMMAND_KIND_TO_HARNESS_STAGE. With the kind stuck at `list` there is no
stage, so no entry is looked up and the picker keeps DEFAULT_AGENT_ID.
Seeding the kind fixes the agent as a consequence - the configured agent
was never unavailable, only unreachable. One defect, three symptoms.

Seeding the selection alone was not enough, and the test caught it: a
<select> cannot hold a value it has no option for, so the seeded change
silently fell back to empty until a `list` had run. The option list is
seeded too, and the existing reconciling effect replaces it with the real
list while keeping the selection.

Nothing is enforced. Every seeded value stays editable, the same way the
stepAgents agent recommendation already was. The chain path is untouched:
a config resolving to `chain` mounts HarnessChainPanel, which has one
button and nothing to pre-select, so `runChange` is set only for the
picker target.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both assert the exact context object, so adding runChange broke them -
correctly. The picker target now expects runChange: true, and the chain
target expects false: a chain view has one button and nothing to
pre-select, so seeding a command kind there would describe a control that
is not on screen.

I missed this locally by reading only the head of the failing-file list
and stopping at git.push.test.ts, which is the known intermittent one. A
second real failure was further down the same output.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@VeryComplexAndLongName
VeryComplexAndLongName merged commit 9353534 into main Sep 3, 2026
7 checks passed
VeryComplexAndLongName added a commit that referenced this pull request Sep 4, 2026
`tasks.md` decides whether a change may be archived, and four of them
were wrong in the same direction:

- `run-with-harness-prefills-the-run` recorded 0 of 16 done, having
  shipped entirely in #202.
- `usage-from-acp`, `event-guard-covers-every-kind` and
  `usage-visible-while-running` each left their "run the checks" and "add
  a changeset" items open, with the checks run and the changesets already
  released in 0.50.0.

One cause, not four slips. Tasks were ticked, the files copied into a
worktree and committed, and only then were the checks run and
`npx changeset` invoked — after the commit that would have recorded them.
The same order produced the same omission four times, always at the last
two items of a list.

Every tick here was verified against `main` rather than recalled: the
symbol the task names existing in the file it names, the test the task
names existing by its own title, and for a changeset item the released
entry in the relevant CHANGELOG. Fifteen of sixteen items in the prefill
change verified this way; the sixteenth is human-only and stays open. The
diff was then re-read item by item against that list to confirm nothing
else was ticked — 21 boxes, matching 15 + 2 + 2 + 2 exactly.

Every human-only item stays open, including `ci-audit-own-job` 3.6, where
half is observed (the audit is now its own check) and half is not (that
the merge gate reports independently *when the audit fails*, which needs
a failure to demonstrate). Closing it on the observed half is the
inference this change exists to refuse.

`openspec/README.md` gains the order that avoids this — run, then tick,
then commit — along with what the failure looks like from outside, since
that is how it will be recognised next time: a change whose work is
plainly in `main`, whose `tasks.md` reads as untouched, and which the
archive step then refuses.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@VeryComplexAndLongName
VeryComplexAndLongName deleted the feat/run-with-harness-prefills-v2 branch September 5, 2026 05:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant