# 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 incompatible wire changes. Protocol 2 uses addressed agents, global message
IDs, typed parts and transactional SQLite storage; it has no legacy `content`
field or session aliases. Never silently import legacy identities or transcripts.
Agents select identity explicitly with TALA_AGENT or --agent, independently of
project/CWD. Inbox consumption acknowledges receipt; history and board do not.
## OpenSpec workflow
All feature work follows the OpenSpec change workflow in `openspec/` (see
`.opencode/skills/openspec-*` and `.opencode/commands/opsx-*`):
1. **Propose** a change (`openspec-propose` / `/opsx-propose`): proposal → delta specs → design → tasks.
2. **Implement** the change (`openspec-apply-change` / `/opsx-apply`), checking off tasks as they land.
Use `openspec-update-change` / `/opsx-update` to revise existing planning artifacts.
3. **Sync** the change's delta specs into main specs (`openspec-sync-specs`), then
**archive** it (`openspec-archive-change` / `/opsx-archive`) 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.