Implement and maintain Symphony according to SPEC.md using:
.NET 10(net10.0)- SQLite for durable orchestrator state
- GitHub as the source of truth for issues, pull requests, milestones, and repository versioning
- Functional behavior:
SPEC.md - Implementation sequencing:
IMPLEMENTATION_PLAN.md - If plan and spec conflict, follow
SPEC.mdand update the plan.
Locked on 2026-03-05:
- Ship Worker + HTTP API in v1.
- Use EF Core + SQLite.
- Design for multi-instance safety.
- Use GitHub PAT auth in v1.
- Candidate filter includes state + label + milestone.
- Dispatch only issues (no PR-only work items).
- Success state uses GitHub issue
Closed. - Use shared clone + Git worktrees for per-issue workspaces.
- Use permissive auto-approve policy in v1.
- Ship
github_graphqlextension in v1. - Default capacity:
5agents,10minute poll interval. - Run as Windows Service in target deployment.
- Do not weaken safety constraints from sections 9, 10, and 15 of the spec.
- Keep workspace path containment checks mandatory.
- Keep protocol parsing strict on stdout; never parse stderr as protocol events.
- Never log secrets (
GITHUB_TOKEN, workflow secrets, auth headers). - Track writes are agent/tool driven; do not add hidden orchestrator-side business writes unless explicitly requested.
- Keep clear boundaries:
- Core domain/orchestration logic must not depend on concrete infra APIs.
- Infrastructure adapters implement interfaces from core.
- Prefer composition over shared mutable globals:
- Orchestrator state must be explicit and testable.
- Background services should use scoped dependencies per tick/run.
- Persistence:
- Use SQLite with migrations.
- Persist only state needed for recovery, observability, and debugging.
- Include DB-backed lease/claim semantics for multi-instance safety.
- GitHub integration:
- Use GraphQL endpoint by default (
https://api.github.com/graphql). - Normalize all tracker payloads to the spec domain model before use.
- Use PAT auth for v1.
- Filter candidates by configured state + label + milestone.
- Exclude PR-only items from dispatch.
- C# latest language version supported by .NET 10 SDK.
- Nullable reference types enabled.
- Async all the way for I/O paths.
- Cancellation tokens respected in polling, subprocess, and HTTP calls.
- Keep classes focused and small; split large orchestration behaviors into feature services.
- Prefer built-in ASP.NET Core and .NET primitives over third-party packages unless justified.
- Read workflow from
WORKFLOW.md. - Resolve
$ENV_VARvalues in config. - Fail fast on invalid required config.
- Validate options at startup and before dispatch cycles where required by spec.
- Default to
max_concurrent_agents=5andpolling.interval_ms=600000unless explicitly overridden.
Minimum for any non-trivial change:
- Unit tests for business logic and state transitions.
- Integration tests for infra boundaries touched (SQLite, GitHub adapter, protocol client).
- Update/add conformance tests mapped to section 17 of
SPEC.md.
Prefer SQLite-backed integration tests over fake in-memory DB providers.
- Structured logs with issue/session correlation fields.
- Clear event names for dispatch, retry, stop, cleanup, and protocol errors.
- Snapshot/status output must be derived from orchestrator state, not ad hoc caches.
- Include lease ownership/heartbeat visibility for multi-instance troubleshooting.
- Start by citing relevant spec section(s) in PR description.
- Implement smallest vertical slice that can be validated.
- Add or update tests.
- Run build + tests locally before handing off.
- Document behavior changes in
README.mdordocs/when applicable.
dotnet restore
dotnet build
dotnet testIf migrations are used:
dotnet ef migrations add <Name> --project src/Symphony.Infrastructure/Persistence.Sqlite
dotnet ef database update --project src/Symphony.Infrastructure/Persistence.Sqlite- Behavior aligns with
SPEC.md. - Tests prove the behavior or failure mode.
- Logging and error paths are explicit.
- No secrets exposed.
- Reviewer can trace change from spec clause to implementation.