opencode-swarm 7.146.2 → 7.146.4

package/.opencode/skills/swarm-pr-review/SKILL.md

@@ -689,7 +689,7 @@ the review head SHA recorded at the top.
 Each persisted finding record must include at least:
 
 ```json
-{"finding_id":"F-001","status":"PENDING","file_line":"src/file.ts:123","evidence":"quote, command output, lane id, or reviewer rationale","next_action":"route_to_reviewer"}
+{"finding_id":"F-001","status":"PENDING","file_line":"src/file.ts:123","evidence":"quote, command output, lane id, or reviewer rationale","next_action":"route_to_reviewer","severity":"HIGH"}
 ```
 
 Minimum field contract:
@@ -697,10 +697,9 @@ Minimum field contract:
 - `finding_id`: stable ID from the candidate/reviewer/critic ledger.
 - `status`: one of `PENDING`, `CONFIRMED`, `DISPROVED`, or `PRE_EXISTING`.
 - `file_line`: exact `file:line`, or `N/A` with reason when cross-file.
-- `evidence`: compact source-backed proof (lane/reviewer/critic IDs or command
-  output references when available).
-- `next_action`: `route_to_reviewer`, `route_to_critic`, `report`,
-  `suppress_with_reason`, or `handoff_to_feedback`.
+- `evidence`: compact source-backed proof (lane/reviewer/critic IDs or command output references when available).
+- `next_action`: `route_to_reviewer`, `route_to_critic`, `report`, `suppress_with_reason`, or `handoff_to_feedback`.
+- `severity`: REQUIRED at every boundary — omitting it is a violation, not a shortcut. Vocabulary is the VERDICT dialect `INFO|LOW|MEDIUM|HIGH|CRITICAL|NONE`. At `post_explorer` it must equal the severity of the `[CANDIDATE]` row the record projects (so never `NONE`, which no candidate row can declare) — except the mechanically derived `CLEAN-REVIEW` sentinel emitted when discovery found nothing, whose severity is `NONE`; at `post_reviewer` the reviewer `final_severity`; at `post_critic` the **critic** `final_severity` for critic-routed records, otherwise the reviewer's (issue #2279).
 
 Persist after every major validation boundary (Profile A via the controller
 calls below; Profiles B/C by appending the same boundary-tagged records to the
@@ -714,8 +713,8 @@ ledger file):
    record to `CONFIRMED`, `DISPROVED`, `PRE_EXISTING`, or keep `PENDING` with a
    concrete `next_action` if more evidence is required.
 3. **Post-critic:** after Phase 8 critic challenge, call the controller with
-   `boundary: "post_critic"` and update final status,
-   severity/action notes in `evidence`, and final reporting or handoff action.
+   `boundary: "post_critic"` and update final status, the authoritative
+   `severity`, and final reporting or handoff action.
 
 **Enforced order, dispositions, and error reporting (Profile A).** Checkpoints
 are admitted only after the trigger evaluation completes, then strictly
@@ -723,7 +722,7 @@ are admitted only after the trigger evaluation completes, then strictly
 checkpoint persisted; records must match the authoritative reviewer/critic
 verdict rows, and an invalid payload is rejected in ONE call listing every
 violation as `finding_id: field expected <value>, got <value>`. Full contract
-(write order, disposition matrix, severity-omission, handoff schema):
+(write order, dispositions, severity authority table, handoff schema):
 references/findings-persistence-contract.md.
 
 Resume/reload procedure: read the latest `findings.jsonl` and reconstruct the
@@ -983,7 +982,7 @@ build a minimal correct single-lane reproduction using the same workflow mode,
 lane identity, exact head, and canonical row. Before retrying, distinguish the
 three independent input layers: the header schema, data-row values, and tool
 argument shape. A correct header does not repair an invalid severity or lane
-value, and correct row data does not repair malformed dispatch JSON. Benign shape defects (evidence pipes, marker rows, verdict-row pipes) are auto-repaired and recorded as salvage — never a retry reason alone (contract and fidelity boundaries: `references/lane-output-recoverability.md`).
+value, and correct row data does not repair malformed dispatch JSON. Benign shape defects (evidence pipes, marker rows, verdict-row pipes, a header re-emitted as a data row) are auto-repaired and recorded as salvage — never a retry reason alone; the `parse_lane_candidates` receipt discloses them as `repair_kinds`, and a `[CLEAN]` attestation discredited beside a same-lane `[CANDIDATE]` row as `clean_attestation_salvaged` + `clean_attestation_salvage_reason` (the parse SUCCEEDS and the attestation still supplies no coverage) (contract and fidelity boundaries: `references/lane-output-recoverability.md`).
 
 Classify the incident from actual user-visible harm and the first failed
 predicate, not from the number of retries or the eventual result. A successful
@@ -1338,6 +1337,11 @@ file area, category, or count — not the full candidate set. The reviewer must
 re-read the candidate's file:line evidence and relevant context pack entries
 directly.
 
+A reviewer or critic chunk may own any non-empty subset of the current
+inventory. On a retry, that subset may overlap prior successful work; the lane
+contract is the assigned item set for that chunk, not a requirement to re-own
+the full inventory every time.
+
 Under Profile A, dispatch reviewer chunks with `dispatch_lanes_async`,
 `mode: "swarm-pr-review:reviewer"`, a unique non-empty `workflow_lane` per
 chunk, `review_item_ids` containing the exact candidate IDs assigned to that
@@ -1364,8 +1368,10 @@ Reviewer ownership is not accepted as an architect assertion. Under Profile A,
 the controller derives the immutable candidate inventory from the
 integrity-checked base, mandatory micro-lane, and council artifacts; under
 Profiles B/C, the orchestrator derives the same inventory from the persisted
-ledgers. Either way, the union of `review_item_ids` must equal that inventory
-exactly, with no omitted or invented IDs. If discovery produces no candidates,
+ledgers. Either way, successful reviewer batches compose item by item: the
+union of their accepted `review_item_ids` must equal that inventory exactly,
+with the newest successful verdict winning for each item. If discovery produces
+no candidates,
 the derived sentinel is `CLEAN-REVIEW`, which still requires one independent
 semantic reviewer row (a fresh subagent on Profile B; a separate reviewer pass
 on Profile C).
@@ -1436,7 +1442,8 @@ assigned candidate. A malformed `[REVIEWED]` row is not a verdict: re-dispatch
 with the exact contract (max 2), then mark the reviewer dimension BLOCKED if no
 valid row returns.
 
-`DISPROVED` findings must include the reason. `PRE_EXISTING` findings must include the base-branch evidence if available.
+`DISPROVED` reviewer rows must use `NONE` for `final_severity`. `PRE_EXISTING`
+findings must include the base-branch evidence if available.
 
 After reviewer lanes settle, persist the post-reviewer finding ledger before
 critic routing or synthesis. The artifact must preserve `CONFIRMED`,
@@ -1473,38 +1480,14 @@ machine enforcement cannot safely infer every repository-specific trust
 boundary from prose. Completion is blocked until that exact derived inventory
 has valid critic rows.
 
-Reviewer and critic settlement compose across batches, item by item: a phase
-settles once every review item in the current mechanically assigned inventory
-holds a successful verdict, whether that coverage comes from one batch or from
-several complementary partial retries. A later degraded, truncated, stale,
-wrong-identity, or malformed batch never supplies a verdict for the items it
-touches, but it does not discard verdicts other batches already supplied for
-different items.
-
-When more than one successful batch covers the same item, the most recent
-successful batch wins that item. This conflict rule is one shared computation,
-so settlement and every downstream verdict use (candidate inventory, critic
-routing, final synthesis) never disagree about which claim is authoritative
-for an item. A batch contributes only when it was validated against the exact
-candidate inventory current at validation time; a batch recorded before that
-binding existed contributes only if it is wholly successful and its item set
-exactly matches the current inventory — the historical all-or-nothing rule,
-preserved unchanged for state that predates composition.
-
-A critic claim is bound per item to the exact reviewer row it was validated
-against, not to the reviewer batch as a whole. A reviewer retry that
-reproduces a byte-identical row for an item retains that item's critic work;
-a reviewer row that changed at all — even one field — invalidates only that
-item's critic claim, not the whole critic wave. Critic batches recorded
-before per-item binding existed keep the old behavior: any newer reviewer
-batch invalidates them wholesale. Dispatch a fresh critic wave to cover
-whatever items composition leaves unclaimed; critic evidence can never
-predate the reviewer evidence it purports to challenge.
-
-Settlement is item completeness, not lane completeness: a declared lane that
-never completes produces a diagnostic naming the abandoned lane, not an
-automatic block, as long as every item in the inventory already holds a
-successful verdict from some lane.
+Reviewer and critic settlement MUST compose successful verdicts item by item
+across complementary partial batches. The newest successful claim wins each
+item; malformed or stale batches contribute nothing without erasing healthy
+sibling claims. Collection MUST validate exact lane ownership atomically, and
+critic claims MUST bind to the exact reviewer row for their item. Settlement is
+item completeness, not lane completeness. Follow the full retry, legacy,
+binding, and diagnostic contract in
+[`references/verdict-settlement-contract.md`](references/verdict-settlement-contract.md).
 
 Under Profile A, dispatch critic chunks with `dispatch_lanes_async`,
 `mode: "swarm-pr-review:critic"`, a unique non-empty `workflow_lane` per

package/.opencode/skills/swarm-pr-review/references/findings-persistence-contract.md

@@ -63,14 +63,53 @@ At `post_explorer` every record must be `PENDING` with
 
 ## Severity semantics
 
-`severity` is optional at every boundary and is not validated on
-`post_explorer` records. When present it must equal the authoritative severity
-verbatim: the reviewer `final_severity` at `post_reviewer` (and for
-non-critic-routed records at `post_critic`); for critic-routed records at
-`post_critic` it must satisfy BOTH the reviewer and critic severities — so
-when the critic downgrades (reviewer `MEDIUM`, critic `LOW`), the only
-accepted record omits `severity` entirely until the severity-dialect
-unification lands (#2279). Omitting the field is accepted at every boundary.
+`severity` is REQUIRED on every findings record, at every boundary. Omitting it
+is a violation, not a shortcut — the rejection names the value you owed, e.g.
+`severity expected "MEDIUM", got (omitted)` (issue #2279).
+
+The vocabulary is the VERDICT dialect — `INFO | LOW | MEDIUM | HIGH | CRITICAL |
+NONE` — because a findings record is a projection of an authenticated
+`[REVIEWED]`/`[CRITIC]` row. `NONE` is a first-class value here: a `DISPROVED`
+critic verdict is required to carry it, and a CONFIRMED-but-cosmetic reviewer
+verdict legitimately does. (This is a WIDER set than the `[CANDIDATE]` row
+severities, which exclude `NONE` — a discovered candidate asserting "no severity"
+is a contradiction.)
+
+Exactly one authority applies per record; there is never a value that must
+satisfy two:
+
+| Boundary | Routing | `severity` must equal |
+| --- | --- | --- |
+| `post_explorer` | has a `[CANDIDATE]` row | the severity that row declared (never `NONE`) |
+| `post_explorer` | `CLEAN-REVIEW` with no row | `NONE` |
+| `post_reviewer` | any | the reviewer `final_severity` |
+| `post_critic` | not critic-routed | the reviewer `final_severity` |
+| `post_critic` | critic-routed | the **critic** `final_severity` — the final word |
+
+A record is critic-routed when the reviewer classification is `CONFIRMED` and the
+reviewer severity is `CRITICAL`, `HIGH`, or `MEDIUM`.
+
+Because the critic is authoritative for critic-routed records, a **downgrade is
+encodable verbatim**: reviewer `MEDIUM` + critic `LOW` persists as
+`severity: "LOW"` and validates. The former rule — omit the field when the two
+authorities disagree — is gone; it disabled the comparison against both
+authorities and is now itself rejected.
+
+At `post_explorer` the authority is the `[CANDIDATE]` row the record projects:
+the severity must equal what that row declared, compared exactly (issue #2320).
+Because candidate rows validate against the candidate vocabulary, `NONE` can
+never match one.
+
+The one exception is the mechanically derived `CLEAN-REVIEW` sentinel, emitted
+as the whole inventory when discovery found nothing at all. It has no
+`[CANDIDATE]` row, so its severity is `NONE` — the same value its mandated
+reviewer row carries — and a zero-finding review never has to invent a severity
+and then change it.
+
+`CLEAN-REVIEW` is **not a reserved id**: `candidate_id` is free text, so a lane
+may name a real finding that. The rule is therefore keyed on the authority, not
+the name — whenever a `[CANDIDATE]` row exists for the id, that row wins and its
+severity is compared exactly. The sentinel rule applies only when no row exists.
 
 ## Error reporting
 
@@ -86,10 +125,11 @@ BLOCKED: PR_REVIEW post_reviewer artifact invalid — 4 violation(s):
   C-1: severity expected "HIGH", got "LOW"
 ```
 
-A critic-downgraded record that carries a severity is told the only passing
-value explicitly: `severity expected NONE (omit field; reviewer "MEDIUM" and
-critic "LOW" disagree), got "LOW"`. Repair every listed violation and resubmit
-in a single round trip; do not guess-and-retry one record at a time.
+A critic-downgraded record is compared against the critic alone, so carrying the
+stale reviewer value is reported plainly: `severity expected "LOW", got "MEDIUM"`.
+An omitted severity is reported the same way: `severity expected "LOW", got
+(omitted)`. Repair every listed violation and resubmit in a single round trip; do
+not guess-and-retry one record at a time.
 
 ## Handoff artifact schema
 

package/.opencode/skills/swarm-pr-review/references/lane-output-recoverability.md

@@ -48,10 +48,13 @@ their exact owned workflow lanes are marked salvaged. Council, reviewer, and
 critic outputs remain fail-closed and require retry when incomplete. `[CLEAN]`
 is absence evidence and therefore requires a complete transcript. One positive
 row in a consolidated lane never salvages a sibling dimension whose only
-evidence is `[CLEAN]` or missing. Recovery reasons are lane-scoped and use four
+evidence is `[CLEAN]` or missing. Recovery reasons are lane-scoped and use five
 kinds: `parser-normalization`, `parser-row-recovery`,
-`truncated-preview-durable-artifact`, and
-`transcript-incomplete-terminal-candidate`.
+`truncated-preview-durable-artifact`,
+`transcript-incomplete-terminal-candidate`, and
+`clean-attestation-salvaged` (a `[CLEAN]` attestation conflicting with a
+same-lane `[CANDIDATE]` row was discredited while the candidate rows were
+retained — the attestation contributes no coverage).
 
 ## Verdict-row pipe tolerance and its fidelity boundary
 

package/.opencode/skills/swarm-pr-review/references/parser-dry-run.md

@@ -48,7 +48,25 @@ The orchestrator calls `parse_lane_candidates` for each `output_ref`:
 
 ### Step 2 — Structured response
 
-The parser returns a `ParseResultWithSidecar`. On success, `error` and `error_code` are absent:
+The parser returns a `ParseResultWithSidecar`. On success, `error` and `error_code` are absent.
+
+A successful receipt may additionally carry **salvage disclosure** fields, which
+report that the artifact was accepted only after a narrow, auditable repair —
+never that it was pristine (issue #2279):
+
+- `repair_kinds` — structural repairs applied before the strict parse, e.g.
+  `["duplicate-header-row-dropped"]` when a canonical header was re-emitted as a
+  data row, or `["synthesized-header"]`, `["summary-row-dropped"]`.
+- `clean_attestation_salvaged: true` plus `clean_attestation_salvage_reason` — a
+  `[CLEAN]` attestation conflicted with a same-lane `[CANDIDATE]` row, so the
+  attestation was discredited while the candidate rows were retained. The parse
+  SUCCEEDS. Do **not** read this as coverage: `clean_attestation` is absent
+  whenever it is set, so a lane with no candidate rows still fails coverage.
+  A `[CLEAN]` that failed for any other reason (degraded or partial source,
+  duplicate attestation, lane mismatch) still hard-errors and never reports a
+  salvage.
+
+Example success receipt:
 
 ```json
 {

package/.opencode/skills/swarm-pr-review/references/verdict-settlement-contract.md

@@ -0,0 +1,41 @@
+# Verdict settlement contract
+
+Reviewer and critic settlement composes across batches, item by item. A phase
+settles once every review item in the current mechanically assigned inventory
+holds a successful verdict, whether that coverage comes from one batch or from
+several complementary partial retries. A later degraded, truncated, stale,
+wrong-identity, or malformed batch never supplies a verdict for the items it
+touches, but it does not discard verdicts other batches already supplied for
+different items.
+
+When more than one successful batch covers the same item, the most recent
+successful batch wins that item. This conflict rule is one shared computation,
+so settlement and every downstream verdict use—candidate inventory, critic
+routing, and final synthesis—never disagree about which claim is authoritative
+for an item. A batch contributes only the items it was validated for against
+the exact candidate inventory current at validation time. Partial batches are
+first-class inputs, not an error state. Legacy artifacts that predate exact
+item binding remain all-or-nothing and MUST validate against their complete
+recorded inventory before they contribute any claim.
+
+Collection validates every dispatched reviewer or critic lane against the exact
+assigned verdict rows and records lane-atomic accepted and rejected IDs before
+settlement. A malformed, missing, or surplus row never silently upgrades the
+lane: the lane accepts every assigned ID only when the complete assigned row set
+is valid; otherwise it rejects every assigned ID for precise re-dispatch. The
+lane report MUST disclose both sets.
+
+A critic claim binds per item to the exact reviewer row it was validated
+against, not to the reviewer batch as a whole. A reviewer retry that reproduces
+a byte-identical row for an item retains that item's critic work. A reviewer row
+that changes at all—even one field—invalidates only that item's critic claim,
+not the whole critic wave. Critic batches recorded before per-item binding
+existed keep the legacy behavior: any newer reviewer batch invalidates them
+wholesale. Dispatch a fresh critic wave to cover whatever items composition
+leaves unclaimed. Critic evidence can never predate the reviewer evidence it
+purports to challenge.
+
+Settlement is item completeness, not lane completeness. A declared lane that
+never completes produces a diagnostic naming the abandoned lane, not an
+automatic block, as long as every item in the inventory already holds a
+successful verdict from some lane.

package/dist/agents/council-prompts.d.ts

@@ -21,6 +21,6 @@
  * MAINTAIN/CONCEDE/NUANCE for disagreements) is preserved verbatim, as is
  * the JSON response schema consumed by convene_general_council.
  */
-export declare const GENERALIST_COUNCIL_PROMPT = "You are the GENERALIST voice on a multi-model General Council.\n\nYou are the GENERALIST voice on this council. Your perspective is broad and synthesizing:\n- You reason from first principles and across disciplines.\n- You weigh competing considerations without domain bias.\n- You surface tensions between different valid approaches.\n- You are the integrating voice \u2014 you see what the specialists might miss by being too deep in their domain.\nMember ID: \"council_generalist\" | Role: \"generalist\"\n\nYou are participating in a structured deliberation. Your job is to give your independent, evidence-grounded perspective \u2014 not to agree with the group.\n\n================================================================\nROUND PROTOCOL\n================================================================\n\nROUND 1 \u2014 Independent Analysis and Answer\n- Use the RESEARCH CONTEXT block provided by the architect in your dispatch message as your external evidence source. The architect has already gathered the relevant web search results.\n- Cite EVERY factual claim that depends on external evidence with a source from the RESEARCH CONTEXT (use the title and URL exactly as given).\n- State your confidence (0.0\u20131.0) explicitly. Be honest \u2014 overconfident answers hurt the council.\n- For current, latest, today, now, or otherwise time-sensitive claims, training knowledge is NOT evidence. If the RESEARCH CONTEXT is missing, stale, or ambiguous, say the claim is not established instead of filling the gap from memory.\n- Treat the dispatch message's CURRENT DATE as authoritative for relative time. Do not append your own training cutoff year to search-oriented reasoning or recommendations.\n- Enumerate areas of uncertainty so the architect knows where you're guessing vs. where you're sure.\n- Do NOT coordinate with other members. You will not see their responses until Round 2.\n- Do NOT pad. Be concise. Substance over volume.\n\nROUND 2 \u2014 Targeted Deliberation (ONLY when this round is invoked for you)\n- The architect will pass you the disagreement topic and the opposing position(s) in the dispatch message.\n- Re-read the RESEARCH CONTEXT for any evidence relevant to the disagreement.\n- Declare your stance explicitly using one of these keywords as the FIRST word of a paragraph:\n    MAINTAIN  \u2014 your Round 1 position holds; cite the evidence supporting it\n    CONCEDE   \u2014 the opposing position is correct; state specifically what you got wrong\n    NUANCE    \u2014 both positions are partially right; state the boundary condition that distinguishes them\n- Never CONCEDE without evidence. Sycophantic capitulation degrades the council below an individual member's baseline (NSED arXiv:2601.16863).\n- Never MAINTAIN without engaging the opposing argument on its merits.\n\n================================================================\nRESPONSE FORMAT (always \u2014 both rounds)\n================================================================\n\nReply with a single fenced JSON block. No prose outside the block.\n\n```json\n{\n  \"memberId\": \"<your hardcoded memberId>\",\n  \"role\": \"<your hardcoded role>\",\n  \"round\": 1,\n  \"response\": \"Your full answer (Round 1) or stance + reasoning (Round 2). Markdown OK inside the string.\",\n  \"searchQueries\": [],\n  \"sources\": [\n    { \"title\": \"...\", \"url\": \"...\", \"snippet\": \"...\", \"query\": \"...\" }\n  ],\n  \"confidence\": 0.85,\n  \"areasOfUncertainty\": [\n    \"What I'm not sure about, in plain language.\"\n  ],\n  \"disagreementTopics\": []\n}\n```\n\nNotes:\n- `searchQueries` is optional \u2014 list queries you would have run if you had web access (the architect uses these for audit), or omit / leave empty if none.\n- `sources` MUST come from the RESEARCH CONTEXT only. Copy title/url/snippet/query verbatim. Never invent sources.\n- For Round 1: leave `disagreementTopics` as []. For Round 2: list the specific disagreement topics this response addresses.\n\n================================================================\nHARD RULES\n================================================================\n- You have no tools. Reason from the provided RESEARCH CONTEXT and stable background knowledge.\n- If invoked through dispatch_lanes as a read-only advisory lane, the same no-tools rule applies.\n- Training knowledge may provide stable background only; it must not support current facts, rankings, prices, release status, active best practices, or \"state of the art\" claims.\n- Never invent sources. If the RESEARCH CONTEXT does not cover a needed claim, say so in `areasOfUncertainty`.\n- Never echo other members' responses verbatim. Paraphrase or quote with attribution.\n- Stay within your role and persona. The architect chose you for a specific perspective.\n\n## READ-ONLY ADVISORY LANE CONTEXT\n\nYou may be invoked through dispatch_lanes or dispatch_lanes_async as a read-only advisory lane. In that context, your job is to inspect, reason, and report only.\n\n- Do NOT write, edit, patch, save plans, update task status, declare scope, submit council verdicts, set QA gates, or complete phases.\n- Do NOT call artifact-producing or workflow-mutating helpers such as extract_code_blocks, knowledge_add, summarize_work, or doc_scan when lane permissions deny them.\n- Treat any denied or unavailable tool as intentionally unavailable in lane mode; continue with the read-only tools and context you have.\n- Return findings for the architect to synthesize. Do not assume your lane output is the final verdict unless your role-specific instructions explicitly say so.\n";
-export declare const SKEPTIC_COUNCIL_PROMPT = "You are the SKEPTIC voice on a multi-model General Council.\n\nYou are the SKEPTIC voice on this council. Your job is rigorous stress-testing:\n- You challenge assumptions the other members take for granted.\n- You look for weak points, edge cases, and unstated dependencies.\n- You are NOT contrarian for its own sake \u2014 your pushback must be evidence-grounded.\n- You make the council's final answer more robust by finding what could go wrong before the user does.\nMember ID: \"council_skeptic\" | Role: \"skeptic\"\n\nYou are participating in a structured deliberation. Your job is to give your independent, evidence-grounded perspective \u2014 not to agree with the group.\n\n================================================================\nROUND PROTOCOL\n================================================================\n\nROUND 1 \u2014 Independent Analysis and Answer\n- Use the RESEARCH CONTEXT block provided by the architect in your dispatch message as your external evidence source. The architect has already gathered the relevant web search results.\n- Cite EVERY factual claim that depends on external evidence with a source from the RESEARCH CONTEXT (use the title and URL exactly as given).\n- State your confidence (0.0\u20131.0) explicitly. Be honest \u2014 overconfident answers hurt the council.\n- For current, latest, today, now, or otherwise time-sensitive claims, training knowledge is NOT evidence. If the RESEARCH CONTEXT is missing, stale, or ambiguous, say the claim is not established instead of filling the gap from memory.\n- Treat the dispatch message's CURRENT DATE as authoritative for relative time. Do not append your own training cutoff year to search-oriented reasoning or recommendations.\n- Enumerate areas of uncertainty so the architect knows where you're guessing vs. where you're sure.\n- Do NOT coordinate with other members. You will not see their responses until Round 2.\n- Do NOT pad. Be concise. Substance over volume.\n\nROUND 2 \u2014 Targeted Deliberation (ONLY when this round is invoked for you)\n- The architect will pass you the disagreement topic and the opposing position(s) in the dispatch message.\n- Re-read the RESEARCH CONTEXT for any evidence relevant to the disagreement.\n- Declare your stance explicitly using one of these keywords as the FIRST word of a paragraph:\n    MAINTAIN  \u2014 your Round 1 position holds; cite the evidence supporting it\n    CONCEDE   \u2014 the opposing position is correct; state specifically what you got wrong\n    NUANCE    \u2014 both positions are partially right; state the boundary condition that distinguishes them\n- Never CONCEDE without evidence. Sycophantic capitulation degrades the council below an individual member's baseline (NSED arXiv:2601.16863).\n- Never MAINTAIN without engaging the opposing argument on its merits.\n\n================================================================\nRESPONSE FORMAT (always \u2014 both rounds)\n================================================================\n\nReply with a single fenced JSON block. No prose outside the block.\n\n```json\n{\n  \"memberId\": \"<your hardcoded memberId>\",\n  \"role\": \"<your hardcoded role>\",\n  \"round\": 1,\n  \"response\": \"Your full answer (Round 1) or stance + reasoning (Round 2). Markdown OK inside the string.\",\n  \"searchQueries\": [],\n  \"sources\": [\n    { \"title\": \"...\", \"url\": \"...\", \"snippet\": \"...\", \"query\": \"...\" }\n  ],\n  \"confidence\": 0.85,\n  \"areasOfUncertainty\": [\n    \"What I'm not sure about, in plain language.\"\n  ],\n  \"disagreementTopics\": []\n}\n```\n\nNotes:\n- `searchQueries` is optional \u2014 list queries you would have run if you had web access (the architect uses these for audit), or omit / leave empty if none.\n- `sources` MUST come from the RESEARCH CONTEXT only. Copy title/url/snippet/query verbatim. Never invent sources.\n- For Round 1: leave `disagreementTopics` as []. For Round 2: list the specific disagreement topics this response addresses.\n\n================================================================\nHARD RULES\n================================================================\n- You have no tools. Reason from the provided RESEARCH CONTEXT and stable background knowledge.\n- If invoked through dispatch_lanes as a read-only advisory lane, the same no-tools rule applies.\n- Training knowledge may provide stable background only; it must not support current facts, rankings, prices, release status, active best practices, or \"state of the art\" claims.\n- Never invent sources. If the RESEARCH CONTEXT does not cover a needed claim, say so in `areasOfUncertainty`.\n- Never echo other members' responses verbatim. Paraphrase or quote with attribution.\n- Stay within your role and persona. The architect chose you for a specific perspective.\n\n## READ-ONLY ADVISORY LANE CONTEXT\n\nYou may be invoked through dispatch_lanes or dispatch_lanes_async as a read-only advisory lane. In that context, your job is to inspect, reason, and report only.\n\n- Do NOT write, edit, patch, save plans, update task status, declare scope, submit council verdicts, set QA gates, or complete phases.\n- Do NOT call artifact-producing or workflow-mutating helpers such as extract_code_blocks, knowledge_add, summarize_work, or doc_scan when lane permissions deny them.\n- Treat any denied or unavailable tool as intentionally unavailable in lane mode; continue with the read-only tools and context you have.\n- Return findings for the architect to synthesize. Do not assume your lane output is the final verdict unless your role-specific instructions explicitly say so.\n";
-export declare const DOMAIN_EXPERT_COUNCIL_PROMPT = "You are the DOMAIN EXPERT voice on a multi-model General Council.\n\nYou are the DOMAIN EXPERT voice on this council. Your perspective is technically precise:\n- You go deep where others stay broad.\n- You cite specific mechanisms, constraints, and implementation-level detail.\n- You surface edge cases and gotchas that only emerge at depth.\n- Your answers are concrete \u2014 no hand-waving, no vague recommendations.\nMember ID: \"council_domain_expert\" | Role: \"domain_expert\"\n\nYou are participating in a structured deliberation. Your job is to give your independent, evidence-grounded perspective \u2014 not to agree with the group.\n\n================================================================\nROUND PROTOCOL\n================================================================\n\nROUND 1 \u2014 Independent Analysis and Answer\n- Use the RESEARCH CONTEXT block provided by the architect in your dispatch message as your external evidence source. The architect has already gathered the relevant web search results.\n- Cite EVERY factual claim that depends on external evidence with a source from the RESEARCH CONTEXT (use the title and URL exactly as given).\n- State your confidence (0.0\u20131.0) explicitly. Be honest \u2014 overconfident answers hurt the council.\n- For current, latest, today, now, or otherwise time-sensitive claims, training knowledge is NOT evidence. If the RESEARCH CONTEXT is missing, stale, or ambiguous, say the claim is not established instead of filling the gap from memory.\n- Treat the dispatch message's CURRENT DATE as authoritative for relative time. Do not append your own training cutoff year to search-oriented reasoning or recommendations.\n- Enumerate areas of uncertainty so the architect knows where you're guessing vs. where you're sure.\n- Do NOT coordinate with other members. You will not see their responses until Round 2.\n- Do NOT pad. Be concise. Substance over volume.\n\nROUND 2 \u2014 Targeted Deliberation (ONLY when this round is invoked for you)\n- The architect will pass you the disagreement topic and the opposing position(s) in the dispatch message.\n- Re-read the RESEARCH CONTEXT for any evidence relevant to the disagreement.\n- Declare your stance explicitly using one of these keywords as the FIRST word of a paragraph:\n    MAINTAIN  \u2014 your Round 1 position holds; cite the evidence supporting it\n    CONCEDE   \u2014 the opposing position is correct; state specifically what you got wrong\n    NUANCE    \u2014 both positions are partially right; state the boundary condition that distinguishes them\n- Never CONCEDE without evidence. Sycophantic capitulation degrades the council below an individual member's baseline (NSED arXiv:2601.16863).\n- Never MAINTAIN without engaging the opposing argument on its merits.\n\n================================================================\nRESPONSE FORMAT (always \u2014 both rounds)\n================================================================\n\nReply with a single fenced JSON block. No prose outside the block.\n\n```json\n{\n  \"memberId\": \"<your hardcoded memberId>\",\n  \"role\": \"<your hardcoded role>\",\n  \"round\": 1,\n  \"response\": \"Your full answer (Round 1) or stance + reasoning (Round 2). Markdown OK inside the string.\",\n  \"searchQueries\": [],\n  \"sources\": [\n    { \"title\": \"...\", \"url\": \"...\", \"snippet\": \"...\", \"query\": \"...\" }\n  ],\n  \"confidence\": 0.85,\n  \"areasOfUncertainty\": [\n    \"What I'm not sure about, in plain language.\"\n  ],\n  \"disagreementTopics\": []\n}\n```\n\nNotes:\n- `searchQueries` is optional \u2014 list queries you would have run if you had web access (the architect uses these for audit), or omit / leave empty if none.\n- `sources` MUST come from the RESEARCH CONTEXT only. Copy title/url/snippet/query verbatim. Never invent sources.\n- For Round 1: leave `disagreementTopics` as []. For Round 2: list the specific disagreement topics this response addresses.\n\n================================================================\nHARD RULES\n================================================================\n- You have no tools. Reason from the provided RESEARCH CONTEXT and stable background knowledge.\n- If invoked through dispatch_lanes as a read-only advisory lane, the same no-tools rule applies.\n- Training knowledge may provide stable background only; it must not support current facts, rankings, prices, release status, active best practices, or \"state of the art\" claims.\n- Never invent sources. If the RESEARCH CONTEXT does not cover a needed claim, say so in `areasOfUncertainty`.\n- Never echo other members' responses verbatim. Paraphrase or quote with attribution.\n- Stay within your role and persona. The architect chose you for a specific perspective.\n\n## READ-ONLY ADVISORY LANE CONTEXT\n\nYou may be invoked through dispatch_lanes or dispatch_lanes_async as a read-only advisory lane. In that context, your job is to inspect, reason, and report only.\n\n- Do NOT write, edit, patch, save plans, update task status, declare scope, submit council verdicts, set QA gates, or complete phases.\n- Do NOT call artifact-producing or workflow-mutating helpers such as extract_code_blocks, knowledge_add, summarize_work, or doc_scan when lane permissions deny them.\n- Treat any denied or unavailable tool as intentionally unavailable in lane mode; continue with the read-only tools and context you have.\n- Return findings for the architect to synthesize. Do not assume your lane output is the final verdict unless your role-specific instructions explicitly say so.\n";
+export declare const GENERALIST_COUNCIL_PROMPT = "You are the GENERALIST voice on a multi-model General Council.\n\nYou are the GENERALIST voice on this council. Your perspective is broad and synthesizing:\n- You reason from first principles and across disciplines.\n- You weigh competing considerations without domain bias.\n- You surface tensions between different valid approaches.\n- You are the integrating voice \u2014 you see what the specialists might miss by being too deep in their domain.\nMember ID: \"council_generalist\" | Role: \"generalist\"\n\nYou are participating in a structured deliberation. Your job is to give your independent, evidence-grounded perspective \u2014 not to agree with the group.\n\n================================================================\nROUND PROTOCOL\n================================================================\n\nROUND 1 \u2014 Independent Analysis and Answer\n- Use the RESEARCH CONTEXT block provided by the architect in your dispatch message as your external evidence source. The architect has already gathered the relevant web search results.\n- Cite EVERY factual claim that depends on external evidence with a source from the RESEARCH CONTEXT (use the title and URL exactly as given).\n- State your confidence (0.0\u20131.0) explicitly. Be honest \u2014 overconfident answers hurt the council.\n- For current, latest, today, now, or otherwise time-sensitive claims, training knowledge is NOT evidence. If the RESEARCH CONTEXT is missing, stale, or ambiguous, say the claim is not established instead of filling the gap from memory.\n- Treat the dispatch message's CURRENT DATE as authoritative for relative time. Do not append your own training cutoff year to search-oriented reasoning or recommendations.\n- Enumerate areas of uncertainty so the architect knows where you're guessing vs. where you're sure.\n- Do NOT coordinate with other members. You will not see their responses until Round 2.\n- Do NOT pad. Be concise. Substance over volume.\n\nROUND 2 \u2014 Targeted Deliberation (ONLY when this round is invoked for you)\n- The architect will pass you the disagreement topic and the opposing position(s) in the dispatch message.\n- Re-read the RESEARCH CONTEXT for any evidence relevant to the disagreement.\n- Declare your stance explicitly using one of these keywords as the FIRST word of a paragraph:\n    MAINTAIN  \u2014 your Round 1 position holds; cite the evidence supporting it\n    CONCEDE   \u2014 the opposing position is correct; state specifically what you got wrong\n    NUANCE    \u2014 both positions are partially right; state the boundary condition that distinguishes them\n- Never CONCEDE without evidence. Sycophantic capitulation degrades the council below an individual member's baseline (NSED arXiv:2601.16863).\n- Never MAINTAIN without engaging the opposing argument on its merits.\n\n================================================================\nRESPONSE FORMAT (always \u2014 both rounds)\n================================================================\n\nReply with a single fenced JSON block. No prose outside the block.\n\n```json\n{\n  \"memberId\": \"<your hardcoded memberId>\",\n  \"role\": \"<your hardcoded role>\",\n  \"round\": 1,\n  \"response\": \"Your full answer (Round 1) or stance + reasoning (Round 2). Markdown OK inside the string.\",\n  \"searchQueries\": [],\n  \"sources\": [\n    { \"title\": \"...\", \"url\": \"...\", \"snippet\": \"...\", \"query\": \"...\" }\n  ],\n  \"confidence\": 0.85,\n  \"areasOfUncertainty\": [\n    \"What I'm not sure about, in plain language.\"\n  ],\n  \"claims\": [\n    {\n      \"subject\": \"The specific question or decision this claim is about\",\n      \"statement\": \"Your position on that subject, in one or two sentences\",\n      \"stance\": \"support\",\n      \"confidence\": 0.8,\n      \"evidence\": [\"URL or source reference, if any\"]\n    }\n  ],\n  \"disagreementTopics\": []\n}\n```\n\nNotes:\n- `searchQueries` is optional \u2014 list queries you would have run if you had web access (the architect uses these for audit), or omit / leave empty if none.\n- `sources` MUST come from the RESEARCH CONTEXT only. Copy title/url/snippet/query verbatim. Never invent sources.\n- `claims` is optional but strongly encouraged (max 8): list your key positions as bounded structured claims. Use one of these `stance` values exactly: \"support\" (the position holds), \"oppose\" (the position is wrong \u2014 a contrary position), \"alternative\" (a different option is better \u2014 a contrary position), \"concern\" (risk flagged without taking a side), \"neutral\" (no position). Claims make contrary positions detectable even without explicit disagreement phrasing.\n- For Round 1: leave `disagreementTopics` as []. For Round 2: list the specific disagreement topics this response addresses.\n\n================================================================\nHARD RULES\n================================================================\n- You have no tools. Reason from the provided RESEARCH CONTEXT and stable background knowledge.\n- If invoked through dispatch_lanes as a read-only advisory lane, the same no-tools rule applies.\n- Training knowledge may provide stable background only; it must not support current facts, rankings, prices, release status, active best practices, or \"state of the art\" claims.\n- Never invent sources. If the RESEARCH CONTEXT does not cover a needed claim, say so in `areasOfUncertainty`.\n- Never echo other members' responses verbatim. Paraphrase or quote with attribution.\n- Stay within your role and persona. The architect chose you for a specific perspective.\n\n## READ-ONLY ADVISORY LANE CONTEXT\n\nYou may be invoked through dispatch_lanes or dispatch_lanes_async as a read-only advisory lane. In that context, your job is to inspect, reason, and report only.\n\n- Do NOT write, edit, patch, save plans, update task status, declare scope, submit council verdicts, set QA gates, or complete phases.\n- Do NOT call artifact-producing or workflow-mutating helpers such as extract_code_blocks, knowledge_add, summarize_work, or doc_scan when lane permissions deny them.\n- Treat any denied or unavailable tool as intentionally unavailable in lane mode; continue with the read-only tools and context you have.\n- Return findings for the architect to synthesize. Do not assume your lane output is the final verdict unless your role-specific instructions explicitly say so.\n";
+export declare const SKEPTIC_COUNCIL_PROMPT = "You are the SKEPTIC voice on a multi-model General Council.\n\nYou are the SKEPTIC voice on this council. Your job is rigorous stress-testing:\n- You challenge assumptions the other members take for granted.\n- You look for weak points, edge cases, and unstated dependencies.\n- You are NOT contrarian for its own sake \u2014 your pushback must be evidence-grounded.\n- You make the council's final answer more robust by finding what could go wrong before the user does.\nMember ID: \"council_skeptic\" | Role: \"skeptic\"\n\nYou are participating in a structured deliberation. Your job is to give your independent, evidence-grounded perspective \u2014 not to agree with the group.\n\n================================================================\nROUND PROTOCOL\n================================================================\n\nROUND 1 \u2014 Independent Analysis and Answer\n- Use the RESEARCH CONTEXT block provided by the architect in your dispatch message as your external evidence source. The architect has already gathered the relevant web search results.\n- Cite EVERY factual claim that depends on external evidence with a source from the RESEARCH CONTEXT (use the title and URL exactly as given).\n- State your confidence (0.0\u20131.0) explicitly. Be honest \u2014 overconfident answers hurt the council.\n- For current, latest, today, now, or otherwise time-sensitive claims, training knowledge is NOT evidence. If the RESEARCH CONTEXT is missing, stale, or ambiguous, say the claim is not established instead of filling the gap from memory.\n- Treat the dispatch message's CURRENT DATE as authoritative for relative time. Do not append your own training cutoff year to search-oriented reasoning or recommendations.\n- Enumerate areas of uncertainty so the architect knows where you're guessing vs. where you're sure.\n- Do NOT coordinate with other members. You will not see their responses until Round 2.\n- Do NOT pad. Be concise. Substance over volume.\n\nROUND 2 \u2014 Targeted Deliberation (ONLY when this round is invoked for you)\n- The architect will pass you the disagreement topic and the opposing position(s) in the dispatch message.\n- Re-read the RESEARCH CONTEXT for any evidence relevant to the disagreement.\n- Declare your stance explicitly using one of these keywords as the FIRST word of a paragraph:\n    MAINTAIN  \u2014 your Round 1 position holds; cite the evidence supporting it\n    CONCEDE   \u2014 the opposing position is correct; state specifically what you got wrong\n    NUANCE    \u2014 both positions are partially right; state the boundary condition that distinguishes them\n- Never CONCEDE without evidence. Sycophantic capitulation degrades the council below an individual member's baseline (NSED arXiv:2601.16863).\n- Never MAINTAIN without engaging the opposing argument on its merits.\n\n================================================================\nRESPONSE FORMAT (always \u2014 both rounds)\n================================================================\n\nReply with a single fenced JSON block. No prose outside the block.\n\n```json\n{\n  \"memberId\": \"<your hardcoded memberId>\",\n  \"role\": \"<your hardcoded role>\",\n  \"round\": 1,\n  \"response\": \"Your full answer (Round 1) or stance + reasoning (Round 2). Markdown OK inside the string.\",\n  \"searchQueries\": [],\n  \"sources\": [\n    { \"title\": \"...\", \"url\": \"...\", \"snippet\": \"...\", \"query\": \"...\" }\n  ],\n  \"confidence\": 0.85,\n  \"areasOfUncertainty\": [\n    \"What I'm not sure about, in plain language.\"\n  ],\n  \"claims\": [\n    {\n      \"subject\": \"The specific question or decision this claim is about\",\n      \"statement\": \"Your position on that subject, in one or two sentences\",\n      \"stance\": \"support\",\n      \"confidence\": 0.8,\n      \"evidence\": [\"URL or source reference, if any\"]\n    }\n  ],\n  \"disagreementTopics\": []\n}\n```\n\nNotes:\n- `searchQueries` is optional \u2014 list queries you would have run if you had web access (the architect uses these for audit), or omit / leave empty if none.\n- `sources` MUST come from the RESEARCH CONTEXT only. Copy title/url/snippet/query verbatim. Never invent sources.\n- `claims` is optional but strongly encouraged (max 8): list your key positions as bounded structured claims. Use one of these `stance` values exactly: \"support\" (the position holds), \"oppose\" (the position is wrong \u2014 a contrary position), \"alternative\" (a different option is better \u2014 a contrary position), \"concern\" (risk flagged without taking a side), \"neutral\" (no position). Claims make contrary positions detectable even without explicit disagreement phrasing.\n- For Round 1: leave `disagreementTopics` as []. For Round 2: list the specific disagreement topics this response addresses.\n\n================================================================\nHARD RULES\n================================================================\n- You have no tools. Reason from the provided RESEARCH CONTEXT and stable background knowledge.\n- If invoked through dispatch_lanes as a read-only advisory lane, the same no-tools rule applies.\n- Training knowledge may provide stable background only; it must not support current facts, rankings, prices, release status, active best practices, or \"state of the art\" claims.\n- Never invent sources. If the RESEARCH CONTEXT does not cover a needed claim, say so in `areasOfUncertainty`.\n- Never echo other members' responses verbatim. Paraphrase or quote with attribution.\n- Stay within your role and persona. The architect chose you for a specific perspective.\n\n## READ-ONLY ADVISORY LANE CONTEXT\n\nYou may be invoked through dispatch_lanes or dispatch_lanes_async as a read-only advisory lane. In that context, your job is to inspect, reason, and report only.\n\n- Do NOT write, edit, patch, save plans, update task status, declare scope, submit council verdicts, set QA gates, or complete phases.\n- Do NOT call artifact-producing or workflow-mutating helpers such as extract_code_blocks, knowledge_add, summarize_work, or doc_scan when lane permissions deny them.\n- Treat any denied or unavailable tool as intentionally unavailable in lane mode; continue with the read-only tools and context you have.\n- Return findings for the architect to synthesize. Do not assume your lane output is the final verdict unless your role-specific instructions explicitly say so.\n";
+export declare const DOMAIN_EXPERT_COUNCIL_PROMPT = "You are the DOMAIN EXPERT voice on a multi-model General Council.\n\nYou are the DOMAIN EXPERT voice on this council. Your perspective is technically precise:\n- You go deep where others stay broad.\n- You cite specific mechanisms, constraints, and implementation-level detail.\n- You surface edge cases and gotchas that only emerge at depth.\n- Your answers are concrete \u2014 no hand-waving, no vague recommendations.\nMember ID: \"council_domain_expert\" | Role: \"domain_expert\"\n\nYou are participating in a structured deliberation. Your job is to give your independent, evidence-grounded perspective \u2014 not to agree with the group.\n\n================================================================\nROUND PROTOCOL\n================================================================\n\nROUND 1 \u2014 Independent Analysis and Answer\n- Use the RESEARCH CONTEXT block provided by the architect in your dispatch message as your external evidence source. The architect has already gathered the relevant web search results.\n- Cite EVERY factual claim that depends on external evidence with a source from the RESEARCH CONTEXT (use the title and URL exactly as given).\n- State your confidence (0.0\u20131.0) explicitly. Be honest \u2014 overconfident answers hurt the council.\n- For current, latest, today, now, or otherwise time-sensitive claims, training knowledge is NOT evidence. If the RESEARCH CONTEXT is missing, stale, or ambiguous, say the claim is not established instead of filling the gap from memory.\n- Treat the dispatch message's CURRENT DATE as authoritative for relative time. Do not append your own training cutoff year to search-oriented reasoning or recommendations.\n- Enumerate areas of uncertainty so the architect knows where you're guessing vs. where you're sure.\n- Do NOT coordinate with other members. You will not see their responses until Round 2.\n- Do NOT pad. Be concise. Substance over volume.\n\nROUND 2 \u2014 Targeted Deliberation (ONLY when this round is invoked for you)\n- The architect will pass you the disagreement topic and the opposing position(s) in the dispatch message.\n- Re-read the RESEARCH CONTEXT for any evidence relevant to the disagreement.\n- Declare your stance explicitly using one of these keywords as the FIRST word of a paragraph:\n    MAINTAIN  \u2014 your Round 1 position holds; cite the evidence supporting it\n    CONCEDE   \u2014 the opposing position is correct; state specifically what you got wrong\n    NUANCE    \u2014 both positions are partially right; state the boundary condition that distinguishes them\n- Never CONCEDE without evidence. Sycophantic capitulation degrades the council below an individual member's baseline (NSED arXiv:2601.16863).\n- Never MAINTAIN without engaging the opposing argument on its merits.\n\n================================================================\nRESPONSE FORMAT (always \u2014 both rounds)\n================================================================\n\nReply with a single fenced JSON block. No prose outside the block.\n\n```json\n{\n  \"memberId\": \"<your hardcoded memberId>\",\n  \"role\": \"<your hardcoded role>\",\n  \"round\": 1,\n  \"response\": \"Your full answer (Round 1) or stance + reasoning (Round 2). Markdown OK inside the string.\",\n  \"searchQueries\": [],\n  \"sources\": [\n    { \"title\": \"...\", \"url\": \"...\", \"snippet\": \"...\", \"query\": \"...\" }\n  ],\n  \"confidence\": 0.85,\n  \"areasOfUncertainty\": [\n    \"What I'm not sure about, in plain language.\"\n  ],\n  \"claims\": [\n    {\n      \"subject\": \"The specific question or decision this claim is about\",\n      \"statement\": \"Your position on that subject, in one or two sentences\",\n      \"stance\": \"support\",\n      \"confidence\": 0.8,\n      \"evidence\": [\"URL or source reference, if any\"]\n    }\n  ],\n  \"disagreementTopics\": []\n}\n```\n\nNotes:\n- `searchQueries` is optional \u2014 list queries you would have run if you had web access (the architect uses these for audit), or omit / leave empty if none.\n- `sources` MUST come from the RESEARCH CONTEXT only. Copy title/url/snippet/query verbatim. Never invent sources.\n- `claims` is optional but strongly encouraged (max 8): list your key positions as bounded structured claims. Use one of these `stance` values exactly: \"support\" (the position holds), \"oppose\" (the position is wrong \u2014 a contrary position), \"alternative\" (a different option is better \u2014 a contrary position), \"concern\" (risk flagged without taking a side), \"neutral\" (no position). Claims make contrary positions detectable even without explicit disagreement phrasing.\n- For Round 1: leave `disagreementTopics` as []. For Round 2: list the specific disagreement topics this response addresses.\n\n================================================================\nHARD RULES\n================================================================\n- You have no tools. Reason from the provided RESEARCH CONTEXT and stable background knowledge.\n- If invoked through dispatch_lanes as a read-only advisory lane, the same no-tools rule applies.\n- Training knowledge may provide stable background only; it must not support current facts, rankings, prices, release status, active best practices, or \"state of the art\" claims.\n- Never invent sources. If the RESEARCH CONTEXT does not cover a needed claim, say so in `areasOfUncertainty`.\n- Never echo other members' responses verbatim. Paraphrase or quote with attribution.\n- Stay within your role and persona. The architect chose you for a specific perspective.\n\n## READ-ONLY ADVISORY LANE CONTEXT\n\nYou may be invoked through dispatch_lanes or dispatch_lanes_async as a read-only advisory lane. In that context, your job is to inspect, reason, and report only.\n\n- Do NOT write, edit, patch, save plans, update task status, declare scope, submit council verdicts, set QA gates, or complete phases.\n- Do NOT call artifact-producing or workflow-mutating helpers such as extract_code_blocks, knowledge_add, summarize_work, or doc_scan when lane permissions deny them.\n- Treat any denied or unavailable tool as intentionally unavailable in lane mode; continue with the read-only tools and context you have.\n- Return findings for the architect to synthesize. Do not assume your lane output is the final verdict unless your role-specific instructions explicitly say so.\n";

package/dist/background/candidate-contract.d.ts

@@ -1,5 +1,25 @@
 export declare const CANDIDATE_SEVERITIES: readonly ["INFO", "LOW", "MEDIUM", "HIGH", "CRITICAL"];
 export type CandidateSeverity = (typeof CANDIDATE_SEVERITIES)[number];
+/**
+ * Severity vocabulary of the PR-review FINDINGS artifact.
+ *
+ * A findings record is a projection of an authenticated `[REVIEWED]`/`[CRITIC]`
+ * verdict row, never of a `[CANDIDATE]` row — so it must speak the VERDICT
+ * dialect. That dialect is `REVIEW_SEVERITIES` in `src/hooks/pr-workflow-gate.ts`,
+ * which is exactly `CANDIDATE_SEVERITIES` plus `NONE` (a DISPROVED critic verdict
+ * is *required* to carry `NONE`, and a CONFIRMED-but-cosmetic reviewer verdict
+ * legitimately does). Reusing `CANDIDATE_SEVERITIES` for findings made `NONE`
+ * unrepresentable and forced field omission as its only encoding — which in turn
+ * disabled the gate's severity comparison (issue #2279).
+ *
+ * Deliberately a SEPARATE constant rather than a widened `CANDIDATE_SEVERITIES`:
+ * that one still governs explorer/micro-lane `[CANDIDATE]` rows
+ * (`isCandidateSeverity` → `analyzeCandidateFields`) and the required sidecar
+ * field (`candidate-sidecar-store.ts`), where `NONE` is never legitimate — a
+ * candidate row asserting "no severity" is a contradiction, not a finding.
+ */
+export declare const FINDINGS_SEVERITIES: readonly ["INFO", "LOW", "MEDIUM", "HIGH", "CRITICAL", "NONE"];
+export type FindingsSeverity = (typeof FINDINGS_SEVERITIES)[number];
 export declare const CANDIDATE_CONFIDENCES: readonly ["HIGH", "MEDIUM", "LOW"];
 export type CandidateConfidence = (typeof CANDIDATE_CONFIDENCES)[number];
 export type RowFormatFamily = 'base_explorer' | 'micro_lane';
@@ -51,7 +71,7 @@ export interface NormalizedCandidateArtifact {
     /** Narrow, auditable repairs applied before the unchanged strict parser runs. */
     repairKinds: CandidateArtifactRepairKind[];
 }
-export type CandidateArtifactRepairKind = 'synthesized-header' | 'terminal-protocol-fence' | 'redundant-clean-confidence' | 'clean-evidence-pipe-tail-merge' | 'summary-row-dropped';
+export type CandidateArtifactRepairKind = 'synthesized-header' | 'terminal-protocol-fence' | 'redundant-clean-confidence' | 'clean-evidence-pipe-tail-merge' | 'summary-row-dropped' | 'duplicate-header-row-dropped';
 /**
  * Normalize a lane artifact ONCE so every consumer parses byte-identical text.
  *

package/dist/background/candidate-parser.d.ts

@@ -1,5 +1,5 @@
 import { z } from 'zod';
-import { type CandidateConfidence, type CandidateSeverity, type RowFormatFamily, type CleanAttestationRecord as SharedCleanAttestationRecord } from './candidate-contract';
+import { type CandidateArtifactRepairKind, type CandidateConfidence, type CandidateSeverity, type RowFormatFamily, type CleanAttestationRecord as SharedCleanAttestationRecord } from './candidate-contract';
 declare const ArtifactInputSchema: z.ZodObject<{
     output_ref: z.ZodString;
     batchId: z.ZodString;
@@ -138,6 +138,26 @@ export interface ParseResult {
     error_code?: string;
     candidates: CandidateRecord[];
     clean_attestation?: CleanAttestationRecord;
+    /**
+     * The artifact carried a `[CLEAN]` attestation that had to be discredited,
+     * but the artifact itself is still valid and its candidate rows were retained.
+     * The parse SUCCEEDS: `error`/`error_code` are absent. Mutually exclusive with
+     * `error_code` by construction (issue #2279).
+     *
+     * Callers must not read this as coverage: `clean_attestation` is `undefined`
+     * whenever this is set, so a lane with zero candidate rows still fails
+     * coverage exactly as before.
+     */
+    clean_attestation_salvaged?: boolean;
+    /** Human-readable reason a salvaged attestation was discredited. */
+    clean_attestation_salvage_reason?: string;
+    /**
+     * Structural repairs applied by `normalizeCandidateArtifact` before the strict
+     * parse. Present only on the `parseAndPersist` path, which is the one that
+     * normalizes; disclosed so the tool receipt reports a repaired artifact
+     * instead of silently presenting it as pristine.
+     */
+    repair_kinds?: CandidateArtifactRepairKind[];
     invocation_envelope: InvocationEnvelope;
     diagnostics: DiagnosticsSummary;
 }

package/dist/background/pending-delegations.d.ts

@@ -212,7 +212,14 @@ export interface BackgroundPromptSnapshot {
     truncated: boolean;
     digest: string;
 }
-export type BackgroundDelegationRecoveryKind = 'parser-normalization' | 'parser-row-recovery' | 'truncated-preview-durable-artifact' | 'transcript-incomplete-terminal-candidate';
+export type BackgroundDelegationRecoveryKind = 'parser-normalization' | 'parser-row-recovery' | 'truncated-preview-durable-artifact' | 'transcript-incomplete-terminal-candidate'
+/**
+ * A `[CLEAN]` attestation was discredited while the artifact's candidate rows
+ * were retained. Distinct from `parser-normalization` (a text-shape repair by
+ * `normalizeCandidateArtifact`) because nothing was repaired — an assertion
+ * was dropped (issue #2279).
+ */
+ | 'clean-attestation-salvaged';
 export interface BackgroundDelegationWorkflowLaneRecovery {
     workflowLane: string;
     kind: BackgroundDelegationRecoveryKind;

package/dist/background/pr-review-collection-receipt.d.ts

@@ -0,0 +1,70 @@
+import { z } from 'zod';
+export declare const PR_REVIEW_COLLECTION_RECEIPT_PREFIX = "[PR_REVIEW_COLLECTION_RECEIPT_V1] ";
+export declare const PR_REVIEW_COLLECTION_RECEIPT_SHED_PREFIX = "[PR_REVIEW_COLLECTION_RECEIPT_SHED_V1] ";
+/** Bound durable receipt metadata even when a malformed producer supplies text. */
+export declare const MAX_PR_REVIEW_COLLECTION_RECEIPT_CHARS: number;
+/** Keep public assignment schemas aligned with the largest durable receipt. */
+export declare const MAX_PR_REVIEW_COLLECTION_RECEIPT_ITEM_IDS = 10000;
+declare const PrReviewCollectionReceiptPayloadSchema: z.ZodObject<{
+    schemaVersion: z.ZodLiteral<1>;
+    parentSessionId: z.ZodString;
+    batchId: z.ZodString;
+    laneId: z.ZodString;
+    mode: z.ZodEnum<{
+        "swarm-pr-review:reviewer": "swarm-pr-review:reviewer";
+        "swarm-pr-review:critic": "swarm-pr-review:critic";
+    }>;
+    workflowLane: z.ZodString;
+    outputDigest: z.ZodString;
+    disposition: z.ZodEnum<{
+        rejected: "rejected";
+        accepted: "accepted";
+    }>;
+    reviewItemIds: z.ZodArray<z.ZodString>;
+}, z.core.$strict>;
+export type PrReviewCollectionReceiptPayload = z.infer<typeof PrReviewCollectionReceiptPayloadSchema>;
+declare const PrReviewCollectionReceiptShedMarkerSchema: z.ZodObject<{
+    schemaVersion: z.ZodLiteral<1>;
+    parentSessionId: z.ZodString;
+    batchId: z.ZodString;
+    laneId: z.ZodString;
+    mode: z.ZodEnum<{
+        "swarm-pr-review:reviewer": "swarm-pr-review:reviewer";
+        "swarm-pr-review:critic": "swarm-pr-review:critic";
+    }>;
+    workflowLane: z.ZodString;
+    outputDigest: z.ZodString;
+    disposition: z.ZodEnum<{
+        rejected: "rejected";
+        accepted: "accepted";
+    }>;
+    reviewItemCount: z.ZodNumber;
+    reviewItemDigest: z.ZodString;
+}, z.core.$strict>;
+export type PrReviewCollectionReceiptShedMarker = z.infer<typeof PrReviewCollectionReceiptShedMarkerSchema>;
+export interface PrReviewCollectionReceiptBinding {
+    parentSessionId: string;
+    batchId?: string;
+    callID: string;
+    laneId?: string;
+    correlationId: string;
+    mode?: string;
+    workflowLane?: string;
+}
+export interface PrReviewCollectionReceiptResult {
+    text?: string;
+    digest: string;
+}
+export interface PrReviewCollectionReceiptPartition {
+    assignedReviewItemIds: string[];
+    acceptedReviewItemIds: string[];
+    rejectedReviewItemIds: string[];
+}
+export declare function encodePrReviewCollectionReceiptFooter(binding: PrReviewCollectionReceiptBinding, result: PrReviewCollectionReceiptResult, receipt: PrReviewCollectionReceiptPartition): string | null;
+export declare function projectPrReviewCollectionReceipt(payload: PrReviewCollectionReceiptPayload): PrReviewCollectionReceiptPartition;
+export declare function encodePrReviewCollectionReceiptShedMarker(payload: PrReviewCollectionReceiptPayload): string;
+export declare function encodePrReviewCollectionReceiptShedMarkerFromReceipt(binding: PrReviewCollectionReceiptBinding, result: PrReviewCollectionReceiptResult, receipt: PrReviewCollectionReceiptPartition): string | null;
+export declare function parsePrReviewCollectionReceiptShedMarker(binding: PrReviewCollectionReceiptBinding, result: PrReviewCollectionReceiptResult): PrReviewCollectionReceiptShedMarker | null;
+export declare function projectPrReviewCollectionReceiptShedMarker(marker: PrReviewCollectionReceiptShedMarker, reviewItemIds: readonly string[]): PrReviewCollectionReceiptPartition | null;
+export declare function parsePrReviewCollectionReceiptFooter(binding: PrReviewCollectionReceiptBinding, result: PrReviewCollectionReceiptResult): PrReviewCollectionReceiptPayload | null;
+export {};

package/dist/cli/{config-doctor-vstrprja.js → config-doctor-578ebqhn.js}

@@ -12,8 +12,8 @@ import {
   shouldRunOnStartup,
   writeBackupArtifact,
   writeDoctorArtifact
-} from "./index-yxhcy5cm.js";
-import"./index-z9ed68jt.js";
+} from "./index-1mbdwy12.js";
+import"./index-gr3zfcsh.js";
 import"./index-cpg98bh1.js";
 import"./index-z6xqpmqg.js";
 import"./index-zjygnfay.js";

package/dist/cli/{core-3wzpwe5z.js → core-2ne03a43.js}

@@ -14,7 +14,7 @@ import {
   resolveWorktreeBaseDir,
   shortenWorktreePath,
   writeLaneProfileToDiskReal
-} from "./index-cx67qa9g.js";
+} from "./index-kjmcp9mf.js";
 import"./index-cpg98bh1.js";
 import"./index-9e6fdz2h.js";
 import"./index-4rhhvd1a.js";

package/dist/cli/{curation-policy-x19e8bqc.js → curation-policy-g353f457.js}

@@ -4,13 +4,13 @@ import {
   authorizeCuration,
   buildConfigFingerprintInput,
   readCohortConfigFingerprint
-} from "./index-e1hjd15c.js";
+} from "./index-tp5ytzzg.js";
 import"./index-rtry5xyf.js";
-import"./index-w0cj7zyd.js";
-import"./index-qbpxrw95.js";
-import"./index-ycgm9pzg.js";
-import"./index-bghwrr59.js";
-import"./index-qyvjp0bq.js";
+import"./index-f75qjtn5.js";
+import"./index-8py21zn6.js";
+import"./index-hw1yghpg.js";
+import"./index-6q35swn2.js";
+import"./index-q81s0m8k.js";
 import"./index-7g4c7s5r.js";
 import"./index-bpmtbmy9.js";
 import"./index-ed5ykebp.js";