social-autoposter 1.6.71 → 1.6.73

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)
@@ -30,6 +30,11 @@ import http from "node:http";
 // (vite-plugin-singlefile) into dist/panel.html alongside this compiled file.
 const DIST_DIR = path.dirname(fileURLToPath(import.meta.url));
 const PANEL_URI = "ui://social-autoposter/panel.html";
+// Stable id for the accumulating draft review queue. submit_drafts appends each
+// run's drafts here (dedup by tweet URL) so the menu-bar cards PILE UP across a
+// continuous autopilot instead of each run overwriting the last; post_drafts posts
+// the approved subset and marks them posted (filtered out of the cards thereafter).
+const REVIEW_QUEUE_ID = "review-queue";
 const TWITTER_AUTOPILOT_LABEL = "com.m13v.social-twitter-cycle";
 const TWITTER_AUTOPILOT_PLIST = path.join(os.homedir(), "Library", "LaunchAgents", `${TWITTER_AUTOPILOT_LABEL}.plist`);
 // Daily self-updater. Enabled alongside autopilot so a hands-free (headless)
@@ -152,7 +157,9 @@ 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 " +
+        "the draft path (`scan_candidates` -> draft -> `submit_drafts`) has verified the pipeline " +
+        "without posting, AND the recurring autopilot scheduled task has been created and run once " +
+        "(see SCHEDULE THE AUTOPILOT below). 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 " +
@@ -160,27 +167,42 @@ const server = new McpServer({
         "twitter.com session cookies into the managed browser: warn that macOS keychain prompts may " +
         "appear, then proceed without a separate yes/no turn. Ask at most one bundled question, only " +
         "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 " +
+        "or pause for an unavoidable interactive login or OS prompt. Never auto-POST during setup, but " +
+        "DO schedule the draft-only autopilot as the final step (it only queues drafts for approval, it " +
+        "never posts on its own). When setup reaches done (" +
+        "runtime ready, a project configured with seeded topics, X connected, the draft path verified, " +
+        "and the autopilot scheduled task created and run once), call the `dashboard` tool so the user " +
+        "sees the finished setup rendered, then give " +
         "the completion summary.\n\n" +
+        "SCHEDULE THE AUTOPILOT (final onboarding step). Once the draft path is verified, start the " +
+        "autopilot by calling the HOST tool `create_scheduled_task` with: taskId " +
+        "'social-autoposter-autopilot'; cronExpression '* * * * *' (continuous, like the pipeline; the " +
+        "host runs one at a time and skips overlapping fires, so cycles run back-to-back); and a " +
+        "self-contained prompt telling the run to call scan_candidates, draft ONE on-brand reply " +
+        "(<=250 chars, same language as the thread, adds real value) for each candidate worth engaging, " +
+        "then call submit_drafts with those drafts, and NOT post (drafts pile up in the menu-bar " +
+        "approval cards for the user to approve). Then run ONE cycle yourself now (scan_candidates -> " +
+        "draft -> submit_drafts) to seed the cards and pre-approve the tools, so unattended fires do not " +
+        "stall on a permission prompt. If the host exposes no create_scheduled_task tool, tell the user " +
+        "the autopilot could not be scheduled here and to run a draft cycle manually instead.\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 +276,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
@@ -465,8 +487,11 @@ async function produceDrafts(project, onProgress) {
 function renderDraftsTable(plan) {
     const candidates = plan.candidates || [];
     return candidates
-        .map((c, i) => {
-        const n = i + 1;
+        // Number by FULL-array index (matches post_drafts + the menu bar), then drop
+        // already-posted entries so the cards only show what's still pending.
+        .map((c, i) => ({ c, n: i + 1 }))
+        .filter((e) => e.c.posted !== true)
+        .map(({ c, n }) => {
         const author = c.thread_author ? `@${c.thread_author}` : "(unknown thread)";
         const style = c.engagement_style ?? "?";
         const reply = c.reply_text ?? "(empty)";
@@ -647,7 +672,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 +836,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 +943,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. Then SCHEDULE THE AUTOPILOT: call create_scheduled_task (taskId 'social-autoposter-autopilot', cron '* * * * *', prompt = scan_candidates -> draft -> submit_drafts, draft-only) and run one cycle now. Then 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 +985,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,8 +1055,9 @@ 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 ` +
-                    `verify without posting. Do not enable autopilot unless explicitly requested.`
+                    `action:'connect_x', confirm:true immediately. Once X is connected, run scan_candidates -> submit_drafts ` +
+                    `to verify without posting, then schedule the draft-only autopilot (create_scheduled_task, cron '* * * * *', ` +
+                    `prompt = scan_candidates -> draft -> submit_drafts) and run one cycle now.`
                 : `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 ` +
                     `call project_config again with name='${result.project}'. Ask only if a required field is genuinely unknowable.`) +
@@ -1042,145 +1068,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 +1104,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;
@@ -1831,11 +1741,10 @@ tool("submit_drafts", {
     const project = (candidates.map((c) => c.matched_project).find((p) => !!p) ||
         firstSc?.matched_project ||
         "default");
-    const plan = { candidates };
-    writePlan(args.batch_id, plan);
-    // Bake link targets into the plan (sub-second at TWITTER_PAGE_GEN_RATE=0), the
-    // same prep step DRAFT_ONLY does before handing off. Best-effort: posting
-    // falls back to the plain project URL per-candidate if this is skipped.
+    // Stage the new drafts under the scan batch id and bake link targets into them
+    // (sub-second at TWITTER_PAGE_GEN_RATE=0). Best-effort: posting falls back to the
+    // plain project URL per-candidate if gen is skipped.
+    writePlan(args.batch_id, { candidates });
     try {
         await runPython("scripts/twitter_gen_links.py", ["--plan", planPath(args.batch_id)], {
             timeoutMs: 120_000,
@@ -1845,21 +1754,45 @@ tool("submit_drafts", {
     catch {
         /* best effort — plan still posts with a plain-URL fallback */
     }
-    const finalPlan = readPlan(args.batch_id) ?? plan;
-    const count = (finalPlan.candidates || []).length;
-    // Surface to the menu-bar review cards (same contract draft_cycle uses).
+    const staged = readPlan(args.batch_id)?.candidates ?? candidates;
+    // Accumulate into ONE persistent review queue so a continuous autopilot's drafts
+    // PILE UP in the menu-bar cards instead of each run overwriting the last. New
+    // drafts are appended; a thread already in the queue (by URL) is skipped (one
+    // draft per thread). Posted entries are KEPT in place so the 1-based card
+    // numbering stays stable across runs — the menu bar, the chat table, and
+    // post_drafts all index the full array and filter on the `posted` flag.
+    const queue = [
+        ...(readPlan(REVIEW_QUEUE_ID)?.candidates ?? []),
+    ];
+    const seen = new Set(queue.map((c) => c.candidate_url).filter((u) => !!u));
+    let added = 0;
+    for (const nc of staged) {
+        if (nc.candidate_url && seen.has(nc.candidate_url))
+            continue;
+        queue.push(nc);
+        if (nc.candidate_url)
+            seen.add(nc.candidate_url);
+        added++;
+    }
+    writePlan(REVIEW_QUEUE_ID, { candidates: queue });
+    const pending = queue.filter((c) => c.posted !== true);
+    // Drafts queued = the pipeline verified end-to-end without posting. This is the
+    // onboarding "draft_verified" terminal goal (formerly completed by draft_cycle).
+    if (added > 0)
+        completeOnboardingMilestone("draft_verified", { outcome: "review_batch", draft_count: added });
+    // Point the menu-bar review cards at the accumulated queue.
     writeReviewRequest({
-        batch_id: args.batch_id,
+        batch_id: REVIEW_QUEUE_ID,
         project,
-        count,
-        plan_path: planPath(args.batch_id),
+        count: pending.length,
+        plan_path: planPath(REVIEW_QUEUE_ID),
         created_at: new Date().toISOString(),
     });
-    return textContent(`${count} draft(s) queued for review (batch ${args.batch_id}). They're now in the menu-bar ` +
-        `approval cards and the table below; nothing posts until approved.\n\n` +
-        renderDraftsTable(finalPlan) +
-        `\n\nTo post the approved ones: the user approves in the menu bar, or call post_drafts with the ` +
-        `numbers to post.`);
+    return textContent(`Queued ${added} new draft(s); ${pending.length} now awaiting approval in the menu-bar cards ` +
+        `(review queue "${REVIEW_QUEUE_ID}"). Nothing posts until approved.\n\n` +
+        renderDraftsTable({ candidates: queue }) +
+        `\n\nTo post: the user approves in the menu bar, or call post_drafts with batch_id ` +
+        `"${REVIEW_QUEUE_ID}" and the numbers to post.`);
 });
 appTool("dashboard", {
     title: "Social Autoposter dashboard",
@@ -1867,7 +1800,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/mcp/dist/version.js

@@ -2,10 +2,12 @@
 //
 // The "real" version is the top-level `social-autoposter` npm package version
 // (e.g. 1.6.x) — that is what actually bundles this MCP's prebuilt dist/. The
-// MCP's own package.json (0.0.1) and manifest (0.0.1) are decoupled artifacts
-// that nobody bumps, so they are NOT a reliable signal. This module resolves the
-// true version from the most authoritative source available at runtime, and can
-// check npm for a newer published release so we can deliver updates on demand.
+// MCP's own package.json and manifest are stamped to the same version at release
+// time (scripts/release-mcpb.sh step 3b), but historically they were frozen at
+// 0.0.1, so this module still resolves the true version from the most
+// authoritative source available at runtime (and tolerates a stale co-located
+// package.json on an old bundle). It can also check npm for a newer published
+// release so we can deliver updates on demand.
 import fs from "node:fs";
 import path from "node:path";
 import { fileURLToPath } from "node:url";
@@ -26,7 +28,8 @@ function readJsonVersion(p) {
 //      from the npm package version at every init/update. Authoritative on a
 //      real user install, where the top-level package.json is NOT copied.
 //   2. <repo>/package.json — git checkout / dev machine: the meaningful 1.6.x.
-//   3. mcp/package.json    — co-located last resort (currently 0.0.1).
+//   3. mcp/package.json    — co-located last resort (release-stamped to match,
+//      but may be stale on an older bundle).
 export function resolveVersion() {
     return (readJsonVersion(path.join(__dirname, "version.json")) ||
         readJsonVersion(path.join(repoDir(), "package.json")) ||

package/mcp/dist/version.json

@@ -1,4 +1,4 @@
 {
-  "version": "1.6.71",
-  "installedAt": "2026-06-20T16:29:20.789Z"
+  "version": "1.6.72",
+  "installedAt": "2026-06-20T17:17:17.565Z"
 }

package/mcp/manifest.json

@@ -2,7 +2,7 @@
   "dxt_version": "0.1",
   "name": "social-autoposter",
   "display_name": "Social Autoposter",
-  "version": "0.0.1",
+  "version": "1.6.72",
   "description": "Draft, review, approve, and autopilot X/Twitter posts. Thin desktop client over the social-autoposter pipeline.",
   "long_description": "A guided assistant that drafts, reviews, and autopilots X/Twitter posts.\nTo get started:\n1. Fully quit and restart Claude (quit and reopen, not just close the window).\n2. Choose **Set up social-autoposter** from the prompt menu or type **Set me up on social-autoposter end to end**. The agent installs the owned runtime, connects X, discovers and configures your product, and verifies with a draft-only cycle.",
   "author": {
@@ -15,7 +15,9 @@
     "entry_point": "dist/index.js",
     "mcp_config": {
       "command": "node",
-      "args": ["${__dirname}/dist/index.js"],
+      "args": [
+        "${__dirname}/dist/index.js"
+      ],
       "env": {
         "PATH": "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
       }
@@ -43,7 +45,13 @@
       "description": "Render the visual dashboard (MCP Apps UI): project setup, X connection, autopilot state, and 7-day stats, with buttons to run a draft cycle, connect X, and refresh. Also rendered automatically after state-changing actions."
     }
   ],
-  "keywords": ["twitter", "x", "social", "autoposter", "marketing"],
+  "keywords": [
+    "twitter",
+    "x",
+    "social",
+    "autoposter",
+    "marketing"
+  ],
   "license": "UNLICENSED",
   "repository": {
     "type": "git",

package/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@m13v/social-autoposter-mcp",
-  "version": "0.0.1",
+  "version": "1.6.72",
   "private": true,
   "description": "Desktop MCP client for social-autoposter (X/Twitter rail): manual draft/review/approve loop, autopilot control, and stats. Thin wrapper over the existing pipeline scripts.",
   "type": "module",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "social-autoposter",
-  "version": "1.6.71",
+  "version": "1.6.73",
   "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/release-mcpb.sh

@@ -75,6 +75,31 @@ fs.writeFileSync(p, JSON.stringify({version:'$VERSION',installedAt:new Date().to
 console.log('  '+fs.readFileSync(p,'utf8').trim());
 "
 
+# ---- 3b. Stamp manifest.json + mcp/package.json + lockfile version ----------
+# Claude Desktop's extension "Details" panel reads version from manifest.json,
+# so it must track the release version too (not the frozen 0.0.1 placeholder).
+# mcp/package.json and its lockfile are stamped in lockstep so the three stay
+# consistent (npm errors if package.json and package-lock.json disagree).
+say "Stamping mcp/manifest.json + mcp/package.json + mcp/package-lock.json -> $VERSION"
+node -e "
+const fs=require('fs');
+const V='$VERSION';
+for (const p of ['$MCP_DIR/manifest.json','$MCP_DIR/package.json']) {
+  const j=JSON.parse(fs.readFileSync(p,'utf8'));
+  j.version=V;
+  fs.writeFileSync(p, JSON.stringify(j,null,2)+'\n');
+  console.log('  '+p.replace('$MCP_DIR/','mcp/')+' -> '+j.version);
+}
+const lp='$MCP_DIR/package-lock.json';
+if (fs.existsSync(lp)) {
+  const l=JSON.parse(fs.readFileSync(lp,'utf8'));
+  l.version=V;
+  if (l.packages && l.packages['']) l.packages[''].version=V;
+  fs.writeFileSync(lp, JSON.stringify(l,null,2)+'\n');
+  console.log('  mcp/package-lock.json -> '+l.version);
+}
+"
+
 # ---- 4. Pack the .mcpb ------------------------------------------------------
 say "Packing $BUNDLE"
 rm -f "$BUNDLE"
@@ -99,6 +124,10 @@ BUNDLE_VER=$(unzip -p "$BUNDLE" dist/version.json 2>/dev/null | node -p "JSON.pa
 [[ "$BUNDLE_VER" == "$VERSION" ]] || die "bundle version.json=$BUNDLE_VER != $VERSION"
 echo "  version.json: $BUNDLE_VER ok"
 
+MANIFEST_VER=$(unzip -p "$BUNDLE" manifest.json 2>/dev/null | node -p "JSON.parse(require('fs').readFileSync(0,'utf8')).version" 2>/dev/null || echo "?")
+[[ "$MANIFEST_VER" == "$VERSION" ]] || die "bundle manifest.json=$MANIFEST_VER != $VERSION (Desktop Details panel would show the wrong version)"
+echo "  manifest.json: $MANIFEST_VER ok"
+
 for f in "dist/index.js" "dist/runtime.js" "manifest.json"; do
   # grep -c reads all input (no SIGPIPE); anchor on the time column + 3-space
   # gutter so node_modules/.../dist/index.js does not false-match the top-level.

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