sequant 2.9.0 → 2.10.0

package/dist/src/commands/update.js

@@ -7,9 +7,11 @@ import { spawnSync } from "child_process";
 import { getManifest, updateManifest, getPackageVersion, } from "../lib/manifest.js";
 import { computeTemplateChanges } from "../lib/templates.js";
 import { getConfig, saveConfig } from "../lib/config.js";
-import { getStackConfig, PM_CONFIG, getPackageManagerCommands, } from "../lib/stacks.js";
+import { getStackConfig, PM_CONFIG, getPackageManagerCommands, resolvePackageManager, } from "../lib/stacks.js";
 import { writeFile } from "../lib/fs.js";
+import { chmod } from "fs/promises";
 import { isStdinTTY, isCI, getNonInteractiveReason } from "../lib/tty.js";
+import { syncSequantMcpPin } from "../lib/mcp-config.js";
 /**
  * True when `update` must not prompt: stdin is not a terminal (piped input) or
  * we are running in a recognized CI environment. CI is checked explicitly
@@ -41,8 +43,18 @@ export async function updateCommand(options) {
     const manifest = await getManifest();
     if (!manifest) {
         console.log(chalk.red("❌ Sequant is not initialized. Run `sequant init` first."));
+        process.exitCode = 1;
         return;
     }
+    // Resolved once for the whole command. The manifest's packageManager is a
+    // snapshot taken at `sequant init`, so it is absent on pre-1.3.0 installs —
+    // exactly the population the PM_RUN backfill below exists to serve. The
+    // three sites that used to spell this `(manifest.packageManager as keyof
+    // typeof PM_CONFIG) || "npm"` therefore assumed npm for those installs, and
+    // wrote an npm PM_RUN token into a pnpm/yarn/bun project's config (#870).
+    // The root is the cwd because `update` operates on the project in place,
+    // the same directory `getManifest` and `syncSequantMcpPin` read.
+    const pm = resolvePackageManager(manifest.packageManager, process.cwd());
     const packageVersion = getPackageVersion();
     console.log(chalk.gray(`Current version: ${manifest.version}`));
     console.log(chalk.gray(`Stack: ${manifest.stack}`));
@@ -64,7 +76,6 @@ export async function updateCommand(options) {
         console.log(chalk.gray(`Dev URL: ${tokens.DEV_URL || "(not set)"}\n`));
         // Add PM_RUN if missing (for existing installs before v1.3.0)
         if (!tokens.PM_RUN) {
-            const pm = manifest.packageManager || "npm";
             const pmConfig = getPackageManagerCommands(pm);
             tokens.PM_RUN = pmConfig.run;
             config.tokens = tokens;
@@ -78,7 +89,6 @@ export async function updateCommand(options) {
         const stackConfig = getStackConfig(manifest.stack);
         const defaultDevUrl = stackConfig.devUrl;
         // Get package manager run command
-        const pm = manifest.packageManager || "npm";
         const pmConfig = getPackageManagerCommands(pm);
         if (options.force || options.yes) {
             tokens = { DEV_URL: defaultDevUrl, PM_RUN: pmConfig.run };
@@ -116,6 +126,16 @@ export async function updateCommand(options) {
             console.log(chalk.green("✔ Configuration saved\n"));
         }
     }
+    // Re-pin the project .mcp.json MCP server to the installed version (#793).
+    // Independent of template changes: a version-only upgrade leaves every
+    // template unchanged (so the flow would short-circuit at "Everything is up to
+    // date" below) but should still refresh the pin so the MCP server tracks the
+    // release the user just updated to. Runs here, before that short-circuit.
+    const mcpPin = syncSequantMcpPin(process.cwd(), { dryRun: options.dryRun });
+    if (mcpPin.updated) {
+        const verb = options.dryRun ? "Would update" : "Updated";
+        console.log(chalk.blue(`${verb} .mcp.json MCP pin: ${mcpPin.from} → ${mcpPin.to}`));
+    }
     // Compute changes using the shared, variable-aware comparison.
     // Templates are rendered (PROJECT_NAME, STACK_NOTES, etc.) before diffing,
     // and in-place-customizable files (constitution) are protected as overrides.
@@ -202,6 +222,11 @@ export async function updateCommand(options) {
     let updated = 0;
     for (const file of applySet) {
         await writeFile(file.path, file.rendered);
+        // Shell scripts (hooks, scripts/dev) need the exec bit, matching the
+        // copyTemplates write path.
+        if (file.path.endsWith(".sh")) {
+            await chmod(file.path, 0o755);
+        }
         updated++;
     }
     // Update manifest
@@ -210,8 +235,6 @@ export async function updateCommand(options) {
     // Check if package.json was updated and run install
     const packageJsonUpdated = applySet.some((f) => f.path === "package.json" || f.path.endsWith("/package.json"));
     if (packageJsonUpdated) {
-        // Use detected package manager or default to npm
-        const pm = manifest.packageManager || "npm";
         const pmConfig = PM_CONFIG[pm];
         console.log(chalk.blue(`\npackage.json updated, running ${pmConfig.install}...`));
         const [cmd, ...args] = pmConfig.install.split(" ");

package/dist/src/lib/ac-parser.d.ts

@@ -6,6 +6,12 @@
  * Also supports alternate formats: `- [ ] **B2:** Description`
  * And bold-wrapped format: `- [ ] **AC-1: Description**`
  *
+ * Bare checkbox items (`- [ ] Some requirement`, no ID prefix) are also
+ * honored, but ONLY under an explicit `## Acceptance Criteria` heading, where
+ * they receive synthesized stable IDs. Human-authored issues rarely prefix
+ * their ACs with IDs, so without this every hand-written issue parsed to zero
+ * ACs — blinding every downstream AC consumer (#850).
+ *
  * @example
  * ```typescript
  * import { parseAcceptanceCriteria } from './ac-parser';
@@ -39,8 +45,16 @@ export declare function inferVerificationMethod(description: string): ACVerifica
  * - `- [ ] **AC-1:** Description`
  * - `- [ ] **B2:** Description`
  * - `- [ ] **AC-1: Description**` (bold wraps ID + description)
+ * - `- [ ] **AC-1** Description` (bold ID, no colon)
+ * - `- [ ] **AC-1**: Description` (colon outside the bold)
  * - `- [ ] AC-1: Description`
  *
+ * Bare checkbox items without an ID prefix (`- [ ] Some requirement`) are also
+ * parsed, but ONLY under an explicit `## Acceptance Criteria` heading, where
+ * they receive synthesized stable IDs (`AC-1`, `AC-2`, ...). This keeps
+ * unrelated checklists elsewhere in the body (Open Questions, Test Plan) from
+ * being misread as ACs, while letting ordinary human-written issues parse.
+ *
  * @param issueBody - The full GitHub issue body markdown
  * @returns Array of parsed acceptance criteria
  */

package/dist/src/lib/ac-parser.js

@@ -6,6 +6,12 @@
  * Also supports alternate formats: `- [ ] **B2:** Description`
  * And bold-wrapped format: `- [ ] **AC-1: Description**`
  *
+ * Bare checkbox items (`- [ ] Some requirement`, no ID prefix) are also
+ * honored, but ONLY under an explicit `## Acceptance Criteria` heading, where
+ * they receive synthesized stable IDs. Human-authored issues rarely prefix
+ * their ACs with IDs, so without this every hand-written issue parsed to zero
+ * ACs — blinding every downstream AC consumer (#850).
+ *
  * @example
  * ```typescript
  * import { parseAcceptanceCriteria } from './ac-parser';
@@ -33,6 +39,9 @@ import { createAcceptanceCriterion, createAcceptanceCriteria, } from "./workflow
  * - `- [ ] **B2:** Description`
  * - `- [ ] **AC1:** Description`
  * - `- [ ] **AC-1: Description**` (bold wraps ID + description)
+ * - `- [ ] **AC-1** Description` (bold ID, no colon)
+ * - `- [ ] **AC-1**: Description` (colon outside the bold)
+ * - `- [ ] AC-1: Description`
  */
 const AC_PATTERNS = [
     // Pattern 1: `- [ ] **AC-1:** Description` or `- [x] **AC-1:** Description`
@@ -43,7 +52,41 @@ const AC_PATTERNS = [
     /^-\s*\[[x\s]\]\s*\*\*([A-Za-z]+-?\d+):\s*(.+?)\*\*\s*(.*)$/gim,
     // Pattern 4: `- [ ] AC-1: Description` (no bold)
     /^-\s*\[[x\s]\]\s*([A-Za-z]+-?\d+):\s*(.+)$/gim,
+    // Pattern 5: `- [ ] **AC-1** Description` / `- [ ] **AC-1**: Description` (#808)
+    //
+    // The colon-less form is a very common authoring style, and before this
+    // pattern existed it matched nothing at all — an issue written this way
+    // parsed as ZERO acceptance criteria, silently, with no warning anywhere
+    // downstream (#803's five ACs were written exactly like this).
+    //
+    // The trailing `:?` also absorbs a colon placed *outside* the bold, which
+    // would otherwise land in the description as a leading ": ".
+    //
+    // Deliberately requires the bold markers. A bare `- [ ] AC1 something` is
+    // ambiguous against ordinary checklist prose, so widening that far would
+    // trade a silent miss for silent false positives. The `\d+` at the end of
+    // the ID keeps non-identifier bold labels (`**Note**`, `**Verify**`) out.
+    /^-\s*\[[x\s]\]\s*\*\*([A-Za-z]+-?\d+)\*\*:?\s*(.+)$/gim,
 ];
+/**
+ * Matches an `## Acceptance Criteria` heading (any level, case-insensitive).
+ *
+ * Real issues vary the casing — #703 uses `## Acceptance criteria` (lowercase
+ * "criteria") — so the match must be case-insensitive. The trailing `\b` lets
+ * a suffix follow ("Acceptance Criteria (v2)") without demanding an exact end.
+ */
+const AC_HEADING_RE = /^#{1,6}\s+acceptance\s+criteria\b/i;
+/**
+ * Matches any markdown ATX heading. Used to detect when the AC section ends —
+ * the next heading of any level closes it, mirroring `parseNonGoals` in
+ * `ready-gate.ts`.
+ */
+const HEADING_RE = /^#{1,6}\s+/;
+/**
+ * Matches a bare checkbox item with no ID prefix: `- [ ] Some requirement`.
+ * Honored only inside the AC section (see {@link parseAcceptanceCriteria}).
+ */
+const BARE_CHECKBOX_RE = /^-\s*\[[x\s]\]\s*(.+)$/i;
 /**
  * Keywords that suggest verification method
  */
@@ -122,22 +165,73 @@ function parseACLine(line) {
  * - `- [ ] **AC-1:** Description`
  * - `- [ ] **B2:** Description`
  * - `- [ ] **AC-1: Description**` (bold wraps ID + description)
+ * - `- [ ] **AC-1** Description` (bold ID, no colon)
+ * - `- [ ] **AC-1**: Description` (colon outside the bold)
  * - `- [ ] AC-1: Description`
  *
+ * Bare checkbox items without an ID prefix (`- [ ] Some requirement`) are also
+ * parsed, but ONLY under an explicit `## Acceptance Criteria` heading, where
+ * they receive synthesized stable IDs (`AC-1`, `AC-2`, ...). This keeps
+ * unrelated checklists elsewhere in the body (Open Questions, Test Plan) from
+ * being misread as ACs, while letting ordinary human-written issues parse.
+ *
  * @param issueBody - The full GitHub issue body markdown
  * @returns Array of parsed acceptance criteria
  */
 export function parseAcceptanceCriteria(issueBody) {
     const criteria = [];
     const seenIds = new Set();
-    // Split into lines and process each
+    const push = (id, description) => {
+        if (seenIds.has(id))
+            return;
+        seenIds.add(id);
+        criteria.push(createAcceptanceCriterion(id, description, inferVerificationMethod(description)));
+    };
+    // Split into lines and process each. `inAcSection` tracks whether the
+    // current line falls under an `## Acceptance Criteria` heading; it toggles on
+    // every heading and closes at the next heading of any level (same boundary
+    // rule as `parseNonGoals` in ready-gate.ts). `bareCount` numbers synthesized
+    // IDs for bare checkboxes in appearance order.
     const lines = issueBody.split("\n");
+    let inAcSection = false;
+    let bareCount = 0;
+    // Pre-scan for explicit IDs anywhere in the body. Synthesis must skip IDs
+    // owned by explicit markers even when the marker appears on a LATER line —
+    // otherwise a bare checkbox listed before `**AC-1:**` under the same heading
+    // synthesizes AC-1 first and the author's explicit AC-1 is silently dropped
+    // by the first-occurrence dedupe.
+    const explicitIds = new Set();
     for (const line of lines) {
         const parsed = parseACLine(line);
-        if (parsed && !seenIds.has(parsed.id)) {
-            seenIds.add(parsed.id);
-            const verificationMethod = inferVerificationMethod(parsed.description);
-            criteria.push(createAcceptanceCriterion(parsed.id, parsed.description, verificationMethod));
+        if (parsed)
+            explicitIds.add(parsed.id);
+    }
+    for (const line of lines) {
+        if (HEADING_RE.test(line)) {
+            inAcSection = AC_HEADING_RE.test(line);
+            continue;
+        }
+        // Existing ID-prefixed patterns run on every line, regardless of section,
+        // so previously-parsable issues are unaffected (AC-4).
+        const parsed = parseACLine(line);
+        if (parsed) {
+            push(parsed.id, parsed.description);
+            continue;
+        }
+        // Bare-checkbox fallback: only inside the AC section (AC-1/AC-2).
+        if (inAcSection) {
+            const bare = line.match(BARE_CHECKBOX_RE);
+            const description = bare?.[1].trim();
+            if (description) {
+                // Synthesize `AC-<n>`, skipping any ID already taken by an explicit
+                // marker — before OR after this line — so a synthesized ID can never
+                // collide with (and be silently dropped against) a hand-written one.
+                let id;
+                do {
+                    id = `AC-${++bareCount}`;
+                } while (seenIds.has(id) || explicitIds.has(id));
+                push(id, description);
+            }
         }
     }
     return criteria;

package/dist/src/lib/assess/index.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Deterministic rendering for `/assess` output (#823).
+ *
+ * `types.ts` owns the contract, `renderer.ts` owns the geometry. Neither touches
+ * TTY state, ANSI, or I/O — see the header comment in `renderer.ts` for why that
+ * rules out the `cli-ui.ts` helpers.
+ */
+export { AssessActionSchema, AssessChainSchema, AssessCleanupSchema, AssessCommandSchema, AssessFlagSchema, AssessIssueSchema, AssessResultSchema, AssessResultValidationError, AssessWarningSchema, parseAssessResult, } from "./types.js";
+export type { AssessAction, AssessChain, AssessCleanup, AssessCommand, AssessFlag, AssessIssue, AssessResult, AssessWarning, } from "./types.js";
+export { GEOMETRY, render, renderBatch, renderSingle } from "./renderer.js";

package/dist/src/lib/assess/index.js

@@ -0,0 +1,9 @@
+/**
+ * Deterministic rendering for `/assess` output (#823).
+ *
+ * `types.ts` owns the contract, `renderer.ts` owns the geometry. Neither touches
+ * TTY state, ANSI, or I/O — see the header comment in `renderer.ts` for why that
+ * rules out the `cli-ui.ts` helpers.
+ */
+export { AssessActionSchema, AssessChainSchema, AssessCleanupSchema, AssessCommandSchema, AssessFlagSchema, AssessIssueSchema, AssessResultSchema, AssessResultValidationError, AssessWarningSchema, parseAssessResult, } from "./types.js";
+export { GEOMETRY, render, renderBatch, renderSingle } from "./renderer.js";

package/dist/src/lib/assess/renderer.d.ts

@@ -0,0 +1,64 @@
+/**
+ * Deterministic renderer for `/assess` output (#823).
+ *
+ * ## Why this module exists
+ *
+ * `/assess` was asked to hand-draw an aligned ASCII dashboard inside a prompt.
+ * It did two things wrong, both recurring: it silently substituted a prose
+ * summary for the block entirely, and when it did draw the table the columns
+ * drifted (every worked example in `SKILL.md` had its header offset from its own
+ * data rows). Both are the same root cause — deterministic formatting done by
+ * hand. This module takes the arithmetic away from the model. The model keeps
+ * the judgment; a tool call, which is observable in the transcript, produces the
+ * geometry.
+ *
+ * ## Why not `cli-ui.ts`
+ *
+ * Its `table()` / `box()` / `divider()` / `sectionHeader()` helpers are the
+ * obvious first instinct and the wrong tool. They emit ANSI via `chalk`, gate on
+ * `config.isTTY` / `config.jsonMode` (so they silently degrade when stdout is a
+ * pipe — which it always is here, since this runs from a Bash call), and
+ * `table()` delegates to `cli-table3`'s bordered grid. This output lands in a
+ * chat transcript *and* is posted to GitHub, then re-parsed by
+ * `assess-comment-parser.ts`. It must be byte-stable, ANSI-free, and
+ * copy-pasteable.
+ *
+ * The only thing shared with the terminal UI is the `string-width` dependency.
+ * The module is otherwise modeled on `src/lib/cli-ui/format.ts`: pure
+ * deterministic string formatting, no TTY state, no I/O.
+ */
+import type { AssessResult } from "./types.js";
+/** Column at which the `Reason` field starts, given whether `ACs` is shown. */
+declare function reasonCol(withAcs: boolean): number;
+/** Width of the `Reason` field — whatever is left before {@link RUN_COL}. */
+declare function reasonWidth(withAcs: boolean): number;
+/**
+ * Render the batch dashboard: table → `Commands:` → annotations → markers.
+ *
+ * Every section is conditional (Section Visibility Rules). A section that has no
+ * content takes its adjacent separator with it, so an all-clear batch renders as
+ * table → separator → commands → separator → markers and nothing else.
+ */
+export declare function renderBatch(result: AssessResult): string;
+/**
+ * Render the single-issue assessment for one verdict.
+ *
+ * PROCEED and REWRITE templates define a `⚠` region between two trailing
+ * separators. CLOSE / CLARIFY / PARK / MERGE do not, so a carried warning
+ * becomes its own separator-delimited block immediately above the markers — the
+ * one case where a posted comment extends a slot-less template.
+ */
+export declare function renderSingle(result: AssessResult): string;
+/** Dispatch on `mode`. The entry point the CLI subcommand calls. */
+export declare function render(result: AssessResult): string;
+/**
+ * Geometry constants, exported for tests and for documenting the layout.
+ * Consumers should treat these as read-only.
+ */
+export declare const GEOMETRY: {
+    readonly RUN_COL: 47;
+    readonly SEPARATOR_WIDTH: 64;
+    readonly reasonCol: typeof reasonCol;
+    readonly reasonWidth: typeof reasonWidth;
+};
+export {};