@m13v/s4l 1.6.204-rc.9 → 1.7.0

package/mcp/dist/index.js

@@ -372,7 +372,12 @@ const server = new McpServer({
         "RENDER THE DASHBOARD AFTER ACTIONS. After any state-changing or results-producing tool call " +
         "(`post_drafts`, `get_stats`, `project_config`), end your turn by " +
         "calling the `dashboard` tool so the user sees the updated state visually. Do NOT call " +
-        "`dashboard` after pure Q&A, config explanations, or status-only checks that changed nothing.",
+        "`dashboard` after pure Q&A, config explanations, or status-only checks that changed nothing.\n\n" +
+        "REPORT FIELD DIAGNOSES. Whenever an S4L setup, healing, or troubleshooting flow FAILS, or " +
+        "succeeds only after a failure (schedule re-arm, runtime repair, stuck drafts, rate limits, " +
+        "anything the user pasted a fix-it prompt for), call `report_diagnosis` with a short markdown " +
+        "report (symptom, root cause, actions taken, current state) before ending the turn. Do this " +
+        "automatically — the developers only learn about field failures through these reports.",
 });
 const TOOL_HANDLERS = {};
 const baseRegisterTool = server.registerTool.bind(server);
@@ -385,7 +390,7 @@ const baseRegisterTool = server.registerTool.bind(server);
 // NOT here — it writes finer scanning/drafting phases itself (see produceDrafts).
 const TOOL_ACTIVITY = {
     post_drafts: "posting",
-    get_stats: "loading stats",
+    get_stats: "stats…",
 };
 function toolActivityLabel(name, args) {
     const fallback = TOOL_ACTIVITY[name];
@@ -605,8 +610,8 @@ async function produceDrafts(project, onProgress) {
     let lastMsg = "";
     // Granular scan progress for the menu-bar label. Phase 1 logs one
     // `executing N queries` line (the total), then one `ok/err project=… kept=K`
-    // line per query. We count those to paint `scanning X · N/M · kept K` instead
-    // of a static "scanning X". Best-effort: missing total falls back to a plain
+    // line per query. We count those to paint `scan N/M +K` (K = kept) instead
+    // of a static "scan…". Best-effort: missing total falls back to a plain
     // count, and any parse miss just leaves the prior label up.
     let scanTotal = 0;
     let scanDone = 0;
@@ -636,7 +641,7 @@ async function produceDrafts(project, onProgress) {
         `project=${project ?? "(default)"} =====\n`);
     // Menu-bar status: scanning first, then drafting once the prep phase begins
     // (switched in onLine below). Cleared before every return.
-    writeActivity("scanning", "scanning X");
+    writeActivity("scanning", "scan…");
     const res = await run("bash", ["skill/run-twitter-cycle.sh"], {
         env: env,
         timeoutMs: 900_000, // scan+draft can take several minutes
@@ -665,10 +670,10 @@ async function produceDrafts(project, onProgress) {
                 if (km)
                     scanKept += parseInt(km[1], 10) || 0;
                 const prog = scanTotal ? `${scanDone}/${scanTotal}` : `${scanDone}`;
-                writeActivity("scanning", `scanning X · ${prog} · kept ${scanKept}`);
+                writeActivity("scanning", `scan ${prog} +${scanKept}`);
             }
             if (/Phase 2b-prep/.test(t))
-                writeActivity("drafting", "drafting replies");
+                writeActivity("drafting", "drafting");
             if (!onProgress)
                 return;
             const msg = cycleProgressMessage(t);
@@ -939,6 +944,24 @@ async function postApproved(batchId, plan) {
     // batch so the every-minute autopilot scan queues behind the post instead of
     // seizing Chrome mid-batch — the root cause of approved batches landing 0/N.
     const heldShellLock = await acquireShellBrowserLock();
+    if (!heldShellLock) {
+        // acquireShellBrowserLock now preempts (SIGKILLs) whatever holds this lock
+        // unconditionally, so reaching `false` here means even reclaiming the dir
+        // across 8 attempts didn't stick (e.g. something is re-taking it faster than
+        // we can write our own pid) — a pathological edge case, not the normal path.
+        // Bail out rather than proceed without ever confirming we hold it. Approved
+        // cards stay sticky (approved && !posted && !terminal), so the very next
+        // post_drafts call — the next approval, or this same tool retried — picks
+        // them straight back up; nothing is lost or re-queued.
+        postingActive = false;
+        stopPostingFlagHeartbeat();
+        return {
+            attempted: 0,
+            exit_code: 0,
+            summary: "couldn't pin down the twitter-browser lock after repeated attempts; approved cards " +
+                "stay queued — re-run post_drafts to retry",
+        };
+    }
     const approvedBatch = `${batchId}_approved`;
     writePlan(approvedBatch, { ...plan, candidates: approved });
     // S4L_SKIP_CAMPAIGN_SUFFIX=1: manual/reviewed posts from this MCP draft_cycle
@@ -976,15 +999,23 @@ async function postApproved(batchId, plan) {
                     // opts.env AFTER process.env, and twitter_post_plan.py never load_dotenv's
                     // with override, so nothing clobbers it. Cron is untouched (it never goes
                     // through this MCP path), so the 0.9 experiment keeps running there.
+                    //
+                    // 2026-07-06: the tail-link decision (link vs no_link) and the Claude
+                    // bridge call both moved to DRAFT time (scripts/twitter_gen_links.py's
+                    // Phase 2b-gen step, which stamps tail_link_variant + finalizes
+                    // reply_text before the review card is ever shown — see
+                    // twitter_post_plan.py's guard on tail_link_variant). That step reads
+                    // DRAFT_ONLY (forced to rate=1.0 there) to guarantee a hand-approved
+                    // card never drops the link it already shows. So both env vars below
+                    // are now no-ops for the normal path — every approved candidate
+                    // already carries tail_link_variant by the time it reaches this MCP
+                    // tool. They're left in place as a defense-in-depth fallback for the
+                    // rare case a candidate reaches post_drafts unstamped (e.g. a plan
+                    // already in flight from before this change): S4L_SKIP_LINK_TAIL=1
+                    // still guarantees post_drafts (a synchronous call the user is
+                    // waiting on) never makes a blocking Claude/queue call at post time,
+                    // no matter what.
                     TWITTER_TAIL_LINK_RATE: "1.0",
-                    // Plugin flow only: skip the link_tail Claude call. It just rewords
-                    // prose around the URL (the minted short link comes from the
-                    // deterministic wrap step), and on .mcpb boxes there's no `claude`
-                    // binary so it wastes ~35s/post of run_claude.sh retry backoff before
-                    // falling back to the mechanical concat anyway. link_tail.py honors
-                    // this and short-circuits to that concat instantly. The local
-                    // cron/plist autopilot never sets this, so it keeps generating the
-                    // bridge sentence.
                     S4L_SKIP_LINK_TAIL: "1",
                     // The poster attaches to the twitter-harness Chrome over CDP. The cron
                     // pipeline exports this from skill/lib/twitter-backend.sh; the MCP path
@@ -1576,7 +1607,8 @@ tool("engagement_mode", {
     const bothOn = personalBrand && promotion;
     const next_step = promotion
         ? (bothOn
-            ? "Personal brand + product promotion are BOTH on (the cycle splits 50/50), and the persona " +
+            ? "Personal brand + product promotion are BOTH on (the cycle splits per the lane split, " +
+                "default 50/50 — adjustable via action:'split' or the dashboard slider), and the persona " +
                 "is provisioned + topic-seeded. "
             : "Product promotion is on and the persona is provisioned. ") +
             "NOW CONTINUE SETUP: configure the product project with project_config (research the product " +
@@ -1907,7 +1939,8 @@ tool("project_config", {
                 "THIRD (engagement lanes — ASK THE USER, do not infer): the PERSONAL BRAND lane (organic, " +
                 "link-free engagement in their own voice) is ON by default, so ask the ONE question — do they " +
                 "ALSO want to PROMOTE a PRODUCT (the marketing lane, link replies)? Both lanes can run (the " +
-                "cycle splits 50/50). Call the `engagement_mode` tool action:'set' with personal_brand:true, " +
+                "cycle splits per the configurable lane split, default 50/50). Call the `engagement_mode` tool " +
+                "action:'set' with personal_brand:true, " +
                 "promotion:true|false AND the voice/description/search_topics you synthesized PLUS the raw " +
                 "dictation transcript as content_corpus (this provisions the persona and seeds topics). Only " +
                 "NOW are topics seeded — postponed until the dictation is in. " +
@@ -1946,6 +1979,7 @@ tool("project_config", {
             update_available: !!snap.update_available,
             mode: snap.mode,
             flags: snap.flags,
+            personal_brand_share: snap.personal_brand_share,
             update_hint: snap.update_available
                 ? `A newer version (${snap.latest_version}) is available — you're on ${snap.version}. ` +
                     `Tell the user and offer to run the \`runtime\` tool with action:'update' ` +
@@ -2459,6 +2493,44 @@ tool("restart_menubar", {
         menubar_running: running,
     });
 });
+// ---- report_diagnosis: ship a field diagnosis to the developers -------------
+// First-class MCP wrapper over scripts/send_diagnostic_report.py (the same
+// Sentry lane the menubar "Diagnose & fix" prompt uses). Before this existed
+// (2026-07-06) field diagnoses only reached us when the user clicked the
+// menubar button AND their Claude ran the script via Bash; troubleshooting done
+// directly in chat left no trace. The server instructions tell the agent to
+// call this automatically after any failed (or recovered-after-failure)
+// setup/heal/troubleshooting flow.
+tool("report_diagnosis", {
+    title: "Send a diagnosis report to the S4L developers",
+    description: "Ship a short markdown field-diagnosis report (symptom, root cause, actions taken, current " +
+        "state) to the S4L developers' telemetry. Call this AUTOMATICALLY after any S4L " +
+        "setup/heal/troubleshooting flow that failed, or that succeeded only after a failure — do not " +
+        "wait for the user to ask. Contains no secrets; keep the report factual and under a page.",
+    inputSchema: {
+        report_markdown: z.string().describe("The diagnosis report, markdown, under ~6000 chars"),
+        reason: z
+            .string()
+            .optional()
+            .describe("Short reason code, e.g. schedule_missing, runtime_repair, rate_limited"),
+    },
+}, async ({ report_markdown, reason }) => {
+    try {
+        const dir = path.join(s4lStateDir(), "diagnostics");
+        fs.mkdirSync(dir, { recursive: true });
+        const file = path.join(dir, `report-${Date.now()}.md`);
+        fs.writeFileSync(file, report_markdown, "utf-8");
+        const res = await runPython("scripts/send_diagnostic_report.py", [file, reason || "mcp_tool"], { timeoutMs: 20_000 });
+        return jsonContent({
+            ok: res.code === 0,
+            detail: res.code === 0 ? "report shipped" : (res.stderr || res.stdout || "").slice(0, 300),
+            saved_to: file,
+        });
+    }
+    catch (e) {
+        return jsonContent({ ok: false, detail: String(e?.message || e).slice(0, 300) });
+    }
+});
 function runtimeSnapshot() {
     const rt = readRuntime();
     const progress = readProgress();
@@ -2634,8 +2706,19 @@ async function autopilotLoaded() {
 // fires every minute, claims ONE job, runs the pipeline's own prompt as its
 // Claude turn, writes the result back, and stops.
 // ===========================================================================
-const QUEUE_WORKER_PROMPT_VERSION = 7; // v7: universal type-blind worker. ONE task claims `--type any`; per-type execution notes (e.g. the v6 incremental-draft pacing for twitter-prep) moved into claude_job.py TYPE_TO_WORKER_NOTES and ride the prompt sidecar, so the worker prompt never mentions job types. Legacy per-type tasks get this same body on refresh and become interchangeable universal workers.
+const QUEUE_WORKER_PROMPT_VERSION = 8; // v8: worker polls internally (claude_job.py next --wait-seconds) instead of single-shot check-then-die. Empirically verified (2026-07-06) that a single long-running Bash call survives well past the host's ~90s between-tool-call inactivity kill — that timer only fires on MODEL silence, not on one in-flight tool call — so one Bash call can safely poll for QUEUE_WORKER_POLL_SECONDS before giving up. This cuts the every-minute spin-up-empty-then-die husk cycle down to roughly one session per poll window instead of one per cron tick. v7: universal type-blind worker. ONE task claims `--type any`; per-type execution notes (e.g. the v6 incremental-draft pacing for twitter-prep) moved into claude_job.py TYPE_TO_WORKER_NOTES and ride the prompt sidecar, so the worker prompt never mentions job types. Legacy per-type tasks get this same body on refresh and become interchangeable universal workers.
 const QUEUE_WORKER_PROMPT_MARKER = "s4l_queue_worker_prompt_version";
+// How long ONE `next --wait-seconds` call polls before giving up and exiting.
+// 240s (4 min): comfortably inside the 900s single-Bash-call survival verified
+// live on 2026-07-06, and covers a meaningful chunk of the ~8min average
+// real job inter-arrival gap measured on the box, while still keeping each
+// worker session bounded. The cron's `* * * * *` cadence remains the outer
+// safety net for whatever the poll window doesn't catch.
+// COUPLING: scripts/reap_stale_claude_sessions.py's S4L_REAPER_CLAIM_GRACE_SEC
+// default MUST stay >= this value + margin — a claimless session inside this
+// poll window is legitimately still working, not a husk, and a too-tight
+// claim_grace would SIGTERM it mid-poll before it ever gets to claim.
+const QUEUE_WORKER_POLL_SECONDS = 240;
 // One spec per worker task. queueType MUST match scripts/claude_job.py TAG_TO_TYPE.
 const QUEUE_WORKERS = [
     { taskId: WORKER_TASK_ID, queueType: "any", human: "universal queue" },
@@ -2688,9 +2771,9 @@ function autopilotStalled() {
         for (const sub of fs.readdirSync(pendRoot, { withFileTypes: true })) {
             if (!sub.isDirectory())
                 continue;
-            // feedback-digest jobs are latency-insensitive (hourly kicker, retried
-            // forever) and may legitimately queue behind a multi-minute draft job;
-            // aging past the draft threshold there is NOT an autopilot stall.
+            // feedback-digest jobs are latency-insensitive (every-minute kicker,
+            // retried forever) and may legitimately queue behind a multi-minute
+            // draft job; aging past the draft threshold there is NOT an autopilot stall.
             if (sub.name === "feedback-digest")
                 continue;
             const subPath = path.join(pendRoot, sub.name);
@@ -2759,17 +2842,24 @@ function queueWorkerBody(spec) {
             `other tool, or trying to "investigate", STALLS it forever.`,
         ``,
         `PACING — CRITICAL: this unattended session is terminated ~90 seconds after ` +
-            `your LAST tool call (a host inactivity timeout). Make your first tool call ` +
-            `promptly, and if the job's prompt gives you per-item persist commands to run ` +
-            `(its own quick Bash calls), run them as you complete each item instead of ` +
-            `working silently — those calls are what keep the session alive. The prompt ` +
-            `file may begin with a WORKER EXECUTION NOTES header; follow it exactly.`,
+            `your LAST tool call (a host inactivity timeout). That clock only runs BETWEEN ` +
+            `tool calls, not during one — step 1 below is a single Bash call that can ` +
+            `legitimately take several minutes to return, and that is fine. Make your ` +
+            `first tool call promptly, and once you are drafting (step 2), if the job's ` +
+            `prompt gives you per-item persist commands to run (its own quick Bash calls), ` +
+            `run them as you complete each item instead of working silently — those calls ` +
+            `are what keep the session alive. The prompt file may begin with a WORKER ` +
+            `EXECUTION NOTES header; follow it exactly.`,
         ``,
         `Steps:`,
-        `1. Claim the next job. Run this EXACT Bash command:`,
-        `     ${py} ${job} next --type any --prompt-file --state-dir ${sd}`,
-        `   It prints one line of JSON. If it prints "{}" (empty), there is NO work — ` +
-            `report "no jobs" in one line and STOP. You are done.`,
+        `1. Look for the next job. Run this EXACT Bash command and let it run to ` +
+            `completion — it polls internally for up to ${Math.round(QUEUE_WORKER_POLL_SECONDS / 60)} ` +
+            `minutes before giving up, so it may take a while to return. That is normal: ` +
+            `do NOT interrupt it and do NOT make any other tool call while it is running.`,
+        `     ${py} ${job} next --type any --prompt-file --wait-seconds ${QUEUE_WORKER_POLL_SECONDS} --state-dir ${sd}`,
+        `   It prints one line of JSON once it returns. If it prints "{}" (empty), no ` +
+            `job showed up during the whole poll window — report "no jobs" in one line ` +
+            `and STOP. You are done.`,
         `2. Otherwise it prints {"job_id":"...","prompt_file":"...","schema_file":...}. ` +
             `Use the Read tool to read prompt_file; it is the complete, self-contained ` +
             `instruction the pipeline wrote for you. If the Read result says it is partial ` +
@@ -3269,12 +3359,19 @@ async function ensureClaudeReaperInstalled() {
     }
 }
 // ---- launchd feedback digest: card decisions -> learned_preferences ---------
-// Hourly, stdlib-only under SYSTEM python (http_api + learned_preferences use
-// urllib/json only; run_claude.sh resolves the claude CLI itself). A run with
-// no unprocessed review_events for this install is a cheap no-op, so the job
-// is installed unconditionally like the reaper. Content-aware install so an
-// already-installed box picks up changed args on the next Claude boot.
-const FEEDBACK_DIGEST_INTERVAL_SECS = 3600;
+// Every minute, same cadence as com.m13v.social-twitter-cycle (the drafting
+// producer), stdlib-only under SYSTEM python (http_api + learned_preferences
+// use urllib/json only; run_claude.sh resolves the claude CLI itself). A run
+// with no unprocessed review_events for this install is a cheap no-op, so the
+// job is installed unconditionally like the reaper. Content-aware install so
+// an already-installed box picks up changed args on the next Claude boot.
+// (Was hourly from the day this shipped, 2026-07-02, on purpose: the digest
+// was designed as a standalone scheduled batch job, not a per-event trigger.
+// Changed 2026-07-06 to close the gap with edits/feedback sitting unprocessed
+// for up to an hour: every-minute checks are still cheap no-ops between
+// actionable events, since digest_project() only calls Claude when at least
+// one fetched event is actionable.)
+const FEEDBACK_DIGEST_INTERVAL_SECS = 60;
 async function ensureFeedbackDigestInstalled() {
     try {
         if (process.platform !== "darwin")
@@ -3290,7 +3387,7 @@ async function ensureFeedbackDigestInstalled() {
             label: FEEDBACK_DIGEST_LABEL,
             programArgs: ["/usr/bin/python3", path.join(repoDir(), "scripts", "feedback_digest.py")],
             intervalSecs: FEEDBACK_DIGEST_INTERVAL_SECS,
-            runAtLoad: false, // no boot-time Claude runs; the hourly tick is enough
+            runAtLoad: false, // no boot-time Claude runs; the every-minute tick is enough
             stdoutLog: path.join(logDir, "launchd-feedback-digest-stdout.log"),
             stderrLog: path.join(logDir, "launchd-feedback-digest-stderr.log"),
         });
@@ -3507,7 +3604,7 @@ async function scheduleState() {
     try {
         const res = await runPython("scripts/schedule_state.py", [], { timeoutMs: 15_000 });
         const state = JSON.parse(res.stdout.trim()).state;
-        if (state === "ok" || state === "disabled")
+        if (state === "ok" || state === "disabled" || state === "stalled")
             return state;
         return "missing";
     }
@@ -3741,23 +3838,81 @@ function startLocalPanel() {
         });
     });
 }
+function panelEndpointPath() {
+    return path.join(process.env.HOME || os.homedir(), ".social-autoposter-mcp", "panel-endpoint.json");
+}
+function isPidAlive(pid) {
+    try {
+        process.kill(pid, 0);
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+function readPanelEndpoint() {
+    try {
+        return JSON.parse(fs.readFileSync(panelEndpointPath(), "utf-8"));
+    }
+    catch {
+        return null;
+    }
+}
 // Publish the loopback URL to stable files so out-of-process readers can find
 // the ephemeral port without scraping `lsof`:
 //   - panel-url            plain text, for the Claude Code side-panel reverse proxy.
 //   - panel-endpoint.json  richer (url + version + pid), for the menu bar app,
 //                          which POSTs /tool/<name> here for live data.
 // Best-effort: a write failure never blocks the panel (readers re-check /health).
+//
+// panel-endpoint.json is a SINGLE shared file that every S4L MCP process writes
+// to on boot (Claude Desktop/Cowork, a Claude Code side-panel session, the
+// ~/.s4l-worker queue runner, ...). Startup here is eager (see main(), "Eagerly
+// start the loopback panel server") so even a one-shot queue-worker invocation
+// that lives for well under a minute claims this file, then exits and leaves it
+// pointing at a dead pid until some other process happens to overwrite it. The
+// menu bar depends on this file to find a server to POST approved drafts to
+// (s4l_state.py loopback_tool), so a dead pointer silently strands approved
+// drafts (post_failed: loopback_unreachable) until pure chance fixes the file.
+// Fix: don't steal the slot from an existing registrant that's still alive —
+// last-writer-wins only among writers that found a dead (or absent) entry.
 function writePanelUrl(url) {
     try {
         const dir = path.join(process.env.HOME || os.homedir(), ".social-autoposter-mcp");
         fs.mkdirSync(dir, { recursive: true });
         fs.writeFileSync(path.join(dir, "panel-url"), url, "utf-8");
-        fs.writeFileSync(path.join(dir, "panel-endpoint.json"), JSON.stringify({ url, pid: process.pid, version: VERSION, started_at: new Date().toISOString() }, null, 2) + "\n", "utf-8");
+        const existing = readPanelEndpoint();
+        if (existing?.pid && existing.pid !== process.pid && isPidAlive(existing.pid)) {
+            // Someone else already holds a live registration (most likely a longer-
+            // lived session than us) — don't clobber it. Our own panel is still up
+            // and fully usable via `url` for anything that already has it (e.g. this
+            // process's own Code side-panel proxy); we just don't publish ourselves
+            // as THE shared menu-bar target.
+            return;
+        }
+        fs.writeFileSync(panelEndpointPath(), JSON.stringify({ url, pid: process.pid, version: VERSION, started_at: new Date().toISOString() }, null, 2) + "\n", "utf-8");
     }
     catch (e) {
         console.error("[social-autoposter-mcp] writePanelUrl failed:", e?.message || e);
     }
 }
+// Relinquish panel-endpoint.json on clean exit if we currently own it, so a
+// short-lived process (typical for the ~/.s4l-worker queue runner or a one-off
+// Claude Code session) never leaves a dead pid lingering as a false-positive
+// registrant — the next process to check sees "nothing registered" (clean,
+// correctly reported as unreachable) rather than a stale pointer that only
+// gets fixed by chance when something else happens to boot.
+process.on("exit", () => {
+    try {
+        const existing = readPanelEndpoint();
+        if (existing?.pid === process.pid) {
+            fs.unlinkSync(panelEndpointPath());
+        }
+    }
+    catch {
+        // best-effort; nothing to do if it's already gone or unreadable
+    }
+});
 // The owned state dir, honoring S4L_STATE_DIR (matches menubar/s4l_state.py).
 function s4lStateDir() {
     return (process.env.S4L_STATE_DIR ||
@@ -4149,14 +4304,27 @@ function scheduleShellLockRelease() {
         releaseShellBrowserLock();
     }, SHELL_LOCK_GRACE_MS);
 }
-// SIGKILL a live scan holding the shell browser lock so the post takes the browser
-// at once. Best-effort; only ever targets a run-twitter-cycle.sh.
+// SIGKILL whatever live process holds the shell browser lock so the post takes
+// the browser at once. Universal preemption (2026-07-07, explicit user call):
+// posting always wins over ANY other CLI Twitter job — the discovery scan,
+// DM engagement, DM outreach, thread posting, follow-up scans, everything.
+// This is a deliberate, informed tradeoff, not an oversight: unlike the scan
+// (read-only, relaunches every minute, nothing to lose), several of these
+// jobs are mid-*send* when they hold this lock (engage-twitter.sh Phase B
+// replies, dm-outreach-twitter.sh / engage-dm-replies.sh send DMs,
+// run-twitter-threads.sh posts a multi-tweet thread). Killing one of those at
+// the wrong instant can leave an action landed on X with its "we did this"
+// bookkeeping never written, so it silently retries and double-sends next
+// cycle — the same class of bug this file's ghost-post handling exists to
+// avoid, just now possible for DMs/threads too. Accepted in exchange for
+// posting never waiting on anything. Best-effort; never throws.
 function preemptScanHoldingBrowser() {
     try {
         const pid = shellLockHolderPid();
-        if (pid && pidAlive(pid) && pidIsScan(pid)) {
-            console.error(`[post] preempting cross-process scan holding the twitter-browser lock (pid ${pid}) — SIGKILL tree`);
-            logPostEvent(`preempt_scan_holding_browser scan_pid=${pid}`);
+        if (pid && pidAlive(pid)) {
+            const label = pidIsScan(pid) ? "scan" : "peer job";
+            console.error(`[post] preempting cross-process ${label} holding the twitter-browser lock (pid ${pid}) — SIGKILL tree`);
+            logPostEvent(`preempt_holder_holding_browser pid=${pid} kind=${label}`);
             sigkillScanTree(pid);
         }
     }
@@ -4164,9 +4332,31 @@ function preemptScanHoldingBrowser() {
         /* best effort */
     }
 }
-// Take (or extend) the shell browser lock for the batch. Preempts a scan holder
-// with SIGKILL; never steals from a live non-scan holder (a peer poster) — there
-// it returns false and posting proceeds unguarded (no worse than before).
+// Take (or extend) the shell browser lock for the batch, so posting is aware of
+// EVERY CLI Twitter job, not just the discovery scan. The lock dir itself is the
+// source of truth: 8+ scripts (engage-twitter.sh, dm-outreach-twitter.sh,
+// run-twitter-threads.sh, engage-dm-replies.sh, scan-twitter-followups.sh,
+// refresh-twitter-following.sh, audit.sh, invent-supply-test.sh, in addition to
+// run-twitter-cycle.sh) all take this exact dir before touching the shared
+// harness Chrome, so whoever holds it is doing real browser work by construction
+// — there is no per-script allowlist to maintain. 2026-07-07 incident: only
+// run-twitter-cycle.sh was ever recognized as preemptable, so posting fell
+// through to "proceed unguarded" against every OTHER script and collided with a
+// LIVE engage-twitter.sh (DM/mentions engagement) mid-reply — both processes
+// reused the same open x.com tab (get_browser_and_page prefers a reusable
+// Twitter tab), so engage-twitter.sh's own navigation yanked the composer away
+// mid-type and got one candidate wrongly classified tweet_unavailable.
+//
+// UNIVERSAL PREEMPTION (2026-07-07, explicit user call, superseding the
+// wait-for-non-scan-peers version that briefly shipped in rc.13): posting
+// SIGKILLs whatever holds this lock, full stop — no waiting on anyone,
+// scan or not. Traded away deliberately: several of these jobs are mid-*send*
+// when they hold the lock (DM outreach/replies, thread posting, mention
+// replies), so killing one at the wrong instant can leave an action landed on
+// X with its own "we did this" bookkeeping never written -> a silent retry
+// double-sends next cycle, the same class of bug this file's ghost-post
+// handling exists to guard against. Accepted in exchange for posting never
+// blocking on anything else running.
 async function acquireShellBrowserLock() {
     // A new post cancels any pending grace-release and EXTENDS the existing hold.
     cancelScheduledShellLockRelease();
@@ -4190,25 +4380,22 @@ async function acquireShellBrowserLock() {
             // Write the pid IMMEDIATELY (sync) so the dir is never observably pid-less.
             fs.writeFileSync(path.join(TW_BROWSER_LOCK_DIR, "pid"), String(process.pid));
             fs.writeFileSync(path.join(TW_BROWSER_LOCK_DIR, "expires_at"), String(Math.floor(Date.now() / 1000) + 1800));
-            console.error(`[post] holding twitter-browser shell lock pid=${process.pid} — scans queue behind the post`);
+            console.error(`[post] holding twitter-browser shell lock pid=${process.pid} — every other CLI Twitter job yields`);
             return true;
         }
         catch {
-            // Dir exists. Reclaim if the holder is dead; SIGKILL-preempt if it's a scan;
-            // otherwise (a live peer poster) leave it and post unguarded.
+            // Dir exists. Reclaim if the holder is dead; SIGKILL-preempt unconditionally
+            // otherwise — scan or not, posting always wins.
             const pid = shellLockHolderPid();
             if (!pid || !pidAlive(pid)) {
                 rmShellLockDir();
             }
-            else if (pidIsScan(pid)) {
-                logPostEvent(`preempt_scan_on_lock_acquire scan_pid=${pid} attempt=${attempt}`);
-                sigkillScanTree(pid); // SIGKILL — scans trap SIGTERM and survive it
+            else {
+                logPostEvent(`preempt_holder_on_lock_acquire pid=${pid} attempt=${attempt}`);
+                sigkillScanTree(pid); // SIGKILL — these jobs don't reliably yield to SIGTERM
                 await sleepMs(300);
                 rmShellLockDir();
             }
-            else {
-                return false; // a real peer holds it — don't steal; proceed
-            }
             await sleepMs(200);
         }
     }