30fc7775a5
Modernizes several `internal/*` packages under the Go proxy, replaces
third-party forks with standard-library primitives, and brings the
test suite from near-zero to high coverage across the touched packages.
Package changes
- **`internal/errors`** — Rewrites the `pkg/errors` fork as a thin
wrapper
over stdlib `errors`. A single `withStack` struct captures stack
traces via `runtime.Callers`; `fmt.Errorf("%w", ...)` handles all
message wrapping. Restores `errors.Is`/`As`/`Unwrap` chain traversal
(silently broken in the fork) and deletes ~190 lines of stack/frame
formatting. `Is`, `As`, `Unwrap`, and `Join` are re-exported so
callers need a single import.
- **`internal/logger`** — Swaps stdlib `log.Logger` for `log/slog` JSON
handlers with UTC timestamps and custom level labels (`verb`, `debug`,
`warn`, `error`). Hides `withContextID` (no external callers).
- **`internal/sync`** — Converts `Map[K, V]` from a concrete struct to
an interface with a `NewMap` constructor for testability.
- **`internal/signal`** — Adds `signalNotify` / `osExit` indirections so
`InstallSignals` and `InstallForceQuit` can be exercised without real
OS signals or process termination.
- **`internal/utils`** — Drops deprecated `io/ioutil` and the stdlib
`errors` alias (the internal `errors` package re-exports what's
needed).
- **`internal/version`** — No code changes; fully covered by new tests.
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
9.2 KiB
| name | description |
|---|---|
| srs-develop | Develop, modify, debug, and maintain the next-generation SRS media server written in Go — including the proxy, origin, and edge servers. This is the AI-maintained successor to the first-generation C++ SRS server. Use for all development tasks, for example, adding features, fixing bugs, refactoring code, understanding code architecture, reviewing changes, and writing tests for the Go codebase. NOT for end-user support, usage questions, configuration help, or learning how to use SRS — use the srs-support skill for those. Only activate when the task is explicitly about developing or modifying the Go SRS codebase. |
SRS Development
Core Principle
Code and documents are the only truth. Issue descriptions may be inaccurate. Pull requests may be misleading. Feature descriptions may be insufficient. Always ground your understanding in the actual source code and project documentation. Documents capture design intent, architecture rationale, and complex background that code alone cannot express — they are another form of code. When code and documents conflict, investigate rather than assume one is wrong.
Task Router
⚠️ MANDATORY — Always execute this step first. Never skip the Task Router. Never jump directly to a task. Every request must be routed through this table before any work begins.
Route the user's request to exactly ONE task type. Follow that task only. Do not combine tasks.
| Task | When | Route To | Status |
|---|---|---|---|
| Develop Code | User wants to add, modify, refactor code, or update docs — any planned change | → Develop Code | ✅ Supported |
| Fix a Bug | User reports something broken, unexpected behavior, or an error | → Fix a Bug | ❌ Not yet supported |
| Learn Code | User wants to understand how code works — no changes intended | → Learn Code | ❌ Not yet supported |
| Review a PR | User wants to review an existing pull request | → Review a PR | ✅ Supported |
If the routed task is not yet supported, stop and tell the user:
- What task type you routed to
- That this task type is not supported yet
- That support will be added in the future
Do NOT attempt unsupported tasks.
Task: Fix a Bug
Prerequisite: You must arrive here via the Task Router. Do not execute this task directly — always complete the Task Router first to confirm this is the correct task type.
Not yet supported. Will be added in a future update.
Task: Learn Code
Prerequisite: You must arrive here via the Task Router. Do not execute this task directly — always complete the Task Router first to confirm this is the correct task type.
Not yet supported. Will be added in a future update.
Task: Review a PR
Prerequisite: You must arrive here via the Task Router. Do not execute this task directly — always complete the Task Router first to confirm this is the correct task type.
Scope: Walk the pending changes on the current branch (relative to develop), summarize them, sync any stale navigation docs, then bump the version and add a changelog entry once the user supplies the PR number.
Guiding rules
- The user drives staging. Never
git addon your own. After each step, stop and wait for the user to review and stage the files they approve. Only rungit commitwhen they say so. - Docs are navigation, not tutorials. When a code change makes an entry stale, correct it — don't expand it. Only add a new entry when a new file or module was introduced; never to describe a refactor inside an existing module.
Step 1: Survey the changes
- Run
git diff develop --statandgit log develop..HEAD --onelineto get the shape of the branch. - Drill into non-test source diffs with
git diff develop -- <path>to understand what actually changed. - Summarize back to the user: refactors, new files, and anything that could break downstream consumers (log format, public API, wire format, etc.).
- Pause and let the user redirect or ask for more detail.
Step 2: Correct stale navigation docs
- Check
.openclaw/memory/srs-codebase-map.mdfor entries covering any module touched in this PR. - For each entry whose description is no longer accurate, make the smallest correction needed to match the new code. Keep the one-line summary style; do not expand into implementation detail.
- Stop. Let the user review. When they
git addthe files they accept, commit with a short message in the existing style, e.g.Claude: Sync srs-codebase-map with internal/<modules>..
Step 3: Bump the version and update the changelog
- Ask the user for the PR number if they haven't given it.
- Bump revision by one in both version files, keeping them in sync:
internal/version/version.go—VersionRevision()trunk/src/core/srs_core_version7.hpp—VERSION_REVISION
- Add a new top entry to
trunk/doc/CHANGELOG.mdunder## SRS 7.0 Changelog, matching the existing format:
Propose the summary to the user; don't invent one unilaterally.* v7.0, YYYY-MM-DD, Merge [#PR](URL): <Prefix>: <one-line summary>. v7.0.<rev> (#PR) - Stop. Let the user review. When they
git addthe version files and changelog, commit with a short message likeProxy: Bump to v7.0.<rev> for #<PR>..
Task: Develop Code
Prerequisite: You must arrive here via the Task Router. Do not execute this task directly — always complete the Task Router first to confirm this is the correct task type.
Scope: This task covers any planned code or documentation change — adding new features, modifying existing functionality, refactoring code, and updating documentation.
Important: The C++ media server (origin + edge) is in maintenance mode — only bug fixes are accepted, no new features. All new feature development happens in the next-generation Go server. You may reference the C++ server's code to understand how things were done before, but do not add features to it.
Service Router — Determine which Go service the feature targets. Route to exactly ONE service. Do not guess — if unclear, ask the user to clarify.
| Service | Route To | Status |
|---|---|---|
| Proxy server | → Proxy Server | ✅ Supported |
| Origin server | → Origin Server | ✅ Supported |
| Edge server | → Edge Server | ❌ Not yet supported |
If the routed service is not yet supported, stop and tell the user:
- What service you routed to
- That this service is not supported yet
Proxy Server
The proxy server is a complex, growing product — not a small app. It has many modules, and more will be added over time. You cannot load all the code into context at once. The key to working on it is routing to the correct module first.
Step 1: Module Routing (MANDATORY)
- Read the codebase map:
memory/srs-codebase-map.md— both the Next-Generation Server Code section (code modules:cmd/+internal/) and the Next-Generation Server Docs section (documentation:docs/proxy/). - Study the module descriptions and doc descriptions. Understand what each covers and its boundaries.
- Reason about which module(s) and which doc(s) are relevant to the user's request. Consider:
- Which module owns the functionality being changed?
- Which modules might be affected as dependencies?
- Which docs cover the design/architecture of this area?
- Is this a new module or a change to an existing one?
- Present your reasoning to the user — both the module(s) and doc(s) you identified — and ask for confirmation. Even if you are confident, you MUST ask. Do not proceed without confirmation.
- If you are unsure, stop and ask the user to clarify. Do not guess.
Only after the user confirms the routing do you proceed to Step 2.
Step 2: Understand the Module
- Read the confirmed docs (if any were identified) — understand the design intent, architecture rationale, and how the module is organized internally. This is the why.
- Based on doc understanding, identify the specific file(s) within the module that are relevant to the feature. Not the whole module — only the files that matter.
- Read only those specific files. Code gives you the implementation details: function signatures, patterns, conventions, edge cases. This is the how.
- If no relevant docs exist, scan the module directory listing (filenames only) to locate the right files, then read them.
Step 3: Implement and Verify
- Implement the code change.
- If you changed or added a Go interface with a
//go:generate go tool counterfeiter ...directive, regenerate fakes:make generate - Run the proxy unit tests to verify:
bash scripts/proxy-utest.sh --coverage - Run the proxy E2E test (starts proxy + SRS origin, publishes RTMP, verifies playback):
bash scripts/proxy-e2e-test.sh - If any tests fail, fix the issues and re-run until all tests pass.
All script paths are relative to this skill's directory.
Origin Server
(workflow steps to be defined)
Edge Server
Not yet supported. Will be added in a future update.