@senpi/runtime 3.0.65 → 3.0.66

package/dist/deploy/orchestrator.js

@@ -36,63 +36,83 @@ const CREATE_POLL_MS = 10_000;
 const OBSERVE_POLL_MS = 5_000;
 const STEP_ORDER = ["reconcile", "preflight", "create", "install", "observe"];
 /**
- * Backend codes that mean "the name is unusable", not "the deploy is unfundable" — see
- * {@link isNameRejection}. Spelled out one per entry rather than packed into a character class
- * (`SERR05[568]`) because the reader who arrives here arrives holding a code: a grep for the exact
- * string they were handed has to land on this list.
- *
- * SERR083 belongs here despite its generic text ("Custom strategy creation failed unexpectedly.
- * Retry with the same payload."), which carries neither a name-ish code nor the word "name": a
- * strategy stuck in PENDING_FUNDING keeps holding its strategyName, and every create reusing that
- * name 500s until the record expires ~15 minutes later. Retrying the SAME payload — precisely what
- * the error itself advises — can never clear it; dropping the name clears it instantly. Observed on
- * a real deploy, two calls 3.6s apart at the same $693 budget:
- *     {initialBudget: 693, strategyName: "vanguard-long"}  → SERR083
- *     {initialBudget: 693}                                 → success
- * It also failed at $100 with the name, ruling out any funding cause. So do not drop this entry on
- * the grounds that the message reads like a generic backend failure — that reading is the bug, and
- * it already cost this guard once when the money path moved out of deploy.py.
+ * Backend codes that mean "the name is unusable AND nothing was created", so retrying unnamed is
+ * free — see {@link isNameRejection}. Spelled out one per entry rather than packed into a character
+ * class (`SERR05[568]`) because the reader who arrives here arrives holding a code: a grep for the
+ * exact string they were handed has to land on this list.
+ *
+ * All three are `INVALID_ARGUMENT` in the MCP's registry (`senpi-error-registry.ts:155-167`):
+ * deterministic input refusals. 055 is the active-name collision; 056 and 058 are the length and
+ * whitespace rules, enforced by zod before the request ever reaches the backend. The backend
+ * rejected the input and created nothing, so a retry cannot double-fund.
+ *
+ * SERR083 was here and is now DELIBERATELY EXCLUDED (decision, 2026-08-11). Its text is generic
+ * ("Custom strategy creation failed unexpectedly. Retry with the same payload.") and the registry
+ * classes it UNAVAILABLE/`retryable` — meaning the outcome is unknown and a wallet may exist behind
+ * it. The case it was added for is real: a strategy still holding its name made every named create
+ * fail, and two calls 3.6s apart at the same $693 budget went named → SERR083, unnamed → success.
+ * But that unblock is bought with a retry that funds a SECOND wallet whenever the first create did
+ * land, and the runtime has a cheaper route to the same outcome: reconcile reads the live
+ * strategies and adopts an initializing record BY NAME before the create call is ever made
+ * (`awaitingActive`), which is exactly the state that produces SERR083. deploy.py, where this guard
+ * came from, had no such step — that is why the code list travelled here with 083 in it. So the
+ * defensive arm was chosen: no retry, and the operator gets the backend's real words (item 1) in
+ * place of "backend returned no strategyId".
  */
-const NAME_REJECTION_CODES = ["SERR055", "SERR056", "SERR058", "SERR083"];
+const NAME_REJECTION_CODES = ["SERR055", "SERR056", "SERR058"];
+/** The `SERRnnn` token in a code or a message, upper-cased; `undefined` when there is none. */
+function readSerrCode(text) {
+    return text?.toUpperCase().match(/SERR\d{3}/)?.[0];
+}
 /**
- * True when a failed create is the backend refusing the wallet NAME, so retrying unnamed works.
- *
- * The bare-word `name` arm is deliberately kept alongside the enumerated codes: every code above
- * was learned from an incident, one at a time, and this arm is what covers the next one before it
- * has a number. Weigh dropping it against the failure that leaves: a name collision reported as a
- * hard deploy failure, stranding the user for ~15 minutes with no action that helps.
- *
- * What a false positive COSTS depends on whether the create it retries actually landed, and this
- * predicate cannot tell — nor can its caller, in every case:
- *
- *   - The backend said no. The ordinary shape, and the harmless one: nothing was created, so the
- *     retry costs legibility (the wallet lands under a backend-assigned name) and nothing else. It
- *     carries the same budget and the same attribution, so it cannot change what gets funded.
- *   - Nobody knows. `callCreate` turns EVERY throw into `success: false`, so a transport error
- *     raised after the request was already written — a socket reset, a 502, a gateway-injected
- *     transport failing mid-call (senpi/client.ts `callToolInner`) — arrives here shaped exactly
- *     like a refusal. If its text matches, the retry runs against a create that may already have
- *     funded a wallet, and funds a second one beside it. A call abandoned at its deadline is one
- *     member of this class, not the whole of it — merely the one `callCreate` flags (`aborted`).
- *
- * Nothing excludes that second class today, and no arm of this predicate can. The deadline text is
- * fixed and carries neither a code nor "name" (`abortedCallError`), but a transport error's text is
- * authored outside this repo and the transport is called with the create's own arguments — the
- * literal key `strategyName` among them — so any transport that echoes the failed request matches.
- * This exposure is unchanged from the regex this replaced, byte for byte; it is written down here
- * because the fix is not the obvious one. The exclusion worth building is "the failure came from a
- * THROW", not `!aborted` — and even that needs care, because a throw raised BEFORE the request went
- * out (connection refused) is a case where retrying is perfectly safe. Telling pre-send from
- * post-send is the actual work, and the reason it belongs in its own change rather than here.
- *
- * Matching stays case-INSENSITIVE on the codes as well as the word, which the regex this replaced
- * was: the backend spells them upper-case today, and nothing here is worth losing the unblock over
- * if some relay downcases a message. (deploy.py compared the codes case-sensitively; that is the
- * one deliberate difference, and it is in the direction of firing more often, never less.)
+ * True when a failed create is the backend refusing the wallet NAME **and nothing was created**, so
+ * retrying unnamed works and cannot cost a second funded wallet.
+ *
+ * Keyed on the CODE, not on prose. Reading the code was impossible until the client learned to
+ * parse the error envelope: a backend refusal has no `data` key, so the old flat `data.message` read
+ * returned `undefined` for every one of them and this predicate was called with `""`. That made the
+ * safe arm — the enumerated backend codes — dead, while the dangerous arm stayed live: `callCreate`
+ * shapes every THROW into `{ success: false, message: errorText(err) }`, and a transport error's
+ * text is authored outside this repo. The predicate the codes were written for could never fire;
+ * the only failures that could reach the retry were the ones whose outcome nobody knows.
+ *
+ * Three arms, in this order:
+ *
+ *   1. **A throw is never a name rejection.** `callTool` throws only on an RPC fault
+ *      (`senpi/client.ts` `callToolInner`); every backend refusal RESOLVES as an error envelope. So
+ *      a throw here means transport, and a transport failure raised after the request was written —
+ *      socket reset, 502, a gateway-injected transport failing mid-call — may have already created
+ *      and funded a wallet. Retrying funds a second one beside it. Refusing on `threw` is stricter
+ *      than telling pre-send from post-send (a connection refused before the request left is safe to
+ *      retry), and it is deliberately the strict version: the give-up costs one legible name, the
+ *      false positive costs a funded wallet. A deadline abort is one member of this class, not the
+ *      whole of it — `aborted` flags only the member `callCreate` recognises.
+ *   2. **A SERR code decides, wherever it is written.** The structured `errorCode` first, then the
+ *      message — because the zod-enforced rules (056 length, 058 whitespace) arrive as
+ *      `INVALID_ARGUMENT` with the SERR code in the TEXT (`classifyError` → `InvalidArgumentError`),
+ *      while a backend-mapped refusal carries it structurally. If a code is found, it decides
+ *      alone: an out-of-list code (SERR083, SERR045, SERR037) is a NO, and the text is not consulted
+ *      afterwards, so a non-name refusal can never sneak in on a stray word.
+ *   3. **Text, only when there is no code at all.** So an uncoded future refusal is not silently
+ *      unmatchable — the reason the bare-word arm existed. It matches the WORD `name`
+ *      (`\bname\b`), not the substring: `HOSTNAME`, `USERNAME`, `UNNAMED` and an echoed
+ *      `strategyName` key all fail the word boundary, which is the false-positive class the
+ *      follow-up ticket named. And because arm 1 already returned, this arm can only ever see a
+ *      RETURNED failure — the backend answered, so nothing was created — which is why widening it
+ *      cannot re-open the outcome-unknown hole.
+ *
+ * Code matching is case-INSENSITIVE, as the regex this replaced was: the backend spells them
+ * upper-case today, and nothing here is worth losing the unblock over if some relay downcases a
+ * message. (deploy.py compared the codes case-sensitively; that is the one deliberate difference,
+ * and it is in the direction of firing more often, never less.)
  */
-function isNameRejection(message) {
-    const upper = message.toUpperCase();
-    return NAME_REJECTION_CODES.some((code) => upper.includes(code)) || upper.includes("NAME");
+function isNameRejection(result) {
+    if (result.threw)
+        return false;
+    const code = readSerrCode(result.errorCode) ?? readSerrCode(result.message);
+    if (code)
+        return NAME_REJECTION_CODES.includes(code);
+    return /\bname\b/i.test(result.message ?? "");
 }
 const ABANDONED_DETAIL = "abandoned at the deploy deadline — the job exceeded its wall-clock cap";
 /** Ticks that prove the scanner executed; `ok` literally means "found a signal", so heartbeat counts. */
@@ -109,6 +129,25 @@ function isFreshTick(row, sinceMs) {
         row.lastRunFinishedAt >= sinceMs // H3: pre-install telemetry survives a re-mint
     );
 }
+/**
+ * Did THIS row record a run of its own since the install — regardless of how it is scheduled?
+ *
+ * Kept separate from {@link isFreshTick}, which is the GATE and must not change: its external
+ * branch short-circuits on `lastAliveAt` before reading these fields, deliberately, because a
+ * watch-only external scanner can never record a run status and demanding one would make its
+ * deploy unable to ever reach `live`. This is the RENDER classifier — it decides which of the two
+ * claims the observe line is allowed to make, and it must answer for the row in front of it rather
+ * than for its schedule mode, since an external scanner that posts non-empty signals does commit
+ * run telemetry.
+ *
+ * Merging the two would be the bug: the gate would start demanding what this asks for.
+ */
+function recordedFreshRun(row, sinceMs) {
+    return (row.lastRunStatus !== null &&
+        OBSERVED_RUN_STATUSES.includes(row.lastRunStatus) &&
+        row.lastRunFinishedAt !== null &&
+        row.lastRunFinishedAt >= sinceMs);
+}
 function isFreshError(row, sinceMs) {
     return (row.lastRunStatus === "error" &&
         row.lastRunFinishedAt !== null &&
@@ -253,8 +292,9 @@ function buildAdoptedWalletDetail(pkg, inst, matched, wallet, budget, matchedBy
  * or something this verb does not recognise.
  *
  * Polling these is the bug this builder exists to prevent: a PAUSED strategy never becomes ACTIVE on
- * its own, so waiting on it burns the whole `--max-wait` and then reports "wallet still funding",
- * which is both untrue and unactionable. The next step is computed from the status actually read,
+ * its own, so waiting on it burns the whole `--max-wait` and then reports the bounded-wait outcome
+ * — "re-run to resume, reconciliation waits for it to reach ACTIVE" — which is unactionable on a
+ * status that will never get there. The next step is computed from the status actually read,
  * and the non-destructive option always leads.
  */
 function buildNotDeployableRefusal(matched, instance, pkg, budget) {
@@ -782,10 +822,10 @@ function describeUnwiredPhase(phase, createdByThisJob) {
 }
 /**
  * A strategy the ACTIVE poll watched go DEAD. Terminal, so the poll stops on it — and the claim it
- * replaces is the point: `buildCreatePendingDetail` would have said "wallet still funding … never
- * creating a second wallet", and on this input neither half holds. It is not funding, and reconcile
- * filters dead statuses on BOTH match routes, so a re-run creates and funds a fresh wallet beside
- * it. The status only ever survived in the step evidence; here it leads the claim.
+ * replaces is the point: `buildCreatePendingDetail` would have said "waits for it to reach ACTIVE,
+ * never creating a second wallet", and on this input neither half holds. It never reaches ACTIVE,
+ * and reconcile filters dead statuses on BOTH match routes, so a re-run creates and funds a fresh
+ * wallet beside it. The status only ever survived in the step evidence; here it leads the claim.
  */
 function buildCreateDeadDetail(pkg, budget, live, createdByThisJob) {
     const origin = polledWalletOrigin(createdByThisJob);
@@ -811,8 +851,8 @@ function buildCreateDeadDetail(pkg, budget, live, createdByThisJob) {
  * there — PAUSED, mid-teardown, or one this build does not recognise.
  *
  * Only {@link INITIALIZING_STATUSES} resolve on their own, so only they are worth waiting on;
- * everything else burned the full `--max-wait` and was then reported as "wallet still funding",
- * which is false for every member of this set.
+ * everything else burned the full `--max-wait` and was then reported with the bounded-wait detail's
+ * "re-run; reconciliation waits for it to reach ACTIVE" promise, which none of them will honour.
  *
  * The REMEDIATION branches, and must: the create step gets no D-6 rollback (only an install failure
  * rolls a wallet back), so a wallet this job created and funded seconds ago is still live when this
@@ -855,8 +895,13 @@ closeOffer) {
         `or whether waiting would have helped. Read-only triage FIRST: ${statusPy}, ` +
         `\`openclaw senpi deploy status\`, or MCP \`strategy_get\` with strategy_id "${live.id}" (that tool takes ` +
         `the id, never a wallet address). Then ${rerun} once it is ACTIVE. Do NOT close or recreate this ` +
-        `strategy to "start clean": ${itsFunded(live.totalFunded)} is not proven stranded, and closing a ` +
-        `strategy that was seconds from ACTIVE throws the wallet away.`);
+        // "seconds from ACTIVE" stood here — an unprovable duration on a rendered surface, the same
+        // class deleted from the bounded-wait outcome. Nothing here read how far along this strategy
+        // is; what this payload DOES establish is that the status is unclassifiable, which is an
+        // argument for not closing on its own.
+        `strategy to "start clean": ${itsFunded(live.totalFunded)} is not proven stranded, and a status ` +
+        `this build cannot place is not evidence the strategy is finished — closing it would throw away ` +
+        `a wallet nothing here showed to be done.`);
 }
 /**
  * The start-over clause for a PAUSED poll, scoped to this job's whole INTENT, never to a mid-loop
@@ -918,10 +963,246 @@ function polledWalletTarget(live) {
         ? `wallet ${live.strategyWalletAddress}`
         : `strategy id ${live.id} (its wallet address is unreadable)`;
 }
-function buildCreatePendingDetail(pkg, budget, waitedSec) {
-    return (`wallet still funding after ${waitedSec}s — re-run \`${resumeCommand(pkg.dir, budget)}\` to resume ` +
-        `(nothing is lost; reconciliation matches this strategy again and waits for it to reach ACTIVE, ` +
-        `never creating a second wallet)`);
+/**
+ * What the last poll read said about the record, and nothing else.
+ *
+ * Both facts are quoted from the `strategy_list` row the poll already holds — no extra call, no
+ * interpretation. An absent row and an unreadable field are named as such rather than filled in:
+ * this whole surface exists because "wallet still funding" was asserted over states nobody read.
+ *
+ * The status carries one qualifier, and it is a classification this repo owns rather than a
+ * measurement: membership of `INITIALIZING_STATUSES`, the list whose entire definition is "statuses
+ * that resolve on their own, so a bounded poll is the right response" (`senpi/strategy-status.ts`).
+ * It is provable by a lookup against a list in this repo, it needs no hedge, and it is the reason
+ * waiting — and re-running to keep waiting — is the correct next step on that payload.
+ *
+ * Nothing here says how long initialization takes. The backend owns that; a figure measured once
+ * somewhere else is not something this deploy read, cannot be checked from here, and cannot be
+ * acted on — so the only durations on this surface are the wait this job bounded and the record's
+ * age off `createdAt`.
+ */
+function polledRecordRead(live, nowMs) {
+    if (!live) {
+        return "the last `strategy_list` read returned no row for it, so its status and age are unread here";
+    }
+    // The empty-status arm is unreachable through `runDeploy`: an empty status is neither ACTIVE nor
+    // initializing, so `pollUntilActive`'s non-initializing guard reports the step `failed` through
+    // `buildCreateNotDeployableDetail` before the deadline branch can run, and reconcile refuses the
+    // same value at the match seam (`buildNotDeployableRefusal`). Kept anyway: `status` is a string
+    // this process read off the backend, this builder is one guard-reorder away from seeing an empty
+    // one, and the alternative rendering is the blank in "it reads status  and was created 630s ago".
+    const status = live.status
+        ? `status ${live.status.toUpperCase()}${isInitializing(live.status) ? " (an initializing status this wait is for)" : ""}`
+        : "NO STATUS on that read";
+    const createdMs = Date.parse(live.createdAt ?? "");
+    if (Number.isNaN(createdMs)) {
+        return `it reads ${status}, age UNREADABLE (the row carried no parseable createdAt)`;
+    }
+    const ageSec = Math.max(0, Math.round((nowMs - createdMs) / 1000));
+    return `it reads ${status} and was created ${ageSec}s ago`;
+}
+/**
+ * Is the NAME route even open for this row — i.e. does it carry the name a re-run will look up?
+ *
+ * Reconcile has two match routes: `strategyName` (case-folded, non-empty on both sides) and a
+ * create key journaled by THIS box. This is the name comparison out of `resolveInstanceBinding`,
+ * and it is a NECESSARY condition for that route, never a sufficient one. Reconcile applies three
+ * further filters this function cannot see, all of them about rows other than the one held here:
+ * it drops `DEAD_STATUSES` before comparing, it refuses when the surviving list carries a foreign
+ * `skillName` stamp (`E_WALLET_OWNED_BY_OTHER_PACKAGE`), and it refuses when more than one
+ * candidate answers to the name (`E_STATE_AMBIGUOUS_WALLETS`). All three are executed and all three
+ * create nothing — so a `false` here means "the name route is closed", while a `true` means only
+ * "it is not closed by the name", which is why the sentence it feeds states its outcome as
+ * conditional rather than as a fact.
+ *
+ * A `false` is not hypothetical: the unnamed create retry sends no `strategyName` at all (it is
+ * `.optional()` in the MCP schema), so the backend names that wallet itself and the row comes back
+ * under a name this package will never derive.
+ */
+function reconcileCanMatchByName(wantedName, live) {
+    const wanted = wantedName.trim().toLowerCase();
+    return wanted !== "" && (live.strategyName ?? "").trim().toLowerCase() === wanted;
+}
+/**
+ * The money invariant, and the executed boundary it holds at.
+ *
+ * `resolveInstanceBinding` matches by NAME first, and a non-empty match ends in `applyCandidates` —
+ * which adopts, waits or refuses and has no create in it. Only `gateOrCreate` sets `needsWallet`,
+ * and it is reached only when NO live row answers to the name this deploy derives. So this is not a
+ * prediction about the row in hand: it is a property of the name route, and it was executed rather
+ * than reasoned — 180 second `runDeploy`s over a live row under that name (status × stamp × sibling
+ * count × address readable/blank × journal present/absent) created nothing, split across `ok` binds
+ * and three different refusal codes, and so did every payload where this row was dead or under
+ * another name while a live row still answered to the derived one.
+ *
+ * WHICH of those answers a re-run gives is exactly what this builder cannot know, so it is not
+ * stated. The create count is the part that spends money, and it is the part that holds.
+ *
+ * `carriesTheName` is the read: this row's own name is the one a re-run looks up. Without a row
+ * (the poll's last read returned none) the invariant still holds — it is about the name, not about
+ * this row — so the clause that asserts something about the row is simply dropped.
+ *
+ * Both halves are scoped to THIS strategy, and that scope is the whole of what the boundary
+ * covers. The command is package-wide: `deploy` runs every sleeve, and a sleeve with no live row
+ * under its own derived name gets a wallet — correct behaviour, and it means a sentence whose
+ * subject is the command is false on any multi-sleeve package. Executed on a two-sleeve package
+ * (`main` 0.6 / `scalp` 0.4, budget 250) whose `main` sleeve renders this very sentence: re-running
+ * exactly the command it names creates `spider-scalp` at `initialBudget: 100` beside a live sibling
+ * row, and again when that row is dead or absent (only an ours-stamped sibling refuses) — while
+ * `spider-main` is bound, not created, on all four. So the promise is stated per strategy: this
+ * strategy is bound or stopped, and no second wallet appears for it.
+ */
+function noSecondWalletWhileNamedLive(resume, carriesTheName) {
+    const lead = carriesTheName
+        ? `This strategy carries the name a re-run looks up, and while a live strategy still answers to ` +
+            `that name, `
+        : `While a live strategy answers to the name a re-run looks up, `;
+    return (`${lead}re-running ${resume} binds this strategy to what it finds there or stops with a code — ` +
+        `never creating a second wallet for it.`);
+}
+/**
+ * The same invariant read from the other side, for a row the name route cannot reach.
+ *
+ * The unnamed create retry sends no `strategyName`, so the backend names that wallet and the name
+ * this package derives will never hit it. The protection above is about that name, and this row is
+ * not under it — executed: names differ, journal absent, and the stamp missing from the read
+ * (starvation; both create calls send `skillName: pkg.id`, `:3252` and `:3294`, so a stampless read
+ * is a producer fault rather than a coin flip) answers `reconcile: ok` with ONE create, a second
+ * funded wallet standing beside this live row. Six such rows executed, across the statuses and
+ * addresses this builder can render.
+ *
+ * Stated as what it CAN do, because whether it does turns on the journal — a file on disk, read by
+ * the next process, which this render path cannot consult. That is what the triage step is for.
+ *
+ * The protection it quotes is scoped per strategy for the same reason the sentence above is: the
+ * command covers every sleeve in the package, so "a re-run funds no second wallet" as a statement
+ * about the COMMAND is false on any multi-sleeve package (executed — see
+ * {@link noSecondWalletWhileNamedLive}).
+ */
+function secondWalletRiskWhenNameRouteClosed(resume) {
+    return (`A re-run funds no second wallet for a strategy while a live strategy answers to the name it ` +
+        `looks up — this strategy is not under that name, so that does not cover it: re-running ` +
+        `${resume} can fund a SECOND wallet beside this live one.`);
+}
+/**
+ * Facts that change what a re-run does — named, with no outcome attached to any of them, and with
+ * no claim that naming them closes the question.
+ *
+ * Each is a fact about rows this process did not read, or about a field it read as absent. Four
+ * rounds attached outcomes to them and each round's enumeration was falsified by the payload beside
+ * the one it was written from, including along these last two axes, which the stated conditions
+ * never named at all. Naming the facts is what this builder can do; naming their outcomes is not.
+ *
+ * A fifth round then attached a COUNT to them ("Four facts decide the answer"), which is a closure
+ * claim and is false on the names-differ arms: the create key journaled on this box decides those,
+ * and this builder takes no journal argument, so it renders the same bytes either way. Executed —
+ * identical row, byte-identical detail: journal absent → one create, journal present → none. The
+ * journal is not listed here for exactly that reason (a fact this render cannot read is not
+ * context, it is a guess); what is dropped instead is the pretence that the list is complete.
+ */
+const FACTS_THAT_DECIDE = `Facts that change the answer, none of them settled by this read: whether another live strategy ` +
+    `answers to that name, whether one under it carries a different package's stamp, whether this ` +
+    `strategy has died, and whether its wallet address has become readable.`;
+/**
+ * The system invariant behind every wallet sentence on this surface, and who resolves a breach.
+ *
+ * One wallet per strategy; two is the failure mode. That makes a duplicate recoverable rather than
+ * catastrophic — both wallets are ordinary rows in `strategy_list` — but only for a reader who is
+ * told what the duplicate looks like and that choosing between the two is not this deploy's call.
+ * Closing is the destructive act, so an agent picking the wrong row closes a funded wallet; that is
+ * why this stands immediately before the never-close line and states no outcome of its own.
+ *
+ * The invariant and whose call a breach is hold on every payload. Where to LOOK does not: on the
+ * degraded read that returned no row, pointing at `strategy_list` for the duplicate contradicts the
+ * lead this same detail opens with, and an agent that triages, sees one row, and reads that as "no
+ * duplicate" re-runs — funding a wallet at the full budget. So that clause renders only where a row
+ * was actually read.
+ */
+function oneWalletPerStrategy(rowWasRead) {
+    // The locator is dropped where the read this detail was built from returned no row. Saying "two
+    // wallets show as two rows in `strategy_list`" beside a lead that just reported no row there
+    // reads as "the list is authoritative and it shows one" — an agent that triages, sees nothing,
+    // and concludes there is no duplicate re-runs, and that re-run funds a wallet at the full budget.
+    // The invariant and whose call it is hold on every payload; only the where-to-look does not.
+    const whoDecides = rowWasRead
+        ? `Two wallets show as two rows in \`strategy_list\`, and which one to keep is the user's call.`
+        : `Which one to keep is the user's call.`;
+    return `One wallet per strategy is the invariant, and two is the failure mode. ${whoDecides}`;
+}
+/**
+ * The one certain next step, on every arm, and the one act that must never follow.
+ *
+ * Read-only triage is the only instruction here that is true regardless of what the next read
+ * finds, and close/recreate is the only genuinely destructive act available on this surface — it
+ * throws away a wallet that may already be funded and live.
+ *
+ * `strategy_list` is named alone. `openclaw senpi status` used to stand beside it as an
+ * alternative "to establish those", and it establishes none of them: it renders
+ * `RuntimeHealthStatus` for runtimes installed HERE — runtime id, health, log level, scanners, DSL,
+ * actions — and reads no backend strategy row, so it carries no name, no status, no package stamp
+ * and no wallet address. Executed through the CLI action: on this payload the install step never
+ * ran, so the gateway collects no handles and the whole output is `No running runtime health
+ * status.`; on the richest payload it CAN render, every line is about a local runtime. An agent
+ * that took the cheaper option would have learned nothing and could count the mandatory triage step
+ * as discharged.
+ */
+function triageThenNeverClose(rowWasRead) {
+    return (`Read-only triage first — \`strategy_list\` — to establish those before re-running anywhere. ` +
+        `${oneWalletPerStrategy(rowWasRead)} NEVER close or recreate to "start clean".`);
+}
+/** The name this row actually carries versus the one this deploy asked for, when they differ. */
+function polledNameMismatchClause(wantedName, live) {
+    const wanted = wantedName.trim();
+    const has = (live.strategyName ?? "").trim();
+    const asked = wanted ? `the "${wanted}" this deploy asked for` : "any name this deploy can look it up by";
+    return has ? `, under the name "${has}", not ${asked}` : `, under no readable name of its own, not ${asked}`;
+}
+/**
+ * The bounded wait ran out. What this renders is what it READ, plus the one thing it can promise.
+ *
+ * The poll's success test is ACTIVE **and** a readable wallet address; everything else that is not
+ * ACTIVE is intercepted before the deadline (dead → `failed`, neither-ACTIVE-nor-initializing →
+ * `failed`), and reconcile refuses those statuses one screen earlier. So what lands here is either
+ * a row still on its way to ACTIVE, or a row that already READS ACTIVE whose address could not be
+ * read — plus the degenerate reads (no row at all, unparseable `createdAt`), which keep the
+ * initializing branch's wording because they establish nothing to say instead. The two payloads
+ * differ in what is MISSING, and that is the one place they diverge here: ACTIVE for the first, the
+ * wallet address for the second.
+ *
+ * It states no outcome for a re-run beyond the money invariant, and the reason is structural. This
+ * builder holds ONE row, read by id. How many live rows answer to the name a re-run looks up, what
+ * stamps THOSE rows carry, whether a create key journaled on this box still resolves, and whether
+ * the address becomes readable are facts about things it did not read and must not read here — a
+ * detail that can throw is a detail that sometimes does not render. Four rounds enumerated those
+ * outcomes anyway: the enumeration grew to 16 predicted branches across the four arms and was still
+ * false on six executed payloads, twice along axes its stated conditions never named. Predicting
+ * from a read that cannot see the deciding facts does not converge, so this renders none of it.
+ *
+ * What survives is {@link noSecondWalletWhileNamedLive} / {@link secondWalletRiskWhenNameRouteClosed}
+ * — one class statement about money per arm, scoped to this strategy and executed at its boundary
+ * rather than reasoned — then {@link FACTS_THAT_DECIDE}, which names facts WITHOUT attaching
+ * outcomes to them or claiming to have listed them all, and {@link triageThenNeverClose}, which
+ * carries the only next step that is correct whatever the next read finds, the shape of the failure
+ * this is all about ({@link oneWalletPerStrategy}), and the one act that must never follow. Every
+ * arm ends on those two, because the tail is what a reader in a hurry acts on.
+ */
+function buildCreatePendingDetail(pkg, budget, waitedSec, live, nowMs, wantedName) {
+    const resume = `\`${resumeCommand(pkg.dir, budget)}\``;
+    const byName = !live || reconcileCanMatchByName(wantedName, live);
+    const nameClause = live && !byName ? polledNameMismatchClause(wantedName, live) : "";
+    const money = byName
+        ? noSecondWalletWhileNamedLive(resume, !!live)
+        : secondWalletRiskWhenNameRouteClosed(resume);
+    const tail = `${money} ${FACTS_THAT_DECIDE} ${triageThenNeverClose(!!live)}`;
+    if (live && live.status.toUpperCase() === "ACTIVE") {
+        return (`after ${waitedSec}s this strategy still has no readable wallet address — ` +
+            `${polledRecordRead(live, nowMs)}${nameClause}: the status this wait was for is already ` +
+            `reached, the wallet address is the field still missing, and an ACTIVE strategy whose ` +
+            `address cannot be read may be funded and live. ${tail}`);
+    }
+    return (`still waiting after ${waitedSec}s for this strategy to read ACTIVE with a wallet address — ` +
+        `${polledRecordRead(live, nowMs)}${nameClause}. ACTIVE is the state this wait is still ` +
+        `missing. ${tail}`);
 }
 /**
  * Live wallets carry this package's stamp, and none of them answered for this instance.
@@ -1222,9 +1503,13 @@ function buildNext(overall, pkg, budget, runs) {
             // A `<runtimeId>` placeholder inside a backticked command is a command an agent pastes
             // literally — and `<` is a shell redirect, so it fails in a way that says nothing about the
             // deploy. With no id to name, name the command that needs none.
+            // Names BOTH things the observe step looks for, because it accepts either: a recorded run
+            // (scheduled) or a fresh liveness post (external). `no verified tick yet` named only the
+            // first, which reads as though a tick were the sole way out of this state — and it is the
+            // mirror of the `verified tick:` prefix the ok side no longer prints for an external row.
             return runtimeId
-                ? `no verified tick yet — check in a few minutes: \`openclaw senpi scanner -r ${runtimeId}\``
-                : `no verified tick yet — this report carries no runtime id: list them with ` +
+                ? `no tick and no liveness post observed yet — check in a few minutes: \`openclaw senpi scanner -r ${runtimeId}\``
+                : `no tick and no liveness post observed yet — this report carries no runtime id: list them with ` +
                     `\`openclaw senpi runtime list\` and check this package's runtime in a few minutes`;
         }
     }
@@ -2213,9 +2498,13 @@ export async function runDeploy(params, deps) {
         });
     }
     /**
-     * A create call that never throws: the backend surfaces a name rejection as a `success:false`
-     * message in some paths and as a thrown MCP error in others, and only one of those shapes must
-     * not decide whether the best-effort naming fallback fires (deploy.py caught the exception).
+     * A create call that never throws, so one code path records the outcome.
+     *
+     * `threw` is part of the result, not a detail of how it was produced: it is the difference
+     * between "the backend answered and created nothing" and "nobody knows whether a wallet was
+     * created and funded", and {@link isNameRejection} refuses to retry on the second. Without it a
+     * transport failure is indistinguishable here from a refusal — which is exactly how the retry
+     * guard came to fire only on the class it must not fire on.
      */
     async function callCreate(params) {
         try {
@@ -2232,7 +2521,7 @@ export async function runDeploy(params, deps) {
             // a rejected name) and unchanged by the C2 carve-out, which could only ever journal a key it
             // received; closing it needs an idempotency key on the create tool, not a client-side fix.
             // Until then the failure detail below tells the operator exactly what to check.
-            return { success: false, message: errorText(err), aborted: isDeadlineAbort(err) };
+            return { success: false, message: errorText(err), threw: true, aborted: isDeadlineAbort(err) };
         }
     }
     async function createInstance(run) {
@@ -2251,7 +2540,7 @@ export async function runDeploy(params, deps) {
         // and nowhere else — and it is the whole difference between "a re-run adopts it by name" and
         // "no route can ever find it", so the report must not have to hedge about which happened.
         let nameFallbackFired = false;
-        if (!result.success && isNameRejection(result.message ?? "")) {
+        if (!result.success && isNameRejection(result)) {
             // The ONE money-moving call in this file with no step boundary ahead of it — every other one
             // is preceded by `boundaryAbandoned()`. It needs its own, because `callCreate` mints a FRESH
             // `MCP_CALL_TIMEOUT_MS` deadline: a retry issued after the soft stop can still be awaiting a
@@ -2357,8 +2646,9 @@ export async function runDeploy(params, deps) {
             }
             // Only INITIALIZING statuses resolve on their own, so only they are worth waiting on (the
             // same rule reconcile applies two screens up). Everything else that is not ACTIVE burns the
-            // whole --max-wait and is then reported `pending` with "wallet still funding" — false for
-            // every one of them. Dead first: it is a subset with its own, opposite re-run consequence.
+            // whole --max-wait and is then reported `pending` with "re-run; reconciliation waits for it
+            // to reach ACTIVE" — a promise none of them can honour. Dead first: it is a subset with its
+            // own, opposite re-run consequence.
             if (live && isDead(live.status)) {
                 record(run, "create", {
                     status: "failed",
@@ -2392,8 +2682,22 @@ export async function runDeploy(params, deps) {
                     status: "pending",
                     // `budget` verbatim, never a per-instance fallback: an adopted instance has no
                     // fundAmount, and `--budget 0` is a command no one can usefully run.
-                    detail: buildCreatePendingDetail(pkg, budget, maxWaitSec),
-                    evidence: { strategyId, status: live?.status ?? null },
+                    // `run.strategyName` is the name a re-run's reconcile will look this row up by, so the
+                    // detail can check whether that route is even open before promising what it does.
+                    detail: buildCreatePendingDetail(pkg, budget, maxWaitSec, live, deps.now(), run.strategyName),
+                    evidence: {
+                        strategyId,
+                        status: live?.status ?? null,
+                        createdAt: live?.createdAt ?? null,
+                        // The fact the sentence branches on, in the machine-readable half too: a `--json`
+                        // reader must not have to diff two prose names to learn the name route is closed.
+                        // `strategyName` follows this file's absence rule — a field the backend did not report
+                        // is OMITTED, never handed over as `""` — because the prose for that same row says
+                        // "under no readable name of its own", and the two readers must not reach different
+                        // conclusions about whether a name exists.
+                        ...(live?.strategyName?.trim() ? { strategyName: live.strategyName } : {}),
+                        ...(live ? { matchableByName: reconcileCanMatchByName(run.strategyName, live) } : {}),
+                    },
                 });
                 return;
             }
@@ -2620,7 +2924,7 @@ export async function runDeploy(params, deps) {
     const observable = runs.filter((run) => run.report.runtimeId && ["ok", "skipped"].includes(run.report.steps.install.status));
     if (!halted() && observable.length > 0) {
         emitPhase("observe", tickWaitSec > 0
-            ? `waiting up to ${tickWaitSec}s for one verified scanner tick`
+            ? `waiting up to ${tickWaitSec}s for one scanner tick — or, for an external scanner, one fresh liveness post`
             : "tick observation skipped by --tick-wait 0");
         await span("deploy.observe", { "senpi.deploy.step": "observe" }, async () => {
             for (const run of observable) {
@@ -2672,12 +2976,26 @@ export async function runDeploy(params, deps) {
             }
             const ticked = active.find((row) => isFreshTick(row, sinceMs));
             if (ticked) {
-                const via = ticked.scheduleMode === "external"
-                    ? `alive (external, lastAliveAt fresh)`
-                    : `lastRunStatus=${ticked.lastRunStatus}`;
+                // Two different things are proven here and the line has to name which one it got.
+                // `isFreshTick` accepts liveness for an external scanner on purpose (see it for why), so
+                // `verified tick:` in front of an external row was a claim its own evidence contradicted:
+                // the production case is `runCount=0 lastRunStatus=null statusesSeen=[]`, because the
+                // scanner's interval is longer than the observe window. Both are legitimate grounds to
+                // call the deploy live; only one of them is a tick.
+                //
+                // Branch on the ROW, never on `scheduleMode`. `isFreshTick`'s external branch short-circuits
+                // on `lastAliveAt` before it reads the run fields, so an external scanner that HAS recorded
+                // a fresh run arrives here too — and a mode-keyed wording printed "not that a run was
+                // recorded" beside `runCount=3`, which is the same verdict-versus-evidence contradiction
+                // inverted. `recordedFreshRun` asks the row what it proves; only when the answer is no does
+                // the line fall back to what liveness alone establishes.
+                const proven = recordedFreshRun(ticked, sinceMs)
+                    ? `verified tick: ${ticked.scannerId} lastRunStatus=${ticked.lastRunStatus}`
+                    : `verified alive: ${ticked.scannerId} is posting (external, lastAliveAt fresh) — this ` +
+                        `proves the scanner is running, not that a run was recorded;`;
                 record(run, "observe", {
                     status: "ok",
-                    detail: `verified tick: ${ticked.scannerId} ${via} runCount=${ticked.runCount} ` +
+                    detail: `${proven} runCount=${ticked.runCount} ` +
                         `signalsProduced=${ticked.signalsProduced} health=${ticked.health}`,
                     evidence: {
                         scannerId: ticked.scannerId,