speexor 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/API-REFERENCE.md +201 -0
- package/ARCHITECTURE.md +548 -0
- package/CHANGELOG.md +52 -0
- package/CODE-OF-CONDUCT.md +83 -0
- package/CONTRIBUTING.md +98 -0
- package/FAQ.md +105 -0
- package/LICENSE.md +21 -0
- package/PUBLISH.md +77 -0
- package/README.md +179 -0
- package/REFACTOR-LOG.md +40 -0
- package/ROADMAP.md +78 -0
- package/SECURITY.md +79 -0
- package/SUMMARY.md +46 -0
- package/TESTING.md +140 -0
- package/dist/agent-5D3BVWNK.js +37 -0
- package/dist/agent-5D3BVWNK.js.map +1 -0
- package/dist/chunk-2F66BZYJ.js +212 -0
- package/dist/chunk-2F66BZYJ.js.map +1 -0
- package/dist/chunk-5NA2TFPG.js +3 -0
- package/dist/chunk-5NA2TFPG.js.map +1 -0
- package/dist/chunk-B7WLHC4W.js +666 -0
- package/dist/chunk-B7WLHC4W.js.map +1 -0
- package/dist/chunk-SXALZEOJ.js +345 -0
- package/dist/chunk-SXALZEOJ.js.map +1 -0
- package/dist/cli/index.d.ts +1 -0
- package/dist/cli/index.js +287 -0
- package/dist/cli/index.js.map +1 -0
- package/dist/core/index.d.ts +31 -0
- package/dist/core/index.js +4 -0
- package/dist/core/index.js.map +1 -0
- package/dist/index.d.ts +75 -0
- package/dist/index.js +205 -0
- package/dist/index.js.map +1 -0
- package/dist/plugins/index.d.ts +6 -0
- package/dist/plugins/index.js +3 -0
- package/dist/plugins/index.js.map +1 -0
- package/dist/types-0q_okI2g.d.ts +205 -0
- package/docs/PRD01.md +264 -0
- package/docs/PRD02.md +299 -0
- package/docs/PRD03.md +0 -0
- package/docs/PRD04.md +349 -0
- package/docs/PRD05.md +312 -0
- package/docs/SETUP.md +94 -0
- package/docs/TROUBLESHOOTING.md +113 -0
- package/examples/basic.yaml +61 -0
- package/package.json +102 -0
- package/schema/config.schema.json +119 -0
- package/speexor.config.yaml.example +30 -0
package/CONTRIBUTING.md
ADDED
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# Contributing to Speexor
|
|
2
|
+
|
|
3
|
+
Thank you for considering contributing to Speexor! This document outlines our development workflow, standards, and expectations.
|
|
4
|
+
|
|
5
|
+
## Code of Conduct
|
|
6
|
+
|
|
7
|
+
All contributors must adhere to our [Code of Conduct](./CODE-OF-CONDUCT.md).
|
|
8
|
+
|
|
9
|
+
## Getting Started
|
|
10
|
+
|
|
11
|
+
### Prerequisites
|
|
12
|
+
- Node.js >= 18.0.0
|
|
13
|
+
- pnpm (recommended) or npm
|
|
14
|
+
- TypeScript basic knowledge
|
|
15
|
+
|
|
16
|
+
### Setup
|
|
17
|
+
```bash
|
|
18
|
+
# Clone the monorepo
|
|
19
|
+
git clone https://github.com/superdevids/speexjs.git
|
|
20
|
+
cd speexjs
|
|
21
|
+
|
|
22
|
+
# Install dependencies
|
|
23
|
+
pnpm install
|
|
24
|
+
|
|
25
|
+
# Navigate to speexor
|
|
26
|
+
cd packages/speexor
|
|
27
|
+
|
|
28
|
+
# Build the package
|
|
29
|
+
pnpm build
|
|
30
|
+
|
|
31
|
+
# Run tests
|
|
32
|
+
pnpm test
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## Development Workflow
|
|
36
|
+
|
|
37
|
+
### Branch Naming
|
|
38
|
+
- `feat/<description>` — New features
|
|
39
|
+
- `fix/<description>` — Bug fixes
|
|
40
|
+
- `docs/<description>` — Documentation changes
|
|
41
|
+
- `refactor/<description>` — Code refactoring
|
|
42
|
+
- `chore/<description>` — Maintenance tasks
|
|
43
|
+
|
|
44
|
+
### Commit Messages
|
|
45
|
+
We follow conventional commits:
|
|
46
|
+
- `feat:` — New feature
|
|
47
|
+
- `fix:` — Bug fix
|
|
48
|
+
- `docs:` — Documentation
|
|
49
|
+
- `refactor:` — Code refactoring
|
|
50
|
+
- `test:` — Test changes
|
|
51
|
+
- `chore:` — Maintenance
|
|
52
|
+
|
|
53
|
+
### Before Submitting
|
|
54
|
+
1. Run `pnpm lint` — Biome will check code quality
|
|
55
|
+
2. Run `pnpm typecheck` — TypeScript will verify types
|
|
56
|
+
3. Run `pnpm test` — Vitest will run tests
|
|
57
|
+
4. Run `pnpm build` — tsup will build the package
|
|
58
|
+
|
|
59
|
+
## Code Standards
|
|
60
|
+
|
|
61
|
+
### TypeScript
|
|
62
|
+
- Strict mode enabled
|
|
63
|
+
- ESM only (`import`/`export`)
|
|
64
|
+
- No `any` types (strict mode)
|
|
65
|
+
- Use interfaces over type aliases for object types
|
|
66
|
+
- All public APIs must have JSDoc comments
|
|
67
|
+
|
|
68
|
+
### Plugin Architecture
|
|
69
|
+
When adding a new plugin:
|
|
70
|
+
1. Define interface in `src/core/types.ts` (if new slot) or implement existing interface
|
|
71
|
+
2. Create implementation in `src/plugins/<slot>/`
|
|
72
|
+
3. Add to `src/plugins/index.ts` `loadAllPlugins()` function
|
|
73
|
+
4. Write unit tests for the plugin contract
|
|
74
|
+
|
|
75
|
+
### Testing
|
|
76
|
+
- Unit tests with Vitest
|
|
77
|
+
- Integration tests for plugin contracts
|
|
78
|
+
- Aim for >80% coverage
|
|
79
|
+
- Tests go in `tests/` directory
|
|
80
|
+
|
|
81
|
+
### Documentation
|
|
82
|
+
- Keep README.md and docs up to date
|
|
83
|
+
- Document new features in the appropriate docs file
|
|
84
|
+
- Add JSDoc comments to public APIs
|
|
85
|
+
|
|
86
|
+
## Pull Request Process
|
|
87
|
+
1. Create a feature branch from `dev`
|
|
88
|
+
2. Implement your changes
|
|
89
|
+
3. Run the full CI suite locally
|
|
90
|
+
4. Push and create a PR against `dev`
|
|
91
|
+
5. Ensure CI passes on GitHub
|
|
92
|
+
6. Request review from maintainers
|
|
93
|
+
|
|
94
|
+
## Plugin Development Guide
|
|
95
|
+
...
|
|
96
|
+
|
|
97
|
+
## Questions?
|
|
98
|
+
Open an issue at https://github.com/superdevids/speexjs/issues
|
package/FAQ.md
ADDED
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
# Frequently Asked Questions
|
|
2
|
+
|
|
3
|
+
## General
|
|
4
|
+
|
|
5
|
+
### What is Speexor?
|
|
6
|
+
Speexor is an Agent Orchestrator that spawns and manages multiple AI coding agents in parallel across one or more git repositories. Each agent runs in an isolated git worktree, handles one task autonomously, and can automatically respond to CI failures and PR comments.
|
|
7
|
+
|
|
8
|
+
### Why not just use AgentWrapper (AO)?
|
|
9
|
+
Speexor was inspired by AO but rebuilt to be:
|
|
10
|
+
- **Agent-agnostic** — not tied to Claude Code; supports OpenCode, Aider, Codex equally
|
|
11
|
+
- **Multi-provider** — route tasks to different AI providers per project
|
|
12
|
+
- **Native OpenCode support** — first-class integration with your vibe coding workflow
|
|
13
|
+
- **Built for solo devs** — dashboard, auto-reactions, cost tracking out of the box
|
|
14
|
+
|
|
15
|
+
### Is Speexor production-ready?
|
|
16
|
+
Version 0.1.0 is a foundation release. The core architecture is solid, but we recommend:
|
|
17
|
+
- Testing with non-critical repositories first
|
|
18
|
+
- Keeping auto-merge disabled (`approved-and-green.auto: false`)
|
|
19
|
+
- Reviewing agent output before merging PRs
|
|
20
|
+
|
|
21
|
+
## Installation & Setup
|
|
22
|
+
|
|
23
|
+
### What are the prerequisites?
|
|
24
|
+
- Node.js >= 18.0.0
|
|
25
|
+
- Git >= 2.30 (for worktree support)
|
|
26
|
+
- GitHub CLI (`gh`) — for GitHub integration
|
|
27
|
+
- tmux >= 3.0 — for tmux runtime (Unix only)
|
|
28
|
+
- At least one AI coding agent CLI (OpenCode, Claude Code, Aider, or Codex)
|
|
29
|
+
|
|
30
|
+
### How do I install Speexor?
|
|
31
|
+
```bash
|
|
32
|
+
npm install -g @speexjs/speexor
|
|
33
|
+
# or
|
|
34
|
+
pnpm add -g @speexjs/speexor
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
### Can I use Speexor on Windows?
|
|
38
|
+
Yes! On Windows, the Process runtime is used automatically (tmux is not available). All features work except live terminal streaming in the dashboard.
|
|
39
|
+
|
|
40
|
+
## Configuration
|
|
41
|
+
|
|
42
|
+
### Where is the config file?
|
|
43
|
+
Speexor looks for `speexor.config.yaml` in the current directory. Run `speexor start <repo-url>` to generate one automatically.
|
|
44
|
+
|
|
45
|
+
### Can I manage multiple projects?
|
|
46
|
+
Yes. The config supports multiple projects under the `projects` array. Each project can have its own provider routing and reaction rules.
|
|
47
|
+
|
|
48
|
+
### What happens if CI fails?
|
|
49
|
+
By default, Speexor automatically spawns a fix agent when CI fails (up to 3 retries). If it still fails after 3 retries, it escalates for human attention.
|
|
50
|
+
|
|
51
|
+
## Usage
|
|
52
|
+
|
|
53
|
+
### How do I spawn an agent?
|
|
54
|
+
```bash
|
|
55
|
+
speexor agent spawn --task 42 --agent opencode
|
|
56
|
+
```
|
|
57
|
+
This creates a worktree, starts a runtime session, and launches the agent.
|
|
58
|
+
|
|
59
|
+
### How do I check agent status?
|
|
60
|
+
```bash
|
|
61
|
+
speexor list
|
|
62
|
+
# Or open the dashboard at http://localhost:3000
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
### Can I run multiple agents in parallel?
|
|
66
|
+
Yes. Each agent gets its own git worktree and runtime session. Configure `concurrentLimit` in the project config to limit parallel agents.
|
|
67
|
+
|
|
68
|
+
### How do I stop an agent?
|
|
69
|
+
```bash
|
|
70
|
+
speexor stop <session-id>
|
|
71
|
+
```
|
|
72
|
+
This kills the agent process, cleans up the worktree, and removes the session.
|
|
73
|
+
|
|
74
|
+
## Troubleshooting
|
|
75
|
+
|
|
76
|
+
### "speexor.config.yaml not found"
|
|
77
|
+
Run `speexor start <repo-url>` first to initialize the project, or manually create the config file.
|
|
78
|
+
|
|
79
|
+
### "tmux not available"
|
|
80
|
+
Install tmux (`brew install tmux` on macOS, `sudo apt install tmux` on Linux). On Windows, Speexor uses Process runtime automatically.
|
|
81
|
+
|
|
82
|
+
### "GitHub CLI (gh) not found"
|
|
83
|
+
Install from https://cli.github.com/ and authenticate with `gh auth login`.
|
|
84
|
+
|
|
85
|
+
### Dashboard not loading?
|
|
86
|
+
Check if port 3000 is available. Use `speexor start --port 4000` to use a different port.
|
|
87
|
+
|
|
88
|
+
## Development
|
|
89
|
+
|
|
90
|
+
### How do I add a new agent adapter?
|
|
91
|
+
1. Create a file in `src/plugins/agent/`
|
|
92
|
+
2. Implement the `AgentPlugin` interface
|
|
93
|
+
3. Add it to `src/plugins/index.ts` `loadAllPlugins()`
|
|
94
|
+
|
|
95
|
+
### How do I create a new plugin?
|
|
96
|
+
1. Define the interface in `src/core/types.ts` (if new slot)
|
|
97
|
+
2. Create the implementation in `src/plugins/<slot>/`
|
|
98
|
+
3. Add to plugin loader
|
|
99
|
+
|
|
100
|
+
### How do I run tests?
|
|
101
|
+
```bash
|
|
102
|
+
pnpm test # Run all tests
|
|
103
|
+
pnpm test:watch # Watch mode
|
|
104
|
+
pnpm test:coverage # With coverage
|
|
105
|
+
```
|
package/LICENSE.md
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Aditya (@superdevids)
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/PUBLISH.md
ADDED
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
# Publishing Speexor
|
|
2
|
+
|
|
3
|
+
This document describes the process for publishing `@speexjs/speexor` to npm.
|
|
4
|
+
|
|
5
|
+
## Prerequisites
|
|
6
|
+
- npm account with access to `@speexjs` organization
|
|
7
|
+
- GitHub repository write access
|
|
8
|
+
- Clean working tree (no uncommitted changes)
|
|
9
|
+
|
|
10
|
+
## Version Bumping
|
|
11
|
+
|
|
12
|
+
We follow [Semantic Versioning](https://semver.org/):
|
|
13
|
+
- **Patch** (`0.1.0` → `0.1.1`): Bug fixes, minor changes
|
|
14
|
+
- **Minor** (`0.1.0` → `0.2.0`): New features, backwards compatible
|
|
15
|
+
- **Major** (`0.1.0` → `1.0.0`): Breaking changes
|
|
16
|
+
|
|
17
|
+
## Pre-Publish Checklist
|
|
18
|
+
|
|
19
|
+
- [ ] All tests pass: `pnpm test`
|
|
20
|
+
- [ ] TypeScript compiles: `pnpm typecheck`
|
|
21
|
+
- [ ] Linter passes: `pnpm lint`
|
|
22
|
+
- [ ] Build succeeds: `pnpm build`
|
|
23
|
+
- [ ] CHANGELOG.md updated
|
|
24
|
+
- [ ] Version bumped in package.json
|
|
25
|
+
- [ ] Git tag created
|
|
26
|
+
- [ ] Docs updated (README, architecture, etc.)
|
|
27
|
+
|
|
28
|
+
## Publishing Steps
|
|
29
|
+
|
|
30
|
+
### 1. Update Version
|
|
31
|
+
```bash
|
|
32
|
+
# From the speexor package directory
|
|
33
|
+
pnpm version patch # or minor, or major
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### 2. Update Changelog
|
|
37
|
+
Update `CHANGELOG.md` with the new version, date, and changes.
|
|
38
|
+
|
|
39
|
+
### 3. Build
|
|
40
|
+
```bash
|
|
41
|
+
pnpm build
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
### 4. Publish to npm
|
|
45
|
+
```bash
|
|
46
|
+
pnpm publish --access public
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
### 5. Tag and Push
|
|
50
|
+
```bash
|
|
51
|
+
git tag speexor-v0.1.0
|
|
52
|
+
git push --tags
|
|
53
|
+
git push origin main
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
### 6. Create GitHub Release
|
|
57
|
+
- Go to https://github.com/superdevids/speexjs/releases
|
|
58
|
+
- Draft a new release
|
|
59
|
+
- Use the git tag as version
|
|
60
|
+
- Copy changelog entry as release notes
|
|
61
|
+
- Attach any relevant binaries
|
|
62
|
+
|
|
63
|
+
## npm Package Contents
|
|
64
|
+
|
|
65
|
+
The published package includes:
|
|
66
|
+
- `dist/` — Compiled ESM + type declarations
|
|
67
|
+
- `schema/` — JSON Schema for config
|
|
68
|
+
- `examples/` — Example configurations
|
|
69
|
+
- `speexor.config.yaml.example` — Config template
|
|
70
|
+
- `*.md` — Documentation files
|
|
71
|
+
|
|
72
|
+
## CI/CD
|
|
73
|
+
|
|
74
|
+
Publishing can also be automated via GitHub Actions:
|
|
75
|
+
- Trigger: pushing a tag matching `speexor-v*`
|
|
76
|
+
- Steps: install → build → test → publish
|
|
77
|
+
- Secrets: `NPM_TOKEN` must be configured in GitHub repository secrets
|
package/README.md
ADDED
|
@@ -0,0 +1,179 @@
|
|
|
1
|
+
# @speexjs/speexor
|
|
2
|
+
|
|
3
|
+
**Agent Orchestrator for multi-AI coding agents across repositories**
|
|
4
|
+
|
|
5
|
+
[](https://www.npmjs.com/package/@speexjs/speexor)
|
|
6
|
+
[](https://opensource.org/licenses/MIT)
|
|
7
|
+
[](https://nodejs.org)
|
|
8
|
+
[](https://www.typescriptlang.org/)
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Overview
|
|
13
|
+
|
|
14
|
+
Speexor is an **agent orchestrator** purpose-built for teams and solo developers running multiple AI coding agents across several repositories. Inspired by the architecture of AgentWrapper AO but designed to be **agent-agnostic** and **multi-provider** from day one, Speexor lets you dispatch, monitor, and manage sessions from OpenCode, Claude Code, Aider, and Codex — all through a single CLI and YAML config.
|
|
15
|
+
|
|
16
|
+
Coordinating multiple coding agents manually is error-prone and slow. Speexor solves this with a **7-plugin slot architecture** that separates agent adapters, runtime backends, workspace management, issue tracking, SCM operations, notifications, and terminal I/O into clean, swappable modules. Git worktree isolation keeps each agent session on its own branch without polluting your working tree.
|
|
17
|
+
|
|
18
|
+
Speexor ships with a built-in **HTTP dashboard**, a **reaction engine** for automated CI-fix loops, JSON-file session persistence, and two runtime backends — `tmux` on Unix and `Process` on Windows — so it works wherever you do.
|
|
19
|
+
|
|
20
|
+
> **Status:** v0.1.0 — Early release. The plugin API and core commands are stable; breaking changes are possible before 1.0.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## Key Features
|
|
25
|
+
|
|
26
|
+
- **Parallel Agent Dispatch** — Spawn multiple coding agents (OpenCode, Claude Code, Aider, Codex) across different repositories simultaneously
|
|
27
|
+
- **Multi-Provider Routing** — Configure primary and fallback AI providers per project with concurrent-limit controls
|
|
28
|
+
- **Git Worktree Isolation** — Every agent task operates on its own isolated `git worktree` branch — zero interference with your main workspace
|
|
29
|
+
- **Reaction Engine** — Automatically detect CI failures, PR review changes, and approvals; trigger fix, notify, or escalate actions with configurable retries
|
|
30
|
+
- **Built-in HTTP Dashboard** — Monitor sessions, worktrees, and agent status in real time (Node.js built-in `http` module, no external dependencies)
|
|
31
|
+
- **7-Plugin Slot Architecture** — Swap or extend every layer: agent adapters, runtimes, workspace, tracker, SCM, notifier, and terminal
|
|
32
|
+
- **Cross-Platform Runtimes** — `tmux` for Unix, `Process` for Windows — pick the backend that matches your OS
|
|
33
|
+
- **JSON-File Persistence** — Session state, worktrees, and runtimes persist to `.speexor/state.json` automatically
|
|
34
|
+
- **Zod-Validated Config** — YAML configuration validated at load with clear error messages for every field
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## Quick Start
|
|
39
|
+
|
|
40
|
+
```bash
|
|
41
|
+
# 1. Install globally
|
|
42
|
+
npm install -g @speexjs/speexor
|
|
43
|
+
|
|
44
|
+
# 2. Initialize a project (creates speexor.config.yaml + starts dashboard)
|
|
45
|
+
speexor start https://github.com/your-org/your-repo --port 3000
|
|
46
|
+
|
|
47
|
+
# 3. (Optional) Edit speexor.config.yaml to set provider, reactions, etc.
|
|
48
|
+
|
|
49
|
+
# 4. Spawn an agent for a GitHub issue
|
|
50
|
+
speexor agent spawn --task 42
|
|
51
|
+
|
|
52
|
+
# 5. Monitor progress
|
|
53
|
+
speexor list
|
|
54
|
+
speexor logs <session-id> --follow
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
**Prerequisites:**
|
|
58
|
+
- Node.js >= 18.0.0
|
|
59
|
+
- `git` installed and authenticated
|
|
60
|
+
- One or more AI coding agents installed (`opencode`, `claude-code`, `aider`, `codex`)
|
|
61
|
+
- `gh` CLI (GitHub CLI) authenticated — required for tracker and SCM plugins
|
|
62
|
+
- `tmux` installed on Unix (optional — falls back to Process runtime)
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## Configuration
|
|
67
|
+
|
|
68
|
+
Speexor is configured via `speexor.config.yaml` (or `.speexor.yaml`, `speexor.yaml`) in your project root.
|
|
69
|
+
|
|
70
|
+
Create one with `speexor start <repo>` or manually:
|
|
71
|
+
|
|
72
|
+
```yaml
|
|
73
|
+
version: "1"
|
|
74
|
+
|
|
75
|
+
projects:
|
|
76
|
+
- name: my-app
|
|
77
|
+
repository: https://github.com/your-org/my-app
|
|
78
|
+
provider:
|
|
79
|
+
primary: opencode
|
|
80
|
+
fallback:
|
|
81
|
+
- claude-code
|
|
82
|
+
- aider
|
|
83
|
+
concurrentLimit: 3
|
|
84
|
+
|
|
85
|
+
reactions:
|
|
86
|
+
ci-failed:
|
|
87
|
+
auto: true
|
|
88
|
+
action: fix
|
|
89
|
+
retries: 3
|
|
90
|
+
escalateAfter: 30
|
|
91
|
+
changes-requested:
|
|
92
|
+
auto: true
|
|
93
|
+
action: fix
|
|
94
|
+
retries: 2
|
|
95
|
+
escalateAfter: 60
|
|
96
|
+
approved-and-green:
|
|
97
|
+
auto: false
|
|
98
|
+
action: notify
|
|
99
|
+
retries: 0
|
|
100
|
+
escalateAfter: 0
|
|
101
|
+
|
|
102
|
+
- name: my-lib
|
|
103
|
+
repository: https://github.com/your-org/my-lib
|
|
104
|
+
provider:
|
|
105
|
+
primary: claude-code
|
|
106
|
+
concurrentLimit: 2
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
See the full schema with `speexor config-help`.
|
|
110
|
+
|
|
111
|
+
---
|
|
112
|
+
|
|
113
|
+
## Plugin Architecture
|
|
114
|
+
|
|
115
|
+
Speexor defines **7 plugin slots**. Each slot can have multiple implementations registered at startup.
|
|
116
|
+
|
|
117
|
+
| Slot | Interface | Built-in Implementations |
|
|
118
|
+
|------|-----------|--------------------------|
|
|
119
|
+
| `agent` | `spawn()`, `sendInput()`, `getStatus()`, `kill()` | OpenCode, Claude Code, Aider, Codex |
|
|
120
|
+
| `runtime` | `createSession()`, `sendInput()`, `getOutput()`, `getLiveStream()` | `tmux` (Unix), `Process` (Windows) |
|
|
121
|
+
| `workspace` | `createWorktree()`, `removeWorktree()`, `cleanupStale()` | `GitWorktreeWorkspace` |
|
|
122
|
+
| `tracker` | `fetchIssues()`, `getIssue()`, `onEvent()` | `GitHubTracker` |
|
|
123
|
+
| `scm` | `createBranch()`, `commitAndPush()`, `createPR()`, `mergePR()` | `GitHubSCM` (via `gh` CLI) |
|
|
124
|
+
| `notifier` | `notify(level, title, message)` | `DesktopNotifier` |
|
|
125
|
+
| `terminal` | `attach()`, `write()`, `onData()` | _(interface defined, implementation optional)_ |
|
|
126
|
+
|
|
127
|
+
Plugins implement `PluginModule` with a standard lifecycle (`initialize` / `destroy`) and receive typed access to the config, event bus, and logger through `PluginContext`.
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
## CLI Reference
|
|
132
|
+
|
|
133
|
+
```
|
|
134
|
+
speexor <command> [options]
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
| Command | Description |
|
|
138
|
+
|---------|-------------|
|
|
139
|
+
| `start [repo]` | Initialize a project config and start the HTTP dashboard. Options: `--port`, `--name`, `--no-dashboard` |
|
|
140
|
+
| `agent spawn --task <id>` | Spawn an agent for a GitHub issue. Options: `--agent` (opencode, claude-code, aider, codex) |
|
|
141
|
+
| `list` | List all projects and active agent statuses |
|
|
142
|
+
| `stop <session-id>` | Stop an agent session safely |
|
|
143
|
+
| `logs <session-id>` | Tail logs for an agent session. Options: `--follow`, `--lines` |
|
|
144
|
+
| `config-help` | Print the full YAML config schema reference |
|
|
145
|
+
|
|
146
|
+
---
|
|
147
|
+
|
|
148
|
+
## Examples
|
|
149
|
+
|
|
150
|
+
A complete multi-project configuration with reaction rules is available in [`examples/basic.yaml`](./examples/basic.yaml).
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## Documentation
|
|
155
|
+
|
|
156
|
+
- [Architecture & Design (PRD 01)](./docs/PRD01.md)
|
|
157
|
+
- [Technical Spec (PRD 02)](./docs/PRD02.md)
|
|
158
|
+
- [Behavior Spec (PRD 03)](./docs/PRD03.md)
|
|
159
|
+
- [Design Docs (PRD 04)](./docs/PRD04.md)
|
|
160
|
+
- [Specification (PRD 05)](./docs/PRD05.md)
|
|
161
|
+
- [Setup Guide](./docs/SETUP.md)
|
|
162
|
+
- [Troubleshooting](./docs/TROUBLESHOOTING.md)
|
|
163
|
+
|
|
164
|
+
---
|
|
165
|
+
|
|
166
|
+
## Why Speexor?
|
|
167
|
+
|
|
168
|
+
Speexor was created because existing agent orchestration tools were either tied to a single AI provider or required complex infrastructure. Speexor is:
|
|
169
|
+
|
|
170
|
+
- **Agent-agnostic** — run OpenCode, Claude Code, Aider, or Codex with the same CLI
|
|
171
|
+
- **Lightweight** — zero external runtime dependencies beyond your agents and git
|
|
172
|
+
- **Repository-native** — works with your existing GitHub repos, issues, and PR workflows
|
|
173
|
+
- **Extensible** — swap any plugin slot with your own implementation
|
|
174
|
+
|
|
175
|
+
---
|
|
176
|
+
|
|
177
|
+
## License
|
|
178
|
+
|
|
179
|
+
[MIT](LICENSE) © SuperDevIds
|
package/REFACTOR-LOG.md
ADDED
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# Refactoring Log
|
|
2
|
+
|
|
3
|
+
> Tracking significant architectural changes and refactoring decisions for Speexor.
|
|
4
|
+
|
|
5
|
+
## [2026-06-30] — Initial Implementation (v0.1.0)
|
|
6
|
+
|
|
7
|
+
### Context
|
|
8
|
+
Initial implementation of the Agent Orchestrator based on PRD01.md. Built from scratch as `packages/speexor` in the speexjs monorepo.
|
|
9
|
+
|
|
10
|
+
### Decisions
|
|
11
|
+
1. **Plugin Architecture**: 7 fixed plugin slots (agent, runtime, workspace, tracker, scm, notifier, terminal) — inspired by AgentWrapper AO but with cleaner interface segregation
|
|
12
|
+
2. **Monorepo as Single Package**: Unlike AO's multi-package structure, v1 lives in a single `@speexjs/speexor` package with internal module separation. This reduces initial complexity while maintaining clean module boundaries via `src/` directories.
|
|
13
|
+
3. **TypeScript ESM Only**: No CJS support. The rest of speexjs ecosystem is ESM-first.
|
|
14
|
+
4. **Built-in HTTP Dashboard**: Using Node.js built-in `http` module instead of Express/NestJS to keep dependencies minimal for v1.
|
|
15
|
+
5. **No Dynamic Plugin Loading**: All built-in plugins are hardcoded in `loadAllPlugins()`. Dynamic loading from external packages is deferred to v2.
|
|
16
|
+
6. **Synchronous File I/O for State**: `SessionStore` uses `readFileSync`/`writeFileSync` for simplicity. Will migrate to async when performance requires it.
|
|
17
|
+
|
|
18
|
+
### Rebrand: Konduktor → Speexor
|
|
19
|
+
The project was initially codenamed "Konduktor" internally. After initial implementation, renamed to "Speexor" to align with the SpeexJS brand ecosystem. All code identifiers, CLI names, config files, and documentation were updated.
|
|
20
|
+
|
|
21
|
+
### Patterns Established
|
|
22
|
+
- `PluginModule` base interface with `initialize()`/`destroy()` lifecycle
|
|
23
|
+
- Debug namespace pattern: `speexor:<module>:<submodule>`
|
|
24
|
+
- Session ID format: `<prefix>-<task-id>-<timestamp>`
|
|
25
|
+
- Worktree branch format: `speexor/<task-id>`
|
|
26
|
+
- Config directory: `.speexor/` at project root
|
|
27
|
+
|
|
28
|
+
### Technical Debt
|
|
29
|
+
- No test files yet (vitest configured but no tests written)
|
|
30
|
+
- `getLiveStream()` throws "not implemented" in both runtime plugins
|
|
31
|
+
- Terminal plugin has no implementation
|
|
32
|
+
- Dashboard HTML is inline (hard to maintain)
|
|
33
|
+
- Session store uses synchronous I/O
|
|
34
|
+
- No dynamic plugin discovery mechanism
|
|
35
|
+
|
|
36
|
+
### What Worked Well
|
|
37
|
+
- TypeScript strict mode caught several type errors during initial build
|
|
38
|
+
- Event bus pattern cleanly decouples lifecycle from dashboard
|
|
39
|
+
- Zod validation provides clear error messages for misconfigured YAML
|
|
40
|
+
- Plugin interface design allows adding new providers without touching core
|
package/ROADMAP.md
ADDED
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# Roadmap
|
|
2
|
+
|
|
3
|
+
> Development roadmap for Speexor — Agent Orchestrator.
|
|
4
|
+
|
|
5
|
+
## Current Release: v0.1.0 (Foundation)
|
|
6
|
+
|
|
7
|
+
Completed milestones:
|
|
8
|
+
- M0: Monorepo setup, core lifecycle, plugin contract types
|
|
9
|
+
- M1: Single-agent E2E (OpenCode + tmux/process + git worktree)
|
|
10
|
+
- M2: GitHub integration (tracker + SCM + reaction engine)
|
|
11
|
+
- M3: Multi-agent adapters (Claude Code, Aider, Codex)
|
|
12
|
+
- M4: Dashboard MVP (REST API + HTML frontend)
|
|
13
|
+
|
|
14
|
+
## Upcoming Milestones
|
|
15
|
+
|
|
16
|
+
### M5 — Cost & Provider Panel (Target: Q3 2026)
|
|
17
|
+
- Multi-provider routing config
|
|
18
|
+
- Cost tracking per provider per project
|
|
19
|
+
- Usage analytics dashboard panel
|
|
20
|
+
- Provider fallback configuration UI
|
|
21
|
+
|
|
22
|
+
### M6 — Polish & Documentation (Target: Q3 2026)
|
|
23
|
+
- Comprehensive test suite (Vitest + integration tests)
|
|
24
|
+
- CI/CD pipeline setup
|
|
25
|
+
- Open-source readiness review
|
|
26
|
+
- Performance benchmarking
|
|
27
|
+
|
|
28
|
+
### M7 — Recursive Task Decomposition (Target: Q4 2026)
|
|
29
|
+
- DAG-based task breakdown
|
|
30
|
+
- Parallel sub-agent spawning
|
|
31
|
+
- Task dependency resolution
|
|
32
|
+
- Progress tracking across sub-tasks
|
|
33
|
+
- Context window management
|
|
34
|
+
|
|
35
|
+
### M8 — Real-Time Terminal (Target: Q4 2026)
|
|
36
|
+
- WebSocket-based live terminal streaming
|
|
37
|
+
- xterm.js integration in dashboard
|
|
38
|
+
- Terminal resize and interactive input
|
|
39
|
+
- Session recording and replay
|
|
40
|
+
|
|
41
|
+
### M9 — Extension Marketplace (Target: Q1 2027)
|
|
42
|
+
- Extension manifest format
|
|
43
|
+
- Plugin SDK (@speexor/sdk)
|
|
44
|
+
- Marketplace index (GitHub-based registry)
|
|
45
|
+
- Extension install/update/remove lifecycle
|
|
46
|
+
- Permission system for extensions
|
|
47
|
+
|
|
48
|
+
### M10 — Advanced Security & Compliance (Target: Q1 2027)
|
|
49
|
+
- End-to-end encryption for cross-device sync
|
|
50
|
+
- Secret scanning in agent output
|
|
51
|
+
- Audit logging for all agent actions
|
|
52
|
+
- Air-gapped mode
|
|
53
|
+
- SBOM generation
|
|
54
|
+
|
|
55
|
+
### M11 — Multi-Host Distribution (Target: Q2 2027)
|
|
56
|
+
- Docker runtime support
|
|
57
|
+
- Remote agent execution
|
|
58
|
+
- Load balancing across hosts
|
|
59
|
+
- Agent pool management
|
|
60
|
+
|
|
61
|
+
## Themes
|
|
62
|
+
|
|
63
|
+
### 🎯 Short-term (Q3 2026)
|
|
64
|
+
- Polish existing features
|
|
65
|
+
- Test coverage >80%
|
|
66
|
+
- Documentation completion
|
|
67
|
+
- Cost tracking
|
|
68
|
+
|
|
69
|
+
### 🚀 Medium-term (Q4 2026)
|
|
70
|
+
- Recursive task decomposition
|
|
71
|
+
- Real-time terminal streaming
|
|
72
|
+
- Advanced observability
|
|
73
|
+
|
|
74
|
+
### 🌟 Long-term (2027)
|
|
75
|
+
- Extension marketplace
|
|
76
|
+
- Plugin SDK for community
|
|
77
|
+
- Multi-host distributed execution
|
|
78
|
+
- Enterprise security features
|
package/SECURITY.md
ADDED
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
# Security Policy
|
|
2
|
+
|
|
3
|
+
## Supported Versions
|
|
4
|
+
|
|
5
|
+
| Version | Supported |
|
|
6
|
+
|---------|-----------|
|
|
7
|
+
| 0.1.x | ✅ Active development |
|
|
8
|
+
|
|
9
|
+
## Reporting a Vulnerability
|
|
10
|
+
|
|
11
|
+
Speexor handles API tokens (GitHub tokens, AI provider keys) and executes AI-generated code. Security is a top priority.
|
|
12
|
+
|
|
13
|
+
**To report a vulnerability:**
|
|
14
|
+
1. **Do NOT** open a public GitHub issue
|
|
15
|
+
2. Email: opensource@superdevids.com (or use GitHub's private vulnerability reporting)
|
|
16
|
+
3. Include a detailed description, steps to reproduce, and potential impact
|
|
17
|
+
|
|
18
|
+
You can expect:
|
|
19
|
+
- **Acknowledgment** within 48 hours
|
|
20
|
+
- **Initial assessment** within 5 business days
|
|
21
|
+
- **Fix timeline** depending on severity
|
|
22
|
+
|
|
23
|
+
## Security Practices
|
|
24
|
+
|
|
25
|
+
### Credential Management
|
|
26
|
+
- API tokens are stored in environment variables or the system keychain
|
|
27
|
+
- Secrets are never logged in plaintext
|
|
28
|
+
- GitHub tokens are reused from `gh` CLI when possible
|
|
29
|
+
- `.speexor/` directory is git-ignored (add to `.gitignore`)
|
|
30
|
+
|
|
31
|
+
### Code Execution
|
|
32
|
+
- AI agents generate and execute code in isolated git worktrees
|
|
33
|
+
- Each agent runs in its own process/tmux session
|
|
34
|
+
- Process runtime has resource limits (SIGTERM → SIGKILL after 5s)
|
|
35
|
+
- Worktrees are cleaned up on session stop or package destroy
|
|
36
|
+
|
|
37
|
+
### Network Security
|
|
38
|
+
- Dashboard server listens on localhost by default
|
|
39
|
+
- CORS is enabled (configurable in production)
|
|
40
|
+
- No telemetry or tracking
|
|
41
|
+
- No cloud dependency — fully local-first
|
|
42
|
+
|
|
43
|
+
### Data Protection
|
|
44
|
+
- Session state stored in `.speexor/state.json` (local only)
|
|
45
|
+
- Logs stored in `.speexor/logs/` (local only)
|
|
46
|
+
- No data sent to external servers except configured AI providers and GitHub API
|
|
47
|
+
- Users control which API endpoints are called
|
|
48
|
+
|
|
49
|
+
### Supply Chain Security
|
|
50
|
+
- All dependencies are pinned with exact versions
|
|
51
|
+
- pnpm lockfile for deterministic installs
|
|
52
|
+
- Regular dependency audits via `pnpm audit`
|
|
53
|
+
- Minimal runtime dependencies (12 packages)
|
|
54
|
+
|
|
55
|
+
## Security Checklist for Deployments
|
|
56
|
+
|
|
57
|
+
- [ ] AI provider API keys stored in environment variables (not config files)
|
|
58
|
+
- [ ] GitHub tokens use minimal scopes (repo, issues, pull requests)
|
|
59
|
+
- [ ] Dashboard port not exposed to public internet
|
|
60
|
+
- [ ] `.speexor/` directory added to `.gitignore`
|
|
61
|
+
- [ ] Regular dependency updates (`pnpm audit`)
|
|
62
|
+
- [ ] Agent output reviewed before auto-merge (auto-merge disabled by default)
|
|
63
|
+
|
|
64
|
+
## Third-Party Security
|
|
65
|
+
|
|
66
|
+
Speexor relies on:
|
|
67
|
+
- **GitHub CLI (`gh`)** — user's existing authentication
|
|
68
|
+
- **AI agent CLIs** — OpenCode, Claude Code, Aider, Codex — each with their own security models
|
|
69
|
+
- **tmux** (Unix) / **Process** (Windows) — for runtime isolation
|
|
70
|
+
|
|
71
|
+
Review the security documentation for each tool you use.
|
|
72
|
+
|
|
73
|
+
## Incident Response
|
|
74
|
+
|
|
75
|
+
1. **Detection** — Monitoring for unusual agent behavior or unauthorized access
|
|
76
|
+
2. **Containment** — `speexor stop <session>` to halt affected agents
|
|
77
|
+
3. **Analysis** — Review logs in `.speexor/logs/` and session state
|
|
78
|
+
4. **Recovery** — Rotate affected credentials, clean up worktrees
|
|
79
|
+
5. **Postmortem** — Document findings, update security practices
|