@papi-ai/server 0.7.24 → 0.7.25

package/dist/index.js

@@ -4119,6 +4119,10 @@ var init_large = __esm({
 });
 
 // ../../node_modules/postgres/src/index.js
+var src_exports = {};
+__export(src_exports, {
+  default: () => src_default
+});
 import os from "os";
 import fs2 from "fs";
 function Postgres(a, b2) {
@@ -4776,6 +4780,7 @@ function rowToToolCallMetric(row) {
   if (row.cycle_number != null) metric.cycleNumber = row.cycle_number;
   if (row.context_bytes != null) metric.contextBytes = row.context_bytes;
   if (row.context_utilisation != null) metric.contextUtilisation = parseFloat(row.context_utilisation);
+  if (row.client_name != null) metric.clientName = row.client_name;
   return metric;
 }
 function rowToCostSnapshot(row) {
@@ -7302,33 +7307,38 @@ EXCEPTION WHEN duplicate_object THEN NULL; END $$;
       }
       async getCycleLearnings(opts) {
         const limit = opts?.limit ?? 50;
+        const resolvedFilter = opts?.includeResolved ? this.sql`` : this.sql`AND resolved_at IS NULL`;
         let rows;
         if (opts?.cycleNumber && opts?.category) {
           rows = await this.sql`
-        SELECT id, project_id, task_id, cycle_number, category, severity, summary, detail, tags, related_decision, action_taken, action_ref, created_at
+        SELECT id, project_id, task_id, cycle_number, category, severity, summary, detail, tags, related_decision, action_taken, action_ref, resolved_at, resolved_by, created_at
         FROM cycle_learnings
         WHERE project_id = ${this.projectId} AND cycle_number = ${opts.cycleNumber} AND category = ${opts.category}
+          ${resolvedFilter}
         ORDER BY created_at DESC LIMIT ${limit}
       `;
         } else if (opts?.cycleNumber) {
           rows = await this.sql`
-        SELECT id, project_id, task_id, cycle_number, category, severity, summary, detail, tags, related_decision, action_taken, action_ref, created_at
+        SELECT id, project_id, task_id, cycle_number, category, severity, summary, detail, tags, related_decision, action_taken, action_ref, resolved_at, resolved_by, created_at
         FROM cycle_learnings
         WHERE project_id = ${this.projectId} AND cycle_number = ${opts.cycleNumber}
+          ${resolvedFilter}
         ORDER BY created_at DESC LIMIT ${limit}
       `;
         } else if (opts?.category) {
           rows = await this.sql`
-        SELECT id, project_id, task_id, cycle_number, category, severity, summary, detail, tags, related_decision, action_taken, action_ref, created_at
+        SELECT id, project_id, task_id, cycle_number, category, severity, summary, detail, tags, related_decision, action_taken, action_ref, resolved_at, resolved_by, created_at
         FROM cycle_learnings
         WHERE project_id = ${this.projectId} AND category = ${opts.category}
+          ${resolvedFilter}
         ORDER BY created_at DESC LIMIT ${limit}
       `;
         } else {
           rows = await this.sql`
-        SELECT id, project_id, task_id, cycle_number, category, severity, summary, detail, tags, related_decision, action_taken, action_ref, created_at
+        SELECT id, project_id, task_id, cycle_number, category, severity, summary, detail, tags, related_decision, action_taken, action_ref, resolved_at, resolved_by, created_at
         FROM cycle_learnings
         WHERE project_id = ${this.projectId}
+          ${resolvedFilter}
         ORDER BY created_at DESC LIMIT ${limit}
       `;
         }
@@ -7345,6 +7355,8 @@ EXCEPTION WHEN duplicate_object THEN NULL; END $$;
           relatedDecision: r.related_decision ?? void 0,
           actionTaken: r.action_taken ?? void 0,
           actionRef: r.action_ref ?? void 0,
+          resolvedAt: r.resolved_at ? r.resolved_at.toISOString() : void 0,
+          resolvedBy: r.resolved_by ?? void 0,
           createdAt: r.created_at ? r.created_at.toISOString() : void 0
         }));
       }
@@ -7355,6 +7367,21 @@ EXCEPTION WHEN duplicate_object THEN NULL; END $$;
       WHERE id = ${learningId}
         AND project_id = ${this.projectId}
         AND action_ref IS NULL
+    `;
+      }
+      /**
+       * Mark a cycle_learnings row resolved (task-1541, C277). Idempotent — re-resolving
+       * an already-resolved row is a no-op (preserves the original resolved_at timestamp).
+       * Scoped to the bound project_id so cross-tenant writes are impossible.
+       */
+      async markCycleLearningResolved(learningId, resolvedBy) {
+        await this.sql`
+      UPDATE cycle_learnings
+      SET resolved_at = now(),
+          resolved_by = ${resolvedBy ?? null}
+      WHERE id = ${learningId}
+        AND project_id = ${this.projectId}
+        AND resolved_at IS NULL
     `;
       }
       async getCycleLearningPatterns() {
@@ -7570,20 +7597,21 @@ EXCEPTION WHEN duplicate_object THEN NULL; END $$;
       INSERT INTO tool_call_metrics (
         project_id, timestamp, tool, duration_ms,
         input_tokens, output_tokens, estimated_cost_usd, model, cycle_number,
-        context_bytes, context_utilisation, success
+        context_bytes, context_utilisation, success, client_name
       ) VALUES (
         ${this.projectId}, ${metric.timestamp}, ${metric.tool}, ${metric.durationMs},
         ${metric.inputTokens ?? null}, ${metric.outputTokens ?? null},
         ${metric.estimatedCostUsd ?? null}, ${metric.model ?? null},
         ${metric.cycleNumber ?? null},
         ${metric.contextBytes ?? null}, ${metric.contextUtilisation ?? null},
-        ${metric.success ?? true}
+        ${metric.success ?? true},
+        ${metric.clientName ?? null}
       )
     `;
       }
       async readToolMetrics() {
         const rows = await this.sql`
-      SELECT timestamp, tool, duration_ms, input_tokens, output_tokens, estimated_cost_usd, model, cycle_number, context_bytes, context_utilisation
+      SELECT timestamp, tool, duration_ms, input_tokens, output_tokens, estimated_cost_usd, model, cycle_number, context_bytes, context_utilisation, client_name
       FROM tool_call_metrics
       WHERE project_id = ${this.projectId}
       ORDER BY timestamp
@@ -8199,6 +8227,14 @@ ${r.content}` + (r.carry_forward ? `
       UPDATE projects SET papi_dir = ${papiDir}, updated_at = now() WHERE id = ${this.projectId}
     `;
       }
+      /**
+       * Public projection of the private ownerUserId helper. Used by verifyProject
+       * (task-1621) to detect legacy pre-multi-user project rows where user_id is
+       * still NULL. Read-only.
+       */
+      async getProjectOwnerUserId() {
+        return this.ownerUserId();
+      }
       // -------------------------------------------------------------------------
       // Project lifecycle (task-1888 / 1885-C)
       // Scoped to the SAME user_id as the currently-bound project — a stdio user on
@@ -9944,7 +9980,8 @@ function taskBranchName(taskId) {
   return `feat/${taskId}`;
 }
 function cycleBranchName(cycleNumber, module) {
-  return `feat/cycle-${cycleNumber}-${module.toLowerCase().replace(/\s+/g, "-")}`;
+  const slug = module.toLowerCase().replace(/&/g, "and").replace(/&/g, "and").replace(/[^a-z0-9]+/g, "-").replace(/^-+|-+$/g, "");
+  return `feat/cycle-${cycleNumber}-${slug}`;
 }
 function getHeadCommitSha(cwd) {
   try {
@@ -10294,17 +10331,133 @@ function formatReport(report) {
   lines.push("Need recovery? In the dashboard: Settings \u2192 Reset connection. Or surgically clean .mcp.json: `npx @papi-ai/server reset`.");
   return lines.join("\n");
 }
-async function runDoctor() {
+function resolveDatabaseUrl() {
+  if (process.env.DATABASE_URL) return process.env.DATABASE_URL;
+  const mcpEnv = findMcpJson();
+  return mcpEnv?.vars.DATABASE_URL;
+}
+function classifyWedged(rows) {
+  const wedged = [];
+  for (const r of rows) {
+    const state2 = (r.state ?? "").toLowerCase();
+    const stateAge = Number(r.state_age ?? 0);
+    const queryAge = Number(r.query_age ?? 0);
+    if (state2.startsWith("idle in transaction") && stateAge > WEDGED_IDLE_TX_SECONDS) {
+      wedged.push({ pid: r.pid, state: r.state ?? "unknown", ageSeconds: Math.round(stateAge), reason: "idle-in-transaction" });
+    } else if (state2 === "active" && queryAge > WEDGED_ACTIVE_SECONDS) {
+      wedged.push({ pid: r.pid, state: r.state ?? "unknown", ageSeconds: Math.round(queryAge), reason: "long-active" });
+    }
+  }
+  return wedged;
+}
+async function diagnosePool(opts) {
+  const dbUrl = resolveDatabaseUrl();
+  if (!dbUrl) {
+    return { status: "skipped", detail: "no DATABASE_URL \u2014 DB pool diagnostics skipped", wedged: [], cleanupRequested: opts.fix };
+  }
+  let factory;
+  try {
+    factory = (await Promise.resolve().then(() => (init_src(), src_exports))).default;
+  } catch {
+    return { status: "skipped", detail: "postgres client not resolvable \u2014 DB pool diagnostics skipped", wedged: [], cleanupRequested: opts.fix };
+  }
+  const sql = factory(dbUrl, { max: 1, idle_timeout: 5, connect_timeout: 10 });
+  try {
+    const rows = await sql`
+      SELECT pid,
+             state,
+             EXTRACT(EPOCH FROM (now() - state_change))::int AS state_age,
+             EXTRACT(EPOCH FROM (now() - query_start))::int  AS query_age
+      FROM pg_stat_activity
+      WHERE usename = current_user
+        AND backend_type = 'client backend'
+        AND pid <> pg_backend_pid()`;
+    const total = rows.length;
+    const active = rows.filter((r) => (r.state ?? "") === "active").length;
+    const idle = rows.filter((r) => (r.state ?? "") === "idle").length;
+    const idleInTransaction = rows.filter((r) => (r.state ?? "").toLowerCase().startsWith("idle in transaction")).length;
+    const wedged = classifyWedged(rows);
+    if (opts.fix && wedged.length > 0) {
+      for (const w of wedged) {
+        try {
+          await sql`SELECT pg_terminate_backend(pid)
+                    FROM pg_stat_activity
+                    WHERE pid = ${w.pid} AND usename = current_user`;
+          w.terminated = "yes";
+        } catch {
+          w.terminated = "failed";
+        }
+      }
+    } else if (wedged.length > 0) {
+      for (const w of wedged) w.terminated = "no";
+    }
+    return { status: "ok", total, active, idle, idleInTransaction, wedged, cleanupRequested: opts.fix };
+  } catch (err) {
+    return {
+      status: "error",
+      detail: err instanceof Error ? err.message : String(err),
+      wedged: [],
+      cleanupRequested: opts.fix
+    };
+  } finally {
+    try {
+      await sql.end({ timeout: 5 });
+    } catch {
+    }
+  }
+}
+function formatPoolReport(pool) {
+  const lines = [];
+  lines.push("## DB pool / backend state");
+  if (pool.status === "skipped") {
+    lines.push(`  \u2022 ${pool.detail}`);
+    return lines.join("\n");
+  }
+  if (pool.status === "error") {
+    lines.push(`  \u2022 DB pool check failed: ${pool.detail}`);
+    lines.push("     \u2192 If this is a permissions error, pg_stat_activity / pg_terminate_backend need a role with sufficient privileges.");
+    return lines.join("\n");
+  }
+  lines.push(`  Connections for this role: ${pool.total} total \u2014 ${pool.active} active, ${pool.idle} idle, ${pool.idleInTransaction} idle-in-transaction`);
+  if (pool.wedged.length === 0) {
+    lines.push("  \u2713 No wedged backends detected.");
+    return lines.join("\n");
+  }
+  lines.push(`  \u26A0 ${pool.wedged.length} wedged backend(s) detected:`);
+  for (const w of pool.wedged) {
+    const verb = w.terminated === "yes" ? "terminated" : w.terminated === "failed" ? "terminate FAILED (insufficient privilege?)" : "would terminate (run with --fix-pool)";
+    lines.push(`     pid ${w.pid} \u2014 ${w.reason}, ${w.ageSeconds}s in state "${w.state}" \u2192 ${verb}`);
+  }
+  if (!pool.cleanupRequested) {
+    lines.push("     \u2192 To clear them: `npx @papi-ai/server doctor --fix-pool` (terminates only this role's confirmed-wedged backends).");
+  }
+  return lines.join("\n");
+}
+async function runDoctor(cliArgs2 = []) {
   const report = diagnose();
   process.stdout.write(formatReport(report) + "\n");
+  const fixPool = cliArgs2.includes("--fix-pool") || cliArgs2.includes("--terminate-wedged");
+  const pool = await diagnosePool({ fix: fixPool });
+  process.stdout.write("\n" + formatPoolReport(pool) + "\n");
   return 0;
 }
-var SECRET_VARS, __testing;
+var SECRET_VARS, WEDGED_IDLE_TX_SECONDS, WEDGED_ACTIVE_SECONDS, __testing;
 var init_doctor = __esm({
   "src/cli/doctor.ts"() {
     "use strict";
     SECRET_VARS = /* @__PURE__ */ new Set(["PAPI_DATA_API_KEY", "DATABASE_URL", "PAPI_ENDPOINT"]);
-    __testing = { redact, findMcpJson, diagnose, formatReport };
+    WEDGED_IDLE_TX_SECONDS = 300;
+    WEDGED_ACTIVE_SECONDS = 300;
+    __testing = {
+      redact,
+      findMcpJson,
+      diagnose,
+      formatReport,
+      classifyWedged,
+      formatPoolReport,
+      WEDGED_IDLE_TX_SECONDS,
+      WEDGED_ACTIVE_SECONDS
+    };
   }
 });
 
@@ -10421,9 +10574,253 @@ var init_reset = __esm({
   }
 });
 
+// src/cli/audit.ts
+var audit_exports = {};
+__export(audit_exports, {
+  __testing: () => __testing2,
+  runAudit: () => runAudit
+});
+import { existsSync as existsSync11, readFileSync as readFileSync12, readdirSync as readdirSync7 } from "fs";
+import { homedir as homedir6 } from "os";
+import { join as join20 } from "path";
+function safeListDirs(dir) {
+  try {
+    return readdirSync7(dir, { withFileTypes: true }).filter((e) => e.isDirectory()).map((e) => e.name).sort((a, b2) => a.localeCompare(b2));
+  } catch {
+    return [];
+  }
+}
+function safeListFiles(dir, ext) {
+  try {
+    return readdirSync7(dir, { withFileTypes: true }).filter((e) => e.isFile() && e.name.endsWith(ext)).map((e) => e.name).sort((a, b2) => a.localeCompare(b2));
+  } catch {
+    return [];
+  }
+}
+function readMcp(projectPath) {
+  const path7 = join20(projectPath, ".mcp.json");
+  if (!existsSync11(path7)) return { servers: [] };
+  try {
+    const parsed = JSON.parse(readFileSync12(path7, "utf-8"));
+    const mcpServers = parsed.mcpServers ?? {};
+    const servers = Object.keys(mcpServers);
+    if (parsed.papi && !servers.includes("papi")) servers.push("papi");
+    servers.sort((a, b2) => a.localeCompare(b2));
+    let papiProjectId;
+    const scanEnv = (entry) => {
+      const env = entry?.env;
+      if (env?.PAPI_PROJECT_ID) papiProjectId = env.PAPI_PROJECT_ID;
+    };
+    for (const entry of Object.values(mcpServers)) scanEnv(entry);
+    scanEnv(parsed.papi);
+    return { servers, papiProjectId };
+  } catch {
+    return { servers: [] };
+  }
+}
+async function detectStaleForkNames(projectPath) {
+  try {
+    const { detectStaleForks } = await import("@papi-ai/skills/manifest");
+    return detectStaleForks(projectPath).map((f) => f.name).sort((a, b2) => a.localeCompare(b2));
+  } catch {
+    return [];
+  }
+}
+function auditProjectSync(projectPath, name) {
+  const { servers, papiProjectId } = readMcp(projectPath);
+  return {
+    name,
+    path: projectPath,
+    papiProjectId,
+    mcpServers: servers,
+    skills: safeListDirs(join20(projectPath, ".claude", "skills")),
+    agentSkills: safeListDirs(join20(projectPath, ".agents", "skills")),
+    agents: safeListFiles(join20(projectPath, ".claude", "agents"), ".md"),
+    hooks: safeListFiles(join20(projectPath, ".claude", "hooks"), ".sh")
+  };
+}
+function discoverProjects() {
+  const out = [];
+  for (const root of PROJECT_ROOTS) {
+    for (const name of safeListDirs(root)) {
+      const path7 = join20(root, name);
+      if (existsSync11(join20(path7, ".mcp.json")) || existsSync11(join20(path7, ".claude"))) {
+        out.push({ name, path: path7 });
+      }
+    }
+  }
+  return out;
+}
+function readGlobalSkills() {
+  return safeListDirs(GLOBAL_SKILLS_DIR);
+}
+function readGlobalMcpServers() {
+  if (!existsSync11(GLOBAL_CLAUDE_JSON)) return [];
+  try {
+    const parsed = JSON.parse(readFileSync12(GLOBAL_CLAUDE_JSON, "utf-8"));
+    const servers = parsed.mcpServers ?? {};
+    return Object.keys(servers).sort((a, b2) => a.localeCompare(b2));
+  } catch {
+    return [];
+  }
+}
+async function checkIdleMcp(projects) {
+  const dbUrl = process.env.DATABASE_URL;
+  const tracked2 = projects.filter((p) => p.papiProjectId);
+  for (const p of projects) p.idleMcp = p.papiProjectId ? "skipped" : "untracked";
+  if (!dbUrl || tracked2.length === 0) return;
+  let factory;
+  try {
+    factory = (await Promise.resolve().then(() => (init_src(), src_exports))).default;
+  } catch {
+    return;
+  }
+  const sql = factory(dbUrl, { max: 1, idle_timeout: 5, connect_timeout: 10 });
+  try {
+    for (const p of tracked2) {
+      try {
+        const rows = await sql`
+          SELECT count(*)::int AS n
+          FROM telemetry_events
+          WHERE project_id = ${p.papiProjectId}
+            AND created_at > now() - make_interval(days => ${IDLE_WINDOW_DAYS})`;
+        p.idleMcp = (rows[0]?.n ?? 0) === 0 ? "idle" : "active";
+      } catch {
+        p.idleMcp = "error";
+      }
+    }
+  } finally {
+    try {
+      await sql.end({ timeout: 5 });
+    } catch {
+    }
+  }
+}
+function computeFlags(projects, globalSkills, globalMcp) {
+  const globalSet = new Set(globalSkills);
+  const staleForks = projects.filter((p) => p.staleForks.length > 0).map((p) => ({ project: p.name, skills: p.staleForks }));
+  const redundantWithGlobal = projects.map((p) => ({ project: p.name, skills: p.skills.filter((s) => globalSet.has(s)) })).filter((r) => r.skills.length > 0);
+  const skillToProjects = /* @__PURE__ */ new Map();
+  for (const p of projects) {
+    for (const s of p.skills) {
+      if (globalSet.has(s)) continue;
+      const arr = skillToProjects.get(s) ?? [];
+      arr.push(p.name);
+      skillToProjects.set(s, arr);
+    }
+  }
+  const globalizeCandidates = [...skillToProjects.entries()].filter(([, ps]) => ps.length >= GLOBALIZE_THRESHOLD).map(([skill, ps]) => ({ skill, projects: ps.sort((a, b2) => a.localeCompare(b2)) })).sort((a, b2) => b2.projects.length - a.projects.length);
+  const idleMcp = projects.filter((p) => p.idleMcp === "idle").map((p) => ({ project: p.name }));
+  return { globalSkills, globalMcp, staleForks, redundantWithGlobal, globalizeCandidates, idleMcp };
+}
+function formatReport2(projects, flags, idleChecked) {
+  const lines = [];
+  lines.push("PAPI audit \u2014 cross-project harness & config (read-only)");
+  lines.push("");
+  lines.push(`## Projects (${projects.length})`);
+  if (projects.length === 0) {
+    lines.push("  No projects found under ~/Ai-App-Projects or ~/android-projects.");
+  } else {
+    const header = `  ${"Project".padEnd(28)} ${"MCP".padStart(4)} ${"Skills".padStart(6)} ${"AgtSk".padStart(5)} ${"Agents".padStart(6)} ${"Hooks".padStart(5)} ${"Stale".padStart(5)}  PAPI`;
+    lines.push(header);
+    lines.push(`  ${"-".repeat(header.length - 2)}`);
+    for (const p of projects) {
+      const papi = p.papiProjectId ? idleChecked ? p.idleMcp : "tracked" : "\u2014";
+      lines.push(
+        `  ${p.name.slice(0, 28).padEnd(28)} ${String(p.mcpServers.length).padStart(4)} ${String(p.skills.length).padStart(6)} ${String(p.agentSkills.length).padStart(5)} ${String(p.agents.length).padStart(6)} ${String(p.hooks.length).padStart(5)} ${String(p.staleForks.length).padStart(5)}  ${papi}`
+      );
+    }
+  }
+  lines.push("");
+  lines.push("## Flags");
+  let any = false;
+  if (flags.globalSkills.length > 0) {
+    any = true;
+    lines.push(`  \u2022 Global skills (${flags.globalSkills.length}) load into EVERY project's context window \u2014 token-hygiene review candidates:`);
+    lines.push(`      ${flags.globalSkills.join(", ")}`);
+  }
+  if (flags.globalMcp.length > 0) {
+    any = true;
+    lines.push(`  \u2022 Global MCP servers (${flags.globalMcp.length}) enabled for every project: ${flags.globalMcp.join(", ")}`);
+  }
+  for (const r of flags.redundantWithGlobal) {
+    any = true;
+    lines.push(`  \u2022 ${r.project}: skill(s) exist both project-locally AND globally (redundant unless an intentional fork): ${r.skills.join(", ")}`);
+  }
+  for (const s of flags.staleForks) {
+    any = true;
+    lines.push(`  \u2022 ${s.project}: stale skill fork(s) drifted from @papi-ai/skills: ${s.skills.join(", ")}`);
+  }
+  for (const c of flags.globalizeCandidates) {
+    any = true;
+    lines.push(`  \u2022 "${c.skill}" is project-local in ${c.projects.length} projects (${c.projects.join(", ")}) \u2014 candidate to promote to ~/.claude/skills.`);
+  }
+  if (idleChecked) {
+    for (const i of flags.idleMcp) {
+      any = true;
+      lines.push(`  \u2022 ${i.project}: PAPI MCP idle \u2014 0 tool calls in ${IDLE_WINDOW_DAYS}d. Candidate to remove from active config.`);
+    }
+  } else {
+    lines.push(`  \u2022 idle-MCP check skipped \u2014 run with \`--idle-mcp\` (requires DATABASE_URL) to flag projects with 0 telemetry in ${IDLE_WINDOW_DAYS}d.`);
+  }
+  if (!any) lines.push("  \u2713 No hygiene flags raised.");
+  lines.push("");
+  lines.push("## Suggestions (proposals \u2014 nothing is applied automatically)");
+  const suggestions = [];
+  if (flags.globalSkills.length > 8) {
+    suggestions.push(`Move rarely-used global skills out of ~/.claude/skills into a per-project .claude/skills/ (or .claude/skills.local/) so they only load where used.`);
+  }
+  if (flags.redundantWithGlobal.length > 0) {
+    suggestions.push(`For redundant project-local copies of global skills, delete the local copy unless it is an intentional fork (keep forks under .claude/skills.local/ so they are not flagged stale).`);
+  }
+  if (flags.staleForks.length > 0) {
+    suggestions.push(`Re-sync stale skill forks from @papi-ai/skills, or move deliberate overrides under .claude/skills.local/.`);
+  }
+  if (idleChecked && flags.idleMcp.length > 0) {
+    suggestions.push(`Remove the PAPI MCP config from dormant projects (no tool calls in ${IDLE_WINDOW_DAYS}d) to trim every-session connector load.`);
+  }
+  if (suggestions.length === 0) {
+    lines.push("  \u2713 Nothing to suggest.");
+  } else {
+    suggestions.forEach((s, i) => lines.push(`  ${i + 1}. ${s}`));
+  }
+  lines.push("");
+  lines.push("Approve any change in Claude Code \u2014 this command never edits files or the database.");
+  return lines.join("\n");
+}
+async function runAudit(args = []) {
+  const idleChecked = args.includes("--idle-mcp");
+  const discovered = discoverProjects();
+  const projects = [];
+  for (const { name, path: path7 } of discovered) {
+    const base = auditProjectSync(path7, name);
+    projects.push({ ...base, staleForks: await detectStaleForkNames(path7), idleMcp: "skipped" });
+  }
+  if (idleChecked) {
+    await checkIdleMcp(projects);
+  }
+  const globalSkills = readGlobalSkills();
+  const globalMcp = readGlobalMcpServers();
+  const flags = computeFlags(projects, globalSkills, globalMcp);
+  process.stdout.write(formatReport2(projects, flags, idleChecked) + "\n");
+  return 0;
+}
+var PROJECT_ROOTS, GLOBAL_SKILLS_DIR, GLOBAL_CLAUDE_JSON, IDLE_WINDOW_DAYS, GLOBALIZE_THRESHOLD, __testing2;
+var init_audit = __esm({
+  "src/cli/audit.ts"() {
+    "use strict";
+    PROJECT_ROOTS = [join20(homedir6(), "Ai-App-Projects"), join20(homedir6(), "android-projects")];
+    GLOBAL_SKILLS_DIR = join20(homedir6(), ".claude", "skills");
+    GLOBAL_CLAUDE_JSON = join20(homedir6(), ".claude.json");
+    IDLE_WINDOW_DAYS = 30;
+    GLOBALIZE_THRESHOLD = 3;
+    __testing2 = { readMcp, computeFlags, formatReport: formatReport2, discoverProjects, auditProjectSync };
+  }
+});
+
 // src/index.ts
-import { readFileSync as readFileSync12 } from "fs";
-import { dirname as dirname5, join as join20 } from "path";
+import { readFileSync as readFileSync13 } from "fs";
+import { dirname as dirname5, join as join21 } from "path";
 import { fileURLToPath as fileURLToPath3 } from "url";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 import { Server as Server2 } from "@modelcontextprotocol/sdk/server/index.js";
@@ -11378,7 +11775,8 @@ function estimateCost(model, inputTokens, outputTokens) {
   if (!rates) return 0;
   return inputTokens * rates.input + outputTokens * rates.output;
 }
-function buildMetric(tool, durationMs, usage, cycleNumber, contextBytes, contextUtilisation) {
+var MAX_CLIENT_NAME_LENGTH = 100;
+function buildMetric(tool, durationMs, usage, cycleNumber, contextBytes, contextUtilisation, clientName) {
   const timestamp = (/* @__PURE__ */ new Date()).toISOString();
   const metric = { timestamp, tool, durationMs };
   if (usage) {
@@ -11396,6 +11794,9 @@ function buildMetric(tool, durationMs, usage, cycleNumber, contextBytes, context
   if (contextUtilisation !== void 0) {
     metric.contextUtilisation = contextUtilisation;
   }
+  if (clientName !== void 0 && clientName.length > 0) {
+    metric.clientName = clientName.slice(0, MAX_CLIENT_NAME_LENGTH);
+  }
   return metric;
 }
 function measureContextUtilisation(inputContext, llmOutput) {
@@ -11445,6 +11846,7 @@ If a candidate AD body could be invalidated by running a SQL query, refreshing a
 **Negative example (reject):** "External user feedback is now flowing. Stonebridge Systems is actively building." \u2014 this is a fact about the current state of the world. Capture as dogfood/signal observation; do not mint.
 
 This rule applies to: new ADs proposed during planning (Step 9), strategy review AD updates (section 5), and strategy_change AD updates. If you find an existing AD that violates this rule during housekeeping, propose deleting it (action: "delete") with a one-line rationale.`;
+var OUTPUT_QUALITY_RUBRIC = `Quality bar \u2014 before emitting, self-score the artifact 1-10 on five dimensions: (1) **Clarity** \u2014 could a third LLM act on it with no extra context? (2) **Scope tightness** \u2014 one focused unit of work, not three bundled together. (3) **Specificity** \u2014 it names concrete files/paths/tasks/ADs, not vague references like "the auth module". (4) **Dependency surfacing** \u2014 prerequisite or upstream items are called out explicitly. (5) **Success-criteria concreteness** \u2014 "done" is testable and observable, not "looks good". Sum to /50. If any single dimension scores \u22644, or the total is <35, revise the artifact and re-score before emitting \u2014 do not ship a below-threshold artifact. This is a self-check gate, not an output field: do NOT add the scores to the artifact or the structured JSON.`;
 var PLAN_SYSTEM = `You are the PAPI Cycle Planner \u2014 an autonomous planning engine for software projects.
 You receive project context and produce a planning cycle output with a BUILD HANDOFF.
 
@@ -11614,152 +12016,6 @@ Before generating cycle tasks, answer: **is this a service or a platform?**
 If unanswered, default to Platform \u2014 which is often wrong for early-stage projects. If the answer is clear from the brief, mint it as AD-1 and shape tasks accordingly.
 
 **CRITICAL: Bootstrap MUST populate newTasks, productBrief, and activeDecisions (if any ADs were created). These are the only way data gets written to files.**`;
-var PLAN_FULL_INSTRUCTIONS = `## FULL MODE
-
-Standard planning cycle with full board review.
-
-### Steps:
-1. **Cycle Health Check** \u2014 Flag issues: >7 day gaps, unprocessed discovered issues, AD conflicts, stale In Progress tasks (3+ cycles).
-   **\u26A0\uFE0F CARRY-FORWARD STALENESS (already-built):** Check the latest carry-forward text for items containing "stale", "already exists", "already implemented", or "already built". For each such item that references a specific task ID, check whether the task is still in Backlog. If a carry-forward says a task's deliverables already exist but the task is still Backlog, emit a \`boardCorrections\` entry setting it to Done with \`closureReason: "Auto-closed \u2014 carry-forward indicates deliverables already exist"\`. Log in the cycle log: "Auto-closed task-XXX \u2014 carry-forward confirmed deliverables exist." This prevents scheduling already-shipped tasks.
-   **\u26A0\uFE0F CARRY-FORWARD FORCED RESOLUTION:** If a "Carry-Forward Staleness" section is provided in the context below, it lists task IDs that have been deferred for 3+ consecutive cycles. For each listed task, you MUST take one of these actions \u2014 deferring again without justification is not acceptable:
-   - **Escalate:** Emit a \`boardCorrections\` entry upgrading the task to P1 High (if currently P2+) and include a "Carry-Forward Escalation" paragraph in the cycle log: list each escalated task by ID with a 1-sentence rationale.
-   - **Cancel:** Emit a \`boardCorrections\` entry setting status to "Cancelled" with a \`closureReason\` explaining why the task is no longer worth pursuing.
-   - **Schedule:** Include the task in this cycle's BUILD HANDOFFs. If scheduled, no further action needed.
-   If you defer a stale task again, you MUST provide an explicit justification in the cycle log \u2014 e.g. "task-XXX deferred again: blocked on task-YYY which must ship first."
-
-2. **Inbox Triage** \u2014 Find unreviewed tasks (reviewed = false). For each: clean title, fill all fields, check for duplicates, verify alignment with Active Decisions. You MUST set priority on unreviewed tasks during triage using these criteria:
-   - **P0 Critical** \u2014 Broken, blocking, or data-loss risk. Fix now.
-   - **P1 High** \u2014 Strategically aligned: directly advances the current horizon/phase goals or Active Decisions.
-   - **P2 Medium** \u2014 Valuable but not strategically urgent: quality improvements, efficiency, polish, infrastructure.
-   - **P3 Low** \u2014 Nice-to-have, speculative, or future-horizon work.
-   **\u26A0\uFE0F PRIORITY RECALIBRATION \u2014 do NOT rubber-stamp the submitted priority.** The priority set at idea submission reflects the submitter's view at that time, which may be outdated by the time the planner runs. For EVERY unreviewed task, evaluate its priority FROM SCRATCH against: (a) current horizon/stage/phase goals, (b) recent Active Decision changes, (c) recently shipped functionality that makes this task more or less urgent. If your assessed priority differs from the submitted one, set the new priority in \`boardCorrections\` and include the change in a **Priority Recalibration** paragraph in your cycle log (Step 8): list each changed task by ID, old priority \u2192 new priority, and a 1-sentence rationale. This paragraph is how the user sees what the planner recalibrated and why. If no priorities changed during triage, omit the paragraph.
-   Also set complexity using the full range \u2014 **XS, Small, Medium, Large, XL** \u2014 based on actual scope, not conservatively. XS = single-line or config change. Small = one file, < 50 lines. Medium = 2-5 files. Large = cross-module, multiple components. XL = architectural, multi-day.
-   **Module classification for cross-cutting tasks:** When a task title contains "audit"/"unfiltered"/"scoping"/"leak" plus a database-entity name (e.g. "audit ... cycle_learnings reads", "unfiltered cycle_tasks queries"), classify the module by the actual code surface that reads/writes the entity \u2014 not by the tool names mentioned in the title. The reasoning surface (e.g. "health" or "strategy_review") is often unrelated to the data-access surface. Resolve this by treating the entity name as the routing signal: tasks touching dashboard read/write paths belong to the Dashboard module even if the title mentions an MCP tool. Misclassification routes the task to the wrong shared cycle branch and surfaces the wrong MODULE INSTRUCTIONS to the builder.
-   If a task is clearly obsolete, duplicated, or rejected, set its status to "Cancelled" with a \`closureReason\` explaining why.
-   **\u2192 PERSIST:** For each task you set reviewed: true, corrected fields on, or marked "Cancelled", include it in \`boardCorrections\` in Part 2.
-
-3. **Board Integrity** \u2014 All tasks have complete fields? Priority still accurate? Duplicates? Stale In Progress tasks?
-   **\u2192 PERSIST:** Include any field corrections (status updates, field fixes) in \`boardCorrections\` in Part 2.
-   **\u26A0\uFE0F PRIORITY LOCK RULE:** Do NOT change the priority of any task that has \`reviewed: true\`. Reviewed tasks have had their priority confirmed by a human. If you believe a reviewed task's priority should change, note your recommendation in the cycle log but do NOT include a priority change in \`boardCorrections\`. You may only set priority on unreviewed tasks (during triage) or on newly created tasks (\`newTasks\` array). Priority values: P0 Critical, P1 High, P2 Medium, P3 Low.
-   **Priority Drift Check:** For reviewed Backlog tasks, check whether their priority still reflects strategic reality. A task submitted as P2 six cycles ago may now be P1 (strategic context shifted) or P3 (redundant, superseded, or de-prioritised by an AD). For each task where drift is detected, check three signals: (1) Does it still align with the current horizon/stage/phase? (2) Has a recent AD changed the strategic importance of this area? (3) Has a recent build shipped functionality that makes this task redundant or more urgent? If drift is found on 1+ tasks, include a **Priority Drift Suggestions** paragraph in your cycle log: list each drifted task by ID, current priority, suggested priority, and a 1-sentence rationale. Do NOT include priority changes in \`boardCorrections\` \u2014 these are suggestions requiring human confirmation, not auto-corrections. Omit this paragraph entirely if no drift is detected.
-
-4. **Security Posture Check** \u2014 Review recently completed tasks and current board state for security concerns. Only flag genuine issues \u2014 do not add boilerplate security notes every cycle. Look for:
-   - Data exposure risks introduced by recent builds (PII in logs, secrets in storage/config)
-   - Unprotected endpoints or missing auth/access control in new features
-   - Undocumented secrets or environment variables added without documentation
-   - New dependencies with known vulnerabilities or excessive permissions
-   **\u2192 PERSIST:** If concerns exist, include them in \`cycleLogNotes\` with a \`[SECURITY]\` tag prefix (e.g. "[SECURITY] New /admin endpoint in task-042 has no auth middleware"). If no concerns, omit \u2014 do not write "[SECURITY] No issues found".
-
-5. **Discovery Gaps** \u2014 If a Discovery Canvas section is provided in the context below, check which sections are populated vs empty. In cycles 1-10, or whenever canvas sections have been empty for 5+ cycles, include a "Discovery Gaps" paragraph in your cycle log suggesting what context would improve planning. Examples: "Your project context would benefit from MVP boundary definition" or "Consider documenting key user journeys." Keep suggestions conversational \u2014 do NOT create tasks for discovery gaps. If all canvas sections are populated, or no Discovery Canvas is provided, skip this step entirely.
-
-6. **Maturity Gate** \u2014 Before scheduling any task, check whether the project is ready for it:
-   - **Cycle number as signal:** A Cycle 3 project should not be scheduling OAuth, billing, or analytics tasks. Early cycles focus on core functionality and proving the concept works.
-   - **Phase prerequisites:** If the board has phases, tasks from later phases should only be scheduled when earlier phases have completed tasks (check Done count per phase). A task in "Phase 4: Monetisation" is premature if Phase 2 tasks are still in Backlog.
-   - **Dependency chain:** If a task's \`dependsOn\` references incomplete tasks, it cannot be scheduled regardless of priority.
-   - **Task maturity:** Tasks with \`maturity: "raw"\` are unscoped ideas from the idea tool. The planner IS the scoping mechanism \u2014 scope them as part of planning. For raw tasks selected for a cycle: (a) derive clear scope, acceptance criteria, and effort from the title, notes, and project context, (b) upgrade them to \`maturity: "investigated"\` via a \`boardCorrections\` entry, and (c) generate a BUILD HANDOFF as normal. For research-type raw tasks, scope the handoff as an investigation task \u2014 the deliverable is findings + follow-up backlog tasks, not code. Only leave a raw task unscheduled if you genuinely cannot derive scope from the available context \u2014 note why in the cycle log. Tasks with \`maturity: "ready"\` or no maturity field are considered cycle-ready. Tasks with \`maturity: "investigated"\` have been scoped but may still need refinement \u2014 schedule them if priority warrants it.
-   - **What to do with premature tasks:** Leave them in Backlog. Do NOT generate BUILD HANDOFFs for them. If a high-priority task fails the maturity gate due to phase prerequisites or dependencies, note it in the cycle log: "task-XXX deferred \u2014 Phase N prerequisites not met". Raw tasks are NOT premature \u2014 they just need scoping (see Task maturity above).
-
-7. **Recommendation** \u2014 Select tasks for this cycle:
-   **Pre-assigned tasks:** If a "Pre-Assigned Tasks" section is provided in the context below, those tasks are ALREADY committed to this cycle by the user. Include them automatically \u2014 do NOT re-evaluate whether they belong. Generate BUILD HANDOFFs for each. Count their effort toward the cycle budget. Then fill remaining slots from the backlog using the priority rules and cycle sizing rules below.
-   **If USER DIRECTION is provided above:** Follow the user's stated focus. Pick the highest-impact task that aligns with their direction. The user knows what they need. Only deviate if a genuine P0 Critical fix exists (broken builds, data loss).
-   **Otherwise, select by priority level then impact:**
-   - **P0 Critical** \u2014 Broken, blocking, or data-loss risk. Always first.
-   - **P1 High** \u2014 Strategically aligned: directly advances the current horizon, phase, or Active Decision goals.
-   - **P2 Medium** \u2014 Valuable but not strategically urgent: quality improvements, efficiency, polish, infra.
-   - **P3 Low** \u2014 Nice-to-have, speculative, or future-horizon work.
-   Within the same priority level, prefer tasks with the highest **impact-to-effort ratio**. Impact is measured by: (a) strategic alignment \u2014 does it advance the current horizon/phase? (b) unlocks other work \u2014 are tasks blocked by this? (c) user-facing \u2014 does it change what users see? (d) compounds over time \u2014 does it make future cycles faster? A high-impact Medium task beats a low-impact Small task at the same priority level. Justify in 2-3 sentences.
-   **Blocked tasks:** Tasks with status "Blocked" MUST be skipped during task selection \u2014 they are waiting on external dependencies or gates and cannot be built. Do NOT generate BUILD HANDOFFs for blocked tasks. Do NOT recommend blocked tasks. If a blocked task's gate has been resolved (check the notes and recent build reports), emit a \`boardCorrections\` entry to move it back to Backlog. Report blocked task count in the cycle log.
-   **Cycle sizing:** Size the cycle based on what the selected tasks actually require \u2014 not a fixed budget. Select the highest-priority unblocked tasks, estimate each one's effort from its scope, and let the total emerge. The historical average effort from Methodology Trends is a reference point for calibration, not a target or floor. A healthy cycle has 6-10 tasks. Cycles with fewer than 5 tasks require explicit justification in the cycle log \u2014 explain why more tasks could not be included. When the backlog has 10+ tasks, the cycle SHOULD have 6+ tasks \u2014 undersized cycles waste planning overhead relative to the available work. If fewer than 5 tasks qualify after filtering (blocked, deferred, raw), check Deferred tasks \u2014 some may be ready to un-defer via a \`boardCorrections\` entry. A 1-task cycle is almost never correct. Prefer grouping tasks by module or similarity \u2014 reduces context switching and enables shared branches during the build phase.
-   **Theme-driven sizing:** Single-theme cycles (all tasks in the same module or epic) can absorb 25-30 effort points because builders maintain context across tasks. Mixed-theme cycles should stay at 15-20 effort points to limit context switching. Use the theme to determine the budget, not a fixed number.
-   **Theme coherence:** After selecting candidate tasks, check whether they form a coherent theme \u2014 all serving one goal, phase, or module. Single-theme cycles produce better build quality and less context switching. If the top candidates touch 3+ unrelated modules or epics, prefer regrouping around the highest-priority theme and deferring the outliers. Mixed-theme cycles are acceptable when justified (e.g. a P0 fix alongside P1 feature work), but the justification must appear in the cycle log. Name the theme in 3-5 words \u2014 it becomes the \`cycleLogTitle\`.
-   **Epic-aware batching:** Epic is the primary grouping signal for theme coherence. When multiple candidate tasks share the same epic (e.g. "Onboarding Redesign", "Dashboard Polish"), prefer co-scheduling them \u2014 they solve connected problems and benefit from shared context during the build. Steps: (1) After filtering by priority, group eligible tasks by epic. (2) If an epic has 3+ eligible tasks, prefer scheduling 2-4 of them together over cherry-picking across epics. (3) Report the epic distribution in the cycle log (e.g. "4 tasks from Onboarding epic, 1 from Platform"). Priority still overrides: a P0 fix from a different epic always takes precedence.
-   **Opportunity clustering:** If backlog tasks have an \`opportunity\` field populated, group them by opportunity before selecting. Tasks sharing the same opportunity solve the same user problem \u2014 co-scheduling them produces more coherent cycles. Report opportunity clusters in the cycle log when present (e.g. "3 tasks clustered under 'planner accuracy' opportunity").
-
-8. **Cycle Log** \u2014 Write 5-10 line entry: what was triaged, what was recommended and why, observations, AD updates. Include a **Priority Recalibration** paragraph if any unreviewed task priorities were changed during triage (Step 2) \u2014 list each by ID with old \u2192 new priority and rationale. Include a **Priority Drift Suggestions** paragraph if reviewed task drift was detected (Step 3).
-   **Cycle Notes** \u2014 Optionally include 1-3 lines of cycle-level observations in \`cycleLogNotes\`: estimation accuracy patterns, recurring blockers, velocity trends, or dependency signals. These notes persist across cycles so future planning runs can learn from them. Use null if there are no noteworthy observations this cycle.
-
-9. **Active Decisions** \u2014 If any AD needs updating: Type A (confidence change), Type B (modification), or Type C (reversal/supersede).
-   **AD Quality Bar:** ADs are for product and architecture choices that constrain future work \u2014 technology selections, data model designs, UX principles, strategic positioning. They are NOT for: process preferences (commit style, PR size), configuration choices (linter rules, tab width), or temporary workarounds. If a decision doesn't affect what gets built or how it's architected, it's not an AD. Apply this bar when proposing new ADs and when triaging existing ones.
-   **Reversal Trigger (required for new ADs):** Every new AD body must include a \`### Reversal Trigger\` section. Wording: "Under what conditions would this stance reverse? Specify: the signal (concrete event or metric threshold); the action (mint new AD, modify, supersede, or abandon); and why writing this now reduces sunk-cost drift later." Example: "Signal: 3+ external users report >10-min setup time. Action: supersede with a streamlined onboarding AD. Why: measuring it now means we act before it becomes a retention problem." Existing ADs without this section remain valid \u2014 do not retroactively add triggers. Only include when creating a new AD or substantially modifying an existing one.
-
-${AD_REJECTION_RULES}
-
-   **\u2192 PERSIST:** EVERY AD you created, updated, or confirmed with changes MUST appear in \`activeDecisions\` array in Part 2. Include the full replacement body with ### heading.
-
-### Operational Quality Rules
-- **Idea similarity pause:** When the idea tool finds similar tasks during planning, stop and explain the overlap \u2014 do not silently ignore the similarity warning. Duplicates bloat the board and waste build slots.
-- **Backlog as steering wheel:** Task priority and notes in the backlog are the user's primary control mechanism over what gets planned. Respect the priority rankings and read task notes carefully \u2014 they contain user intent that shapes scope and scheduling.
-- **Planning quality is the bar:** Strategy review depth and plan quality set the standard for the product. Do not cut corners on analysis depth, triage thoroughness, or handoff specificity \u2014 these are what users experience as PAPI's value.
-
-10. **BUILD HANDOFFs** \u2014 Generate a full BUILD HANDOFF block for every task selected for this cycle. Include each handoff in the \`cycleHandoffs\` array in the structured output. The handoffs are written to each task on the board for durability.
-   **SKIP existing handoffs:** Tasks marked with "Has BUILD HANDOFF: yes" or "\u2713 handoff" on the board already have a valid handoff from a previous plan. Do NOT regenerate handoffs for these tasks \u2014 omit them from the \`cycleHandoffs\` array entirely. Only generate handoffs for tasks that do NOT have one yet. Exception: if a task's dependencies have been completed since its handoff was written, or a relevant Active Decision has changed, you MAY regenerate its handoff \u2014 but note this explicitly in the cycle log.
-   **Scope pre-check:** Before writing the SCOPE section of each handoff, cross-reference the task against the "Recently Shipped Capabilities" section in the context below (if present). For each candidate task: (1) check if the task's title or scope overlaps with any recently shipped task, (2) check if the FILES LIKELY TOUCHED overlap with files already modified in recent builds, (3) check the architecture notes from recent builds for patterns that already cover this task's scope. If >80% of a task's scope appears in recently shipped capabilities, recommend cancellation via \`boardCorrections\` or reduce the handoff scope to only the missing pieces \u2014 explicitly note what already exists. C126 task-728 was over-scoped because the planner assumed Blocked status needed creating from scratch \u2014 it already existed in types, DB, orient, and build_list. Over-scoped handoffs waste builder time on verification and cause estimation mismatches.
-   **Reality check (task-1755):** Before scoping a handoff for a candidate task, evaluate whether the implicit assumptions a builder would make actually hold. For each task ask: (a) **Replacement assets** \u2014 does the task assume a copy/image/visual/dataset/fixture that doesn't yet exist? (e.g. "swap the hero illustration" assumes a new illustration is ready); (b) **Required user decisions** \u2014 does it assume an answer to an unresolved question (positioning, copy direction, model choice, pricing) that the user has not yet made?; (c) **Infrastructure dependencies** \u2014 does it assume a service/credential/migration/feature flag that isn't yet provisioned? If ANY assumption is unmet: do NOT generate a handoff for that task. Instead include the task in a **Pre-conditions Missing** paragraph in \`cycleLogNotes\` listing the task ID, the missing dependency, and the suggested unblock (e.g. "task-1234: needs new hero illustration \u2014 file separate asset-creation task or surface as a decision"). Drop it from the cycle entirely; the user can re-add it once the dependency is satisfied. ellies-birthday C5 hit two mid-cycle defers in one cycle from this exact gap (handoffs assumed assets that didn't exist) \u2014 reality check catches that before scope is written, not after work starts.
-   **Simplest Viable Path rule:** Before writing each BUILD HANDOFF, identify the simplest approach that satisfies the task's goal \u2014 the minimum change, fewest new abstractions, and smallest blast radius. Write the SCOPE (DO THIS) section for that simplest path FIRST. If you believe a more complex approach is warranted (new abstractions, multi-file refactors, framework changes), you MUST include a "WHY NOT SIMPLER" line in the handoff explaining why the simple path is insufficient. If you cannot articulate a concrete reason, use the simpler path. Pay special attention to tasks involving auth, data access, multi-user features, and infrastructure \u2014 these are the most common over-engineering targets.
-   **Maturity gate applies here:** Do NOT generate BUILD HANDOFFs for tasks that failed the maturity gate in step 6 (phase prerequisites not met, dependency chain incomplete). Raw tasks that the planner has scoped and upgraded to "investigated" in step 6 ARE eligible for handoffs.
-   **Intra-cycle dependency detection:** After selecting cycle tasks, check every pair for build-order dependencies. Two tasks A and B have an intra-cycle dependency when A must be built before B because B consumes an artifact A creates \u2014 e.g. A adds a new adapter method that B calls, A creates a DB migration B depends on, A introduces a new shared type B imports, A refactors a utility B modifies. Signals: same module + adjacent scope (one is "add X", another is "use X"), or notes explicitly reference the other task. For each dependency detected:
-   - Populate the DEPENDS ON section in the dependent task's BUILD HANDOFF with the upstream task ID(s).
-   - Add a \`boardCorrections\` entry for the dependent task with \`updates.dependsOn\` set to the comma-separated upstream IDs \u2014 this persists the dependency so the builder's runtime can reuse the upstream branch.
-   - Keep the SCOPE sections independent (each task still has its own deliverable) but note the ordering in "Why now" \u2014 e.g. "depends on task-123 completing the adapter method".
-   Do NOT invent dependencies where tasks merely share a module \u2014 only real build-order coupling counts. Linear chains only \u2014 do not attempt to resolve multi-level graphs. When in doubt, omit the dependency and let the builder discover it.
-   **Dependency Chain section (Part 1 markdown):** When intra-cycle dependencies are detected, include a visible **## Dependency Chain** section in Part 1 markdown immediately before the first BUILD HANDOFF block. List each dependency as an arrow chain with a brief reason: \`task-A \u2192 task-B (B calls the adapter method A creates)\`. Then show the full recommended build sequence for all cycle tasks, including standalone tasks: e.g. \`Build order: task-A \u2192 task-B; task-C standalone; task-D standalone\`. Flag circular dependencies with \u26A0\uFE0F and a note. Omit this section entirely when no intra-cycle dependencies exist \u2014 do not include an empty section.
-   **Security section guidance:** Each handoff includes a SECURITY CONSIDERATIONS section. Populate it when the task involves: data exposure risks (PII, secrets in logs/storage), secrets or credentials handling (API keys, tokens, env vars), auth/access control changes, or dependency security risks (new packages, version changes). For pure refactoring, documentation, prompt-text, or UI-only tasks, write "None \u2014 no security-relevant changes".
-   **Estimation calibration:** Estimate **XS** for: copy/text-only changes, single string replacements, config tweaks, and any task where the scope is "change words in an existing file" with no logic changes. Estimate **S** for: wiring existing adapter methods, adding API routes following established patterns, modifying prompts, or documentation-only changes. Default to S for pattern-following work. Only use M when genuine new architecture, new DB tables, or multi-file architectural changes are needed. Historical data shows systematic over-estimation (198 over vs 8 under out of 528 tasks) \u2014 when in doubt, estimate smaller. If an "Estimation Calibration (Historical)" section is provided in the context below, use its data to adjust your estimates \u2014 it shows how often each estimated size matched the actual effort. Pay special attention to systematic over/under-estimation patterns (e.g. if M\u2192S happens frequently, estimate S instead of M for similar work).
-   **Reference docs:** If a task's notes include a \`Reference:\` path (e.g. \`Reference: docs/architecture/papi-brain-v1.md\`), include a REFERENCE DOCS section in the BUILD HANDOFF with those paths. This tells the builder to read the referenced doc for background context before implementing. Do NOT omit or summarise the reference \u2014 pass it through so the builder can access the full document. Only tasks with explicit \`Reference:\` paths in their notes should have this section.
-   **Full notes lookup:** Notes in the Board section are truncated to 300 chars for concise task selection. When generating a BUILD HANDOFF for a task, check the "Full Notes for Candidate Tasks" section (if present in context) for that task's complete untruncated notes before writing SCOPE, SCOPE BOUNDARY, and PRE-MORTEM. Submitter context, constraints, and reasoning often live past the 300-char cutoff and must not be dropped from the handoff.
-   **Pre-build verification:** EVERY handoff MUST include a PRE-BUILD VERIFICATION section listing 2-5 specific file paths the builder should read before implementing. Derive these from FILES LIKELY TOUCHED \u2014 pick the files most likely to already contain the target functionality. This is the #1 prevention mechanism for wasted build slots (C120, C125, C126 all scheduled already-shipped work). If the builder finds >80% of the scope already implemented, they report "already built" instead of re-implementing.
-   **Pre-mortem:** For projects with 10+ cycles, include a PRE-MORTEM section in every BUILD HANDOFF with 1-3 bullet points: (a) most likely technical blocker based on module history, (b) integration risk with adjacent systems, (c) scope creep signal \u2014 what the builder might be tempted to expand beyond scope. Draw from \`dead_ends\` and \`surprises\` in recent build reports for the same module. Omit this section entirely for projects with fewer than 10 cycles.
-   **Build order in cycle log:** If any intra-cycle dependencies were detected in this cycle, include a "Build Order" paragraph in \`cycleLogNotes\` showing the recommended build sequence as arrow chains (e.g. "Build order: task-123 \u2192 task-124; task-130 standalone"). Skip this paragraph when no dependencies exist.
-   **Research task detection:** When a task's title starts with "Research:" or the task type is "research", add a RESEARCH OUTPUT section to the BUILD HANDOFF after ACCEPTANCE CRITERIA:
-
-   RESEARCH OUTPUT
-   Deliverable: docs/research/[topic]-findings.md (draft path)
-   Review status: pending owner approval
-   Follow-up tasks: DO NOT submit to backlog until owner confirms findings are actionable
-
-   Also add to ACCEPTANCE CRITERIA: "[ ] Findings doc drafted and saved to docs/research/ before submitting any follow-up ideas"
-
-   **Bug task detection:** When a task's task type is "bug" or the title starts with "Bug:" or "Fix:", apply these rules:
-   - **Auto-P1:** If the task's current priority is P2 or lower, upgrade it to "P1 High" via a boardCorrections entry in Part 2. Note the upgrade in Part 1 analysis.
-   - Add a BLAST RADIUS note to the BUILD HANDOFF SCOPE section: "Bug fix \u2014 minimal blast radius. Change only what is necessary to fix the reported behaviour. Do not refactor surrounding code or expand scope."
-   - Add to ACCEPTANCE CRITERIA: "[ ] Fix is targeted \u2014 no unrelated code changed"
-
-   **Idea task detection:** When a task's task type is "idea", add a scope clarification note to the BUILD HANDOFF:
-   - Add to SCOPE (DO THIS): "This task originated as an idea. Confirm the exact deliverable before implementing \u2014 check task notes and any referenced docs for intent. If scope is unclear, flag it in the build report surprises."
-
-   **UI/visual task detection:** Apply these additions ONLY to tasks whose PRIMARY scope is frontend visual work \u2014 the task's main deliverable must be a UI change, new component, visual design, or page. Do NOT apply to backend tasks, DB migrations, or prompt/config changes that merely mention a dashboard or page in passing. Signal: the task would fail if no .tsx/.css files were changed. If uncertain, skip the UI additions.
-   When a task IS a UI task (primary scope is visual/frontend):
-   - Add to SCOPE: "Read \`.impeccable.md\` for component patterns, anti-patterns, and dev-loop design rules. Read \`docs/branding/brand-book.html\` for brand identity (positioning, voice, palette as final canon). Use the \`frontend-design\` skill for implementation."
-   - For M/L UI tasks, add to SCOPE: "Use the full UI toolchain: Playground (design preview) \u2192 Frontend-design (build) \u2192 Playwright (verify). The playground is the quality bar. Expect 2-3 iterations."
-   - Add to ACCEPTANCE CRITERIA: "[ ] Visually verify rendered output in browser \u2014 provide localhost URL or screenshot to user for review." and "[ ] No raw IDs, abbreviations, or jargon visible without human-readable labels or tooltips."
-   - If the task involves image selection, add to SCOPE: "Include brand/theme direction constraints for image selection \u2014 pull from \`docs/branding/brand-book.html\` for canonical brand identity."
-   The planner's job is scoping, not design direction. Design decisions happen at build time via \`.impeccable.md\` (dev patterns) + \`docs/branding/brand-book.html\` (brand identity) and the frontend-design skill \u2014 don't try to write design specs in the handoff.
-
-11. **New Tasks (max 3 per cycle)** \u2014 Actively mine the Recent Build Reports for task candidates. For each report, check:
-   - **Discovered Issues:** If a build report lists a discovered issue and no existing board task covers it, propose a new task.
-   - **Surprises:** If a surprise reveals a gap (e.g. "schema assumed but not verified"), propose a task to close it.
-   - **Architecture Notes:** If a pattern was established that needs follow-up (e.g. "shared service layer created, MCP migration needed"), propose the follow-up.
-   - **Strategy gaps:** If an Active Decision has no board tasks supporting it, propose one.
-   - **Dogfood observations:** If unactioned dogfood entries are listed in context (with IDs), check if any map to existing tasks. If not, propose a new task. **CRITICAL: Include \`dogfood:<uuid>\` in the new task's \`notes\` field** (e.g. \`"notes": "Addresses recurring friction. dogfood:abc12345-..."\`). This links the task to the observation so the pipeline can track what was actioned. Without this annotation, the observation stays unactioned forever.
-   Create new tasks via the \`newTasks\` array in Part 2. Use \`new-N\` IDs in \`cycleHandoffs\` to reference them. **Limit: 3 new tasks per cycle** to prevent backlog bloat.
-   **\u26A0\uFE0F DUPLICATE CHECK:** Before adding a task to \`newTasks\`, scan the Cycle Board above for any existing task with the same or very similar title/scope. If a matching task already exists (even with slightly different wording), do NOT create a duplicate \u2014 reference the existing task ID instead. The board already contains all active tasks; re-creating them wastes IDs and bloats the board.
-   **\u26A0\uFE0F ALREADY-BUILT CHECK:** Before creating a task, check the recent build reports and cycle log for evidence that this capability was already shipped. If a recent build report shows this feature was completed (even under a different task name), do NOT create a new task for it. This is especially important for UI features, data models, and integrations that may already exist.
-
-12. **Product Brief** \u2014 Check whether the product brief still reflects reality. Update the brief when ANY of these apply:
-   - A new AD was created or an existing AD was superseded that changes product scope, target user, or positioning
-   - The North Star changed or was validated in a way that the brief doesn't reflect
-   - A phase completed that shifts what the product IS (not just what was built)
-   - The brief describes capabilities, architecture, or direction that are no longer accurate
-   - **DRIFT CHECK:** Compare the brief's content against current reality. The brief is drifted if: (a) it describes capabilities that don't exist or have been removed, (b) it references user types, architecture, or positioning that ADs have since changed, (c) the current phase/stage has shifted from what the brief describes, or (d) key metrics or success criteria no longer match the project's direction. Cycle count since last update is a secondary signal only \u2014 a brief updated 15 cycles ago that still accurately describes the product is NOT stale. A brief updated 3 cycles ago that contradicts a recent AD IS drifted.
-   If any of these apply, include an updated \`productBrief\` in the structured output. Include the FULL updated brief (not a diff). Preserve all existing sections and user-added content; update facts, numbers, and status to reflect current reality. Do not regenerate the brief every cycle \u2014 but do not let it go stale either.
-
-13. **Forward Horizon** \u2014 If a Forward Horizon section is provided in the context below, write a "## Forward Horizon" section in Part 1. Surface 2-3 decisions the team should make before the next phase starts. Each item must be:
-   - **Specific** \u2014 reference the upcoming phase by name and the architectural fork or tradeoff involved
-   - **Actionable** \u2014 frame as a decision to make, not a vague warning (e.g. "Decide whether to use WebSockets or SSE for real-time updates before starting Phase 4: Real-Time Features")
-   - **Tied to trajectory** \u2014 based on current board state, ADs, and velocity, not generic advice
-   If the Forward Horizon context is absent or there are no meaningful decisions to surface, omit this section entirely. Do NOT generate generic advice like "plan ahead" or "consider testing".
-
-**CRITICAL: Review your Part 2 JSON before finishing. Every action from Part 1 must have a corresponding entry in Part 2. If Part 1 mentions corrections, new tasks, AD changes, or handoffs but Part 2 has empty arrays \u2014 you have a persistence bug.**`;
 var PLAN_FRAGMENT_DISCOVERY_GAPS = `
 5. **Discovery Gaps** \u2014 If a Discovery Canvas section is provided in the context below, check which sections are populated vs empty. In cycles 1-10, or whenever canvas sections have been empty for 5+ cycles, include a "Discovery Gaps" paragraph in your cycle log suggesting what context would improve planning. Examples: "Your project context would benefit from MVP boundary definition" or "Consider documenting key user journeys." Keep suggestions conversational \u2014 do NOT create tasks for discovery gaps. If all canvas sections are populated, or no Discovery Canvas is provided, skip this step entirely.`;
 var PLAN_FRAGMENT_RESEARCH = `
@@ -11852,8 +12108,7 @@ var PLAN_FRAGMENT_FORWARD_HORIZON = `
    - **Actionable** \u2014 frame as a decision to make, not a vague warning (e.g. "Decide whether to use WebSockets or SSE for real-time updates before starting Phase 4: Real-Time Features")
    - **Tied to trajectory** \u2014 based on current board state, ADs, and velocity, not generic advice
    If the Forward Horizon context is absent or there are no meaningful decisions to surface, omit this section entirely. Do NOT generate generic advice like "plan ahead" or "consider testing".`;
-function buildPlanFullInstructionsConditional(flags, ctx) {
-  if (!flags || !ctx) return PLAN_FULL_INSTRUCTIONS;
+function composeFullModeInstructions(flags, ctx) {
   const parts = [
     `## FULL MODE
 
@@ -11937,6 +12192,7 @@ ${AD_REJECTION_RULES}
 10. **BUILD HANDOFFs** \u2014 Generate a full BUILD HANDOFF block for every task selected for this cycle. Include each handoff in the \`cycleHandoffs\` array in the structured output. The handoffs are written to each task on the board for durability.
    **SKIP existing handoffs:** Tasks marked with "Has BUILD HANDOFF: yes" or "\u2713 handoff" on the board already have a valid handoff from a previous plan. Do NOT regenerate handoffs for these tasks \u2014 omit them from the \`cycleHandoffs\` array entirely. Only generate handoffs for tasks that do NOT have one yet. Exception: if a task's dependencies have been completed since its handoff was written, or a relevant Active Decision has changed, you MAY regenerate its handoff \u2014 but note this explicitly in the cycle log.
    **Scope pre-check:** Before writing the SCOPE section of each handoff, cross-reference the task against the "Recently Shipped Capabilities" section in the context below (if present). For each candidate task: (1) check if the task's title or scope overlaps with any recently shipped task, (2) check if the FILES LIKELY TOUCHED overlap with files already modified in recent builds, (3) check the architecture notes from recent builds for patterns that already cover this task's scope. If >80% of a task's scope appears in recently shipped capabilities, recommend cancellation via \`boardCorrections\` or reduce the handoff scope to only the missing pieces \u2014 explicitly note what already exists. C126 task-728 was over-scoped because the planner assumed Blocked status needed creating from scratch \u2014 it already existed in types, DB, orient, and build_list. Over-scoped handoffs waste builder time on verification and cause estimation mismatches.
+   **\u26A0\uFE0F PRE-SCOPE GROUNDING (enforced):** The Scope pre-check above is NOT optional \u2014 before writing the SCOPE of any "build/implement X" handoff you MUST ground the scope against current reality. (1) Check the "### Relevant Research Docs" context section (if present) AND docs/INDEX.md for an existing design/research/status:final doc that already covers this capability. If one exists, either (a) reduce the handoff SCOPE to only the genuinely-missing pieces and NAME the existing doc inside the handoff, or (b) emit a \`boardCorrections\` cancellation with a \`closureReason\` citing the doc. (2) The resulting handoff's PRE-BUILD VERIFICATION section MUST name the specific files and/or docs the builder reads to confirm X is not already implemented \u2014 this is required at SCOPING time, not deferred for the builder to discover. (3) When a candidate's scope was reduced or cancelled because an existing doc or shipped capability already covers it, record a "Grounding Check:" line in \`cycleLogNotes\` naming the task ID and what was already covered, so the owner sees what the guard caught. Evidence (C273): task-1873 was sized Large but ~half its scope was already shipped (hub OAuth-default, llms.txt), and task-1874 proposed rebuilding shipped login against a status:final research doc \u2014 both because scope was written from a stale basis without this grounding step. Do NOT build a new code/doc search service \u2014 use the injected context above plus docs/INDEX.md.
    **Reality check (task-1755):** Before scoping a handoff for a candidate task, evaluate whether the implicit assumptions a builder would make actually hold. For each task ask: (a) **Replacement assets** \u2014 does the task assume a copy/image/visual/dataset/fixture that doesn't yet exist? (e.g. "swap the hero illustration" assumes a new illustration is ready); (b) **Required user decisions** \u2014 does it assume an answer to an unresolved question (positioning, copy direction, model choice, pricing) that the user has not yet made?; (c) **Infrastructure dependencies** \u2014 does it assume a service/credential/migration/feature flag that isn't yet provisioned? If ANY assumption is unmet: do NOT generate a handoff for that task. Instead include the task in a **Pre-conditions Missing** paragraph in \`cycleLogNotes\` listing the task ID, the missing dependency, and the suggested unblock (e.g. "task-1234: needs new hero illustration \u2014 file separate asset-creation task or surface as a decision"). Drop it from the cycle entirely; the user can re-add it once the dependency is satisfied. ellies-birthday C5 hit two mid-cycle defers in one cycle from this exact gap (handoffs assumed assets that didn't exist) \u2014 reality check catches that before scope is written, not after work starts.
    **Simplest Viable Path rule:** Before writing each BUILD HANDOFF, identify the simplest approach that satisfies the task's goal \u2014 the minimum change, fewest new abstractions, and smallest blast radius. Write the SCOPE (DO THIS) section for that simplest path FIRST. If you believe a more complex approach is warranted (new abstractions, multi-file refactors, framework changes), you MUST include a "WHY NOT SIMPLER" line in the handoff explaining why the simple path is insufficient. If you cannot articulate a concrete reason, use the simpler path. Pay special attention to tasks involving auth, data access, multi-user features, and infrastructure \u2014 these are the most common over-engineering targets.
    **Maturity gate applies here:** Do NOT generate BUILD HANDOFFs for tasks that failed the maturity gate in step 6 (phase prerequisites not met, dependency chain incomplete). Raw tasks that the planner has scoped and upgraded to "investigated" in step 6 ARE eligible for handoffs.
@@ -11947,7 +12203,9 @@ ${AD_REJECTION_RULES}
    **Pre-build verification:** EVERY handoff MUST include a PRE-BUILD VERIFICATION section listing 2-5 specific file paths the builder should read before implementing. Derive these from FILES LIKELY TOUCHED \u2014 pick the files most likely to already contain the target functionality. This is the #1 prevention mechanism for wasted build slots (C120, C125, C126 all scheduled already-shipped work). If the builder finds >80% of the scope already implemented, they report "already built" instead of re-implementing.
    **Pre-mortem:** For projects with 10+ cycles, include a PRE-MORTEM section in every BUILD HANDOFF with 1-3 bullet points: (a) most likely technical blocker based on module history, (b) integration risk with adjacent systems, (c) scope creep signal \u2014 what the builder might be tempted to expand beyond scope. Draw from \`dead_ends\` and \`surprises\` in recent build reports for the same module. Omit this section entirely for projects with fewer than 10 cycles.
    **Intra-cycle dependency detection:** After selecting cycle tasks, check every pair for build-order dependencies. Two tasks A and B have an intra-cycle dependency when A must be built before B because B consumes an artifact A creates \u2014 e.g. A adds a new adapter method that B calls, A creates a DB migration B depends on, A introduces a new shared type B imports, A refactors a utility B modifies. Signals: same module + adjacent scope (one is "add X", another is "use X"), or notes explicitly reference the other task. For each dependency detected: (a) populate the DEPENDS ON section in the dependent task's BUILD HANDOFF with the upstream task ID(s); (b) add a \`boardCorrections\` entry for the dependent task with \`updates.dependsOn\` set to the comma-separated upstream IDs \u2014 this persists the dependency so the builder's runtime can reuse the upstream branch; (c) keep SCOPE sections independent but note the ordering in "Why now". Do NOT invent dependencies where tasks merely share a module \u2014 only real build-order coupling counts. Linear chains only \u2014 no multi-level graph resolution. When in doubt, omit.
-   **Build order in cycle log:** If intra-cycle dependencies were detected, include a "Build order:" line in \`cycleLogNotes\` showing the recommended sequence as arrow chains (e.g. "Build order: task-123 \u2192 task-124; task-130 standalone"). Skip when no dependencies exist.`);
+   **Dependency Chain section (Part 1 markdown):** When intra-cycle dependencies are detected, include a visible **## Dependency Chain** section in Part 1 markdown immediately before the first BUILD HANDOFF block. List each dependency as an arrow chain with a brief reason: \`task-A \u2192 task-B (B calls the adapter method A creates)\`. Then show the full recommended build sequence for all cycle tasks, including standalone tasks: e.g. \`Build order: task-A \u2192 task-B; task-C standalone; task-D standalone\`. Flag circular dependencies with \u26A0\uFE0F and a note. Omit this section entirely when no intra-cycle dependencies exist \u2014 do not include an empty section.
+   **Build order in cycle log:** If intra-cycle dependencies were detected, include a "Build order:" line in \`cycleLogNotes\` showing the recommended sequence as arrow chains (e.g. "Build order: task-123 \u2192 task-124; task-130 standalone"). Skip when no dependencies exist.
+   **Branch-coherence check (task-1908):** In-cycle tasks are routed to one shared branch PER MODULE (\`feat/cycle-N-<module>\`); tasks in different modules land on different branches and merge separately. After writing the handoffs, cross-reference the FILES LIKELY TOUCHED lists: if two selected tasks in DIFFERENT modules name the SAME file, those edits will land on separate branches and collide at merge time (C273 hit two manual merge-conflict resolutions this way on \`docs/architecture/mcp-server-deploy.md\`). For each such overlap, add a "Branch-coherence:" line to \`cycleLogNotes\` naming the two tasks + the shared file and recommend ONE of: consolidate the overlapping tasks into the same module so they share a branch, or sequence them so the second rebases on the first. Do NOT change the one-branch-per-module convention \u2014 flag and recommend only. Same-module overlaps are fine (they already share a branch); only cross-module same-file overlaps are flagged.`);
   if (flags.hasResearchTasks) parts.push(PLAN_FRAGMENT_RESEARCH);
   if (flags.hasBugTasks) parts.push(PLAN_FRAGMENT_BUG);
   if (flags.hasIdeaTasks) parts.push(PLAN_FRAGMENT_IDEA);
@@ -11959,6 +12217,8 @@ ${AD_REJECTION_RULES}
   if (flags.hasOpsBriefTasks) parts.push(PLAN_FRAGMENT_OPS_BRIEF);
   if (flags.hasUITasks) parts.push(PLAN_FRAGMENT_UI);
   parts.push(`
+   **Handoff quality gate (score before emit):** Apply this quality bar to every BUILD HANDOFF \u2014 including any task-type-specific additions above \u2014 before persisting it. ${OUTPUT_QUALITY_RUBRIC} If you had to regenerate a handoff to clear the threshold, you MAY note it in \`cycleLogNotes\` (e.g. "Regenerated task-XXX handoff \u2014 below quality threshold on file specificity").`);
+  parts.push(`
 11. **New Tasks (max 3 per cycle)** \u2014 Actively mine the Recent Build Reports for task candidates. For each report, check:
    - **Discovered Issues:** If a build report lists a discovered issue and no existing board task covers it, propose a new task.
    - **Surprises:** If a surprise reveals a gap (e.g. "schema assumed but not verified"), propose a task to close it.
@@ -11976,6 +12236,26 @@ ${AD_REJECTION_RULES}
 **CRITICAL: Review your Part 2 JSON before finishing. Every action from Part 1 must have a corresponding entry in Part 2. If Part 1 mentions corrections, new tasks, AD changes, or handoffs but Part 2 has empty arrays \u2014 you have a persistence bug.**`);
   return parts.join("\n");
 }
+var PLAN_FULL_BASELINE_FLAGS = {
+  hasBugTasks: true,
+  hasResearchTasks: true,
+  hasIdeaTasks: true,
+  hasSpikeTasks: false,
+  hasUITasks: true,
+  hasTaskTasks: false,
+  hasDesignBriefTasks: false,
+  hasResearchBriefTasks: false,
+  hasMarketingBriefTasks: false,
+  hasOpsBriefTasks: false
+};
+var PLAN_FULL_INSTRUCTIONS = composeFullModeInstructions(PLAN_FULL_BASELINE_FLAGS, {
+  hasDiscoveryCanvas: true,
+  hasHorizonContext: true
+});
+function buildPlanFullInstructionsConditional(flags, ctx) {
+  if (!flags || !ctx) return PLAN_FULL_INSTRUCTIONS;
+  return composeFullModeInstructions(flags, ctx);
+}
 function buildPlanUserMessage(ctx) {
   const modeLabel = ctx.mode.toUpperCase();
   const parts = [
@@ -12270,6 +12550,7 @@ IMPORTANT: You are running as a non-interactive API call. Do NOT ask the user qu
 - **Be concise and scannable.** Use short paragraphs, bullet points, and clear headings. Avoid walls of text. The review should be readable in 3 minutes, not 15. Format cycle summaries as compact bullet points, not multi-paragraph narratives.
 - **Every conditional section earns its place.** If a conditional section has nothing meaningful to say, skip it entirely. Do not write "No issues found" or "No concerns" \u2014 just omit the section.
 - **AD housekeeping is an appendix, not the centerpiece.** Just list changes and make them. Don't score every AD individually. Don't ask for approval on wording tweaks \u2014 small changes (confidence bumps, deleting stale ADs, fixing wording) should just happen. Only flag ADs that represent a genuine strategic question.
+- **Recommendation quality gate.** Apply this quality bar to every \`strategicRecommendations\` point and \`actionItems\` entry before emitting it \u2014 a vague recommendation is worse than none. ${OUTPUT_QUALITY_RUBRIC}
 
 ## TWO-PHASE DELIVERY
 
@@ -18558,6 +18839,9 @@ async function scaffoldPapiDir(adapter2, config2, input) {
     } catch {
     }
   }
+  if (config2.adapterType === "proxy") {
+    return true;
+  }
   const commandsDir = join5(config2.projectRoot, ".claude", "commands");
   const docsDir = join5(config2.projectRoot, "docs");
   await mkdir(commandsDir, { recursive: true });
@@ -18661,9 +18945,6 @@ async function ensurePapiPermission(projectRoot) {
 }
 async function applySetupOutputs(adapter2, config2, input, briefText, adSeedText, conventionsText) {
   const warnings = [];
-  if (config2.adapterType !== "pg") {
-    await writeFile2(join5(config2.papiDir, "PRODUCT_BRIEF.md"), briefText, "utf-8");
-  }
   await adapter2.updateProductBrief(briefText);
   const briefPhases = parsePhases(briefText);
   if (briefPhases.length > 0) {
@@ -18725,7 +19006,7 @@ async function applySetupOutputs(adapter2, config2, input, briefText, adSeedText
       }
     }
   }
-  if (conventionsText?.trim()) {
+  if (conventionsText?.trim() && config2.adapterType !== "proxy") {
     try {
       const claudeMdPath = join5(config2.projectRoot, "CLAUDE.md");
       const existing = await readFile4(claudeMdPath, "utf-8");
@@ -19086,28 +19367,30 @@ async function applySetup(adapter2, config2, input, briefText, adSeedText, conve
       if (msg.startsWith("100% overlap")) throw err;
     }
   }
-  try {
-    const claudeMdPath = join5(config2.projectRoot, "CLAUDE.md");
-    const existing = await readFile4(claudeMdPath, "utf-8");
-    if (!existing.includes("Dogfood Logging")) {
-      const dogfoodSection = [
-        "",
-        "## Dogfood Logging",
-        "",
-        "After each `release`, append a dogfood entry capturing observations from the cycle.",
-        "Call the adapter method with structured entries for each observation:",
-        "",
-        "- **friction** \u2014 workflow pain points, confusing flows, things that broke or slowed you down",
-        "- **methodology** \u2014 what worked or didn't in the plan/build/review cycle",
-        "- **signal** \u2014 indicators of product-market fit, user value, or growth potential",
-        "- **commercial** \u2014 cost, pricing, or business model observations",
-        "",
-        "This is autonomous plumbing \u2014 log observations after release without asking.",
-        ""
-      ].join("\n");
-      await writeFile2(claudeMdPath, existing + dogfoodSection, "utf-8");
+  if (config2.adapterType !== "proxy") {
+    try {
+      const claudeMdPath = join5(config2.projectRoot, "CLAUDE.md");
+      const existing = await readFile4(claudeMdPath, "utf-8");
+      if (!existing.includes("Dogfood Logging")) {
+        const dogfoodSection = [
+          "",
+          "## Dogfood Logging",
+          "",
+          "After each `release`, append a dogfood entry capturing observations from the cycle.",
+          "Call the adapter method with structured entries for each observation:",
+          "",
+          "- **friction** \u2014 workflow pain points, confusing flows, things that broke or slowed you down",
+          "- **methodology** \u2014 what worked or didn't in the plan/build/review cycle",
+          "- **signal** \u2014 indicators of product-market fit, user value, or growth potential",
+          "- **commercial** \u2014 cost, pricing, or business model observations",
+          "",
+          "This is autonomous plumbing \u2014 log observations after release without asking.",
+          ""
+        ].join("\n");
+        await writeFile2(claudeMdPath, existing + dogfoodSection, "utf-8");
+      }
+    } catch {
     }
-  } catch {
   }
   if (adapter2.writeDogfoodEntries) {
     try {
@@ -19129,7 +19412,7 @@ async function applySetup(adapter2, config2, input, briefText, adSeedText, conve
     });
   } catch {
   }
-  const gitignoreNote = await ensureMcpJsonGitignored(config2.projectRoot);
+  const gitignoreNote = config2.adapterType === "proxy" ? void 0 : await ensureMcpJsonGitignored(config2.projectRoot);
   let cursorScaffolded = false;
   try {
     await access2(join5(config2.projectRoot, ".cursor", "rules", "papi.mdc"));
@@ -22528,7 +22811,7 @@ function getInstallId() {
 // src/lib/telemetry.ts
 var HOSTED_SUPABASE_URL2 = process.env["PAPI_HOSTED_SUPABASE_URL"] ?? "https://guewgygcpcmrcoppihzx.supabase.co";
 var DEFAULT_TELEMETRY_ENDPOINT = `${HOSTED_SUPABASE_URL2}/functions/v1/data-proxy`;
-var MD_PINGS_SUPABASE_URL = HOSTED_SUPABASE_URL2;
+var MD_PINGS_SUPABASE_URL = process.env["PAPI_MD_PINGS_URL"] ?? HOSTED_SUPABASE_URL2;
 var MD_PINGS_ANON_KEY = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6Imd1ZXdneWdjcGNtcmNvcHBpaHp4Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3NzI2Njk2NTMsImV4cCI6MjA4ODI0NTY1M30.V5Jw7wJgiMpSQPa2mt0ftjyye5ynG1qLlam00yPVNJY";
 function isEnabled() {
   const val = process.env["PAPI_TELEMETRY"];
@@ -22598,6 +22881,11 @@ function emitMilestone(projectId, milestone, extra) {
     metadata: extra
   });
 }
+function resolveTelemetryProjectId(config2) {
+  if (config2.projectId && config2.projectId.length > 0) return config2.projectId;
+  const env = process.env["PAPI_PROJECT_ID"];
+  return env && env.length > 0 ? env : void 0;
+}
 
 // src/services/release.ts
 init_git();
@@ -23230,16 +23518,32 @@ var state = {
   lastOrientAt: null,
   releaseSinceLastOrient: false,
   sessionStartedAt: Date.now(),
-  lastReviewListAt: null
+  lastReviewListAt: null,
+  failureTimestamps: [],
+  consecutiveFailures: 0
 };
 var CONTEXT_BLOAT_CALL_THRESHOLD = 40;
 var ORIENT_GAP_MS = 3 * 60 * 60 * 1e3;
 var REVIEW_LIST_GUARD_WINDOW_MS = 15 * 60 * 1e3;
+var FAILURE_WINDOW_MS = 30 * 60 * 1e3;
+var FAILURE_RATE_THRESHOLD = 8;
+var CONSECUTIVE_FAILURE_THRESHOLD = 4;
 function recordToolCall(name) {
   state.toolCallCount++;
   if (name === "release") state.releaseSinceLastOrient = true;
   if (name === "review_list") state.lastReviewListAt = Date.now();
 }
+function recordToolOutcome(success) {
+  if (success) {
+    state.consecutiveFailures = 0;
+    return;
+  }
+  const now = Date.now();
+  state.consecutiveFailures++;
+  state.failureTimestamps.push(now);
+  const cutoff = now - FAILURE_WINDOW_MS;
+  state.failureTimestamps = state.failureTimestamps.filter((t) => t >= cutoff);
+}
 function wasReviewListSeenRecently(windowMs = REVIEW_LIST_GUARD_WINDOW_MS) {
   if (state.lastReviewListAt == null) return false;
   return Date.now() - state.lastReviewListAt <= windowMs;
@@ -23252,8 +23556,22 @@ function getProjectConnectionBanner(projectName, projectSlug) {
   if (!projectName || !projectSlug) return null;
   return `[Connected: ${projectName} (${projectSlug})] \u2014 confirm this is the project you mean before I write to it. If it's wrong, don't proceed: pass \`project=<id>\` on the call to target a different project, or fix the project id in your MCP config (PAPI_PROJECT_ID for local, x-papi-project-id header for remote) and reconnect.`;
 }
+function detectContextDegradation(now = Date.now()) {
+  if (state.consecutiveFailures >= CONSECUTIVE_FAILURE_THRESHOLD) {
+    return `Context degradation (clash): ${state.consecutiveFailures} tool calls failed in a row \u2014 the session may be stuck on a contradiction. Consider a fresh window after this task.`;
+  }
+  const cutoff = now - FAILURE_WINDOW_MS;
+  const recentFailures = state.failureTimestamps.filter((t) => t >= cutoff).length;
+  if (recentFailures >= FAILURE_RATE_THRESHOLD) {
+    const mins = Math.round(FAILURE_WINDOW_MS / 6e4);
+    return `Context degradation (distraction/confusion): ${recentFailures} tool failures in the last ${mins}min. A fresh window often clears this faster than pushing on.`;
+  }
+  return null;
+}
 async function buildSessionGuidance() {
   const signals = [];
+  const degradation = detectContextDegradation();
+  if (degradation) signals.push(degradation);
   if (state.toolCallCount > CONTEXT_BLOAT_CALL_THRESHOLD) {
     signals.push(
       `${state.toolCallCount} tool calls this session \u2014 context may be bloated. Consider starting a fresh window.`
@@ -25139,6 +25457,37 @@ function dedupeEnrichmentBlob(existing, blob) {
   return output.join("\n");
 }
 
+// src/lib/verify-project.ts
+async function verifyProject(adapter2) {
+  const warnings = [];
+  if (adapter2.readHorizons && adapter2.readStages) {
+    try {
+      const [horizons, stages] = await Promise.all([
+        adapter2.readHorizons(),
+        adapter2.readStages()
+      ]);
+      if (horizons.length === 0 && stages.length === 0) {
+        warnings.push(
+          "\u26A0\uFE0F Your project predates the AD-14 hierarchy seed (Horizon \u2192 Stage \u2192 Phase \u2192 Task). Hub and Strategy surfaces will be partially empty until horizons + stages are populated. Run `papi setup --backfill-hierarchy` to seed the canonical layout."
+        );
+      }
+    } catch {
+    }
+  }
+  if (adapter2.getProjectOwnerUserId) {
+    try {
+      const ownerUserId = await adapter2.getProjectOwnerUserId();
+      if (ownerUserId === null) {
+        warnings.push(
+          "\u26A0\uFE0F Your project's `projects.user_id` is NULL \u2014 pre-multi-user legacy row. Dashboard ownership and activity attribution will be incomplete until backfilled. Run `papi setup --backfill-user-id` to attach the row to your authenticated user."
+        );
+      }
+    } catch {
+    }
+  }
+  return warnings;
+}
+
 // src/tools/orient.ts
 import { execFile } from "child_process";
 import { promisify } from "util";
@@ -25756,6 +26105,11 @@ async function handleOrient(adapter2, config2, args = {}) {
     if (proxyWarning) buildResult.warnings.push(proxyWarning);
     const p1Warning = p1BacklogOutcome.status === "fulfilled" ? p1BacklogOutcome.value : void 0;
     if (p1Warning) buildResult.warnings.push(p1Warning);
+    try {
+      const verifyWarnings = await verifyProject(adapter2);
+      for (const w of verifyWarnings) buildResult.warnings.push(w);
+    } catch {
+    }
     const ttfvNote = ttfvOutcome.status === "fulfilled" ? ttfvOutcome.value : "";
     const latestTag = latestTagOutcome.status === "fulfilled" ? latestTagOutcome.value : "";
     const versionDrift = versionDriftOutcome.status === "fulfilled" ? versionDriftOutcome.value : void 0;
@@ -26833,6 +27187,45 @@ Use \`learning_action mark\` or submit via \`idea\` to close these out.`
   return errorResponse(`Unknown mode "${mode}". Use "mark" or "list".`);
 }
 
+// src/tools/discovered-issue-resolve.ts
+var discoveredIssueResolveTool = {
+  name: "discovered_issue_resolve",
+  description: 'Mark a discovered_issue (cycle_learnings row, category="issue") as resolved. Pass the learning_id you saw in orient / learning_action list output. The row stays in the database for history, but default reads exclude it. Use this when the underlying fix has actually landed \u2014 NOT when you just created a follow-up task (that is `learning_action mark` with action_taken="task_created"). Optional `note` is recorded as resolved_by.',
+  annotations: { readOnlyHint: false, destructiveHint: false },
+  inputSchema: {
+    type: "object",
+    properties: {
+      issue_id: {
+        type: "string",
+        description: "The cycle_learnings id (UUID) to mark resolved. Find it via `learning_action list` or recent orient output."
+      },
+      note: {
+        type: "string",
+        description: "Optional resolved_by tag \u2014 e.g. the task id whose merge resolved this issue, or the agent name. Recorded for audit."
+      }
+    },
+    required: ["issue_id"]
+  }
+};
+async function handleDiscoveredIssueResolve(adapter2, args) {
+  const issueId = typeof args.issue_id === "string" ? args.issue_id.trim() : "";
+  const note = typeof args.note === "string" ? args.note.trim() : void 0;
+  if (!issueId) {
+    return errorResponse("issue_id is required.");
+  }
+  if (!adapter2.markCycleLearningResolved) {
+    return errorResponse("discovered_issue_resolve requires the pg adapter. Not available in md / proxy mode.");
+  }
+  try {
+    await adapter2.markCycleLearningResolved(issueId, note);
+    return textResponse(
+      `Discovered issue \`${issueId}\` marked resolved${note ? ` (by: \`${note}\`)` : ""}. Future reads will exclude it by default; pass include_resolved=true to surface.`
+    );
+  } catch (err) {
+    return errorResponse(`Failed to resolve issue: ${err instanceof Error ? err.message : String(err)}`);
+  }
+}
+
 // src/tools/project.ts
 import path6 from "path";
 function workspacePapiDir(config2) {
@@ -27214,6 +27607,7 @@ var PAPI_TOOLS = [
   scopeBriefTool,
   adViewTool,
   learningActionTool,
+  discoveredIssueResolveTool,
   projectCreateTool,
   projectListTool,
   projectSwitchTool,
@@ -27390,6 +27784,8 @@ function createServer(adapter2, config2) {
           return handleAdView(adapter2, safeArgs);
         case "learning_action":
           return handleLearningAction(adapter2, safeArgs);
+        case "discovered_issue_resolve":
+          return handleDiscoveredIssueResolve(adapter2, safeArgs);
         case "project_create":
           return handleProjectCreate(adapter2, config2, safeArgs);
         case "project_list":
@@ -27414,6 +27810,7 @@ function createServer(adapter2, config2) {
           console.error(`[papi] Exiting after '${name}' timeout (wedge-recovery #${wedgeRecoveryStats.count}); user must reconnect with /mcp before the next call.`);
           process.exit(2);
         });
+        recordToolOutcome(false);
         return { content: [{ type: "text", text: `Error: ${msg}` }] };
       }
       throw err;
@@ -27426,8 +27823,10 @@ function createServer(adapter2, config2) {
     delete result._contextBytes;
     delete result._contextUtilisation;
     const isError = result.content.some((c) => c.text.startsWith("Error:") || c.text.startsWith("\u274C"));
+    recordToolOutcome(!isError);
     try {
-      const metric = buildMetric(name, elapsed, usage, void 0, contextBytes, contextUtilisation);
+      const clientName = server2.getClientVersion()?.name;
+      const metric = buildMetric(name, elapsed, usage, void 0, contextBytes, contextUtilisation, clientName);
       metric.success = !isError;
       adapter2.appendToolMetric(metric).catch(() => {
       });
@@ -27437,7 +27836,7 @@ function createServer(adapter2, config2) {
       const mdProjectSlug = config2.projectRoot ? config2.projectRoot.split("/").pop() : void 0;
       emitMdAdapterPing(name, { duration_ms: elapsed, success: !isError }, config2.userId, mdProjectSlug);
     }
-    const telemetryProjectId = process.env["PAPI_PROJECT_ID"];
+    const telemetryProjectId = resolveTelemetryProjectId(config2);
     if (telemetryProjectId) {
       emitToolCall(telemetryProjectId, name, elapsed, {
         adapter_type: config2.adapterType
@@ -27725,7 +28124,8 @@ async function dispatchRequest(args) {
   });
   const requestConfig = {
     ...baseConfig,
-    adapterType: "proxy"
+    adapterType: "proxy",
+    projectId: effectiveProjectId
   };
   const server2 = createServer(adapter2, requestConfig);
   const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: void 0 });
@@ -27764,7 +28164,7 @@ async function dispatchRequest(args) {
 var __dirname = dirname5(fileURLToPath3(import.meta.url));
 var pkgVersion = "unknown";
 try {
-  const pkg = JSON.parse(readFileSync12(join20(__dirname, "..", "package.json"), "utf-8"));
+  const pkg = JSON.parse(readFileSync13(join21(__dirname, "..", "package.json"), "utf-8"));
   pkgVersion = pkg.version;
 } catch {
 }
@@ -27778,12 +28178,15 @@ Commands:
   (none)           Start the MCP server (default)
   doctor           Print a diagnostic of your PAPI environment (read-only)
   reset            Surgically remove the papi entry from .mcp.json
+  audit            Cross-project harness/config audit + token-hygiene flags (read-only)
 
 Options:
   --help, -h       Show this help message
   --version, -v    Show version number
   --project <dir>  Set the project directory
   --yes, -y        Skip confirmation prompts (reset only)
+  --idle-mcp       Flag PAPI-idle projects in audit (needs DATABASE_URL; read-only)
+  --fix-pool       Terminate this role's confirmed-wedged DB backends (doctor only; guarded)
 
 Getting started:
   1. Sign up at https://getpapi.ai/login
@@ -27806,12 +28209,16 @@ if (cliArgs.includes("--version") || cliArgs.includes("-v")) {
 var subcommand = cliArgs.find((arg) => !arg.startsWith("-"));
 if (subcommand === "doctor") {
   const { runDoctor: runDoctor2 } = await Promise.resolve().then(() => (init_doctor(), doctor_exports));
-  process.exit(await runDoctor2());
+  process.exit(await runDoctor2(cliArgs));
 }
 if (subcommand === "reset") {
   const { runReset: runReset2 } = await Promise.resolve().then(() => (init_reset(), reset_exports));
   process.exit(await runReset2(cliArgs));
 }
+if (subcommand === "audit") {
+  const { runAudit: runAudit2 } = await Promise.resolve().then(() => (init_audit(), audit_exports));
+  process.exit(await runAudit2(cliArgs));
+}
 process.on("unhandledRejection", (err) => {
   console.error("[papi] unhandledRejection (swallowed):", err instanceof Error ? err.message : err);
 });