@senpi/runtime 3.0.72 → 3.0.74

package/dist/deploy/messages.js

@@ -0,0 +1,1388 @@
+/**
+ * Every refusal, warning and detail string the deploy verb emits — one producer per taxonomy code.
+ *
+ * Split out of `orchestrator.ts` verbatim: this module holds the rendering, `orchestrator.ts` holds
+ * the control flow that decides which of these to call. Nothing here reads the job's run state, which
+ * is why it could move at all — the handful of builders that DO take an `InstanceRun` stay beside it.
+ */
+import { join, } from "node:path";
+import { describeScannerEnabledOffense, lowercasePackageIdFix, sanitizeStrategyName, } from "./package.js";
+import { CLOSING_STATUSES, isInitializing, } from "../senpi/strategy-status.js";
+import { MIN_WALLET, budgetArg, resumeCommand, usd, } from "./funding.js";
+import { deployPyValidateCommand, PROOF_ROUTE_NOTE, recheckBlock, validateCommand, } from "./recheck-commands.js";
+import { INSTALL_DEADLINE_MS, INSTALL_INDETERMINATE_CODE, WALLET_INSTALL_IN_FLIGHT_CODE, } from "./deadlines.js";
+/** The provenance clause every reconcile message carries, so a report never hides how it matched. */
+export function matchedByClause(matchedBy) {
+    return matchedBy === "created-key" ? " (matched by journaled create key, verified against the backend)" : "";
+}
+/**
+ * The other live strategies that answered to the matched name and were dropped as another
+ * package's. A bind that ignored one is still a bind on a CONTESTED name — the collision outlives
+ * this deploy and surfaces again at the next `close.py`, rename, or status read — so the report
+ * says so rather than rendering a clean "matched by name". It is a note, not a warning: nothing
+ * here is this package's to act on, which is the same reason those rows were dropped.
+ */
+export function foreignCollisionClause(ignoredForeign) {
+    if (ignoredForeign.length === 0)
+        return "";
+    const stamps = [...new Set(ignoredForeign.map((s) => s.skillName?.trim()).filter((v) => !!v))];
+    const whose = stamps.length > 0 ? stamps.map((s) => `"${s}"`).join(", ") : "another package";
+    const plural = ignoredForeign.length === 1 ? "y" : "ies";
+    return (` — note: ${ignoredForeign.length} other live strateg${plural} of the same name ` +
+        `${ignoredForeign.length === 1 ? "is" : "are"} stamped for ${whose} and ${ignoredForeign.length === 1 ? "was" : "were"} ` +
+        `left untouched`);
+}
+export function buildAmbiguousRefusal(count, matchedAs, instance) {
+    return (`[E_STATE_AMBIGUOUS_WALLETS] ${count} live strategies ${matchedAs} — cannot resolve ` +
+        `which wallet belongs to instance "${instance}". Read-only triage first (openclaw senpi status / ` +
+        `strategy_list), clear the ambiguity with the user. NEVER close or recreate to "start clean".`);
+}
+/**
+ * A single live name-match whose wallet address cannot be read. deploy.py refused this case rather
+ * than guessing, and the taxonomy's `E_STATE_AMBIGUOUS_WALLETS` row names it explicitly: the strategy
+ * may be funded and live, so neither adopting a blank address nor creating a second wallet is safe.
+ */
+export function buildUnreadableWalletRefusal(strategyName, instance, strategyId) {
+    // An id the backend did not report is stated as unreadable, never rendered as the blank in
+    // "(id )" — the same rule the wallet address in this very refusal is subject to. A reader who
+    // sees an empty parenthetical cannot tell a missing id from a rendering bug.
+    const id = strategyId?.trim() ? `id ${strategyId.trim()}` : "id unreadable";
+    return (`[E_STATE_AMBIGUOUS_WALLETS] Live strategy "${strategyName}" (${id}) matches instance ` +
+        `"${instance}" but its wallet address is unreadable — cannot resolve which wallet this instance ` +
+        `owns, and it may be funded and live. Nothing was created or changed. Read-only triage first ` +
+        `(openclaw senpi status / strategy_list), clear the ambiguity with the user. NEVER close or recreate to ` +
+        `"start clean".`);
+}
+/**
+ * The `create: skipped` detail for an adopted wallet.
+ *
+ * When a budget was requested, this is the only place the report can say that it was **not**
+ * applied — deploy never adds funds to a wallet that already exists, and a silent skip would let an
+ * agent summarise "deployed spider with $500" over a wallet holding $100.
+ */
+/**
+ * How a backend `totalFunded` read renders in prose.
+ *
+ * An unreadable figure is stated as unreadable, never as `$0.00`. Every sentence that quotes this
+ * number sits beside an instruction about money, and the two cases call for opposite next steps: a
+ * genuine zero says "there is nothing on this wallet", an unread one says "nobody knows yet".
+ */
+export function fundedClause(amount) {
+    return amount === undefined ? "with no readable funded amount reported" : `funded ${usd(amount)}`;
+}
+/** `its $60.00` / `its balance` — the possessive form of the same rule. */
+export function itsFunded(amount) {
+    return amount === undefined ? "its balance" : `its ${usd(amount)}`;
+}
+/**
+ * The rollback voice of {@link fundedClause}: `funded $250.00` / the unread form.
+ *
+ * Both sentences it feeds order money moves on the wallet they name — "closing it and returning the
+ * funds", "Reclaim the funds from THIS wallet" — so a `?? 0` here told the reader to reclaim from a
+ * wallet the same sentence called empty, which reads as "nothing to reclaim, skip it" over money
+ * that is genuinely out there. UNKNOWN, never $0.00.
+ */
+export function rollbackFundedClause(amount) {
+    return amount === undefined
+        ? `funded an amount that was unreadable at deploy time (UNKNOWN, never zero — verify the ` +
+            `wallet's balance)`
+        : `funded ${usd(amount)}`;
+}
+/**
+ * A live name-match in a status that is neither ACTIVE nor on its way there — PAUSED, mid-teardown,
+ * 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 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.
+ */
+export function buildNotDeployableRefusal(matched, instance, pkg, budget) {
+    const status = matched.status.toUpperCase();
+    const head = `[INVALID_REQUEST] Live strategy "${matched.strategyName}" (id ${matched.id}) matches instance ` +
+        `"${instance}" but its status is ${matched.status} — `;
+    const rerun = `re-run \`${resumeCommand(pkg.dir, budget)}\``;
+    if (status === "PAUSED") {
+        return (`${head}a paused strategy cannot be deployed onto, and it will not become ACTIVE on its own. ` +
+            `Nothing was created. Resume it first, then ${rerun}. If you meant to start over instead, tear ` +
+            `this one down with \`python3 senpi-strategy-ops/scripts/close.py '${pkg.id}'\` (that returns its ` +
+            `funds) before re-running — never leave it paused and fund a second wallet beside it.`);
+    }
+    if (CLOSING_STATUSES.includes(status)) {
+        return (`${head}it is being torn down. Nothing was created. Wait for it to reach CLOSED (re-check with ` +
+            `\`python3 senpi-strategy-ops/scripts/status.py '${pkg.id}'\`), then ${rerun} — the re-run will ` +
+            `create a fresh wallet once this one is gone.`);
+    }
+    return (`${head}deploy cannot proceed from that state and will not guess. Nothing was created. Read-only ` +
+        `triage first (openclaw senpi status / strategy_list) to find out why it is ${matched.status}, then ${rerun} ` +
+        `once it is ACTIVE. NEVER close or recreate to "start clean".`);
+}
+export function buildBudgetRequiredRefusal(wallets, pkg) {
+    return (`[INVALID_REQUEST] --budget is required to create ${wallets} wallet(s) ` +
+        `(min ${usd(MIN_WALLET)}/wallet). Nothing was created. Re-run: ${resumeCommand(pkg.dir)}`);
+}
+/**
+ * `--budget 0` is not "no budget": it parses, and without this gate `planFunding` floors every
+ * wallet to MIN_WALLET — funding money the user never asked to spend. `--budget ≤ $0` is also the
+ * taxonomy's rule-4 field case: its only known source in the field is a buggy computed hint, so the
+ * refusal teaches where the real fix lives instead of letting that loop run. The same gate exists
+ * at gateway intake (register.ts), keeping every caller of `runDeploy` covered.
+ */
+export function buildBudgetNotPositiveRefusal(budget, wallets, pkg) {
+    return (`[INVALID_REQUEST] --budget must be a positive USD amount: ${usd(budget)} cannot fund ` +
+        `${wallets} wallet(s) (min ${usd(MIN_WALLET)}/wallet). Nothing was created. If a report ` +
+        `suggested \`--budget ${budgetArg(budget)}\`, that hint was a bug, not an instruction — a ` +
+        `sleeve declaring \`funding_share: 0\` is fixed by giving it a share in strategy.yaml, never ` +
+        `by re-deploying. Re-run: ${resumeCommand(pkg.dir)}`);
+}
+/** `scalp $12.00 (needs $13.50)` — both numbers, so the claim is checkable. */
+function renderUnderfunded(under) {
+    return under.map((row) => `${row.wallet} ${usd(row.funded)} (needs ${usd(row.needs)})`).join(", ");
+}
+/**
+ * The budget a re-run scoped to exactly `under` would need, given how `planFunding` will split it:
+ * each sleeve gets its declared share, or an even slice of however many are being redeployed.
+ * COMPUTED, never templated — the taxonomy's rule 4 exists because a hint that can be nonsense for
+ * some state is a bug, and "deploy at the package minimum" is nonsense when only one sleeve is
+ * being replaced.
+ */
+function budgetToCover(rerunFunds, pkg, min) {
+    // A declared share of 0 is kept verbatim by `sharesOf`, so that wallet is floored at MIN_WALLET
+    // at EVERY budget — no number satisfies it, and including one in the max would send this to
+    // Infinity. Such a sleeve never shapes the TARGET (the fix is the manifest, not the budget — see
+    // `zeroShareSentence`), but when the re-run will fund it anyway (it has no wallet) it stays in
+    // `rerunFunds` and so in the even-split DENOMINATOR: `planFunding` divides evenly over every
+    // wallet being funded, zero-share ones included, and a hint sized against a smaller split
+    // under-hints the agent straight back into this warn. (An ABSENT share is different — it becomes
+    // an even slice, which does scale.)
+    const scalable = rerunFunds.filter((name) => pkg.instances.find((i) => i.name === name)?.fundingShare !== 0);
+    if (scalable.length === 0)
+        return 0;
+    const evenShare = 1 / rerunFunds.length;
+    const needsOf = new Map(min.breakdown.map((row) => [row.wallet, row.perWalletMin]));
+    const worst = scalable.reduce((most, name) => {
+        const declared = pkg.instances.find((inst) => inst.name === name)?.fundingShare;
+        const share = declared !== null && declared !== undefined && declared > 0 ? declared : evenShare;
+        return Math.max(most, (needsOf.get(name) ?? 0) / share);
+    }, 0);
+    // Ceil to whole cents so `budget × share` clears the requirement BEFORE `planFunding`'s round2.
+    return Math.ceil(worst * 100) / 100;
+}
+/**
+ * The fix-the-manifest sentence for `funding_share: 0` sleeves — the one shortfall this escape can
+ * NEVER remediate. `planFunding` keeps a declared 0 verbatim, so the wallet is floored at
+ * MIN_WALLET at every budget: closing it and re-deploying bigger funds it straight back at the
+ * floor, which is the destructive no-op loop the close command must not offer. When such a sleeve
+ * is the ONLY short one, this sentence IS the whole escape — deliberately with nothing to run.
+ */
+function zeroShareSentence(names) {
+    const one = names.length === 1;
+    return (`Sleeve${one ? "" : "s"} ${names.join(", ")} declare${one ? "s" : ""} \`funding_share: 0\`, so ` +
+        `NO budget can lift ${one ? "it" : "them"} above the ${usd(MIN_WALLET)} floor and closing/` +
+        `re-deploying cannot change that — the fix is a share in strategy.yaml, not more money.`);
+}
+/**
+ * The close-then-redeploy escape — the ONLY sequence that actually raises a deployed wallet's size.
+ *
+ * A bare re-run at a bigger `--budget` is a guaranteed no-op: reconcile matches the strategy by
+ * name, ADOPTS it, skips create, and answers with `buildAdoptedWalletDetail`'s "the requested … was
+ * NOT added". The agent then has to reverse-engineer the real step from a message it did not
+ * expect, and the two likeliest readings are "the deploy failed" and "close it to start clean".
+ *
+ * SCOPED to the underfunded sleeves. `close.py <id>` tears down the WHOLE package, so on a
+ * partially-adopted deploy it would close the adopted, live, funded sleeve that this warn is not
+ * even about — the "close-to-replace teardown" class the taxonomy's rule 5 exists to prevent.
+ * `--instance` narrows it, and is only omitted when every sleeve in the package really is affected.
+ *
+ * `existing` is the subset of `under` whose wallets ACTUALLY EXIST on the finished report. An empty
+ * one yields no escape at all: on a deploy that failed before create there is no "it" to close, and
+ * offering a teardown for a wallet that was never made is a false premise plus a pointless step.
+ */
+export function buildBudgetEscape(pkg, min, state) {
+    // E_ROLLBACK_INCOMPLETE owns the remediation wherever it appears. It names a stranded funded
+    // wallet and the command to reclaim it; a second close instruction beside it — scoped differently,
+    // and unrunnable besides — is a report contradicting itself, and an agent reconciling the two
+    // picks whichever one executes. Defer, and say who to follow.
+    if (state.rollbackIncomplete) {
+        return (` Deal with the [E_ROLLBACK_INCOMPLETE] line on this report FIRST — it owns the cleanup here, ` +
+            `and its instruction is the one to follow. Re-size only once that wallet is settled.`);
+    }
+    // A wallet with no runtime cannot be closed by instance at all: `close.py --instance` resolves the
+    // sleeve THROUGH its runtime and hard-exits without one, telling the reader to "omit --instance to
+    // close all of <id>" — the whole-package teardown of any adopted sleeve beside it. Never emit a
+    // command whose precondition this report does not meet; point at read-only triage instead.
+    if (state.strandedNames.length > 0) {
+        // Deliberately names NO teardown command. Per-sleeve teardown resolves the sleeve through its
+        // runtime, which these wallets do not have; the package-wide form would take down every sleeve
+        // including any adopted live one. The only command here is read-only, so there is nothing to
+        // copy that could destroy anything.
+        return (` Re-sizing is NOT safe to automate on this report: wallet(s) ${state.strandedNames.join(", ")} ` +
+            `were funded but no runtime was installed on them, which is the one state a per-sleeve teardown ` +
+            `cannot resolve — and a package-wide one would take down every other sleeve with it, adopted ` +
+            `live ones included. Triage read-only first: ` +
+            `\`python3 senpi-strategy-ops/scripts/status.py '${pkg.id}'\`, then decide with the user.`);
+    }
+    // A zero-share short sleeve is not remediable by this escape AT ALL — no budget moves it off the
+    // floor (see `zeroShareSentence`) — so it never reaches `closable` and never shapes the hint's
+    // target. When it is the only short sleeve, the manifest sentence is the entire escape.
+    const zeroShareNote = state.zeroShare.length > 0 ? ` ${zeroShareSentence(state.zeroShare)}` : "";
+    if (state.closable.length === 0)
+        return zeroShareNote;
+    // The id and the package dir are quoted the way `--instance` is: shell input, copied verbatim.
+    const wholePackage = state.closable.length === pkg.instances.length;
+    const closeCmd = wholePackage
+        ? `python3 senpi-strategy-ops/scripts/close.py '${pkg.id}'`
+        : state.closable
+            .map((name) => `python3 senpi-strategy-ops/scripts/close.py '${pkg.id}' --instance '${name}'`)
+            .join(" && ");
+    // The scoped clause NAMES the sleeves it closes rather than saying "the underfunded sleeve(s)":
+    // a zero-share sleeve can be underfunded yet deliberately absent from the command, and prose that
+    // describes a wider set than the command executes is the self-contradiction this note exists to
+    // avoid.
+    const closeClause = wholePackage
+        ? `Close it first (\`${closeCmd}\`, which returns the funds)`
+        : `Close ONLY ${state.closable.join(", ")} first — the rest of the package stays up ` +
+            `(\`${closeCmd}\`, which returns the funds)`;
+    // The re-run funds every walletless instance, not just the ones being closed — a sleeve whose own
+    // create failed is in that set too, and sizing the hint against the closed set alone under-hints
+    // it straight back into this same warn.
+    const rerunFunds = [...new Set([...state.closable, ...state.walletless])];
+    const redeployBudget = wholePackage ? min.minBudget : budgetToCover(rerunFunds, pkg, min);
+    // Mirror of `underfundedNote`'s guard, on the module's other money-hint producer: below
+    // MIN_WALLET no rendered `--budget` is valid, and suggesting one produces nonsense the agent
+    // then follows ("--budget ≤ $0", the M381223 churn).
+    //
+    // No longer reachable through `runDeploy`: its only route in was a mis-authored share > 1, and
+    // `sharesOverAuthorization` now refuses that at the preflight, before a wallet is funded. With
+    // every share at or below 1 the implied figure is `perWalletMin / share ≥ perWalletMin`, and
+    // `min_budget` floors perWalletMin at MIN_WALLET, so it cannot fall under it. Kept as defence in
+    // depth — it costs one comparison, and it is the second half of a rule the other producer also
+    // enforces locally.
+    if (redeployBudget < MIN_WALLET)
+        return zeroShareNote;
+    return (` Running the authored design means starting over at the larger size, NOT re-running at a bigger ` +
+        `budget: deploy never adds funds to a wallet that already exists, so a re-run would just adopt ` +
+        `what is already there. ${closeClause}, then ` +
+        `\`openclaw senpi deploy -p '${pkg.dir}' --budget ${budgetArg(redeployBudget)}\`.${zeroShareNote}`);
+}
+/** Forward-looking tense for the preflight narration: everything is about to be funded and run. */
+export function forwardTense(under) {
+    const names = under.map((row) => row.wallet);
+    return { funded: new Set(names), running: new Set(names) };
+}
+/**
+ * The SOFT tier's warn: one or more wallets this deploy funds get less than their own sizing needs.
+ *
+ * It must not read like the `[E_FUNDS_*]` refusals that share its `[E_…]` shape, because it did not
+ * stop anything — users size their own budgets, and a strategy that runs with fewer slots than
+ * authored is a legitimate choice, not a fault. Hence the explicit "nothing was blocked": without
+ * it, an agent that pattern-matches bracketed codes to "refused" would report a live deploy as a
+ * failure and start closing wallets to "fix" it. The phrasing is state-independent ("the budget
+ * check did not stop this deploy") because this note also rides `failed` reports, where the old
+ * "this deploy PROCEEDS" was simply untrue.
+ *
+ * The whole-package minimum is quoted as CONTEXT, in its own parenthesis — never as the claim.
+ */
+function buildBudgetBelowMinNote(pkg, min, under, escape, tense) {
+    // "Will run" is a claim about something INSTALLED, judged per row: a mixed report used to say
+    // "those sleeve(s) WILL RUN DEGRADED" about wallets it named as stranded two clauses later. The
+    // sizing observation itself stays in every branch — it was true about the plan.
+    const running = under.map((row) => row.wallet).filter((name) => tense.running.has(name));
+    const degraded = running.length === under.length
+        ? `those sleeve(s) will run DEGRADED, with`
+        : running.length === 0
+            ? `at that size those sleeve(s) would run DEGRADED, with`
+            : `of these, ${running.join(", ")} will run DEGRADED — the rest never got a runtime ` +
+                `installed on this run — with`;
+    // "This deploy funds" is a claim about the WALLET, judged per row too: on a deploy that never
+    // created one, present tense states an allocation that did not happen — while "would have funded"
+    // about a wallet that IS live and funded (stranded, rollback-incomplete) contradicts the very
+    // line that names it. Each row's own fact decides.
+    const fundedCount = under.filter((row) => tense.funded.has(row.wallet)).length;
+    const lead = fundedCount === under.length
+        ? `This deploy funds ${under.length} wallet(s) below what their own sizing needs`
+        : fundedCount === 0
+            ? `This deploy would have funded ${under.length} wallet(s) below what their own sizing needs`
+            : `This deploy funds ${fundedCount} of ${under.length} wallet(s) below what their own ` +
+                `sizing needs (the rest never got a wallet)`;
+    return (`[W_BUDGET_BELOW_STRATEGY_MIN] ${lead}: ${renderUnderfunded(under)}. Nothing was blocked — the ` +
+        `budget check did not stop this deploy; ${degraded} fewer slots than designed and each ` +
+        `position a larger share of its wallet. (For reference, deploying the whole ${pkg.id} package ` +
+        `fresh needs ${usd(min.minBudget)} across ${min.walletCount} wallet(s).)${escape}`);
+}
+/**
+ * The SOFT tier's other half: a sleeve whose slot size could not be read out of its runtime.yaml
+ * (the vol-parity sleeves expose risk weights, not margin percentages). Its per-wallet minimum fell
+ * back to the bare floor, so the figure is a LOWER bound — saying it plainly is the whole point,
+ * because the alternative is advertising a $10 minimum for a design that no-trades below $250.
+ *
+ * A concrete shortfall is APPENDED rather than replacing this note. Both facts matter and the
+ * understatement is the more important caveat, so it leads — but "these wallets are already short"
+ * is the one hard, checkable thing available, and suppressing it (the shape this had when the two
+ * branches were exclusive) left the agent with the softer half of the truth while `belowMin`
+ * reported the opposite of it. Once it asserts that shortfall it must also name the way out, or an
+ * agent reading a concrete number with no escape will improvise one — and the improvisations this
+ * repo has field cases for are a bare re-run and a close.
+ */
+function buildBudgetUnresolvedNote(pkg, min, under, escape, tense) {
+    // Same per-row funding tense as the below-min note (see there for why).
+    const fundedCount = under.filter((row) => tense.funded.has(row.wallet)).length;
+    const funding = fundedCount === under.length
+        ? `is ALREADY funding ${under.length} wallet(s)`
+        : fundedCount === 0
+            ? `would have funded ${under.length} wallet(s)`
+            : `is ALREADY funding ${fundedCount} of ${under.length} wallet(s) (the rest never got a wallet)`;
+    const shortfall = under.length > 0
+        ? ` This deploy ${funding} below their own sizing: ${renderUnderfunded(under)}.`
+        : "";
+    return (`[W_BUDGET_UNRESOLVED] could not compute a reliable minimum for ${pkg.id} — sleeve(s) ` +
+        `${min.unresolvedWallets.join(", ")} expose no resolvable marginPct, so the ${usd(min.minBudget)} ` +
+        `figure may be UNDERSTATED. Size conservatively.${shortfall} Nothing was blocked — the budget ` +
+        `check did not stop this deploy.${escape}`);
+}
+/** Which code leads the soft-tier note, or null when there is nothing to say. */
+function softLead(min, under) {
+    if (min.unresolvedWallets.length > 0)
+        return "unresolved";
+    return under.length > 0 ? "below" : null;
+}
+/**
+ * The soft-tier note, assembled from the facts plus whatever escape the caller's state supports.
+ * ONE producer for both codes' strings — the preflight narration and the final report differ only
+ * in `escape`, so they can never drift into two different accounts of the same finding.
+ */
+export function buildSoftBudgetNote(pkg, min, under, escape, tense) {
+    switch (softLead(min, under)) {
+        case "unresolved":
+            return buildBudgetUnresolvedNote(pkg, min, under, escape, tense);
+        case "below":
+            return buildBudgetBelowMinNote(pkg, min, under, escape, tense);
+        default:
+            return null;
+    }
+}
+/**
+ * The fraction landed, FLOORED to a tenth of a percent.
+ *
+ * Floored rather than rounded on purpose: this warn fires strictly below 90%, and a rounded 89.97%
+ * would print "(90%)" beside a sentence explaining that the wallet came up short of 90% — the kind
+ * of self-contradiction that makes a reader distrust the whole line. Trailing `.0` is dropped so
+ * the ordinary case reads `12%`, not `12.0%`.
+ *
+ * Computed in integer CENTS. Flooring a raw double reintroduced the misprint the flooring exists to
+ * prevent, away from the boundary: `(6.80 / 10.00) * 1000` is 679.999… in binary floating point, so
+ * an exact 68% printed `67.9%`. Cents are what the figures actually are.
+ */
+function fundedPercent(row) {
+    const fundedCents = Math.round(row.funded * 100);
+    const requestedCents = Math.round(row.requested * 100);
+    return `${Math.floor((fundedCents * 1000) / requestedCents) / 10}%`;
+}
+/**
+ * `main (0x…), created by this deploy, funded $60.00 of requested $500.00 (12%, short $440.00)` —
+ * both numbers, so the claim is checkable, and the provenance and the shortfall folded into the same
+ * clause so each wallet is named exactly once.
+ *
+ * The ask is attributed to whoever made it. On the adoption path the amount comes from a PRIOR run's
+ * journal, so "of requested $500.00" under a lead saying "what this deploy requested" described a
+ * request this run never made — against a wallet it never funded. The adopted clause names that run
+ * instead, and a reader who wants the current number is sent to `status.py` by the remediation.
+ */
+function renderPartialFunded(rows) {
+    return rows
+        .map((row) => {
+        const asked = row.created
+            ? `${row.instance} (${row.wallet}), created by this deploy, funded ${usd(row.funded)} of ` +
+                `requested ${usd(row.requested)}`
+            : `${row.instance} (${row.wallet}), adopted by this deploy from an earlier run, funded ` +
+                `${usd(row.funded)} of the ${usd(row.requested)} that run requested`;
+        return `${asked} (${fundedPercent(row)}, short ${usd(row.requested - row.funded)})`;
+    })
+        .join(", ");
+}
+/**
+ * The OUTCOME tier's warn: the backend funded a wallet for materially less than the create call
+ * asked for (a partial bridge, a rejected top-up leg — the deploy sees only the result). The
+ * successor to the skills-side verify gate's `_budget_verdict`, which reported the whole strategy
+ * "not live" over the same finding.
+ *
+ * It is a `W_`, and the difference from that predecessor is the point: the strategy IS live, its
+ * wallet holds real money and its runtime is ticking. Reporting `not-live` (or letting this change
+ * `overall`) would send an agent to close a funded, running strategy over a shortfall a top-up
+ * fixes. So it warns, the exit code stays whatever the deploy earned, and the remediation leads
+ * with the NON-destructive route.
+ *
+ * It deliberately emits NO teardown command. `close.py`'s correct scope depends on state this note
+ * does not own — adopted siblings, wallets stranded with no runtime, an `[E_ROLLBACK_INCOMPLETE]`
+ * line already claiming the cleanup — and the report already has exactly one producer of close
+ * commands ({@link buildBudgetEscape}). A second, differently scoped teardown beside it is the
+ * self-contradiction the taxonomy's rule 5 exists to prevent, and an agent reconciling two of them
+ * runs whichever executes. The destructive option is named as an option and routed through
+ * read-only triage, which is the only command here and cannot destroy anything.
+ *
+ * Two properties of the note are load-bearing and easy to lose:
+ *  - `reassure` — the "nothing is broken, the strategy is LIVE" sentence is a CLAIM about the rest
+ *    of the report, so it is only made when the report PROVES it: `overall === "live"` and nothing
+ *    less (see the gate at the call site). Asserted unconditionally it rode `failed` and `pending`
+ *    reports saying the opposite two lines above; gated only loosely it rode
+ *    `installed-unobserved` ones, where no tick was ever seen.
+ *  - the figures are DATED and the top-up is routed through a fresh read. This note persists on the
+ *    job snapshot and re-renders on every later `deploy status`, and unlike every other budget note
+ *    it asserts a MUTABLE backend quantity whose fix is exactly the action that invalidates it — so
+ *    an undated "short $440.00" invites a second $440 top-up after the first one landed.
+ *  - PROVENANCE, exactly as its unreadable sibling carries it. This note is reachable on the
+ *    ADOPTION path too — the ask is looked up from a prior run's journal for the strategy this run
+ *    adopted — where "SHORT of what this deploy requested … funded $60.00 of requested $500.00"
+ *    named a request this run never made about a wallet it never funded ($500 was the earlier run's
+ *    ask; this one asked for nothing and created nothing). The lead attributes the ask to no one and
+ *    each wallet states its own origin, so a reader can correct the figure from the note itself.
+ */
+export function buildPartialFundNote(pkg, rows, reassure) {
+    // The size claim is about the WALLETS THIS NOTE NAMES, never about the strategy. `rows` is the
+    // filtered SHORT set, so "the strategy is LIVE, but it is trading a $20.00 book" read a
+    // whole-package figure out of one sleeve of it: on a deploy whose other sleeve landed its full
+    // $300, the strategy was trading $320 across two wallets. Same rule the unreadable note's
+    // standing sentence follows — a filtered set speaks only for the wallets in it.
+    const book = rows.length === 1
+        ? `that wallet is trading a ${usd(rows[0].funded)} book`
+        : `those wallets are trading only what landed on them`;
+    const standing = reassure
+        ? `Nothing was blocked and nothing is broken — the strategy is LIVE, but ${book}, `
+        : `Read the step lines above first — they, not this note, say what state this ` +
+            `deploy left behind. Either way ${book}, `;
+    return (`[W_BUDGET_PARTIAL_FUND] The backend funded ${rows.length} wallet(s) SHORT of what was ` +
+        `requested for them, as the backend reported them at deploy time: ${renderPartialFunded(rows)}. ` +
+        `${standing}so every position opened there is sized off the money that actually landed, not ` +
+        `off the amount requested. Report the funded figure, never the requested one. Fix it the ` +
+        `non-destructive way FIRST — and re-read the CURRENT funding before moving any money, because ` +
+        `those figures are what the backend reported AT DEPLOY TIME and a top-up (or a slow bridge leg ` +
+        `settling late) makes them stale: run ` +
+        `\`python3 senpi-strategy-ops/scripts/status.py '${pkg.id}'\`, then add whatever difference it ` +
+        `still shows through the \`senpi-deposit-withdraw-transfer\` skill. Deploy itself never adds ` +
+        `funds to a wallet that already exists, so re-running at the same budget would only adopt what ` +
+        `is there. Closing and redeploying at the full size is the alternative and it is DESTRUCTIVE: ` +
+        `agree the scope with the user against that same read, because a teardown here also takes down ` +
+        `whatever else this package has live.`);
+}
+/**
+ * The unreadable-read sibling of {@link buildPartialFundNote}: the ask is known, the landed amount
+ * is not, so this note makes NO percentage claim, NO dollar shortfall, and asks for no money move.
+ *
+ * The failure it replaces: the client coerced a missing/unparseable `totalFunded` to `0`, which
+ * turned one bad read into `funded $0.00 of requested $500.00 (0%)` plus an instruction to add
+ * $500 — against a wallet that may already hold the full amount, so following it doubled the
+ * deployment. An unread figure is not a small figure; the only honest next step is for the USER to
+ * establish what is actually on the wallet.
+ *
+ * `reassure` is the same earned-claim gate its sibling carries, and for the same reason: "the
+ * create succeeded and the strategy is running" is a claim about the REST of the report, and this
+ * note is reachable on `failed` and `pending` reports through the adoption path — asserted
+ * unconditionally it rode a verdict saying the opposite two lines above. Without it the note keeps
+ * every fact it owns (the amount is unreadable, verify before moving money) and makes no claim
+ * about what the deploy left running.
+ *
+ * PROVENANCE is the other claim it may not invent, and it is claimed PER WALLET only. The note is
+ * reachable on the ADOPTION path — a journaled ask is looked up for exactly the strategy a prior
+ * run created — so "wallet(s) this deploy created" described a create that never happened on a
+ * crash-resume that adopted, created nothing and funded nothing, handing the reader a second wallet
+ * that does not exist. Each wallet therefore states its own origin from
+ * {@link UnreadableFundedWallet.created}.
+ *
+ * No sentence here generalises that over the deploy. `rows` is a FILTERED set — the wallets whose
+ * funded figure came back unreadable — so nothing about the OTHER wallets can be read out of it,
+ * and a `rows.every(...)` looks exactly like a deploy-level fact while being one about the subset:
+ * a deploy that created `main` (readable $300) and adopted `scalp` (unreadable) has `rows =
+ * [scalp]`, and "this deploy created no wallet" is then flatly false about the $300 it just moved.
+ * The only deploy-level claim allowed is the one `reassure` proves — the report says `live`, so the
+ * strategy is running — and it names no create and no adoption.
+ */
+export function buildFundedUnreadableNote(pkg, rows, reassure) {
+    const wallets = rows
+        .map((row) => row.created
+        ? `${row.instance} (${row.wallet}), created by this deploy, requested ${usd(row.requested)}`
+        : `${row.instance} (${row.wallet}), adopted by this deploy from an earlier run that ` +
+            `requested ${usd(row.requested)}`)
+        .join(", ");
+    const standing = reassure
+        ? `Nothing was blocked and the strategy is running; what is UNKNOWN is `
+        : `Read the step lines above first — they, not this note, say what state this deploy left ` +
+            `behind. What is UNKNOWN here is `;
+    return (`[W_BUDGET_FUNDED_UNREADABLE] The backend did not report a readable funded amount for ` +
+        `${rows.length} wallet(s): ${wallets}. ${standing}` +
+        `how much money landed on it — do not state it as ` +
+        `zero, and do not state it as the requested amount. Move no money on this: ask the USER to ` +
+        `verify the actually-funded amount first ` +
+        `(\`python3 senpi-strategy-ops/scripts/status.py '${pkg.id}'\`, or inspecting the wallet), and ` +
+        `only then decide whether anything needs topping up or resizing.`);
+}
+export function buildDecisionModelRefusal(instance, pkg, budget) {
+    return (`[INVALID_REQUEST] Instance "${instance}" runs actions with decision_mode: llm, but no decision ` +
+        `model was given. Nothing was created. Re-run naming the model: ` +
+        `${resumeCommand(pkg.dir, budget)} --decision-model <model>`);
+}
+export function buildDecisionModelEnvRefusal(instance, pkg) {
+    return (`[INVALID_REQUEST] Instance "${instance}" runs actions with decision_mode: llm, but ` +
+        `${pkg.dir}/strategy.yaml declares no defaults.decision_model_env — there is no token to ` +
+        `substitute the model into. Nothing was created. Add ` +
+        `defaults.decision_model_env to strategy.yaml, bind it in the runtime.yaml, then re-run.`);
+}
+/**
+ * An install that came up with NO live entry scanners (`payload.unwired`). The runtime came UP and
+ * is BLIND, and every one of the three phases is deterministic on this box — so this is an install
+ * failure, not a tick that has not landed yet.
+ *
+ * Says what is true (it will never tick), what was NOT done (no scanner ever mounted), and — the
+ * part that has to track reality — what is LEFT on the box. The two teardown outcomes leave
+ * different states, so they never share a sentence: naming `senpi runtime delete` after a
+ * successful delete points at a runtime that no longer exists, and omitting it after a failed one
+ * hides a runtime still running against a wallet this job is about to close.
+ *
+ * The NEXT STEP is per-phase for the same reason. One ladder ("delete, fix, re-run") cannot serve
+ * all three: only `install_wire` is fixable in the package, and on `no_intake` re-running is a loop
+ * that cannot terminate — create → fund → install → unwired → close, moving real money out and
+ * back on every iteration — because the cause is box-level and the intake context is built once at
+ * plugin register. No emitted command may require a precondition the state lacks.
+ */
+export function buildUnwiredInstallDetail(params) {
+    const { phase, runtimeId, wallet, createdByThisJob, removal } = params;
+    const { cause, next } = describeUnwiredPhase(phase, createdByThisJob);
+    // Deleting a runtime tears down DSL exit management for its wallet ADDRESS — it cancels the
+    // exchange stop-loss and drops the backend ratchet stop for every ACTIVE DSL there. On a wallet
+    // this job created, the rollback closes it moments later, so there is nothing left to be
+    // unmanaged; on an ADOPTED wallet nothing closes, so the consequence has to be said out loud.
+    const dslNote = createdByThisJob || !removal.ok
+        ? ""
+        : ` Deleting it also tore down DSL exit management for ${wallet}, which this deploy did not ` +
+            `create: any open position there has lost its ratchet stop and its exchange stop-loss, and ` +
+            `nothing is watching it — check with MCP \`strategy_get_clearinghouse_state\` on ${wallet} ` +
+            `before you leave this.`;
+    const left = removal.ok
+        ? `The runtime was deleted, so nothing is left running against this wallet; the cause is in ` +
+            `the gateway log (event \`runtime.scanners_unwired\`, phase ${phase}).${dslNote}`
+        : `The runtime could NOT be deleted (${removal.error}) and is STILL RUNNING against this ` +
+            `wallet — read it with \`openclaw senpi status -r ${runtimeId}\`, then remove it yourself: ` +
+            `\`openclaw senpi runtime delete ${runtimeId}\`.`;
+    return (`install produced a BLIND runtime "${runtimeId}": ${cause} (phase ${phase}), so it has no entry ` +
+        `scanners and would never tick. Counted as an install failure. ${left} ${next}`);
+}
+/**
+ * The install step's detail when this deploy stopped waiting on an install it could not cancel.
+ *
+ * Every clause here is load-bearing. The install is IN-PROCESS work that takes no signal, so this
+ * deploy giving up says nothing about what the install did — and a detail that guessed either way
+ * would send a reader to close a wallet a runtime may have just come up on. So the claim is the
+ * only one both reads support: the outcome is unknown. The read that resolves it is free and
+ * non-destructive, so it leads; the money-moving step is conditional on its answer, and carries the
+ * same live-sleeve caveat the rollback path uses, because the same package may hold other wallets.
+ *
+ * The detail forks on TWO facts, because one was not enough to make either instruction true.
+ *
+ * `createdByThisJob` (the same flag {@link buildUnwiredInstallDetail} branches on) decides whether a
+ * close is even on the table. A wallet this job created was never closed BECAUSE the install might
+ * still bind it — the causal claim, and the reclaim instruction, both hold, and the money is this
+ * job's own to reclaim. A wallet this job ADOPTED predates the deploy: D-6 never closes an adopted
+ * wallet regardless of how the install lands, so "would have closed it but for the race" is false on
+ * that wallet, and `funded` is the caller's pre-existing balance — not a close target this deploy
+ * has any standing to name.
+ *
+ * `stillInFlight` is the wallet's install FENCE, read as this detail is written, and it decides
+ * whether ANY instruction may be given yet. `installRuntimeCore` writes its registry row and takes
+ * its MCP wallet-ownership check BEFORE `run()` — the modal wedge — so at this instant the install
+ * can be sitting anywhere in that sequence with the fence still held. Two things follow, and both
+ * used to be wrong here:
+ *  - a registry ROW is not proof the install landed. The row is written first; `senpi.listRuntimes`
+ *    renders exactly that state `status: "stopped"`. The landed claim is therefore keyed on the
+ *    runtime showing RUNNING, never on a row existing.
+ *  - while the fence is held, no close may be named at all. An install wedged at the ownership
+ *    check has written NO row, so "if NO row names that wallet, reclaim the funds" pointed straight
+ *    at a `strategy_close` that races the install into the one state this whole carve-out exists to
+ *    prevent — a live runtime trading a closed strategy.
+ * An UNREADABLE fence (`undefined`) takes the in-flight arm: it cannot be proven clear, and the
+ * only unsafe mistake here is naming a close over an install that is still running.
+ */
+export function buildInstallIndeterminateDetail(args) {
+    const { wallet, funded, runtimeId, deadlineMs, createdByThisJob, stillInFlight, resume, caveat } = args;
+    // The landed claim, keyed on RUNNING. A "stopped" row is called out by name because it is the
+    // likeliest thing this reader actually sees: the row is written before `run()`, so the wedge this
+    // detail reports for produces exactly that row.
+    const triage = `Read what exists before changing anything: \`openclaw senpi runtime list\` — the install ` +
+        `LANDED only if that list shows "${runtimeId}" on ${wallet} RUNNING. A row on its own does not ` +
+        `prove it: the registry row is written BEFORE the runtime starts, so a row rendered "stopped" ` +
+        `is an install that registered and never came up. If it is running, re-run \`${resume}\` to ` +
+        `observe a tick.`;
+    // Whose wallet this is — the one fact both settled arms and the in-flight arm state, because a
+    // reader deciding anything about money has to know whether this deploy created it.
+    const inFlightProvenance = createdByThisJob
+        ? `This wallet — ${fundedClause(funded)} — was created by this deploy and was NOT closed`
+        : `This wallet predates this deploy — ${fundedClause(funded)} — and this deploy never closes an ` +
+            `adopted wallet`;
+    const outcome = stillInFlight !== false
+        ? `${inFlightProvenance}. ` +
+            (stillInFlight === true
+                ? `That install is STILL RUNNING inside this gateway as this report is written`
+                : `Whether that install is still running could not be read here, so this report assumes ` +
+                    `it is`) +
+            ` — the wallet is fenced against a second install until it settles, so its outcome is not ` +
+            `decided yet and nothing you can read right now is final. Change NOTHING on ${wallet} and ` +
+            `close NOTHING: a close now would land on a strategy that install is still binding, ` +
+            `leaving a live runtime trading a closed strategy. Re-read shortly — \`openclaw senpi ` +
+            `deploy status\`, then \`openclaw senpi runtime list\` — and decide from the settled ` +
+            // Scoped to THIS wallet on purpose: a re-run that reaches it is fenced, but "a re-run
+            // changes nothing" is a claim about the whole deploy that this detail cannot make — a
+            // sleeve whose strategy reconcile fails to match by name is created and funded again.
+            `state. A re-run that reaches this wallet is refused rather than installing over it, so it ` +
+            `cannot settle this for you.`
+        : createdByThisJob
+            ? `This wallet — ${fundedClause(funded)} — was NOT closed, because closing a wallet an ` +
+                `install is still binding would leave a runtime trading a closed strategy. That install ` +
+                `is no longer running in this gateway — the wallet's install fence has cleared — so what ` +
+                `exists now is what it left. ${triage} If that list shows "${runtimeId}" on ${wallet} ` +
+                `but NOT running, do not close the wallet: the next gateway restart will try to start ` +
+                `that runtime, so read it first (\`openclaw senpi status -r ${runtimeId}\`) and decide ` +
+                `with the user. If NO runtime names that wallet at all, nothing is watching the funds: ` +
+                `reclaim them with MCP \`strategy_close\` on ${wallet}${caveat}`
+            : `This wallet predates this deploy — ${fundedClause(funded)} — and this deploy never ` +
+                `closes an adopted wallet, whichever way the install landed. That install is no longer ` +
+                `running in this gateway. ${triage} Its funds are unaffected by this deploy either way; ` +
+                `use the read above to decide what, if anything, needs doing yourself.`;
+    return (`[${INSTALL_INDETERMINATE_CODE}] the install on wallet ${wallet} did not finish within ` +
+        `${Math.round(deadlineMs / 1000)}s, so this deploy stopped waiting for it. The install runs ` +
+        `inside the gateway and was NOT cancelled: it may still have completed, or it may not have. ` +
+        `${outcome}`);
+}
+/**
+ * The install step's detail when this deploy found an install already running on the wallet.
+ *
+ * The refusal `installRuntimeCore` renders for the same condition is the enforcement copy; this one
+ * exists because deploy reaches the condition one step earlier — before the dead-row branch that
+ * would delete the in-flight install's registry row — and so can say what deploy did (nothing) as
+ * well as what it found. Both name the same reads and neither names a delete, and this one now
+ * carries the same install-bound and wedge-vs-restart facts the enforcement copy does — deploy is
+ * the primary path, so it is the one most readers see, and a weaker message here would invert which
+ * of the two is the source of truth. The one fact it deliberately does NOT reach parity on is elapsed
+ * time: `installPendingOnWallet` reports a boolean, not when the install started, and the job's own
+ * timing is already what `openclaw senpi deploy status` (named below) shows.
+ */
+export function buildInstallInFlightDetail(args) {
+    const boundSec = Math.round(INSTALL_DEADLINE_MS / 1000);
+    return (`[${WALLET_INSTALL_IN_FLIGHT_CODE}] an install is already running on wallet ${args.wallet} ` +
+        `(runtime "${args.runtimeId}") inside this gateway, so nothing was installed or deleted here — ` +
+        `a second runtime on one wallet would put two exit engines on one margin account. This normally ` +
+        `clears on its own once that install finishes. A deploy's own install bound is ${boundSec}s — ` +
+        `well past that, this install is more likely wedged than merely slow, and if so the fence on ` +
+        `this wallet will not clear until this gateway process restarts. Read what that install produced ` +
+        `before acting: openclaw senpi deploy status, then openclaw senpi runtime list.`);
+}
+/**
+ * The cause and the next step for one unwired phase — computed from the phase, never templated.
+ *
+ * `no_intake`'s stake depends on what this job actually did: only a run that CREATES a wallet moves
+ * money on every doomed iteration. Asserting that on an adopted wallet (where a re-run installs and
+ * closes nothing) would overstate a warning that is already strong enough on its own facts.
+ */
+function describeUnwiredPhase(phase, createdByThisJob) {
+    if (phase === "no_intake") {
+        const loop = createdByThisJob
+            ? `every re-run repeats create → fund → install → close and moves real money out and back each time`
+            : `every re-run repeats install → delete on this adopted wallet — no funds move, but nothing ` +
+                `is ever left watching it`;
+        return {
+            cause: `supervised scanner intake is disabled for this whole box, so no external scanner could ` +
+                `be mounted — nothing about this package or this runtime caused it`,
+            next: `Do NOT re-run the deploy yet: the cause is box-level and is decided once when the plugin ` +
+                `starts, so ${loop}. Repair or clear the plugin's \`acceptance-record.json\` state file ` +
+                `and RESTART the gateway first (the boot log names the file with its full path); re-run ` +
+                `only once a fresh install wires its scanners.`,
+        };
+    }
+    if (phase === "install_launch") {
+        return {
+            cause: `the supervised scanner launcher failed to start`,
+            next: `Read the launcher error in the gateway log before re-running — a re-run repeats it ` +
+                `verbatim while the cause is still there.`,
+        };
+    }
+    return {
+        cause: `the supervised scanner wiring failed (a packaging or entrypoint error in this package)`,
+        next: `Fix the scanner entrypoint this package declares (the \`path\`/module of each external ` +
+            `scanner in the instance runtime.yaml), then re-run the deploy.`,
+    };
+}
+/**
+ * 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 "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.
+ */
+export function buildCreateDeadDetail(pkg, budget, live, createdByThisJob) {
+    const origin = polledWalletOrigin(createdByThisJob);
+    const target = polledWalletTarget(live);
+    // A teardown instruction is earned HERE and only here: a dead status proves the strategy is not
+    // coming back, so money left on it really is stranded.
+    const funds = live.totalFunded === undefined
+        ? `The backend reported no readable funded amount for it, so whether anything is stranded is ` +
+            `UNKNOWN — read it with MCP \`strategy_list\` on ${target} before deciding.`
+        : live.totalFunded > 0
+            ? `It still reports ${usd(live.totalFunded)} funded: reclaim that FIRST with MCP ` +
+                `\`strategy_close\` on ${target}, or the money stays in a dead strategy.`
+            : `It reports ${usd(live.totalFunded)} funded, so there is likely nothing to reclaim — ` +
+                `confirm with MCP \`strategy_list\` on ${target} before re-running.`;
+    return (`strategy ${live.id} went ${live.status} while waiting for ACTIVE — a dead status is terminal, ` +
+        `so the wait stopped here rather than running out the clock. Nothing was installed. ${origin}. ` +
+        `${funds} A re-run does NOT adopt a dead strategy (reconcile filters dead statuses on both ` +
+        `match routes), so \`${resumeCommand(pkg.dir, budget)}\` WILL create and fund a NEW wallet beside ` +
+        `this one.`);
+}
+/**
+ * A strategy the ACTIVE poll watched settle on a status that is neither ACTIVE nor on the way
+ * 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 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
+ * is read. One shared "reclaim it FIRST with `strategy_close`" told an agent to tear down a wallet
+ * on a status this build cannot interpret — the exact opposite of what
+ * {@link buildNotDeployableRefusal} says for the same input at the reconcile seam ("will not guess
+ * … NEVER close or recreate to 'start clean'"). The two seams now agree arm for arm: a teardown is
+ * offered only where the status PROVES the strategy is not coming back.
+ */
+export function buildCreateNotDeployableDetail(pkg, budget, live, createdByThisJob, 
+/**
+ * The scoped start-over clause — see {@link buildPackageCloseOffer}. Used by the PAUSED arm
+ * only. Completes the sentence "If you meant to start over instead, …" and carries its own
+ * terminal period; the arm appends nothing to it.
+ */
+closeOffer) {
+    const status = live.status.toUpperCase();
+    const origin = polledWalletOrigin(createdByThisJob);
+    const rerun = `re-run \`${resumeCommand(pkg.dir, budget)}\``;
+    // `pkg.id` is single-quoted everywhere it reaches a shell, exactly as buildStrandedCloseCaveat
+    // quotes it: these strings get copied verbatim into a terminal.
+    const statusPy = `\`python3 senpi-strategy-ops/scripts/status.py '${pkg.id}'\``;
+    const head = `strategy ${live.id} is ${live.status} while this deploy waited for ACTIVE, so the wait stopped ` +
+        `here — this is not a funding delay. Nothing was installed. ${origin}. `;
+    if (status === "PAUSED") {
+        return (`${head}A paused strategy will not become ACTIVE on its own. Resume it, then ${rerun}. If you ` +
+            `meant to start over instead, ${closeOffer} Never leave it paused and fund a second wallet ` +
+            `beside it.`);
+    }
+    if (CLOSING_STATUSES.includes(status)) {
+        return (`${head}It is being torn down, and ${itsFunded(live.totalFunded)} returns to the owner wallet as ` +
+            `that finishes — nothing to reclaim by hand. Wait for it to reach CLOSED (re-check with ` +
+            `${statusPy}), then ${rerun} — the re-run creates a fresh wallet once this one is gone.`);
+    }
+    // Unrecognized. "Waiting cannot help" is a claim this build has no basis for: the status is in
+    // none of the sets it knows, so it may still be on its way to ACTIVE. Read-only triage only —
+    // and no teardown command, because nothing here proves the money is stranded.
+    return (`${head}This build does not recognize the status ${live.status} — it is in none of the ` +
+        `initializing, closing or dead sets this version knows, so deploy will not guess what it means ` +
+        `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 ` +
+        // "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.`);
+}
+/** Who funded the polled wallet — shared by both break-outs so they can never disagree. */
+function polledWalletOrigin(createdByThisJob) {
+    return createdByThisJob
+        ? `This deploy created it`
+        : `This deploy adopted it and funded nothing — it predates this run`;
+}
+/** How to name the polled wallet in a command, address-first and never `undefined`. */
+function polledWalletTarget(live) {
+    return live.strategyWalletAddress
+        ? `wallet ${live.strategyWalletAddress}`
+        : `strategy id ${live.id} (its wallet address is unreadable)`;
+}
+/**
+ * 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.
+ */
+export 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.
+ */
+export 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.
+ *
+ * Rendered from the reconcile read alone — no additional network calls, because a gate that can
+ * fail to render is a gate that sometimes does not fire. Every column is quoted from that read and
+ * says so when it is unreadable: an unread funded amount is the one number a reader would otherwise
+ * take for an empty wallet. The name column is there because a missing/differing name is WHY the
+ * match failed, and it is the fact that tells a reader whether this is old-tooling residue or a
+ * backend that renamed what deploy created.
+ *
+ * The destructive route is named LAST and behind the read-only one, with its real blast radius on
+ * the same line: a refusal that names only a teardown gets followed.
+ *
+ * The consequence sentence is hedged for the same reason the columns are: this read is metadata,
+ * so "left funded, in position and supervised by nothing" would assert two things nothing here
+ * looked at (no position read, no `registryFindById`/`runtimeIsLive` call) — and the second can be
+ * plainly false, since install rebinds only the registry row for `<id>-<instance>` and a wallet
+ * carrying a different runtime id keeps its runtime. What is unread is named as unread; that is
+ * the argument for stopping, not a weaker version of it.
+ */
+export function buildBindingUnknownRefusal(pkg, instance, wantedName, candidates, budget) {
+    const rows = candidates
+        .map((s) => {
+        const wallet = s.strategyWalletAddress?.trim() || "(wallet address unreadable)";
+        const funded = s.totalFunded === undefined ? "funded amount unreadable" : usd(s.totalFunded);
+        const created = s.createdAt ? `created ${s.createdAt.slice(0, 10)}` : "creation date unreadable";
+        const named = s.strategyName?.trim() ? `named "${s.strategyName.trim()}"` : "no name reported";
+        return `  ${wallet}   ${funded}   ${s.status}   ${created}   ${named}`;
+    })
+        .join("\n");
+    return (`[E_INSTANCE_BINDING_UNKNOWN] ${pkg.id}: ${candidates.length} live wallet(s) carry this package's ` +
+        `stamp, and none of them answers for instance "${instance}".\n\n${rows}\n\n` +
+        `Nothing was created and no money moved. Deploying now would fund a NEW wallet beside the ` +
+        `one(s) above and rebind instance "${instance}"'s runtime id onto it. This read is metadata ` +
+        `only: whether the wallet(s) above hold open positions, and whether any runtime is still ` +
+        `watching them, was NOT read here — which is exactly why deploying past it is a bet rather ` +
+        `than a decision.\n\n` +
+        `Read what each wallet is doing before deciding anything:\n` +
+        `  \`python3 senpi-strategy-ops/scripts/status.py '${pkg.id}'\`\n\n` +
+        `Deploy binds an existing strategy two ways — by the name instance "${instance}" answers to ` +
+        `("${wantedName}"), and by a create key journaled on this box — and neither reached the ` +
+        `wallet(s) above. If one of them IS this instance under a name deploy does not know, this verb ` +
+        `has no way to bind to it, so re-running changes nothing. What each wallet is and whether it is ` +
+        `still wanted is the USER's call, made from the read above — deploy will not pick one. Only if ` +
+        `the USER confirms these wallets are unwanted, close them: ` +
+        `\`python3 senpi-strategy-ops/scripts/close.py '${pkg.id}'\` returns their funds and tears down ` +
+        `the WHOLE ${pkg.id} package, every sleeve and runtime in it. Then re-run ` +
+        `\`${resumeCommand(pkg.dir, budget)}\`.`);
+}
+/**
+ * Every live strategy under the name this instance answers to is stamped for a DIFFERENT package.
+ *
+ * The counterpart to {@link buildBindingUnknownRefusal} on the other match route, and the harder of
+ * the two to word: nothing here is the operator's to close. The wallets named belong to another
+ * package — its positions, its balance, possibly its running runtime — so the only routes offered
+ * are edits to THIS package and reads. Re-running is explicitly not one of them: the name is
+ * derived, so it comes out identical every time, which is exactly why the collision is structural
+ * rather than transient.
+ *
+ * Neither is "set `id:` back to the stamp and re-run", which this refusal used to offer. The name
+ * is derived FROM the id ({@link walletName}: `sanitizeStrategyName(id)`, or `<id>-<instance>` for
+ * a multi-sleeve package), and a loadable id is sanitize-stable by construction
+ * (`assertIdentityRoundTrips`), so changing the id to the stamp changes the derived name by exactly
+ * as much — the run after the edit looks for a name the matched wallet does not carry, finds
+ * nothing, and refuses again from the gate instead, whose remedy is the whole-package `close.py`
+ * this refusal's last line forbids. Only the id AND the sleeve layout restored together re-derive
+ * the matched name, which is a restructure of this package, not a field edit — so the route ends at
+ * the read and hands the decision to the user.
+ */
+export function buildForeignPackageRefusal(pkg, instance, wantedName, candidates, budget) {
+    const rows = candidates
+        .map((s) => {
+        // Same absence rules as every other rendered candidate list: an unread field says so rather
+        // than rendering as a blank or a `$0.00` the reader would act on.
+        const wallet = s.strategyWalletAddress?.trim() || "(wallet address unreadable)";
+        const funded = s.totalFunded === undefined ? "funded amount unreadable" : usd(s.totalFunded);
+        const claimant = s.skillName?.trim() || "(stamp unreadable)";
+        return `  ${wallet}   ${funded}   ${s.status}   stamped "${claimant}"`;
+    })
+        .join("\n");
+    // Deduped, because the sentence names WHOSE they are and repeating one id per row reads as more
+    // packages than were found.
+    const stamps = [...new Set(candidates.map((s) => s.skillName?.trim()).filter((v) => !!v))];
+    const whose = stamps.length > 0 ? stamps.map((s) => `"${s}"`).join(", ") : "another package";
+    // Computed from the package as loaded, not templated: a flat package's name IS its id, and
+    // telling its author to rename an instance it does not have is an edit they cannot make.
+    const multi = pkg.instances.length > 1;
+    const derivedFrom = multi
+        ? `package id "${pkg.id}" + instance name "${instance}"`
+        : `package id "${pkg.id}"`;
+    const renameWhat = multi ? "the package `id:` or this instance's `name:`" : "the package `id:`";
+    // A stamp is BACKEND text, not a package id this box loaded, so it is not shell-safe by
+    // construction the way `pkg.id` is (`assertIdentityRoundTrips` guarantees that one). A stamp that
+    // is not a legal package id is named in prose instead of pasted into a command — an emitted
+    // command has to be runnable, and one carrying a quote is worse than none.
+    const reads = stamps
+        .map((s) => sanitizeStrategyName(s) === s
+        ? `  \`python3 senpi-strategy-ops/scripts/status.py '${s}'\``
+        : `  (no command for the stamp ${JSON.stringify(s)} — it is not a usable package id; look ` +
+            `the wallet up by address with \`openclaw senpi status\` / \`strategy_list\`)`)
+        .join("\n");
+    return (`[E_WALLET_OWNED_BY_OTHER_PACKAGE] ${pkg.id}: instance "${instance}" answers to the strategy ` +
+        `name "${wantedName}", and every live strategy under that name carries another package's ` +
+        `attribution stamp (${whose}).\n\n${rows}\n\n` +
+        `Nothing was created and no money moved. Deploy binds an existing strategy BY NAME, so ` +
+        `adopting one of the above would have pointed this package's runtime at another package's ` +
+        `funded wallet — its balance and its open positions — and, if something is already watching ` +
+        `that wallet, left two exit engines on one margin account. This read is metadata only: what ` +
+        `those wallets hold, and whether anything is watching them, was NOT read here.\n\n` +
+        `Re-running changes nothing — "${wantedName}" is derived from ${derivedFrom}, so it comes out ` +
+        `the same every time. Two ways forward, neither of them a money move:\n\n` +
+        `  • The wallet(s) above are not this package's. Two packages collide on one derived name: ` +
+        `give this one a name of its own by editing ${renameWhat} in ` +
+        `${join(pkg.dir, "strategy.yaml")}, then re-run \`${resumeCommand(pkg.dir, budget)}\` — deploy ` +
+        `will create this package's own wallet.\n` +
+        `  • One of them IS this package's, deployed under a package id it no longer has. Editing ` +
+        `\`id:\` back to the stamp does NOT reach it: "${wantedName}" is derived from ${derivedFrom}, ` +
+        `so that edit moves the name deploy looks for along WITH the id — the next run stops looking ` +
+        `for "${wantedName}" at all and refuses again, having bound nothing. What produced ` +
+        `"${wantedName}" is the id and the sleeve layout together, so restoring both as they were is ` +
+        `what would bind it by name; whether this package should go back to that shape is the USER's ` +
+        `call, and a metadata read cannot settle it. Read what each wallet is doing first:\n` +
+        `${reads}\n\n` +
+        `Do NOT close a wallet stamped for another package to clear this — that is a different ` +
+        `strategy's funds and a different runtime's positions. Whose these are is the USER's call.`);
+}
+/**
+ * Refusal for a package whose instances ship no DSL exit block. Rendered BEFORE any wallet exists:
+ * funding a strategy that cannot stop itself out is the "funded-but-no-DSL" hole, and the skills-side
+ * validator has always refused it.
+ */
+export function buildNoDslExitRefusal(instances, pkg) {
+    return (`[INVALID_REQUEST] Instance(s) ${instances.map((inst) => inst.name).join(", ")} declare no DSL ` +
+        `exit block (\`exit.dsl_preset\`, or \`exit.engine: dsl\`) — every position they open would run ` +
+        `with no stop loss and no trailing floor. Nothing was created. Add an exit block to the instance ` +
+        `runtime.yaml, then re-check read-only with either route:\n` +
+        // One `senpi validate` per OFFENDING instance directory, computed from the instance rather than
+        // templated: the offence is per-recipe, and so is the proof that clears it.
+        `${recheckBlock(instances.map((inst) => inst.runtimeYamlDir), deployPyValidateCommand(pkg.dir))}\n` +
+        `${PROOF_ROUTE_NOTE} Then re-run.`);
+}
+/**
+ * A recipe that does not bind the wallet its manifest promises, refused before a wallet exists.
+ *
+ * Names the two addresses side by side because the failure is precisely that they are two: the
+ * money this run would move, and the account the strategy would trade. It states the edit rather
+ * than a command, in the {@link buildInstanceDirCollisionRefusal} spirit — the fix is one line in a
+ * file the reader already has open, and no command can make it for them.
+ */
+export function buildUnboundWalletRefusal(faults, pkg) {
+    const rows = faults.map((fault) => `  - "${fault.instance.name}" (${fault.instance.runtimeYamlPath}) binds ` +
+        `${fault.declared === undefined ? "no strategy.wallet at all" : `\`${fault.declared}\``}, ` +
+        `but strategy.yaml declares \`wallet_env: ${fault.instance.walletEnv}\` for it`);
+    return (`[INVALID_REQUEST] ${faults.length} instance(s) do not bind the wallet this package says they ` +
+        `bind:\n${rows.join("\n")}\n\n` +
+        `Why: deploy CREATES and FUNDS a wallet for each instance and passes it in by substituting ` +
+        `\`\${<wallet_env>}\` into the recipe. A recipe that does not carry that token gets nothing ` +
+        `substituted — silently, because the unresolved-placeholder check only looks for \`\${...}\` ` +
+        `left over, and a hardcoded address leaves none. The deploy would fund a new wallet from your ` +
+        `budget and then install the strategy, actions and exit engine included, against a DIFFERENT ` +
+        `account: the funded wallet would sit with nothing watching it while the strategy traded ` +
+        `elsewhere, and the install step would name the recipe's address, so the report would read ` +
+        `clean.\n\n` +
+        `Nothing was created — this gate reads the package's own files and stopped before any live ` +
+        `read.\n\n` +
+        `Fix — in each recipe above set \`strategy.wallet\` to the token strategy.yaml declares for ` +
+        `that instance (for example \`wallet: "${faults[0].expected}"\` in ` +
+        `${faults[0].instance.runtimeYamlPath}). Deploy substitutes the wallet it creates; a literal ` +
+        `address there is never what you want on this path. Then re-check read-only with either ` +
+        `route:\n` +
+        `${recheckBlock(faults.map((fault) => fault.instance.runtimeYamlDir), deployPyValidateCommand(pkg.dir))}\n` +
+        `${PROOF_ROUTE_NOTE} Then re-run.`);
+}
+/**
+ * A package id carrying capitals, refused before any wallet exists to carry the wrong stamp.
+ *
+ * Deploy's copy of `register.ts`'s gate — same rule, same fix (built from the one producer in
+ * `package.ts`, so the edit an author reads is word-for-word identical), different standing
+ * sentence: nothing was CREATED here, where the gateway's copy could only say nothing was started.
+ *
+ * The re-run command names the directory the fix LEAVES BEHIND, not the one that failed — this is
+ * the only refusal in the verb whose own instruction can move the package.
+ */
+export function buildNonLowercaseIdRefusal(pkg, budget) {
+    const fix = lowercasePackageIdFix(pkg.id, pkg.dir);
+    return (`[INVALID_REQUEST] strategy.yaml id "${pkg.id}" must be lowercase. Nothing was created. ` +
+        `Fix — ${fix.instruction}. Why: this verb writes the id into each wallet's \`skillName\` ` +
+        `attribution stamp VERBATIM at create, and the backend stores what it is given ` +
+        `case-normalized, so a mixed-case id is stamped under one spelling and looked up under ` +
+        `another — that is how \`close.py '${pkg.id}'\` came to report "no OPEN strategies to close." ` +
+        `over a live, funded, trading wallet. Every reader now folds case, so wallets already stamped ` +
+        `in any case are still found and this package will ADOPT the ones it already owns rather than ` +
+        `fund a second set beside them. Then re-run \`${resumeCommand(fix.dirAfterFix, budget)}\`.`);
+}
+/**
+ * The refusal for a manifest whose funding shares allocate more than the whole budget.
+ *
+ * States the arithmetic and nothing about the outcome: the sum, every sleeve's effective share, and
+ * the amount the plan would have moved against the amount authorized. A reader can check each
+ * figure against the file named, which is the point — the defect is a typo in one line of
+ * `strategy.yaml`, and the fastest fix is seeing which share is wrong.
+ *
+ * The fix is the author's, and only they can make it: which sleeve should be smaller is a decision
+ * about the strategy, not one this gate can compute. So it names the constraint (the shares are a
+ * split of ONE budget) and the file, and offers no edit of its own — a hint naming a particular
+ * share would be a guess presented as an instruction. Deliberately no teardown route either:
+ * nothing was created, so there is nothing to tear down.
+ */
+export function buildShareOverrunRefusal(overrun, pkg, budget) {
+    const rows = overrun.shares
+        .map((row) => `${row.name} ${budgetArg(row.share)} (${usd(budget * row.share)})`)
+        .join(", ");
+    return (`[E_FUNDING_SHARES_OVER_ONE] The funding shares in ${join(pkg.dir, "strategy.yaml")} sum to ` +
+        `${budgetArg(overrun.sum)}, not 1 — so this deploy would fund ` +
+        `${usd(budget * overrun.sum)} against the ${usd(budget)} you authorized. ` +
+        `Nothing was created and no money moved. Shares: ${rows}. ` +
+        `Fix — a \`funding_share\` is that sleeve's slice of ONE budget, so the values must sum to 1 ` +
+        `across the package (an undeclared share is an even split of what is left). Correct the ` +
+        `share(s) in ${join(pkg.dir, "strategy.yaml")}, then re-run ` +
+        `\`${resumeCommand(pkg.dir, budget)}\`. ` +
+        `Why this is refused rather than clamped: the amounts a share produces are what each wallet ` +
+        `TRADES, so scaling them down here would size every position off a number you never chose.`);
+}
+/**
+ * The install gate's refusal, rendered for deploy rather than for the gateway.
+ *
+ * Same findings, different standing sentence: the gateway's copy says a recipe cannot be installed,
+ * which is all that is true there. Here the run had money to move and did not move it, and that is
+ * the fact a reader needs first — so it is stated, and the re-check names `senpi validate` on the
+ * instance directory rather than "run validate on the package" in the abstract.
+ *
+ * Deploy's refusal shape: bracketed code first (taxonomy.ts:16 reads it), then what/why/fix.
+ */
+export function buildInstallGateRefusal(gate, inst, pkg, budget) {
+    const lines = gate.blocking.map((f) => `  • ${f.what}\n    why: ${f.why}\n    fix: ${f.fix}`);
+    return (`[${gate.blocking[0].code}] "${inst.name}" cannot be installed — it would not trade.\n\n` +
+        `${lines.join("\n\n")}\n\n` +
+        `Nothing was created by this run — the check reads the package only, and it stopped before ` +
+        `touching the backend.\n\n` +
+        `Fix the recipe, then re-check with: ${validateCommand(inst.runtimeYamlDir)}\n` +
+        // The same command `next` ends the report with, budget and all: a re-run line that differs
+        // from it — a `<usd>` placeholder where the report has the real number — is a second, worse
+        // command competing with the authoritative one.
+        `Then re-run: ${resumeCommand(pkg.dir, budget)}`);
+}
+/**
+ * The gate itself could not run. NOT a verdict on the recipe — so it carries no taxonomy code and
+ * names no offending field, exactly like the universe check's `unavailable` branch.
+ */
+export function buildInstallGateUnavailableDetail(inst, reason) {
+    return (`The install gate could not run for "${inst.name}" (${reason}), so nothing is known about ` +
+        `whether this recipe can trade. Nothing was created by this run. Re-run the deploy; if it ` +
+        // The real directory, never a `<package dir>` placeholder: this line is the one command the
+        // reader is given, and a command that has to be edited before it runs is a command an agent
+        // pastes literally. The INSTANCE's directory, not the package root: the gate ran for one
+        // sleeve, and on a multi-instance package the root is not a validate target at all — it
+        // answers "this directory has no recipe of its own, pick an instance".
+        `persists, run: ${validateCommand(inst.runtimeYamlDir)}`);
+}
+/**
+ * D-2 (revised 2026-08-05): a scanner-level `enabled` key is refused outright — the engine never
+ * reads it (see {@link scannersDeclaringEnabled}), so accepting `enabled: false` would ship a
+ * strategy that ticks and trades while its author believes it is switched off. Package-derivable,
+ * so it is decided synchronously here rather than discovered later; observe keeps its own
+ * all-disabled branch for the live-state case, which the runtime API can genuinely produce.
+ *
+ * Every offense is enumerated in ONE refusal, each as a delete-this-line instruction naming the
+ * key, the scanner, the instance and the file: a reader (agent or human) fixes the whole package in
+ * one pass instead of re-running to discover the next one.
+ */
+export function buildScannerEnabledUnsupportedRefusal(offenders, pkg) {
+    return (`[INVALID_REQUEST] Unsupported \`enabled\` key on ${offenders.length} scanner entr` +
+        `${offenders.length === 1 ? "y" : "ies"}. Nothing was created. Fix — delete these lines:\n` +
+        offenders.map((entry) => `  - ${describeScannerEnabledOffense(entry)}`).join("\n") +
+        `\nWhy: the runtime engine never reads a scanner-level \`enabled\` (the scanner schema passes ` +
+        `it through untyped and registration comes from the strategy, not the scanner entry), so an ` +
+        `\`enabled: false\` scanner registers ENABLED and ticks — the package would trade while you ` +
+        `believe it is off. A scanner runs because the package declares it: to stop one, remove the ` +
+        `scanner entry itself, or disable it after install through the runtime API (\`disableScanner\`). ` +
+        `Then re-run: ${resumeCommand(pkg.dir)}`);
+}
+/**
+ * A create this job stopped waiting on at its per-call deadline. Deliberately NOT phrased as
+ * "creation failed": the deadline bounds the WAIT, not the backend's work, so the wallet may come
+ * into existence after this line is written. Naming both reconcile routes — and the one case
+ * neither can see — is what lets the operator check rather than guess.
+ */
+export function buildCreateAbandonedDetail(args) {
+    const { instance, strategyName, nameFallbackFired, fundAmount, message, pkg, budget } = args;
+    const head = `wallet creation for instance "${instance}" was abandoned at its deadline, so its outcome is ` +
+        `UNKNOWN — this is not "nothing happened": ${message ?? "no message"}. The backend may still ` +
+        `complete the create and fund ${usd(fundAmount)} after this report. Nothing else was done for ` +
+        `this instance, and nothing was rolled back.`;
+    // Which create was abandoned is KNOWN, so neither branch hedges. A named create that lands is
+    // findable by name; the unnamed retry is findable by nothing — it lands under a backend-assigned
+    // name and this box never received the strategyId to journal. In that case re-running FIRST is
+    // the money-losing move, so the check leads.
+    const tail = nameFallbackFired
+        ? ` The name "${strategyName}" had already been rejected, so this second create asked for NO ` +
+            `name: if it landed, the wallet carries a backend-assigned name and no create key ever ` +
+            `reached this box — a re-run can find it by neither route and would fund a SECOND wallet ` +
+            `beside it. Check before you re-run: list your strategies (MCP \`strategy_list\`) and look ` +
+            `for a CUSTOM strategy created just now, funded about ${usd(fundAmount)}. If it is there, ` +
+            `that is this instance's wallet — keep it, or close it with ` +
+            `\`python3 senpi-strategy-ops/scripts/close.py '${pkg.id}'\` before re-running. If it is not ` +
+            `there, the create did not land: re-run \`${resumeCommand(pkg.dir, budget)}\`.`
+        : ` The create asked for the name "${strategyName}", so if it landed the wallet carries that ` +
+            `name and reconcile adopts it instead of funding a second one: re-run ` +
+            `\`${resumeCommand(pkg.dir, budget)}\`. If that re-run creates a fresh wallet and your ` +
+            `accessible balance looks short afterwards, check the wallet list (MCP \`strategy_list\`) ` +
+            `and close the orphan: \`python3 senpi-strategy-ops/scripts/close.py '${pkg.id}'\`.`;
+    return head + tail;
+}
+/**
+ * The name-rejection retry that was NOT issued because the deadline stop landed between the two
+ * creates.
+ *
+ * Not a variant of {@link buildCreateAbandonedDetail}: nothing was abandoned mid-call here. One
+ * create was issued and the backend answered it; the second one — the money-moving call this run
+ * would otherwise have made with no step boundary in front of it — never went out. So the line says
+ * what was attempted, what was not, and leaves the rejected create's own residue to the same check
+ * every rejection carries: reconcile re-reads the live list before it creates anything.
+ */
+export function buildCreateNameRetryNotIssuedDetail(args) {
+    const { instance, strategyName, fundAmount, message, pkg, budget } = args;
+    return (`wallet creation for instance "${instance}" stopped at the deploy deadline. The backend rejected ` +
+        `the name "${strategyName}" (${message ?? "no message"}), and the unnamed retry that normally ` +
+        `follows was NOT issued: a create started now would take a fresh 90s deadline of its own, ` +
+        `outliving the grace period that hands the deploy slot to the next run — this job could still ` +
+        `be waiting on a create funding ${usd(fundAmount)} while a new deploy runs its own preflight ` +
+        `against the same balance. One create was issued for this instance and the backend rejected it; ` +
+        `no second wallet was asked for, and nothing was rolled back. Re-run ` +
+        `\`${resumeCommand(pkg.dir, budget)}\` — reconcile re-reads your live strategies before it ` +
+        `creates anything, and a wallet that landed under the name "${strategyName}" despite the ` +
+        `rejection is exactly what it looks for.`);
+}
+export function buildUnobservedDetail(waitSec, runtimeId) {
+    return (`no tick observed within ${waitSec}s — scanners may tick on a longer interval. ` +
+        `Check in a few minutes: \`openclaw senpi scanner -r ${runtimeId}\``);
+}
+//# sourceMappingURL=messages.js.map