Archon/README.md

348 lines
16 KiB
Markdown
Raw Permalink Normal View History

<p align="center">
<img src="assets/logo.png" alt="Archon" width="160" />
</p>
<h1 align="center">Archon</h1>
<p align="center">
The first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.
</p>
<p align="center">
<a href="https://trendshift.io/repositories/13964" target="_blank"><img src="https://trendshift.io/api/badge/repositories/13964" alt="coleam00%2FArchon | Trendshift" style="width: 250px; height: 55px;" width="250" height="55"/></a>
</p>
<p align="center">
<a href="LICENSE"><img src="https://img.shields.io/badge/License-MIT-blue.svg" alt="License: MIT" /></a>
<a href="https://github.com/coleam00/Archon/actions/workflows/test.yml"><img src="https://github.com/coleam00/Archon/actions/workflows/test.yml/badge.svg" alt="CI" /></a>
<a href="https://archon.diy"><img src="https://img.shields.io/badge/docs-archon.diy-blue" alt="Docs" /></a>
</p>
---
2025-11-12 15:10:34 +00:00
Archon is a workflow engine for AI coding agents. Define your development processes as YAML workflows - planning, implementation, validation, code review, PR creation - and run them reliably across all your projects.
Like what Dockerfiles did for infrastructure and GitHub Actions did for CI/CD - Archon does for AI coding workflows. Think n8n, but for software development.
## Why Archon?
When you ask an AI agent to "fix this bug", what happens depends on the model's mood. It might skip planning. It might forget to run tests. It might write a PR description that ignores your template. Every run is different.
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
Archon fixes this. Encode your development process as a workflow. The workflow defines the phases, validation gates, and artifacts. The AI fills in the intelligence at each step, but the structure is deterministic and owned by you.
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
- **Repeatable** - Same workflow, same sequence, every time. Plan, implement, validate, review, PR.
- **Isolated** - Every workflow run gets its own git worktree. Run 5 fixes in parallel with no conflicts.
- **Fire and forget** - Kick off a workflow, go do other work. Come back to a finished PR with review comments.
- **Composable** - Mix deterministic nodes (bash scripts, tests, git ops) with AI nodes (planning, code generation, review). The AI only runs where it adds value.
- **Portable** - Define workflows once in `.archon/workflows/`, commit them to your repo. They work the same from CLI, Web UI, Slack, Telegram, or GitHub.
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
## What It Looks Like
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
Here's an example of an Archon workflow that plans, implements in a loop until tests pass, gets your approval, then creates the PR:
2025-11-12 15:10:34 +00:00
```yaml
# .archon/workflows/build-feature.yaml
refactor(workflows)!: remove sequential execution mode, DAG becomes sole format (#805) * refactor(workflows)!: remove sequential execution mode, DAG becomes sole format Remove the steps-based (sequential) workflow execution mode entirely. All workflows now use the nodes-based (DAG) format exclusively. - Convert 8 sequential default workflows to DAG format - Delete archon-fix-github-issue sequential (DAG version absorbs triggers) - Remove SingleStep, ParallelBlock, StepWorkflow types and guards - Gut executor.ts from ~2200 to ~730 lines (remove sequential loop) - Remove step_started/completed/failed and parallel_agent_* events - Remove logStepStart/Complete and logParallelBlockStart/Complete - Delete SequentialEditor, StepProgress, ParallelBlockView components - Remove sequential mode from workflow builder and execution views - Delete executor.test.ts (4395 lines), update ~45 test fixtures - Update CLAUDE.md and docs to reflect DAG-only format BREAKING CHANGE: Workflows using `steps:` format are no longer supported. Convert to `nodes:` (DAG) format. The loader provides a clear error message directing users to the migration guide. * fix: address review findings — guard errors, remove dead code, add tests - Guard logNodeSkip/logWorkflowError against filesystem errors in dag-executor - Move mkdir(artifactsDir) inside try-catch with user-friendly error - Remove startFromStep dead parameter from executeWorkflow signature - Remove isDagWorkflow() tautology and all callers (20+ sites) - Remove dead BuilderMode/mode state from frontend components - Remove vestigial isLoop, selectedStep, stepIndex, step_index fields - Remove "DAG" prefix from user-facing resume/error messages - Fix 5 stale docs (README, getting-started, authoring-commands, web adapter) - Update event-emitter tests to use node events instead of removed step events - Add executor-shared.test.ts (12 tests) for substituteWorkflowVariables - Add executor.test.ts (11 tests) for concurrent-run, model resolution, resume * fix(workflows): add migration guide, port preamble tests, improve error message - Add docs/sequential-dag-migration-guide.md with 3 conversion patterns (single step, chain with clearContext, parallel block) and a Claude Code migration command for automated conversion - Update loader error message to point to migration guide and include ready-to-run claude command - Port 8 preamble tests from deleted executor.test.ts to new executor-preamble.test.ts: staleness detection (3), concurrent-run guard (3), DAG resume (2) Addresses review feedback from #805. * fix(workflows): update loader test to match new error message wording * fix: address review findings — fail stuck runs, remove dead code, fix docs - Mark workflow run as failed when artifacts mkdir fails (prevents 15-min concurrent-run guard block) - Remove vestigial totalSteps from WorkflowStartedEvent and executor - Delete dead WorkflowToolbar.tsx (369 lines, no importers) - Remove stepIndex prop from StepLogs (always 0, label now "Node logs") - Restore cn() in StatusBar for consistent conditional classes - Promote resume-check log to error, add errorType to failure logs - Remove ghost $PLAN/$IMPLEMENTATION_SUMMARY from docs (never implemented) - Update workflows.md rules to DAG-only format - Fix migration guide trigger_rule example - Clean up blank-line residues and stale comments * fix: resolve rebase conflicts with #729 (forkSession) and #730 (dashboard) - Remove sequential forkSession/persistSession code from #729 (dead after sequential removal) - Fix loader type narrowing for DagNode context field - Update dashboard components from #730 to use dagNodes instead of steps - Remove WorkflowStepEvent/ParallelAgentEvent from dashboard SSE hook
2026-03-26 09:27:34 +00:00
nodes:
- id: plan
prompt: "Explore the codebase and create an implementation plan"
refactor(workflows)!: remove sequential execution mode, DAG becomes sole format (#805) * refactor(workflows)!: remove sequential execution mode, DAG becomes sole format Remove the steps-based (sequential) workflow execution mode entirely. All workflows now use the nodes-based (DAG) format exclusively. - Convert 8 sequential default workflows to DAG format - Delete archon-fix-github-issue sequential (DAG version absorbs triggers) - Remove SingleStep, ParallelBlock, StepWorkflow types and guards - Gut executor.ts from ~2200 to ~730 lines (remove sequential loop) - Remove step_started/completed/failed and parallel_agent_* events - Remove logStepStart/Complete and logParallelBlockStart/Complete - Delete SequentialEditor, StepProgress, ParallelBlockView components - Remove sequential mode from workflow builder and execution views - Delete executor.test.ts (4395 lines), update ~45 test fixtures - Update CLAUDE.md and docs to reflect DAG-only format BREAKING CHANGE: Workflows using `steps:` format are no longer supported. Convert to `nodes:` (DAG) format. The loader provides a clear error message directing users to the migration guide. * fix: address review findings — guard errors, remove dead code, add tests - Guard logNodeSkip/logWorkflowError against filesystem errors in dag-executor - Move mkdir(artifactsDir) inside try-catch with user-friendly error - Remove startFromStep dead parameter from executeWorkflow signature - Remove isDagWorkflow() tautology and all callers (20+ sites) - Remove dead BuilderMode/mode state from frontend components - Remove vestigial isLoop, selectedStep, stepIndex, step_index fields - Remove "DAG" prefix from user-facing resume/error messages - Fix 5 stale docs (README, getting-started, authoring-commands, web adapter) - Update event-emitter tests to use node events instead of removed step events - Add executor-shared.test.ts (12 tests) for substituteWorkflowVariables - Add executor.test.ts (11 tests) for concurrent-run, model resolution, resume * fix(workflows): add migration guide, port preamble tests, improve error message - Add docs/sequential-dag-migration-guide.md with 3 conversion patterns (single step, chain with clearContext, parallel block) and a Claude Code migration command for automated conversion - Update loader error message to point to migration guide and include ready-to-run claude command - Port 8 preamble tests from deleted executor.test.ts to new executor-preamble.test.ts: staleness detection (3), concurrent-run guard (3), DAG resume (2) Addresses review feedback from #805. * fix(workflows): update loader test to match new error message wording * fix: address review findings — fail stuck runs, remove dead code, fix docs - Mark workflow run as failed when artifacts mkdir fails (prevents 15-min concurrent-run guard block) - Remove vestigial totalSteps from WorkflowStartedEvent and executor - Delete dead WorkflowToolbar.tsx (369 lines, no importers) - Remove stepIndex prop from StepLogs (always 0, label now "Node logs") - Restore cn() in StatusBar for consistent conditional classes - Promote resume-check log to error, add errorType to failure logs - Remove ghost $PLAN/$IMPLEMENTATION_SUMMARY from docs (never implemented) - Update workflows.md rules to DAG-only format - Fix migration guide trigger_rule example - Clean up blank-line residues and stale comments * fix: resolve rebase conflicts with #729 (forkSession) and #730 (dashboard) - Remove sequential forkSession/persistSession code from #729 (dead after sequential removal) - Fix loader type narrowing for DagNode context field - Update dashboard components from #730 to use dagNodes instead of steps - Remove WorkflowStepEvent/ParallelAgentEvent from dashboard SSE hook
2026-03-26 09:27:34 +00:00
- id: implement
depends_on: [plan]
loop: # AI loop - iterate until done
prompt: "Read the plan. Implement the next task. Run validation."
until: ALL_TASKS_COMPLETE
fresh_context: true # Fresh session each iteration
2025-11-12 15:10:34 +00:00
- id: run-tests
depends_on: [implement]
bash: "bun run validate" # Deterministic - no AI
- id: review
depends_on: [run-tests]
prompt: "Review all changes against the plan. Fix any issues."
2025-11-12 15:10:34 +00:00
- id: approve
depends_on: [review]
loop: # Human approval gate
prompt: "Present the changes for review. Address any feedback."
until: APPROVED
interactive: true # Pauses and waits for human input
- id: create-pr
depends_on: [approve]
prompt: "Push changes and create a pull request"
```
Tell your coding agent what you want, and Archon handles the rest:
```
You: Use archon to add dark mode to the settings page
Agent: I'll run the archon-idea-to-pr workflow for this.
→ Creating isolated worktree on branch archon/task-dark-mode...
→ Planning...
→ Implementing (task 1/4)...
→ Implementing (task 2/4)...
→ Tests failing - iterating...
→ Tests passing after 2 iterations
→ Code review complete - 0 issues
→ PR ready: https://github.com/you/project/pull/47
```
## Previous Version
Looking for the original Python-based Archon (task management + RAG)? It's fully preserved on the [`archive/v1-task-management-rag`](https://github.com/coleam00/Archon/tree/archive/v1-task-management-rag) branch.
## Getting Started
> **Most users should start with the [Full Setup](#full-setup-5-minutes)** - it walks you through credentials, installs the Archon skill into your projects, and gives you the web dashboard.
>
> **Already have Claude Code and just want the CLI?** Jump to the [Quick Install](#quick-install-30-seconds).
### Full Setup (5 minutes)
Clone the repo and use the guided setup wizard. This configures credentials, platform integrations, and copies the Archon skill into your target projects.
<details>
<summary><b>Prerequisites</b> - Bun, Claude Code, and the GitHub CLI</summary>
**Bun** - [bun.sh](https://bun.sh)
```bash
# macOS/Linux
curl -fsSL https://bun.sh/install | bash
# Windows (PowerShell)
irm bun.sh/install.ps1 | iex
```
**GitHub CLI** - [cli.github.com](https://cli.github.com/)
```bash
# macOS
brew install gh
# Windows (via winget)
winget install GitHub.cli
# Linux (Debian/Ubuntu)
sudo apt install gh
```
**Claude Code** - [claude.ai/code](https://claude.ai/code)
```bash
# macOS/Linux/WSL
curl -fsSL https://claude.ai/install.sh | bash
# Windows (PowerShell)
irm https://claude.ai/install.ps1 | iex
```
</details>
2025-11-12 15:10:34 +00:00
```bash
git clone https://github.com/coleam00/Archon
cd Archon
bun install
claude
```
2025-11-12 15:10:34 +00:00
Then say: **"Set up Archon"**
2025-11-12 15:10:34 +00:00
docs: restructure setup flow, fix workflow tables, rename getting-started (#820) * docs: update README, getting-started, and authoring-workflows for default workflows (#789) Documentation was stale: workflow count was wrong (16→17), several workflows were missing from tables, router auto-selection was undocumented, and examples used deprecated sequential/loop syntax instead of DAG nodes. Changes: - README.md: Fix workflow count to 17, update table with all key workflows, add defaults-as-templates guidance, mention router auto-selection - docs/getting-started.md: Complete workflow table (all 17), add auto-selection explanation, convert custom workflow example to DAG syntax - docs/authoring-workflows.md: Remove sequential (steps:) and standalone loop sections, convert all examples to DAG nodes: syntax, add deprecation notice, add "Using defaults as templates" guidance, update summary Fixes #789 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(docs): address review findings — complete workflow table and fix stale step refs - Add 6 missing workflows to README table (now lists all 17) - Replace stale "step" references with "node" terminology in authoring-workflows.md - Update retry notification example to match DAG executor output - Fix artifact chain table to reference node name instead of "step 1" Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs(readme): remove Option A (run from Archon repo) — only target repo usage * docs: restructure setup flow — wizard-first, rename getting-started - README: Make the setup wizard the primary path (clone → claude → "set up archon") - README: Add clear "Start Using Archon" section with exit/cd/claude steps - README: Add note to always run from target repo, not Archon repo - README: Link to CLI and Web UI guides as alternative paths - Rename docs/getting-started.md → docs/getting-started-cli.md - Update all cross-references (7 files) to new filename * docs: fix workflow count (17 → 16) in authoring-workflows.md * docs: fix loop node YAML nesting and add fresh_context in authoring-workflows --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Rasmus Widing <rasmus.widing@gmail.com>
2026-03-26 10:54:04 +00:00
The setup wizard walks you through everything: CLI installation, authentication, platform selection, and copies the Archon skill to your target repo.
2025-11-12 15:10:34 +00:00
### Quick Install (30 seconds)
Already have Claude Code set up? Install the standalone CLI binary and skip the wizard.
**macOS / Linux**
```bash
curl -fsSL https://archon.diy/install | bash
```
**Windows (PowerShell)**
```powershell
irm https://archon.diy/install.ps1 | iex
```
**Homebrew**
```bash
brew install coleam00/archon/archon
```
fix(providers): replace Claude SDK embed with explicit binary-path resolver (#1217) * feat(providers): replace Claude SDK embed with explicit binary-path resolver Drop `@anthropic-ai/claude-agent-sdk/embed` and resolve Claude Code via CLAUDE_BIN_PATH env → assistants.claude.claudeBinaryPath config → throw with install instructions. The embed's silent failure modes on macOS (#1210) and Windows (#1087) become actionable errors with a documented recovery path. Dev mode (bun run) remains auto-resolved via node_modules. The setup wizard auto-detects Claude Code by probing the native installer path (~/.local/bin/claude), npm global cli.js, and PATH, then writes CLAUDE_BIN_PATH to ~/.archon/.env. Dockerfile pre-sets CLAUDE_BIN_PATH so extenders using the compiled binary keep working. Release workflow gets negative and positive resolver smoke tests. Docs, CHANGELOG, README, .env.example, CLAUDE.md, test-release and archon skills all updated to reflect the curl-first install story. Retires #1210, #1087, #1091 (never merged, now obsolete). Implements #1176. * fix(providers): only pass --no-env-file when spawning Claude via Bun/Node `--no-env-file` is a Bun flag that prevents Bun from auto-loading `.env` from the subprocess cwd. It is only meaningful when the Claude Code executable is a `cli.js` file — in which case the SDK spawns it via `bun`/`node` and the flag reaches the runtime. When `CLAUDE_BIN_PATH` points at a native compiled Claude binary (e.g. `~/.local/bin/claude` from the curl installer, which is Anthropic's recommended default), the SDK executes the binary directly. Passing `--no-env-file` then goes straight to the native binary, which rejects it with `error: unknown option '--no-env-file'` and the subprocess exits code 1. Emit `executableArgs` only when the target is a `.js` file (dev mode or explicit cli.js path). Caught by end-to-end smoke testing against the curl-installed native Claude binary. * docs: record env-leak validation result in provider comment Verified end-to-end with sentinel `.env` and `.env.local` files in a workflow CWD that the native Claude binary (curl installer) does not auto-load `.env` files. With Archon's full spawn pathway and parent env stripped, the subprocess saw both sentinels as UNSET. The first-layer protection in `@archon/paths` (#1067) handles the inheritance leak; `--no-env-file` only matters for the Bun-spawned cli.js path, where it is still emitted. * chore(providers): cleanup pass — exports, docs, troubleshooting Final-sweep cleanup tied to the binary-resolver PR: - Mirror Codex's package surface for the new Claude resolver: add `./claude/binary-resolver` subpath export and re-export `resolveClaudeBinaryPath` + `claudeFileExists` from the package index. Renames the previously single `fileExists` re-export to `codexFileExists` for symmetry; nothing outside the providers package was importing it. - Add a "Claude Code not found" entry to the troubleshooting reference doc with platform-specific install snippets and pointers to the AI Assistants binary-path section. - Reframe the example claudeBinaryPath in reference/configuration.md away from cli.js-only language; it accepts either the native binary or cli.js. * test+refactor(providers, cli): address PR review feedback Two test gaps and one doc nit from the PR review (#1217): - Extract the `--no-env-file` decision into a pure exported helper `shouldPassNoEnvFile(cliPath)` so the native-binary branch is unit testable without mocking `BUNDLED_IS_BINARY` or running the full sendQuery pathway. Six new tests cover undefined, cli.js, native binary (Linux + Windows), Homebrew symlink, and suffix-only matching. Also adds a `claude.subprocess_env_file_flag` debug log so the security-adjacent decision is auditable. - Extract the three install-location probes in setup.ts into exported wrappers (`probeFileExists`, `probeNpmRoot`, `probeWhichClaude`) and export `detectClaudeExecutablePath` itself, so the probe order can be spied on. Six new tests cover each tier winning, fall-through ordering, npm-tier skip when not installed, and the which-resolved-but-stale-path edge case. - CLAUDE.md `claudeBinaryPath` placeholder updated to reflect that the field accepts either the native binary or cli.js (the example value was previously `/absolute/path/to/cli.js`, slightly misleading now that the curl-installer native binary is the default). Skipped from the review by deliberate scope decision: - `resolveClaudeBinaryPath` async-with-no-await: matches Codex's resolver signature exactly. Changing only Claude breaks symmetry; if pursued, do both providers in a separate cleanup PR. - `isAbsolute()` validation in parseClaudeConfig: Codex doesn't do it either. Resolver throws on non-existence already. - Atomic `.env` writes in setup wizard: pre-existing pattern this PR touched only adjacently. File as separate issue if needed. - classifyError branch in dag-executor for setup errors: scope creep. - `.env.example` "missing #" claim: false positive (verified all CLAUDE_BIN_PATH lines have proper comment prefixes). * fix(test): use path.join in Windows-compatible probe-order test The "tier 2 wins (npm cli.js)" test hardcoded forward-slash path comparisons, but `path.join` produces backslashes on Windows. Caused the Windows CI leg of the test suite to fail while macOS and Linux passed. Use `path.join` for both the mock return value and the expectation so the separator matches whatever the platform produces.
2026-04-14 14:56:37 +00:00
> **Compiled binaries need a `CLAUDE_BIN_PATH`.** The quick-install binaries
> don't bundle Claude Code. Install it separately, then point Archon at it:
>
> ```bash
> # macOS / Linux / WSL
> curl -fsSL https://claude.ai/install.sh | bash
> export CLAUDE_BIN_PATH="$HOME/.local/bin/claude"
>
> # Windows (PowerShell)
> irm https://claude.ai/install.ps1 | iex
> $env:CLAUDE_BIN_PATH = "$env:USERPROFILE\.local\bin\claude.exe"
> ```
>
> Or set `assistants.claude.claudeBinaryPath` in `~/.archon/config.yaml`.
> The Docker image ships Claude Code pre-installed. See [AI Assistants → Binary path configuration](https://archon.diy/docs/getting-started/ai-assistants/#binary-path-configuration-compiled-binaries-only) for details.
### Start Using Archon
Once you've completed either setup path, go to your project and start working:
```bash
cd /path/to/your/project
claude
```
```
Use archon to fix issue #42
```
```
What archon workflows do I have? When would I use each one?
```
The coding agent handles workflow selection, branch naming, and worktree isolation for you. Projects are registered automatically the first time they're used.
> **Important:** Always run Claude Code from your target repo, not from the Archon repo. The setup wizard copies the Archon skill into your project so it works from there.
## Web UI
feat: add `archon serve` command for one-command web UI install (#1011) * Investigate issue #978: one-command web UI install via archon serve * feat: add `archon serve` command for one-command web UI install (#978) Extract `startServer(opts)` from server's monolithic `main()` into an exported function with `ServerOptions` (webDistPath, port, skipPlatformAdapters). Add `import.meta.main` guard so the file still works as a standalone script for `bun dev`. Create `archon serve` CLI command that lazily downloads a pre-built web UI tarball from GitHub releases on first run, verifies SHA-256 checksum, extracts atomically, then starts the full server. Cached per version in `~/.archon/web-dist/<version>/`. Update release CI to build the web UI, package it as `archon-web.tar.gz`, and include in release checksums. * fix: address review findings for archon serve command - Validate --port range (1-65535) and reject NaN before any other checks - Capture tar stderr for actionable extraction error messages - Add structured logging (download_started/download_failed/server_start_failed) - Post-extraction sanity check for index.html - Wrap renameSync with error context and tmpDir cleanup - Wrap fetch() calls to preserve URL context on network errors - Validate parseChecksum returns 64 hex chars - Set skipPlatformAdapters: true for standalone web UI mode - Improve ServerOptions/ServeOptions JSDoc - Move consoleErrorSpy cleanup to afterEach in tests - Add tests for port validation and malformed hash rejection - Update CLAUDE.md: CLI section, directory tree, package descriptions - Update README.md: mention archon serve for binary installs - Update docs-web: CLI reference, archon-directories * refactor: simplify serve command implementation - Use BUNDLED_IS_BINARY directly instead of version === 'dev' sentinel - Extract toError() helper for repeated error normalization - Use dirname() instead of manual substring/lastIndexOf - Extract cleanupAndThrow() for repeated rmSync + throw pattern - Add missing assertion on port 0 test for consistency
2026-04-10 10:33:47 +00:00
Archon includes a web dashboard for chatting with your coding agent, running workflows, and monitoring activity. Binary installs: run `archon serve` to download and start the web UI in one step. From source: ask your coding agent to run the frontend from the Archon repo, or run `bun run dev` from the repo root yourself.
Register a project by clicking **+** next to "Project" in the chat sidebar - enter a GitHub URL or local path. Then start a conversation, invoke workflows, and watch progress in real time.
**Key pages:**
- **Chat** - Conversation interface with real-time streaming and tool call visualization
- **Dashboard** - Mission Control for monitoring running workflows, with filterable history by project, status, and date
- **Workflow Builder** - Visual drag-and-drop editor for creating DAG workflows with loop nodes
- **Workflow Execution** - Step-by-step progress view for any running or completed workflow
**Monitoring hub:** The sidebar shows conversations from **all platforms** - not just the web. Workflows kicked off from the CLI, messages from Slack or Telegram, GitHub issue interactions - everything appears in one place.
See the [Web UI Guide](https://archon.diy/adapters/web/) for full documentation.
feat: add per-node skills for DAG workflows (#446) (#689) * feat: add per-node skills for DAG workflows (#446) Add `skills: [name, ...]` field to DAG workflow nodes. When a node has skills, the executor wraps it in an AgentDefinition that preloads those skills into the subagent context. 'Skill' is auto-added to allowedTools. - Add skills field to DagNodeBase type and loader validation - Add agents + agent fields to WorkflowAssistantOptions and AssistantRequestOptions for AgentDefinition wrapping - Pass agents/agent through ClaudeClient to SDK Options - Build AgentDefinition with preloaded skills in dag-executor - Add Codex warning (per-node skills not supported) - Add skills comma-separated input in Web UI NodeInspector - Add skills to WorkflowCanvas reactFlowToDagNodes conversion - Add 5 unit tests for skills parsing validation * feat: add Remotion video generation workflow and skills/MCP docs Add archon-remotion-generate as a bundled default workflow that uses per-node skills (remotion-best-practices) to generate Remotion video compositions with AI, then renders preview stills and full video via deterministic bash nodes. - Add archon-remotion-generate.yaml to defaults - Add docs/remotion-workflow.md with setup guide and examples - Add docs/skills.md documenting per-node skills feature (#446) - Register workflow in bundled-defaults.ts for binary builds * chore: gitignore skills-lock.json * fix: address review feedback for per-node skills (#446) - Always pass ['Skill'] in AgentDefinition.tools instead of undefined - Surface buildPromptWithContext errors to user via safeSendMessage - Use AgentDefinition from SDK in AssistantRequestOptions (remove cast) - Warn and skip non-object MCP server configs instead of silent passthrough - Include JSON parse error detail in loadMcpConfig error messages - Add 3 executor-level tests for skills options construction - Update bundled-defaults test count for remotion workflow - Add skills to CLAUDE.md, authoring-workflows.md, README.md, hooks.md - Clean up loader skills validation with type predicate
2026-03-17 07:21:47 +00:00
## What Can You Automate?
feat: DAG workflow engine with parallel execution and conditional branching (#450) * feat: add DAG workflow engine with parallel execution and conditional branching Adds a third workflow execution mode (`nodes:`) alongside `steps:` and `loop:`. DAG workflows support explicit dependency edges, parallel layer execution via Promise.allSettled, conditional branching with `when:` expressions, join semantics via `trigger_rule`, structured JSON output via Claude SDK `outputFormat`, and upstream output capture via `$node_id.output` substitution. - New: `DagNode`, `DagWorkflow`, `TriggerRule`, `NodeOutput`, `NodeState` types - New: `condition-evaluator.ts` — pure `evaluateCondition` for `when:` expressions - New: `dag-executor.ts` — topological sort, Promise.allSettled parallel layers, output capture, trigger rule evaluation, per-node provider/model resolution - Updated: `loader.ts` — detect `nodes:` key, validate node graph, Kahn cycle detection - Updated: `executor.ts` — route DAG workflows to dag-executor before loop dispatch - Updated: `logger.ts` / `event-emitter.ts` — node_start/complete/skip/error events - Updated: `workflow-bridge.ts` — SSE events for dag_node state changes - Updated: `AssistantRequestOptions` — added `outputFormat` for Claude structured output - Updated: `claude.ts` — thread `outputFormat` into SDK Options - Tests: 37 new tests (condition-evaluator + dag-executor topological sort, trigger rules, loader cycle detection, invalid DAG rejection, valid DAG parsing) * docs: document DAG workflow mode (nodes:) added in phase 1 Add full documentation for the new `nodes:` execution mode: - docs/authoring-workflows.md: add third workflow type section, full DAG schema reference (node fields, trigger_rule, when: conditions, output_format, $nodeId.output substitution), a DAG example workflow, and update the variable table and summary - CLAUDE.md: add nodes:/DAG bullet points to the Workflows section - README.md: add nodes: example alongside steps: and loop:, update key design patterns to mention DAG mode * fix: address DAG workflow engine review findings Critical bugs: - DB workflow status never updated after DAG completion (completeWorkflowRun/failWorkflowRun now called) - resolveNodeProviderAndModel throws silently swallowed by Promise.allSettled — now caught and returned as failed node outputs - substituteNodeOutputRefs JSON parse failure was silent — now logged as warn Important fixes: - Surface unparseable when: conditions to user via safeSendMessage (fail-open preserved) - Missing upstream nodes treated as failed in checkTriggerRule instead of silently filtered out - Config load failure in loadCommandPrompt upgraded from warn to error - Circular import executor ↔ dag-executor broken via new command-validation.ts module - Remove defensive "should never happen" else branch in executeNodeInternal (DagNode discriminated union guarantees it) Type improvements: - DagNode → CommandNode | PromptNode discriminated union (command/prompt mutually exclusive at type level) - NodeOutput → discriminated union (error: string required on failed, absent on others) - TRIGGER_RULES constant and isTriggerRule() added to types.ts, deduplicating loader.ts local definitions - isDagWorkflow simplified to Array.isArray(workflow.nodes) - output_format array guard in parseDagNode now rejects arrays and null values Code quality: - Replace all void workflowEventDb.createWorkflowEvent() with .catch() error logging - Fix o.error ?? 'unknown' to o.state === 'failed' ? o.error : 'unknown' (type-safe) - Export substituteNodeOutputRefs for unit testing Tests (7 new): - condition-evaluator: number and boolean JSON field coercion - dag-executor: none_failed_min_one_success with all-skipped deps, nodes+loop conflict, invalid trigger_rule rejection, substituteNodeOutputRefs (3 cases), all-nodes-skipped mechanism * docs: fix two inaccuracies in DAG workflow documentation - README: "Nodes without depends_on run in parallel" was misleading — root nodes run concurrently with each other in the same layer, but a single root node doesn't run "in parallel" with anything. Reworded to "are in the first layer and run concurrently with each other". - authoring-workflows.md: Variable Substitution section intro said "Loop prompts and DAG node prompts/commands support these variables" but step-based workflows also support the same variables via substituteWorkflowVariables in executor.ts. Updated to say all workflow types. * fix: address PR #450 review findings in DAG workflow engine Correctness: - Remove throw from !anyCompleted path to prevent double workflow_failed emission; add safeSendMessage and return instead - Guard lastSequentialSessionId assignment against undefined overwrite Type safety: - Narrow workflowProvider from string to 'claude' | 'codex' in resolveNodeProviderAndModel and executeDagWorkflow signatures - Remove unsafe 'as claude | codex' cast - Add compile-time assertion that NodeOutput covers all NodeState values Silent failure surfacing: - Pre-execution node failure now notifies user via safeSendMessage - Unexpected Promise.allSettled rejection notifies user and logs layerIdx - completeWorkflowRun DB failure notifies user of potential inconsistency - Codex node with output_format now warns user (not just server log) - Make resolveNodeProviderAndModel async to support the above Dead code: - Remove unused 'export type { MergedConfig }' re-export Comments: - Update safeSendMessage/substituteWorkflowVariables/loadCommandPrompt TODOs to reflect Rule of Three is now met - Fix executeNodeInternal docstring to mention context:'fresh' nodes - Fix evaluateCondition @param: "settled" not "completed" upstreams - Fix NodeOutput doc: "JSON-encoded string from the SDK" Tests (7 new): - substituteNodeOutputRefs: unknown node ref resolves to empty string - checkTriggerRule: absent upstream synthesised as failed (x2) - buildTopologicalLayers: two independent chains share layers correctly - evaluateCondition: valid expression returns parsed: true
2026-02-18 13:13:22 +00:00
Archon ships with workflows for common development tasks:
| Workflow | What it does |
|----------|-------------|
| `archon-assist` | General Q&A, debugging, exploration - full Claude Code agent with all tools |
docs: restructure setup flow, fix workflow tables, rename getting-started (#820) * docs: update README, getting-started, and authoring-workflows for default workflows (#789) Documentation was stale: workflow count was wrong (16→17), several workflows were missing from tables, router auto-selection was undocumented, and examples used deprecated sequential/loop syntax instead of DAG nodes. Changes: - README.md: Fix workflow count to 17, update table with all key workflows, add defaults-as-templates guidance, mention router auto-selection - docs/getting-started.md: Complete workflow table (all 17), add auto-selection explanation, convert custom workflow example to DAG syntax - docs/authoring-workflows.md: Remove sequential (steps:) and standalone loop sections, convert all examples to DAG nodes: syntax, add deprecation notice, add "Using defaults as templates" guidance, update summary Fixes #789 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(docs): address review findings — complete workflow table and fix stale step refs - Add 6 missing workflows to README table (now lists all 17) - Replace stale "step" references with "node" terminology in authoring-workflows.md - Update retry notification example to match DAG executor output - Fix artifact chain table to reference node name instead of "step 1" Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs(readme): remove Option A (run from Archon repo) — only target repo usage * docs: restructure setup flow — wizard-first, rename getting-started - README: Make the setup wizard the primary path (clone → claude → "set up archon") - README: Add clear "Start Using Archon" section with exit/cd/claude steps - README: Add note to always run from target repo, not Archon repo - README: Link to CLI and Web UI guides as alternative paths - Rename docs/getting-started.md → docs/getting-started-cli.md - Update all cross-references (7 files) to new filename * docs: fix workflow count (17 → 16) in authoring-workflows.md * docs: fix loop node YAML nesting and add fresh_context in authoring-workflows --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Rasmus Widing <rasmus.widing@gmail.com>
2026-03-26 10:54:04 +00:00
| `archon-fix-github-issue` | Classify issue → investigate/plan → implement → validate → PR → smart review → self-fix |
| `archon-idea-to-pr` | Feature idea → plan → implement → validate → PR → 5 parallel reviews → self-fix |
| `archon-plan-to-pr` | Execute existing plan → implement → validate → PR → review → self-fix |
| `archon-issue-review-full` | Comprehensive fix + full multi-agent review pipeline for GitHub issues |
| `archon-smart-pr-review` | Classify PR complexity → run targeted review agents → synthesize findings |
| `archon-comprehensive-pr-review` | Multi-agent PR review (5 parallel reviewers) with automatic fixes |
| `archon-create-issue` | Classify problem → gather context → investigate → create GitHub issue |
| `archon-validate-pr` | Thorough PR validation testing both main and feature branches |
| `archon-resolve-conflicts` | Detect merge conflicts → analyze both sides → resolve → validate → commit |
docs: restructure setup flow, fix workflow tables, rename getting-started (#820) * docs: update README, getting-started, and authoring-workflows for default workflows (#789) Documentation was stale: workflow count was wrong (16→17), several workflows were missing from tables, router auto-selection was undocumented, and examples used deprecated sequential/loop syntax instead of DAG nodes. Changes: - README.md: Fix workflow count to 17, update table with all key workflows, add defaults-as-templates guidance, mention router auto-selection - docs/getting-started.md: Complete workflow table (all 17), add auto-selection explanation, convert custom workflow example to DAG syntax - docs/authoring-workflows.md: Remove sequential (steps:) and standalone loop sections, convert all examples to DAG nodes: syntax, add deprecation notice, add "Using defaults as templates" guidance, update summary Fixes #789 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(docs): address review findings — complete workflow table and fix stale step refs - Add 6 missing workflows to README table (now lists all 17) - Replace stale "step" references with "node" terminology in authoring-workflows.md - Update retry notification example to match DAG executor output - Fix artifact chain table to reference node name instead of "step 1" Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs(readme): remove Option A (run from Archon repo) — only target repo usage * docs: restructure setup flow — wizard-first, rename getting-started - README: Make the setup wizard the primary path (clone → claude → "set up archon") - README: Add clear "Start Using Archon" section with exit/cd/claude steps - README: Add note to always run from target repo, not Archon repo - README: Link to CLI and Web UI guides as alternative paths - Rename docs/getting-started.md → docs/getting-started-cli.md - Update all cross-references (7 files) to new filename * docs: fix workflow count (17 → 16) in authoring-workflows.md * docs: fix loop node YAML nesting and add fresh_context in authoring-workflows --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Rasmus Widing <rasmus.widing@gmail.com>
2026-03-26 10:54:04 +00:00
| `archon-feature-development` | Implement feature from plan → validate → create PR |
| `archon-architect` | Architectural sweep, complexity reduction, codebase health improvement |
| `archon-refactor-safely` | Safe refactoring with type-check hooks and behavior verification |
| `archon-ralph-dag` | PRD implementation loop - iterate through stories until done |
docs: restructure setup flow, fix workflow tables, rename getting-started (#820) * docs: update README, getting-started, and authoring-workflows for default workflows (#789) Documentation was stale: workflow count was wrong (16→17), several workflows were missing from tables, router auto-selection was undocumented, and examples used deprecated sequential/loop syntax instead of DAG nodes. Changes: - README.md: Fix workflow count to 17, update table with all key workflows, add defaults-as-templates guidance, mention router auto-selection - docs/getting-started.md: Complete workflow table (all 17), add auto-selection explanation, convert custom workflow example to DAG syntax - docs/authoring-workflows.md: Remove sequential (steps:) and standalone loop sections, convert all examples to DAG nodes: syntax, add deprecation notice, add "Using defaults as templates" guidance, update summary Fixes #789 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(docs): address review findings — complete workflow table and fix stale step refs - Add 6 missing workflows to README table (now lists all 17) - Replace stale "step" references with "node" terminology in authoring-workflows.md - Update retry notification example to match DAG executor output - Fix artifact chain table to reference node name instead of "step 1" Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs(readme): remove Option A (run from Archon repo) — only target repo usage * docs: restructure setup flow — wizard-first, rename getting-started - README: Make the setup wizard the primary path (clone → claude → "set up archon") - README: Add clear "Start Using Archon" section with exit/cd/claude steps - README: Add note to always run from target repo, not Archon repo - README: Link to CLI and Web UI guides as alternative paths - Rename docs/getting-started.md → docs/getting-started-cli.md - Update all cross-references (7 files) to new filename * docs: fix workflow count (17 → 16) in authoring-workflows.md * docs: fix loop node YAML nesting and add fresh_context in authoring-workflows --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Rasmus Widing <rasmus.widing@gmail.com>
2026-03-26 10:54:04 +00:00
| `archon-remotion-generate` | Generate or modify Remotion video compositions with AI |
| `archon-test-loop-dag` | Loop node test workflow - iterative counter until completion |
fix: address PR #938 review findings — interactive loop correctness and coverage Fixed: - H1: Return 'completed' (not 'failed') from interactive loop gate to prevent false "Some DAG nodes failed" warnings in multi-node workflows - H2: Check safeSendMessage return value before pausing — fail the node with a clear error if the gate message failed to deliver, preventing orphaned paused runs - H3: Extend isApprovalTransition guard in updateWorkflowRun to cover loop_user_input metadata key, preventing completed_at from being stamped on resumable loop runs - M1: Add isApprovalContext() type guard in workflow-run.ts; replace unsafe casts in dag-executor.ts and command-handler.ts - M4/L3: Update comments to accurately reflect completed-return semantics and metadata merge requirement - L1: Pass '' instead of undefined for $LOOP_USER_INPUT on iterations after first - L4: Update $LOOP_USER_INPUT docstring to clarify first-iteration-only scoping - Gap6: Add archon-piv-loop to bundled-defaults.ts so it's available in binary builds Tests added: - H4: /workflow approve interactive_loop branch tests in command-handler.test.ts (routing, approval_received event, no node_completed, error cases) - M2: superRefine validation tests in loader.test.ts (reject interactive without gate_message; accept valid interactive loop) - M3: loader warning test for interactive loop in non-interactive workflow Docs updated: - H5: docs/loop-nodes.md — add interactive/gate_message fields, $LOOP_USER_INPUT variable, and interactive loop pattern section - M5: docs/authoring-workflows.md — note interactive loops require workflow-level interactive: true - L5: README.md — add archon-piv-loop row, update count 16→17 - L6: docs/authoring-workflows.md — update count 16→17 - L7: CLAUDE.md — add $LOOP_USER_INPUT to variable substitution table Bundled defaults test updated: count 10→11 to reflect archon-piv-loop addition Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-01 16:17:56 +00:00
| `archon-piv-loop` | Guided Plan-Implement-Validate loop with human review between iterations |
Archon ships 17 default workflows - run `archon workflow list` or describe what you want and the router picks the right one.
**Or define your own.** Default workflows are great starting points - copy one from `.archon/workflows/defaults/` and customize it. Workflows are YAML files in `.archon/workflows/`, commands are markdown files in `.archon/commands/`. Same-named files in your repo override the bundled defaults. Commit them - your whole team runs the same process.
See [Authoring Workflows](https://archon.diy/guides/authoring-workflows/) and [Authoring Commands](https://archon.diy/guides/authoring-commands/).
2025-11-12 15:10:34 +00:00
## Add a Platform
The Web UI and CLI work out of the box. Optionally connect a chat platform for remote access:
| Platform | Setup time | Guide |
|----------|-----------|-------|
| **Telegram** | 5 min | [Telegram Guide](https://archon.diy/adapters/telegram/) |
| **Slack** | 15 min | [Slack Guide](https://archon.diy/adapters/slack/) |
| **GitHub Webhooks** | 15 min | [GitHub Guide](https://archon.diy/adapters/github/) |
| **Discord** | 5 min | [Discord Guide](https://archon.diy/adapters/community/discord/) |
2025-11-12 15:10:34 +00:00
## Architecture
```
┌─────────────────────────────────────────────────────────┐
│ Platform Adapters (Web UI, CLI, Telegram, Slack, │
2026-04-20 06:59:26 +00:00
│ Discord, GitHub) │
└──────────────────────────┬──────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ Orchestrator │
│ (Message Routing & Context Management) │
└─────────────┬───────────────────────────┬───────────────┘
│ │
┌───────┴────────┐ ┌───────┴────────┐
│ │ │ │
▼ ▼ ▼ ▼
┌───────────┐ ┌────────────┐ ┌──────────────────────────┐
│ Command │ │ Workflow │ │ AI Assistant Clients │
feat(providers/pi): interactive flag binds UIContext for extensions (#1299) * feat(providers/pi): interactive flag binds UIContext for extensions Adds `interactive: true` opt-in to Pi provider (in `.archon/config.yaml` under `assistants.pi`) that binds a minimal `ExtensionUIContext` stub to each session. Without this, Pi's `ExtensionRunner.hasUI()` reports false, causing extensions like `@plannotator/pi-extension` to silently auto-approve every plan instead of opening their browser review UI. Semantics: clamped to `enableExtensions: true` — no extensions loaded means nothing would consume `hasUI`, so `interactive` alone is silently dropped. Stub forwards `notify()` to Archon's event stream; interactive dialogs (select/confirm/input/editor/custom) resolve to undefined/false; TUI-only setters (widgets/headers/footers/themes) no-op. Theme access throws with a clear diagnostic — Pi's theme singleton is coupled to its own `Symbol.for()` registry which Archon doesn't own. Trust boundary: only binds when the operator has explicitly enabled both flags. Extensions gated on `ctx.hasUI` (plannotator and similar) get a functional UI context; extensions that reach for TUI features still fail loudly rather than rendering garbage. Includes smoke-test workflow documenting the integration surface. End-to-end plannotator UI rendering requires plan-mode activation (Pi `--plan` CLI flag or `/plannotator` TUI slash command) which is out of reach for programmatic Archon sessions — manual test only. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(providers/pi): end-to-end interactive extension UI Three fixes that together get plannotator's browser review UI to actually render from an Archon workflow and reach the reviewer's browser. 1. Call resourceLoader.reload() when enableExtensions is true. createAgentSession's internal reload is gated on `!resourceLoader`, so caller-supplied loaders must reload themselves. Without this, getExtensions() returns the empty default, no ExtensionRunner is built, and session.extensionRunner.setFlagValue() silently no-ops. 2. Set PLANNOTATOR_REMOTE=1 in interactive mode. plannotator-browser.ts only calls ctx.ui.notify(url) when openBrowser() returns { isRemote: true }; otherwise it spawns xdg-open/start on the Archon server host — invisible to the user and untestable from bash asserts. From the workflow runner's POV every Archon execution IS remote; flipping the heuristic routes the URL through notify(), which the ExtensionUIContext stub forwards into the event stream. Respect explicit operator overrides. 3. notify() emits as assistant chunks, not system chunks. The DAG executor's system-chunk filter only forwards warnings/MCP prefixes, and only assistant chunks accumulate into $nodeId.output. Emitting as assistant makes the URL available both in the user's stream and in downstream bash/script nodes via output substitution. Plus: extensionFlags config pass-through (equivalent to `pi --plan` on the CLI) applied via ExtensionRunner.setFlagValue() BEFORE bindExtensions fires session_start, so extensions reading flags in their startup handler actually see them. Also bind extensions with an empty binding when enableExtensions is on but interactive is off, so session_start still fires for flag-driven but UI-less extensions. Smoke test (.archon/workflows/e2e-plannotator-smoke.yaml) uses openai-codex/gpt-5.4-mini (ChatGPT Plus OAuth compatible) and bumps idle_timeout to 600000ms so plannotator's server survives while a human approves in the browser. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * refactor(providers/pi): keep Archon extension-agnostic Remove the plannotator-specific PLANNOTATOR_REMOTE=1 env var write from the Pi provider. Archon's provider layer shouldn't know about any specific extension's internals. Document the env var in the plannotator smoke test instead — operators who use plannotator set it via their shell or per-codebase env config. Workflow smoke test updated with: - Instructions for setting PLANNOTATOR_REMOTE=1 externally - Simpler assertion (URL emission only) — validated in a real reject-revise-approve run: reviewer annotated, clicked Send Feedback, Pi received the feedback as a tool result, revised the plan (added aria-label and WCAG contrast per the annotation), resubmitted, and reviewer approved. Plannotator's tool result signals approval but doesn't return the plan text, so the bash assertion now only checks that the review URL reached the stream (not that plan content flowed into \$nodeId.output — it can't). - Known-limitation note documenting the tool-result shape so downstream workflow authors know to Write the plan separately if they need it. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * chore(providers/pi): keep e2e-plannotator-smoke workflow local-only The smoke test is plannotator-specific (calls plannotator_submit_plan, expects PLAN.md on disk, requires PLANNOTATOR_REMOTE=1) and is better kept out of the PR while the extension-agnostic infra lands. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * style(providers/pi): trim verbose inline comments Collapse multi-paragraph SDK explanations to 1-2 line "why" notes across provider.ts, types.ts, ui-context-stub.ts, and event-bridge.ts. No behavior change. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(providers/pi): wire assistants.pi.env + theme-proxy identity Two end-to-end fixes discovered while exercising the combined plannotator + @pi-agents/loop smoke flow: - PiProviderDefaults gains an optional `env` map; parsePiConfig picks it up and the provider applies it to process.env at session start (shell env wins, no override). Needed so extensions like plannotator can read PLANNOTATOR_REMOTE=1 from config.yaml without requiring a shell export before `archon workflow run`. - ui-context-stub theme proxy returns identity decorators instead of throwing on unknown methods. Styled strings flow into no-op setStatus/setWidget sinks anyway, so the throw was blocking plannotator_submit_plan after HTTP approval with no benefit. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(providers/pi): flush notify() chunks immediately in batch mode Batch-mode adapters (CLI) accumulate assistant chunks and only flush on node completion. That broke plannotator's review-URL flow: Pi's notify() emitted the URL as an assistant chunk, but the user needed the URL to POST /api/approve — which is what unblocks the node in the first place. Adds an optional `flush` flag on assistant MessageChunks. notify() sets it, and the DAG executor drains pending batched content before surfacing the flushed chunk so ordering is preserved. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * docs: mention Pi alongside Claude and Codex in README + top-level docs The AI assistants docs page already covers Pi in depth, but the README architecture diagram + docs table, overview "Further Reading" section, and local-deployment .env comment still listed only Claude/Codex. Left feature-specific mentions alone where Pi genuinely lacks support (e.g. structured output — Claude + Codex only). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * docs: note Pi structured output (best-effort) in matrix + workflow docs Pi gained structured output support via prompt augmentation + JSON extraction (see packages/providers/src/community/pi/capabilities.ts). Unlike Claude/Codex, which use SDK-enforced JSON mode, Pi appends the schema to the prompt and parses JSON out of the result text (bare or fenced). Updates four stale references that still said Claude/Codex-only: - ai-assistants.md capabilities matrix - authoring-workflows.md (YAML example + field table) - workflow-dag.md skill reference - CLAUDE.md DAG-format node description Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(providers/pi): default extensions + interactive to on Extensions (community packages like @plannotator/pi-extension and user-authored ones) are a core reason users pick Pi. Defaulting enableExtensions and interactive to false previously silenced installed extensions with no signal, leading to "did my extension even load?" confusion. Opt out in .archon/config.yaml when you want the prior behavior: assistants: pi: enableExtensions: false # skip extension discovery entirely # interactive: false # load extensions, but no UI bridge Docs gain a new "Extensions (on by default)" section in getting-started/ai-assistants.md that documents the three config surfaces (extensionFlags, env, workflow-level interactive) and uses plannotator as a concrete walk-through example. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
2026-04-20 12:37:40 +00:00
│ Handler │ │ Executor │ │ (Claude / Codex / Pi) │
│ (Slash) │ │ (YAML) │ │ │
└───────────┘ └────────────┘ └──────────────────────────┘
│ │ │
└──────────────┴──────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ SQLite / PostgreSQL (7 Tables) │
│ Codebases • Conversations • Sessions • Workflow Runs │
│ Isolation Environments • Messages • Workflow Events │
└─────────────────────────────────────────────────────────┘
2025-11-12 15:10:34 +00:00
```
## Documentation
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
Full documentation is available at **[archon.diy](https://archon.diy)**.
| Topic | Description |
|-------|-------------|
| [Getting Started](https://archon.diy/getting-started/overview/) | Setup guide (Web UI or CLI) |
| [The Book of Archon](https://archon.diy/book/) | 10-chapter narrative tutorial |
| [CLI Reference](https://archon.diy/reference/cli/) | Full CLI reference |
| [Authoring Workflows](https://archon.diy/guides/authoring-workflows/) | Create custom YAML workflows |
| [Authoring Commands](https://archon.diy/guides/authoring-commands/) | Create reusable AI commands |
| [Configuration](https://archon.diy/reference/configuration/) | All config options, env vars, YAML settings |
feat(providers/pi): interactive flag binds UIContext for extensions (#1299) * feat(providers/pi): interactive flag binds UIContext for extensions Adds `interactive: true` opt-in to Pi provider (in `.archon/config.yaml` under `assistants.pi`) that binds a minimal `ExtensionUIContext` stub to each session. Without this, Pi's `ExtensionRunner.hasUI()` reports false, causing extensions like `@plannotator/pi-extension` to silently auto-approve every plan instead of opening their browser review UI. Semantics: clamped to `enableExtensions: true` — no extensions loaded means nothing would consume `hasUI`, so `interactive` alone is silently dropped. Stub forwards `notify()` to Archon's event stream; interactive dialogs (select/confirm/input/editor/custom) resolve to undefined/false; TUI-only setters (widgets/headers/footers/themes) no-op. Theme access throws with a clear diagnostic — Pi's theme singleton is coupled to its own `Symbol.for()` registry which Archon doesn't own. Trust boundary: only binds when the operator has explicitly enabled both flags. Extensions gated on `ctx.hasUI` (plannotator and similar) get a functional UI context; extensions that reach for TUI features still fail loudly rather than rendering garbage. Includes smoke-test workflow documenting the integration surface. End-to-end plannotator UI rendering requires plan-mode activation (Pi `--plan` CLI flag or `/plannotator` TUI slash command) which is out of reach for programmatic Archon sessions — manual test only. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(providers/pi): end-to-end interactive extension UI Three fixes that together get plannotator's browser review UI to actually render from an Archon workflow and reach the reviewer's browser. 1. Call resourceLoader.reload() when enableExtensions is true. createAgentSession's internal reload is gated on `!resourceLoader`, so caller-supplied loaders must reload themselves. Without this, getExtensions() returns the empty default, no ExtensionRunner is built, and session.extensionRunner.setFlagValue() silently no-ops. 2. Set PLANNOTATOR_REMOTE=1 in interactive mode. plannotator-browser.ts only calls ctx.ui.notify(url) when openBrowser() returns { isRemote: true }; otherwise it spawns xdg-open/start on the Archon server host — invisible to the user and untestable from bash asserts. From the workflow runner's POV every Archon execution IS remote; flipping the heuristic routes the URL through notify(), which the ExtensionUIContext stub forwards into the event stream. Respect explicit operator overrides. 3. notify() emits as assistant chunks, not system chunks. The DAG executor's system-chunk filter only forwards warnings/MCP prefixes, and only assistant chunks accumulate into $nodeId.output. Emitting as assistant makes the URL available both in the user's stream and in downstream bash/script nodes via output substitution. Plus: extensionFlags config pass-through (equivalent to `pi --plan` on the CLI) applied via ExtensionRunner.setFlagValue() BEFORE bindExtensions fires session_start, so extensions reading flags in their startup handler actually see them. Also bind extensions with an empty binding when enableExtensions is on but interactive is off, so session_start still fires for flag-driven but UI-less extensions. Smoke test (.archon/workflows/e2e-plannotator-smoke.yaml) uses openai-codex/gpt-5.4-mini (ChatGPT Plus OAuth compatible) and bumps idle_timeout to 600000ms so plannotator's server survives while a human approves in the browser. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * refactor(providers/pi): keep Archon extension-agnostic Remove the plannotator-specific PLANNOTATOR_REMOTE=1 env var write from the Pi provider. Archon's provider layer shouldn't know about any specific extension's internals. Document the env var in the plannotator smoke test instead — operators who use plannotator set it via their shell or per-codebase env config. Workflow smoke test updated with: - Instructions for setting PLANNOTATOR_REMOTE=1 externally - Simpler assertion (URL emission only) — validated in a real reject-revise-approve run: reviewer annotated, clicked Send Feedback, Pi received the feedback as a tool result, revised the plan (added aria-label and WCAG contrast per the annotation), resubmitted, and reviewer approved. Plannotator's tool result signals approval but doesn't return the plan text, so the bash assertion now only checks that the review URL reached the stream (not that plan content flowed into \$nodeId.output — it can't). - Known-limitation note documenting the tool-result shape so downstream workflow authors know to Write the plan separately if they need it. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * chore(providers/pi): keep e2e-plannotator-smoke workflow local-only The smoke test is plannotator-specific (calls plannotator_submit_plan, expects PLAN.md on disk, requires PLANNOTATOR_REMOTE=1) and is better kept out of the PR while the extension-agnostic infra lands. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * style(providers/pi): trim verbose inline comments Collapse multi-paragraph SDK explanations to 1-2 line "why" notes across provider.ts, types.ts, ui-context-stub.ts, and event-bridge.ts. No behavior change. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(providers/pi): wire assistants.pi.env + theme-proxy identity Two end-to-end fixes discovered while exercising the combined plannotator + @pi-agents/loop smoke flow: - PiProviderDefaults gains an optional `env` map; parsePiConfig picks it up and the provider applies it to process.env at session start (shell env wins, no override). Needed so extensions like plannotator can read PLANNOTATOR_REMOTE=1 from config.yaml without requiring a shell export before `archon workflow run`. - ui-context-stub theme proxy returns identity decorators instead of throwing on unknown methods. Styled strings flow into no-op setStatus/setWidget sinks anyway, so the throw was blocking plannotator_submit_plan after HTTP approval with no benefit. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(providers/pi): flush notify() chunks immediately in batch mode Batch-mode adapters (CLI) accumulate assistant chunks and only flush on node completion. That broke plannotator's review-URL flow: Pi's notify() emitted the URL as an assistant chunk, but the user needed the URL to POST /api/approve — which is what unblocks the node in the first place. Adds an optional `flush` flag on assistant MessageChunks. notify() sets it, and the DAG executor drains pending batched content before surfacing the flushed chunk so ordering is preserved. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * docs: mention Pi alongside Claude and Codex in README + top-level docs The AI assistants docs page already covers Pi in depth, but the README architecture diagram + docs table, overview "Further Reading" section, and local-deployment .env comment still listed only Claude/Codex. Left feature-specific mentions alone where Pi genuinely lacks support (e.g. structured output — Claude + Codex only). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * docs: note Pi structured output (best-effort) in matrix + workflow docs Pi gained structured output support via prompt augmentation + JSON extraction (see packages/providers/src/community/pi/capabilities.ts). Unlike Claude/Codex, which use SDK-enforced JSON mode, Pi appends the schema to the prompt and parses JSON out of the result text (bare or fenced). Updates four stale references that still said Claude/Codex-only: - ai-assistants.md capabilities matrix - authoring-workflows.md (YAML example + field table) - workflow-dag.md skill reference - CLAUDE.md DAG-format node description Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(providers/pi): default extensions + interactive to on Extensions (community packages like @plannotator/pi-extension and user-authored ones) are a core reason users pick Pi. Defaulting enableExtensions and interactive to false previously silenced installed extensions with no signal, leading to "did my extension even load?" confusion. Opt out in .archon/config.yaml when you want the prior behavior: assistants: pi: enableExtensions: false # skip extension discovery entirely # interactive: false # load extensions, but no UI bridge Docs gain a new "Extensions (on by default)" section in getting-started/ai-assistants.md that documents the three config surfaces (extensionFlags, env, workflow-level interactive) and uses plannotator as a concrete walk-through example. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
2026-04-20 12:37:40 +00:00
| [AI Assistants](https://archon.diy/getting-started/ai-assistants/) | Claude, Codex, and Pi setup details |
| [Deployment](https://archon.diy/deployment/) | Docker, VPS, production setup |
| [Architecture](https://archon.diy/reference/architecture/) | System design and internals |
| [Troubleshooting](https://archon.diy/reference/troubleshooting/) | Common issues and fixes |
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
feat(telemetry): anonymous PostHog workflow-invocation tracking (#1262) * feat(telemetry): add anonymous PostHog workflow-invocation tracking Emits one `workflow_invoked` event per run with workflow name/description, platform, and Archon version. Uses a stable random UUID persisted to `$ARCHON_HOME/telemetry-id` for distinct-install counting, with `$process_person_profile: false` to stay in PostHog's anonymous tier. Opt out with `ARCHON_TELEMETRY_DISABLED=1` or `DO_NOT_TRACK=1`. Self-host via `POSTHOG_API_KEY` / `POSTHOG_HOST`. Closes #1261 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * test(telemetry): stop leaking test events to production PostHog The `telemetry-id preservation` test exercised the real capture path with the embedded production key, so every `bun run validate` published a tombstone `workflow_name: "w"` event. Redirect POSTHOG_HOST to loopback so the flush fails silently; bump test timeout to accommodate the retry-then-give-up window. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(telemetry): silence posthog-node stderr leak on network failure The PostHog SDK's internal logFlushError() writes 'Error while flushing PostHog' directly to stderr via console.error on any network or HTTP error, bypassing logger config. For a fire-and-forget telemetry path this leaked stack traces to users' terminals whenever PostHog was unreachable (offline, firewalled, DNS broken, rate-limited). Pass a silentFetch wrapper to the PostHog client that masks failures as fake 200 responses. The SDK never sees an error, so it never logs. Original failure is still recorded at debug level for diagnostics. Side benefit: shutdown is now fast on network failure (no retry loop), so offline CLI commands no longer hang ~10s on exit. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * test(telemetry): make id-preservation test deterministic Replace the fire-and-forget capture + setTimeout + POSTHOG_HOST-loopback dance with a direct synchronous call to getOrCreateTelemetryId(). Export the function with an @internal marker so tests can exercise the id path without spinning up the PostHog client. No network, no timer, no flake. Addresses CodeRabbit feedback on #1262. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
2026-04-16 18:45:55 +00:00
## Telemetry
Archon sends a single anonymous event — `workflow_invoked` — each time a workflow starts, so maintainers can see which workflows get real usage and prioritize accordingly. **No PII, ever.**
**What's collected:** the workflow name, the workflow description (both authored by you in YAML), the platform that triggered it (`cli`, `web`, `slack`, etc.), the Archon version, and a random install UUID stored at `~/.archon/telemetry-id`. Nothing else.
**What's *not* collected:** your code, prompts, messages, git remotes, file paths, usernames, tokens, AI output, workflow node details — none of it.
**Opt out:** set any of these in your environment:
```bash
ARCHON_TELEMETRY_DISABLED=1
DO_NOT_TRACK=1 # de facto standard honored by Astro, Bun, Prisma, Nuxt, etc.
```
Self-host PostHog or use a different project by setting `POSTHOG_API_KEY` and `POSTHOG_HOST`.
## Contributing
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
Contributions welcome! See the open [issues](https://github.com/coleam00/Archon/issues) for things to work on.
Please read [CONTRIBUTING.md](CONTRIBUTING.md) before submitting a pull request.
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
## Star History
[![Star History Chart](https://api.star-history.com/chart?repos=coleam00/Archon&type=date&legend=top-left)](https://www.star-history.com/?repos=coleam00%2FArchon&type=date&legend=top-left)
## License
feat: Phase 5 - CLI binary distribution (#325) * docs: Add Phase 5 CLI binary distribution plan - Create detailed implementation plan for binary distribution - Add Phase 5.0: Bundle defaults for binary (depends on #322) - Add Phase 5.1-5.7: Build scripts, GitHub Actions, curl install, Homebrew formula, Windows docs, version command, release guide - Update research doc with Phase 6 (auto-update command) - Renumber dashboard to Phase 7, workflow builder to Phase 8 - Mark Phases 1-4 as complete in research doc * feat: Phase 5 - CLI binary distribution Implement standalone binary distribution for Archon CLI: - Bundle default commands and workflows into binaries at compile time - Add build scripts for cross-platform compilation (macOS/Linux, ARM64/x64) - Create GitHub Actions release workflow triggered on version tags - Add curl install script with checksum verification - Create Homebrew formula for macOS/Linux installation - Update version command to show platform, build type, and database info - Add developer release guide documentation - Update README with CLI installation instructions Binary compilation uses Bun's --compile flag to create standalone executables that include the Bun runtime and all dependencies. Default workflows and commands are imported as text at compile time and embedded directly into the binary. * fix: Pin Dockerfile to Bun 1.3.4 to match lockfile version The Docker build was failing because oven/bun:1-slim resolved to 1.3.6 while the lockfile was created with 1.3.4, causing --frozen-lockfile to fail. * docs: Clarify binary vs source builds for default commands/workflows * fix: Address PR review issues for CLI binary distribution Security fixes: - install.sh: Require SKIP_CHECKSUM=true to bypass checksum verification instead of silently skipping (addresses security vulnerability) - install.sh: Show actual error output when version check fails instead of falsely reporting success Validation improvements: - checksums.sh: Validate all 4 expected binaries exist before generating checksums to prevent releasing incomplete builds - build-binaries.sh: Verify binary exists and has reasonable size (>1MB) after each build step - update-homebrew.sh: Validate extracted checksums are non-empty and look like valid SHA256 hashes (64 hex chars) - update-homebrew.sh: Fix sed patterns to use URL context for updating checksums on subsequent runs Bug fixes: - homebrew/archon.rb: Fix test to expect exit code 0 (success) instead of 1 for `archon version` - loader.ts: Log error when bundled workflow fails to parse (indicates build-time corruption) Test coverage: - Add bundled-defaults.test.ts for isBinaryBuild() and content validation - Add connection.test.ts for getDatabaseType() function - Add binary build bundled workflow tests to loader.test.ts - Add binary build bundled command tests to executor.test.ts All 959 tests pass.
2026-01-21 21:51:51 +00:00
[MIT](LICENSE)