aiwcli 0.12.7 → 0.12.8

package/dist/templates/cc-native/_cc-native/{lib-ts → plan-review/lib}/reviewers/schemas.ts

@@ -1,201 +1,201 @@
-/**
- * JSON schemas and prompt constants for plan reviewers.
- * Centralized schema definitions used by Claude/Codex/Gemini agents and orchestrator.
- * See cc-native-plan-review-spec.md §4.10
- */
-
-// ---------------------------------------------------------------------------
-// Prompt Constants
-// ---------------------------------------------------------------------------
-
-/** Prefix for agent review prompts (embedded in stdin or --system-prompt) */
-export const AGENT_REVIEW_PROMPT_PREFIX = `# SINGLE-TURN PLAN REVIEW
-
-## CRITICAL: ONE TURN ONLY
-You have exactly ONE response to complete this review. Do NOT attempt multi-step workflows, context queries, or phased analysis. Analyze the plan and output your review immediately.
-
-## YOUR TASK
-Review the plan below from your area of expertise. Then call StructuredOutput with your assessment.
-
-## REQUIRED OUTPUT (all fields must have content)
-Call StructuredOutput with:
-- **verdict**: "pass" (no concerns), "warn" (some concerns), or "fail" (critical issues)
-- **summary**: 2-3 sentences with your overall assessment and key findings (REQUIRED)
-- **issues**: Array of concerns found. Format each as:
-  {"severity": "high/medium/low", "category": "...", "issue": "...", "suggested_fix": "...", "dimension": "..."}
-- **dimension**: Classify each issue into exactly one dimension:
-  completeness, simplicity, security, performance, reliability,
-  maintainability, testability, scope, feasibility, or clarity.
-  Examples: "missing error handling" → reliability, "excessive abstraction" → simplicity,
-  "no test strategy" → testability, "missing deployment steps" → completeness,
-  "unclear interaction between components" → clarity.
-- **missing_sections**: Topics the plan should address but doesn't
-- **questions**: Things that need clarification before implementation
-
-## IMPORTANT RULES
-1. A "warn" verdict MUST include at least one issue explaining why
-2. Summary MUST explain your reasoning, not just "looks good" or empty
-3. Focus on your expertise area (architecture, security, performance, etc.)
-4. Output StructuredOutput NOW - no other tools, no questions, no delays
-5. Return ONLY your top 3 most critical issues. Prioritize high-severity over medium/low. Quality over quantity.
-`;
-
-/** Prefix for Codex/Gemini review prompts (legacy, may be deprecated) */
-export const REVIEW_PROMPT_PREFIX = `You are a senior staff software engineer acting as a strict plan reviewer.
-
-Review the PLAN below. Focus on:
-- missing steps, unclear assumptions, edge cases
-- security/privacy concerns
-- testing/rollout/rollback completeness
-- operational concerns (observability, failure modes)
-`;
-
-// ---------------------------------------------------------------------------
-// JSON Schemas
-// ---------------------------------------------------------------------------
-
-/** JSON schema for review structured output (agents: Claude, Codex, Gemini) */
-export const REVIEW_SCHEMA: Record<string, unknown> = {
-  type: "object",
-  properties: {
-    verdict: { type: "string", enum: ["pass", "warn", "fail"] },
-    summary: { type: "string", minLength: 20 },
-    issues: {
-      type: "array",
-      items: {
-        type: "object",
-        properties: {
-          severity: { type: "string", enum: ["high", "medium", "low"] },
-          category: { type: "string" },
-          issue: { type: "string" },
-          suggested_fix: { type: "string" },
-          dimension: {
-            type: "string",
-            enum: [
-              "completeness", "simplicity", "security", "performance",
-              "reliability", "maintainability", "testability", "scope",
-              "feasibility", "clarity",
-            ],
-          },
-        },
-        required: ["severity", "category", "issue", "suggested_fix", "dimension"],
-        additionalProperties: false,
-      },
-    },
-    missing_sections: { type: "array", items: { type: "string" } },
-    questions: { type: "array", items: { type: "string" } },
-  },
-  required: ["verdict", "summary", "issues", "missing_sections", "questions"],
-  additionalProperties: false,
-};
-
-/**
- * Build orchestrator JSON schema with enum-constrained agent names.
- * Dynamic schema that restricts selectedAgents to valid agent names.
- */
-export function buildOrchestratorSchema(
-  validAgentNames: string[],
-  categories: string[],
-): Record<string, unknown> {
-  const itemsSchema: Record<string, unknown> = { type: "string" };
-  if (validAgentNames.length > 0) {
-    itemsSchema.enum = validAgentNames;
-  }
-
-  return {
-    type: "object",
-    properties: {
-      complexity: { type: "string", enum: ["simple", "medium", "high"] },
-      category: { type: "string", enum: categories },
-      selectedAgents: {
-        type: "array",
-        items: itemsSchema,
-      },
-      reasoning: { type: "string" },
-      skipReason: { type: "string" },
-    },
-    required: ["complexity", "category", "selectedAgents", "reasoning"],
-    additionalProperties: false,
-  };
-}
-
-// ---------------------------------------------------------------------------
-// Plan Questions Schema
-// ---------------------------------------------------------------------------
-
-/** Prefix for plan question generation prompts */
-export const QUESTIONS_PROMPT_PREFIX = `# PLAN QUESTION GENERATION
-
-## CRITICAL: ONE TURN ONLY
-You have exactly ONE response. Do NOT attempt multi-step workflows or tool use beyond StructuredOutput.
-
-## YOUR TASK
-You are reviewing a plan that was written by another agent. You have NO access to the codebase, NO session history, and NO exploration context. You see ONLY the plan text.
-
-This is intentional. Plans must be executable by a fresh agent in a new session. If the plan assumes knowledge that isn't written down, that's a gap.
-
-## WHAT TO LOOK FOR
-- Questions the plan doesn't answer but should
-- Assumptions the plan makes without stating them
-- Ambiguities where a reader could interpret something two ways
-- Missing context that would be obvious to the author but not a new reader
-
-## IMPORTANT
-- Focus on questions that would change the implementation approach if answered differently
-- Don't ask about things clearly stated in the plan
-- Don't generate generic questions — every question should be specific to THIS plan
-- Aim for 3-6 high-value questions
-`;
-
-/** JSON schema for plan question generation output */
-export const QUESTIONS_SCHEMA: Record<string, unknown> = {
-  type: "object",
-  properties: {
-    questions: {
-      type: "array",
-      items: { type: "string" },
-      description: "Questions the user should answer before this plan is implemented",
-    },
-    assumptions: {
-      type: "array",
-      items: { type: "string" },
-      description: "Assumptions the plan makes that are not explicitly stated",
-    },
-    ambiguities: {
-      type: "array",
-      items: { type: "string" },
-      description: "Parts of the plan that could be interpreted multiple ways",
-    },
-  },
-  required: ["questions", "assumptions", "ambiguities"],
-  additionalProperties: false,
-};
-
-// ---------------------------------------------------------------------------
-// Orchestrator Schemas
-// ---------------------------------------------------------------------------
-
-/** JSON schema for orchestrator structured output (static fallback) */
-export const ORCHESTRATOR_SCHEMA: Record<string, unknown> = {
-  type: "object",
-  properties: {
-    complexity: { type: "string", enum: ["simple", "medium", "high"] },
-    category: {
-      type: "string",
-      enum: [
-        "code",
-        "infrastructure",
-        "documentation",
-        "life",
-        "business",
-        "design",
-        "research",
-      ],
-    },
-    selectedAgents: { type: "array", items: { type: "string" } },
-    reasoning: { type: "string" },
-    skipReason: { type: "string" },
-  },
-  required: ["complexity", "category", "selectedAgents", "reasoning"],
-  additionalProperties: false,
-};
+/**
+ * JSON schemas and prompt constants for plan reviewers.
+ * Centralized schema definitions used by Claude/Codex/Gemini agents and orchestrator.
+ * See cc-native-plan-review-spec.md §4.10
+ */
+
+// ---------------------------------------------------------------------------
+// Prompt Constants
+// ---------------------------------------------------------------------------
+
+/** Prefix for agent review prompts (embedded in stdin or --system-prompt) */
+export const AGENT_REVIEW_PROMPT_PREFIX = `# SINGLE-TURN PLAN REVIEW
+
+## CRITICAL: ONE TURN ONLY
+You have exactly ONE response to complete this review. Do NOT attempt multi-step workflows, context queries, or phased analysis. Analyze the plan and output your review immediately.
+
+## YOUR TASK
+Review the plan below from your area of expertise. Then call StructuredOutput with your assessment.
+
+## REQUIRED OUTPUT (all fields must have content)
+Call StructuredOutput with:
+- **verdict**: "pass" (no concerns), "warn" (some concerns), or "fail" (critical issues)
+- **summary**: 2-3 sentences with your overall assessment and key findings (REQUIRED)
+- **issues**: Array of concerns found. Format each as:
+  {"severity": "high/medium/low", "category": "...", "issue": "...", "suggested_fix": "...", "dimension": "..."}
+- **dimension**: Classify each issue into exactly one dimension:
+  completeness, simplicity, security, performance, reliability,
+  maintainability, testability, scope, feasibility, or clarity.
+  Examples: "missing error handling" → reliability, "excessive abstraction" → simplicity,
+  "no test strategy" → testability, "missing deployment steps" → completeness,
+  "unclear interaction between components" → clarity.
+- **missing_sections**: Topics the plan should address but doesn't
+- **questions**: Things that need clarification before implementation
+
+## IMPORTANT RULES
+1. A "warn" verdict MUST include at least one issue explaining why
+2. Summary MUST explain your reasoning, not just "looks good" or empty
+3. Focus on your expertise area (architecture, security, performance, etc.)
+4. Output StructuredOutput NOW - no other tools, no questions, no delays
+5. Return ONLY your top 3 most critical issues. Prioritize high-severity over medium/low. Quality over quantity.
+`;
+
+/** Prefix for Codex/Gemini review prompts (legacy, may be deprecated) */
+export const REVIEW_PROMPT_PREFIX = `You are a senior staff software engineer acting as a strict plan reviewer.
+
+Review the PLAN below. Focus on:
+- missing steps, unclear assumptions, edge cases
+- security/privacy concerns
+- testing/rollout/rollback completeness
+- operational concerns (observability, failure modes)
+`;
+
+// ---------------------------------------------------------------------------
+// JSON Schemas
+// ---------------------------------------------------------------------------
+
+/** JSON schema for review structured output (agents: Claude, Codex, Gemini) */
+export const REVIEW_SCHEMA: Record<string, unknown> = {
+  type: "object",
+  properties: {
+    verdict: { type: "string", enum: ["pass", "warn", "fail"] },
+    summary: { type: "string", minLength: 20 },
+    issues: {
+      type: "array",
+      items: {
+        type: "object",
+        properties: {
+          severity: { type: "string", enum: ["high", "medium", "low"] },
+          category: { type: "string" },
+          issue: { type: "string" },
+          suggested_fix: { type: "string" },
+          dimension: {
+            type: "string",
+            enum: [
+              "completeness", "simplicity", "security", "performance",
+              "reliability", "maintainability", "testability", "scope",
+              "feasibility", "clarity",
+            ],
+          },
+        },
+        required: ["severity", "category", "issue", "suggested_fix", "dimension"],
+        additionalProperties: false,
+      },
+    },
+    missing_sections: { type: "array", items: { type: "string" } },
+    questions: { type: "array", items: { type: "string" } },
+  },
+  required: ["verdict", "summary", "issues", "missing_sections", "questions"],
+  additionalProperties: false,
+};
+
+/**
+ * Build orchestrator JSON schema with enum-constrained agent names.
+ * Dynamic schema that restricts selectedAgents to valid agent names.
+ */
+export function buildOrchestratorSchema(
+  validAgentNames: string[],
+  categories: string[],
+): Record<string, unknown> {
+  const itemsSchema: Record<string, unknown> = { type: "string" };
+  if (validAgentNames.length > 0) {
+    itemsSchema.enum = validAgentNames;
+  }
+
+  return {
+    type: "object",
+    properties: {
+      complexity: { type: "string", enum: ["simple", "medium", "high"] },
+      category: { type: "string", enum: categories },
+      selectedAgents: {
+        type: "array",
+        items: itemsSchema,
+      },
+      reasoning: { type: "string" },
+      skipReason: { type: "string" },
+    },
+    required: ["complexity", "category", "selectedAgents", "reasoning"],
+    additionalProperties: false,
+  };
+}
+
+// ---------------------------------------------------------------------------
+// Plan Questions Schema
+// ---------------------------------------------------------------------------
+
+/** Prefix for plan question generation prompts */
+export const QUESTIONS_PROMPT_PREFIX = `# PLAN QUESTION GENERATION
+
+## CRITICAL: ONE TURN ONLY
+You have exactly ONE response. Do NOT attempt multi-step workflows or tool use beyond StructuredOutput.
+
+## YOUR TASK
+You are reviewing a plan that was written by another agent. You have NO access to the codebase, NO session history, and NO exploration context. You see ONLY the plan text.
+
+This is intentional. Plans must be executable by a fresh agent in a new session. If the plan assumes knowledge that isn't written down, that's a gap.
+
+## WHAT TO LOOK FOR
+- Questions the plan doesn't answer but should
+- Assumptions the plan makes without stating them
+- Ambiguities where a reader could interpret something two ways
+- Missing context that would be obvious to the author but not a new reader
+
+## IMPORTANT
+- Focus on questions that would change the implementation approach if answered differently
+- Don't ask about things clearly stated in the plan
+- Don't generate generic questions — every question should be specific to THIS plan
+- Aim for 3-6 high-value questions
+`;
+
+/** JSON schema for plan question generation output */
+export const QUESTIONS_SCHEMA: Record<string, unknown> = {
+  type: "object",
+  properties: {
+    questions: {
+      type: "array",
+      items: { type: "string" },
+      description: "Questions the user should answer before this plan is implemented",
+    },
+    assumptions: {
+      type: "array",
+      items: { type: "string" },
+      description: "Assumptions the plan makes that are not explicitly stated",
+    },
+    ambiguities: {
+      type: "array",
+      items: { type: "string" },
+      description: "Parts of the plan that could be interpreted multiple ways",
+    },
+  },
+  required: ["questions", "assumptions", "ambiguities"],
+  additionalProperties: false,
+};
+
+// ---------------------------------------------------------------------------
+// Orchestrator Schemas
+// ---------------------------------------------------------------------------
+
+/** JSON schema for orchestrator structured output (static fallback) */
+export const ORCHESTRATOR_SCHEMA: Record<string, unknown> = {
+  type: "object",
+  properties: {
+    complexity: { type: "string", enum: ["simple", "medium", "high"] },
+    category: {
+      type: "string",
+      enum: [
+        "code",
+        "infrastructure",
+        "documentation",
+        "life",
+        "business",
+        "design",
+        "research",
+      ],
+    },
+    selectedAgents: { type: "array", items: { type: "string" } },
+    reasoning: { type: "string" },
+    skipReason: { type: "string" },
+  },
+  required: ["complexity", "category", "selectedAgents", "reasoning"],
+  additionalProperties: false,
+};

package/dist/templates/cc-native/_cc-native/{lib-ts → plan-review/lib}/reviewers/types.ts

@@ -1,23 +1,23 @@
-/**
- * Reviewer interface and options for plan review implementations.
- * See cc-native-plan-review-spec.md §4.9
- */
-
-import type { ReviewerResult,   Verdict, ReviewData } from "../types.js";
-
-// Re-export for convenience
-
-
-/** Create a standard ReviewerResult. Shared by all reviewer implementations. */
-export function makeResult(
-  name: string,
-  ok: boolean,
-  verdict: Verdict,
-  data: ReviewData | Record<string, unknown>,
-  raw: string,
-  err: string,
-): ReviewerResult {
-  return { name, ok, verdict, data: data as Record<string, unknown>, raw, err };
-}
-
-export {type Reviewer, type ReviewerResult, type ReviewOptions} from "../types.js";
+/**
+ * Reviewer interface and options for plan review implementations.
+ * See cc-native-plan-review-spec.md §4.9
+ */
+
+import type { ReviewerResult,   Verdict, ReviewData } from "../../../lib-ts/types.js";
+
+// Re-export for convenience
+
+
+/** Create a standard ReviewerResult. Shared by all reviewer implementations. */
+export function makeResult(
+  name: string,
+  ok: boolean,
+  verdict: Verdict,
+  data: ReviewData | Record<string, unknown>,
+  raw: string,
+  err: string,
+): ReviewerResult {
+  return { name, ok, verdict, data: data as Record<string, unknown>, raw, err };
+}
+
+export {type Reviewer, type ReviewerResult, type ReviewOptions} from "../../../lib-ts/types.js";

package/dist/templates/cc-native/_cc-native/{lib-ts → plan-review/lib}/verdict.ts

@@ -1,72 +1,72 @@
-/**
- * Pure verdict aggregation logic.
- * See cc-native-plan-review-spec.md §4.2
- */
-
-import type { ReviewDecisionResult, Verdict } from "./types.js";
-
-/**
- * Return the worst verdict from a list.
- * Order: pass < warn < fail. skip→pass, error→warn.
- */
-export function worstVerdict(verdicts: Verdict[]): Verdict {
-  const order: Record<Verdict, number> = {
-    pass: 0,
-    warn: 1,
-    fail: 2,
-    skip: 0,
-    error: 1,
-  };
-
-  let worst: Verdict = "pass";
-  for (const v of verdicts) {
-    if ((order[v] ?? 1) > (order[worst] ?? 0)) {
-      worst = v;
-    }
-  }
-
-  // Normalize error → warn
-  if (worst === "error") return "warn";
-  return worst;
-}
-
-/**
- * Verdict aggregation: fail veto triggers a block.
- *
- * Priority order:
- * 1. Fail Veto: Any fail → deny (ISO 61508 zero-tolerance)
- * 2. Acceptable: warns are informational only
- *
- * Error exclusion: Detectors that produce no signal (error/skip) are excluded
- * from the denominator.
- *
- * @param allVerdicts - List of verdict strings from all reviewers
- * @returns ReviewDecisionResult with should_deny, reason, and score
- */
-export function computeReviewDecision(
-  allVerdicts: Verdict[],
-): ReviewDecisionResult {
-  // Exclude non-signal verdicts
-  const signalVerdicts = allVerdicts.filter(
-    (v) => v === "pass" || v === "warn" || v === "fail",
-  );
-
-  if (signalVerdicts.length === 0) {
-    return { should_deny: false, reason: "no_signal", score: 0 };
-  }
-
-  // Fail blocks unconditionally
-  const failCount = signalVerdicts.filter((v) => v === "fail").length;
-  if (failCount > 0) {
-    return { should_deny: true, reason: "fail_veto", score: 1 };
-  }
-
-  // Warn also blocks — reviewers flagged concerns worth addressing
-  const warnCount = signalVerdicts.filter((v) => v === "warn").length;
-  const warnRatio = warnCount / signalVerdicts.length;
-  if (warnCount > 0) {
-    return { should_deny: true, reason: "warn_block", score: warnRatio };
-  }
-
-  return { should_deny: false, reason: "acceptable", score: 0 };
-}
+/**
+ * Pure verdict aggregation logic.
+ * See cc-native-plan-review-spec.md §4.2
+ */
+
+import type { ReviewDecisionResult, Verdict } from "../../lib-ts/types.js";
+
+/**
+ * Return the worst verdict from a list.
+ * Order: pass < warn < fail. skip→pass, error→warn.
+ */
+export function worstVerdict(verdicts: Verdict[]): Verdict {
+  const order: Record<Verdict, number> = {
+    pass: 0,
+    warn: 1,
+    fail: 2,
+    skip: 0,
+    error: 1,
+  };
+
+  let worst: Verdict = "pass";
+  for (const v of verdicts) {
+    if ((order[v] ?? 1) > (order[worst] ?? 0)) {
+      worst = v;
+    }
+  }
+
+  // Normalize error → warn
+  if (worst === "error") return "warn";
+  return worst;
+}
+
+/**
+ * Verdict aggregation: fail veto triggers a block.
+ *
+ * Priority order:
+ * 1. Fail Veto: Any fail → deny (ISO 61508 zero-tolerance)
+ * 2. Acceptable: warns are informational only
+ *
+ * Error exclusion: Detectors that produce no signal (error/skip) are excluded
+ * from the denominator.
+ *
+ * @param allVerdicts - List of verdict strings from all reviewers
+ * @returns ReviewDecisionResult with should_deny, reason, and score
+ */
+export function computeReviewDecision(
+  allVerdicts: Verdict[],
+): ReviewDecisionResult {
+  // Exclude non-signal verdicts
+  const signalVerdicts = allVerdicts.filter(
+    (v) => v === "pass" || v === "warn" || v === "fail",
+  );
+
+  if (signalVerdicts.length === 0) {
+    return { should_deny: false, reason: "no_signal", score: 0 };
+  }
+
+  // Fail blocks unconditionally
+  const failCount = signalVerdicts.filter((v) => v === "fail").length;
+  if (failCount > 0) {
+    return { should_deny: true, reason: "fail_veto", score: 1 };
+  }
+
+  // Warn also blocks — reviewers flagged concerns worth addressing
+  const warnCount = signalVerdicts.filter((v) => v === "warn").length;
+  const warnRatio = warnCount / signalVerdicts.length;
+  if (warnCount > 0) {
+    return { should_deny: true, reason: "warn_block", score: warnRatio };
+  }
+
+  return { should_deny: false, reason: "acceptable", score: 0 };
+}

package/dist/templates/cc-native/_cc-native/{workflows → plan-review/workflows}/specdev.md

@@ -1,9 +1,9 @@
-Read this spec and interview me in detail using the AskUserQuestionTool about literally anything: 
-- Technical implementation
-- UI & UX
-- Concerns
-- Tradeoffs, etc. 
-
-But make sure the questions are not obvious
-
-Be very in-depth and continue interviewing me continually until it's complete, then write the spec to the file.
+Read this spec and interview me in detail using the AskUserQuestionTool about literally anything: 
+- Technical implementation
+- UI & UX
+- Concerns
+- Tradeoffs, etc. 
+
+But make sure the questions are not obvious
+
+Be very in-depth and continue interviewing me continually until it's complete, then write the spec to the file.

package/oclif.manifest.json

@@ -416,5 +416,5 @@
       ]
     }
   },
-  "version": "0.12.7"
+  "version": "0.12.8"
 }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "aiwcli",
   "description": "AI Workflow CLI - Command-line interface for AI-powered workflows",
-  "version": "0.12.7",
+  "version": "0.12.8",
   "author": "jofu-tofu",
   "bin": {
     "aiw": "bin/run.js"

package/dist/templates/cc-native/_cc-native/lib-ts/artifacts.ts

@@ -1,21 +0,0 @@
-/**
- * Review artifact writing and formatting.
- * Re-exports from artifacts/ subdirectory for backward compatibility.
- */
-
-export {
-  formatReviewMarkdown,
-  formatCombinedMarkdown,
-  buildInlineReviewSummary,
-  extractTopIssuesText,
-  buildHighIssuesDocument,
-  buildCorroborationReport,
-  generateReviewIndex,
-  buildCombinedJson,
-  writeCombinedArtifacts,
-  writeFile,
-  writeFileNonCritical,
-  writeReviewTracker,
-  extractPreviousHashes,
-} from "./artifacts/index.js";
-export type { ReviewTrackerEntry } from "./artifacts/index.js";