lsd-pi 1.0.0 → 1.1.1

package/src/resources/extensions/gsd/prompts/validate-milestone.md

@@ -1,47 +0,0 @@
-You are executing GSD auto-mode.
-
-## UNIT: Validate Milestone {{milestoneId}} ("{{milestoneTitle}}")
-
-## Working Directory
-
-Your working directory is `{{workingDirectory}}`. All file reads, writes, and shell commands MUST operate relative to this directory. Do NOT `cd` to any other directory.
-
-## Your Role in the Pipeline
-
-All slices are done. Before the milestone can be completed, you must validate that the planned work was delivered as specified. Compare the roadmap's success criteria and slice definitions against the actual slice summaries and UAT results. This is a reconciliation gate — catch gaps, regressions, or missing deliverables before the milestone is sealed.
-
-This is remediation round {{remediationRound}}. If this is round 0, this is the first validation pass. If > 0, prior validation found issues and remediation slices were added and executed — verify those remediation slices resolved the issues.
-
-All relevant context has been preloaded below — the roadmap, all slice summaries, UAT results, requirements, decisions, and project context are inlined. Start working immediately without re-reading these files.
-
-{{inlinedContext}}
-
-{{skillActivation}}
-
-## Validation Steps
-
-1. For each **success criterion** in `{{roadmapPath}}`, check whether slice summaries and UAT results provide evidence that it was met. Record pass/fail per criterion.
-2. For each **slice** in the roadmap, verify its demo/deliverable claim against its summary. Flag any slice whose summary does not substantiate its claimed output.
-3. Check **cross-slice integration points** — do boundary map entries (produces/consumes) align with what was actually built?
-4. Check **requirement coverage** — are all active requirements addressed by at least one slice?
-5. If **Verification Classes** are provided in the inlined context above, check each non-empty class:
-   - For each verification class (Contract, Integration, Operational, UAT), determine whether slice summaries, UAT results, or observable behavior provide evidence that this verification tier was addressed.
-   - Document the compliance status of each class in a dedicated verification classes section.
-   - If `Operational` verification is non-empty and no evidence of operational verification exists, flag this explicitly — it means planned operational checks (migrations, deployments, runtime verification) were not proven.
-   - A milestone with unaddressed verification classes may still pass if the gaps are minor, but the gaps MUST be documented in the Deferred Work Inventory.
-6. Determine a verdict:
-   - `pass` — all criteria met, all slices delivered, no gaps
-   - `needs-attention` — minor gaps that do not block completion (document them)
-   - `needs-remediation` — material gaps found; remediation slices must be added to the roadmap
-
-## Persist Validation
-
-**Persist validation results through `gsd_validate_milestone`.** Call it with: `milestoneId`, `verdict`, `remediationRound`, `successCriteriaChecklist`, `sliceDeliveryAudit`, `crossSliceIntegration`, `requirementCoverage`, `verificationClasses` (when non-empty), `verdictRationale`, and `remediationPlan` (if verdict is `needs-remediation`). The tool writes the validation to the DB and renders VALIDATION.md to disk.
-
-If verdict is `needs-remediation`:
-- After calling `gsd_validate_milestone`, use `gsd_reassess_roadmap` to add remediation slices. Pass `milestoneId`, a synthetic `completedSliceId` (e.g. "VALIDATION"), `verdict: "roadmap-adjusted"`, `assessment` text, and `sliceChanges` with the new slices in the `added` array. The tool persists the changes to the DB and re-renders ROADMAP.md.
-- These remediation slices will be planned and executed before validation re-runs.
-
-**File system safety:** When scanning milestone directories for evidence, use `ls` or `find` to list directory contents first — never pass a directory path (e.g. `tasks/`, `slices/`) directly to the `read` tool. The `read` tool only accepts file paths, not directories.
-
-When done, say: "Milestone {{milestoneId}} validation complete — verdict: <verdict>."

package/src/resources/extensions/gsd/prompts/workflow-start.md

@@ -1,28 +0,0 @@
-# Workflow Template: {{templateName}}
-
-You are executing a **{{templateName}}** workflow (template: `{{templateId}}`).
-
-## Context
-
-- **Description:** {{description}}
-- **Issue reference:** {{issueRef}}
-- **Date:** {{date}}
-- **Branch:** {{branch}}
-- **Artifact directory:** {{artifactDir}}
-- **Phases:** {{phases}}
-- **Complexity:** {{complexity}}
-
-## Workflow Definition
-
-Follow the workflow defined below. Execute each phase in order, completing one before moving to the next. For low and medium complexity workflows, keep moving by default — pause only at true decision gates (user must choose between materially different directions, outward-facing actions need approval, or the workflow explicitly requires a human checkpoint). For high complexity workflows, confirm at phase transitions unless the workflow explicitly marks a gate as skip-safe.
-
-{{workflowContent}}
-
-## Execution Rules
-
-1. **Follow the phases in order.** Do not skip phases unless the workflow explicitly allows it.
-2. **Artifact discipline.** If an artifact directory is specified, write all planning/summary documents there.
-3. **Atomic commits.** Commit working code after each meaningful change. Use conventional commit format: `<type>(<scope>): <description>`.
-4. **Verify before shipping.** Run the project's test suite and build before marking the workflow complete.
-5. **Decision gates, not ceremony.** After each phase, summarize what changed. For low/medium complexity, ask for confirmation only when the next phase depends on a real user choice or external approval. For high complexity, confirm before proceeding to each new phase.
-6. **Stay focused.** This is a {{complexity}}-complexity workflow. Match your ceremony level to the task — don't over-engineer or under-deliver.

package/src/resources/extensions/gsd/prompts/worktree-merge.md

@@ -1,123 +0,0 @@
-You are merging changes from worktree **{{worktreeName}}** (branch `{{worktreeBranch}}`) into target branch `{{mainBranch}}`.
-
-## Working Directory
-
-Your current working directory has been set to the **main project tree** at `{{mainTreePath}}`. You are on the `{{mainBranch}}` branch. All git and file commands run from here.
-
-- **Main tree (CWD):** `{{mainTreePath}}` — this is where you run `git merge`, read main-branch files, and commit
-- **Worktree directory:** `{{worktreePath}}` — the worktree's working copy; read files here to inspect worktree versions before merging
-- **Worktree branch:** `{{worktreeBranch}}`
-
-## Context
-
-The worktree was created as a parallel workspace. It may contain code changes, new milestones, updated roadmaps, new plans, research, decisions, or other artifacts that need to be merged into the target branch.
-
-### Commit History (worktree)
-
-```
-{{commitLog}}
-```
-
-### Changed Files
-
-**Added files:**
-{{addedFiles}}
-
-**Modified files:**
-{{modifiedFiles}}
-
-**Removed files:**
-{{removedFiles}}
-
-### Code Diff
-
-```diff
-{{codeDiff}}
-```
-
-### GSD Artifact Diff
-
-```diff
-{{gsdDiff}}
-```
-
-## Your Task
-
-Analyze the changes and guide the merge. Follow these steps exactly:
-
-### Step 1: Categorize Changes
-
-Classify each changed file:
-
-**Code changes:**
-- **New source files** — new modules, components, utilities, tests
-- **Modified source files** — changes to existing code
-- **Config changes** — package.json, tsconfig, build config, etc.
-- **Deleted files** — removed source or config files
-
-**GSD artifact changes:**
-- **New milestones** — entirely new M###/ directories with roadmaps
-- **New slices/tasks** — new planning artifacts within existing milestones
-- **Updated roadmaps** — modifications to existing M###-ROADMAP.md files
-- **Updated plans** — modifications to existing slice or task plans
-- **Research/context** — new or updated RESEARCH.md, CONTEXT.md files
-- **Decisions** — changes to DECISIONS.md
-- **Requirements** — changes to REQUIREMENTS.md
-- **Other** — anything else
-
-### Step 2: Conflict Assessment
-
-For each **modified** file, check whether the main branch version has also changed since the worktree branched off. Flag any files where both branches have diverged — these need manual reconciliation.
-
-To compare versions:
-- **Main-branch version:** read the file at its normal path (your CWD is the main tree)
-- **Worktree version:** read the file at `{{worktreePath}}/<relative-path>`
-- Use `git merge-base {{mainBranch}} {{worktreeBranch}}` to find the common ancestor if needed
-
-Classify each modified file:
-- **Clean merges** — main hasn't changed, worktree changes can apply directly
-- **Conflicts** — both branches changed the same file; needs reconciliation
-- **Stale changes** — worktree modified a file that main has since replaced or removed
-
-### Step 3: Merge Strategy
-
-Present a merge plan to the user:
-
-1. For **clean merges**: list files that will merge without conflict
-2. For **conflicts**: show both versions side-by-side and propose a reconciled version
-3. For **new files**: confirm they should be added to the main branch
-4. For **removed files**: confirm the removals are intentional
-
-Ask the user to confirm the merge plan before proceeding.
-
-### Step 4: Execute Merge
-
-Once confirmed, run all commands from `{{mainTreePath}}` (your CWD):
-
-1. Ensure you are on the target branch: `git checkout {{mainBranch}}`
-2. If there are conflicts requiring manual reconciliation, apply the reconciled versions first
-3. Run `git merge --squash {{worktreeBranch}}` to bring in all changes
-4. Review the staged changes — if any reconciled files need adjustment, apply them now
-5. Commit with message: `merge(worktree/{{worktreeName}}): <summary of what was merged>`
-6. Report what was merged
-
-### Step 5: Cleanup Prompt
-
-After a successful merge, ask the user whether to:
-- **Remove the worktree** — delete the worktree directory and the `{{worktreeBranch}}` branch
-- **Keep the worktree** — leave it for continued parallel work
-
-If the user chooses to remove it, run these commands from `{{mainTreePath}}`:
-```
-git worktree remove {{worktreePath}}
-git branch -D {{worktreeBranch}}
-```
-
-**Do NOT use `/worktree remove` — the command handler may not have the correct state after the merge.** Use the git commands directly.
-
-## Important
-
-- Never silently discard changes from either branch
-- When in doubt about a conflict, show both versions and ask the user
-- Preserve all GSD artifact formatting conventions (frontmatter, section structure, checkbox states)
-- If the worktree introduced new milestone IDs that conflict with main, flag this immediately

package/src/resources/extensions/gsd/provider-error-pause.ts

@@ -1,49 +0,0 @@
-export type ProviderErrorPauseUI = {
-  notify(message: string, level?: "info" | "warning" | "error" | "success"): void;
-};
-
-/**
- * Pause auto-mode due to a provider error.
- *
- * For transient errors (rate limits, server errors, overloaded), schedules
- * an automatic resume after a delay. For permanent errors (auth, billing),
- * pauses indefinitely — user must manually resume.
- */
-export async function pauseAutoForProviderError(
-  ui: ProviderErrorPauseUI,
-  errorDetail: string,
-  pause: () => Promise<void>,
-  options?: {
-    isRateLimit?: boolean;
-    isTransient?: boolean;
-    retryAfterMs?: number;
-    resume?: () => void;
-  },
-): Promise<void> {
-  const shouldAutoResume = (options?.isRateLimit || options?.isTransient)
-    && options.retryAfterMs
-    && options.retryAfterMs > 0
-    && options.resume;
-
-  if (shouldAutoResume) {
-    const delaySec = Math.ceil(options!.retryAfterMs! / 1000);
-    const reason = options!.isRateLimit ? "Rate limited" : "Server error (transient)";
-    ui.notify(
-      `${reason}${errorDetail}. Auto-resuming in ${delaySec}s...`,
-      "warning",
-    );
-    await pause();
-
-    // Schedule auto-resume after the delay
-    setTimeout(() => {
-      const resumeMsg = options!.isRateLimit
-        ? "Rate limit window elapsed. Resuming auto-mode."
-        : "Server error recovery delay elapsed. Resuming auto-mode.";
-      ui.notify(resumeMsg, "info");
-      options!.resume!();
-    }, options!.retryAfterMs!);
-  } else {
-    ui.notify(`Auto-mode paused due to provider error${errorDetail}`, "warning");
-    await pause();
-  }
-}

package/src/resources/extensions/gsd/queue-order.ts

@@ -1,230 +0,0 @@
-/**
- * GSD Queue Order — Custom milestone execution ordering.
- *
- * Stores an explicit execution order in `.gsd/QUEUE-ORDER.json`.
- * When present, `findMilestoneIds()` uses this order instead of
- * the default numeric sort (milestoneIdSort).
- *
- * The file is committed to git (not gitignored) so ordering
- * survives branch switches and is shared across sessions.
- */
-
-import { join } from "node:path";
-import { gsdRoot } from "./paths.js";
-import { milestoneIdSort } from "./milestone-ids.js";
-import { loadJsonFileOrNull, saveJsonFile } from "./json-persistence.js";
-
-// ─── Types ───────────────────────────────────────────────────────────────────
-
-interface QueueOrderFile {
-  order: string[];
-  updatedAt: string;
-}
-
-export interface DependencyViolation {
-  milestone: string;
-  dependsOn: string;
-  type: 'would_block' | 'circular' | 'missing_dep';
-  message: string;
-}
-
-export interface DependencyRedundancy {
-  milestone: string;
-  dependsOn: string;
-}
-
-export interface DependencyValidation {
-  valid: boolean;
-  violations: DependencyViolation[];
-  redundant: DependencyRedundancy[];
-}
-
-// ─── Path ────────────────────────────────────────────────────────────────────
-
-function queueOrderPath(basePath: string): string {
-  return join(gsdRoot(basePath), "QUEUE-ORDER.json");
-}
-
-// ─── Type Guards ─────────────────────────────────────────────────────────────
-
-function isQueueOrderFile(data: unknown): data is QueueOrderFile {
-  return data !== null && typeof data === "object" && "order" in data! && Array.isArray((data as QueueOrderFile).order);
-}
-
-// ─── Read / Write ────────────────────────────────────────────────────────────
-
-/**
- * Load the custom queue order. Returns null if no file exists or if
- * the file is corrupt/unreadable.
- */
-export function loadQueueOrder(basePath: string): string[] | null {
-  const data = loadJsonFileOrNull(queueOrderPath(basePath), isQueueOrderFile);
-  return data?.order ?? null;
-}
-
-/**
- * Save a custom queue order to disk.
- */
-export function saveQueueOrder(basePath: string, order: string[]): void {
-  const data: QueueOrderFile = {
-    order,
-    updatedAt: new Date().toISOString(),
-  };
-  saveJsonFile(queueOrderPath(basePath), data);
-}
-
-// ─── Sorting ─────────────────────────────────────────────────────────────────
-
-/**
- * Sort milestone IDs respecting a custom order.
- *
- * - IDs present in `customOrder` appear in that exact sequence.
- * - IDs on disk but NOT in `customOrder` are appended at the end,
- *   sorted by the default `milestoneIdSort` (numeric).
- * - IDs in `customOrder` but NOT on disk are silently skipped.
- * - When `customOrder` is null, falls back to `milestoneIdSort`.
- */
-export function sortByQueueOrder(ids: string[], customOrder: string[] | null): string[] {
-  if (!customOrder) return [...ids].sort(milestoneIdSort);
-
-  const idSet = new Set(ids);
-  const ordered: string[] = [];
-
-  // First: IDs from customOrder that exist on disk
-  for (const id of customOrder) {
-    if (idSet.has(id)) {
-      ordered.push(id);
-      idSet.delete(id);
-    }
-  }
-
-  // Then: remaining IDs not in customOrder, in default sort order
-  const remaining = [...idSet].sort(milestoneIdSort);
-  return [...ordered, ...remaining];
-}
-
-// ─── Pruning ─────────────────────────────────────────────────────────────────
-
-/**
- * Remove IDs from the queue order file that are no longer valid
- * (completed or deleted milestones). No-op if file doesn't exist.
- */
-export function pruneQueueOrder(basePath: string, validIds: string[]): void {
-  const order = loadQueueOrder(basePath);
-  if (!order) return;
-
-  const validSet = new Set(validIds);
-  const pruned = order.filter(id => validSet.has(id));
-
-  if (pruned.length !== order.length) {
-    saveQueueOrder(basePath, pruned);
-  }
-}
-
-// ─── Validation ──────────────────────────────────────────────────────────────
-
-/**
- * Validate a proposed queue order against dependency constraints.
- *
- * Checks:
- * - would_block: A milestone is placed before one of its dependencies
- * - circular: Two or more milestones form a dependency cycle
- * - missing_dep: A milestone depends on an ID that doesn't exist
- * - redundant: A dependency is satisfied by queue position (dep comes earlier)
- */
-export function validateQueueOrder(
-  order: string[],
-  depsMap: Map<string, string[]>,
-  completedIds: Set<string>,
-): DependencyValidation {
-  const violations: DependencyViolation[] = [];
-  const redundant: DependencyRedundancy[] = [];
-
-  const positionMap = new Map<string, number>();
-  for (let i = 0; i < order.length; i++) {
-    positionMap.set(order[i], i);
-  }
-
-  const allKnownIds = new Set([...order, ...completedIds]);
-
-  for (const [mid, deps] of depsMap) {
-    const midPos = positionMap.get(mid);
-    if (midPos === undefined) continue; // not in pending order
-
-    for (const dep of deps) {
-      // Dep already completed — always satisfied
-      if (completedIds.has(dep)) continue;
-
-      // Dep doesn't exist anywhere
-      if (!allKnownIds.has(dep)) {
-        violations.push({
-          milestone: mid,
-          dependsOn: dep,
-          type: 'missing_dep',
-          message: `${mid} depends on ${dep}, but ${dep} does not exist.`,
-        });
-        continue;
-      }
-
-      const depPos = positionMap.get(dep);
-      if (depPos === undefined) continue; // dep not in pending order (edge case)
-
-      if (depPos > midPos) {
-        // Dep comes AFTER this milestone in the order — violation
-        violations.push({
-          milestone: mid,
-          dependsOn: dep,
-          type: 'would_block',
-          message: `${mid} cannot run before ${dep} — ${mid} depends_on: [${dep}].`,
-        });
-      } else {
-        // Dep comes before — satisfied by position, redundant
-        redundant.push({ milestone: mid, dependsOn: dep });
-      }
-    }
-  }
-
-  // Check for circular dependencies
-  const visited = new Set<string>();
-  const inStack = new Set<string>();
-
-  function hasCycle(node: string, path: string[]): string[] | null {
-    if (inStack.has(node)) return [...path, node];
-    if (visited.has(node)) return null;
-
-    visited.add(node);
-    inStack.add(node);
-
-    const deps = depsMap.get(node) ?? [];
-    for (const dep of deps) {
-      if (completedIds.has(dep)) continue;
-      const cycle = hasCycle(dep, [...path, node]);
-      if (cycle) return cycle;
-    }
-
-    inStack.delete(node);
-    return null;
-  }
-
-  for (const mid of order) {
-    if (!visited.has(mid)) {
-      const cycle = hasCycle(mid, []);
-      if (cycle) {
-        const cycleStr = cycle.join(' → ');
-        violations.push({
-          milestone: cycle[0],
-          dependsOn: cycle[cycle.length - 2],
-          type: 'circular',
-          message: `Circular dependency: ${cycleStr}`,
-        });
-        break; // one cycle report is enough
-      }
-    }
-  }
-
-  return {
-    valid: violations.length === 0,
-    violations,
-    redundant,
-  };
-}