ed30088adb deleted packages/ui/tui, so the two present-tense clauses naming
it in notes this branch already rewrites no longer describe HEAD. The
operative claim — the surfaces beyond the web row needed no change — stands
without naming the package. Pair hashes re-recorded.
Also anchor tool-row-styles.spec.ts's rule lookup at a rule boundary, so a
compound selector landing above a base rule fails loud instead of reading
the wrong declaration block.
`flex: none` stops the `+n` box shrinking but not its text wrapping, so a
row too narrow for title + separator + suffix broke the one-line summary in
the exact case the slot exists for. Add `white-space: nowrap` and pin the
declaration as CSS text, since jsdom has no layout.
Also align the README's row illustration with the English rendering (the
same sentence's plan-strip clause already used it), and record the two
deferred review findings in the Agent Note so they survive merge.
The plan strip header has not emitted `<done>/<total> tasks · <n> in progress`
since #740 replaced it with `·`-joined per-status counts. Four sites still
quoted the old string: plan-summary.ts's module JSDoc, ui-conversation's
README pair, and the web-todo-display note pair.
The parallel-in-progress note's regression example mixed a four-item plan with
an eight-item row reading, and built-boot.snapshot.ts still called itself the
only test loading the built bundles.
The `+N` active count rides ToolRow's non-shrinking `summarySuffix` slot,
but only jsdom package suites covered it: the ACP snapshots render no web
surface and the built-boot smoke asserts no todo row. Add
`apps/web/tests/todo-row.snapshot.ts`, which boots the built client bundles
against the keyless fixture transport and records `summary`, `suffix`, and
the plan strip's header as separate fields, so folding the count back into
the summary string changes the expected output.
The three assembled-jsdom files now share `apps/web/tests/assembled-boot.ts`
instead of each carrying its own copy of the boot entry list, bundle map,
jsdom stubs, and mount call.
Also: name the policy branch in each `allowParallelInProgress` test title so
no case asserting `true` sits under a `false` describe, reword the stale cap
comment in todo-panel.spec.tsx, and record the plan strip's real header
format in the Agent Note (per-status counts, not `<done>/<total> tasks`).
The tool catalog boots every tool with its default config, but
allowParallelInProgress has no default, so the generator has to choose;
the page now says which branch it shows. The Agent Note's sidecar count
went stale twice inside this PR, so it records the refresh rule instead
of a point-in-time census. The SDK builtin entry pins its config literal
with satisfies like every sibling.
Rebuild the todo row's parallel summary on the shared ToolRow that master
introduced: planSummary still returns the active name and the remaining
count separately, and the row hands the count to a new non-shrinking
summarySuffix slot so a narrow row clips the summary text before the count.
An error row drops the suffix, whose collapsed summary is the failure line.
Re-record the ACP todo-write transcript for the parallel prompt, regenerate
the config catalog for the required allowParallelInProgress field, and
re-record the bilingual pairing hashes.
Whether concurrent active tasks are legitimate depends on runtime
concurrency the tool cannot observe, but whether a deployment's agents
ever fan out is knowable at composition time. `allowParallelInProgress`
(default true) therefore replaces the hardcoded policy: the flag moves
the model-facing instruction and the accepted input together, so a
deployment running strictly sequential agents can restore the
single-active discipline from cordis.yml.
The durable-log invariant does not follow the flag. A log written while
parallel work was allowed must still replay after a deployment tightens
the policy, so the invariant stays silent on the active count.
The fixture committed the generated Linux workspace path instead of the
`{{cwd}}` token every other acp recording uses. The normalizer masked it
so replay passed, but the next record or refresh would rewrite the file
for no reason; refresh is now byte-stable on it.
The Agent Note's schema-pin arithmetic predated master's
`toolSchemasSource` sharing: seven of the eight sidecars carry the todo
schema, and scenarios composing an identical header share one rather
than each keeping a copy.
The web-fetch pinsHeader scenario landed on master after this branch, so its
tool-schemas.expected.json carried the old at-most-one-in_progress description
while replay assembles the new one. Refreshed keylessly with
DSH_SNAPSHOT=refresh; the Agent Note now records that every pinning scenario
carries its own copy of the description, so a branch changing it has to refresh
the pins that landed after it branched.
Both todo one-line surfaces truncate the active hint with overflow: hidden
and text-overflow: ellipsis. A "+N" appended to the first active task's name
therefore sat at the far end of the truncatable text, so a long task name or a
narrow viewport clipped exactly the part that reports the other running tasks,
leaving a parallel plan indistinguishable from a sequential one.
planSummary now returns activeContent and activeExtra as separate fields
instead of one joined activeHint, and each surface renders the count in its own
flex: none span beside the ellipsized name: .activeExtra in the collapsed plan
strip header, .extra in the todo_write row. Putting the count in front of the
name was rejected — the task name is what the reader looks for first.
The parallel-plan cases in todo-panel.spec.tsx now assert the count is a
separate element from the name, and both fail if the two are rejoined. The
assembled web snapshot re-records: the flex gap supplies the visual space, so
the transcript reads "实现 fixture 样本+1" with no space in the text nodes.
Lifting the single-in_progress cap makes a list shape reachable that the
web surfaces never received. Two sites derived their one-line summary with
todos.find(t => t.status === 'in_progress') — the collapsed TodoPanel header
and the todo_write row — which was total under the old cap and silently
dropped every active item but the first once several could match: a plan
with three running tasks collapsed to the name of one. The expanded list
was always correct, so neither PR's tests covered it.
Both sites now take planSummary in contract/todo-plan-model.ts, the
domain-shared face both the skeleton and toolviews domains may import; the
duplicated derivation was why one find could be fixed while the other
stayed wrong. The hint names the first active item and suffixes +<n> for
the rest, so the collapsed line reports how many tasks are running.
The web fixture's todo sample now runs two items in_progress, so the
assembled web transcript replays a parallel plan: the row reads
'1/4 已完成 · 实现 fixture 样本 +1' over the built bundles.
Remove the single-in_progress cap from todo_write execute validation and
the durable-log invariant so a task list can mirror genuinely parallel
work (concurrent subagents, background commands). Update the tool
description to instruct marking every actively worked task in_progress,
refresh the tool catalog and keyless snapshot expected outputs, and
record the decision in a new Agent Note superseding the original cap.
Tianyi Cui