dsh-compound-engineering 0.0.0-stage → 0.1.0

package/skills/ce-pov/references/cross-model-panel.md

@@ -0,0 +1,596 @@
+# Cross-Model POV Panel
+
+This protocol obtains independent peer POVs, reconciles material disagreement,
+and returns one ce-pov decision. ce-pov remains the decision-maker: peers are
+cross-checks, never substitutes or votes. The panel is read-only and
+non-blocking; every branch ends in a panel POV, a solo POV with an availability
+note, or the ordinary POV's explicit blocked-on-missing-context result.
+
+## 1. Resolve the subject, host, and participants
+
+Resolve conversational shorthand before spending: "the approach," "these
+options," and "the three options presented" mean the single unambiguous
+subject identified by the active conversation. Return missing context to the caller when several possible subjects would
+materially change the POV and context cannot distinguish them.
+
+Keep four identities separate for the host and every peer:
+
+- **target** — the user-facing choice (`codex`, `claude`, `grok`, `cursor`,
+  `composer`, `opencode`, or `antigravity`);
+- **harness/intermediary route** — the CLI or intermediary that runs it;
+- **requested model** — an explicit model or the route's declared default; and
+- **served model** — the model the worker's receipt (the route's adapter
+  reporting which model answered) names, otherwise `unverified`.
+
+The requested model is a fact about the request and is always known; the served
+model is a claim about the backend and is known only from a receipt. `unverified`
+means no receipt exists, not that the model is unknown. In anything the user
+reads, name a peer by its target and requested model. Add a serving caveat only
+when a receipt disagrees with the request, or when the route requested no model
+(Cursor default/Auto, OpenCode auto). A receipt-less route with a requested model
+carries `model_actual: unverified` in the panel record and needs no caveat in
+the chat note.
+
+Attest the host from host-provided markers and serving evidence, never from
+another installed CLI or home directory. Set `independence_verified: true` only
+when the peer's served model family is attestably different from the host's.
+Otherwise retain the useful cross-check but label independence unverified; do
+not present it as different-model corroboration. If the host family is unknown,
+automatic discovery excludes any candidate whose independence cannot be
+verified rather than guessing.
+
+Attest the host harness and its serving family as two separate tokens:
+
+```bash
+XHOST_SEEN=;
+if [ "${CLAUDECODE:-}" = "1" ]; then XHOST_SEEN="$XHOST_SEEN claude"; fi;
+if [ -n "${CODEX_SANDBOX:-}${CODEX_SANDBOX_NETWORK_DISABLED:-}${CODEX_SESSION_ID:-}${CODEX_THREAD_ID:-}${CODEX_CI:-}" ]; then XHOST_SEEN="$XHOST_SEEN codex"; fi;
+if [ "${GROK_AGENT:-}" = "1" ] || [ -n "${GROK_SESSION_ID:-}" ]; then XHOST_SEEN="$XHOST_SEEN grok"; fi;
+if [ -n "${OMPCODE:-}" ]; then XHOST_HARNESS=omp; XHOST_FAMILY=unknown;
+elif [ "$XHOST_SEEN" = " claude" ] || [ "$XHOST_SEEN" = " codex" ] || [ "$XHOST_SEEN" = " grok" ]; then XHOST_HARNESS="${XHOST_SEEN# }"; XHOST_FAMILY="$XHOST_HARNESS";
+elif [ -n "$XHOST_SEEN" ]; then XHOST_HARNESS=unknown; XHOST_FAMILY=unknown;
+elif [ -n "${CURSOR_AGENT:-}${CURSOR_CONVERSATION_ID:-}" ]; then XHOST_HARNESS=cursor; XHOST_FAMILY=unknown;
+elif [ -n "${OPENCODE_TERMINAL:-}" ]; then XHOST_HARNESS=opencode; XHOST_FAMILY=unknown;
+else XHOST_HARNESS=unknown; XHOST_FAMILY=unknown; fi
+```
+
+Both tokens come from the same peer-key vocabulary as the targets above, never
+from a provider's corporate name: `<host-serving-family>` (`XHOST_FAMILY`) is
+`codex`, `claude`, `grok`, `composer`, `gemini`, or `unknown`. `<host-harness>`
+(`XHOST_HARNESS`) is `codex`, `claude`, `grok`, `cursor`, `opencode`,
+`antigravity`, `omp`, or `unknown`. The
+snippet is evidence, not the verdict: it resolves the harnesses whose
+environment markers it already names, and where it yields `unknown` on a harness
+you can identify from your own runtime, attest what you know instead. A harness
+the snippet does not name needs no new branch here.
+
+Claude Code, Codex, and Grok each serve their own model family, so the snippet
+takes the family from that harness's marker when it is the only such marker
+present. Another harness can copy one of those markers (oh-my-pi sets
+`CLAUDECODE=1` whatever model serves it), and a session started from inside
+another harness inherits that harness's marker. So the snippet leaves family
+`unknown` under `OMPCODE` or when more than one of those markers is present.
+Pass a family the snippet names. Where it leaves family `unknown`, set it only
+from a model id the runtime publishes as the model serving this session, and
+only when that id maps to `codex`, `claude`, `grok`, `composer`, or `gemini`. A
+requested model, the model's own claim, and the product name are not that id.
+Never infer serving family from the Cursor brand.
+
+Section 4 passes `XHOST_FAMILY` as the worker's first argument and
+`XHOST_HARNESS` as `CROSS_MODEL_HOST_HARNESS`; a provider name such as
+`anthropic`, `openai`, or `xai` in either slot makes the worker refuse the
+job and produce no artifact.
+
+`Cursor` and `Composer` are distinct targets:
+
+- `cursor` uses `cursor-agent` with no forced model, allowing Cursor's configured
+  default/Auto choice. No model was requested, so unless a receipt identifies it,
+  report `Cursor default/Auto; serving model unverified` and
+  `independence_verified: false`.
+- `composer` requests the current compatible Composer model through
+  `cursor-agent`.
+- `grok` prefers the native Grok CLI; Grok through Cursor is a different route
+  and recipient. Section 3 binds which token.
+- `antigravity` runs a Gemini model through Google Antigravity's ACP runtime,
+  and its serving family is `gemini`. A request for a Gemini peer binds this
+  target. `CROSS_MODEL_PEERS` sanctions it only through the literal token
+  `antigravity`, so a skip there names that token. It is never a peer when the
+  host's serving family is `gemini` or its harness is `antigravity`.
+
+Apply exactly one participation branch:
+
+`oracle` is shorthand for the panel behavior, not a keyword gate. An explicit
+request to consult other models, gather independent peer opinions, pressure-test
+with named peers, or reconcile their disagreement enters the same protocol even
+when the request never says `oracle`. A request for ce-pov's take alone does not.
+
+- **Named peers:** exact and uncapped. Announce and run every named target.
+  Explicit names override
+  `oracle` discovery and its cap. Never rewrite named `Cursor` to Composer or
+  replace an explicitly named model with another model.
+- **Bare `oracle`:** select up to two reachable, attestably different-model
+  targets using conversation preference, local configuration, active project
+  conventions, then the default order `codex -> claude -> grok -> antigravity`;
+  announce the selection and run
+  it. Invoking `oracle` authorizes this ordinary read-only consultation against
+  the current project.
+- **Explicit unnamed cross-check:** skip the correction-cost check and use the
+  count rule below; announce the selected peers and run them.
+- **No explicit cross-check:** after ce-pov independently forms its POV, offer
+  only when meaningful downstream work will build on the take before an error
+  would show up, or it feeds a shared, public, security, or data commitment.
+  Adoption Tier 1 is ineligible; Tier 2/3 are eligible. A warm invocation (a
+  mid-session second opinion) never offers.
+
+For the count rule: zero reachable means solo plus one availability line. One
+or more auto-selected peers means one concise progress line naming the selected
+targets before dispatch.
+Cursor default and Composer are never selected automatically; they run when
+named or configured as a preference.
+
+**Prior-opinion subjects.** When the subject is an already-formed position —
+ce-pov's own prior POV or the user's stated view — that position is the subject
+artifact and ships in the payload; peers answer the underlying question with
+their own verdict, and those `independent` voices enter convergence (unlike
+`skeptic` mode, where the critique does not). Any fresh host meta-judgment formed
+after the panel request (the summons) is withheld per Section 4's round-1 sequencing. A user-supplied
+position is handled identically to a host-authored one — shipped as the subject,
+never capitulated to.
+
+## 2. Normalize scope and freeze repository identity
+
+Normalize the allowed read scope once as:
+
+- one repository-relative workspace root; and
+- optional ordered include and exclude path patterns.
+
+Pass that identical representation to every peer prompt and route adapter. The
+default is the repository root. A narrower user- or host-supplied scope is
+binding and is never broadened. Peers launched on the same host inspect existing
+subject files and supporting evidence directly from this shared working tree;
+point them to those files instead of copying their contents into the payload.
+Pass material inline only when it exists solely in the conversation or is
+otherwise unavailable in the workspace.
+
+Treat include and exclude path patterns as cooperative unless the concrete
+adapter turns them into filesystem controls. Never present prompt-only patterns,
+a working directory, or a read-only flag as a confidentiality boundary, and
+never promise that secrets inside the readable scope are inaccessible. Peers may
+search and read within the declared scope but may not mutate the project or
+intentionally inspect outside it. Every route denies the peer's write requests
+and runs the adapter's read-only mode where one exists, but the Codex adapter
+does not enforce its read-only mode, so no route is a write sandbox.
+
+Before initial dispatch, capture one **repository-scope identity**: the committed
+revision plus a digest of dirty and untracked content inside the normalized
+scope. Include it in every peer payload. Revalidate it before every reconcile
+dispatch and before final fold-in. If it changed, never reconcile or fold stale
+voices into the current project: disclose the change and either restart all
+voices on the new identity or return an incomplete panel result.
+
+The caller passes this panel the resolved absolute `$SCRATCH_DIR` created in
+SKILL.md Phase 1. Keep payloads, raw output, logs, and result artifacts there;
+do not reconstruct the scratch root in this reference. Create each payload under
+`umask 077`, then `chmod 600 "$PAYLOAD_PATH"` before dispatch; do not rely on
+the ambient umask or a mode flag alone.
+
+## 3. Resolve and announce one fixed route
+
+Routing is adaptable only inside hard boundaries. The requested target plus
+safety, authority, independence, read scope, and the rules on which external
+recipients may receive project content are durable;
+concrete model IDs, CLI flags, and availability are adapter defaults.
+
+For each peer:
+
+1. Probe current route and model capabilities without giving the process project
+   content or repository access.
+2. Try the declared preferred mapping first.
+3. If that default is observed unavailable, obsolete, or incompatible, choose
+   only the closest compatible equivalent in the same requested target, model
+   family, and reasoning tier. Record the observed local fact and substitute.
+   An explicit user model request cannot become another model. For
+   `antigravity`, the worker's own fallback from `gemini-4-argon` to
+   `gemini-3.8-flash` is the preferred mapping, so the host passes no
+   replacement model for it.
+4. Resolve one concrete target, model choice, harness route, provider, and every
+   intermediary. Confirm every actual recipient is on the allowlist of permitted
+   external recipients.
+5. Announce the selected target and route in ordinary language before dispatch.
+
+The fixed route passed to the worker accepts exactly these tokens; the worker
+refuses anything else (including route-shaped guesses like `codex-cli`):
+
+| Target | Route token(s) |
+|--------|----------------|
+| `codex` | `codex` |
+| `claude` | `claude` |
+| `grok` | `grok-cli` (native CLI) or `grok-cursor` (via Cursor intermediary) |
+| `cursor` | `cursor` |
+| `composer` | `composer` |
+| `opencode` | `opencode` |
+| `antigravity` | `antigravity` |
+
+The host harness does not choose the Grok route. Target `grok` binds `grok-cli` when that CLI is installed. Bind `grok-cursor` only when the user asked for Grok through Cursor, or when the grok CLI is absent and Cursor is a sanctioned recipient.
+
+Binary presence proves only that a route is a candidate. Pre-dispatch capability
+evidence may refine the fixed route only when the current host context makes that
+evidence authoritative. Do not preflight authentication there: the
+provider-capable worker attempt owns authentication truth, and a valid artifact
+is the usability proof. Classify a failed run from its structured diagnostics
+rather than guessing from a generic terminal state.
+
+The dispatched worker runs only the fixed route. It must return failure to the
+host rather than automatically hopping to another provider or intermediary. If
+a retry would add an unexpected recipient or intermediary, resolve it at the
+host, explain the change, and ask before starting a new fixed-route job. An
+active user, project, or organization instruction that separately gates external
+consultation also requires approval. Otherwise the explicit peer, cross-check,
+or `oracle` invocation is the authority to proceed. A named peer that cannot run
+within these rules is reported, never silently replaced or dropped.
+
+The pre-dispatch update should say who will inspect the subject and that the
+review is read-only. Do not recite scope mechanics, promise that repository
+secrets are inaccessible, or describe probe results, CLI versions, model tiers,
+commit hashes, repository identity, route health, job lifecycle, or scratch
+paths. Mention a cooperative scope restriction only when it materially changes
+the user's choice. Refer to the codebase as "this project" or "the repository"
+unless the user supplied a recognizable name.
+
+## 4. Dispatch, wait, reap, and collect
+
+Prepare one complete canonical payload containing the framed question, subject
+shape, normalized read scope, repository-scope identity, mode, paths to subject
+material already in the workspace, and required conversational material that is
+not available there. Let peers inspect and ground against the shared working
+tree. Do not duplicate readable files or add a host-curated architecture summary
+merely to brief the peer.
+
+For an initial `independent` round, exclude ce-pov's position and every other
+voice's conclusion. The proposal, document, or approach set being judged is the
+subject and remains fully available; independence means withholding prior
+judgments about it, not withholding the artifact. The host's own argument —
+candidate-risk enumerations, decisive premises stated as fact, advocacy framing,
+and evaluative option labels — is reconcile-round material, not round-1 material;
+the independent round carries only the framed question, the subject, the read
+scope, and the evidence. Define round-1 evidence by provenance: source-located
+facts and the user's decision-relevant need are round-1 material, while host
+interpretations, risk rankings, and recommended consequences are not (for
+example, "the file at PATH contains X" is round-1 evidence, while "X is the risky
+option" waits for reconcile). Label inlined conversation-only material as such.
+When the user's goal bears on the decision, include the goal, how strongly they
+hold it, and any evidence they gave for it. State in the payload that rejecting every supplied option, or the
+framing itself, is a valid position. When ce-pov authored the subject in-session,
+present the options symmetrically in the payload's own words even though the full
+subject document remains attached. When the subject is itself an already-formed
+position (Section 1), the list of material to withhold above applies only to fresh
+host framing generated in response to the panel request: the position's own
+premises, labels, and advocacy ship intact as the subject artifact, and only host
+meta-judgment formed about it after the panel request waits for reconcile — peers still return their own
+independent verdict. For `skeptic` mode, include
+ce-pov's position because critiquing it is the task. Reconciliation payloads
+follow Section 5 and deliberately include already-formed positions.
+
+Verify that the same complete payload fits every selected route; never truncate
+it per provider. A route that cannot accept it is unavailable under the ordinary
+partial-panel degradation rule.
+
+Use `scripts/cross-model-pov.sh` from this skill's directory to run one resolved
+fixed route per peer, and `scripts/peer-job-runner.py` for detached lifecycle
+control. Pass the actual repository root separately from
+any narrower read root, and pre-create the round output directory as private
+scratch outside the repository. For named peers, start one job per exact target;
+for a selected panel, start one job per selected peer. Start all jobs before
+waiting.
+
+**At the defaults, the peer budget needs nothing from you.** This skill's worker
+stops itself at 600s and the runner supervisor derives a floor of 1230s, so the
+runner window is already longer than the worker's cap and kills nothing healthy.
+
+**Raising `CROSS_MODEL_HARD_SECS` widens the runner window automatically.** The
+runner derives its supervisor hard cap from the ambient knob
+(`max(1230, knob + 30)`). Do not set a numeric `CE_PEER_HARD_SECS` here — and
+clear any ambient one on the start prefix (`CE_PEER_HARD_SECS=`) so a stale
+export cannot undercut the derivation. Do not re-export a *resolved*
+`CROSS_MODEL_HARD_SECS` onto the worker's command line: that converts a
+fallback into an override and strips the worker of its own default.
+
+Each worker writes `<run-dir>/pov-<target>.json`, where `<target>` is the resolved
+route target with `grok-cli`/`grok-cursor` collapsing to `grok`. Pass exactly that
+path as `--result-path` to `peer-job-runner.py start`, so `done` is keyed to the
+artifact and `result <job-id>` reads it without guessing the filename or the
+host's provider key.
+
+**Runner prefix.** Every runner call below starts with these two lines, in the
+*same* tool call as the command, because each tool call is a fresh shell. Set
+`SKILL_DIR` to the absolute directory of **this** skill's `SKILL.md`; the shell's
+working directory is the user's project, not the skill directory. Do not
+hardcode `python3`: on native Windows it resolves to a Microsoft Store stub that
+exits without running Python and still satisfies `command -v`, so the prefix
+probes execution rather than presence.
+
+```bash
+SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
+PY="$(for c in python3 python py; do command -v "$c" >/dev/null 2>&1 && "$c" -c '' >/dev/null 2>&1 && { echo "$c"; break; }; done)"; [ -n "$PY" ] || { echo "no working Python 3 interpreter on PATH" >&2; exit 1; };
+```
+
+**Host command-sandbox boundary.** The detached worker inherits the permission
+context of the `start` call that launches it. Before executing that exact call,
+treat `CODEX_SANDBOX_NETWORK_DISABLED` as a positive signal that the current
+Codex command sandbox cannot reach the provider; unsetting it does not change
+the sandbox policy. A DNS or authentication failure alone is not proof of that
+condition. Use the narrowest host permission that restores the fixed route's
+provider connection. When Codex exposes only full command escalation, attach
+this request to the exact `peer-job-runner.py start ...` tool call after the
+existing disclosure of which external provider receives the subject:
+
+```json
+{
+  "sandbox_permissions": "require_escalated",
+  "justification": "Allow the disclosed read-only cross-model panel request to reach the fixed external provider."
+}
+```
+
+Disclose that this is not launcher-only isolation: the detached worker inherits
+that launch context for its lifetime, so the adapter's declared read-only/tool
+restrictions — not the Codex command sandbox — bound the peer while the subject
+is sent to the provider. If the grant is denied or unavailable, do not execute `start`; create
+no peer job, drop that voice, and continue with the surviving panel. After
+`start` returns a job id, any network, authentication, or provider failure is a
+started-job outcome and follows the ordinary terminal/recovery rules; keep
+`status`, `wait`, `result`, and `reap` sandboxed because they need no provider
+connection.
+
+Start one job per peer with the runner prefix and this command, filling every
+`<...>` slot. The command is complete: do not read either script's source or a
+peer CLI's help to build it.
+
+```bash
+CE_PEER_HARD_SECS= "$PY" "$SKILL_DIR/scripts/peer-job-runner.py" start --skill ce-pov --run-id "<run-id>" --label "<target>" --result-path "<run-dir>/pov-<target>.json" -- env CROSS_MODEL_HOST_HARNESS="<host-harness>" CROSS_MODEL_REPO_ROOT="<repo-root>" CROSS_MODEL_READ_ROOT="<read-root>" CROSS_MODEL_SCRATCH_PARENT="<scratch-dir>" bash "$SKILL_DIR/scripts/cross-model-pov.sh" "<host-serving-family>" "<fixed-route>" "<payload-path>" "<run-dir>"
+```
+
+- `<host-serving-family>` is `codex`, `claude`, `grok`, `composer`, `gemini`,
+  or `unknown`; `<host-harness>` is `codex`, `claude`, `grok`, `cursor`,
+  `opencode`, `antigravity`, `omp`, or `unknown`. Both are the Section 1 attestation,
+  not a provider name.
+- `<fixed-route>` is the sanctioned route token from Section 3's table;
+  `<target>` is its resolved target, with `grok-cli` and `grok-cursor`
+  collapsing to `grok`.
+- `<payload-path>` is this round's mode-600 payload and `<run-dir>` the
+  pre-created round output directory; `<scratch-dir>` is the Phase 1 scratch
+  root, and `<run-id>` its basename.
+- `<read-root>` is Section 2's normalized workspace root and `<repo-root>` the
+  actual repository root containing it.
+- Add `CROSS_MODEL_INCLUDE_PATHS` / `CROSS_MODEL_EXCLUDE_PATHS` only when
+  Section 2 resolved patterns, and `CROSS_MODEL_MODEL_OVERRIDE_TARGET` /
+  `CROSS_MODEL_MODEL_OVERRIDE` only for a Section 3 same-family substitution.
+
+Record every job id. Then wait for all of them with the runner prefix and this
+command, which polls for up to 30 seconds per call:
+
+```bash
+"$PY" "$SKILL_DIR/scripts/peer-job-runner.py" wait --max-secs 30 --deadline-secs "${CROSS_MODEL_HARD_SECS:-600}" --deadline-grace-secs 10 <job-ids...>
+```
+
+Each call prints one row per job (label, job id, state, seconds since start,
+and the reason for any job that ended without a result), then one line that
+says what to do next:
+
+- `all settled` — no job is still running. Collect results from the rows that
+  say `done`. Every other row is a peer that did not answer; its reason is only
+  the runner's view, so take the cause you report from that job's log, as
+  described below.
+- `waiting: ...` — run the same command again. Do not add a separate shell
+  sleep; `wait` itself provides the bounded polling delay.
+- `deadline passed: reap <job-ids>, then wait once more; ...` — reap every
+  listed job in one call with the runner prefix and the command below, then
+  run the wait command once more. If that final wait prints the same line,
+  stop waiting and treat the jobs still running as timed out.
+
+```bash
+"$PY" "$SKILL_DIR/scripts/peer-job-runner.py" reap <job-ids...>
+```
+
+Job ids or job-directory paths are positional. `--skill`, `--run-id`, and
+`--label` are start-only; never pass them to `wait` or `reap`. The deadline is
+the worker's own cap plus 10 seconds (610s by default). It is counted from the
+last job's start. The command passes the cap from `CROSS_MODEL_HARD_SECS` in
+the host's environment to the runner, which adds the 10 seconds itself and
+rejects a value that is not a plain number of seconds. The workers inherit the
+same environment, so a user who exported a larger value keeps their wider
+window. Never add `CROSS_MODEL_HARD_SECS` to the
+start command's `env` prefix: the worker would see a cap this wait does not.
+Never set a smaller `CROSS_MODEL_HARD_SECS` to finish sooner: some peers routinely need about four minutes, and a shorter cap drops
+them after they have spent their run. Let each wait call run its full slice:
+when your shell tool hands back control before the command exits (a Codex
+shell session still running, a background task), keep reading that command's
+output rather than starting another wait. Between waits, read the result of
+any job whose row says `done` instead of holding it until the rest finish.
+
+Classify every started job from its terminal state; `done` alone does not
+prove a usable artifact exists.
+
+Read artifacts and logs only through the runner's ownership-checked `result`
+interface. Accept only schema-shaped artifacts whose `position` is a settled
+answer to the framed question, with non-empty `reasoning`, a valid `movement`,
+and the route/model receipt tuple. Settledness is the peer's own declaration
+through the schema's required `final` flag, never a reading of its prose: a
+settled `Blocked — …` verdict marked `final: true` is a usable answer, while
+any shaped artifact whose `final` is not true is a placeholder. The worker
+retries a non-final artifact once on the same route with a final-answer
+requirement, inside the same hard window, and if it recurs or no window
+remains drops the voice with `peer skip evidence: non-final position`. Should
+a non-final artifact still reach you, treat it as no usable artifact, not as a
+peer voice. Initial responses require `movement: initial`; reconcile
+responses require `moved` or `held` plus what changed or why the new evidence
+was insufficient.
+
+Attribute a served model only from a receipt, never from the request. Record
+target, actual harness/intermediary route, requested model, served model, and
+`independence_verified` separately. A served model of `unverified` stays
+`unverified` in the record; it does not become "unknown model" in the note,
+because the requested model is known.
+
+Every route runs through acpx, which needs Node 22.13 or newer and `npx`. A
+worker line `transport unavailable (pre-egress, <scope>): <reason>` means the
+peer did not run and nothing reached the provider; report that voice as not run
+with the reason. Scope `shared` (Node, `npx`, or the npm fetch of acpx) fails
+every route the same way, so another route cannot replace it. Scope `route`
+(that route's CLI is missing, an acpx config file replaces its launch command,
+or the model was rejected, with the available models listed) affects only that
+route. A rejected model follows the refused-model rule below; any other
+replacement follows Section 3's recipient rules.
+
+When the requested model itself was refused (the adapter did not offer it, or
+the provider rejected it for this account, which `peer skip evidence (reply):`
+carries when the provider sent it as reply text), only the model failed and
+the route is still usable. If the worker ran its own default model rather than
+one the user named, start one new job for that voice on the same route, with
+no new recipient. Give it Section 3's closest same-family substitute, picked
+from `peer skip evidence (advertised models):` when that line is present. The
+note says which model was rejected. A model the user named is never swapped.
+
+If a job yields no usable artifact, use bounded `peer skip evidence`
+from its log to state an observed quota, authentication, or route failure; never
+invent a cause. Attribute an account authentication failure only after
+provider-capable dispatch is positively established by the launch context or
+provider response; then report the observed failure and login or
+credential-refresh remediation. Without that proof, authentication-shaped peer
+text describes only the peer's execution context: a sandboxed host can produce
+the same signal as a genuine logout, so never report it as the user's account
+being logged out or prompt a login command.
+
+## 5. Detect dissent, verify claims, and reconcile
+
+Only `mode: independent` voices enter convergence. Material dissent means a
+different adoption grade, a different selected approach, or document bottom
+lines that imply different reader actions (`proceed`, `revise-first`, or
+`reject`) or disagree on whether a risk is fatal. Wording, emphasis, confidence,
+or supporting detail with the same decision is concurrence.
+
+The default limit is the independent initial round plus at most two reconcile
+exchanges. A user-supplied pass or round limit overrides it: "one pass" or "one
+round" means no reconcile exchange, while a larger explicit limit replaces the
+default cap. Never reinterpret a smaller user limit as a suggestion.
+
+For each reconcile exchange:
+
+1. Revalidate repository-scope identity. Restart or return incomplete on change.
+2. Have ce-pov reconsider every current position and its evidence.
+3. Identify only disputed project claims that could change the decision. Verify
+   them against the allowed scope and classify each as `verified`,
+   `contradicted`, or `unverifiable`, with source locations when available.
+4. Build one common evidence delta. Send the identical complete delta to every
+   surviving peer—never route-specific truncation—along with the full original
+   subject and every surviving voice's current position and reasoning, capped at
+   five succinct source-attributed evidence bullets per voice.
+5. Re-resolve every fixed route under Section 3, then dispatch a fresh stateless
+   round. The same recipients need no question; an unexpected new recipient or
+   intermediary does. A failed peer is dropped for later rounds; do not reuse its
+   older position as if it participated.
+
+When the initial independent voices materially dissent, run at least one
+reconcile exchange before any stop, unless the user limited the run to one
+pass. Deciding over a dissenter who never saw the counter-evidence is not a
+reasoned convergence.
+
+After fold-in, stop on the first matching enum:
+
+- **`confident`** — ce-pov has a reasoned POV after weighing every survivor;
+- **`no-movement`** — every surviving peer returned `held` and ce-pov is still
+  not confident; or
+- **`limit-reached`** — the effective user-authorized finite limit completed
+  after initial dissent and ce-pov is still not confident.
+
+Convergence is ce-pov's reasoned confidence, not a vote. A three-way split still
+ends in a confident decision or the stalemate disclosure. Route `confident` to
+the **Confident** disclosure below. Route `no-movement` and `limit-reached` to
+the **Stalemate** disclosure; those stops mean bounded reconciliation ended
+without confident convergence, never that ce-pov should infer a settled result.
+
+The cap stops automatic dispatch; it is a checkpoint, not proof that another
+round would be useless. At the checkpoint, decide whether a bounded extension is
+likely to change the result. Recommend a specific number of additional exchanges
+only when ce-pov can name the unresolved decision-relevant question, the new
+evidence or framing the extension would introduce, and why it could move a
+position. Otherwise recommend stopping. Further rounds require user approval
+unless the user supplied the larger limit in advance; each approval establishes
+a new finite cap, never an open-ended loop.
+
+## 6. Decide and disclose
+
+Lead with ce-pov's POV in the active subject shape, followed by a compact panel
+note:
+
+- **Confident:** state whether voices aligned. Concurrence raises confidence but
+  does not eliminate correlated-model blind spots. If ce-pov decided over
+  dissent, name the disagreement and why its result prevailed. Claim peer
+  agreement only for what the peers judged; name any recommendation you added
+  after the panel as your own.
+- **Stalemate:** state ce-pov's current position, each surviving peer's position
+  and movement, every dropped voice's last state, and whether the disagreement
+  is an evidence gap or judgment difference. Recommend when there is a real
+  basis; otherwise say "Either is viable" with the material tradeoffs. At a cap,
+  add **Further rounds:** recommend a specific bounded extension with its new
+  evidence path, or recommend stopping because no additional exchange is likely
+  to change the result.
+- **Partial:** name surviving and dropped targets and the observed failure state
+  (for example quota, authentication, timeout, or a non-final placeholder
+  position that survived the bounded retry).
+- **No survivor:** deliver the solo POV with "cross-model check unavailable or
+  incomplete." When a summons was present but the panel branch never entered
+  (no reachable peers, or the branch was never entered), still state that panel status —
+  which peers were attempted, or that none ran and the observed reason — rather
+  than shipping a bare solo verdict.
+
+Retain target, route, requested model, served model, and independence receipts in
+the panel record, but keep the default chat note decision-relevant: name the
+peer by target and requested model, its position and movement, any observed
+failure, and a serving or independence caveat only where a receipt disagreed, no
+model was requested, or independence affects credibility. Do not dump route or model diagnostics unless they
+materially change the conclusion or the user asks. Never attribute a position to
+a model that did not run.
+
+The panel itself never mutates. After delivery, apply SKILL.md Phase 4's
+four-part conjunction: the original prompt explicitly authorized the named
+downstream action, the result is non-stalemated, the action stays in inherited
+scope, and it is non-destructive and otherwise authorized. All four must pass
+for handoff; otherwise return the judgment without starting downstream work. A calling workflow retains ownership of continuation.
+
+## 7. Skeptic mode and degradation
+
+When asked to challenge ce-pov rather than form an independent POV, set
+`mode: skeptic`. Fold a valid attributed critique into ce-pov once, but do not
+put that voice into convergence. Disclose whether it changed the POV. A failed
+skeptic degrades like any unavailable peer.
+
+A peer never blocks a POV. Mid-round failure drops only that voice; an
+oversized canonical payload drops routes that cannot accept the identical
+payload; no surviving peer yields the solo POV plus the availability note.
+
+Distinguish a route-level failure from a dispatch-infrastructure failure. A
+route that runs and returns no usable artifact is dropped as above. But if the
+dispatch scripts themselves fail unexpectedly — a crash, a non-zero exit before
+any job starts, an unresolved script path — do not drop that peer on the first
+error. Attempt the same resolved route by hand, holding the selected target and
+model, the normalized read scope, and the round's independence rules fixed.
+Keep attempting only while each failure is a new, plausibly recoverable one and
+the panel's aggregate deadline has not passed; stop and fall to the solo POV
+once a failure repeats or the deadline is spent. A hand recovery may not
+substitute a different target, widen read scope, or include a withheld
+position — those make the recovered peer's result untrustworthy, not merely
+unavailable.
+
+## 8. Cleanup
+
+Remove every consumed job directory, round output directory, payload, raw log,
+and result beneath this run's private scratch root on success, failure, timeout,
+interruption, and reap. Never delete outside the current run root. Peer reasoning
+and project context must not outlive their use.
+
+## Participation, announcement, and disclosure (relocated from the body)
+
+A summons (a panel request) is an **affirmative** request to consult or reconcile peers, detected by reasoning over the invocation context — the user's wording or a calling skill's args. Wording that declines consultation ("solo POV, do not cross-check") or merely recounts a past cross-check names the same terms without asking for one, and is not a summons: peers are not dispatched and no project context leaves the run. For an affirmative request, a caller's paraphrase in one channel never cancels a summons still present in another; only a summons erased from every readable channel upstream is unrecoverable here.
+Invoking a named peer, an explicit cross-check, or `oracle` authorizes the panel protocol's normal read-only consultation against this project. Announce the selected peers before dispatch; ask only when a retry adds an unexpected recipient or intermediary, or an active instruction requires separate approval. Peers inspect the shared working tree directly and are told not to edit it. The panel protocol preserves an unbiased initial round, bounds evidence-based reconciliation while honoring user-supplied pass limits, and attributes only receipt-supported independence.
+Any POV delivered after a summons states which peers ran, or that none did and the observed reason; if no panel runs after a summons, keep the verdict content unchanged but add that panel-status line rather than shipping a bare solo verdict. A POV with no summons keeps the solo result unchanged with no panel note.
+Keep the host's own frozen position out of an independent peer's initial context; expose it only when the requested task is to critique that position or when a later reconciliation round compares already-formed views.

package/skills/ce-pov/references/followup.md

@@ -0,0 +1,9 @@
+# Requested continuation
+
+The judgment itself completes `ce-pov`. When another workflow called it, return the result; that workflow decides the next action. Do not add a menu or capture offer.
+
+A standalone invocation may hand off to another workflow only when the original request authorized the downstream action. The result must resolve the decision needed for that action. The action must remain within the inherited scope and be non-destructive and otherwise authorized. A recommendation alone grants no implementation authority. When a consequential choice remains with the user, return that choice under the skill body's interaction rule; otherwise finish with the result.
+
+Choose any authorized continuation from the actual outcome, not a fixed menu. Adoption may need planning or a trial; a document take may inform revisions; an approach-set position may return to design or execution. Invoke the skill responsible for that next step through the host's skill-invocation capability with the decision, evidence, conditions, and inherited scope. Never assume every positive result requires a plan.
+
+For a requested full write-up, read `references/report.md`. For a requested durable decision capture, invoke `ce-compound` with `mode:non-interactive` and the structured decision fitting an existing capture type. Neither is a required follow-up to a POV.