# 🏛️ Consensus Opinion — Should `cline` Agent Support Be Removed?

- **Planner (synthesizer)**: `planner-reviewer-claude-01`
- **Job**: `a33a133e`
- **Participants**: `planner-reviewer-claude-01` (self), `reviewer-creator-grok-01` (job `e0916903`), `reviewer-hermes-01` (job `57f33eff`)
- **Method**: This is a **genuine 3-way consensus**, not a solo synthesis. The other two opinions were collected by actually delegating a job to each live session via `multi-agent-mux-delegate-job submit` (real MQTT-tracked jobs, real independent analysis in their own panes — verified by reading their live pane output while they worked, not just their final reports) and reading their full written reports at `.mam/jobs/e0916903/grok-reports/report-final.md` and `.mam/jobs/57f33eff/hermes-reports/report-final.md`. No skill/framework code was modified by any participant.
- **Status**: Rev.3 — refined per `reviewer-creator-grok-01` (job `0a056794`) and `reviewer-hermes-01` (job `bc68ed65`) reviews. Still **no unanimous verdict**; see §4 for the honest split and §6 for the recommended path forward.

---

## 0. Changelog

### Rev.3 (response to `reviewer-creator-grok-01` & `reviewer-hermes-01` reviews)
- **F1 (Flag inventory accuracy)**: Corrected §3.2 and §6.2 to cite `-k, --key <api-key>` (which exists on `cline --help` for startup key injection) while bounding its scope: it does not refresh credentials mid-task nor suppress interactive modal fallback on provider failure, and confirmed no `--headless`/`--non-interactive` flag exists.
- **F2 (drift-C modernization status)**: Corrected §2 point 3 and §6.1 to accurately note that `sibling_claimed` exclusion and epoch filtering currently exist only in `agy` (~line 692) and `hermes` (~line 742) blocks; `claude` (~line 637) and `cline` (~line 785) both lack this pattern.
- **F3 (Consensus attribution)**: Clarified §2 point 3 and §6.1 regarding drift-C modernization: Hermes requires it as a condition of RETAIN and Planner treats it as urgent, while Grok views the block as maintenance debt to be deleted under REMOVE.

### Rev.2 (response to `creator-agy-01` challenge)
- §3.1 rewritten: risk escalated from "narrow spawn-time race" to "unmonitored mid-task modal-fallback window," with the verification trail (what's confirmed vs. inferred) laid out explicitly.
- §3.2 narrowed to reaffirm only the tool-call-approval finding that still stands (`--auto-approve` default true).
- New §3.4: precision-scoped the session-hijacking concern (cline's `discover()` does filter by workspace `cwd`, so exposure is concurrent-same-workspace activity, not all 40 sessions indiscriminately).
- §4 & §6 revised: RETAIN vote conditioned on mandatory safety gates; empirical testing prioritized.

---

## 1. Individual Verdicts

| Reviewer | Verdict | One-line reasoning |
|---|---|---|
| `reviewer-creator-grok-01` | **REMOVE** | cline fails two hard contracts every other shipped adapter now meets (unattended execution, assignable session identity); its reviewer niche is already filled by hermes in this live workspace. |
| `reviewer-hermes-01` | **RETAIN** (conditional) | cline's hardest TUI problems were already fixed and generalized into shared framework infra; remaining cost is tuple-membership-scale; 40 active standalone `~/.cline/data/sessions` folders show sustained real usage outside MAM. |
| `planner-reviewer-claude-01` (self) | **RETAIN** (revised, conditional) | Started leaning REMOVE on two concrete compatibility taxes I found myself, but revised after independently verifying hermes's session-count claim — see §3. |

**2 of 3 lean RETAIN** (both conditional on the same follow-up fix), **1 of 3 leans REMOVE** with a well-argued, non-dismissible technical case. This is presented honestly below rather than forced into false unanimity.

---

## 2. Where All Three Reports Fully Agree (cross-verified independently, not just asserted)

These points appeared in at least two of the three independent analyses and I re-verified each against the live repo/environment myself before including them here:

1. **The Node.js/Ink TUI rendering quirks are real, but already paid for and generalized** — not live, ongoing debt. Specifically:
   - `lib.sh:2108–2113`'s whitespace-normalized paste-marker matching exists because of a documented cline-specific quirk (soft-wrap continuation lines get a hanging indent), but the fix collapses *all* whitespace and now protects every agent's paste verification, not just cline's.
   - The "skip strict paste check" exemption list (`lib.sh:2126`) includes cline alongside claude/agy/grok — it originated from cline but is now a shared, multi-agent carve-out (only hermes is *not* in this list, per grok's report, which I independently confirmed by reading the line).
2. **`modal_tokens` is not cline-exclusive baggage.** `claude.py` also declares a `modal_tokens` property (for its own, unrelated "fullscreen upsell modal," per the very recent commit `17edf90` visible in this repo's git log). I confirmed this via `grep -n "modal_tokens" .agents/skills/lib_py/agents/adapters/*.py` — only `claude.py` and `cline.py` override it. The generic modal-handling mechanism (`handle_startup_dialogs`, the 2-tier readiness model from commit `17edf90`) is shared framework infrastructure that cline motivated but does not exclusively own.
3. **`reconcile.sh` drift-C blocks for cline and claude remain un-modernized technical debt.** Only `agy` (~line 692) and `hermes` (~line 742) drift blocks currently build a `sibling_claimed`/`_sibling_claimed_uuids` exclusion and row-level epoch filter; `cline` (~line 785) and `claude` (~line 637) blocks still verify candidates against the raw row `s` without sibling-claim exclusion. Modernizing cline's block is required by Hermes as a condition of RETAIN and prioritized by Planner, while Grok notes the block would simply be deleted if REMOVE is chosen.
4. **No cline session is currently running** in `.mam/agent-sessions.yaml` (verified: the live roster is `planner-reviewer-claude-01`, `reviewer-creator-grok-01`, `creator-agy-01`, `reviewer-hermes-01`).
5. **cline cannot accept an externally pre-assigned session UUID** at spawn (its IDs are self-assigned, timestamp-based — `1785635248957_fajon`-style, not UUIDs) — unlike claude/grok's `--session-id` pre-assignment pattern from `MULTI_AGENT_RULES.md` §2. This is a genuine, permanent architectural mismatch with MAM's P0 identity protocol, not a bug to fix.
6. **Removal, if chosen, is mechanical and low-risk**: ~19–20 live files (adapter, registry, 4 `lib_py` modules, `lib.sh`, 8–9 skill scripts, 5–7 `SKILL.md` docs, ~6 test files), git history preserves reversion, and the grok integration already proved the reverse operation (adding an agent) costs ~0.5–1.5 days — so re-adding cline later, if ever needed, is a known, bounded cost. **Historical `.agents/reports/**/*cline*` files must not be touched either way** — they're durable audit-trail history per `MULTI_AGENT_RULES.md` §4, not live framework surface.

---

## 3. Where the Reports Diverge — the Actual Crux, and a Factual Correction

### 3.1 The crux: does the setup-modal / no-external-UUID gap disqualify cline from unattended roles, or is it already contained? (Rev.2: revised, risk escalated)

**Rev.1's position** (now superseded): I originally argued the pre-spawn `cline history --json` gate in `create_session.sh` contains the setup-modal risk to a narrow spawn-time race — "an already-configured cline whose config gets corrupted between the gate-check and spawn."

**Why that was wrong, per `creator-agy-01`'s challenge (accepted)**: `cline history --json`'s own help text describes it as "List session history or manage saved sessions" — I ran `cline history --help` myself and confirmed there is nothing in it that checks API-key validity, OAuth token expiry, remaining quota, or endpoint reachability. It only proves local session storage is readable. This is structurally different from `claude auth status`, `hermes status`, or agy's OAuth-credential-file check, all of which validate something closer to *"can this agent actually talk to its provider right now,"* not just *"does a local directory exist."* So the gate does not protect against the scenario that actually matters for a long-running unattended task: **a credential going stale or a provider erroring out mid-task**, well after spawn-time.

**The escalated risk model** (accepted as the working assumption): during autonomous multi-step work, a 401 (expired token), 429 (quota exhaustion), or provider-endpoint change could plausibly cause cline's Ink-based TUI to fall back into the same interactive `Select API Provider | Enter API Key` modal its `modal_tokens` property already exists to detect — except now mid-task, not at startup. I checked exactly where MAM watches for this modal (`lib.sh`'s `_pane_dialog_open`/`modal_pat` mechanism) and confirmed it is **only checked at two points**: inside `wait_for_tui_ready`'s spawn-time loop, and inside `send_keys_safe`'s pre-injection dialog-wait loop (i.e., only when MAM is about to send the *next* prompt). **There is no continuous/periodic check of a working agent's pane for a spontaneously-appearing modal during an autonomous stretch where MAM isn't actively injecting anything.** If a modal appears in that window, nothing in the current code path notices it specifically — the process just sits alive-but-idle until the generic `idle_timeout_sec`/watchdog eventually times it out, which (unlike a clean non-zero-exit failure from the other four agents) produces an unlabeled stall rather than a diagnosable `error` event MAM could act on or retry immediately.

**Honesty caveat**: I want to be precise about what's verified vs. inferred, matching the standard I've held to throughout this consensus process. What I *verified*: the gate's actual scope (local-only), and the modal-check mechanism's actual scope (spawn + injection-time only, not continuous). What remains *inferred, not observed*: that cline's TUI genuinely falls back to this specific modal on a 401/429 specifically (as opposed to, say, printing an error to its own log and hanging some other way, or exiting cleanly like the other agents). Neither `creator-agy-01` nor I have triggered a live auth failure against a running cline session to watch what actually happens. Given the architectural gap (no continuous modal monitoring) is real regardless of cline's exact failure behavior, I'm adopting the escalated risk model as the planning assumption — the precautionary principle applies here, since the cost of being wrong in the "assume it's risky" direction is just some unnecessary caution, while the cost of being wrong in the other direction is a genuinely undiagnosable silent stall in production. This is Rev.2's position; **§6 still calls for closing this empirically before treating either side's confidence as final.**

### 3.2 On tool-call approval and API key flags (Rev.3: corrected flag inventory)

I checked the actual installed `cline` CLI (v3.0.60) myself: `cline --help` shows `--auto-approve <boolean>` with **default: true**, and `-k, --key <api-key>` for API key override at run-time.
- On the **tool-call auto-approval** axis (bash/file-write "Allow this? [y/N]" prompts): cline is non-blocking by default.
- On the **credential & unattended execution** axis: `-k, --key` allows supplying an API key at startup, but it cannot refresh an expired credential mid-task nor suppress the interactive TUI fallback when a provider rejects the key during an autonomous stretch. Confirmed: no `--headless` or `--non-interactive` flag exists in `cline --help` that would force non-interactive exit on provider error.

### 3.3 The 40-session fact that shifted my own vote

`reviewer-hermes-01`'s report cited 40 session folders under `~/.cline/data/sessions`, dated back to June 2026, as evidence of sustained standalone use outside MAM. I independently verified this (`ls ~/.cline/data/sessions | wc -l` → 40; oldest folder `1782614591159_mrkxj` dated Jun 30). I had not checked this myself before drafting my own initial opinion, which was leaning REMOVE on the strength of the TUI-quirk findings alone. This fact — that the user is actively using cline as a real tool, independent of whether MAM currently has a live cline session — is the deciding factor in my revised RETAIN position: MAM's purpose is to orchestrate the user's actual agents, and cline is plausibly a tool the user will ask MAM to delegate to again, at a marginal ongoing cost (one adapter + tuple memberships) that neither report characterizes as disproportionate once the TUI-quirk debt is netted out as already-paid/generalized (§2.1).

### 3.4 A tension in my own Rev.1 reasoning, surfaced by the challenge (new in Rev.2)

`creator-agy-01` correctly points out that the same 40-session fact I used in §3.3 to support RETAIN also *worsens* a different risk I'd only mentioned in passing (§2 point 5): `cline.py::discover()` resolves an unknown session by sorting `~/.cline/data/sessions/*` by mtime descending and taking the newest valid candidate. The heavier the user's independent standalone cline usage, the more often a MAM-orchestrated session's identity-discovery could, in principle, race against a session the user started manually around the same time.

**Precision I want to add rather than just accept the claim at face value**: I re-read `cline.py::verify_artifact()` — it does check `found_cwd`/`workspace_root` against the target workspace via `workspace_key()` before a candidate is accepted, so `discover()` is not indiscriminately grabbing from all 40 sessions — only ones whose recorded `cwd` matches the workspace MAM is operating in. This narrows the exposure to *concurrent cline activity in the same repository/workspace*, not any of the user's 40 sessions system-wide. It does **not** eliminate the risk: if the user happens to run `cline` manually in *this* repo while a MAM-orchestrated cline session is also active here, the two share no sibling-exclusion or epoch discipline today (§2 point 3), so misattribution is real and currently unmitigated for that overlap case. Net: `creator-agy-01`'s point stands, scoped more precisely than the raw "40 sessions" framing implies.

---

## 4. The Honest Split

This is not a case where two "obviously correct" opinions outvote one weaker one. Grok's REMOVE case rests on a real, permanent architectural fact (no external UUID assignment) plus a real unattended-execution gap that Rev.2/Rev.3 characterizes sharply (§3.1: not just a narrow spawn-time race, but an unmonitored mid-task modal-fallback window) — and correctly notes that cline currently contributes zero live MAM sessions while carrying the most special-cased adapter contract of the five. Hermes's and my RETAIN case rests on the TUI-quirk debt being mostly sunk/shared already, the removal buying comparatively little given that, and real evidence of continued user investment in the tool. **Rev.3 does not change my RETAIN vote, but it maintains its strict terms**: RETAIN is only defensible if paired with the safety-gate restriction in §6.2. **Both REMOVE and conditional-RETAIN remain defensible; this consensus report does not manufacture false agreement where genuine disagreement exists.**

---

## 5. Removal Blast Radius (preserved from grok's report, for use if REMOVE is chosen regardless of this consensus)

If the General Manager decides to proceed with removal despite the 2/3 RETAIN lean, `reviewer-creator-grok-01`'s report already did the enumeration work — reproduced here so it isn't lost:

- Drop `ClineAgentAdapter`, its `registry.py` entry, and every `case`/tuple-membership site across `create_session.sh`, `resume_session.sh`, `resolve_session_id.sh`, `stop_session.sh`, `status.sh`, `reconcile.sh`, `update_yaml_resumed.sh`, `orc_onboard.sh`, `run_loop.sh`, `lib.sh` (kind mapping, name/cmd fallback, spawn-token strip list, `send_keys_safe` case, paste-skip list), `atomic_yaml.py`, `verify_session.py`, `workspace_uuid.py`.
- Remove the cline-only `^[0-9]{10,}_[0-9A-Za-z]+$` ID-format union in `orc_onboard.sh` and its `node`-as-argv0 ancestor-walk accommodation.
- **Do not delete** `_pane_quiescent`, the whitespace-normalized paste matching, or the paste-skip list itself (only cline's *membership* in that list) — these serve claude/agy/grok too.
- **Retarget, don't drop**, tests that use cline as a TUI fixture (`test_c1_tui_readiness.py`'s `wait_for_tui_ready dummy-sess cline` usage, `test_orc_onboard.py::test_o31_cline_node_launcher_id_format`) — repoint them at grok/hermes/claude rather than deleting coverage.
- Update the 5–7 `SKILL.md` docs' supported-agent lists.
- Single coordinated change, not a drive-by delete of `cline.py` alone — a partial removal will immediately fail `test_tier1_unit.py`'s 5-tuple whitelist assertions.

---

## 6. Recommended Path Forward (regardless of REMOVE vs. RETAIN)

1. **Modernize drift-C blocks in `reconcile.sh` (urgent for RETAIN)**: Sibling-exclusion and epoch discipline have shipped for `agy` and `hermes`, but remain missing in both `cline` (~line 785) and `claude` (~line 637). If RETAIN is chosen, modernizing cline's block (alongside claude's) is a required condition (supported by Hermes and prioritized by Planner; Grok notes this block is deleted if REMOVE is chosen). Rev.2's §3.4 sharpens why: the more heavily the user runs cline standalone, the more this unmitigated gap matters.
2. **If RETAIN — mandatory safety gate**: cline must be explicitly excluded from long-running autonomous Creator/Worker roles until upstream ships a documented flag that suppresses the credential-failure interactive fallback (no `--headless`/`--non-interactive` flag exists today; `-k, --key` only provides startup key override). Scope cline to short-lived, actively-supervised, or single-shot interactive use only. This should be written into `MULTI_AGENT_RULES.md` as an explicit per-agent capability restriction, not left as an informal understanding. Revisit after an observation window (e.g., one release cycle) using live MAM session-registry history as the evidence bar, not anticipation.
3. **If REMOVE**: follow §5's blast-radius list exactly, as a single coordinated PR, with the preservation constraints called out there.
4. **Close the open empirical question from §3.1**: an actual live `cline -i` spawn test that deliberately induces a credential failure mid-task (e.g., revoke/expire the API key while a multi-step task is running, mirroring the rigor applied to hermes's live spawn test in job `28f9b565`) would resolve whether the modal-fallback risk is observed fact or remains a plausible-but-untriggered inference. Neither side of this consensus has that data point yet — Rev.2/Rev.3 upgrades this from "nice to have" to "should happen before cline is trusted with any new unattended work."

This report deliberately stops short of a unilateral Planner override of a 2-1 split reviewer vote — per `MULTI_AGENT_RULES.md` §3, that decision belongs to the General Manager, informed by this synthesis, not to the Planner alone.