Agent Development Guide
中文版本:Agent 开发指南
This chapter is a contributor-oriented digest of how ToughRADIUS is built with AI coding agents. It summarizes the working rules, quality gates, and the auto-delegation loop so the workflow is discoverable from the handbook.
The canonical rules live in the repository’s
AGENT.md;
that file stays authoritative and is referenced directly by the agent tooling.
This chapter does not replace it — when in doubt, follow AGENT.md.
Product scope baseline
Development stays anchored to the feature checklist; it never drifts into unrelated product directions.
- The canonical scope baseline is
docs/feature-checklist.md(with an English copy atdocs/feature-checklist.en.md). - Every task, issue, PR, test, and review note maps to a feature ID such as
TR-F004. - If a request does not map to an existing ID, the checklist is updated first (scope, status, acceptance boundary, rationale) before any code changes.
- Non-goals
TR-N001–TR-N005(payment, CRM, generic monitoring stack, multi-tenancy, full rewrite) are out of scope unless the checklist is explicitly revised first.
Roadmap and skill library
Agent-driven development is organized around three artifacts:
docs/roadmap.md— long-term roadmap and milestones, each mapped toTR-FIDs. This is the task source for agent work..agents/skills/— reusable skill SOPs, one folder per skill (.agents/skills/<name>/SKILL.md)..agents/README.md— the delegation reference and shared guardrails.
A coordinator layer drives the loop, while the execution SOPs do the domain-specific work:
| Role | Skill | Purpose |
|---|---|---|
| Coordinator | orchestrate-roadmap | Entry role for “auto-delegate development”: selects the next unchecked subtask, picks the matching SOP, enforces gates, opens a PR |
| Gate | review-pr | Independent, CI-anchored review; requests changes via labels/comments and auto-merges only when approved and CI is green |
| Self-iteration | groom-roadmap | After each merge, checks off the delivered subtask and re-grooms the roadmap |
Execution SOPs include: add vendor VSA (add-radius-vendor), add EAP method
(add-eap-method), add Admin API (add-adminapi-endpoint), add React Admin
resource (add-react-admin-resource), add config schema (add-config-schema),
add acceptance test (add-acceptance-test), sync upstream radius
(sync-upstream-radius), reference RFC (reference-rfc), align checklist
(align-feature-checklist), write Go tests (write-go-tests), and document Go
APIs (document-go-apis). Pick the matching skill before starting a task type.
Agents run on your own host with your own agent/CLI, not via a CI workflow, so credentials never enter CI and the execution environment stays under your control.
Working guidelines
Understand existing code before editing
Never change code blindly. Locate the existing implementation, related tests, and documentation first, then mirror the project’s naming, error handling, and data flow. Trace the full execution path before fixing a bug, and map dependencies and side effects before refactoring.
Continuous verification
Do not wait until the end to run tests. Every logical change is followed by a test run so regressions surface immediately rather than at the end of a large batch.
Code is the best documentation
- All exported APIs carry comprehensive godoc comments — purpose,
parameters with constraints, return values, and error conditions (with usage
examples for complex APIs). See the
document-go-apisskill for the standard-library-style conventions. - Complex logic carries inline comments explaining the why, not the what.
- Vendor-specific code references the protocol spec (RFC numbers, VSA docs).
- No redundant standalone summary documents — information belongs in code comments and Git history.
Core development principles
Test-driven development (TDD)
Write the test first, then the code: define the expected behavior in a failing
test (red), write the minimum code to pass it (green), then refactor while the
tests stay green. If internal/radiusd/auth.go changes, the test lives in
internal/radiusd/auth_test.go. See the write-go-tests skill for the unified
conventions.
GitHub workflow
- Pull requests only — never push to
main; the protected branch rejects direct pushes. - Conventional commits —
<type>(<scope>): <subject>with types such asfeat,fix,test,docs,refactor,perf,chore. - Small, atomic changes over giant PRs.
Repository issue/PR automation
Several GitHub Actions add lightweight triage around issues and pull requests. They help maintainers scan the queue, but they do not replace reading the original issue, PR diff, and CI output.
| Workflow | Trigger and result | Maintainer notes |
|---|---|---|
| AI issue summary | .github/workflows/ai-issue-summary.yml runs when an issue is opened and posts a short GitHub Models summary as an issue comment. | Issue titles and bodies are untrusted input. Treat the generated summary as a convenience only; the issue text remains the source of truth. |
| Stale | .github/workflows/stale.yml runs daily at 04:24 UTC and by manual dispatch. After 60 days without activity it adds stale; after 14 more inactive days it closes the item. | Comment, push a commit, or remove stale to keep work open. Issues with pinned, security, help wanted, agent-roadmap, or needs-human are exempt; PRs with pinned, security, agent-roadmap, or needs-human are exempt; all milestones are exempt. |
| Labeler | .github/workflows/labeler.yml runs on pull_request_target and applies labels from .github/labeler.yml based on changed paths. | It labels go, javascript, github_actions, dependencies, and doc. The action reads the changed-file list and base-branch config; it does not check out or execute PR code. |
| Greetings | .github/workflows/greetings.yml runs when a contributor opens their first issue or PR and posts onboarding guidance. | The comment is informational. It does not change review requirements or issue priority. |
Minimum viable product (MVP)
Each change is delivered as a minimal, independently usable, rollback-safe unit that does not break existing behavior. Large efforts are broken into MVP increments (for example, vendor attribute parsing → auth integration → accounting → management UI) rather than landing in one oversized PR.
Quality gates
Every agent change must pass these gates before merging:
go build ./...— no compilation errors.go test ./...— all unit tests pass.golangci-lint run— clean (pinned to v2.12.2, matching CI).cd web && npm run build— for any frontend change.- Protocol / end-to-end changes ship a CI-executable acceptance test under
test/integration/and cite the relevant spec underdocs/rfcs/. - Output goes through a PR labeled
agent-roadmap, gated byreview-pr, and is merged only whenagent-approvedwith green CI.
Technical constraints
- No CGO — the project builds with
CGO_ENABLED=0for easy cross-platform deployment. Use pure Go drivers only (for examplegithub.com/glebarez/sqliteinstead ofgithub.com/mattn/go-sqlite3). - Database dual-compatibility — every schema change must work on both PostgreSQL (default) and SQLite.
- Upstream dependency — the core
layeh.com/radiuslibrary isreplaced ingo.modto the organization forkgithub.com/talkincode/radius; important upstream fixes are evaluated via thesync-upstream-radiusskill.
Common anti-patterns (prohibited)
- Exporting APIs without documentation.
- Committing implementation without tests.
- Giant PRs that mix many concerns.
- Implementing before writing tests.
- Pushing directly to
mainor skipping review. - Creating redundant standalone summary/report documents.
- Introducing CGO dependencies.
Where to go next
AGENT.md— the full, canonical agent development guide.- Documentation Map — find the README, security policy, feature checklist, roadmap, and RFC index.
- Protocol & RFC Reference — protocol standards mapped to the code and milestones.