Skip to content

Commit 510f6a9

Browse files
docs: consolidate documentation and reduce redundancy (#272)
1 parent b664511 commit 510f6a9

File tree

4 files changed

+54
-60
lines changed

4 files changed

+54
-60
lines changed

AGENTS.md

Lines changed: 25 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -1,51 +1,38 @@
11
# AGENTS.md
22

3-
The following rules apply to coding agent collaboration and delivery workflows in this repository.
3+
The following rules apply to coding agent collaboration in this repository. These complement the general [CONTRIBUTING.md](CONTRIBUTING.md) workflow.
44

55
## 1. Core Principles
66

7-
- Move tasks forward under secure and traceable conditions, while avoiding unnecessary process blockers.
8-
- Stay consistent with the existing repository structure, implementation style, and engineering conventions.
7+
- Move tasks forward under secure and traceable conditions.
8+
- Adhere to the existing repository structure and engineering conventions.
99

10-
## 2. Git Workflow
10+
## 2. Collaboration Workflow
1111

12-
- Do not commit or push directly to protected branches: `main` / `master` / `release/*`.
13-
- Each development task should be implemented on an independent branch, preferably cut from the latest mainline.
14-
- Prefer `git fetch` + `git merge --ff-only` to sync mainline and avoid implicit merges.
15-
- It is allowed to push development branches to remote branches with the same name for collaboration and backup.
16-
- Do not rewrite shared history: no `git push --force`, `git push --force-with-lease`, or arbitrary `rebase`.
17-
- Commit only files related to the current task; do not clean up or roll back unrelated local changes.
12+
- Follow the Git, Issue, and PR workflow defined in [CONTRIBUTING.md](CONTRIBUTING.md).
13+
- Use `gh` CLI for all issue/PR operations (reading, writing, and comments). Do not edit through the web UI.
14+
- Create a new tracking issue for any development task that does not already have one.
15+
- Link the issue explicitly in PR descriptions (e.g., `Closes #xx`).
16+
- Keep status updates synchronized to the relevant issue/PR to avoid duplicate manual work.
1817

19-
## 3. Issue and PR Collaboration
18+
## 3. Tooling and Text Conventions
2019

21-
- Before starting a development task, check whether a related open issue already exists (for example, `gh issue list --state open`).
22-
- If no related issue exists, create a new issue for tracking. The issue should include background, reproduction steps, expected vs. actual behavior, acceptance criteria, and a `git rev-parse HEAD` snapshot.
23-
- Only collaboration-process documentation changes (such as `AGENTS.md`) can be modified directly without creating an additional issue.
24-
- Recommended issue title prefixes: `[feat]`, `[bug]`, `[docs]`, `[ops]`, `[chore]`.
25-
- If a commit serves a specific issue, include the corresponding `#issue` in the commit message.
26-
- PRs are recommended to be created as Draft by default, and should explicitly indicate linkage in the description (for example, `Closes #xx` / `Relates to #xx`).
27-
- When key progress, solution changes, or new risks appear, sync updates to the corresponding issue/PR in time and avoid duplicate comments.
20+
- **Language**: Use Simplified Chinese for issues, PRs, and comments. Technical terms may remain in English.
21+
- **PR Body**: For multi-line bodies, write to a temporary file first and pass it via `gh pr create --body-file`.
22+
- **References**: Use `#123` for same-repo references; use full URLs for cross-repo links.
2823

29-
## 4. Tooling and Text Conventions
24+
## 4. Regression and Validation
3025

31-
- Use `gh` CLI to read and write issues/PRs; do not edit through the web UI manually.
32-
- Use Simplified Chinese for issues, PRs, and comments; technical terms may remain in English.
33-
- For multi-line bodies, write to a temporary file first and pass it with `--body-file`; do not concatenate `\\n` in `--body`.
34-
- Use `#123` for same-repo references (auto-linking); use full URLs for cross-repo references.
26+
- Use the primary validation entrypoint for all changes:
27+
```bash
28+
./scripts/doctor.sh
29+
```
30+
- If `pre-commit` (via `doctor.sh`) auto-fixes files, review the changes before committing.
31+
- For documentation-only changes, you may skip tests but must self-check all commands and paths.
32+
- If environment limits prevent full validation, explicitly report what was skipped and why.
3533

36-
## 5. Regression and Validation
34+
## 5. Security and Configuration
3735

38-
- Choose regression strategy based on change type. Default baseline:
39-
- `uv run pre-commit run --all-files`
40-
- `uv run pytest`
41-
- If `pre-commit` auto-fixes files (such as `ruff --fix`), review the changes before committing.
42-
- For shell/deployment script changes, in addition to baseline checks, run at least `bash -n` for syntax validation on modified scripts.
43-
- For documentation-only changes, tests may be skipped, but commands and path examples must be self-checked for usability.
44-
- `uv sync --all-extras` is required only for first-time setup or dependency changes; it is not mandatory for every change.
45-
- If any validation cannot be completed due to environment limits, explicitly state the skipped item and reason in the report.
46-
47-
## 6. Security and Configuration
48-
49-
- Never commit keys, tokens, credentials, or other sensitive information (including `.env` content).
50-
- Logs and debug output must not leak access tokens or private data.
51-
- Changes related to deployment, authentication, or secret injection must include synchronized documentation updates and minimal acceptance steps.
36+
- **Secrets**: Never commit keys, tokens, or `.env` content.
37+
- **Logs**: Ensure debug output does not leak access tokens.
38+
- **Documentation**: Synchronize documentation updates for all deployment or auth-related changes.

README.md

Lines changed: 27 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -8,22 +8,36 @@ deployment boundary.
88

99
## What This Is
1010

11-
- An A2A adapter service for `opencode serve`.
12-
- Use it when you need a stable A2A endpoint for apps, gateways, or A2A
13-
clients.
11+
- An A2A adapter service built on `opencode serve`, with inbound runtime
12+
exposure plus outbound peer calling.
13+
- It supports both roles in one process: serving as an A2A Server and hosting an
14+
embedded A2A Client for `a2a_call`.
15+
16+
## Architecture
1417

1518
```mermaid
1619
flowchart TD
17-
Client["a2a-client-hub / any A2A client"]
20+
External["A2A Clients / a2a-client-hub / Gateways"]
1821
19-
subgraph ServerSide["Server-side"]
20-
Adapter["opencode-a2a\nA2A adapter service"]
21-
Runtime["opencode serve\nOpenCode runtime"]
22+
subgraph Adapter["opencode-a2a Runtime"]
23+
Ingress["Inbound A2A Surface\nREST + JSON-RPC"]
24+
OpenCode["OpenCode Runtime"]
25+
Outbound["Embedded A2A Client\na2a_call"]
26+
end
2227
23-
Adapter <--> Runtime
28+
subgraph Peers["Peer A2A services"]
29+
PeerA2A["Peer A2A Agent"]
30+
PeerRuntime["Peer OpenCode Runtime"]
31+
PeerA2A --> PeerRuntime
2432
end
2533
26-
Client <--> Adapter
34+
External -->|message/send,\nmessage:stream| Ingress
35+
Ingress -->|tool call| OpenCode
36+
OpenCode -->|model/tool result events| Ingress
37+
Ingress -->|a2a_call| Outbound
38+
Outbound -->|message/send,\nmessage:stream| PeerA2A
39+
PeerA2A -->|tool result| Outbound
40+
PeerRuntime -->|task session\nexecution| PeerA2A
2741
```
2842

2943
## Quick Start
@@ -62,7 +76,6 @@ OPENCODE_BASE_URL=http://127.0.0.1:4096 \
6276
A2A_HOST=127.0.0.1 \
6377
A2A_PORT=8000 \
6478
A2A_PUBLIC_URL=http://127.0.0.1:8000 \
65-
A2A_STREAM_SSE_PING_SECONDS=15 \
6679
OPENCODE_WORKSPACE_ROOT=/abs/path/to/workspace \
6780
opencode-a2a serve
6881
```
@@ -73,22 +86,19 @@ Verify that the service is up:
7386
curl http://127.0.0.1:8000/.well-known/agent-card.json
7487
```
7588

76-
Default local address: `http://127.0.0.1:8000`
77-
78-
## What You Get
89+
## Capabilities
7990

8091
- A2A HTTP+JSON endpoints such as `/v1/message:send` and
8192
`/v1/message:stream`
8293
- A2A JSON-RPC support on `POST /`
8394
- Peering capabilities: can act as a client via `opencode-a2a call`
8495
- Autonomous tool execution: supports `a2a_call` tool for outbound agent-to-agent communication
8596
- SSE streaming with normalized `text`, `reasoning`, and `tool_call` blocks
86-
- Explicit REST SSE keepalive configurable through `A2A_STREAM_SSE_PING_SECONDS`
8797
- Session continuity through `metadata.shared.session.id`
8898
- Request-scoped model selection through `metadata.shared.model`
8999
- OpenCode-oriented JSON-RPC extensions for session and model/provider queries
90100

91-
## Peering Node
101+
## Peering Node / Outbound Access
92102

93103
`opencode-a2a` supports a "Peering Node" architecture where a single process handles both inbound (Server) and outbound (Client) A2A traffic.
94104

@@ -140,9 +150,8 @@ turn OpenCode into a hardened multi-tenant platform.
140150
- Provider auth and default model configuration remain on the OpenCode side; deployment-time
141151
precedence details and HOME/XDG state impact are documented in
142152
[docs/guide.md](docs/guide.md#troubleshooting-provider-auth-state).
143-
- `A2A_CLIENT_BEARER_TOKEN` is used for outbound peer calls initiated by the
144-
server-side `a2a_call` tool.
145-
- Provider auth and default model configuration remain on the OpenCode side.
153+
- Use `A2A_CLIENT_BEARER_TOKEN` for server-side outbound peer calls initiated by
154+
`a2a_call`.
146155
- Deployment supervision is intentionally BYO. Use `systemd`, Docker,
147156
Kubernetes, or another supervisor if you need long-running operation.
148157
- For mutually untrusted tenants, run separate instance pairs with isolated

docs/guide.md

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -188,9 +188,7 @@ comes from the `opencode-a2a` package itself.
188188
URI.
189189
- `DataPart` is currently rejected explicitly; it is not silently downgraded.
190190
- Task state defaults to `completed` for successful turns.
191-
- The deployment profile is single-tenant and shared-workspace: one server
192-
instance exposes one OpenCode workspace/environment to all consumers bound to
193-
that instance.
191+
- The deployment profile is single-tenant and shared-workspace. For detailed isolation principles and security boundaries, see [SECURITY.md](../SECURITY.md).
194192

195193
## Streaming Contract
196194

scripts/README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ remaining repository-maintenance helpers.
1212

1313
## Other Scripts
1414

15-
- [`doctor.sh`](./doctor.sh): local development regression entrypoint (`sync`/`pip check` + lint + tests + coverage policy)
15+
- [`doctor.sh`](./doctor.sh): primary local development regression entrypoint (uv sync + lint + tests + coverage)
1616
- [`dependency_health.sh`](./dependency_health.sh): dependency review entrypoint (`sync`/`pip check` + outdated + audit)
1717
- [`check_coverage.py`](./check_coverage.py): enforces the overall coverage floor and per-file minimums for critical modules
1818
- [`lint.sh`](./lint.sh): lint helper

0 commit comments

Comments
 (0)