# tala
Agent-to-agent messaging for AI coding tools. Chat with agents across
different projects — no more relaying messages between terminals.
## Development
```bash
cargo build
cargo test
```
Pre-commit hooks require `cargo fmt --check` and clippy with `-D warnings`.
## CLI design
When creating or modifying CLI tools, follow the [Command Line Interface Guidelines](https://clig.dev/):
`verb-noun` subcommands, consistent flags (`--help`, `--version`), `=` for flag values,
meaningful exit codes, stderr for logs/stdout for data, and `--` to separate options
from positional arguments.
## Commits
Use conventional commits (`feat:`, `fix:`, etc.) — the release pipeline bumps
the version from them, and non-conventional messages silently skip releases.
## Wire protocol
The CLI↔daemon wire protocol has a `PROTOCOL_VERSION` (`src/models.rs`). Bump
it on any incompatible wire change (new required request fields, changed
message shapes); the CLI refuses commands against a mismatched daemon and
read-only commands warn. `--json` output keeps the legacy `content` field on
messages alongside `parts` for older clients.
## OpenSpec workflow
All feature work follows the OpenSpec change workflow in `openspec/` (see
`.opencode/skills/openspec-*` and `.opencode/commands/opsx-*`):
1. **Create** a change (`openspec-new-change`): proposal → delta specs → design → tasks.
2. **Implement** the change, checking off tasks as they land.
3. **Sync** the change's delta specs into main specs (`openspec-sync-specs`), then
**archive** it (`openspec-archive-change` / `openspec-bulk-archive-change`) to
`openspec/changes/archive/YYYY-MM-DD-<name>/`. Never archive without syncing first,
unless the change is superseded (document why).
4. Do the sync and archive on the feature branch, in the same PR as the implementation,
so `main` is clean at every merge. If a reviewer objects to mixing docs with code, an
immediate doc-only follow-up PR is acceptable — but open it when the code PR merges,
not later.
5. Completed-but-unarchived changes are technical debt — archive promptly; keep
`openspec list` empty and `openspec validate --all` green.
## Evaluation
E2E evaluation scenarios live in `eval/scenarios/` (see `eval/README.md` for
orchestration). They are manually orchestrated — no autonomous loop, no
commits or PRs from evals. Findings feed OpenSpec change proposals that a
human reviews.
### Tala binary selection
When communicating with other agents, use the installed `tala` resolved from
`PATH`, and verify it first with `command -v tala` and `tala --version`. Other
agents normally use that same user-facing binary; do not default to
`target/debug/tala`, which may be built from an older feature branch.
For repository development and tests, use `cargo build`, `cargo test`, and the
explicitly built `target/debug/tala` when testing the checkout itself. Set an
explicit `TALA_BIN`, verify its version, and use an isolated `TALA_HOME` when
mixing built and installed binaries so their daemon and session state cannot be
confused.