@haystackeditor/cli 0.8.1 → 0.10.0

package/dist/utils/pending-state.js

@@ -0,0 +1,86 @@
+/**
+ * Pending submit state persistence.
+ *
+ * Manages `.haystack/pending-submit.json` in the git root directory.
+ * This file persists across CLI sessions so that analysis results
+ * can be retrieved after disconnection.
+ */
+import { existsSync, mkdirSync, readFileSync, writeFileSync, unlinkSync } from 'fs';
+import { join } from 'path';
+import { findGitRoot } from './git.js';
+// ============================================================================
+// Constants
+// ============================================================================
+const PENDING_FILE = 'pending-submit.json';
+const HAYSTACK_DIR = '.haystack';
+const STALE_THRESHOLD_MS = 2 * 60 * 60 * 1000; // 2 hours
+// ============================================================================
+// Functions
+// ============================================================================
+function getPendingPath(gitRoot) {
+    const root = gitRoot || findGitRoot();
+    if (!root)
+        return null;
+    return join(root, HAYSTACK_DIR, PENDING_FILE);
+}
+/**
+ * Save pending submit state to disk.
+ */
+export function savePendingSubmit(state, gitRoot) {
+    const root = gitRoot || findGitRoot();
+    if (!root)
+        throw new Error('Not a git repository');
+    const dir = join(root, HAYSTACK_DIR);
+    if (!existsSync(dir)) {
+        mkdirSync(dir, { recursive: true });
+    }
+    const filePath = join(dir, PENDING_FILE);
+    writeFileSync(filePath, JSON.stringify(state, null, 2));
+}
+/**
+ * Load pending submit state from disk.
+ * Returns null if no pending state exists or if it's stale.
+ */
+export function loadPendingSubmit(gitRoot) {
+    const filePath = getPendingPath(gitRoot);
+    if (!filePath || !existsSync(filePath))
+        return null;
+    try {
+        const content = readFileSync(filePath, 'utf-8');
+        const state = JSON.parse(content);
+        // Check version
+        if (state.version !== 1)
+            return null;
+        // Auto-mark stale entries
+        if (state.status === 'polling') {
+            const age = Date.now() - new Date(state.submittedAt).getTime();
+            if (age > STALE_THRESHOLD_MS) {
+                state.status = 'stale';
+                savePendingSubmit(state, gitRoot);
+            }
+        }
+        return state;
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * Clear pending submit state (delete the file).
+ */
+export function clearPendingSubmit(gitRoot) {
+    const filePath = getPendingPath(gitRoot);
+    if (filePath && existsSync(filePath)) {
+        unlinkSync(filePath);
+    }
+}
+/**
+ * Update the status and optionally the analysis result of a pending submit.
+ */
+export function updatePendingSubmit(updates, gitRoot) {
+    const state = loadPendingSubmit(gitRoot);
+    if (!state)
+        return;
+    Object.assign(state, updates);
+    savePendingSubmit(state, gitRoot);
+}

package/dist/utils/secrets.js

@@ -18,7 +18,7 @@ const SECRET_PATTERNS = [
     // API Keys
     {
         name: 'generic-api-key',
-        pattern: /(?:api[_-]?key|apikey)\s*[:=]\s*['"]?([a-zA-Z0-9_\-]{20,})['"]?/gi,
+        pattern: /(?:api[_-]?key|apikey)\s*[:=]\s*['"]?([a-zA-Z0-9_-]{20,})['"]?/gi,
         description: 'Potential API key detected',
         severity: 'high',
     },
@@ -43,7 +43,7 @@ const SECRET_PATTERNS = [
     },
     {
         name: 'cloudflare-api-token',
-        pattern: /(?:cloudflare|cf)[_-]?(?:api)?[_-]?token\s*[:=]\s*['"]?([a-zA-Z0-9_\-]{40,})['"]?/gi,
+        pattern: /(?:cloudflare|cf)[_-]?(?:api)?[_-]?token\s*[:=]\s*['"]?([a-zA-Z0-9_-]{40,})['"]?/gi,
         description: 'Cloudflare API Token detected',
         severity: 'high',
     },
@@ -122,7 +122,7 @@ const SECRET_PATTERNS = [
     // Generic high-entropy strings in config values
     {
         name: 'high-entropy-string',
-        pattern: /(?:token|key|secret|password|credential|auth)\s*[:=]\s*['"]([a-zA-Z0-9+/=_\-]{32,})['"]?/gi,
+        pattern: /(?:token|key|secret|password|credential|auth)\s*[:=]\s*['"]([a-zA-Z0-9+/=_-]{32,})['"]?/gi,
         description: 'High-entropy string in sensitive field',
         severity: 'medium',
     },

package/dist/utils/skill.js

@@ -1380,12 +1380,266 @@ npx @haystackeditor/cli secrets get SECRET_NAME --show-metadata
 - For CI, use GitHub Secrets or organization-level Haystack secrets
 - Check \`npx @haystackeditor/cli secrets list --scope=org\`
 `;
+const SETUP_RULES_CONTENT = `# Set Up Review Policies & Rules
+
+**Your job**: Help the user configure two systems that control how Haystack evaluates their PRs:
+
+1. **Review Policies** — deterministic, path-based triggers that **always** require human review
+2. **PR Rules** — LLM-evaluated code invariants that **flag violations** in the diff
+
+These are distinct systems. Make sure the user understands the difference before proceeding.
+
+---
+
+## The Two Systems
+
+### Review Policies (\`.haystack/review-policy.md\`)
+
+**"If a PR touches X → human review needed, period."**
+
+Policies are simple glob patterns. When a PR changes files matching a policy's paths, Haystack will always recommend human review for that PR, regardless of what the code changes look like.
+
+**Good candidates for policies:**
+- Infrastructure (Terraform, Kubernetes, CI/CD pipelines)
+- Authentication and authorization code
+- Database migrations and schemas
+- API contracts (OpenAPI specs, GraphQL schemas, protobuf)
+- Security-sensitive code (crypto, secrets handling)
+- Billing/payment logic
+- Code that bypasses feature flags or launches directly to production
+
+**Format:**
+\`\`\`markdown
+## Policy name
+- **Paths**: \\\`glob/pattern/**\\\`, \\\`other/pattern/*.ts\\\`
+- **Severity**: critical | high | medium | low
+- **Reason**: Why this always needs human eyes
+\`\`\`
+
+### PR Rules (\`.haystack/pr-rules.yml\`)
+
+**"If this invariant is violated in the diff → flag it."**
+
+Rules are checked by an LLM that reads the PR diff and looks for violations. They catch patterns that shouldn't appear in new code, regardless of which files are touched.
+
+**Good candidates for rules:**
+- Error handling conventions (no silent catches, no swallowed errors)
+- Logging requirements (all API calls must be logged)
+- Security patterns (no hardcoded secrets, no SQL string concatenation)
+- Code style invariants (no TODOs without issue refs, no console.log in production)
+- Architecture boundaries (service A must not import from service B)
+- Naming conventions specific to your team
+
+**Format:**
+\`\`\`yaml
+- id: PR001
+  name: Short rule name
+  type: llm
+  severity: warning | error
+  message: Human-readable description of the violation
+  llm:
+    prompt: >
+      Detailed instructions for the LLM about what to look for
+      in the PR diff. Be specific about what counts as a violation
+      and what doesn't.
+    files: "optional/glob/pattern/**/*.ts"  # optional file scope
+\`\`\`
+
+---
+
+## Step 1: Explore the Codebase
+
+Before suggesting anything, understand the repo structure:
+
+\`\`\`bash
+# Understand repo layout
+ls -la
+find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' | head -40
+
+# Find infrastructure files
+find . -name "*.tf" -o -name "Dockerfile*" -o -name "docker-compose*" -o -name "*.yml" -path "*/.github/*" | head -20
+
+# Find auth-related code
+grep -rl "auth\\|login\\|session\\|token\\|credential" --include="*.ts" --include="*.py" --include="*.go" --include="*.js" -l | grep -v node_modules | head -20
+
+# Find database/migration files
+find . -path "*/migration*" -o -path "*/schema*" -o -name "*.sql" | grep -v node_modules | head -20
+
+# Find API contract files
+find . -name "*.proto" -o -name "openapi*" -o -name "swagger*" -o -name "*.graphql" | head -20
+
+# Find feature flag patterns
+grep -rl "feature.?flag\\|feature.?toggle\\|isEnabled\\|FEATURE_" --include="*.ts" --include="*.py" --include="*.go" --include="*.js" -l | grep -v node_modules | head -20
+
+# Check for existing config
+cat .haystack/review-policy.md 2>/dev/null || echo "No review-policy.md yet"
+cat .haystack/pr-rules.yml 2>/dev/null || echo "No pr-rules.yml yet"
+\`\`\`
+
+Also look for:
+- CI/CD pipeline files
+- Payment or billing directories
+- Secrets or credential management code
+- Environment configuration patterns
+- Key shared libraries or core utilities that many things depend on
+
+---
+
+## STOP — Propose Review Policies
+
+Present your findings to the user. Be specific about what you found and why each area warrants a policy.
+
+**Format your proposal like this:**
+
+> Based on the codebase, here are the areas I'd recommend always requiring human review:
+>
+> | # | Policy | Paths | Severity | Why |
+> |---|--------|-------|----------|-----|
+> | 1 | Infrastructure | \\\`terraform/**\\\`, \\\`*.tf\\\` | high | Cost and security implications |
+> | 2 | Auth & secrets | \\\`src/auth/**\\\`, \\\`**/*.secret*\\\` | critical | Security-sensitive |
+> | 3 | ... | ... | ... | ... |
+>
+> **Notes:**
+> - I didn't find any database migrations in this repo, so I'm not including that
+> - The \`src/core/\` directory is imported by everything — should changes there always need review?
+>
+> Which of these should I include? Any to add, remove, or modify?
+
+**Wait for the user to confirm before writing anything.**
+
+---
+
+## Step 2: Write review-policy.md
+
+Once the user confirms, write the policies to \`.haystack/review-policy.md\`:
+
+\`\`\`markdown
+# Review Policies
+
+Review policies define file patterns that always require human attention. When a PR touches files matching these patterns, Haystack will flag it for human review.
+
+## [Policy name]
+- **Paths**: \\\`pattern/**\\\`
+- **Severity**: [level]
+- **Reason**: [why]
+\`\`\`
+
+Create the \`.haystack/\` directory if it doesn't exist.
+
+---
+
+## Step 3: Understand Team Conventions
+
+Now shift to rules. Ask the user about their code quality invariants:
+
+> Now let's set up **PR rules** — these are code invariants that Haystack checks in every diff.
+>
+> Unlike policies (which trigger on file paths), rules look at *what the code does*. For example:
+> - "Don't add empty catch blocks"
+> - "Don't add TODOs without issue references"
+> - "Don't hardcode API URLs"
+>
+> **What conventions does your team care about?** Some common categories:
+>
+> 1. **Error handling** — e.g., no swallowed errors, no silent fallbacks
+> 2. **Security** — e.g., no hardcoded secrets, no raw SQL strings
+> 3. **Logging** — e.g., all API calls must have logging
+> 4. **Code hygiene** — e.g., no TODOs without issues, no console.log in production
+> 5. **Architecture** — e.g., no cross-service imports, no direct DB access from UI layer
+> 6. **Testing** — e.g., no skipped tests without reason, no snapshot-only tests
+>
+> Tell me which categories matter to your team, or describe your own conventions.
+
+Also explore the codebase for clues:
+
+\`\`\`bash
+# Check for linter configs (reveals team conventions)
+cat .eslintrc* .eslintrc.json .eslintrc.js eslint.config.* 2>/dev/null | head -50
+
+# Check for existing code review guidelines
+find . -name "CONTRIBUTING*" -o -name "REVIEW*" -o -name "STYLE*" | head -5
+
+# Look for common anti-patterns
+grep -rn "catch.*{\\s*}" --include="*.ts" --include="*.js" | head -5
+grep -rn "console\\.log" --include="*.ts" --include="*.tsx" | grep -v test | head -5
+grep -rn "TODO\\|FIXME\\|HACK\\|XXX" --include="*.ts" --include="*.tsx" | head -10
+\`\`\`
+
+---
+
+## STOP — Propose PR Rules
+
+Based on the user's input and your codebase exploration, propose 2-5 custom rules.
+
+**Format your proposal like this:**
+
+> Here are the PR rules I'd suggest:
+>
+> **1. PR001 — No silent error handling** (warning)
+> > Flag: Adding catch blocks that swallow errors without logging or re-throwing
+>
+> **2. PR002 — No TODOs without tracking issues** (warning)
+> > Flag: Adding TODO/FIXME comments without referencing an issue number
+>
+> **3. PR003 — No hardcoded API endpoints** (warning)
+> > Flag: Adding hardcoded URLs or API endpoints instead of using config/env vars
+>
+> Should I add, remove, or modify any of these?
+
+**Wait for the user to confirm before writing.**
+
+---
+
+## Step 4: Write pr-rules.yml
+
+Once confirmed, write to \`.haystack/pr-rules.yml\`:
+
+\`\`\`yaml
+version: 1
+
+rules:
+  - id: PR001
+    name: [Short name]
+    type: llm
+    severity: warning
+    message: [Human-readable description]
+    llm:
+      prompt: >
+        [Detailed LLM instructions — be specific about what counts as
+        a violation and what doesn't. Include examples of violations
+        and non-violations when helpful.]
+\`\`\`
+
+**Tips for writing good rule prompts:**
+- Be specific about what counts as a violation
+- Mention common false positives to ignore (e.g., "test files are exempt")
+- Use the \`files\` field to scope rules to relevant file types
+- \`severity: error\` caps the Haystack rating at 3 (needs review); \`warning\` is advisory
+
+---
+
+## Step 5: Commit
+
+\`\`\`bash
+git add .haystack/review-policy.md .haystack/pr-rules.yml
+git commit -m "Add Haystack review policies and PR rules"
+\`\`\`
+
+Done! Haystack will now:
+- Flag PRs touching policy-matched files for human review
+- Check every PR diff against your custom rules and report violations
+`;
+const SETUP_RULES_COMMAND = `# Set Up Rules
+
+Follow .agents/skills/setup-haystack-rules.md to configure review policies (what always needs human review) and PR rules (what code invariants to enforce).
+`;
 export async function createSkillFile() {
     const skillDir = path.join(process.cwd(), '.agents', 'skills');
     const setupPath = path.join(skillDir, 'setup-haystack.md');
     const refPath = path.join(skillDir, 'haystack-reference.md');
     const prepPath = path.join(skillDir, 'prepare-haystack.md');
     const secretsPath = path.join(skillDir, 'setup-haystack-secrets.md');
+    const rulesPath = path.join(skillDir, 'setup-haystack-rules.md');
     // Create directory if needed
     await fs.mkdir(skillDir, { recursive: true });
     // Write all skill files
@@ -1393,6 +1647,7 @@ export async function createSkillFile() {
     await fs.writeFile(refPath, REFERENCE_CONTENT, 'utf-8');
     await fs.writeFile(prepPath, PREPARE_VERIFICATION_CONTENT, 'utf-8');
     await fs.writeFile(secretsPath, SECRETS_SKILL_CONTENT, 'utf-8');
+    await fs.writeFile(rulesPath, SETUP_RULES_CONTENT, 'utf-8');
     return setupPath;
 }
 /**
@@ -1404,11 +1659,13 @@ export async function createClaudeCommand() {
     const setupPath = path.join(commandDir, 'setup-haystack.md');
     const prepPath = path.join(commandDir, 'prepare-haystack.md');
     const secretsPath = path.join(commandDir, 'setup-haystack-secrets.md');
+    const rulesPath = path.join(commandDir, 'setup-haystack-rules.md');
     // Create directory if needed
     await fs.mkdir(commandDir, { recursive: true });
     // Write command files
     await fs.writeFile(setupPath, CLAUDE_COMMAND_CONTENT, 'utf-8');
     await fs.writeFile(prepPath, PREPARE_HAYSTACK_COMMAND, 'utf-8');
     await fs.writeFile(secretsPath, SECRETS_COMMAND_CONTENT, 'utf-8');
+    await fs.writeFile(rulesPath, SETUP_RULES_COMMAND, 'utf-8');
     return setupPath;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haystackeditor/cli",
-  "version": "0.8.1",
+  "version": "0.10.0",
   "description": "Set up Haystack verification for your project",
   "type": "module",
   "bin": {
@@ -32,16 +32,18 @@
     "url": "https://github.com/haystackeditor/haystack-review/issues"
   },
   "dependencies": {
-    "chalk": "^5.3.0",
-    "commander": "^12.0.0",
-    "fast-glob": "^3.3.0",
-    "inquirer": "^9.2.0",
-    "yaml": "^2.3.4"
+    "chalk": "5.6.2",
+    "commander": "12.1.0",
+    "fast-glob": "3.3.3",
+    "glob": "10.5.0",
+    "inquirer": "9.3.8",
+    "yaml": "2.8.2",
+    "zod": "3.25.76"
   },
   "devDependencies": {
-    "@types/inquirer": "^9.0.0",
-    "@types/node": "^20.10.0",
-    "typescript": "^5.3.0"
+    "@types/inquirer": "9.0.9",
+    "@types/node": "20.19.30",
+    "typescript": "5.9.3"
   },
   "files": [
     "dist"