social-autoposter 1.6.71 → 1.6.72

package/mcp/dist/index.js

@@ -2,9 +2,9 @@
 // social-autoposter MCP server (X/Twitter rail).
 //
 // Core tools:
-//   draft_cycle  - scan + draft, return all drafts as a numbered table for the
-//                  user to review in chat (posts nothing).
-//   post_drafts  - post the drafts the user chose by number from a batch.
+//   scan_candidates - scan + score X threads, return the top candidates (no draft, no post).
+//   submit_drafts   - take the replies you drafted and queue them for review (posts nothing).
+//   post_drafts     - post the drafts the user chose by number from a batch.
 //   get_stats    - read-only post + engagement stats.
 //
 // THIN wrapper. The pipeline brain (scan, score, drafting prompts, posting)
@@ -152,7 +152,8 @@ const server = new McpServer({
         "ONBOARDING IS A TERMINAL GOAL. When the user asks to set up, install, configure, or onboard " +
         "social-autoposter, keep taking the next safe action until the owned runtime is ready, a " +
         "project is fully configured with seeded search topics, X is connected with its real handle, " +
-        "and `draft_cycle` has verified the pipeline without posting. Do not ask whether to inspect " +
+        "and the draft path (`scan_candidates` -> draft -> `submit_drafts`) has verified the pipeline " +
+        "without posting. Do not ask whether to inspect " +
         "status, install or repair owned dependencies, choose an auto-detected browser profile, connect " +
         "X, scan the profile, research the product website, save conservative inferred fields, seed " +
         "topics, retry a recoverable failure, or run draft-only verification. Do those things. The " +
@@ -162,25 +163,28 @@ const server = new McpServer({
         "when no product can be identified from config, context, the X profile, or public research, " +
         "or pause for an unavoidable interactive login or OS prompt. Never post drafts or enable " +
         "autopilot during setup unless the user explicitly requested that. When setup reaches done — " +
-        "runtime ready, a project configured with seeded topics, X connected, and `draft_cycle` " +
-        "verified — call the `dashboard` tool so the user sees the finished setup rendered, then give " +
+        "runtime ready, a project configured with seeded topics, X connected, and the draft path " +
+        "(scan_candidates -> draft -> submit_drafts) verified — call the `dashboard` tool so the user " +
+        "sees the finished setup rendered, then give " +
         "the completion summary.\n\n" +
         "BE PROACTIVE ABOUT MARKETING MOMENTS. Whenever the user ships, finishes, merges, or releases " +
         "something worth talking about in this session (a new feature, a launch, a long-awaited fix, a " +
-        "milestone), don't wait to be asked: offer to tell the world by running `draft_cycle` to post " +
-        "about it. A feature nobody hears about is wasted distribution. Use judgment, suggest it for " +
+        "milestone), don't wait to be asked: offer to tell the world by running a draft cycle " +
+        "(`scan_candidates` -> draft the replies -> `submit_drafts`) about it. A feature nobody hears " +
+        "about is wasted distribution. Use judgment, suggest it for " +
         "genuinely shareable moments, not routine refactors, chores, or internal cleanup.\n\n" +
         "STAY CURRENT. At the start of a session, and again right after you help the user ship/merge/" +
         "release, call the `runtime` tool (action:'version'). If `update_available` is true, tell the " +
         "user and offer to run `runtime` with action:'update'. The `project_config` tool's status also " +
         "surfaces `update_available` and an `update_hint`.\n\n" +
-        "TYPICAL FLOW: `project_config` (configure OR edit the project, and connect X) -> `draft_cycle` " +
-        "(scan + review a batch; the user approves / edits / skips every draft in a single form) -> " +
+        "TYPICAL FLOW: `project_config` (configure OR edit the project, and connect X) -> `scan_candidates` " +
+        "(get the top threads to reply to) -> draft the replies yourself -> `submit_drafts` (queue them " +
+        "for review; nothing posts until the user approves) -> `post_drafts` (post the approved ones) -> " +
         "`get_stats` (see performance). Run `project_config` first; the other tools refuse until a " +
         "project is fully configured. To change anything about a project later, call `project_config` " +
         "again with the project's name and just the changed fields — there is no separate config editor.\n\n" +
         "RENDER THE DASHBOARD AFTER ACTIONS. After any state-changing or results-producing tool call " +
-        "(`draft_cycle`, `post_drafts`, `get_stats`), end your turn by " +
+        "(`scan_candidates`, `submit_drafts`, `post_drafts`, `get_stats`), 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.",
 });
@@ -254,28 +258,28 @@ function blockedReasonMessage(reason) {
                 "couldn't run. (It DID find and rank threads, it just couldn't draft replies.) This " +
                 "CLI uses its own login, separate from Claude Desktop. To fix it, open a terminal and run:\n\n" +
                 "    claude\n\n" +
-                "then `/login` inside it (or run `claude setup-token`). Once it's logged in, run draft_cycle again.");
+                "then `/login` inside it (or run `claude setup-token`). Once it's logged in, run scan_candidates again.");
         case "monthly_limit":
         case "daily_limit":
         case "rate_limit_5h":
             return (`The drafting step hit an Anthropic usage limit (${reason}), so no replies were drafted. ` +
-                "Wait for the limit to reset, then run draft_cycle again.");
+                "Wait for the limit to reset, then run scan_candidates again.");
         case "no_search_topics":
             return ("This project has no search topics yet, so there was nothing to scan. Topics live in the " +
                 "DB (project_search_topics) and are seeded from your project's `search_topics` when you " +
                 "configure it. Re-run the `project_config` tool for this project with a `search_topics` list " +
                 "(comma-separated keywords/phrases your buyers tweet about); it seeds them automatically, then " +
-                "run draft_cycle again.");
+                "run scan_candidates again.");
         case "topics_api_unreachable":
             return ("Couldn't reach the search-topics service to load this project's topics, so the cycle stopped " +
-                "before scanning. This is usually a transient backend/network issue. Try draft_cycle again in a " +
+                "before scanning. This is usually a transient backend/network issue. Try scan_candidates again in a " +
                 "moment; if it persists, check connectivity to the autoposter backend.");
         case "credit_balance":
             return ("The drafting step failed because the Anthropic account is out of credits. " +
-                "Add credits, then run draft_cycle again.");
+                "Add credits, then run scan_candidates again.");
         default:
             return (`The drafting step failed (${reason}) and produced no drafts. ` +
-                "Check skill/logs/twitter-cycle-*.log on this machine for details, then run draft_cycle again.");
+                "Check skill/logs/twitter-cycle-*.log on this machine for details, then run scan_candidates again.");
     }
 }
 // Turn a raw run-twitter-cycle.sh stdout line into a short, user-facing
@@ -647,7 +651,7 @@ tool("project_config", {
         "Call with status:true (or no name) to list every configured project, its remaining fields, AND " +
         "whether X is connected. Use config, conversation context, profile_scan, and website research " +
         "before asking for fields. Ask only if no product can be identified or an interactive login is " +
-        "unavoidable. The draft_cycle and get_stats tools refuse to run until a project is " +
+        "unavoidable. The scan_candidates and get_stats tools refuse to run until a project is " +
         "fully set up.",
     inputSchema: {
         status: z.boolean().optional(),
@@ -811,7 +815,7 @@ tool("project_config", {
             next_step: r.connected
                 ? "X is connected. Next, run project_config action:'profile_scan' to read this account's bio + recent " +
                     "posts + replies and draft the project's voice/icp/search_topics in the user's own register " +
-                    "before saving. Then run draft_cycle once the project is fully set up."
+                    "before saving. Then run a draft cycle (scan_candidates -> draft -> submit_drafts) once the project is fully set up."
                 : r.state === "needs_login"
                     ? "The user must finish signing in to x.com in the Chrome window that just opened. Tell " +
                         "them that single required action, then call project_config action:'connect_x', confirm:true again."
@@ -918,7 +922,7 @@ tool("project_config", {
                         (x.connected ? "" : " X is not connected yet either — detect_x_sources, warn about keychain prompts, then run connect_x with confirm:true without a separate permission turn.")
                     : projects.every((p) => p.ready)
                         ? (x.connected
-                            ? "All configured projects are ready and X is connected. Run draft_cycle now to verify end to end without posting. After it verifies, call the `dashboard` tool so the user sees the finished setup."
+                            ? "All configured projects are ready and X is connected. Run scan_candidates, draft a reply or two, and submit_drafts now to verify end to end without posting. After it verifies, call the `dashboard` tool so the user sees the finished setup."
                             : "All configured projects are ready, but X is NOT connected — posting needs a logged-in " +
                                 "x.com session. Detect sources and run project_config action:'connect_x', confirm:true; do not ask whether to proceed.")
                         : "Some projects are missing required fields (see each project's missing_required). Derive them from config, context, profile_scan, and website research, then call project_config again. Ask only if a required field is genuinely unknowable." +
@@ -960,13 +964,13 @@ tool("project_config", {
                     topic_count: topicCount,
                 });
                 seedNote = m
-                    ? ` Seeded ${m[1]} search topic(s) into the DB (new: ${m[2]}, updated: ${m[3]}), so draft_cycle has a topic universe to work with.`
-                    : " Seeded search topics into the DB so draft_cycle has a topic universe to work with.";
+                    ? ` Seeded ${m[1]} search topic(s) into the DB (new: ${m[2]}, updated: ${m[3]}), so scan_candidates has a topic universe to work with.`
+                    : " Seeded search topics into the DB so scan_candidates has a topic universe to work with.";
             }
             else {
                 const tail = (seed.stderr || seed.stdout).trim().split("\n").slice(-1)[0] || "unknown error";
                 blockOnboardingMilestone("topics_seeded", "topic_seed_failed", tail, { exit_code: seed.code });
-                seedNote = ` (Heads up: couldn't seed search topics into the DB yet — ${tail}. draft_cycle will tell you clearly if topics are missing.)`;
+                seedNote = ` (Heads up: couldn't seed search topics into the DB yet — ${tail}. scan_candidates will tell you clearly if topics are missing.)`;
             }
             // Cold-start QUERY supply: fan the seeded topics out into >=30 real X
             // search queries (project_search_queries) so the deterministic Phase 1
@@ -1030,7 +1034,7 @@ tool("project_config", {
             note: (result.ready
                 ? `Project '${result.project}' is fully configured.${seedNote} Next: if X is not connected, ` +
                     `detect sources, warn about keychain prompts, and call project_config with ` +
-                    `action:'connect_x', confirm:true immediately. Once X is connected, run draft_cycle to ` +
+                    `action:'connect_x', confirm:true immediately. Once X is connected, run scan_candidates -> submit_drafts to` +
                     `verify without posting. Do not enable autopilot unless explicitly requested.`
                 : `Saved what you provided for '${result.project}'. Still need: ${result.missing_required.join(", ")}. ` +
                     `First derive those fields from existing context, profile_scan, and website research, then ` +
@@ -1042,145 +1046,29 @@ tool("project_config", {
         return textContent(`Setup failed: ${e.message}`);
     }
 });
-// ---- draft_cycle: scan + draft, then hand the batch to the user for review.
-// Posting is a SEPARATE step (post_drafts) so the user picks by number in chat.
-// This host doesn't support elicitation, so there is no in-tool form: the model
-// relays the table and asks which to post / edit, then calls post_drafts.
-tool("draft_cycle", {
-    title: "Draft an X reply cycle",
-    description: "Scan X and draft replies on this machine, then return ALL drafts as a numbered table " +
-        "for review. This tool POSTS NOTHING. Show the table to the user and ask which numbers " +
-        "to post and which to rewrite, then call `post_drafts` with their decision and the " +
-        "returned batch_id. The table MUST show, per draft: the thread being replied to " +
-        "(thread_text), the draft reply, and the link target (link_url) when present; never " +
-        "drop those columns. Flow: discover -> draft -> review in chat -> post_drafts. " +
-        "After returning the table, call the `dashboard` tool so the user sees the updated state.",
-    inputSchema: {
-        project: z
-            .string()
-            .optional()
-            .describe("Which configured project to draft for. Optional when only one project is set up; required when several are."),
-    },
-}, async ({ project }, extra) => {
-    const r = resolveProject(project);
-    if (!r.ok)
-        return textContent(r.message);
-    const proj = r.project;
-    recordOnboardingAttempt("draft_verified");
-    // Live progress so the chat doesn't sit on a frozen spinner for minutes.
-    // Two channels, both best-effort (a sink failure must never fail the cycle):
-    //   1. notifications/message — a log line; the host records it (and some
-    //      clients show it in a log view). Works with no client opt-in.
-    //   2. notifications/progress — drives the status text under the running
-    //      tool. Only valid when the client supplied a progressToken on the
-    //      request, so it's guarded on that.
-    const progressToken = extra?._meta?.progressToken;
-    const sendProgress = async (message, step) => {
-        try {
-            await extra.sendNotification({
-                method: "notifications/message",
-                params: { level: "info", logger: "draft_cycle", data: message },
-            });
-        }
-        catch {
-            /* ignore */
-        }
-        if (progressToken !== undefined) {
-            try {
-                await extra.sendNotification({
-                    method: "notifications/progress",
-                    params: { progressToken, progress: step, message },
-                });
-            }
-            catch {
-                /* ignore */
-            }
-        }
-    };
-    const drafted = await produceDrafts(proj, (message, step) => {
-        void sendProgress(message, step);
-    });
-    if (drafted.blocked || !drafted.batchId) {
-        blockOnboardingMilestone("draft_verified", "draft_cycle_blocked", drafted.blocked ?? "No drafts produced.", { outcome: "blocked" });
-        return textContent(drafted.blocked ?? "No drafts produced.");
-    }
-    const plan = readPlan(drafted.batchId);
-    if (!plan || !(plan.candidates && plan.candidates.length)) {
-        blockOnboardingMilestone("draft_verified", "draft_batch_empty", `No drafts in batch ${drafted.batchId}.`, { outcome: "empty_batch", draft_count: 0 });
-        return textContent(`No drafts in batch ${drafted.batchId}.`);
-    }
-    const count = plan.candidates.length;
-    completeOnboardingMilestone("draft_verified", {
-        outcome: "review_batch",
-        draft_count: count,
-    });
-    // Fire the menu-bar pop-up review (default). The chat-table review below is
-    // unchanged; both surfaces can approve, de-duped by the plan `posted` flag.
-    writeReviewRequest({
-        batch_id: drafted.batchId,
-        project: proj,
-        count,
-        plan_path: planPath(drafted.batchId),
-        created_at: new Date().toISOString(),
-    });
-    const table = renderDraftsTable(plan);
-    const message = `Drafted ${count} ${count === 1 ? "reply" : "replies"} for "${proj}" ` +
-        `(batch ${drafted.batchId}). NOTHING has been posted yet.\n\n` +
-        `${table}\n\n` +
-        `Show this list to the user and ask which to post and which to edit. When you render ` +
-        `the table, ALWAYS include, for every draft: the thread it replies to (in reply to / ` +
-        `thread_text), the draft text, and the link target (link_url) if present. Do NOT drop ` +
-        `the thread or link columns. Note the literal short link is appended at post time and ` +
-        `an A/B gate may omit it, so present link_url as the target, not a guaranteed final URL. ` +
-        `They can reply however is natural, e.g. "post 1, 3 and 5", "edit 2: <new wording>", ` +
-        `"post all", or "skip all". Editing a draft also posts it. Then call the post_drafts ` +
-        `tool with batch_id "${drafted.batchId}" and their decision (post: [numbers], ` +
-        `edits: [{n, text}], or post_all: true). Do not post anything the user didn't ask for.`;
-    return {
-        content: [{ type: "text", text: message }],
-        structuredContent: {
-            batch_id: drafted.batchId,
-            drafted: count,
-            status: "awaiting_decision",
-            onboarding: onboardingSnapshot(),
-            // Include the actual draft text here, not just a count. Some hosts
-            // (e.g. Claude Desktop) surface ONLY structuredContent to the model and
-            // drop the human-readable `content` table — which left the agent saying
-            // "drafted: 2" with no way to show the drafts. Carrying the drafts in
-            // structuredContent makes them available regardless of host behavior.
-            drafts: (plan.candidates || []).map((c, i) => ({
-                n: i + 1,
-                author: c.thread_author,
-                tweet_url: c.candidate_url,
-                // The original tweet being replied to — reviewer context. Hosts that
-                // surface ONLY structuredContent (Claude Desktop, Fazm Code tab) need
-                // this here or the relayed table loses the thread it's responding to.
-                thread_text: c.thread_text,
-                reply_text: c.reply_text,
-                // Target link only. The literal /r/<code> short link is minted at post
-                // time and an A/B gate may omit it; do not pre-mint here.
-                link_url: c.link_url,
-                style: c.engagement_style,
-                language: c.language,
-            })),
-        },
-    };
-});
+// ---- draft_cycle: DEPRECATED 2026-06-20 (registration removed) -------------
+// Replaced by the scan_candidates -> (agent drafts) -> submit_drafts flow, so the
+// AI drafting now runs in the calling session (on the user's plan) instead of a
+// spawned `claude -p`. post_drafts (below) still posts the approved subset, and
+// submit_drafts completes the onboarding "draft_verified" milestone that this
+// tool used to. The underlying pipeline (run-twitter-cycle.sh) and the
+// produceDrafts() helper are kept as the source those tools reuse; only the
+// draft_cycle tool registration was removed here.
 // ---- post_drafts: post the user's chosen drafts from a batch ---------------
 // Second half of the manual loop. The user reviewed the table from draft_cycle
 // and said which numbers to post / edit; this posts exactly those. Editing a
 // draft implies posting it. Indices are 1-based, matching the table.
 tool("post_drafts", {
     title: "Post chosen drafts",
-    description: "Post the drafts the user approved from a draft_cycle batch. Pass the batch_id from " +
-        "draft_cycle and the user's decision by NUMBER (1-based, matching the table): `post` is " +
+    description: "Post the drafts the user approved from a submit_drafts batch. Pass the batch_id from " +
+        "submit_drafts and the user's decision by NUMBER (1-based, matching the table): `post` is " +
         "the list of draft numbers to post as drafted; `edits` rewrites a draft's text before " +
         "posting it (editing implies posting); `post_all` posts every draft. Only the chosen " +
         "drafts post; anything not listed is left unposted. Call this ONLY after the user has " +
         "told you which drafts they want. After posting, call the `dashboard` tool so the user " +
         "sees the updated state.",
     inputSchema: {
-        batch_id: z.string().describe("The batch_id returned by draft_cycle."),
+        batch_id: z.string().describe("The batch_id returned by submit_drafts."),
         post: z
             .array(z.number().int().positive())
             .optional()
@@ -1194,7 +1082,7 @@ tool("post_drafts", {
 }, async ({ batch_id, post, edits, post_all }) => {
     const plan = readPlan(batch_id);
     if (!plan || !(plan.candidates && plan.candidates.length)) {
-        return textContent(`No drafts found for batch ${batch_id}. Run draft_cycle again to produce a fresh batch.`);
+        return textContent(`No drafts found for batch ${batch_id}. Run scan_candidates then submit_drafts again to produce a fresh batch.`);
     }
     const candidates = plan.candidates;
     const total = candidates.length;
@@ -1847,7 +1735,11 @@ tool("submit_drafts", {
     }
     const finalPlan = readPlan(args.batch_id) ?? plan;
     const count = (finalPlan.candidates || []).length;
-    // Surface to the menu-bar review cards (same contract draft_cycle uses).
+    // Drafts queued = the pipeline verified end-to-end without posting. This is the
+    // onboarding "draft_verified" terminal goal (formerly completed by draft_cycle).
+    if (count > 0)
+        completeOnboardingMilestone("draft_verified", { outcome: "review_batch", draft_count: count });
+    // Surface to the menu-bar review cards (same review plan draft_cycle used).
     writeReviewRequest({
         batch_id: args.batch_id,
         project,
@@ -1867,7 +1759,7 @@ appTool("dashboard", {
         "connection, autopilot state, and 7-day stats, with buttons to run a draft cycle, connect X, " +
         "and refresh. Use when the user asks to see the dashboard, panel, " +
         "status, or controls. ALSO call this at the end of any state-changing or results-producing " +
-        "action (draft_cycle, post_drafts, get_stats) so the user sees the " +
+        "action (scan_candidates, submit_drafts, post_drafts, get_stats) so the user sees the " +
         "updated dashboard. Hosts without UI support get the same data as text.",
     inputSchema: {},
     // fallback_url is set only when the host can't render the ui:// resource and

package/mcp/dist/telemetry.js

@@ -13,7 +13,7 @@ import { repoDir, runPython } from "./repo.js";
 import { VERSION } from "./version.js";
 // Sentry DSN is a client-side identifier (safe to embed, same posture as Fazm's
 // hardcoded Swift DSN). Overridable via env for dev. Empty -> Sentry disabled.
-const EMBEDDED_DSN = "";
+const EMBEDDED_DSN = "https://4d44ac907262c6545cf8681703528d04@o4507617161314304.ingest.us.sentry.io/4511598804336640";
 const SENTRY_DSN = process.env.SAPS_SENTRY_DSN || EMBEDDED_DSN;
 let sentryReady = false;
 export function initSentry() {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "social-autoposter",
-  "version": "1.6.71",
+  "version": "1.6.72",
   "description": "Automated social posting pipeline for Reddit, X/Twitter, LinkedIn, and Moltbook. Install as a Claude Code agent skill.",
   "bin": {
     "social-autoposter": "bin/cli.js"
@@ -87,7 +87,6 @@
     "!scripts/export_kent_handoff.py",
     "!scripts/extract_user_messages_today.py",
     "!scripts/fazm_seo_health.py",
-    "!scripts/fetch_twitter_t1.py",
     "!scripts/fix_mdx_light_mode.py",
     "!scripts/fix_style_lengths_20260601.py",
     "!scripts/fix_svg_paragraph_wrap.py",

package/scripts/sentry_init.py

@@ -15,7 +15,7 @@ import os
 
 # Client-side DSN: safe to embed, same posture as the Node telemetry and Fazm's
 # hardcoded Swift DSN. Overridable via env for dev. Empty -> Sentry disabled.
-_EMBEDDED_DSN = ""
+_EMBEDDED_DSN = "https://4d44ac907262c6545cf8681703528d04@o4507617161314304.ingest.us.sentry.io/4511598804336640"
 
 _initialized = False
 

package/skill/lock.sh

@@ -617,10 +617,9 @@ defer_if_foreign_browser_mcp_active() {
 
 # Explicit early release. Use this when a long-running script only needs the
 # browser for part of its run (e.g. run-twitter-cycle.sh holds the lock for
-# Phase 1 scrape, releases during the 5-min T1 sleep + Phase 2a HTTP poll, then
-# re-acquires before Phase 2b posting). Without this, sibling pipelines waiting
-# on the same profile lock block for the full cycle even when the holder is
-# only sleeping.
+# Phase 1 scrape, releases between Phase 1 and Phase 2b posting, then re-acquires
+# before Phase 2b). Without this, sibling pipelines waiting on the same profile
+# lock block for the full cycle even when the holder is not using the browser.
 release_lock() {
   local name="$1"
   local lock_dir="/tmp/social-autoposter-${name}.lock"

package/skill/run-twitter-cycle.sh

@@ -12,18 +12,14 @@
 #   - scrape tweets via twitter-harness, enrich via fxtwitter -> T0 snapshot
 #   - store all candidates with batch_id and search_topic
 #
-# Sleep 300s.
+# No ripen wait (variant D won the A/B/C/D test 2026-05-31): the cycle goes
+# straight from discovery to drafting. There is NO 5-min sleep and NO fxtwitter
+# T1 re-poll anywhere in the Twitter pipeline. delta_score stays at its T0
+# value and is no longer a gate. Do not re-introduce a ripen/sleep step here.
 #
-# Phase 2 (t=5m):
-#   - re-fetch the same candidates via fxtwitter -> T1 snapshot + delta_score
-#   - SQL gate: floor lowered to delta_score >= 0 so zero-momentum but on-theme
-#     product-discussion tweets (asking for a tool, venting a pain point) can
-#     compete; ranking still favors growth via hybrid sort
-#   - Hybrid sort: ORDER BY (delta_score + product_intent_boost) where
-#     product_intent_boost is +5 when tweet text matches an intent-signal regex
-#     (wish/need/looking for/recommend/alternative/frustrated/etc); raw growth
-#     remains the dominant signal, but a slow-burn "anyone know a tool for..."
-#     tweet now ranks alongside fast-growing news/drama
+# Phase 2 (immediately after Phase 1):
+#   - sort candidates by virality_score DESC (composite predictor stamped at
+#     discovery by score_twitter_candidates.py); no delta floor, no T1 re-poll
 #   - Claude reads top 25 (raised from 15 so the long tail reaches the model),
 #     drops unsuitable, posts every candidate it judges genuinely on-brand
 #     (no per-cycle post cap, no per-project quota)
@@ -412,7 +408,7 @@ python3 "$REPO_DIR/scripts/twitter_batch_phase.py" start "$BATCH_ID" --phase pha
 #      read from the owner's twitter_batches row:
 #        phase0        ->  5 min  (just the salvage SQL)
 #        phase1        -> 20 min  (Claude scan + scrape)
-#        phase2a       -> 20 min  (5 min sleep + HTTP T1 poll)
+#        phase2a       -> 20 min  (browser-lock handoff window; no ripen wait since 2026-05-31)
 #        phase2b-prep  -> 45 min  (Claude reads threads + drafts; bumped 2026-05-15
 #                                  15 -> 30 after 17:15 cycle was wrongly salvaged
 #                                  while queued behind 17:30's 42-min lock-hold;
@@ -1454,16 +1450,16 @@ if [ "$BATCH_COUNT" = "0" ]; then
     exit 0
 fi
 
-# Stamp phase2a before releasing the lock so the budget covers the entire
-# 5-min wait + HTTP poll window (phase2a budget = 20 min).
+# Stamp phase2a before releasing the lock so the salvage budget covers the
+# browser-lock handoff window (phase2a budget = 20 min).
 python3 "$REPO_DIR/scripts/twitter_batch_phase.py" advance "$BATCH_ID" --phase phase2a 2>&1 | tee -a "$LOG_FILE" || true
 
-# Release the twitter-browser lock during the 5-min T1 wait + HTTP-only Phase 2a.
+# Release the twitter-browser lock between Phase 1 scrape and Phase 2b posting.
 # Other pipelines (engage-twitter, dm-outreach-twitter, link-edit-twitter,
 # stats.sh) can run their browser steps in this window instead of waiting for us
 # to finish. We re-acquire just before Phase 2b posts, blocking up to the
 # acquire_lock timeout if another pipeline is mid-run.
-log "Releasing twitter-browser lock for the T1 wait window (5min sleep + HTTP fxtwitter poll)..."
+log "Releasing twitter-browser lock between Phase 1 scrape and Phase 2b posting..."
 release_lock "twitter-browser" 2>>"$LOG_FILE"
 # (2026-06-16) NO `rm -f twitter-browser-lock.json` here. The blind rm was
 # ownership-unaware and ran AFTER release_lock, so under a pipeline handoff it