cool-workflow 0.1.78

package/docs/multi-agent-operator-ux.7.md

@@ -0,0 +1,314 @@
+# Multi-Agent Operator UX
+
+CW v0.1.21 makes multi-agent operator inspection first-class. The feature is a
+read-only userland view over existing run state. It does not create a hidden
+dashboard database and does not infer success when evidence, dependency, or
+lifecycle state is ambiguous.
+CW v0.1.22 adds trust panels to the same operator path so role policy,
+permission decisions, blackboard write audit, message provenance, judge
+rationale, panel decisions, and policy violations are visible beside topology
+and evidence state.
+CW v0.1.24 uses the same operator-derived graph, dependency, failure, evidence,
+trust, and report views as replay comparison inputs for the Multi-Agent Eval &
+Replay Harness.
+CW v0.1.25 layers State Explosion Management on top of these operator views: when
+a run grows large, `summary show`, `multi-agent summarize`, and
+`multi-agent graph --view compact` collapse high-volume records into synthetic
+summary nodes while preserving the critical path, failures, missing evidence,
+policy violations, and judge rationale. See
+[state-explosion-management.7.md](state-explosion-management.7.md).
+
+CW v0.1.26 adds the `Adoption Rationale` panel and the `multi-agent reasoning`
+view, which explains *why* each evidence item was adopted. Reasoning steps are on
+the critical path and are never collapsed by compaction. See
+[evidence-adoption-reasoning-chain.7.md](evidence-adoption-reasoning-chain.7.md).
+
+CW v0.1.27 adds an additive evidence `disposition` (`adopted` | `inspectable` |
+`blocking`) and an `inspectableEvidence` list. The raw `status` (the adoption
+state) is unchanged; `disposition` is the operator-facing reading of it. Before a
+verifier-gated commit, a missing/pending row genuinely blocks. After a
+verifier-gated commit the selected path is decided, so missing/pending evidence
+for sibling roles that were never driven as separate workers — for example
+undriven judge-panel judges — is inspectable operator state, not a hidden
+failure. The `multi-agent status` "Missing Evidence" header and the `status`
+panel report the blocking-vs-inspectable split so the operator is not misled.
+
+The model is derived from:
+
+- `WorkflowRun` tasks, dispatches, workers, nodes, feedback, candidates,
+  selections, commits, and report paths
+- multi-agent runs, roles, groups, memberships, fanouts, and fanins
+- topology runs and their missing evidence/conflict records
+- blackboard topics, messages, contexts, artifacts, snapshots, and coordinator
+  decisions
+- candidate score files, trust audit events, and verifier-gated commit records
+- role policy, blackboard provenance, judge rationale, panel decisions, and
+  policy violation audit records
+
+## Operator Commands
+
+Use the normal status and report commands for the broad view:
+
+```bash
+node scripts/cw.js status <run-id>
+node scripts/cw.js graph <run-id>
+node scripts/cw.js report <run-id> --show
+```
+
+Use the focused multi-agent views when the operator needs the process table:
+
+```bash
+node scripts/cw.js multi-agent status <run-id>
+node scripts/cw.js multi-agent graph <run-id>
+node scripts/cw.js multi-agent dependencies <run-id>
+node scripts/cw.js multi-agent failures <run-id>
+node scripts/cw.js multi-agent evidence <run-id>
+```
+
+Every focused command supports deterministic JSON:
+
+```bash
+node scripts/cw.js multi-agent status <run-id> --json
+node scripts/cw.js multi-agent dependencies <run-id> --json
+node scripts/cw.js multi-agent failures <run-id> --format json
+node scripts/cw.js multi-agent evidence <run-id> --json
+```
+
+The compact human output uses six stable panels:
+
+```text
+Agent Graph
+Dependencies
+Failed / Blocked Agents
+Adopted Evidence
+Missing Evidence
+Next Action
+```
+
+## Graph
+
+`multi-agent graph` shows the topology-backed agent graph plus downstream
+acceptance records:
+
+- MultiAgentRun, topology run, roles, groups, memberships, fanout, and fanin
+- tasks, dispatches, workers, result nodes, and verifier gates
+- blackboard topics, messages, artifacts, contexts, snapshots, and coordinator
+  decisions
+- candidates, score records, selections, verifier-gated commits, and feedback
+
+Edges are labeled when the label carries operational meaning:
+
+```text
+owns
+depends-on
+dispatches
+reports
+cites
+adopted-by
+rejected-by
+blocks
+scores
+selects
+gates
+commits
+```
+
+Direction follows the dependency or evidence flow. For example, a membership
+depends on a task and worker, worker output reports into the membership,
+blackboard artifacts are cited by fanin, scores evaluate candidates, selections
+choose scored candidates, and commits record the selected verifier-gated result.
+
+## Failures
+
+`multi-agent failures` merges the records an operator normally has to inspect
+one at a time:
+
+- failed memberships and missing role coverage
+- missing worker output and failed or rejected workers
+- open feedback, including sandbox-policy failures
+- fanin blocked reasons and missing blackboard evidence
+- rejected or failed candidates
+- score, selection, verifier, and commit-gate gaps
+- ambiguous blocked dependencies
+
+Each row includes the record id, kind, status, owner or role when known, linked
+task/worker/membership/fanin/candidate when known, the exact reason, and the
+next safe command.
+
+## Evidence Adoption
+
+`multi-agent evidence` explains why a result was accepted or not accepted. Each
+row includes:
+
+- evidence id/ref/path/locator
+- source kind and source id
+- adopted-by ids and rejected-by ids
+- pending consumers
+- candidate, score, selection, and commit links
+- provenance or trust source when available
+- status: `adopted`, `rejected`, `pending`, `superseded`, `conflicting`, or
+  `missing`
+
+An accepted path should be traceable like this:
+
+```text
+worker result -> blackboard artifact/message -> fanin -> candidate score
+-> selection -> verifier-gated commit
+```
+
+When any link is missing, CW reports it as pending or missing and recommends the
+next command rather than assuming the run is healthy.
+
+## MCP Parity
+
+MCP hosts can inspect the same derived data:
+
+- `cw_multi_agent_status`
+- `cw_multi_agent_graph`
+- `cw_multi_agent_dependencies`
+- `cw_multi_agent_failures`
+- `cw_multi_agent_evidence`
+
+`cw_multi_agent_status` preserves the v0.1.20 host envelope and adds the
+derived operator model under `summaries.multiAgentOperator`.
+
+## Example Trace
+
+```bash
+node scripts/cw.js multi-agent graph "$RUN"
+node scripts/cw.js multi-agent dependencies "$RUN" --json
+node scripts/cw.js multi-agent failures "$RUN"
+node scripts/cw.js multi-agent evidence "$RUN"
+node scripts/cw.js audit provenance "$RUN" --candidate "$CANDIDATE"
+node scripts/cw.js commit "$RUN" --selection "$SELECTION" --reason "verified winner"
+node scripts/cw.js report "$RUN" --show
+```
+
+The operator can start at an agent membership, follow `depends-on` to its task
+and worker, follow `reports` to the blackboard artifact and fanin, follow
+`scores` to the candidate score, follow `selects` to the selected result, and
+follow `commits` to the verifier-gated state commit.
+
+## Smoke Coverage
+
+`test/multi-agent-operator-ux-smoke.js` creates a deterministic topology-backed
+run with a successful worker evidence path, a failed worker path, blocked fanin
+evidence, score and selection records, a verifier-gated commit, human CLI
+assertions, JSON CLI assertions, MCP parity assertions, and report assertions.
+It is included in `npm test` and `npm run release:check`.
+## CLI ↔ MCP Parity (v0.1.27)
+
+Every command and tool referenced above is declared in the v0.1.27 capability
+registry (`src/capability-registry.ts`) and validated by `npm run parity:check`,
+so `cw <cmd> --json` and the matching `cw_<tool>` result render one data source.
+See [cli-mcp-parity.7.md](cli-mcp-parity.7.md).
+
+## Run Registry / Control Plane (v0.1.28)
+
+The runs described here are indexed, searchable, resumable, archivable, and
+rerunnable across repos by the v0.1.28 Run Registry / Control Plane, which derives
+a fingerprinted, fail-closed index over the same per-run `.cw/runs/<id>/state.json`
+source of truth. See [run-registry-control-plane.7.md](run-registry-control-plane.7.md).
+
+## Execution Backends (v0.1.29)
+
+v0.1.29 lifts execution into a pluggable driver layer: one narrow `ExecutionBackend`
+contract with interchangeable `node`/`bun`/`shell`/`container`/`remote`/`ci`
+drivers, selected by `--backend` (parallel to `--sandbox`) and inspected via
+`backend list|show|probe`. The result/evidence envelope is schema-identical across
+backends; the backend id + sandbox attestation are recorded as provenance, so this
+surface is unchanged regardless of which backend executed a run. See
+[execution-backends.7.md](execution-backends.7.md).
+## Web / Desktop Workbench (v0.1.30)
+
+v0.1.30 adds the Web / Desktop Workbench: a read-only, localhost-only human
+console that renders this surface (and the other four operator panels — run
+graph, blackboard, worker logs, candidate compare, audit timeline) for any run,
+reading the SAME capability `--json` payloads. It is a THIRD FRONT DOOR alongside
+the CLI and MCP that holds no authoritative state and forks no schema: each panel
+equals its `cw <cmd> --json` payload byte-for-byte (parity-gated), and refresh
+re-derives everything from disk. See
+[web-desktop-workbench.7.md](web-desktop-workbench.7.md).
+
+## Observability + Cost Accounting (v0.1.31)
+
+v0.1.31 adds Observability + Cost Accounting: `metrics show`/`metrics summary`
+derive durations, failure/verifier/acceptance rates (with sample counts and
+fail-closed `n/a`), and host-attested token/cost from existing durable run state
+— no metrics database, no collector daemon, no hidden counter. Usage is additive
+and optional (absent ⇒ `unreported`, never 0); cost is `attested` (attested usage
+× a recorded pricing policy) or clearly `estimated`, with pricing as policy. Both
+verbs are parity-gated and render read-only in the v0.1.30 Workbench. See
+[observability-cost-accounting.7.md](observability-cost-accounting.7.md).
+
+
+## Team Collaboration (v0.1.32)
+
+v0.1.32 adds Team Collaboration: a host-attested actor and append-only
+approvals/rejections/comments/handoffs provenance-linked to a durable target,
+plus a review gate that STACKS ON the verifier gate — required approvals from
+authorized roles, enforced inside `resolveCommitGate` AFTER the verifier checks
+and never instead of them, failing closed on quorum/authority/self-approval and
+recording who approved the very artifact that shipped. Policy (required approvals,
+authorized roles, self-approval) is data, default off (pre-v0.1.32 behavior
+unchanged). The verbs are parity-gated and render read-only in the v0.1.30
+Workbench. See [Team Collaboration](team-collaboration.7.md).
+
+## Release Tooling (v0.1.33)
+
+the per-tag mechanical surfaces (version bump across 17 surfaces, feature scaffold, and the forward-reference docs) become deterministic scripts, with a de-duplicated release gate. See release-tooling(7).
+
+## Real Execution Backend Integrations (v0.1.34)
+
+container/remote/ci backends really execute (docker/podman run, remote/CI POST-and-poll) under the sandbox contract, with byte-stable evidence vs node and fail-closed refusal when a runtime/endpoint is unavailable. See real-execution-backends(7).
+
+## Node Snapshot / Diff / Replay (v0.1.35)
+
+per-node snapshot, structural diff, and isolated deterministic replay over StateNode, reusing the v0.1.23 eval harness; fail-closed on source drift (valid|stale|absent). See node-snapshot-diff-replay(7).
+
+## Contract Migration Tooling (v0.1.36)
+
+first-class declared migration registry (run-state + workflow-app) with per-edge compatibility proofs, fail-closed reachability, and a round-trip/non-destruction prover. See contract-migration-tooling(7).
+
+## Control-Plane Scheduling (v0.1.37)
+
+priority + concurrency limits + lease lifecycle + retry/backoff + fail-closed park over the v0.1.28 Run Registry queue; policy-as-data, deterministic. See control-plane-scheduling(7).
+
+## Agent Delegation Drive (v0.1.38)
+
+spawn an external agent process per worker, capture result.md + attestation, auto-drive plan->dispatch->fulfill->accept->commit
+
+## Run Retention & Provable Reclamation (v0.1.39)
+
+tiered, append-only, cryptographically-verifiable run reclamation: seal the audit skeleton, free the reconstructable bulk, prove it
+
+## Durable State & Locking (v0.1.40)
+
+atomic temp->rename writes + fsync-durability for authoritative stores; portable stale-stealing file lock serializing the cross-process read-modify-write stores
+
+## Self-Audit Hardening & Pure-Router Decomposition (v0.1.41)
+
+evidence grounding + durable audit append + symlink-hardened containment + deterministic worker ids + recursive redaction; BackendRegistry self-describing drivers (no per-id switches); orchestrator god-object decomposed into per-domain operation modules (pure loadRun->delegate router)
+
+## Robust Result Ingest (v0.1.42)
+
+capture findings/evidence from any reasonable agent shape (alt keys + prose), CW derives grounded evidence itself, warn on empty capture — closes the v0.1.41 live-drive 'accepted with 0 captured' failure
+
+## No-False-Green Gate & Launch Prep (v0.1.43)
+
+Hard gate blocking empty-capture verifier-gated commits, plus quickstart and launch-prep docs.
+
+## Release-Gate Determinism & Agents Vendor (v0.1.44)
+
+Release-readiness checks now validate the committed blob (`git show HEAD:<path>`) instead of the mutable working tree — eliminating false-red/false-green from concurrent working-tree writes (iCloud/Spotlight/editor). Adds the `agents` vendor manifest target: a generated `.agents/plugins/cool-workflow/` adapter giving any non-Claude AI agent one common interface to CW.
+
+## P1-P2 Fixes & CI Content Surfaces (v0.1.49)
+
+Migration DAG with reversible edges (v0.1.45), capability auto-discovery (v0.1.46), vendor-adapter registry (v0.1.47), state auto-compaction and P2 fixes (v0.1.48), plus CI content-surface determinism hardening (v0.1.49).
+0.1.51
+
+0.1.76
+
+0.1.77
+
+0.1.78

package/docs/multi-agent-runtime-core.7.md

@@ -0,0 +1,231 @@
+# Multi-Agent Runtime Core
+
+CW v0.1.17 made multi-agent runtime state first-class. Dispatches and worker
+records still exist, but they now have explicit process-table-style state around
+them: `MultiAgentRun`, `AgentRole`, `AgentGroup`, `AgentMembership`,
+`AgentFanout`, and `AgentFanin`.
+
+CW v0.1.18 extends these records with blackboard and topic links so fanout,
+worker manifests, accepted worker output, and fanin evidence can cite the
+Coordinator / Blackboard substrate.
+
+This release is the runtime core, not an autonomous scheduler. CW records and
+validates the state model. The agent host still executes agents and enforces
+OS/process/network/environment controls.
+
+## State Model
+
+Multi-agent state lives in durable run state:
+
+```text
+.cw/runs/<run-id>/state.json
+  multiAgent:
+    schemaVersion: 1
+    runs: []
+    roles: []
+    groups: []
+    memberships: []
+    fanouts: []
+    fanins: []
+```
+
+CW also mirrors records to local JSON files:
+
+```text
+.cw/runs/<run-id>/multi-agent/
+  index.json
+  runs/<multi-agent-run-id>.json
+  roles/<role-id>.json
+  groups/<group-id>.json
+  memberships/<membership-id>.json
+  fanouts/<fanout-id>.json
+  fanins/<fanin-id>.json
+```
+
+All records carry stable ids, timestamps, schema versions, lifecycle history,
+parent/child links where relevant, and metadata. Records link back to the
+existing workflow run, phase, task, dispatch, worker, result, verifier,
+candidate, commit, and audit surfaces.
+
+## Runtime Objects
+
+`MultiAgentRun` is the top-level runtime table entry for coordinated agent work.
+Its lifecycle is:
+
+```text
+planned -> forming -> running -> collecting -> verifying -> completed
+```
+
+It may also move to `failed` or `cancelled`. Invalid lifecycle transitions fail
+closed.
+
+`AgentRole` describes responsibility, required evidence, sandbox profile hints,
+expected artifacts, and fanin obligations.
+
+`AgentGroup` is a coordinated set of members for a phase or subproblem. Groups
+hold role, task, membership, worker, fanout, and fanin ids.
+
+`AgentMembership` binds one role to one task and, once dispatched, one worker.
+A worker can belong to one or more groups only through explicit membership
+records. Duplicate membership for the same group, role, task, and worker fails
+closed.
+
+`AgentFanout` records why work was split, which roles/tasks/workers were
+created or attached, concurrency limits, sandbox profile choices, dispatch ids,
+and the expected return shape.
+
+`AgentFanin` records aggregation strategy, required roles, reported members,
+missing members, evidence coverage, blocked reasons, and verifier readiness.
+Fanin does not silently accept missing evidence for required roles.
+
+## Dispatch Integration
+
+Existing dispatch and worker flows remain valid:
+
+```bash
+node scripts/cw.js dispatch <run-id> --limit 1 --sandbox readonly
+```
+
+To attach dispatch to explicit multi-agent state:
+
+```bash
+node scripts/cw.js multi-agent run <run-id> --id ma-release --objective "release verification"
+node scripts/cw.js multi-agent role <run-id> verifier \
+  --multi-agent-run ma-release \
+  --responsibility "verify release evidence" \
+  --required-evidence "release-check log"
+node scripts/cw.js multi-agent group <run-id> release-group \
+  --multi-agent-run ma-release \
+  --phase "Verify" \
+  --task verify:package
+node scripts/cw.js multi-agent fanout <run-id> release-fanout \
+  --group release-group \
+  --reason "split release verification" \
+  --role verifier \
+  --task verify:package \
+  --limit 1 \
+  --sandbox-choice verifier=readonly
+node scripts/cw.js dispatch <run-id> \
+  --limit 1 \
+  --sandbox readonly \
+  --multi-agent-run ma-release \
+  --multi-agent-group release-group \
+  --multi-agent-role verifier \
+  --multi-agent-fanout release-fanout
+```
+
+Worker manifests then include:
+
+```json
+{
+  "multiAgent": {
+    "runId": "ma-release",
+    "groupId": "release-group",
+    "roleId": "verifier",
+    "membershipId": "membership-id",
+    "fanoutId": "release-fanout"
+  }
+}
+```
+
+When CW accepts worker output, it updates linked membership evidence and records
+multi-agent trust audit events.
+
+## Fanin
+
+Collect fanin after worker output:
+
+```bash
+node scripts/cw.js multi-agent fanin <run-id> release-fanin \
+  --group release-group \
+  --fanout release-fanout \
+  --required-role verifier
+```
+
+If a required role has no membership, or a membership has not reported evidence,
+the fanin record is `blocked` and `verifierReady=false`. This is intentional:
+missing evidence is a state error, not an implicit success.
+
+## Inspect
+
+Use normal operator commands:
+
+```bash
+node scripts/cw.js status <run-id>
+node scripts/cw.js graph <run-id>
+node scripts/cw.js report <run-id> --show
+node scripts/cw.js audit summary <run-id>
+node scripts/cw.js audit provenance <run-id>
+```
+
+Use focused multi-agent commands:
+
+```bash
+node scripts/cw.js multi-agent summary <run-id>
+node scripts/cw.js multi-agent summary <run-id> --json
+node scripts/cw.js multi-agent graph <run-id>
+node scripts/cw.js multi-agent graph <run-id> --json
+node scripts/cw.js multi-agent show <run-id> <multi-agent-run-id>
+node scripts/cw.js multi-agent role <run-id> <role-id>
+node scripts/cw.js multi-agent group <run-id> <group-id>
+node scripts/cw.js multi-agent membership <run-id> <membership-id>
+node scripts/cw.js multi-agent fanout <run-id> <fanout-id>
+node scripts/cw.js multi-agent fanin <run-id> <fanin-id>
+```
+
+The status and report Multi-Agent panel shows group status, role coverage,
+membership health, fanout/fanin progress, blocked reasons, and the next
+recommended action.
+
+## MCP Parity
+
+MCP read/inspect tools:
+
+```text
+cw_multi_agent_summary
+cw_multi_agent_graph
+cw_multi_agent_run_show
+cw_multi_agent_role_show
+cw_multi_agent_group_show
+cw_multi_agent_membership_show
+cw_multi_agent_fanout_show
+cw_multi_agent_fanin_show
+```
+
+Safe write tools:
+
+```text
+cw_multi_agent_run_create
+cw_multi_agent_run_transition
+cw_multi_agent_role_create
+cw_multi_agent_group_create
+cw_multi_agent_membership_create
+cw_multi_agent_fanout_create
+cw_multi_agent_fanin_collect
+```
+
+There is no MCP-only or CLI-only core model. The dogfood release script remains
+CLI-only because it is a local release-engineering composition of existing CW
+tools, not a new runtime primitive.
+
+## Compatibility
+
+Older v0.1.16 and earlier run state normalizes with:
+
+```json
+{
+  "multiAgent": {
+    "schemaVersion": 1,
+    "runs": [],
+    "roles": [],
+    "groups": [],
+    "memberships": [],
+    "fanouts": [],
+    "fanins": []
+  }
+}
+```
+
+Unknown user data is preserved. Fixtures are copied before compatibility tests,
+and fixture files are not mutated.
+0.1.51

package/docs/multi-agent-topologies.7.md

@@ -0,0 +1,103 @@
+# Multi-Agent Topologies
+
+CW v0.1.19 adds the first official topology layer on top of the Multi-Agent
+Runtime Core and Coordinator / Blackboard.
+
+Topologies are userland recipes, not hidden automation. Applying a topology
+materializes ordinary CW records: `MultiAgentRun`, roles, groups, fanouts,
+fanins, blackboard topics, messages, coordinator decisions, audit events,
+candidate links, selections, commits, and graph nodes.
+
+## Official Topologies
+
+- `map-reduce`: creates mapper roles, a reducer role, mapper fanout, mapper
+  output topics, reducer synthesis topics, and fail-closed fanin readiness.
+- `debate`: creates opposing roles, debate round topics, conflict context,
+  coordinator claim decisions, and a final synthesis role.
+- `judge-panel`: creates independent judge roles, a panel chair, judge verdict
+  topics, score aggregation expectations, and panel decision provenance.
+
+## Contract
+
+Each topology definition declares:
+
+- roles and groups
+- blackboard topics
+- phases
+- fanout and fanin strategy
+- required evidence
+- coordinator decision kinds
+- candidate and scoring expectations
+- verifier gates
+
+Durable topology run records live in:
+
+```text
+.cw/runs/<run-id>/topologies/index.json
+.cw/runs/<run-id>/topologies/runs/<topology-run-id>.json
+```
+
+The topology record links to the generated multi-agent run, roles, groups,
+fanouts, fanins, blackboard topics, messages, coordinator decisions,
+candidates, selections, commits, and trust audit events.
+
+## CLI
+
+```bash
+node scripts/cw.js topology list
+node scripts/cw.js topology show map-reduce
+node scripts/cw.js topology validate map-reduce
+node scripts/cw.js topology apply <run-id> map-reduce --task map:server-api --mapper-count 2
+node scripts/cw.js topology summary <run-id>
+node scripts/cw.js topology graph <run-id>
+```
+
+Apply commands are JSON-first. `summary` and `graph` also support human output
+and `--json`.
+
+## MCP
+
+MCP parity tools:
+
+- `cw_topology_list`
+- `cw_topology_show`
+- `cw_topology_validate`
+- `cw_topology_apply`
+- `cw_topology_summary`
+- `cw_topology_graph`
+
+There is no topology behavior that is intentionally CLI-only.
+
+## Fail Closed
+
+Topology fanin uses the existing `AgentFanin` checks. Required roles without
+memberships, memberships without result evidence, and memberships without
+indexed blackboard evidence remain blocked. A topology run can recommend the
+next command, but it does not silently mark missing evidence as complete.
+
+For map-reduce, reducer readiness requires mapper evidence and blackboard
+artifact refs. For debate, synthesis must cite messages, conflict context, and
+coordinator decisions. For judge-panel, no judge output is authoritative until
+fanin and score evidence support a panel decision.
+
+## Operator UX
+
+`status`, `report --show`, and `graph` include topology progress:
+
+- topology id and topology run id
+- generated multi-agent run and blackboard id
+- roles, topics, fanouts, and fanins
+- readiness and missing evidence
+- conflicts
+- deterministic next action
+
+Trust audit summaries include topology event counts, and audit provenance can
+follow worker evidence into blackboard artifacts, fanin, candidate selection,
+commits, and reports.
+
+CW v0.1.22 adds policy-aware topology inspection. Applying a topology records
+role policies, message provenance, blackboard write audit, judge rationale,
+panel decisions, and policy violations through the same trust-audit log used by
+worker sandbox and evidence provenance records. Judge-panel selection now
+requires evidence-backed judge rationale and panel-chair rationale.
+0.1.51