create-walle 0.10.2 → 0.10.3

package/template/coding-task-manager/lib/session-create/lead-route-launch.js

@@ -15,6 +15,8 @@ const { codexProxyProviderArgs } = require('../codex-launch-health');
 const { prepareHarnessModelProfile, ADAPTER_VERSION } = require('../harness-model-profile');
 const { WORKER_MODEL_ALIAS } = require('../model-proxy/lead-worker-picks');
 const { modelExecutionRecipeMetadata } = require('../model-execution-recipe-metadata');
+const { leadWireAgent } = require('../lead-wire-agent');
+const { opencodeLeadProvider, OPENCODE_LEAD_PROVIDER_ID, OPENCODE_LEAD_MODEL_REF } = require('./opencode-lead-provider');
 const nativeLeadLifetime = require('./native-lead-lifetime');
 
 const READINESS_BUDGET_MS = 12000;
@@ -110,6 +112,105 @@ function _nativePrepareReason(prepared) {
   return 'native_settings_prepare_failed';
 }
 
+// §5 D-5/D-6 (WP-2, S7): the FINITE failure vocabulary for a native adoption. At base both channels
+// collapsed into one generic reason, so a refused PROXY replay read as a settings failure. Every field is
+// a fixed literal or an EXACT member of a code table this build exports, so an exception message, token,
+// PEM or settings path can only ever map to `unknown`.
+const NATIVE_ADOPTION_STAGE_SETTINGS = 'settings';
+const NATIVE_ADOPTION_STAGE_PROXY = 'proxy';
+const NATIVE_ADOPTION_UNKNOWN = 'unknown';
+// The one generic reason a failed mTLS verification still returns to its caller (unchanged from base, so
+// the claim contract is compatible). It is a NAMED constant because the claim-failure branch below uses it
+// to recognise "the finite diagnostic for this failure was already emitted" — one shared verification, one
+// diagnostic — and a bare literal in two places would drift.
+const NATIVE_ADOPTION_GENERIC_REASON = 'native_settings_adopt_failed';
+// The reasons `oauth-proxy-supervisor.adoptLeadToken` can refuse with (`_normalizeLeadRegistration`,
+// `_registerLeadTokenIntoChild`) — plus `unknown` for anything else.
+const NATIVE_ADOPTION_PROXY_REASONS = new Set([
+  'proxy_unavailable', 'admin_rejected', 'revoked', 'invalid_token',
+  'invalid_binding', 'missing_exact_binding', 'conflicting_binding',
+]);
+// The two underlying codes worth naming as a CAUSE: a handoff that closed the listener this attempt was
+// talking to, and a token the registry already tombstoned. Exact matching only.
+const NATIVE_ADOPTION_CAUSES = new Set(['native_lead_listener_closed', 'lead_token_revoked']);
+
+// The settings allowlist is built from the EXPORTED code tables of the settings/client modules, with one
+// LITERAL specifier per table (never computed). Those modules are invariants of this build: a missing table
+// throws here rather than silently shrinking the allowlist.
+let _nativeAdoptionSettingsReasons = null;
+function _nativeSettingsReasons() {
+  if (!_nativeAdoptionSettingsReasons) {
+    _nativeAdoptionSettingsReasons = new Set([
+      ...Object.values(require('../native-lead-settings').NATIVE_LEAD_SETTINGS_CODES),
+      ...Object.values(require('../native-lead-tls').NATIVE_LEAD_TLS_CODES),
+      ...Object.values(require('../native-lead-settings-client').NATIVE_LEAD_SETTINGS_CLIENT_CODES),
+    ]);
+  }
+  return _nativeAdoptionSettingsReasons;
+}
+
+// §5 D-6: the CAUSE is the underlying condition, and it is read from every bounded carrier the two channels
+// actually use: a thrown error's `code`/`cause`, and the supervisor's `error` field (the refusal object
+// carries the listener/tombstone code there: `{ok:false, reason:'admin_rejected', error:'native_lead_listener_closed'}`).
+// Each candidate is EXACT-matched against the two-member allowlist, so a free-form exception message or any
+// other caller text can only ever map to `unknown` — nothing is echoed.
+function _adoptionCause(...values) {
+  for (const value of values) {
+    if (typeof value === 'string' && NATIVE_ADOPTION_CAUSES.has(value)) return value;
+  }
+  return NATIVE_ADOPTION_UNKNOWN;
+}
+
+function _adoptionSettingsReason(...values) {
+  const allowlist = _nativeSettingsReasons();
+  for (const value of values) {
+    if (typeof value === 'string' && allowlist.has(value)) return value;
+  }
+  return NATIVE_ADOPTION_UNKNOWN;
+}
+
+function _adoptionProxyReason(...values) {
+  for (const value of values) {
+    if (typeof value === 'string' && NATIVE_ADOPTION_PROXY_REASONS.has(value)) return value;
+  }
+  return NATIVE_ADOPTION_UNKNOWN;
+}
+
+/**
+ * §5 D-6 (WP-2, S7): the ONE bounded diagnostic per failed native adoption. `stage` says which channel
+ * refused, `reason` is an allowlisted code for that stage, and `cause` names the underlying condition when
+ * it is exactly one of the two known ones. Nothing here is interpolated from an exception, a token, a PEM
+ * or a settings reference; the session id is truncated like every other launcher line.
+ */
+function _emitNativeAdoptionFailure(sessionId, failure) {
+  const line = `[lead-route] native adoption failed session=${String(sessionId ?? '').slice(0, 64)}`
+    + ` stage=${failure.stage} reason=${failure.reason} cause=${failure.cause}\n`;
+  process.stderr.write(line);
+  return failure;
+}
+
+// The two channels, each with its own allowlist. A settings verification reports one bounded code and the
+// two vocabularies are disjoint, so it is offered to both.
+function _emitNativeSettingsFailure(sessionId, code) {
+  return _emitNativeAdoptionFailure(sessionId, {
+    stage: NATIVE_ADOPTION_STAGE_SETTINGS,
+    reason: _adoptionSettingsReason(code),
+    cause: _adoptionCause(code),
+  });
+}
+
+// `{ reason: [...], cause: [...] }` — the refusal's own code(s) vs the underlying condition code(s). The
+// lists are DELIBERATELY separate: only a refusal's own reason may name a reason, while `error` is eligible
+// as a cause ONLY — so free-form text can never be promoted into a semantic reason, and a reason word
+// arriving in `error` (e.g. `'revoked'`) stays `unknown`.
+function _emitNativeProxyFailure(sessionId, { reason = [], cause = [] } = {}) {
+  return _emitNativeAdoptionFailure(sessionId, {
+    stage: NATIVE_ADOPTION_STAGE_PROXY,
+    reason: _adoptionProxyReason(...reason),
+    cause: _adoptionCause(...cause),
+  });
+}
+
 // §6.3/§6.4 item 2: the fence every awaited boundary re-checks. It is the coordinator's PURE
 // current-generation accessor when the caller supplies one (the server's provider deps do); without
 // one this is a no-op fence, exactly as before, so existing callers keep their current semantics.
@@ -258,10 +359,15 @@ async function prepareLeadRoute(target = {}, deps = {}) {
   const { sessionId, agent, routeId, model, plannedGeneration, transitionId } = target;
   if (!Number.isSafeInteger(plannedGeneration) || plannedGeneration < 1) return { ok: false, reason: 'lead_generation_unavailable' };
 
+  // §5 R-1 / §6.1: an OpenCode lead speaks the claude wire (anthropic face), so route servability
+  // and the per-agent execution profile are asked of 'claude' -- never of 'opencode'. This is the
+  // ONE mapping (lib/lead-wire-agent.js); Claude and Codex map to themselves unchanged.
+  const wireAgent = leadWireAgent(agent);
+
   let r = target.resolvedRoute || null;
   if (!r) {
     try {
-      r = await readiness.resolveRoute({ route: routeId, model, agent, signal: target.signal });
+      r = await readiness.resolveRoute({ route: routeId, model, agent: wireAgent, signal: target.signal });
     } catch (err) {
       if (err instanceof DelegateError) {
         const map = {
@@ -289,7 +395,7 @@ async function prepareLeadRoute(target = {}, deps = {}) {
         routeId: r.deployment.routeId,
         providerId: r.deployment.providerId,
         wireModelId: r.deployment.wireModelId,
-        harness: agent === 'codex' ? 'codex-cli' : 'claude-code',
+        harness: wireAgent === 'codex' ? 'codex-cli' : 'claude-code',
         cliVersion: target.cliVersion,
         binaryPath: target.binaryPath,
         adapterVersion: target.adapterVersion || ADAPTER_VERSION,
@@ -361,11 +467,16 @@ async function prepareLeadRoute(target = {}, deps = {}) {
 
   // D-13: persist the token so a CTM restart that adopts this session can re-register it. A store
   // throw must never fail the launch -- the token is already live in the supervisor.
+  //
+  // §5 R-1 (WP-2): the row's `agent` column is the CLI WIRE the token serves, and the store's own
+  // contract admits exactly {'claude','codex'} (session-lead-route-store.js LEAD_AGENTS). An OpenCode
+  // lead speaks the claude wire, so it persists `agent: wireAgent` ('claude') -- never 'opencode',
+  // which the store refuses. Claude/Codex map to themselves, so their rows are byte-identical.
   try {
     const bindings = [{ alias: r.alias, wireModelId: r.deployment.wireModelId, harness, metadataRevision: r.deployment.factsRevision }];
     if (transitionId) {
       const staged = await store.stageSessionLeadToken({
-        ctmSessionId: sessionId, agent, routeId, alias: r.alias, model, token, bindings,
+        ctmSessionId: sessionId, agent: wireAgent, routeId, alias: r.alias, model, token, bindings,
         generation: plannedGeneration, transitionId, expectedRevision: target.expectedRevision,
         sourceGeneration: target.sourceGeneration, profileFingerprint: profile.fingerprint,
         factsRevision: r.deployment.factsRevision,
@@ -376,7 +487,7 @@ async function prepareLeadRoute(target = {}, deps = {}) {
         return { ok: false, reason: 'transition_superseded' };
       }
     } else if (typeof deps.recordLeadRouteLaunchOwnership === 'function') {
-      const recorded = await deps.recordLeadRouteLaunchOwnership({ ctmSessionId: sessionId, agent, routeId,
+      const recorded = await deps.recordLeadRouteLaunchOwnership({ ctmSessionId: sessionId, agent: wireAgent, routeId,
         alias: r.alias, model, token, bindings, profileFingerprint: profile.fingerprint,
         factsRevision: r.deployment.factsRevision, processGeneration: plannedGeneration,
         providerThreadId: target.providerThreadId || null, display: target.display || model,
@@ -387,7 +498,7 @@ async function prepareLeadRoute(target = {}, deps = {}) {
       }
     } else {
       await store.setSessionLeadToken({
-        ctmSessionId: sessionId, agent, routeId, alias: r.alias, model, token, bindings,
+        ctmSessionId: sessionId, agent: wireAgent, routeId, alias: r.alias, model, token, bindings,
         profileFingerprint: profile.fingerprint, factsRevision: r.deployment.factsRevision,
         processGeneration: plannedGeneration, transitionId: null,
         providerThreadId: target.providerThreadId || null,
@@ -413,6 +524,37 @@ async function prepareLeadRoute(target = {}, deps = {}) {
     return { ok: true, token, env, argsTransform, alias: r.alias, model, profile, ownership };
   }
 
+  // §5 R-3/R-4/R-6, §6.2 (WP-2): the OpenCode last step. Codex gets a `-c model_providers.ctm-lead`
+  // block and Claude gets ANTHROPIC_BASE_URL env; OpenCode gets a `ctm-lead` provider entry that the
+  // spawn path merges into the SAME OPENCODE_CONFIG_CONTENT blob its subagent pick and Wall-E MCP
+  // server ride (subagent-pick.opencodeLeadRouteProjection). The token rides env only; the model ref
+  // is the FIXED `ctm-lead/lead` so a prompted 1.x tab's resumed conversation keeps its ref (R-4).
+  if (agent === 'opencode') {
+    const env = { CTM_LEAD_TOKEN: token };
+    const configPatch = {
+      provider: {
+        [OPENCODE_LEAD_PROVIDER_ID]: opencodeLeadProvider({
+          proxyPort: port,
+          alias: r.alias,
+          wireModelId: r.deployment.wireModelId,
+          display: target.display || model,
+          contextTokens: r.deployment.contextTokens || null,
+          maxOutputTokens: r.deployment.maxOutputTokens || null,
+        }),
+      },
+      model: OPENCODE_LEAD_MODEL_REF,
+    };
+    const argsTransform = (args) => {
+      const stripped = stripModelFlags(args);
+      // §5 R-4 / probe P-R4: OpenCode 2.x's TUI rejects `--model`, so the ref is injected only on the
+      // v1 line. An unknown line (peekOpencodeLine -> null) records nothing else and appends no flag.
+      const peekLine = typeof deps.peekOpencodeLine === 'function' ? deps.peekOpencodeLine : require('../opencode-cli').peekOpencodeLine; // test seam
+      let line = null; try { line = peekLine(); } catch { line = null; }
+      return line === 'v1' ? [...stripped, '--model', OPENCODE_LEAD_MODEL_REF] : stripped;
+    };
+    return { ok: true, token, env, configPatch, argsTransform, alias: r.alias, model, profile, ownership };
+  }
+
   const env = { ..._claudeEnv(base, token, model), ...(profile.contextEnv || {}) };
   const argsTransform = (args) => [...stripModelFlags(args), '--model', model];
   return { ok: true, token, env, argsTransform, alias: r.alias, model, profile, ownership };
@@ -914,12 +1056,16 @@ async function adoptLeadRouteForSession(sessionId, deps = {}, actual = {}) {
               settingsRef: nativeFields.settingsRef,
             });
             if (!adoptedSettings || adoptedSettings.ok !== true || !adoptedSettings.lease) {
-              return { ok: false, reason: 'native_settings_adopt_failed' };
+              // §5 D-6 (WP-2, S7): the client's OWN exported code is the reason; anything else is `unknown`.
+              _emitNativeSettingsFailure(sessionId, adoptedSettings && adoptedSettings.code);
+              return { ok: false, reason: NATIVE_ADOPTION_GENERIC_REASON };
             }
             lease = adoptedSettings.lease;
           } catch (error) {
-            process.stderr.write(`[lead-route] native settings adopt failed session=${sessionId}: ${String((error && error.message) || error).slice(0, 200)}\n`);
-            return { ok: false, reason: 'native_settings_adopt_failed' };
+            // §5 D-6 (WP-2, S7): a throwing verification reports its bounded CODE — never `error.message`,
+            // which is exactly how a settings path or a caller string used to reach the log.
+            _emitNativeSettingsFailure(sessionId, error && error.code);
+            return { ok: false, reason: NATIVE_ADOPTION_GENERIC_REASON };
           }
           let adoptedNative;
           try {
@@ -933,15 +1079,32 @@ async function adoptLeadRouteForSession(sessionId, deps = {}, actual = {}) {
               nativeSettingsRef: nativeFields.settingsRef,
             });
           } catch (error) {
-            process.stderr.write(`[lead-route] native auth adopt failed session=${sessionId}: ${String((error && error.message) || error).slice(0, 200)}\n`);
+            // §5 D-6/DEFENSIVE: production `adoptLeadToken` RETURNS a bounded refusal for an admin failure,
+            // so a thrown replay is an unexpected transport/registration throw, not the live handoff path
+            // (that one is the `!ok` refusal below). A thrown error's `code` is a bounded control code, so
+            // it may name the reason or the cause; its `cause`/`message` are only ever cause CANDIDATES, and
+            // the EXACT allowlist match means no free-form text can reach the line.
+            _emitNativeProxyFailure(sessionId, {
+              reason: [error && error.code],
+              cause: [error && error.code, error && error.cause, error && error.message],
+            });
             // §7.3 (gen-7 item 3): the mTLS settings client already granted this attempt a committed
             // adopted lease. A refused/THROWN proxy replay must carry that partial resource through the
             // SHARED verification failure result so the lifetime's last-claim path can release its client
             // tracking exactly once — dropping it here was the reproduced leak.
-            return { ok: false, reason: 'native_settings_adopt_failed', lease, partialLease: lease };
+            return { ok: false, reason: NATIVE_ADOPTION_GENERIC_REASON, lease, partialLease: lease };
           }
           if (!adoptedNative?.ok) {
-            return { ok: false, reason: 'native_settings_adopt_failed', lease, partialLease: lease };
+            // §5 D-6: the supervisor's own refusal reason (`admin_rejected`, `revoked`, …) is kept VERBATIM
+            // when it is in vocabulary, and its `error` field is read for the CAUSE ONLY: the real
+            // supervisor reports `{ok:false, reason:'admin_rejected', error:'native_lead_listener_closed'}`,
+            // which is exactly the handoff condition an operator needs. Exact match or `unknown`; the raw
+            // `error` text is never printed and never promoted to a reason.
+            _emitNativeProxyFailure(sessionId, {
+              reason: [adoptedNative && adoptedNative.reason, adoptedNative && adoptedNative.code],
+              cause: [adoptedNative && adoptedNative.error],
+            });
+            return { ok: false, reason: NATIVE_ADOPTION_GENERIC_REASON, lease, partialLease: lease };
           }
           // The ACTUAL adopted lease is handed to the claim set (the record binds it), never kept here.
           return { ok: true, lease };
@@ -954,7 +1117,12 @@ async function adoptLeadRouteForSession(sessionId, deps = {}, actual = {}) {
         expectedEndpoint: configuredEndpoint,
       });
       if (!claim.ok) {
-        process.stderr.write(`[lead-route] native auth adopt refused session=${sessionId}: ${String(claim.reason || 'lifetime_claim_failed').slice(0, 64)}\n`);
+        // §5 D-6 (WP-2, S7): the finite stage/reason/cause line was already emitted by the verification
+        // that failed, so this generic refusal line is reserved for claim-state refusals that never reached
+        // it. One diagnostic per failure — never the same failure twice under two different names.
+        if (claim.reason !== NATIVE_ADOPTION_GENERIC_REASON) {
+          process.stderr.write(`[lead-route] native auth adopt refused session=${sessionId}: ${String(claim.reason || 'lifetime_claim_failed').slice(0, 64)}\n`);
+        }
         return null;
       }
       // §6.4: THIS attempt's own current/abort state is what decides whether its claim survives — checked
@@ -981,7 +1149,12 @@ async function adoptLeadRouteForSession(sessionId, deps = {}, actual = {}) {
         harness: 'claude-code', providerThreadId,
       });
     } catch (error) {
-      process.stderr.write(`[lead-route] native auth adopt failed session=${sessionId}: ${String((error && error.message) || error).slice(0, 200)}\n`);
+      // §5 D-6 (WP-2, S7): the legacy (non-mTLS) replay reports the same finite vocabulary — its exception
+      // text is never printed here either, so no branch of this function can widen a diagnostic.
+      _emitNativeProxyFailure(sessionId, {
+        reason: [error && error.code],
+        cause: [error && error.code, error && error.cause, error && error.message],
+      });
       return null;
     }
     if (!adoptedNative?.ok) return null;

package/template/coding-task-manager/lib/session-create/native-lead-lifetime.js

@@ -322,10 +322,32 @@ async function claimLeadRouteAdoption(options = {}) {
   const key = _coalesceKey(tuple);
   if (!record.adoption || record.adoption.key !== key) record.adoption = { key, promise: null };
   if (!record.adoption.promise) {
+    // §5 D-5 (WP-2, S8, race 2): the client-tracking release latch belongs to the ADMISSION ATTEMPT, not to
+    // the record — and the settings client publishes ONE lease per `adopt()` call, so a NEW verification is
+    // about to obtain its OWN partial lease. The OLD attempt's release is therefore a BARRIER this
+    // verification waits behind: `_releaseAbandonedLease` coalesces on `record.inflightClientRelease`, so a
+    // fresh verification that ran while that release was in flight would join the OLD release, return, and
+    // leak its own lease (the reproduced overlap: firstLeaseReleases=1, secondLeaseReleases=0). The latch is
+    // re-armed only AFTER the barrier settles, and a failure the old release recorded keeps its obligation.
+    const releaseBarrier = record.inflightClientRelease || null;
     // ONE operation per full tuple. The verify result carries the ACTUAL lease this attempt set is
     // about to attach, so the record never binds a lease the verification did not vouch for.
     record.adoption.promise = Promise.resolve()
-      .then(() => (typeof options.verify === 'function' ? options.verify() : { ok: true }))
+      .then(async () => {
+        if (releaseBarrier) {
+          try { await releaseBarrier; }
+          catch (error) {
+            // REPORT: the earlier release retained its OWN obligation on the record; waiting for its failure
+            // is not swallowing it, and this attempt must still get its own release.
+            void error;
+          }
+        }
+        // §6.1 (gen-6 bug C): a host PROVEN gone while we waited is refused BEFORE this attempt borrows
+        // anything — the retired/exit-proof latch is re-checked here, not only after the await below.
+        if (record.retired || record.exitProof) return { ok: false, reason: LIFETIME_CODES.RECORD_RETIRED };
+        record.clientTrackingReleased = false;
+        return typeof options.verify === 'function' ? options.verify() : { ok: true };
+      })
       .then(
         // §7.3 (gen-7 item 3): a FAILED result is carried through VERBATIM — never normalized down to
         // `{ok:false, reason}` — because the attempt may already hold a partially obtained adopted lease
@@ -341,12 +363,17 @@ async function claimLeadRouteAdoption(options = {}) {
     // §7.3 (gen-7 item 3): the attempt may have obtained a lease before the proxy replay refused. That
     // partial resource is carried on the SHARED result and released exactly ONCE — by the LAST claimant,
     // through the same shared abandonment path — with `removeFiles:false` (never a survivor's files or row).
+    // §5 D-5 (WP-2, S8): `verificationFailed` is what keeps that same path off the GRANT phase. A refused
+    // or aborted verification never replayed a grant, so the token this record names still belongs to the
+    // SURVIVING host — revoking it is exactly the live failure this package repairs.
     const partialLease = verification.lease || verification.partialLease || options.lease || null;
-    const abandoned = await _abandonClaim(record, claimId, { partialLease });
+    const abandoned = await _abandonClaim(record, claimId, { partialLease, verificationFailed: true });
     return {
       ok: false,
       reason: (verification && verification.reason) || LIFETIME_CODES.ADOPTION_FAILED,
       claimDropped: true,
+      grantRevoked: abandoned.grantRevoked === true,
+      grantRetained: abandoned.grantRetained === true,
       associationRetained: abandoned.associationRetained !== false,
     };
   }
@@ -823,8 +850,14 @@ async function releaseLeadRouteLifetime(capture, options = {}) {
  *   * otherwise the exact newly replayed grant is revoked once and the attempt's partial lease releases its
  *     CLIENT tracking once (`removeFiles:false`): a survivor's files and its durable row are never touched.
  * A failed cleanup keeps its obligation and stays reachable for a caller-driven retry.
+ *
+ * §5 D-5 (WP-2, S8): `verificationFailed: true` marks the ONE caller that is NOT "this attempt replayed a
+ * grant" — a refused or aborted verification. The terminal/attached guards above keep their meaning; for
+ * the LAST claimant the GRANT phase is then skipped entirely and the borrowed partial lease releases its
+ * client tracking exactly once, so a failed adoption can never unauthenticate the survivor it borrowed
+ * from. Every other caller keeps the base cleanup bit-for-bit.
  */
-async function _abandonClaim(record, claimId, { partialLease = null } = {}) {
+async function _abandonClaim(record, claimId, { partialLease = null, verificationFailed = false } = {}) {
   const claim = record.claims.get(claimId);
   if (claim) record.claims.delete(claimId);
   if (record.attachedClaimId === claimId) record.attachedClaimId = null;
@@ -836,6 +869,25 @@ async function _abandonClaim(record, claimId, { partialLease = null } = {}) {
     const discharged = _dischargeIfComplete(record);
     return { ok: true, claimDropped: true, terminal: true, discharged, associationRetained: !discharged };
   }
+  if (verificationFailed === true) {
+    // §5 D-5: no grant phase, no row phase — this attempt borrowed the survivor's identity and never
+    // created that grant. Only the partial client-side tracking it obtained is released, exactly once.
+    // The lease released here is ONLY the one THIS failed verification carried (`partialLease`): the
+    // record's own `record.lease` belongs to an EARLIER, possibly still-live attempt, and reusing it would
+    // release tracking this attempt never obtained.
+    try { await _releaseAbandonedLease(record, partialLease); }
+    catch (error) {
+      void error; // REPORT: `_releaseAbandonedLease` retained the obligation (and the record), so the failure stays observable
+      return { ok: false, code: 'lifetime_client_release_failed', claimDropped: true, verificationFailed: true,
+        grantRevoked: false, grantRetained: true, filesRetained: true, associationRetained: true };
+    }
+    // Nothing else references an unattached adopted record, so its association goes: the NEXT attempt must
+    // start from a FRESH record (and a fresh release latch) instead of inheriting a released one. The cached
+    // `record.adoption` is deliberately NOT cleared here — it belongs to whoever started it.
+    const dropped = _dropUnreferencedRecord(record);
+    return { ok: true, claimDropped: true, verificationFailed: true, grantRevoked: false, grantRetained: true,
+      filesRetained: true, associationRetained: !dropped };
+  }
   const grant = await _runPhase(record, 'grantRevoked', record.grantRevoke);
   if (!grant.ok) {
     _retainObligation(record, { code: 'grant_revoke_failed' });

package/template/coding-task-manager/lib/session-create/opencode-lead-provider.js

@@ -0,0 +1,50 @@
+'use strict';
+
+// WP-2 (docs/opencode-model-selection-round-2-shared-route-logic-2026-10-30.html §5 R-3/R-4/R-6,
+// §6.2): the OpenCode twin of Codex's `model_providers.ctm-lead` -c block and Claude's
+// ANTHROPIC_BASE_URL env. An OpenCode routed lead reaches CTM's model proxy as ONE custom AI-SDK
+// provider entry inside its inline OPENCODE_CONFIG_CONTENT -- CTM never writes ~/.config/opencode/*
+// (R-6). The entry points @ai-sdk/anthropic at the proxy's anthropic face (D-1: OpenCode leads speak
+// the claude wire) and carries the lead token ONLY as `{env:CTM_LEAD_TOKEN}`: OpenCode's own config
+// loader substitutes the env value, so the literal token is never written into config text (probe
+// P-R1/P-R2 confirm this on the installed binary).
+//
+// The model ref is FIXED at `ctm-lead/lead` (R-4): the route and the wire model live in the provider
+// entry (`options.baseURL` alias, `models.lead.id`), so a routed->routed switch on a prompted 1.x tab
+// keeps the ref the resumed conversation is pinned to and only moves where it points.
+//
+// PURE: no fs, no env reads. Same input -> same output.
+
+const OPENCODE_LEAD_PROVIDER_ID = 'ctm-lead';
+const OPENCODE_LEAD_MODEL_REF = 'ctm-lead/lead';
+
+/**
+ * @param {{ proxyPort: number|string, alias: string, wireModelId: string, display?: string,
+ *           contextTokens?: number|null, maxOutputTokens?: number|null }} [spec]
+ * @returns {{ npm:string, name:string, options:{baseURL:string, authToken:string},
+ *             models:{ lead:{ id:string, name:(string|undefined), limit?:{context:number, output:number} } } }}
+ */
+function opencodeLeadProvider({ proxyPort, alias, wireModelId, display, contextTokens, maxOutputTokens } = {}) {
+  return {
+    npm: '@ai-sdk/anthropic',
+    name: 'CTM lead route',
+    options: {
+      baseURL: `http://127.0.0.1:${proxyPort}/r/${alias}/v1`,
+      authToken: '{env:CTM_LEAD_TOKEN}',
+    },
+    models: {
+      lead: {
+        id: wireModelId,
+        name: display,
+        // Probe P-R3 (scripts/opencode-lead-route-probe.js, OpenCode 1.19.5): a `limit` block must carry
+        // BOTH keys -- `limit.context` alone is refused ("Missing key ...limit.output") and the TUI exits
+        // before any request. So `limit` is emitted only when the route's deployment facts know both
+        // (shared/coding-model-deployment.js contextTokens/maxOutputTokens); otherwise it is omitted and
+        // the proxy still enforces the route's own caps.
+        ...(contextTokens && maxOutputTokens ? { limit: { context: contextTokens, output: maxOutputTokens } } : {}),
+      },
+    },
+  };
+}
+
+module.exports = { opencodeLeadProvider, OPENCODE_LEAD_PROVIDER_ID, OPENCODE_LEAD_MODEL_REF };