{
  "notes": "Episode 4: authoritative state has trunk 2ee4c6aea8846f7b1ae51b55d18ff9f2843bd7d1, only repository-foundation, example-facts and implementation accepted, 5/20 items used, no running batches and no handed results. The episode-3 docs-examples wave NEVER started: its example task variable requested a command's verbatim output and was refused. Its read/wake requests consequently referenced nonexistent results/batches. Stalled=1. Earlier notes saying that wave was spawned or budgets were spent are intentions, not state. Do not cancel or wait for docs-examples or example-docs.\n\nThis episode creates only the required decisions JSON. No trunk work or fresh verification was performed here. Episode 3's recorded evidence is 46 passing implementation tests on Node 24.22.1, correct scores/table/JSON for the six supplied rows, clean library imports and aggregated CLI errors. That is historical evidence, not a check of documentation that has yet to exist.\n\nDecision: spawn one new code wave docs-and-examples-repair, with two disjoint items. example owns examples/**, docs/example-sources.md and test/examples.test.ts; readme owns only README.md. They complete the missing documentation/example deliverables in parallel on the already implemented trunk. Each brief explicitly describes one deliverable and requires a short authored findings report, files, check names/counts, discrepancies and deferred checks. The requested table/JSON content is a product fixture in the repository and README, not terminal logs in the result report. No machine configuration or credentials are requested. Neither item can rely on its sibling's files until merge. No second code wave is scheduled, avoiding the earlier overlapping-wave refusal. This spends 2 items if accepted, leaving 13 of 20; episodes 5 and 6 remain. finish=false because documentation and final integration evidence are missing.\n\nShared input contract: JSON array with name, stage, proofSystem, permissionlessProving, exitWindowDays, upgrades, dataAvailability, forceInclusion. The six supplied snapshot rows (in input order) are Arbitrum One/1/fraud/true/10/securityCouncil9of12/blobs/true; OP Mainnet/1/fraud/true/0/securityCouncil10of13/blobs/true; Base/1/fraud/true/0/securityCouncil8of11/blobs/true; ZKsync Era/0/validity/false/5/securityCouncil6of8/blobs/false; Starknet/1/validity/false/7/securityCouncil9of12/blobs/false; Scroll/0/validity/false/0/multisig/blobs/true. Frozen types spell blobs ethereumBlobs. Expected ranked scores: Arbitrum One85, OP Mainnet75, Base70, Starknet65, ZKsync Era50, Scroll45. Use two-space JSON and the stated field order for consistent README/input. Examples' table/JSON fixtures come from application behavior and are regression-tested. Facts are from prior accepted example-facts research, read 2026-10-27; no new research was handed to this episode. Workers must be honest about that provenance and use public source links, never claim fresh verification without evidence. Preserve the regular-vs-emergency exit caveat (all six lack an emergency exit window), council-Safe/co-signer simplification, Base hybrid proof mapping, Scroll's team multisig and disableable enforcement, and nonqualifying ZKsync/Starknet inclusion paths.\n\nRead next: both new reports plus the three known accepted implementation reports, explicitly requested for assessment/final citations. Wake only on the new wave, with a 60-minute fallback. No cancellation: no batch is running. If the timer wakes before merge, inspect actual state; do not start an overlapping code wave or infer completion.\n\nEpisode 5: inspect refusals, wave status, reports and merged commit first. If documentation is merged, schedule one final integration-review code item, with scope [] if evidence shows no repair is needed, or a single item with narrowly scoped files if concrete defects were reported. Run npm test (including test/examples.test.ts); verify CLI table and JSON match committed fixtures exactly and both --json positions work; verify README's input/output blocks agree with committed examples; check --help, empty input, malformed JSON, invalid arguments, read errors and multiple field errors (nonzero, stderr only); check import side effects; inspect coverage of every rubric branch, exit boundaries, council ratios/one signer, proof gating, 0..100 totals, ranking ties/nonmutation and validator paths. Verify README covers schema, API, CLI, all scoring rules and caveats; confirm MIT LICENSE, no dependencies, no build, only erasable TS and node:/relative runtime imports, and offline testability. Summarize commands and counts/findings rather than copying terminal output. Configuration is immutable. If repairs are necessary, combine only evidenced repairs and full verification into one scoped worker so episode 6 can assess the final tested merge; avoid independent fix/check items in the same wave because the checker cannot see sibling changes. If docs did not land, recover only missing/refused work and require that recovery item to perform full checks, respecting available episodes.\n\nEpisode 6: finish=true only with accepted deliverables, merged wave and passing checks covering the complete final tree. Do not equate item acceptance alone with correctness. Any remaining failures or unverifiable criteria must be stated honestly. Final write-up should name the final trunk commit and cite implementation/validator, implementation/scoring, implementation/cli, docs-and-examples-repair/example, docs-and-examples-repair/readme and the final verification report (plus any repairs). Cite the supplied snapshot date and its limitations; do not invent a result key for example-facts, whose exact item key is absent from the current state.",
  "spawn": [
    {
      "name": "docs-and-examples-repair",
      "mode": "code",
      "brief": "Complete one {{component}} deliverable for rollup-risk from the current merged trunk. Change only {{files}}. Use docs/architecture.md and src/types.ts as interface/scoring specifications. Keep the library dependency-free, directly runnable with Node 24, with no build or configuration edits. Other items run concurrently and their files will not exist in your checkout.\n\nUse this supplied historical L2BEAT-derived snapshot, dated 2026-10-27. Input is a JSON array; fields are name, stage, proofSystem, permissionlessProving, exitWindowDays, upgrades, dataAvailability, forceInclusion. All rows use dataAvailability='ethereumBlobs'. Rows below give the other fields in that order; SC(t/m) expands to {type:'securityCouncil',threshold:t,members:m}; multisig expands to {type:'multisig'}:\nArbitrum One;1;fraud;true;10;SC(9/12);true\nOP Mainnet;1;fraud;true;0;SC(10/13);true\nBase;1;fraud;true;0;SC(8/11);true\nZKsync Era;0;validity;false;5;SC(6/8);false\nStarknet;1;validity;false;7;SC(9/12);false\nScroll;0;validity;false;0;multisig;true\nKeep that input order and key order, using two-space JSON indentation. Expected ranking/scores: Arbitrum One 85, OP Mainnet 75, Base 70, Starknet 65, ZKsync Era 50, Scroll 45; check these against the application.\n\nPreserve modeling caveats: exit days are regular-path values; all six have emergency paths without an exit window. Council thresholds describe the council Safe alone, omitting co-signers. Base's validity label simplifies its hybrid TEE/ZK system. Scroll uses a 3/4 team multisig and can disable enforced batches. ZKsync's queue and Starknet's council minority do not count as force inclusion. Treat supplied facts as a snapshot, not freshly verified live claims.\n\n{{task}}\n\nFinish within an hour. Result: a concise Markdown report naming changed files, the checks run and their pass/fail counts, any expected-versus-actual discrepancies, and checks deferred until the wave merges. Report findings in your own words.",
      "items": [
        {
          "key": "example",
          "vars": {
            "component": "example dataset, output fixtures and regression tests",
            "files": "examples/**, docs/example-sources.md, test/examples.test.ts",
            "task": "Create examples/rollups.json with the six rows, and examples/expected.txt plus examples/expected.json as application-output fixtures for table and JSON modes. Derive the fixtures from the CLI and add offline node:test coverage validating all six rows, the stated scores/ranking, and exact equality between CLI results and both fixtures, including trailing newlines. Write docs/example-sources.md with snapshot provenance, public L2BEAT project links, per-field mapping explanations and the caveats above; distinguish supplied facts from any independently corroborated claims. Run npm test and the new tests. Do not depend on the concurrently written README."
          },
          "scope": [
            "examples/**",
            "docs/example-sources.md",
            "test/examples.test.ts"
          ]
        },
        {
          "key": "readme",
          "vars": {
            "component": "README",
            "files": "README.md",
            "task": "Write README.md with purpose, source-checkout setup, Node 24 direct execution, table/--json/help usage, public API examples, full schema and validation behavior, every scoring factor and boundary from the architecture, proof gating, ranking ties and limitations of the heuristic. Include the complete six-rollup input and its expected table output as separate fenced blocks; verify the documented result with the CLI. Explain snapshot caveats and link docs/example-sources.md. Document npm test, zero dependencies, no build, and the MIT license. Check instructions and examples using existing trunk modules; do not require the concurrently created example files."
          },
          "scope": [
            "README.md"
          ]
        }
      ],
      "output": {
        "format": "markdown",
        "maxBytes": 10000
      }
    }
  ],
  "read": [
    "docs-and-examples-repair/example",
    "docs-and-examples-repair/readme",
    "implementation/validator",
    "implementation/scoring",
    "implementation/cli"
  ],
  "cancel": [],
  "wake": {
    "batches": [
      "docs-and-examples-repair"
    ],
    "afterMinutes": 60
  },
  "finish": false
}