@m13v/s4l 1.6.204-rc.7 → 1.6.204

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);
@@ -866,6 +871,38 @@ async function ensureTwitterBrowserForPost() {
     });
 }
 async function postApproved(batchId, plan) {
+    // Drain serialization (2026-07-06 incident). Every call drains the WHOLE
+    // approved backlog, so overlapping drains are pure waste and actively harmful:
+    // a Claude restart mid-drain at 00:25Z left 10 landed replies unstamped, then
+    // restart recovery + per-approval calls launched 8 concurrent approved=14
+    // drains that re-attempted already-replied threads, fought over the browser
+    // lock, and clobbered each other's posted stamps. Wait for any in-flight drain
+    // (ours via `postingActive`, a sibling MCP's via the posting flag on disk)
+    // instead of stacking a new one. 8-minute cap: comfortably above a normal
+    // drain, comfortably below the menu bar's 900s loopback timeout so a waiting
+    // call still returns to its caller. After a wait, RE-READ the plan so the
+    // peer's posted/terminal stamps shrink our backlog before we attempt anything.
+    {
+        const gateDeadline = Date.now() + 8 * 60_000;
+        let waited = false;
+        while ((postingActive || isPeerDrainActive()) && Date.now() < gateDeadline) {
+            waited = true;
+            await sleepMs(5000);
+        }
+        if (postingActive || isPeerDrainActive()) {
+            return {
+                attempted: 0,
+                exit_code: 0,
+                summary: "another posting drain has been running for 8+ minutes; approved cards stay " +
+                    "queued in the review store — re-run post_drafts once it finishes",
+            };
+        }
+        if (waited) {
+            const fresh = readPlan(batchId);
+            if (fresh)
+                plan = fresh;
+        }
+    }
     // Post every card the user APPROVED that hasn't already landed or been ruled out.
     // `approved` is now a DURABLE decision (sticky, never cleared by a later call), so
     // filtering out posted/terminal here makes this idempotent: re-running it only
@@ -907,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
@@ -944,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
@@ -1068,10 +1131,52 @@ async function postApproved(batchId, plan) {
     }
     if (touchedPlan) {
         try {
-            writePlan(batchId, plan);
+            // Merge our stamps into a FRESH read of the store instead of rewriting the
+            // whole plan from the copy we took minutes ago. The old whole-file write
+            // was last-writer-wins: while this batch posted, the menubar (decision
+            // re-stamps) and any peer drain also wrote the store, and whichever run
+            // finished last erased the others' posted flags (2026-07-06: card 344877
+            // posted at 00:29Z ended `posted=None, terminal=duplicate_thread_pre_post`
+            // after a later run's stale write). Merge rules: `posted` is sticky and
+            // wins over terminal; `terminal` never overwrites a fresh `posted=true`.
+            // Fallback: candidates without a candidate_id can't be matched into the
+            // fresh copy, so keep the legacy whole-plan write for those older plans.
+            const mergeable = approved.every((c) => c.candidate_id !== undefined && c.candidate_id !== null);
+            const fresh = mergeable ? readPlan(batchId) : null;
+            if (fresh && Array.isArray(fresh.candidates)) {
+                const freshById = new Map();
+                fresh.candidates.forEach((c) => {
+                    if (c.candidate_id !== undefined && c.candidate_id !== null)
+                        freshById.set(String(c.candidate_id), c);
+                });
+                for (const c of approved) {
+                    const f = freshById.get(String(c.candidate_id));
+                    if (!f)
+                        continue;
+                    if (c.posted === true) {
+                        f.posted = true;
+                        f.terminal = false;
+                        if (c.our_url)
+                            f.our_url = c.our_url;
+                    }
+                    else if (c.terminal === true && f.posted !== true) {
+                        f.terminal = true;
+                        f.terminal_reason = c.terminal_reason;
+                    }
+                }
+                writePlan(batchId, fresh);
+            }
+            else {
+                writePlan(batchId, plan);
+            }
         }
         catch {
-            /* best effort */
+            try {
+                writePlan(batchId, plan);
+            }
+            catch {
+                /* best effort */
+            }
         }
     }
     // Post failures are HANDLED in the pipeline (it returns a count, never throws),
@@ -1246,7 +1351,8 @@ async function seedSearchQueriesForProject(project, rawQueries) {
 tool("engagement_mode", {
     title: "Choose engagement lanes (personal brand + optional product promotion)",
     description: "Set or read the engagement LANES the autopilot drafts in. There are TWO independent lanes that " +
-        "can BOTH be on (the cycle then splits 50/50): PERSONAL BRAND (organic, link-free engagement in " +
+        "can BOTH be on (the cycle then splits per the configurable lane split, default 50/50 — see " +
+        "action:'split'): PERSONAL BRAND (organic, link-free engagement in " +
         "the user's own voice — ON by default) and PRODUCT PROMOTION (the marketing pipeline, link " +
         "replies — OFF by default, opt-in). This is a SETUP step: AFTER X is connected, the profile " +
         "is scanned (for VOICE), and the user has answered the DICTATION interview (for TOPICS + corpus), " +
@@ -1261,9 +1367,9 @@ tool("engagement_mode", {
         "project_config afterward. The user flips either lane any time from the menu-bar checkmarks.",
     inputSchema: {
         action: z
-            .enum(["get", "set", "toggle"])
+            .enum(["get", "set", "toggle", "split"])
             .optional()
-            .describe("get = read current lane flags + persona status. set = record the user's chosen lanes (provisions the persona). toggle = lightweight flip of ONE lane (pass `lane`); mode.json only, no persona work — the dashboard/menu-bar quick toggle."),
+            .describe("get = read current lane flags + persona status + lane split. set = record the user's chosen lanes (provisions the persona). toggle = lightweight flip of ONE lane (pass `lane`); mode.json only, no persona work — the dashboard/menu-bar quick toggle. split = set the personal-brand share of both-lanes-on cycles (pass `split`); mode.json only — the dashboard slider."),
         personal_brand: z
             .boolean()
             .optional()
@@ -1276,6 +1382,12 @@ tool("engagement_mode", {
             .enum(["personal_brand", "promotion"])
             .optional()
             .describe("action:'toggle' — which single lane to flip."),
+        split: z
+            .union([z.number(), z.string()])
+            .optional()
+            .describe("action:'split' (or alongside action:'set') — the personal-brand SHARE of cycles when both " +
+            "lanes are on: 0.7, 70, or '70%' all mean 70% personal brand / 30% promotion. Clamped to " +
+            "0..1; ignored while only one lane is on (single-lane states run that lane every cycle)."),
         mode: z
             .enum(["personal_brand", "promotion"])
             .optional()
@@ -1325,11 +1437,47 @@ tool("engagement_mode", {
             return { personal_brand: true, promotion: false };
         }
     };
+    const readSplit = async () => {
+        const r = await runPython("scripts/s4l_mode.py", ["split"], { timeoutMs: 15_000 });
+        try {
+            const v = Number(JSON.parse((r.stdout || "").trim()).personal_brand_share);
+            return Number.isFinite(v) ? v : 0.5;
+        }
+        catch {
+            return 0.5;
+        }
+    };
     if (action === "get") {
         const flags = await readFlags();
         const persona = findPersonaProject();
         const mode = flags.personal_brand ? "personal_brand" : "promotion";
-        return jsonContent({ flags, mode, persona: persona ? persona.name : null });
+        return jsonContent({
+            flags,
+            mode,
+            personal_brand_share: await readSplit(),
+            persona: persona ? persona.name : null,
+        });
+    }
+    // Set the both-lanes-on split (the dashboard slider): just rewrite
+    // mode.json via s4l_mode.py — NO persona provisioning, same weight class
+    // as action:'toggle'.
+    if (action === "split") {
+        if (args.split === undefined || args.split === null || args.split === "") {
+            return jsonContent({ personal_brand_share: await readSplit() });
+        }
+        const res = await runPython("scripts/s4l_mode.py", ["split", String(args.split)], {
+            timeoutMs: 15_000,
+        });
+        if (res.code !== 0) {
+            const tail = (res.stderr || res.stdout).trim().split("\n").slice(-1)[0] || "unknown error";
+            return textContent(`Could not set the lane split: ${tail}`);
+        }
+        try {
+            return jsonContent(JSON.parse((res.stdout || "").trim()));
+        }
+        catch {
+            return jsonContent({ personal_brand_share: await readSplit() });
+        }
     }
     // Lightweight flip of ONE lane (the dashboard/menu-bar quick toggle): just
     // rewrite mode.json via s4l_mode.py — NO persona provisioning. Mirrors the
@@ -1362,7 +1510,7 @@ tool("engagement_mode", {
     }
     if (!personalBrand && !promotion) {
         return textContent("At least one lane must be on. personal_brand is the default; set promotion:true if the user " +
-            "also wants product promotion (both on -> the cycle splits 50/50).");
+            "also wants product promotion (both on -> the cycle splits per the lane split, default 50/50).");
     }
     const mode = personalBrand ? "personal_brand" : "promotion";
     recordOnboardingAttempt("mode_chosen", { personal_brand: personalBrand, promotion });
@@ -1372,6 +1520,11 @@ tool("engagement_mode", {
         blockOnboardingMilestone("mode_chosen", "mode_set_failed", tail, { personal_brand: personalBrand, promotion });
         return textContent(`Couldn't save the engagement lanes: ${tail}`);
     }
+    // Optional lane split rider on 'set' (best-effort: the lanes are saved
+    // either way, and the split keeps its previous/default value on failure).
+    if (args.split !== undefined && args.split !== null && args.split !== "") {
+        await runPython("scripts/s4l_mode.py", ["split", String(args.split)], { timeoutMs: 15_000 });
+    }
     // NOTE (2026-07-06): the draft-only flag (mode.json {"draft_only": false} —
     // promotion cycles POST autonomously instead of drafting cards) is
     // DELIBERATELY NOT exposed on this tool or any user surface. It is an
@@ -1454,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 " +
@@ -1754,9 +1908,12 @@ tool("project_config", {
                 "a phrase bank + things they avoid, and their icp. The scan is BACKWARD-LOOKING (only what " +
                 "they already posted) so it is the source for VOICE, not the primary source for topics. " +
                 "SECOND (the DICTATION interview — this is where TOPICS + grounding corpus come from, do NOT " +
-                "skip it and do NOT infer topics from the scan alone): tell the user to answer ALL of the " +
+                "skip it and do NOT infer topics from the scan alone): invite the user to answer the " +
                 "following in ONE spoken dictation (the Claude input box already supports dictation, so they " +
-                "just talk once and you split the answers into fields). Ask verbatim, as a single numbered " +
+                "just talk once and you split the answers into fields). KEEP THE FRAMING CHILL: this is a " +
+                "casual brain-dump, not a form. No pressure; they can answer as much or as little as they " +
+                "like, skip anything, and come back to the rest whenever they feel like it. Preface the list " +
+                "with one short low-key line saying exactly that, then ask verbatim, as a single numbered " +
                 "list:\n" +
                 "  1. Who are you, and what do you want to be known for? (-> description)\n" +
                 "  2. What subjects could you talk about for an hour, work and non-work? (-> search_topics: " +
@@ -1775,12 +1932,15 @@ tool("project_config", {
                 "Then SYNTHESIZE the fields from their dictation: search_topics comes PRIMARILY from answer 2 " +
                 "(fold in recurring scan themes only as reinforcement); description/content_angle/voice from " +
                 "the rest. Keep their RAW transcript VERBATIM as content_corpus (do NOT paraphrase; their " +
-                "actual numbers, opinions, and phrasing are what make drafts sound like them). If the user " +
-                "declines or gives nothing usable, fall back to scan-derived topics. " +
+                "actual numbers, opinions, and phrasing are what make drafts sound like them). If they " +
+                "answer only some questions, take what they gave, continue without nagging, and mention once " +
+                "that they can answer the rest any time later to make drafts sound more like them. If the " +
+                "user declines or gives nothing usable, fall back to scan-derived topics. " +
                 "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. " +
@@ -1819,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' ` +
@@ -2332,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();
@@ -2507,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" },
@@ -2561,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);
@@ -2632,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 ` +
@@ -3142,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")
@@ -3163,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"),
         });
@@ -3380,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";
     }
@@ -3614,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 ||
@@ -3742,6 +4024,22 @@ function isPostingFlagFresh() {
         return false;
     }
 }
+// True when a DIFFERENT process holds a fresh posting flag — i.e. a sibling MCP
+// instance is mid-drain. Our own fresh flag doesn't count: same-process
+// re-entrancy is covered by the in-memory `postingActive`, and a leftover flag
+// from our own earlier drain (a crash before the finally cleared it) must not
+// deadlock us against ourselves.
+function isPeerDrainActive() {
+    try {
+        const j = JSON.parse(fs.readFileSync(postingFlagPath(), "utf-8"));
+        if (typeof j?.expires_at !== "number" || j.expires_at <= Date.now())
+            return false;
+        return typeof j?.pid === "number" && j.pid !== process.pid;
+    }
+    catch {
+        return false;
+    }
+}
 // activity.json: a tiny "what's running right now" signal the menu bar reads to
 // show a loading spinner + label (scanning / drafting / posting / …). Written by
 // long-running tools, cleared when they finish. Best-effort; absence == idle.
@@ -4006,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);
         }
     }
@@ -4021,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();
@@ -4047,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);
         }
     }