@straiffi/archon 1.0.5 → 1.0.7

package/README.md

@@ -1,6 +1,6 @@
 # Archon
 
-A ticket-driven interface for AI-assisted code automation. Create tickets, plan features, then let an AI agent (Claude or OpenCode) implement them in isolated git worktrees.
+Archon is a ticket-driven interface for AI-assisted code automation. Create tickets, plan features, then let an AI agent such as Claude or OpenCode implement them in isolated git worktrees.
 
 ## Install
 
@@ -42,7 +42,7 @@ archon update
 
 V1 targets macOS and Linux first.
 
-## External tool prerequisites
+## External Tool Prerequisites
 
 Archon does not bundle external developer tools.
 
@@ -51,49 +51,25 @@ Required or commonly expected tools:
 | Tool | Why it matters |
 | --- | --- |
 | `git` | Required for project repositories, worktrees, diffing, and commit operations |
-| `opencode` | Required for OpenCode plan/build/chat/review workflows |
-| `claude` | Required for Claude-backed workflows |
-| `gh` | Required for GitHub PR and review integration |
+| `opencode` | Needed for OpenCode-backed plan, build, chat, and review workflows |
+| `claude` | Needed for Claude-backed workflows |
+| `gh` | Optional for GitHub PR and review workflows; GitHub API key integration also works without it |
 
-If one of the optional AI tools is missing, Archon should still start, but features that depend on that binary will return actionable errors.
+Archon should still start if an optional tool is missing, but features that depend on that binary or integration path will return actionable errors.
 
-## How it works
+## How It Works
 
-Tickets move through three states:
+Archon has three main workspaces:
 
-1. **Plan** — write a title and description for the feature or task
-2. **Build** — the server spawns your configured AI tool in a new git worktree on a dedicated branch; real-time logs stream back to the UI
-3. **Review** — an agent conducts a code review and fixes any issues found
+1. **Board**: create tickets, move them through planning and implementation, and run builds in isolated git worktrees on dedicated branches.
+2. **Chat**: use persistent project chat sessions for planning, implementation help, and follow-up questions. Chat supports both planning-oriented and build-oriented turns so you can scope work first, then continue in the same conversation.
+3. **Memory**: optionally save project conventions, accepted decisions, and other prompt context in Archon so future ticket, chat, build, and review runs stay aligned with how your project works.
 
-The frontend is a React kanban board. The backend is an Express server with a SQLite database and Socket.io for live status updates.
+Within the board workflow, tickets move through three stages:
 
-## Development
-
-For normal source development, use the repo checkout workflow instead of the packaged CLI.
-
-Install dependencies from the repository root:
-
-```bash
-npm install
-```
-
-Start dev mode:
-
-```bash
-npm run start:dev
-```
-
-`npm run start:dev` is the primary local development command. It keeps the Express server and Vite frontend as separate processes and configures the dev database plus API base URL overrides for you.
-
-Other useful commands:
-
-```bash
-npm run build
-npm test
-npm run smoke:package
-```
-
-`npm run smoke:package` builds the package, installs the packed tarball into a temporary npm prefix, runs `archon --version`, starts `archon --no-open`, fetches the app shell and an API route, then shuts it down.
+1. **Plan**: write a title and description for the feature or task
+2. **Build**: Archon runs your configured AI tool in a new git worktree and streams progress back to the UI in real time
+3. **Review**: an agent reviews the resulting changes and suggests fixes that you can inspect and accept manually
 
 ## Project Setup
 
@@ -101,13 +77,13 @@ After Archon starts, create a project from the UI:
 
 1. Click `Create project`
 2. Enter a project name and repository path
-3. Optionally click `Auto-config` to inspect top-level repo files and fill any empty setup, service, or worktree sync settings
+3. Optionally click `Auto-config` to fill any empty setup, service, or worktree sync settings
 4. Optionally open `Advanced settings` to review or edit setup, service, worktree sync, and IDE settings
 5. Save the project, select it in the project switcher, and create tickets inside that project
 
-## Project configuration
+## Project Configuration
 
-Archon stores repository and run settings per project in its database. Use the project form in the UI to configure each project.
+Use the project form in the UI to configure how Archon prepares worktrees and runs project-specific services.
 
 ### Required fields
 
@@ -116,7 +92,7 @@ Archon stores repository and run settings per project in its database. Use the p
 | `Project name` | The label shown in the project switcher, such as `Platform API` or `Marketing Site` |
 | `Repository path` | Any path inside the target git repository; Archon resolves it to the repo root before saving |
 
-`Auto-config` is available in both the create and edit project modals. It uses the currently selected global tool, reads only top-level README/config files, and fills only empty `Setup commands`, `Services`, and `Worktree sync` sections. It never changes `IDE command`.
+`Auto-config` is available in both the create and edit project modals. It fills only empty `Setup commands`, `Services`, and `Worktree sync` sections, and it never changes `IDE command`.
 
 ### Advanced fields
 
@@ -128,10 +104,6 @@ Archon stores repository and run settings per project in its database. Use the p
 | `cwd` | Optional working directory for a service, relative to the worktree root. For example, use `client` for a frontend dev server or `server` for an API process. Leave it blank to run from the worktree root. |
 | `IDE command` | Optional command to open the finished worktree in your editor after services start, such as `code --reuse-window` or `idea`. |
 
-Worktree sync entries are stored as `{ source, target?, mode }` objects. `source` is required, `target` is optional and defaults to the same path, and `mode` is either `copy` or `symlink`.
-
-Service entries are stored as `{ cmd, cwd }` objects. `cmd` is required, while `cwd` is optional.
-
 ### Example project setup
 
 ```text
@@ -158,7 +130,7 @@ IDE command: code --reuse-window
 
 Each ticket gets its own worktree and branch derived from the ticket title, using the active project's repository settings. Archon reuses an existing local branch when one already exists; otherwise it creates a new branch for the worktree.
 
-## Data And Migration
+## Data Storage
 
 Archon keeps runtime state out of the installed package tree.
 
@@ -171,54 +143,7 @@ Default database locations:
 
 You can override the database location with `DB_PATH`.
 
-### Migrating from an existing dev database
-
-Older local development runs may already have data in one of these files:
+## Development And Maintenance
 
-- `server/archon-dev.db`
-- `server/archon.db`
-
-Recommended manual migration flow:
-
-1. Stop all Archon dev and production processes.
-2. Back up the source database and any current production database.
-3. Create the production app-data directory if it does not exist.
-4. Copy the chosen development database to the production database path.
-5. If SQLite sidecar files such as `-wal` or `-shm` exist, only copy them while Archon is fully stopped.
-6. Start Archon normally and let its startup schema checks apply any missing migrations.
-
-If you want to run production Archon against an existing database temporarily, launch it with:
-
-```bash
-DB_PATH=/path/to/archon-dev.db archon
-```
-
-## Release Process
-
-Archon uses a manual GitHub Actions release workflow.
-
-### GitHub setup
-
-1. Publish the npm package scope or package name from the npm account or organization that owns `@straiffi/archon`.
-2. Add an `NPM_TOKEN` repository secret in GitHub with publish access to that package.
-3. Run the `Release` workflow from the `main` branch.
-4. Choose one of `patch`, `minor`, or `major` for `release_type`.
-
-The workflow will:
-
-1. install dependencies
-2. run type checks, lint, tests, build, tarball validation, and packaged-install smoke checks
-3. run `npm version <release_type>`
-4. publish with `npm publish --access public`
-5. push the version commit and git tag back to GitHub
-
-### Local release dry run
-
-Before running the workflow, you can validate the release path locally with:
-
-```bash
-npm install
-npm run build
-npm run smoke:package
-npm pack --dry-run
-```
+- Contributor workflow: [`DEVELOPMENT.md`](https://github.com/Straiffi/Archon/blob/main/DEVELOPMENT.md)
+- Release workflow: [`RELEASING.md`](https://github.com/Straiffi/Archon/blob/main/RELEASING.md)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@straiffi/archon",
-  "version": "1.0.5",
+  "version": "1.0.7",
   "private": false,
   "type": "module",
   "workspaces": [