@pennixrv/trellis 0.7.0-beta.9 → 0.7.1-beta.1

package/dist/templates/common/bundled-skills/trellis-channel/references/forum.md

@@ -1,233 +0,0 @@
-# Forum Channels
-
-Forum channels are durable, topic-style channels. They are created with
-`--type forum` at channel-creation time and are immutable after that. They are
-not normal chat streams: the default read path is
-**forum summary -> one thread timeline -> current context**.
-
-## Forum vs Regular Channel
-
-A channel's type is set with `--type` on `channel create` and never changes:
-
-- `chat` (default) — flat message timeline. `channel messages` always renders
-  the event stream. Forum-only flags such as `--thread` and `--action` are
-  rejected here.
-- `forum` — thread-oriented. `channel messages` without filters renders a
-  thread-board summary instead of raw events. The `post`, `forum`, `thread`,
-  and `thread rename` subcommands only apply to forum channels.
-
-Both types share the same scope model (`--scope project` is the default;
-`--scope global` puts the channel in the cross-project bucket).
-
-## Create A Forum Channel
-
-```bash
-trellis channel create design-feedback \
-  --type forum \
-  --scope global \
-  --description "Cross-project design feedback board." \
-  --context-raw "One thread per design topic; close when resolved." \
-  --by main
-```
-
-Use `--scope project` for a board scoped to one repo, `--scope global` for a
-cross-project board.
-
-## Threads: Open, Comment, Status, Summary
-
-Threads live inside a forum channel. Each thread is identified by a stable
-`--thread <key>` (lowercase kebab-case is conventional). The first action on
-a thread is `opened`; everything afterwards uses the same `--thread` key.
-
-```bash
-trellis channel post design-feedback opened \
-  --scope global \
-  --as main \
-  --thread login-empty-state \
-  --title "Empty state on the login screen" \
-  --description "Track design feedback for the new login empty state." \
-  --labels design,login \
-  --context-raw "Spotted during the 0.4 release review." \
-  --text-file /tmp/thread-open.md
-
-trellis channel post design-feedback comment \
-  --scope global \
-  --as reviewer \
-  --thread login-empty-state \
-  --text-file /tmp/review.md
-
-trellis channel post design-feedback status \
-  --scope global \
-  --as main \
-  --thread login-empty-state \
-  --status closed
-
-trellis channel post design-feedback summary \
-  --scope global \
-  --as main \
-  --thread login-empty-state \
-  --summary "Adopted the option-B layout; ticket TRELLIS-123 owns the fix."
-```
-
-Key distinctions:
-
-- `--description` is the **durable** thread description (the answer to "what
-  is this thread about?"). It is set on `opened` and edited by re-running
-  `post` with `--description`.
-- `--text` / `--stdin` / `--text-file` is the **event body** — the comment or
-  payload attached to this specific timeline entry.
-- `--labels` and `--assignees` are CSV and **replace** the current value; they
-  do not append.
-- `--summary` is the rolling thread summary. Setting it on `status closed` is
-  the standard way to mark a thread resolved with context.
-
-`--thread` is required for every action except `opened` (where it is also
-required in practice — there is no anonymous thread).
-
-## Read A Forum
-
-```bash
-trellis channel messages design-feedback --scope global
-trellis channel forum design-feedback --scope global --status open
-trellis channel thread design-feedback login-empty-state --scope global
-trellis channel messages design-feedback --scope global --raw --thread login-empty-state
-```
-
-If a peer says "I commented on the forum", run `channel forum` first to see
-which thread changed, then drill into that thread with `channel thread <name>
-<thread>`. Do not jump straight to ad-hoc `events.jsonl` parsing.
-
-## Context
-
-Context entries are durable background that should always be in scope when
-reading a channel or a thread. They are **not** timeline events; they are
-projected separately and replayed for every reader.
-
-Use the `context` subcommands. The legacy `--linked-context-file` /
-`--linked-context-raw` flags on `create` and `post` are deprecated aliases
-that fold into the canonical `--context-file` / `--context-raw`.
-
-### Add Context
-
-```bash
-# Channel-level context (whole forum)
-trellis channel context add design-feedback \
-  --scope global \
-  --raw "Upstream feedback board; please link tasks before opening threads."
-
-# Thread-level context (one thread)
-trellis channel context add design-feedback \
-  --scope global \
-  --thread login-empty-state \
-  --file "$PWD/.trellis/tasks/05-13-login-redesign/design.md"
-```
-
-- `--thread <key>` switches between channel-level and thread-level context.
-- `--file` paths **must be absolute**; relative paths are rejected.
-- `--raw` is plain text inline content.
-- Both flags are repeatable; at least one is required for `add` / `delete`.
-- `--as <agent>` records authorship; defaults to `main`.
-
-### List Context
-
-```bash
-trellis channel context list design-feedback --scope global
-trellis channel context list design-feedback --scope global --thread login-empty-state --raw
-```
-
-`--raw` on `list` emits one JSON entry per line (useful for piping); without
-it you get a human-readable `file <path>` / `raw <truncated text>` listing.
-An empty store prints `(no context)`.
-
-### Delete Context
-
-```bash
-trellis channel context delete design-feedback \
-  --scope global \
-  --thread login-empty-state \
-  --raw "stale note"
-```
-
-You delete by **value**, not by id: pass the same `--file` or `--raw` value
-that was added. Repeat the flag to delete multiple entries in one call.
-
-### Reading Order
-
-When reading a thread, work top-down:
-
-1. Thread `description` (the durable "what is this about").
-2. Context entries (channel-level + thread-level).
-3. Timeline (`opened`, `comment`, `status`, `summary`).
-
-If a context file is missing or unreadable, state that explicitly and
-continue with the remaining data — do not fabricate the content.
-
-## Title Projection
-
-`title` projects a stable display title onto the channel without renaming the
-storage address. The channel `name` you pass to every command stays the same.
-
-```bash
-trellis channel title set design-feedback \
-  --scope global \
-  --title "Design feedback board"
-
-trellis channel title clear design-feedback --scope global
-```
-
-- `title set` requires `--title`.
-- `--as <agent>` records authorship; defaults to `main`.
-- This is a presentation-layer change. Tooling and scripts keep using the
-  original channel name.
-
-## Thread Rename
-
-`thread rename` is the correction path when a thread was opened with the
-wrong key (typo, wrong slug convention, etc.). Threads do not support hard
-deletion — rename is the supported corrective action.
-
-```bash
-trellis channel thread rename design-feedback old-key new-key \
-  --scope global \
-  --as main
-```
-
-- `--as <agent>` is **required**.
-- `post <name> rename` is rejected — you must use `thread rename`.
-
-## Deletion Discipline
-
-Do not model single-comment deletion or hard thread deletion as normal
-workflow. Forum threads are append-only collaboration history. To correct
-state, use:
-
-- `post ... status` to mark a thread closed / blocked / etc.
-- `post ... summary` to record the resolution.
-- `post ... --labels` to re-label (replaces the set).
-- `thread rename` to correct a bad thread key.
-
-## Internal Changelog Pattern
-
-A common use of a global forum channel is an internal release / runtime
-changelog. One thread per notable change keeps history searchable:
-
-```bash
-trellis channel create release-notes \
-  --type forum \
-  --scope global \
-  --description "Internal release and runtime changelog." \
-  --context-raw "One thread per notable change; close when shipped." \
-  --by main
-
-trellis channel post release-notes opened \
-  --scope global \
-  --as main \
-  --thread release-2026-q1 \
-  --title "Channel threads and forum UX in 0.6" \
-  --description "Forum channel UX shipped in the 0.6 line." \
-  --labels channel,release \
-  --text-file /tmp/release-notes.md
-```
-
-Use stable, descriptive thread keys (e.g. `release-2026-q1`,
-`runtime-event-schema-change`) so later readers can find them by name.

package/dist/templates/common/bundled-skills/trellis-channel/references/progress-debugging.md

@@ -1,237 +0,0 @@
-# Progress And Debugging
-
-Pretty output is for operators. Raw output is the audit log. Subcommands
-(`forum`, `thread`, `messages`, `context`) are the audit _interface_ — reach
-for them before grepping `events.jsonl` by hand.
-
-## Pretty vs `--raw`
-
-`trellis channel messages <channel>` renders a compact, human-readable view:
-timestamps, identities, kind, and a short body. It is meant for operators
-scanning a channel, not for diagnostics.
-
-Pretty output can and will truncate:
-
-- long progress deltas (`text_delta`, partial tool args)
-- tool names and command lines
-- multi-line status fields and structured `detail` blobs
-- forum thread titles past the column budget
-
-When something looks "off" — a worker appears stuck, a progress line ends
-mid-word, an action field shows `...` — switch to `--raw`. Raw mode emits
-one JSON event per line exactly as it lives in `events.jsonl`, so nothing
-is dropped.
-
-```bash
-# Pretty (operator view)
-trellis channel messages <channel> --kind done --last 10
-trellis channel messages <channel> --kind error --last 10
-
-# Raw (diagnostic view) — one JSON per line
-trellis channel messages <channel> --raw --kind progress --last 20
-trellis channel messages <channel> --raw --last 50
-```
-
-Rule of thumb: never diagnose a worker from a truncated progress line.
-
-### Rebuild Streaming Text
-
-To reconstruct what a model actually streamed during a turn, concatenate
-`detail.text_delta` from progress events:
-
-```bash
-trellis channel messages <channel> --raw --kind progress --last 80 \
-  | python3 -c 'import json,sys; [print((json.loads(l).get("detail") or {}).get("text_delta",""), end="") for l in sys.stdin if l.strip()]'
-```
-
-## Stalled Worker Diagnosis
-
-Symptom: `trellis channel list` shows the worker as running, but no new
-events appear in `messages` and `wait` keeps timing out.
-
-Triage order:
-
-1. **Locate the channel files.** Use `list --all --all-projects` if you are
-   not sure which bucket the channel lives in.
-
-   ```bash
-   trellis channel list --all --all-projects
-   CHAN=~/.trellis/channels/<bucket>/<channel>
-   ```
-
-2. **Confirm the supervisor and worker PIDs are alive.**
-
-   ```bash
-   cat "$CHAN/<worker>.pid"            # supervisor PID
-   cat "$CHAN/<worker>.worker-pid"     # actual CLI subprocess PID
-   ps -p "$(cat "$CHAN/<worker>.pid")"
-   ps -p "$(cat "$CHAN/<worker>.worker-pid")"
-   ```
-
-   If the supervisor PID is gone but the channel still lists the worker,
-   you have a ghost entry — clean it with
-   `trellis channel kill <name> --as <worker> --force`.
-
-3. **Tail the worker log.** This is the canonical place to see provider /
-   MCP / tool startup output that never makes it onto the channel.
-
-   ```bash
-   tail -f "$CHAN/<worker>.log"
-   ```
-
-4. **Check the last raw events.** A worker that emitted `progress` but no
-   `message`/`done` is usually mid-stream or blocked on a tool call:
-
-   ```bash
-   trellis channel messages <channel> --raw --last 50
-   ```
-
-Common "alive but silent" causes:
-
-- Provider cold start before the first token (long, but eventually moves).
-- A blocking MCP server during startup — visible in the worker log.
-- Worker is waiting for a tool result whose subprocess hung.
-- Prompt is huge / model is rate-limited; check provider-side errors in the
-  worker log.
-
-## Progress Event Interpretation
-
-A `progress` event represents an in-flight piece of work. Its shape varies
-by `action` field, but the load-bearing fields are always under `detail`:
-
-- `detail.text_delta` — incremental model output (concatenate across events
-  to rebuild the streamed reply).
-- `detail.tool_name`, `detail.tool_input` — tool call about to run or
-  currently running.
-- `detail.status` — short string used by long-running actions
-  (`starting`, `running`, `flushing`, `done`).
-- `detail.action` — semantic label (e.g. `status` for thread heartbeats).
-
-Progress events are **noisy** by design. `wait` ignores them unless you
-pass `--include-progress`. When you do want to see them, prefer:
-
-```bash
-trellis channel messages <channel> --raw --kind progress --last 80
-```
-
-A stream that emits progress at a steady cadence but never closes with
-`done`/`error`/`message` is the classic shape of a hung tool call —
-inspect the worker log for the subprocess.
-
-## Wait Semantics (Quick Reference)
-
-Without `--after-seq`, `channel wait` captures the current durable sequence,
-then watches matching later events. For an operation that can finish before the
-wait command starts, capture a barrier before that operation and pass it back:
-
-```bash
-BARRIER="$(trellis channel barrier T)"
-# spawn or trigger work that may emit a terminal event
-trellis channel wait T --as main --from check --kind done,error \
-  --after-seq "$BARRIER" --timeout 15m
-```
-
-It wakes on:
-
-- `message`
-- `done`
-- `error`
-- `killed`
-- `progress` only with `--include-progress`
-
-Useful filters:
-
-```bash
-trellis channel wait T --as main --from check --kind done --timeout 15m
-trellis channel wait T --as main --from check,check-cx --kind done --all --timeout 15m
-trellis channel wait T --as worker --kind message --timeout 1h
-trellis channel wait T --as main --thread release-note --action status --timeout 10m
-```
-
-Exit codes: `0` matched, `124` timeout, `1`/`2` errors. On `wait --all`
-timeout, stderr names the workers still missing.
-
-## Auditing `events.jsonl` — Use Subcommands, Not `grep`
-
-Every channel persists its full history at `$CHAN/events.jsonl`. It is
-tempting to `tail` / `grep` / `jq` this file directly during debugging.
-Don't make it a habit, and **never** do it for forum channels.
-
-Why subcommands first:
-
-- `messages` already replays the file with filters (`--kind`, `--from`,
-  `--last`, `--tag`, `--thread`, `--action`) and gives you `--raw` for the
-  exact JSON. Anything you would write a one-liner for, `messages` already
-  does.
-- `wait` consumes the same file with EOF semantics — re-implementing that
-  with `tail -f | jq` will drop events under load and misorder them under
-  rotation.
-- `context` materializes a worker's inbox view, including cursor state.
-  Hand-rolled filters do not respect `<worker>.inbox-cursor`.
-
-### Forum channels: never parse `events.jsonl` directly
-
-Forum channels multiplex many logical threads onto a single `events.jsonl`.
-Each event carries `thread`, `action`, and tag fields that the forum
-subcommands know how to fold together. Parsing the file by hand will:
-
-- Mix threads together and make a thread look incoherent.
-- Miss thread lifecycle events (open / status / close) that change how
-  later events should be interpreted.
-- Ignore worker inbox cursors, so you will "see" events a worker has
-  already consumed and assume they are pending.
-
-Use the forum-aware views instead:
-
-```bash
-# List logical threads inside the forum channel
-trellis channel forum list <channel>
-
-# Inspect one thread end-to-end
-trellis channel thread show <channel> <thread>
-
-# Replay messages for a thread (supports --raw, --kind, --last)
-trellis channel messages <channel> --thread <thread> --raw --last 100
-
-# What a specific worker still has pending
-trellis channel context <channel> --as <worker>
-```
-
-Direct reads of `events.jsonl` are reserved for the case where the CLI
-itself is suspect — e.g. confirming an event was actually persisted, or
-diffing against `<worker>.inbox-cursor` while debugging the supervisor.
-
-## Common Failures
-
-| Symptom                          | Cause                                 | Fix                                                             |
-| -------------------------------- | ------------------------------------- | --------------------------------------------------------------- |
-| `trellis: command not found`     | CLI not installed globally            | `npm install -g @pennixrv/trellis`                              |
-| `wait` exits immediately         | wrong filter or identity collision    | use distinct `--as`, inspect raw messages                       |
-| zsh errors on message text       | shell interpreted punctuation         | use `--stdin` or `--text-file`                                  |
-| progress line is cut off         | pretty output truncation              | use `messages --raw --kind progress`                            |
-| worker never speaks              | provider startup / prompt / MCP delay | inspect `<worker>.log`, `ps`, raw events                        |
-| channel not found in another cwd | project bucket mismatch               | `cd` to project, use `--scope global`, or `list --all-projects` |
-| ghost worker in list             | supervisor died without cleanup       | `trellis channel kill <name> --as <worker> --force`             |
-| forum thread looks scrambled     | parsed `events.jsonl` directly        | use `forum`, `thread`, `messages --thread`                      |
-
-## Storage Layout
-
-```text
-~/.trellis/channels/
-└── <bucket>/
-    └── <channel-name>/
-        ├── events.jsonl
-        ├── <channel>.lock
-        ├── <worker>.log
-        ├── <worker>.pid
-        ├── <worker>.worker-pid
-        ├── <worker>.config
-        ├── <worker>.session-id
-        ├── <worker>.thread-id
-        ├── <worker>.inbox-cursor
-        └── <worker>.spawnlock
-```
-
-Agents normally use the CLI, not direct file reads. Direct file reads are
-for debugging when CLI views are insufficient — and even then, never on a
-forum channel's `events.jsonl`.

package/dist/templates/common/bundled-skills/trellis-channel/references/subnode-work.md

@@ -1,222 +0,0 @@
-# Bounded Subnode Work
-
-Use a `subnode` only when the user explicitly needs independently reviewable
-evidence for a bounded analysis, design, audit, review, counterargument, or
-verification question. It is not the normal path for an ordinary static review,
-implementation, memory retrieval, or routine tool call.
-
-The coordinator owns task facts, protected targets, acceptance, Git, worker
-lifecycle, and the final result. A subnode owns one evidence report and its own
-append-only worklog. This is a behavioral contract; do not add `--sandbox` or
-claim that path restrictions enforce it.
-
-## Artifact Setup
-
-Before spawning, the coordinator must use an active task (`planning` or
-`in_progress`), define one stable `work_id` and
-`subnode_id`, then prepare a brief-draft JSON with the question, independence
-reason, scope, protected targets, lens, evidence method, source snapshot,
-dependencies, stop conditions, deadline, and `channel_ref`. Set `retry_of`
-only for an explicit manual retry and `counter_of` only for intentional
-counterwork. A retry names an existing, different subnode in the same task and
-`work_id`; counterwork may be initialized independently. The helper supplies
-the immutable task identity and report path.
-
-```bash
-TASK=.trellis/tasks/09-07-example
-WORK_ID=security-audit
-SUBNODE_ID=dependency-evidence
-
-python3 .trellis/scripts/subnode_artifact.py init \
-  --task "$TASK" \
-  --work-id "$WORK_ID" \
-  --subnode-id "$SUBNODE_ID" \
-  --draft /tmp/subnode-brief.json
-```
-
-This creates exactly:
-
-```text
-$TASK/subnodes/$WORK_ID/$SUBNODE_ID/
-  brief.json     # coordinator-owned and immutable after dispatch
-  worklog.md     # subnode appends material progress and corrections
-  report.json    # subnode-owned final pending-review result
-  disposition.json # coordinator-owned, create-once result decision
-```
-
-Do not use a Channel command or message body as the report transport. The
-subnode's short final assistant reply names the already-written `report.json`
-and its status; the Codex supervisor projects that reply into the durable
-Channel message and `done` events. The durable JSON file carries the
-reviewable result.
-
-The subnode copies identity, scope, and lens from `brief.json`. Schema version 2
-requires one `scope_assessment` entry for every brief scope item, structured
-findings with evidence references, and typed uncertainties or corrections when
-present. Schema version 1 is retired and the validator rejects it. The minimal
-complete report is:
-
-```json
-{
-  "schema_version": 2,
-  "task_id": "task-id-from-brief",
-  "work_id": "work-id-from-brief",
-  "subnode_id": "subnode-id-from-brief",
-  "role_id": "subnode",
-  "status": "complete",
-  "scope": ["exact scope copied from brief"],
-  "lens": "exact lens copied from brief",
-  "scope_assessment": [
-    {
-      "scope": "exact scope item from brief",
-      "status": "covered",
-      "conclusion": "What this scope establishes.",
-      "evidence_ids": ["stable-evidence-id"]
-    }
-  ],
-  "evidence": [
-    {
-      "id": "stable-evidence-id",
-      "locator": "source path, URL, or command receipt",
-      "summary": "What this independently reviewable evidence establishes."
-    }
-  ],
-  "findings": [
-    {
-      "id": "finding-id",
-      "conclusion": "Bounded conclusion.",
-      "evidence_ids": ["stable-evidence-id"]
-    }
-  ],
-  "uncertainties": [],
-  "corrections": []
-}
-```
-
-Append a checkpoint marker to `worklog.md` when a material unit is complete or
-blocked. It is a bounded recovery projection, not coordinator acceptance:
-
-```text
-<!-- trellis-checkpoint: {"id":"checkpoint-1","covered_scope":["exact scope item"],"evidence_ids":["stable-evidence-id"],"conclusion_or_blocker":"Current conclusion or blocker.","unknowns":[],"safe_resume_point":"Next safe action."} -->
-```
-
-The validator returns `review_concern` for missing or incomplete checkpoint
-coverage and for inconclusive scope assessments so the coordinator can inspect
-them. Identity, schema, path, and malformed-structure failures remain hard
-errors. A concern is never automatic acceptance or rejection.
-
-For `blocked`, `incomplete`, or `error`, include the same base fields plus a
-`completed_scope` list (empty when no assigned scope started) and a non-empty
-`blocker` string. Never use
-`accepted`, `rejected`, or `deferred` as a report status.
-
-## Dispatch And Wait
-
-Inspect the installed role first, then capture a durable event barrier before
-the worker can emit a terminal event. The CLI waits once and replays matching
-events committed after that barrier:
-
-```bash
-trellis channel create subnode-example --by main --cwd "$PWD"
-BARRIER="$(trellis channel barrier subnode-example)"
-trellis channel spawn subnode-example --agent subnode --provider codex \
-  --as "$SUBNODE_ID" --cwd "$PWD"
-
-printf '%s\n' "Read $TASK/subnodes/$WORK_ID/$SUBNODE_ID/brief.json and perform only that bounded work." \
-  | trellis channel send subnode-example --as main --to "$SUBNODE_ID" \
-      --stdin --delivery-mode requireRunningWorker
-
-trellis channel wait subnode-example --as main --from "$SUBNODE_ID" \
-  --kind done,error,killed --after-seq "$BARRIER" --timeout 30m
-```
-
-`channel.subnode` in `.trellis/config.yaml` supplies the role defaults for
-`max_live_workers` (generated default `8`), `idle_timeout`, `timeout`, and
-`warn_before`. Change that section before a dispatch group when its resource
-or lifetime needs differ; pass the corresponding `spawn` flag only for a
-one-off override. The generic `channel.worker_guard` remains the fallback for
-ordinary workers and for a subnode key omitted from the project config.
-
-Where the host exposes a live wait continuation, capture the same barrier,
-establish one event waiter before triggering the worker, and continue that same
-waiter until terminal state. Until it resolves, times out, or errors, the next
-host operation is only that continuation: do not create another waiter or run
-shell/CLI diagnostics, including `channel messages`, worker inspection, or
-status/list commands. Do not treat an empty transport slice as completion.
-After the waiter returns, use those commands only for an on-demand diagnosis,
-not as a high-frequency supervision loop.
-
-## Coordinator Review
-
-After the subnode's final reply, independently validate and then record a
-task-level disposition. `complete` means only that the subnode claims it
-completed its assigned work; it is not acceptance. Confirm the terminal state
-from the durable worker projection; a report without a terminal worker is
-still pending, and a terminal worker without a valid report is recovery.
-
-```bash
-REPORT="$TASK/subnodes/$WORK_ID/$SUBNODE_ID/report.json"
-python3 .trellis/scripts/subnode_artifact.py validate --report "$REPORT"
-trellis channel workers subnode-example --include-terminal --json
-```
-
-The coordinator must re-check enough source evidence and protected-target state
-to decide `accepted`, `rejected`, or `deferred`. Record the terminal lifecycle
-and sequence returned by `channel workers`, then let the helper create the
-disposition exactly once:
-
-```bash
-python3 .trellis/scripts/subnode_artifact.py disposition \
-  --report "$REPORT" \
-  --outcome accepted \
-  --terminal-lifecycle done \
-  --terminal-seq 17 \
-  --terminal-at 2026-09-14T03:00:00Z \
-  --check report_validation \
-  --check source_recheck \
-  --check protected_target_check \
-  --reason "Evidence and protected targets were independently rechecked."
-```
-
-`disposition.json` is coordinator-owned and cannot be replaced. The helper
-does not inspect the Channel store or make the acceptance judgment; the
-terminal values must come from the worker projection and the reason records
-the coordinator's decision.
-
-Use the separate coordinator work-record helper only for a durable cross-task
-observation, decision, open question, or blocker. It does not substitute for a
-task artifact or subnode worklog.
-
-```bash
-python3 .trellis/scripts/workspace_note.py \
-  --kind decision \
-  --summary "Accepted independent dependency evidence for the release gate." \
-  --source "$REPORT"
-```
-
-## Counterwork
-
-Counterwork is a new, independently scoped subnode, not a retry. It must use a
-different `subnode_id`, lens, and evidence identities, and its brief sets
-`counter_of` to the primary subnode ID. After both reports are complete:
-
-```bash
-python3 .trellis/scripts/subnode_artifact.py validate-counter \
-  --primary "$TASK/subnodes/$WORK_ID/primary" \
-  --counter "$TASK/subnodes/$WORK_ID/counter"
-```
-
-The coordinator compares the two reports and retains the comparison as part of
-its own disposition.
-
-## Manual Retry
-
-A retry is a fresh, explicitly approved subnode after a recorded failed or
-incomplete attempt. It uses a new `subnode_id`, preserves the old artifacts,
-and sets `retry_of` to that prior subnode ID in its brief. The coordinator must
-record why it is retrying and check the new report independently; neither the
-helper nor Channel decides when to retry.
-
-No scheduler, high-frequency polling loop, automatic retry, worktree, global
-ledger, or provider-specific transport is introduced by this workflow. A
-manual retry always uses a new subnode id and worker handle.