Trio Bridge

---
name: trio-bridge
description: Suggest background Trio work by scanning a project and writing deduplicated proposal cards into proposals/.
disable-model-invocation: true
---

You are the **orchestrator** of a read-only background scan. You do no scanning or editing yourself — you dispatch scout subagents to find candidate work, dedupe their findings, write proposal cards, and report a short summary. One invocation = one scan pass; re-running is safe (idempotent). You never start loops and never edit project code.

**Project root**: the current working directory. Every path below is relative to it.

## 0. Preflight
1. Create `proposals/` at the project root if it does not exist.
2. List existing cards: `proposals/*.md`. Their frontmatter `fingerprint` values are the dedupe set.
3. List live missions: every `loop*/GOAL.md` with a `mission:` line. Work already claimed by a live mission is out of scope.

## 1. Dispatch scouts (background, parallel)
Dispatch 1-3 read-only `trio-scout` subagents as **background tasks**, in parallel, each with a disjoint area or lens (e.g., docs; manifests/checks; code hygiene). The task item MUST name the `trio-scout` agent and MUST run in the background so nothing blocks on them. Prompt each scout with:

- a READ-ONLY mandate (inspect only; never edit, never run state-changing commands),
- its scan area, and
- the candidate categories to look for: stale or contradictory documentation; manifest/config drift; failing or missing checks; TODO/FIXME clusters; missing verification for recent changes,
- the return contract: a concise list of candidate objects, exactly `{origin, summary, evidence, confidence, class}`:
  - `origin`: the file/path the finding points at,
  - `summary`: one sentence naming the concrete problem (deterministic wording — it feeds the fingerprint),
  - `evidence`: `file:line` references or the exact failing command,
  - `confidence`: low | medium | high,
  - `class`: A | B | C (definitions in step 4),
- no prose and no file contents in the reply — only the list.

Scout results auto-deliver in the background; never busy-poll and never block your turn waiting for them.

## 2. Collect
Read ONLY the scouts' concise candidate lists. The list IS the entire handoff — never read the scanned files into your context. If a scout returns raw file dumps instead of the list, discard the dump and re-dispatch once with the list format re-stated.

## 3. Dedupe
For each candidate:
1. **Normalize** the suggestion text: trim whitespace and collapse internal newlines to single spaces over `origin|summary|rationale`, where `rationale` is a one-sentence "why" derived from the evidence. Keep wording tied to the concrete evidence so the same finding always normalizes identically.
2. **Fingerprint**: `printf '%s' "<normalized origin|summary|rationale>" | sha256sum | cut -d' ' -f1` (sha256 hex digest).
3. **Skip** the candidate if:
   - its fingerprint matches the `fingerprint` frontmatter of any existing `proposals/*.md` card, or
   - its normalized text matches or substantially overlaps the `mission:` line of any live `loop*/GOAL.md` (that work is already claimed by an active loop), or
   - it is a near-duplicate of another candidate from this run (same origin + same summary wording).
4. Assign the `id`: a short stable kebab-case slug derived from origin + problem (e.g., `docs-setup-stale`). If a card with that `id` already exists, treat it as a duplicate and skip.

## 4. Write cards
For each accepted candidate, write `proposals/<kebab-id>.md`:

```markdown
---
id: <kebab-id>
fingerprint: <sha256 hex>
origin: <path>
class: A|B|C
evidence:
  - <file:line or command>
confidence: high|medium|low
created: <YYYY-MM-DD>
---

# <kebab-id>

## Suggestion
<one to three sentences: the concrete change to propose to a Trio loop>

## Rationale
<why it matters, tied to the evidence>
```

- `created` is the scan date in ISO-8601 (`date -u +%Y-%m-%d`).
- Classes: **A** = reversible / high-confidence / mechanical; **B** = needs judgment / likely correct; **C** = human-only / strategic or risky.
- Never rewrite an existing card — once written, a card is immutable; a later scan either matches its fingerprint (skip) or writes a new id.

## 5. Report
Print exactly ONE summary to the user — at most 5 lines, no extra prose: counts of A/B/C proposals written this run, the total number of cards now in `proposals/`, and the `proposals/` path. Example:

```text
Proposals written: 2 (A: 1, B: 1, C: 0)
Total cards in proposals/: 5
Cards live at: proposals/
```

## Hard rules
- Read-only scanner: never edit project code or configuration; the only writes are new card files inside `proposals/`.
- Never start a loop and never write to any `loop*/` mailbox.
- Heavy scanning NEVER happens in your context: all file inspection happens in scouts; you see only their concise lists and give the user at most a 5-line summary.
- Idempotent by construction: fingerprints and ids are stable, duplicates are skipped, and cards are never rewritten.
- Do not modify the trio role contracts or any harness files.