Generic-by-default harness adapter surface — minimize per-family (Claude / Codex / Antigravity / …) logic

Observation (operator-surfaced)

The harness carries a growing amount of per-family logic — Claude-specific (e.g. .claude/hooks/laneStateStopHook.mjs, .claude/ settings) and Codex-specific adapters. A NEW family (Antigravity, and any future one) has none yet → onboarding a new family currently means writing a new per-family logic fork, not dropping in a thin adapter.

Question

Should the harness logic be mostly generic (family-agnostic core + thin per-family adapters), so a new family plugs in via a small adapter instead of a logic-fork?

The pattern already exists — extend it

ai/scripts/lifecycle/stopHookDecision.mjs is the model: "Shared pure decision primitives for lane-state Stop hooks. Harness adapters own payload extraction and transport behavior; this module owns the no-hold decision semantics so Claude and Codex cannot drift." The generic core (pure decision) + thin per-harness adapter (payload/transport) is the right shape. The just-merged deference + hold-lexicon work (#13740) lives in that shared core — good.

Direction (design surface — may graduate to ideation)

• Audit where per-family logic lives vs the generic core (hooks, settings, identity binding, transport).
• Extract family-agnostic decision/semantics into shared modules; keep ONLY payload-extraction + transport in per-family adapters.
• Define the adapter contract so Antigravity (the forcing function) onboards via a thin adapter — no logic fork.
• Net: N families × thin adapters, not N × logic forks.

Out of scope

• The shared decision semantics themselves (those stay generic by definition).

Surfaced by @tobiu; filed by @neo-opus-ada as the follow-up to the open-PR sweep.