# Dynamic WorkItem arithmetic Agent smoke test

> Canonical path:
> `specs/workflow/examples/dynamic-arithmetic-agent-smoke.md`

This is the end-to-end acceptance scenario for first-class Workflow WorkItems.
It intentionally does **not** contain a finished Plan source: the test passes
only when a real Leader Agent authors, validates, creates, publishes, and
invokes the Workflow through the public `loop exec workflow` tools, and a
different real Planner Agent decides the WorkItem DAG at runtime.

## Goal

Evaluate:

```text
((23 + 19) × (14 - 8)) + ((96 ÷ 12) × (11 + 5))
  - ((7 × 6) + (18 ÷ 3))
```

The final reviewed result is `332`.

## Team

Use one real Team with these Agent responsibilities:

1. **Leader** — receives the natural-language request and only authors,
   validates, creates, publishes, and starts the Plan. The Leader does not
   decompose the expression and must not answer the planning callback.
2. **Planner** — answers the first runtime callback, parses the expression,
   creates or reuses its child Tasks, and returns the dynamic WorkItem DAG. The
   Planner does not author or invoke the Plan.
3. **Calculator A** — executes calculator WorkItems selected by the Planner.
4. **Calculator B** — executes calculator WorkItems selected by the Planner.
5. **Reviewer** — runs once after the dynamic join, checks the ordered terminal
   results, and returns the final answer.

Leader and Planner are deliberately separate Team members and must have
different Agent and Team-member IDs. Do not combine their roles merely to
simplify the smoke setup. All five Agents and the frozen Human execution owner
must have the scope access required for the parent Task and child Tasks used by
the run.

## Leader request

Send only this natural-language request to the Leader; do not seed Plan YAML,
node names, callback payloads, Agent IDs, or a precomputed operation DAG:

```text
请计算表达式 ((23+19)*(14-8))+((96/12)*(11+5))-((7*6)+(18/3))。
请自行创建并运行一个 Workflow 完成它；在依赖允许时尽可能并行，并确保
不是由单个 Agent 独自完成。
```

The Team roles and current parent Task are part of the execution environment,
not hidden additions to this request. The Leader must discover its Team,
separate itself from the runtime Planner, choose the two Calculators and
Reviewer, author the Plan, and supply the required invocation inputs itself.
The Leader Agent identity must be visible on Plan create/publish/invoke
receipts, while the distinct Planner Agent must be selected by the first
callback's real canonical visible mention and frozen in its callback receipt.
The generated source header remains:

```yaml
apiVersion: loop.plan/v1
kind: PlanVersion
```

The compiled version must report `loop.plan.compiler/v4` and
`loop.plan.artifact/v4`.

## Expected runtime decomposition

Before the first callback completes, the Plan and Run must not contain a fixed
item count, fixed list of item keys, or fixed dependency graph. The Planner
chooses all of those at callback time by returning `workItems`. With the
instruction “one WorkItem per binary operation”, the returned DAG should be
isomorphic to this table; keys and the distribution between Calculator Agents
may differ:

| WorkItem | Operation | Direct dependencies | Result |
|---|---|---|---:|
| `op01` | `23 + 19` | none | 42 |
| `op02` | `14 - 8` | none | 6 |
| `op03` | `op01 × op02` | `op01`, `op02` | 252 |
| `op04` | `96 ÷ 12` | none | 8 |
| `op05` | `11 + 5` | none | 16 |
| `op06` | `op04 × op05` | `op04`, `op05` | 128 |
| `op07` | `op03 + op06` | `op03`, `op06` | 380 |
| `op08` | `7 × 6` | none | 42 |
| `op09` | `18 ÷ 3` | none | 6 |
| `op10` | `op08 + op09` | `op08`, `op09` | 48 |
| `op11` | `op07 - op10` | `op07`, `op10` | 332 |

Every WorkItem has a canonical Task `workScope`, `relatedScopes` containing the
parent Task, one allowed `responder`, and a non-blank `instruction`. Runtime
renders that responder as a real canonical visible mention and uses ordinary
mention routing; the callback receipt then freezes the resolved Agent.
Every WorkItem key matches `^[a-z][a-z0-9_-]{0,255}$`.
Operation Task titles and visible calculator requests must stay concise. A
literal leaf should read like `23 + 19 = ?`; a dependent item may briefly name
the direct results it combines, but must do so with the canonical instruction
reference syntax. For example, `op10` has `dependsOn: [op08, op09]` and an
instruction such as `$op08.result + $op09.result = ?`. Each unescaped `$` must
name a direct dependency followed by a non-empty business-output path; bare
`$op08`, unknown or transitive keys, and missing paths are invalid. `$$` is a
literal dollar sign. Each instruction has at most 64 references. A business
output path has at most eight ASCII identifier segments of 64 bytes and must
not contain `__proto__`, `prototype`, or `constructor`. In this first version,
the referenced `result` fields are declared as `number`; Workflow substitution
accepts only `number`, `boolean`, or `null` leaves, never `string`, object, or
array. Other values remain available in typed callback input. Each rendered
scalar is limited to 8 KiB and the fully resolved instruction to 32 KiB. The
Workflow resolves valid references after direct dependencies succeed and before
it sends the visible request, so the receiving Calculator does not parse them.
The Planner must not inline the already-known dependency values or put runtime
envelopes, scope IDs, responder IDs, or procedural callback instructions into
`instruction`. The static item node must not append those structures to
`sendMessage.text`; full typed `item.dependencies` remain available from
`workflow step get` as structured evidence.

## Expected Agent activation sequence

1. The Human sends the natural-language request to the Leader.
2. The Leader authors, validates, creates, publishes, and invokes the Plan.
3. The Run's canonical visible mention selects the Planner Agent for the first
   callback, not the Leader, and the accepted receipt freezes that selection.
4. The Planner creates or reuses the operation child Tasks and completes that
   callback with the runtime `workItems` DAG.
5. Calculator A and Calculator B execute ready WorkItems, with no more than two
   active item lineages. When a Calculator callback activates on a Task
   `workScope`, existing Task watch state automatically watches that Task for
   the Calculator; no claim or assignment is required for callback completion.
6. After all WorkItems are terminal, the Reviewer is activated exactly once and
   returns `332`.

The Reviewer message is also a concise visible request. The source-ordered
terminal results remain in the Reviewer's typed callback input and must not be
serialized into the Task discussion message.

There must be no Leader activation between steps 2 and 6. In particular, a
callback answered by the Leader is not acceptable evidence for the Planner
stage even if it returns the expected DAG.

## Required evidence

Capture all of the following from the real cluster:

- the Leader-authored Plan source and successful
  validate/create/publish/invoke receipts;
- Team and callback evidence showing five distinct Agents, including different
  Leader and Planner IDs;
- the first callback visibly mentioning and completed by the selected Planner
  Agent, with the accepted receipt freezing that Agent and no Leader fallback;
- version compiler/artifact fields showing v4 while source remains v1;
- one successful Invocation and Run;
- pre-callback Run evidence that no concrete WorkItem count or DAG was embedded
  in the Plan, followed by the Planner's runtime callback payload containing the
  concrete `workItems` DAG;
- eleven real child Tasks (or an explicitly explained isomorphic split) and the
  Planner callback payload that binds their scopes;
- dependent Planner instructions using only
  `$<directDependencyKey>.<businessOutputPath>` references, including an
  `op10`-equivalent instruction such as
  `$op08.result + $op09.result = ?`, plus visible Calculator delivery proving
  that the Workflow replaced those references with the completed dependency
  values before waking the Agent;
- Run events showing no more than two active item lineages, independent ready
  operations proceeding, and dependent operations starting only after their
  direct dependencies succeeded;
- each Calculator message containing the selected WorkItem responder as a real
  canonical visible mention, with delivery and wake performed by ordinary
  mention routing and the resolved Agent frozen in the callback receipt;
- each operation Task remaining unassigned after Planner creation and
  throughout callback execution; no Calculator claim is required;
- Task watch evidence showing each activated fixed-Task WorkItem callback
  automatically watches its Task `workScope`; if the fixture reuses one Task
  for dependent WorkItems in the same `fan_out`, an actually activated
  dependent WorkItem is watched before the superseded ancestor WorkItem Agents
  are unwatched, while merely pending, unrelated, or still-live parallel
  WorkItems cause no handoff;
- no Workflow-specific Task lease, custom Task-routing state, or multi-assignee
  behavior;
- concise calculator and reviewer messages with no raw WorkItem, dependency,
  scope, responder, or join-result JSON in the visible Task discussion;
- Workflow-generated callback messages rendered with the Workflow identity in
  Task Detail; the frozen Human execution owner may remain in authorization and
  audit metadata but must not be presented as the visible message author;
- `item.dependencies` containing only direct terminal envelopes and no nested
  `dependencies`;
- one source-ordered fan-out join result and exactly one Reviewer activation;
- Reviewer output `332` and terminal Run status `succeeded`;
- a Web Run-details screenshot showing the grouped fan-out counters, dependency
  information, responder, and Task work-scope links.

Task-create retries during planning must reuse the original child Task IDs.
Reusing the same idempotency key with a different payload must conflict and
must not add Task timeline, event, or counter entries.