← 2.1.16 Test inconclusive · runtime-test

Combo Test: Forked Parallel Exploration with Task Coordination — runtime test

Hands-on runtime battle-test of Combo Test: Forked Parallel Exploration with Task Coordination. Result: INCONCLUSIVE.

Forked parallel agents can coordinate work through shared task state and metadata updates, enabling divide-and-conquer exploration.

Test Setup

Two agents (FORK-EXPLORER-A and FORK-EXPLORER-B) were spawned in parallel, each assigned a separate investigation domain: task system architecture and session ID discovery. Both agents were instructed to create tasks, research independently, and persist findings via task metadata updates. An orchestrator spawned and monitored both agents while maintaining its own task list.

What the Test Found

Both agents successfully created tasks visible to all other agents in the shared TaskList. FORK-EXPLORER-A created task #21; FORK-EXPLORER-B created task #22. Each agent updated its task metadata with research findings, including architecture details and session ID discovery methods. All agents operated on the same local task store at ~/.claude/tasks/{session}/, confirming shared state.

The test discovered three operational session ID vectors: hooks (JSON stdin), the sessions-index.json file, and skill string substitution. Session IDs were confirmed absent from environment variables.

The Pattern

The test demonstrates a repeatable workflow: create "exploration" tasks for distinct hypotheses, spawn parallel agents each claiming one task, have agents research independently and update task metadata with findings, then have the orchestrator synthesize results from all metadata. Findings persist even if an agent process terminates early.

Limitations

The test validated task visibility and metadata coordination but did not measure convergence time, handle agent failures mid-research, verify metadata consistency under concurrent updates, or test at scale beyond two agents. Whether this pattern remains reliable under high coordination load or with longer-lived forked processes remains open.

Primary source
⎘ 2.1.16/tests/combo-07-forked-exploration/TEST-RESULTS.mdverbatim from the corpus

Combo Test: Forked Parallel Exploration with Task Coordination

Hypothesis

Multiple forked agents can coordinate via shared task state.

Test Setup

Spawned two agents in parallel:

  • FORK-EXPLORER-A: Investigate task system architecture
  • FORK-EXPLORER-B: Investigate session ID discovery

Both were instructed to create tasks, do research, update with findings.

Results

Status: ✅ VALIDATED

Agent Visibility

Both agents saw the full TaskList including:

  • Orchestrator's tasks
  • Each other's tasks (once created)

Task Creation

  • FORK-EXPLORER-A created task #21
  • FORK-EXPLORER-B created task #22
  • Both tasks visible in shared TaskList

Findings Shared via Metadata

Both agents updated their task metadata with findings:

  • Architecture details
  • Session ID discovery methods
  • Available env vars

Key Discoveries

  • Session ID available via: hooks (JSON stdin), sessions-index.json, skill string substitution
  • Session ID NOT in: environment variables
  • Shared state confirmed: all agents operate on same ~/.claude/tasks/{session}/

Pattern

1. Create "exploration" tasks for different hypotheses
2. Spawn parallel agents, each claims one task
3. Agents research independently
4. Agents update task metadata with findings
5. Orchestrator synthesizes from all task metadata

This Enables

  • Parallel research with coordination
  • Divide-and-conquer exploration
  • Findings persisted even if agent dies
Evidence & receipt
◇ ed25519 receipt
idtest_15abacac29f3f5a86f9c3e68
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
sigfcc50c559b05e4671a539bf433542022e57acb58bf015d92f631aee6091ed84544af2e9f4ef271db11770bc4de042d67a3d3815f49aa4a8264fae743ad2bc805

Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.

Connected