all-hands-cli 0.1.8 → 0.1.10

package/.allhands/flows/shared/EXTERNAL_TECH_GUIDANCE.md

@@ -37,42 +37,26 @@ For proprietary domains with documentation pages:
 - Extract API patterns, configuration examples
 - Note version-specific behaviors
 
-### Open Source Inspiration (Clone & Browse)
-
-For exploring GitHub repositories locally:
-
-1. **Search for repositories**:
-   ```bash
-   gh search repos "<query>" --limit 5
-   ```
-
-2. **Clone to local research folder**:
-   ```bash
-   # Clone into .reposearch folder (gitignored)
-   mkdir -p .reposearch
-   git clone --depth 1 <repo-url> .reposearch/<repo-name>
-   ```
-
-   Note: Ensure `.reposearch/` is in the project's `.gitignore`.
-
-3. **Browse locally with standard tooling**:
-   - Use `Glob` to find files by pattern
-   - Use `Grep` to search code content
-   - Use `Read` to examine specific files
-   - Use `ls` to explore directory structure
-
-4. **Clean up when done** (optional):
-   ```bash
-   rm -rf .reposearch/<repo-name>
-   ```
-
-This approach leverages the agent's superior local file navigation capabilities:
-- Full regex search across the codebase
-- Fast pattern matching and file discovery
-- Direct file reading without API encoding issues
-- Study implementation patterns in similar projects
-- Extract architectural decisions
-- Note how libraries handle similar problems
+### Open Source Inspiration (`ah spawn reposearch`)
+
+Use `ah spawn reposearch` to clone external GitHub repos and delegate research to an AI agent that searches across both the current project and external codebases.
+
+**OSS codebase answers** — ask how a specific project handles something:
+```bash
+ah spawn reposearch "How does this project handle authentication?" --repos https://github.com/org/project
+```
+
+**Cross-repo comparison** — compare our implementation vs an external project:
+```bash
+ah spawn reposearch "Compare our error handling approach vs theirs" --repos https://github.com/org/project
+```
+
+**Multi-framework comparison** — check out 2+ repos, compare approaches side-by-side:
+```bash
+ah spawn reposearch "How do these projects handle routing?" --repos https://github.com/a/repo,https://github.com/b/repo
+```
+
+Re-running the same command with the same repos is fast — repos are cached locally between invocations.
 
 ### Parallel Exploration
 

package/.allhands/harness/src/commands/spawn.ts

@@ -3,13 +3,15 @@
  *
  * Commands:
  *   ah spawn codesearch "<query>" [--budget <n>] [--steps <n>]
+ *   ah spawn reposearch "<query>" --repos <url1,url2,...> [--steps <n>]
  */
 
 import { Command } from "commander";
-import { readFileSync } from "fs";
-import { dirname, join } from "path";
+import { existsSync, mkdirSync, readFileSync } from "fs";
+import { dirname, join, basename } from "path";
 import { fileURLToPath } from "url";
-import { AgentRunner, withDebugInfo } from "../lib/opencode/index.js";
+import { execFileSync } from "child_process";
+import { AgentRunner, withDebugInfo, type ReposearchOutput } from "../lib/opencode/index.js";
 import { BaseCommand, type CommandResult } from "../lib/base-command.js";
 import { loadProjectSettings } from "../hooks/shared.js";
 
@@ -19,15 +21,23 @@ const getProjectRoot = (): string => {
   return process.env.PROJECT_ROOT || process.cwd();
 };
 
-// Load prompt
+// Load prompts
 const CODESEARCH_PROMPT_PATH = join(__dirname, "../lib/opencode/prompts/codesearch.md");
 const getCodesearchPrompt = (): string => readFileSync(CODESEARCH_PROMPT_PATH, "utf-8");
 
-// Defaults
+const REPOSEARCH_PROMPT_PATH = join(__dirname, "../lib/opencode/prompts/reposearch.md");
+const getReposearchPrompt = (): string => readFileSync(REPOSEARCH_PROMPT_PATH, "utf-8");
+
+// Codesearch defaults
 const DEFAULT_TOOL_BUDGET = 12;
 const DEFAULT_STEPS_LIMIT = 20;
 const DEFAULT_TIMEOUT_MS = 120000; // 2 min
 
+// Reposearch defaults
+const DEFAULT_REPOSEARCH_STEPS = 30;
+const DEFAULT_REPOSEARCH_TIMEOUT_MS = 180000; // 3 min
+const DEFAULT_REPOSEARCH_TOOL_BUDGET = 20;
+
 // Output types
 interface CodeResult {
   file: string;
@@ -125,6 +135,165 @@ Respond with JSON matching the required schema.`;
   }
 }
 
+/**
+ * Derive a directory name from a GitHub URL.
+ * e.g. "https://github.com/org/repo" -> "org--repo"
+ */
+function repoDirName(url: string): string {
+  try {
+    const parsed = new URL(url);
+    // Remove .git suffix and leading slash, replace / with --
+    const path = parsed.pathname.replace(/\.git$/, "").replace(/^\//, "");
+    return path.replace(/\//g, "--");
+  } catch {
+    // Fallback: use basename-like extraction
+    return basename(url).replace(/\.git$/, "") || "repo";
+  }
+}
+
+/**
+ * Clone or pull a repo into the .reposearch directory.
+ * Returns the local directory path, or null on failure.
+ */
+function cloneOrPullRepo(reposearchDir: string, repoUrl: string): string | null {
+  const dirName = repoDirName(repoUrl);
+  const repoDir = join(reposearchDir, dirName);
+
+  try {
+    if (existsSync(join(repoDir, ".git"))) {
+      // Repo already cloned — pull latest
+      execFileSync("git", ["pull", "--ff-only"], {
+        cwd: repoDir,
+        stdio: "pipe",
+        timeout: 60000,
+      });
+    } else {
+      // Fresh clone (shallow)
+      mkdirSync(reposearchDir, { recursive: true });
+      execFileSync("git", ["clone", "--depth", "1", repoUrl, repoDir], {
+        stdio: "pipe",
+        timeout: 120000,
+      });
+    }
+    return repoDir;
+  } catch (error) {
+    const message = error instanceof Error ? error.message : String(error);
+    console.error(`Warning: Failed to clone/pull ${repoUrl}: ${message}`);
+    return null;
+  }
+}
+
+/**
+ * Reposearch command - spawn research agent that searches across current project and external repos.
+ */
+class ReposearchCommand extends BaseCommand {
+  readonly name = "reposearch";
+  readonly description = "Research code across the current project and external GitHub repositories";
+
+  defineArguments(cmd: Command): void {
+    cmd
+      .argument("<query>", "Research query (natural language)")
+      .requiredOption("--repos <urls>", "Comma-separated GitHub repo URLs to search")
+      .option("--steps <n>", "Hard step limit for agent iterations", String(DEFAULT_REPOSEARCH_STEPS))
+      .option("--debug", "Include agent debug metadata (model, timing, fallback) in output");
+  }
+
+  async execute(args: Record<string, unknown>): Promise<CommandResult> {
+    const query = args.query as string;
+    const reposRaw = args.repos as string;
+    const stepsLimit = parseInt((args.steps as string) ?? String(DEFAULT_REPOSEARCH_STEPS), 10);
+    const debug = !!args.debug;
+
+    if (!query) {
+      return this.error("validation_error", "query is required");
+    }
+    if (!reposRaw) {
+      return this.error("validation_error", "--repos is required (comma-separated GitHub URLs)");
+    }
+
+    const repoUrls = reposRaw.split(",").map((u) => u.trim()).filter(Boolean);
+    if (repoUrls.length === 0) {
+      return this.error("validation_error", "No valid repo URLs provided");
+    }
+
+    const projectRoot = getProjectRoot();
+    const reposearchDir = join(projectRoot, ".reposearch");
+
+    // Clone or pull each repo
+    const repoDirectories: Array<{ url: string; dir: string }> = [];
+    const warnings: string[] = [];
+
+    for (const url of repoUrls) {
+      const dir = cloneOrPullRepo(reposearchDir, url);
+      if (dir) {
+        repoDirectories.push({ url, dir });
+      } else {
+        warnings.push(`Failed to clone/pull: ${url}`);
+      }
+    }
+
+    if (repoDirectories.length === 0) {
+      return this.error("clone_error", "All repo clones/pulls failed. Check URLs and network.");
+    }
+
+    const runner = new AgentRunner(projectRoot);
+
+    // Build directory listing for the agent
+    const repoListing = repoDirectories
+      .map((r) => `- ${r.url} → ${r.dir}`)
+      .join("\n");
+
+    const userMessage = `## Research Query
+${query}
+
+## Directories to Search
+
+### Current Project
+- Root: ${projectRoot}
+
+### External Repositories
+${repoListing}
+
+## Budget
+- Tool budget (soft): ${DEFAULT_REPOSEARCH_TOOL_BUDGET} tool calls
+- Available tools: grep (text search), glob (file patterns), read (file content), lsp (if available)
+- Search all relevant directories to answer the query
+
+${warnings.length > 0 ? `## Warnings\n${warnings.map((w) => `- ${w}`).join("\n")}\n\n` : ""}Respond with JSON matching the required schema.`;
+
+    try {
+      const result = await runner.run<ReposearchOutput>(
+        {
+          name: "reposearch",
+          systemPrompt: getReposearchPrompt(),
+          timeoutMs: DEFAULT_REPOSEARCH_TIMEOUT_MS,
+          steps: stepsLimit,
+        },
+        userMessage
+      );
+
+      if (!result.success) {
+        return this.error("agent_error", result.error ?? "Unknown agent error");
+      }
+
+      const data = result.data!;
+
+      return this.success(withDebugInfo({
+        query,
+        repos_requested: repoUrls,
+        repos_analyzed: data.repos_analyzed,
+        analysis: data.analysis,
+        code_references: data.code_references,
+        warnings,
+        metadata: result.metadata,
+      }, result, debug));
+    } catch (error) {
+      const message = error instanceof Error ? error.message : String(error);
+      return this.error("spawn_error", message);
+    }
+  }
+}
+
 /**
  * Register spawn commands on the given commander program.
  */
@@ -133,19 +302,35 @@ export function register(program: Command): void {
     .command("spawn")
     .description("Spawn sub-agents for specialized tasks");
 
+  // Register codesearch
   const codesearch = new CodesearchCommand();
-  const cmd = spawnCmd.command(codesearch.name).description(codesearch.description);
-  codesearch.defineArguments(cmd);
-  cmd.action(async (...args) => {
+  const codesearchCmd = spawnCmd.command(codesearch.name).description(codesearch.description);
+  codesearch.defineArguments(codesearchCmd);
+  codesearchCmd.action(async (...args) => {
     const opts = args[args.length - 2] as Record<string, unknown>;
     const cmdObj = args[args.length - 1] as Command;
     const positionalArgs = cmdObj.args;
 
-    // Map positional args to named args based on command definition
     const namedArgs: Record<string, unknown> = { ...opts };
     if (positionalArgs[0]) namedArgs.query = positionalArgs[0];
 
     const result = await codesearch.execute(namedArgs);
     console.log(JSON.stringify(result, null, 2));
   });
+
+  // Register reposearch
+  const reposearch = new ReposearchCommand();
+  const reposearchCmd = spawnCmd.command(reposearch.name).description(reposearch.description);
+  reposearch.defineArguments(reposearchCmd);
+  reposearchCmd.action(async (...args) => {
+    const opts = args[args.length - 2] as Record<string, unknown>;
+    const cmdObj = args[args.length - 1] as Command;
+    const positionalArgs = cmdObj.args;
+
+    const namedArgs: Record<string, unknown> = { ...opts };
+    if (positionalArgs[0]) namedArgs.query = positionalArgs[0];
+
+    const result = await reposearch.execute(namedArgs);
+    console.log(JSON.stringify(result, null, 2));
+  });
 }

package/.allhands/harness/src/lib/opencode/index.ts

@@ -101,6 +101,22 @@ export interface AggregatorOutput {
   design_notes?: string[];
 }
 
+// Reposearch output types
+export interface RepoCodeReference {
+  repo: string;        // "current" or the GitHub URL
+  file: string;        // relative path within the repo
+  line_start: number;
+  line_end: number;
+  code: string;
+  context: string;
+}
+
+export interface ReposearchOutput {
+  analysis: string;              // markdown research findings
+  code_references: RepoCodeReference[];
+  repos_analyzed: string[];
+}
+
 export { AgentRunner } from "./runner.js";
 
 // Debug metadata for agent results (included when --debug flag is passed)

package/.allhands/harness/src/lib/opencode/prompts/reposearch.md

@@ -0,0 +1,115 @@
+# Repo Search Agent
+
+You research code across a current project and one or more external GitHub repositories. You search all provided directories to answer questions, compare implementations, and analyze patterns across codebases. Return structured JSON with your findings.
+
+## Context
+
+You will receive:
+- **Project root directory**: The current project's codebase
+- **External repo directories**: One or more cloned GitHub repos under `.reposearch/`
+- **Research query**: What to investigate across these codebases
+
+## Available Tools
+
+**grep** - Text search via ripgrep
+- Search across any of the provided directories
+- Best for: string literals, identifiers, patterns, comments
+
+**glob** - File pattern matching
+- Discover files by extension or name pattern in any repo
+- Scope searches to specific directories
+
+**read** - File content retrieval
+- Read specific files from any repo after finding them
+- Specify line ranges when possible to minimize output
+
+**lsp** (if available) - Language Server Protocol
+- goToDefinition, findReferences, hover
+- Works on the current project; may not be available for external repos
+
+## Search Strategy
+
+1. **Understand the query**: Determine if it's about a single repo, a comparison, or a pattern search
+2. **Parallel discovery**: Search relevant directories simultaneously using grep/glob
+3. **Targeted reads**: Read specific files to understand implementations
+4. **Cross-reference**: Compare findings between repos to answer the query
+5. **Synthesize**: Combine findings into a coherent analysis
+
+## Budget Awareness
+
+You have a soft tool budget. Stay efficient:
+- Use grep/glob to narrow down before reading files
+- Don't read entire files when a section suffices
+- Avoid redundant searches across repos
+- Focus on the most relevant code to the query
+
+## Output Format
+
+Return ONLY valid JSON:
+
+```json
+{
+  "analysis": "## Findings\n\nMarkdown analysis of research findings...",
+  "code_references": [
+    {
+      "repo": "current",
+      "file": "src/auth/handler.ts",
+      "line_start": 10,
+      "line_end": 25,
+      "code": "function handleAuth() { ... }",
+      "context": "Current project's auth handler using JWT"
+    },
+    {
+      "repo": "https://github.com/org/project",
+      "file": "lib/auth.py",
+      "line_start": 45,
+      "line_end": 60,
+      "code": "class AuthMiddleware: ...",
+      "context": "External project uses middleware-based auth"
+    }
+  ],
+  "repos_analyzed": ["current", "https://github.com/org/project"]
+}
+```
+
+## Field Guidelines
+
+**analysis** (markdown string):
+- Structured markdown answering the research query
+- Include headings, comparisons, and key observations
+- Reference specific code when making claims
+- Keep focused on the query — don't summarize everything
+
+**code_references** (array, max 15):
+- `repo`: "current" for the project, or the GitHub URL for external repos
+- `file`: Relative path within the repo
+- `line_start` / `line_end`: 1-indexed line range
+- `code`: Actual code snippet (keep concise, 1-20 lines)
+- `context`: Why this reference is relevant (1 sentence)
+
+**repos_analyzed** (array):
+- List of repos that were actually searched
+- "current" for the project root
+- GitHub URLs for external repos
+
+## Use Cases
+
+**OSS Q&A**: "How does project X handle authentication?"
+- Focus on the external repo, search for auth-related patterns
+- Provide concrete code examples with explanation
+
+**Cross-repo comparison**: "Compare our error handling vs project X"
+- Search both repos for error handling patterns
+- Highlight similarities and differences in the analysis
+
+**Multi-framework comparison**: "How do projects A and B handle routing?"
+- Search multiple external repos
+- Compare approaches side-by-side in the analysis
+
+## Anti-patterns
+
+- Returning entire files instead of relevant sections
+- Analysis not grounded in actual code found
+- Missing cross-references when comparison was requested
+- Exceeding tool budget with redundant searches
+- Not searching all provided repos when the query requires it

package/.allhands/skills/harness-maintenance/references/validation-tooling.md

@@ -17,6 +17,16 @@ This is how validation compounds. Every domain has both a stochastic dimension (
 
 A validation suite must have a meaningful stochastic dimension to justify existing. Deterministic-only tools (type checking, linting, formatting) are test commands referenced directly in acceptance criteria and CI/CD — they are NOT suites.
 
+## Repository Agnosticism
+
+This reference file is a generic rule file that ships with the harness. It MUST NOT contain references to project-specific validation suites, commands, or infrastructure. All examples must either:
+- Reference existing default validation suites shipped with this repo (currently: xcode-automation, browser-automation)
+- Use generic/hypothetical descriptions that any target repository can map to their own context
+
+When examples are needed, use **snippets from the existing default suites** rather than naming suites or commands that belong to a specific target project. Target repositories create their own suites for their domains — this file teaches how to create and structure them, not what they should be called.
+
+**Why**: Target repositories consume this file as authoritative guidance. Project-specific references create confusion (agents look for suites that don't exist), couple the harness to a single project, and violate the principle that this file teaches patterns, not inventories. If a pattern needs a concrete example, draw it from xcode-automation or browser-automation.
+
 ## Creating Validation Tooling
 
 Follow `.allhands/flows/shared/CREATE_VALIDATION_TOOLING_SPEC.md` for the full process. This creates a spec, not an implementation.
@@ -80,6 +90,113 @@ Prompt files reference validation suites in their `validation_suites` frontmatte
 2. Agent runs suite's **Deterministic Integration** section for acceptance criteria gating
 3. Validation review (`PROMPT_VALIDATION_REVIEW.md`) confirms pass/fail
 
+## Command Documentation Principle
+
+Two categories of commands exist in validation suites, each requiring different documentation approaches:
+
+**External tooling commands — Document explicitly**: Commands from external tools (`xctrace`, `xcrun simctl`, `agent-browser`, `playwright`, `curl`, etc.) are stable, unfamiliar to agents by default, and unlikely to change with codebase evolution. Document specific commands, flags, and use cases inline with motivations. Example from xcode-automation: `xcrun xctrace record --template 'Time Profiler' --device '<UDID>' --attach '<PID>'` — the flags, ordering constraints, and PID discovery method are all external tool knowledge that the suite documents explicitly.
+
+**Internal codebase commands — Document patterns, not inventories**: Project-specific scripts, test commands, and codebase-specific CLI wrappers evolve rapidly. Instead:
+1. **Document core infrastructure commands explicitly** — commands that boot services, manage environments, and are foundational to validation in the target project. These are stable and essential per-project, but suites should teach agents how to discover them (e.g., "check `package.json` scripts" or "run `--help`"), not hardcode specific script names.
+2. **Teach patterns for everything else** — naming conventions, where to discover project commands, what categories mean, and how to build upon them.
+3. **Document motivations** — why different test categories exist, when to use which, what confidence each provides.
+
+Per **Frontier Models are Capable**: An agent given patterns + motivations + discovery instructions outperforms one given stale command inventories. Suites that teach patterns age gracefully; suites that enumerate commands require maintenance on every change.
+
+## Decision Tree Requirement
+
+Every validation suite MUST include a decision tree that routes agents to the correct validation approach based on their situation. Decision trees:
+- Distinguish which instructions are relevant to which validation scenario (e.g., UI-only test vs full E2E with native code changes)
+- Show where/when stochastic vs deterministic testing applies
+- Surface deterministic branch points where other validation suites must be utilized (e.g., "Does this branch have native code changes? → Yes → follow xcode-automation decision tree")
+- Cleanly articulate multiple expected use cases within a single suite
+
+The decision tree replaces flat prerequisite lists with structured routing. An agent reads the tree and follows the branch matching their situation, skipping irrelevant setup and finding the right cross-references.
+
+## tmux Session Management Standard
+
+All suites that require long-running processes (dev servers, Expo servers, Flask API, Metro bundler) MUST use the tmux approach proven in xcode-automation:
+
+```bash
+# CRITICAL: -t $TMUX_PANE pins split to agent's window, not user's focused window
+tmux split-window -h -d -t $TMUX_PANE \
+  -c /path/to/repo '<command>'
+```
+
+**Observability**: Agents MUST verify processes are running correctly via tmux pane capture (`tmux capture-pane -p -t <pane_id>`) before proceeding with validation. This prevents silent failures where a dev server fails to start but the agent proceeds to test against nothing.
+
+**Teardown**: Reverse order of setup. Kill processes via `tmux send-keys -t <pane_id> C-c` or kill the pane.
+
+**Worktree isolation**: Each worktree uses unique ports (via `.env.local`), so tmux sessions in different worktrees don't conflict. Agents must use the correct repo path (`-c`) for the worktree they're operating in.
+
+Reference xcode-automation as the canonical tmux pattern.
+
+## Hypothesis-First Validation Workflow
+
+New suites should be drafted, then tested hands-on on a feature branch before guidance is marked as proven. This aligns with the Proven vs Untested Guidance principle:
+
+1. **Draft**: Write suite files based on plan and codebase analysis (mark unverified practices as hypotheses)
+2. **Test on feature branch**: Check out a feature branch and exercise each suite's practices hands-on — boot services, run commands, verify workflows, test worktree isolation
+3. **Verify & adjust**: Document what works, what doesn't, what needs adjustment. Worktree-specific concerns get explicit verification.
+4. **Solidify**: Only after verification do practices become authoritative guidance. Unverified practices stay framed as motivations per the Proven vs Untested Guidance principle.
+
+The plan/handoff document persists as the hypothesis record. If implementation runs long, it serves as the handoff document for future work.
+
+## Cross-Referencing Between Suites
+
+**Reference** when complex multi-step setup is involved (e.g., simulator setup spanning multiple tools) — point to the authoritative suite's decision tree rather than duplicating instructions.
+
+**Inline** when the command is simple and stable (e.g., `xcrun simctl boot <UDID>`) — no need to send agents to another document for a single command.
+
+Decision trees are the natural place for cross-references — branch points that route to another suite's decision tree. Example from browser-automation: "Does the change affect native iOS rendering? → Yes → follow xcode-automation decision tree for build and simulator verification."
+
+## Testing Scenario Matrix
+
+Target repositories should build a scenario matrix mapping their validation scenarios to suite combinations. The matrix documents which suites apply to which types of changes, so agents can quickly determine what validation is needed. Structure as a table:
+
+| Scenario | Suite(s) | Notes |
+|----------|----------|-------|
+| _Description of change type_ | _Which suites apply_ | _Any special setup or cross-references_ |
+
+Example using this repo's default suites:
+
+| Scenario | Suite(s) | Notes |
+|----------|----------|-------|
+| Browser UI changes only | browser-automation | Dev server must be running |
+| Native iOS/macOS changes | xcode-automation | Simulator setup via session defaults |
+| Cross-platform changes (web + native) | browser-automation + xcode-automation | Each suite's decision tree routes to the relevant validation path |
+
+When a suite serves as a shared dependency for multiple scenarios (e.g., a database management suite referenced by both API and front-end suites), it should be cross-referenced via decision tree branch points rather than duplicated.
+
+## Environment Management Patterns
+
+Validation suites that depend on environment configuration should document these patterns for their domain:
+
+**ENV injection**: Document how the target project injects environment variables for different contexts (local development, testing, production). Suites should teach the pattern (e.g., "check for `.env.*` files and wrapper scripts") rather than hardcoding specific variable names.
+
+**Service isolation**: When validation requires running services (dev servers, databases, bundlers), document how to avoid port conflicts across concurrent worktrees or parallel agent sessions. Reference the suite's ENV Configuration table for relevant variables.
+
+**Worktree isolation**: Each worktree should use unique ports and isolated service instances where possible. Suites should document which resources need isolation and how to configure it (e.g., xcode-automation documents simulator isolation via dedicated simulator clones and derived data paths).
+
+## Suite Creation Guidance
+
+When creating a new validation suite for a new domain:
+
+**Engineer provides**: Testing scenarios, tooling requirements, CI/CD integration needs, cross-references to existing suites.
+
+**Suite author follows**:
+1. Follow the validation suite schema (`ah schema validation-suite`)
+2. Validate the stochastic dimension meets the existence threshold
+3. Apply the Command Documentation Principle — external tools explicit, internal commands via patterns + discovery
+4. Include a Decision Tree routing agents to the correct validation path
+5. Use tmux Session Management Standard for long-running processes
+6. Document proven vs untested guidance per the Hypothesis-First Validation Workflow
+7. Cross-reference other suites at decision tree branch points
+
+**Structural templates** (reference the existing default suites for patterns):
+- xcode-automation — external-tool-heavy suite (MCP tools, xctrace, simctl). Reference for suites that primarily wrap external CLI tools with agent-driven exploration.
+- browser-automation — dual-dimension suite (agent-browser stochastic, Playwright deterministic). Reference for suites that have both agent-driven exploration and scripted CI-gated tests.
+
 ## Related References
 
 - [`tools-commands-mcp-hooks.md`](tools-commands-mcp-hooks.md) — When validation uses hooks, CLI commands, or MCP research tools

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "all-hands-cli",
-  "version": "0.1.8",
+  "version": "0.1.10",
   "description": "Agentic harness for model-first software development",
   "type": "module",
   "bin": {