| tags |
|
||
|---|---|---|---|
| type | reference | ||
| status | active | ||
| area | community | ||
| aliases |
|
||
| created | 2026-03-06 |
Thanks for your interest in contributing! Symphony is an open-source orchestration engine for coding agents, and we welcome contributions of all kinds.
# Clone and build
git clone https://github.com/broomva/symphony.git
cd symphony
make smoke # compile + lint + test (~2 min)Requires Rust 1.88+ (edition 2024).
make smoke # Full gate: compile + clippy + test
make check # Compile + clippy only
make test # Run all tests
make build # Release buildSymphony supports Linear and GitHub Issues. Adding Jira, GitLab, Asana, etc. is the highest-impact contribution.
To add a tracker:
- Create a new file in
crates/symphony-tracker/src/(e.g.,jira.rs) - Implement the
TrackerClienttrait (4 methods:fetch_candidate_issues,fetch_issues_by_states,fetch_issue_states_by_ids,set_issue_state) - Register it in the
create_tracker()factory incrates/symphony-tracker/src/lib.rs - Add the new
kindto config validation incrates/symphony-config/src/loader.rs - Add tests in the same file under
#[cfg(test)] mod tests - Add an example workflow in
examples/ - Add setpoints to
CONTROL.mdfor the new tracker
The agent runner works with any CLI that:
- Accepts input on stdin (JSON-RPC) or as CLI arguments
- Outputs line-delimited JSON on stdout
- Uses stderr for diagnostics (not parsed)
If you get Symphony working with a new agent, add an example workflow.
- Check the spec reference for behavioral requirements
- Add tests for any new logic (tests live in
#[cfg(test)] mod testsat the bottom of each file) - Run
make smokebefore submitting
Symphony uses a control metalayer ([[CONTROL]]) as the grounding framework for all development. Before writing code, read the setpoints that your change affects. After writing code, verify those setpoints pass.
The loop:
- CHECK
CONTROL.md→ which setpoints does your change affect? - IMPLEMENT → write code that satisfies those setpoints
- MEASURE → run
make smoke - VERIFY → all affected setpoints green?
- DOCUMENT → add new setpoints for new behavior
- FEEDBACK → log deviations if any setpoint was relaxed
If you add a new feature, add corresponding setpoints to CONTROL.md. This keeps the system verifiable across agent sessions and human contributors alike.
thiserrorfor library errors,anyhowfor application errorstracingfor structured logging (neverprintln!orlog)tokiofor async runtimeserdefor all serialization- State normalization:
trim().to_lowercase()for state comparisons - Workspace keys: only
[A-Za-z0-9._-], replace others with_
- Fork and create a branch from
master - Make your changes with tests
- Run
make smoke— it must pass - Open a PR with a clear description of what and why
- Link to any relevant spec sections (e.g., "Implements S11.2")
See [[AGENTS]] for crate layout and design decisions. See [[PLANS]] for the implementation roadmap. See [[docs/operations/Control Harness|Control Harness]] for the build gate details.
By contributing, you agree that your contributions will be licensed under the Apache License 2.0.
This project follows the Contributor Covenant. Please be respectful and constructive.
- [[EXTENDING]] — plugin architecture: adding trackers, agent runners, config sections
- [[docs/architecture/Crate Map|Crate Map]] — all crates with spec coverage
- [[CONTROL]] — quality setpoints your code must satisfy
- [[docs/operations/Configuration Reference|Configuration Reference]] — WORKFLOW.md format
- [[SPEC]] — behavioral requirements