OpenClaw: Restructure workspace with symlinks, add codebase map, and rewrite AI docs. v7.0.141 (#4654)

Restructure the OpenClaw workspace so all SRS project directories are
accessible via symlinks from `.openclaw/`, eliminating the need for
parent traversal or absolute paths. All AI tools (OpenClaw, Claude Code,
Codex, Kiro) now see the same relative paths from the workspace root.

**Workspace restructuring**
- Add symlinks in `.openclaw/` for `trunk/`, `cmd/`, `internal/`,
`cmake/`, `docs/`, `objs/`, and a self-referential `.openclaw` link
- Add root-level `memory` symlink pointing to `.openclaw/memory`
- Simplify `TOOLS.md` working directory rules: everything is relative
from CWD
- Update `.gitignore` patterns for `personal*`, `support*`,
`srs-consults*` directories

**New codebase map (`memory/srs-codebase-map.md`)**
- Comprehensive map of the entire SRS codebase: C++ media server modules
(`core/`, `kernel/`, `protocol/`, `app/`), State Threads, Go next-gen
server (`cmd/` + `internal/`), documentation, and testing structure
- Enables AI to reason about which files are relevant to a question
instead of blind grepping
- Added "Codebase map first" rule to `MEMORY.md`: always load the map
before searching code

**Skill updates**
The `srs-support` has been reorganized into a three-phase workflow
consisting of Setup, Load Knowledge, and Answer by Topic. It now
features a tiered approach to knowledge integration, with the codebase
map being incorporated as the third layer.
- `st-develop`: Simplified setup, added codebase map reference
For both skills, the dynamic resolution logic for `SRS_ROOT` has been
eliminated. Now, all paths are relative.

**Documentation rewrite (`getting-started-ai.md`)**
- Replaced Augment Code / GitHub Copilot / PR review content with
current AI tooling: SRS Robot (Telegram/Discord), Claude Code, Codex,
Kiro, and OpenClaw
- Added sections on skills and the knowledge base philosophy

**Cleanup**
- Removed `docs/ideas.md`, `docs/youtube/` transcripts, and
`proxy/README.md`
- Removed "Ideas Capture" and "YouTube Channel Content" sections from
`MEMORY.md`
- Fixed origin cluster doc build command (`cd srs && make`)

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

.gitignore

@@ -44,3 +44,7 @@ cmake-build-debug
 srs-proxy
 .go-formarted
 .env
+
+# For AI
+/*personal*
+

.openclaw/.gitignore

@@ -1,6 +1,11 @@
-/.openclaw/workspace-state.json
+# For OpenClaw
+/workspace-state.json
 /.clawhub
 /.pi
 /extensions
 /skills/llm-switcher
-/personal
+
+# For speical folders.
+/personal*
+/support*
+/*srs-consults*

.openclaw/.openclaw

@@ -0,0 +1 @@
+../.openclaw

.openclaw/MEMORY.md

@@ -3,6 +3,7 @@
 ## Workspace Conventions
 - **No auto-commit** — Never automatically git commit. Only commit when William explicitly tells me to.
 - **No guessing** — William will teach me everything about SRS. Don't speculate or fill in gaps. Wait for him to explain.
+- **Codebase map first** — Before searching/grepping the codebase, ALWAYS load `memory/srs-codebase-map.md` in full (the entire file, not partial). Read the module descriptions to reason about which specific files are relevant, then search only those files. Never grep broad directories like `trunk/src/` or the repository root. This is a critical rule.
 
 ## 2026-02-05 — First Boot
 - I'm SRSBot ⚡ — AI developer working with William on SRS
@@ -61,13 +62,6 @@
 
 The three layers are what William controls; the external conditions are what the AI ecosystem must provide. When both are ready, AI can truly manage the project.
 
-## Ideas Capture
-- When William shares isolated/separate ideas, save them to `docs/ideas.md`
-- This is for **rudimentary, temporary, brainstorm-level** ideas — not mature ones
-- Mature/specific topics go to their proper place (YouTube stuff → `docs/youtube/`, SRS knowledge → `memory/srs-*.md`)
-- `docs/ideas.md` is the scratch pad for early-stage thinking that doesn't belong anywhere else yet
-- Ideas may grow into major features or directions over time
-
 ## Changelog & Version
 - **Changelog:** `trunk/doc/CHANGELOG.md`
 - **Version file:** `trunk/src/core/srs_core_version7.hpp` — bump `VERSION_REVISION` to match the new changelog entry
@@ -82,13 +76,9 @@ The three layers are what William controls; the external conditions are what the
 Detailed SRS knowledge in `memory/srs-*.md` files:
 - `srs-overview.md` — What SRS is, protocols, ecosystem tools, and **Features section** with all SRS features, versions, and dates
 - `srs-coroutines.md` — State Threads (ST) coroutine library, why SRS uses coroutines, how coroutine switching works, maintenance burden (platform matrix, Windows/SEH), and multi-CPU strategy (cluster > multi-threading)
+- `srs-codebase-map.md` — Codebase structure: directory layout, file naming conventions, module boundaries, and packet flow. Enables reasoning about which files to look at for a given topic instead of blind searching.
 
 ### Rule: Keep Feature List Updated
 When creating new features, updating protocols, or making changes to SRS capabilities, **always update the Features section in `memory/srs-overview.md`** with the feature name, description, version, and date.
 
-## YouTube Channel Content (docs/youtube/)
-- Contains transcripts from SRS YouTube channel videos
-- ⚠️ **DO NOT trust as knowledge base** — these are snapshots of thoughts at a specific date
-- May contain outdated info, changed opinions, or revised ideas
-- Always verify against current codebase, docs, and project state
-- Use for historical context only, not authoritative reference
+

.openclaw/TOOLS.md

@@ -40,15 +40,13 @@ Skills are shared. Your setup is yours. Keeping them apart means you can update
 - Channel: `telegram`, accountId: `srs` (SRS bot)
 - When sending to William's Telegram: `channel: "telegram"`, `accountId: "srs"`
 
-### ACP Working Directory
+### Working Directory
 
-- My OpenClaw workspace may be a subdirectory like `~/git/srs/.openclaw`. That is **my assistant workspace**, not necessarily the real project directory for ACP coding work.
-- When delegating project work to ACP agents (Claude/Codex/Gemini/Kiro/etc), do **not** assume the OpenClaw workspace is the project root.
-- First ask: **Is the real project directory the parent of the current OpenClaw workspace?** In this setup, yes: workspace is `~/git/srs/.openclaw`, while the SRS project directory is the **parent directory** `~/git/srs`.
-- Treat this as the default pattern unless the task clearly targets OpenClaw itself: **workspace = assistant home, parent directory = actual project root**.
-- For ACP project tasks, prefer the **parent directory of the current workspace** as cwd when that parent is the real repo/project root.
+- ⚠️ **CRITICAL RULE:** Find everything from the current working directory. All SRS project directories are available here — no discovery, no parent traversal, no absolute paths.
+- Available directories: `trunk/`, `cmd/`, `internal/`, `cmake/`, `docs/`, `memory/`
+- All AI tools (OpenClaw, Codex, Claude Code, Kiro CLI) see the same relative paths.
+- ACP agents (Codex, Claude Code, etc.) also use the current directory as root — they find files from here too.
 - Use the OpenClaw workspace itself only for OpenClaw-specific/meta tasks.
-- The key idea: ACP should see the **project first**, not the assistant's memory/persona files.
 
 ### Git Commit Workflow
 

.openclaw/cmake

@@ -0,0 +1 @@
+../cmake

.openclaw/cmd

@@ -0,0 +1 @@
+../cmd

.openclaw/docs

@@ -0,0 +1 @@
+../docs

.openclaw/docs/ideas.md

@@ -1,49 +0,0 @@
-# Ideas
-
-Collection of ideas for SRS — captured as they come, refined over time.
-
-**Format:** Each idea is a top-level section (`##`) with the date. Multiple paragraphs OK, but one section per idea. No subsections.
-
----
-
-## 1M Token Context Window = Full SRS in One Shot (2025-02-12)
-
-Claude Opus 4.6 supports 1M tokens. SRS is ~150K lines of code + docs ≈ 300K tokens — only 30% of the context window. This means the entire codebase and all documentation can be loaded into a single model context at once.
-
-**Why this matters:**
-- No need for RAG, context engines, or search tools to narrow focus — the AI already has everything
-- The model can find its own context across the full codebase rather than being told what to look at
-- An AI with full codebase + full docs is potentially more capable than any single human maintainer
-
-**The gap:** There's still knowledge in William's brain that isn't in the code or docs — background reasoning, design decisions, "why not" choices, protocol nuances.
-
-**The play:** Build out the knowledge base to capture that brain knowledge. And here's the beautiful part — because the AI can already load all the code and docs, it can *help* extract that knowledge from William by cross-referencing against the codebase. The AI becomes a tool for building its own training data.
-
-**Next step:** Load the full SRS codebase and docs into context, then use that to help William build the knowledge base for the project. See whether the AI can effectively assist in extracting and structuring knowledge when it has full code + doc context.
-
-## Skills as Knowledge Base Loaders, Not Replacements (2026-02-14)
-
-Published the first SRS skill to ClawHub: https://clawhub.ai/winlinvip/srs-support
-
-**What the skill does:** It's a standard workflow that activates when you ask about SRS. The skill checks the knowledge base, checks the codebase, checks the local repository, and loads all relevant documents into the AI's context. This turns a generic AI into one that knows every detail of SRS — specific, up-to-date, not generic or misleading.
-
-**Key insight: Skills don't replace the knowledge base — skills depend on the knowledge base.** The skill is the mechanism that loads the knowledge base (and potentially special knowledge bases) into context. If the workflow changes or new workflows are introduced (e.g., a skill for code review, or bug fixes), new skills can be created. But the knowledge base itself is the core asset.
-
-**What makes the knowledge base valuable:**
-- It's up-to-date (not stale training data)
-- It includes the codebase AND documentation
-- Most importantly: it captures background, decisions, and design thinking — the stuff in William's mind that's NOT in the code
-- The knowledge base will be updated by William as he teaches the AI, not by the skill itself (unless workflow changes require it)
-
-**Multiple knowledge bases for different audiences:**
-- Users need to know how to use SRS — configuration, deployment, scaling, debugging
-- Developers need to know how to modify SRS — architecture, internals, design rationale
-- Maybe at least two knowledge bases, maybe more (deep analysis, domain-specific)
-- With large enough context windows (1M+ tokens), the AI might load all knowledge bases at once — but the audiences are still different, so the skill can help focus the response
-
-**Skills can also be smart about context:**
-- Check the environment (local repo state, config, etc.)
-- Ask clarifying questions to make the query more specific
-- Help the user formulate better questions before loading context
-
-**Future direction:** More specialized skills (code review, bug fix, deployment) following the same pattern — skill as workflow, knowledge base as the underlying asset. The skill + knowledge base combination is powerful for the community: anyone can use it to get expert-level help with SRS.

.openclaw/docs/youtube/after-12-years-of-maintaining-srs-i-let-ai-run-the-project.md

@@ -1,101 +0,0 @@
-# After 12 Years of Maintaining SRS, I Let AI Run the Open Source Project
-
-- **Author:** William
-- **Published:** 2026-01-10
-- **URL:** https://youtu.be/evN70DjiwcU
-
-> ⚠️ **Note:** This is a transcript from a specific date. Information may be outdated. Do not treat as authoritative — verify against current codebase and documentation.
-
-After several months of experimentation, I found that AI — powered by Augment — can effectively manage the SRS open-source project end to end, from issues and code to testing, bug fixes, and community support.
-
-However, this does not work automatically — AI still needs proper context, including clear guidelines, correctly configured ignore files, and a repository that gathers all relevant documentation while excluding unrelated content like third-party libraries.
-
-Moreover, AI has clear limitations and side effects — it cannot handle everything, and achieving the expected results still requires following specific patterns and workflows.
-
-## What We Achieved by Using AI in the SRS Project
-Within several months, AI helped reduce open issues from ~200 to ~10, increased test coverage from ~50% to ~88%, and enabled a largely end-to-end AI-assisted contribution workflow, from issue analysis to feature delivery and community communication. We achieved measurable improvements across communication, quality, maintenance, feature delivery, and workflow efficiency.
-
-Global Communication and Documentation at Scale: AI was first introduced one to two years ago to handle translation. All issue titles, descriptions, discussions, pull requests, and documentation were automatically translated into English.
-
-This removed language barriers and allowed contributors and users worldwide to participate more effectively. Over time, English became the consistent working language of the project without increasing the burden on maintainers.
-
-Test Coverage and Testability Improvements: With AI assistance, test coverage improved from about 50% to 88%. Most new unit tests were generated by AI.
-
-More importantly, AI helped refactor code to be more testable — improving modularity, enabling mocking, and isolating components. This allowed AI to write meaningful uTests at the class and function level, rather than superficial tests.
-
-Issue Analysis and Backlog Reduction: Historically, SRS accumulated around 1,600 total issues, with roughly 200 open issues at any time.
-
-AI was used to analyze issue reports — especially crash dumps and failure logs — identify root causes, write reproduction tests, or provide precise reproduction steps when tests were not feasible. AI could also run servers, benchmarks, and black-box tests to verify fixes. As a result, open issues dropped from ~200 to ~10, a significant improvement in project stability.
-
-Feature Development and Protocol Enhancements: AI also contributed to real feature development, not just maintenance.
-
-A notable example is IPv6 support. Previously, IPv6 was only partially supported (mainly RTMP). With AI assistance, IPv6 support was completed across WebRTC, HTTP API, HTTP streaming, SRT, RTSP, and GB protocols. AI also helped deliver other features, demonstrating its ability to handle cross-protocol and non-trivial development work.
-
-AI as a Knowledge Base and Support Engineer: Earlier AI bots that indexed only documentation were limited because they lacked awareness of the code and recent changes.
-
-By indexing code, documents, tests, and changelogs, AI now has comprehensive and up-to-date knowledge of SRS. It can reliably answer questions about feature support, usage, and version history, effectively acting as both a maintainer assistant and a user support engineer.
-
-A Closed-Loop, AI-Assisted Contribution Workflow: AI fundamentally improved the contribution workflow. For both bug fixes and new features, the process now follows a test-driven, end-to-end loop.
-
-AI helps clarify requirements, writes uTests first, assists with implementation, runs verification tests, drafts pull request titles and descriptions, updates documentation, and even prepares community announcements. Human review remains essential, but the overall cycle is faster, more consistent, and easier to sustain.
-
-## Why I Choose Augment?
-Before settling on Augment, I experimented with several AI tools and agents to manage the SRS project, including GitHub Copilot, Cursor, and Cloud Code. Each of these tools has its own design philosophy, workflow, and strengths, but in practice, only Augment proved suitable for managing a large, long-lived open-source project like SRS.
-
-GitHub Copilot and Cloud Code: My experience with GitHub Copilot and Cloud Code was similar. While both tools were helpful for writing small pieces of code, they often failed to respect the latest SRS codebase and documentation. Instead, they sometimes relied on common or generic knowledge, or even outdated assumptions about the project. As a result, they occasionally generated code that did not match the actual design or current state of SRS, and in some cases exhibited hallucinations.
-
-Cursor: Cursor exposed a different but equally critical problem. SRS is not a greenfield project created by AI from scratch; it is a mature system maintained by human engineers for more than a decade. Over time, it has accumulated a large number of third-party libraries and tools — such as OpenSSL, LibSRT, SRS Bench, and numerous Go dependencies.
-
-Augment: Augment stood out because it solved several fundamental problems that are critical for non-greenfield open-source projects.
-
-First, Augment allowed me to explicitly define the SRS codebase by ignoring irrelevant files and directories, such as OpenSSL and other bundled libraries. This ability to limit and curate the AI’s knowledge base is essential. While SRS itself consists of roughly 150k lines of code plus hundreds of documents, its third-party dependencies can reach millions of lines. Without exclusion, meaningful reasoning becomes impossible.
-
-Second, Augment provides a context indexing and selection engine. It indexes both code and documentation and clearly shows what has been indexed. For each query, it dynamically selects the most relevant context depending on the task — whether it is answering usage questions, developing new features, fixing bugs, or re-investigating reported issues. In my experience, this context engine works extremely well, with very few hallucinations.
-
-Third, Augment follows project guidelines very strictly. For SRS, this is crucial. The project uses C++98 only, does not support newer C++ standards, and relies on a custom smart pointer implementation rather than the C++11 standard library. These constraints are non-negotiable, and Augment consistently respected them. While guideline support is not unique to Augment, strict adherence is a key factor that made AI-driven management viable in practice.
-
-For these reasons, after trying multiple tools, Augment was the only solution that worked reliably for managing SRS at the project level — not just writing code, but understanding context, respecting constraints, and operating within a complex, real-world open-source environment.
-
-## The Limitations and Risks of Using Augment
-While Augment proved to be the only practical solution for managing the SRS open-source project at scale, it also exposes several important limitations and risks. These weaknesses are not flaws of implementation, but rather structural trade-offs that anyone adopting AI-driven project management must understand.
-
-Context Engine vs. Code Privacy: Augment relies on indexing the full codebase and documentation to ensure it always works with the latest and most accurate context. This is ideal for open-source projects, where code is already public.
-
-However, this approach does not work well for commercial or private projects. Uploading proprietary code to a third-party server for indexing introduces security and confidentiality risks that many organizations cannot accept. As a result, Augment is far better suited for open-source projects than for closed-source or sensitive systems.
-
-Cost, Token Usage, and Scalability: Cost is another practical concern. At around $200 per month, Augment may be acceptable for a company but is already expensive for individual maintainers.
-
-More importantly, cost scales with project size, number of repositories, and model choice. Newer models can be significantly more expensive, and because the context engine dynamically decides what to load, users have limited control over token consumption. This makes costs harder to predict and, in some cases, difficult to control.
-
-Hallucination in Issue Handling: Hallucinations are rare in practice, but they become risky when handling issues. Issue reports often contain misleading descriptions, false assumptions, or outdated information.
-
-By default, AI tends to trust the input it receives. When an issue itself is wrong, the AI may produce confident but incorrect analysis. This problem cannot be fully eliminated, because it originates from human input. Therefore, verification and review must always be part of the workflow, especially for bug reports and investigations.
-
-The Human Growth Problem: The most subtle risk is its impact on human development. A good open-source project should not only deliver features, but also improve the design, architecture, and reasoning skills of its maintainers.
-
-Because Augment’s context engine can handle poorly organized or inconsistent code, it may reduce the incentive to maintain clean structure, strong abstractions, and clear design patterns. Over time, this can lead to code that is optimized for AI understanding rather than human understanding.
-
-If maintainers fully trust AI output without careful review and intentional design, the project may become increasingly dependent on AI and harder for humans to maintain. From a long-term perspective, this is a serious risk that requires discipline and conscious control.
-
-## What I Plan to Explore Next
-While Augment works well today, my long-term goal is not to depend on a single AI product. Instead, I want to explore general patterns and approaches that allow software engineers to use AI tools effectively — across both open-source and commercial projects.
-
-Avoiding Tool Lock-In: Relying on one AI product inevitably limits flexibility. Even if a tool works well now, its constraints become your constraints.
-
-My goal is to separate methodology from tooling — so that workflows remain valid even as AI models and products change. Ideally, switching tools should not require redesigning the entire development process.
-
-Reclaiming the Context Engine: Inspired by The New Calculus of AI-based Coding, one idea I want to explore is manually managing context, instead of fully relying on an AI product’s built-in context engine.
-
-This means designing code structure, documentation, and project layout in a way that is easier for AI to search, load, and reason about — while still being understandable and maintainable for humans. Context should be an explicit design artifact, not an opaque byproduct.
-
-Designing for AI First, but Not AI Only: Before AI, good software design was optimized primarily for human understanding. In the AI era, this assumption may need to evolve.
-
-I want to explore AI-friendly system design, while still preserving human readability, architectural clarity, and long-term maintainability. AI should benefit from structure — but humans must never lose the ability to understand or control the system.
-
-Re-evaluating Other AI Tools: With better context design, I plan to revisit other AI tools such as GitHub Copilot, Cloud Code, Amazon Q, and others.
-
-If these tools start to work well under improved structure, it would suggest that the key problem is how context is presented. This would make the approach portable across projects and environments.
-
-An Ongoing Experiment: I fully acknowledge that I may be wrong. Future AI tools or models may prove that manual context design is unnecessary.
-
-For now, this is an experiment: discovering how software engineers can stay in the loop, grow their skills, and use AI as a force multiplier. I plan to continue documenting what I learn and sharing the takeaways with the community.

.openclaw/docs/youtube/how-i-used-ai-to-improve-my-english-for-open-source-collaboration.md

@@ -1,75 +0,0 @@
-# How I Used AI to Improve My English for Open-Source Collaboration
-
-- **Author:** William
-- **Published:** 2026-01-21
-- **URL:** https://youtu.be/P1Y1z2Zzrg0
-
-> ⚠️ **Note:** This is a transcript from a specific date. Information may be outdated. Do not treat as authoritative — verify against current codebase and documentation.
-
-As a software engineer and open-source community maintainer, English communication is essential for my daily work. For a long time, my English listening and speaking were a real bottleneck, even after working in an English environment.
-
-In early 2025, my CELPIP scores for listening and speaking were both 6, and I still depended heavily on subtitles in meetings and avoided speaking when possible. After using AI consistently for daily listening and speaking practice, my scores improved to 8, and more importantly, my real-life performance changed: I can now follow meetings without subtitles and express my ideas more naturally.
-
-In this article, I share how I used AI to improve my English listening and speaking so I could communicate more effectively in a global open-source community.
-
-## Why I Need to Learn English — and Why Speaking Became My Bottleneck
-
-There is a common belief that once you live in an English-speaking environment, language skills will naturally improve within a few months. My experience proved otherwise. I work in Canada, my colleagues are mostly in the United States, and English is the working language. Yet after many months, my listening and speaking were still weak. The reality is simple: environment alone does not guarantee practice, and exposure does not automatically turn into ability.
-
-I need to learn English not because one language is better than another, but because English is the shared working language of software development. Code, documentation, and open-source communities all rely on English. Writing and communicating in English makes collaboration easier for others, even if it costs me more effort. Relying on translation tools every time creates friction, especially in real-time discussions where clarity and speed matter.
-
-Speaking became my biggest bottleneck because it is the easiest skill to avoid. In daily work, I could listen more than I spoke. Reading felt familiar as a programmer, and writing could always be revised. Speaking, however, requires instant output. There is no time to think, no chance to edit. Over time, avoidance turned into habit, and habit turned into low confidence.
-
-This gap showed clearly in both my work and my test scores. Other skills improved slowly, but speaking stayed behind. The problem was not a lack of effort or discipline — it was the lack of sustained, low-pressure speaking practice. Realizing why I needed English, and why speaking was holding everything back, was the first step toward changing how I learned.
-
-## How I Rebuilt My Listening with AI
-
-Listening was the first skill I chose to focus on, because without it, everything else felt unstable. If I could not understand what others were saying, speaking confidence was impossible, and meetings were exhausting. I eventually realized that weak listening was the real bottleneck behind most of my communication problems.
-
-The most important mindset shift was letting go of the idea that listening practice only works when I understand everything. For years, I treated listening like reading comprehension: if I did not understand a sentence, I replayed it, translated it, or gave up. This approach made listening stressful and inefficient. Instead, I adopted a more natural rule: keep listening, even when large parts are unclear. Understanding comes later, not first.
-
-Content choice mattered more than difficulty. Simplified materials, such as children’s cartoons, did not work well for me because I was not genuinely interested in them. I switched to content I actually cared about, such as news analysis, long-form discussions, and TED-style talks. Even when I understood very little at the beginning, interest kept me engaged long enough for improvement to happen.
-
-AI supported this process, but not by translating everything. I tried to avoid direct translation as much as possible. When a word or phrase felt important, I paused and asked AI about it in English. The explanation itself became additional listening input and helped me stay in English instead of switching back to my native language.
-
-For content I found especially interesting, I combined extensive and intensive listening. I listened first for overall meaning, then revisited parts with subtitles or AI assistance. Because the topic already made sense, details became easier to absorb without frustration.
-
-Over time, listening stopped feeling like training and became a natural habit. I was no longer practicing English; I was simply listening to things I wanted to understand. The biggest value of AI was not intelligence or accuracy, but patience. It allowed me to stay in English longer, with less stress, until my listening ability finally caught up.
-
-## How I Used AI to Break Through My Speaking Barrier
-
-After rebuilding my listening skills, I realized that speaking was still lagging behind. I could understand meetings much better, but when it was my turn to talk, I often hesitated or chose silence. Listening alone was not enough. Speaking required deliberate, sustained output, and it was the part I had avoided the longest.
-
-Speaking is fundamentally different from reading and writing. When speaking, there is no time to think carefully or revise sentences. You must produce language instantly, even when your thoughts are unclear. This pressure made speaking easy to avoid in real life, especially at work, where listening quietly was usually acceptable.
-
-AI changed this dynamic by removing social pressure. I could speak freely without worrying about judgment, impatience, or embarrassment. Mistakes were allowed, pauses were acceptable, and repetition was unlimited. This low-pressure environment made daily speaking practice possible for the first time.
-
-One key mistake I made early on was letting AI lead the conversation. Casual, unfocused chatting quickly became boring and ineffective. I learned that speaking practice works best when I bring my own content. If I had nothing real to say, the practice had little value.
-
-Daily life turned out to be the best source of speaking material. I described what I was cooking, summarized news I had just listened to, explained my work tasks, or talked through my daily diary aloud. When I got stuck, AI helped me rephrase or offered alternative expressions, which I immediately reused in my own speech.
-
-I also combined speaking with listening instead of treating them as separate skills. While listening to news or reading books, I discussed unfamiliar words with AI in English instead of translating them. Explaining a word back in my own sentences helped turn passive vocabulary into active speaking ability.
-
-Another important habit was learning to pause while speaking. I noticed that I tended to speak too fast, with few breaks, which hurt clarity and fluency. By consciously adding pauses between sentences, I gained time to think and made my speech easier to follow.
-
-Over several months, speaking slowly became more natural. I was no longer practicing isolated sentences; I was practicing expressing real thoughts. The improvement showed not only in test scores, but in meetings, discussions, and my willingness to speak up.
-
-AI did not make me fluent automatically. What it did was make consistent speaking practice possible. By lowering friction and pressure, it allowed speaking to become a daily habit rather than a stressful event. That consistency was what finally moved my spoken English forward.
-
-## Looking Ahead: Building Toward Fluent Expression
-
-Reaching a CELPIP score of 8 showed me that my approach was working, but it also made my next goal clearer. I want to continue practicing until I can reach a CELPIP 10, which, to me, represents the ability to express myself fluently and precisely in English. This is not just about a test score, but about communicating ideas naturally without hesitation.
-
-I do not expect this level to come from shortcuts or tricks. Progress at this stage depends almost entirely on time, repetition, and consistency. My plan is simple: keep practicing every day and let improvement accumulate gradually.
-
-At the moment, I spend about four to five hours a day on English. This time is not arranged as formal study blocks. Instead, it is integrated into my daily routine so that learning feels sustainable rather than exhausting.
-
-Every morning, while preparing breakfast, I listen to English news or podcasts. This has become a stable listening habit rather than a conscious training session. It helps me stay exposed to natural speech patterns and current topics without adding pressure.
-
-After listening, I usually discuss my thoughts with AI. Sometimes this takes the form of a spoken diary, where I talk through what I heard or reflect on my own day. Once I can express the ideas clearly in speech, I write them down. This process connects listening, speaking, and writing into a single loop.
-
-I plan to continue refining this routine and adjusting it as my ability improves. The goal is not to rush toward a number, but to make fluent English expression a natural part of my thinking and communication. As this process continues, I will share what works, what changes, and how far consistent practice can really take me.
-
-## Conclusion
-
-In the end, improving my English was not about talent, environment, or finding the perfect method, but about making long-term practice possible. AI did not replace effort or thinking; it removed friction and lowered the cost of daily listening and speaking, which allowed consistency to take over. By turning English into part of my everyday life rather than a separate task, real progress became inevitable. This experience convinced me that with enough meaningful input, honest output, and sustained time, fluent communication is not a privilege reserved for a few, but a reachable outcome for anyone willing to keep going.

.openclaw/docs/youtube/the-real-bottleneck-ai-open-source.md

@@ -1,68 +0,0 @@
-# The Real Bottleneck Stopping AI From Managing Open Source Projects
-
-## 1. What's wrong?
-
-AI can't manage open source projects like SRS — and it's not because models aren't powerful enough.
-
-AI is getting smarter and smarter. So smart that people believe it will eventually manage codebases, fix bugs, develop features, and maintain whole projects. But AI still can't manage large, real-world open source projects — and I don't think it will, at least not by “just waiting.” The core problem isn't the AI model.
-
-## 2. Why is it a problem?
-
-- Maintainers get tired and burn out. Projects slow down and get stuck. When maintainers leave, a lot of knowledge leaves with them.
-- The common assumption — "just wait for smarter models" — is wrong.
-- Even the most powerful models can't understand the *why* behind code when nobody has explained it.
-
-## 3. What exactly needs solving?
-
-Two missing foundations:
-
-**1) AI-native knowledge**
-- Human documentation explains *what*, not *why*
-- The reasoning, design decisions, and tradeoffs often live in the maintainer's head
-- Most knowledge and experience is never written down or shared online
-- Even with all the docs and code, AI doesn't understand each line because it doesn't know the background
-- Some things are forgotten — sometimes literally nobody knows anymore
-
-**2) Verifiable code structure**
-- Without good tests and checks, AI can't verify its own changes
-- This depends on foundation #1 — you need to understand *why* code exists to write meaningful tests
-
-The bottleneck isn't intelligence. It's knowledge that was never written down.
-
-## 4. What can be done?
-
-Build an AI-native knowledge base through conversation:
-
-- Tools like Augment have context engines that index code and docs — but it's a black box, and it can pull in flawed or outdated information
-- Instead: build the knowledge base *conversationally* through AI memory (the OpenClaw approach)
-- You control what goes in. You can correct mistakes. You add the *why* that never made it into docs.
-- The memory files *are* the context engine — transparent and human-curated
-
-The process:
-- Walk with AI, work with AI, talk to AI
-- Go through docs, code, and protocols together
-- Discuss everything
-- Move what's in your mind into the knowledge base
-
-## 5. Why will it work?
-
-- Unlike black-box indexing: you control the input
-- You can correct misinformation and outdated content
-- You capture the *why* — the reasoning that exists only in your head
-- Code and docs are artifacts; the knowledge base captures the thinking behind them
-- It's collaborative and iterative
-- Over time, AI can maintain and update the knowledge base too — it becomes self-sustaining
-
-## 6. What should we do next?
-
-Start building your project's AI-native knowledge base:
-
-1. Choose a tool that supports persistent memory (OpenClaw, or similar)
-2. Start transferring knowledge through conversation — not just facts, but reasoning
-3. Go through your codebase with AI, explain the *why*
-4. Let AI work with you, and update the knowledge base as you go
-5. Eventually: AI develops features, fixes bugs, and maintains the knowledge base itself
-
----
-
-*The bottleneck isn't smarter models. It's the knowledge in your head that was never written down.*

.openclaw/docs/youtube/youtube-channel.md

@@ -1,60 +0,0 @@
-# SRS YouTube Channel
-
-> ⚠️ **IMPORTANT FOR AI AGENTS:** Documents in this folder are transcripts from YouTube videos. They may contain outdated information, opinions that have since changed, or ideas that were later revised. **Do not use these as a reliable knowledge base.** These documents represent thoughts at a specific point in time — not current truth. Always verify against the main SRS codebase, documentation, and current project state.
-
-## About (Official Description)
-At SRS, our goal is to create a non-profit, open-source community that makes it easy for everyone to boost their businesses using video streaming!
-
-**SRS** is a simple, high-efficiency, real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, RTSP, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711. After more than ten years of work, SRS has become the most popular media server on GitHub, with many developers around the world valued it.
-
-**Oryx** is a video solution that is lightweight, open-source, and based on Go, Reactjs, SRS, FFmpeg, WebRTC, etc. The Oryx is an all-in-one video streaming tool that can be used for different purposes, like streaming on YouTube and Twitch, WordPress and WooCommerce, and Unity. It makes adding video streaming to your business super easy, giving you more than just a media server, but a solution.
-
-## Community
-- **Discord:** https://discord.gg/yZ4BnPmHAd
-
-## Purpose
-Official YouTube channel for the SRS open source project, covering:
-1. **Tutorials** — How to use SRS (setup, configuration, protocols, features)
-2. **AI-assisted development** — Research on using AI to manage open source projects
-
-## Meta-Purpose
-The channel documents William training an AI (SRSBot) with his knowledge base. This serves as:
-- Proof-of-concept for AI-managed open source
-- Educational content showing how AI can learn and teach a complex project
-- A model for scaling maintainer expertise across a community
-
-## Value for Viewers
-- Learn SRS directly from the maintainer
-- Learn how to use AI to understand/customize/extend SRS
-- Learn how to apply AI-assisted maintenance to their own projects
-
-## Channel Details
-- **YouTube:** https://www.youtube.com/@srs_server
-- **Twitter/X:** https://x.com/srs_server
-- **Channel created:** 2021-11-21
-- **Primary language:** English
-- **Content format:** Podcast (audio + video)
-
-## Playlists
-
-### Running Open Source with AI
-- **URL:** https://www.youtube.com/playlist?list=PLAc09vdRb0Tcf0A0IIUEQOvTjlWcA_oi6
-- **Description:** Podcast series documenting the experiment of using AI to manage an open source project — the methodology, tools, lessons learned, and personal journey.
-
-## Video Index
-
-### 1. After 12 Years of Maintaining SRS, I Let AI Run the Project
-- **Playlist:** Running Open Source with AI
-- **Published:** 2026-01-10
-- **URL:** https://youtu.be/evN70DjiwcU
-- **Transcript:** `after-12-years-of-maintaining-srs-i-let-ai-run-the-project.md`
-- **Summary:** William shares how AI (Augment) now manages SRS end-to-end: issues reduced from ~200 to ~10, test coverage 50%→88%, IPv6 support completed across all protocols. Covers why Augment over Copilot/Cursor/Claude Code (context engine, guideline adherence, codebase exclusion). Discusses limitations: privacy concerns for commercial projects, cost (~$200/mo), hallucinations on bad input, human growth risk. Future plans: avoid tool lock-in, manual context management, AI-friendly system design.
-- **Relevance:** Core manifesto for AI-managed open source — proves the concept works at scale.
-
-### 2. How I Used AI to Improve My English for Open Source Collaboration
-- **Playlist:** Running Open Source with AI
-- **Published:** 2026-01-21
-- **URL:** https://youtu.be/P1Y1z2Zzrg0
-- **Transcript:** `how-i-used-ai-to-improve-my-english-for-open-source-collaboration.md`
-- **Summary:** William shares his journey improving English listening/speaking (CELPIP 6→8) using AI for daily practice. Key insights: environment alone doesn't teach language; AI removes social pressure from speaking practice; integrate learning into daily routines (4-5 hrs/day); combine listening→speaking→writing into a loop.
-- **Relevance:** Shows how AI enables global open source collaboration by helping non-native speakers communicate effectively.

.openclaw/internal

@@ -0,0 +1 @@
+../internal

.openclaw/memory/srs-codebase-map.md

@@ -0,0 +1,352 @@
+# SRS Codebase Map
+
+⚠️ **CRITICAL RULE:** Only files explicitly listed in this document are trusted. AI must NOT discover, reference, or use any file that is not listed here. If a file is not in this map, it does not exist for AI purposes.
+
+This file helps AI navigate the SRS project. Instead of grepping blindly, AI should use this map to reason about which part of the codebase is relevant to a question, then go directly to the right files.
+
+## Code Structure
+
+SRS has three codebases:
+
+### C++ Media Server
+
+The C++ media server (`trunk/src/`) serves as both origin server and edge server. It uses the ST (State Threads) coroutine library and is the full-featured server with all SRS capabilities.
+
+`main/` — Entry point:
+- `main_server` — The `main()` function, starts the server
+
+`core/` — Foundational definitions:
+- `core` — Core includes, macros, config generated by configure
+- `core_version` through `core_version7` — Version definitions per major release
+- `core_autofree` — SrsUniquePtr smart pointer (RAII)
+- `core_deprecated` — Deprecated SrsAutoFree, kept for compat
+- `core_performance` — Performance tuning constants (merge-read, etc.)
+- `core_platform` — Platform abstraction (32/64-bit, PRId64, large file support)
+- `core_time` — Time types and conversions (srs_utime_t, ms/us)
+
+`kernel/` — Low-level building blocks, no network, no protocol logic:
+
+Media codecs/containers:
+- `kernel_codec` — Codec definitions, H.264/H.265/AAC parsing, sequence headers
+- `kernel_aac` — AAC transmuxer (raw AAC stream output)
+- `kernel_mp3` — MP3 transmuxer
+- `kernel_flv` — FLV tag reader/writer, muxer/demuxer
+- `kernel_mp4` — MP4/fMP4 box reader/writer
+- `kernel_ts` — MPEG-TS muxer/demuxer
+- `kernel_ps` — PS (Program Stream) muxer/demuxer (GB28181)
+- `kernel_packet` — Media packet: raw undecoded frame with timing info
+
+Buffers & I/O:
+- `kernel_buffer` — SrsBuffer: binary read/write cursor over a byte array
+- `kernel_stream` — SrsSimpleStream: growable byte buffer
+- `kernel_io` — Abstract I/O interfaces (ISrsReader, ISrsSeeker, ISrsWriter)
+- `kernel_file` — File reader/writer implementations
+
+RTC primitives:
+- `kernel_rtc_rtp` — RTP packet structure, encode/decode
+- `kernel_rtc_rtcp` — RTCP packet types, encode/decode
+- `kernel_rtc_queue` — RTP ring buffer and reorder queue
+
+Utilities:
+- `kernel_error` — Error code definitions and SrsCplxError
+- `kernel_log` — Log levels and ISrsLog interface
+- `kernel_consts` — Global constants (chunk sizes, timeouts, limits)
+- `kernel_utility` — System time, string helpers, bit buffer
+- `kernel_kbps` — Bandwidth statistics (ISrsProtocolStatistic, ISrsClock)
+- `kernel_balance` — Load balancing algorithms (round-robin)
+- `kernel_hourglass` — Timer/hourglass coroutine (periodic callbacks)
+- `kernel_pithy_print` — Sampled logging (print every N seconds, not every call)
+- `kernel_factory` — Abstract factory interfaces (ISrsKernelFactory)
+- `kernel_resource` — Resource management interfaces (ISrsResource, disposing)
+- `kernel_st` — ST coroutine wrappers (ISrsCoroutine, ISrsCoroutineHandler)
+
+`protocol/` — Protocol implementations (wire formats, parsing, serialization):
+
+RTMP:
+- `protocol_rtmp_stack` — RTMP chunk stream, message parsing, AMF commands
+- `protocol_rtmp_conn` — RTMP client/server handshake and command exchange
+- `protocol_rtmp_handshake` — RTMP handshake (simple and complex)
+- `protocol_rtmp_msg_array` — Shared message array with auto-free
+- `protocol_amf0` — AMF0 encoding/decoding
+
+HTTP:
+- `protocol_http_stack` — HTTP message, header, URI, serve mux, handler
+- `protocol_http_conn` — HTTP connection parsing (request/response)
+- `protocol_http_client` — HTTP client for outbound requests
+- `protocol_http_stack_llhttp` — llhttp parser (from Node.js)
+- `protocol_http_stack_llhttpadapter` — llhttp adapter for SRS
+- `protocol_http_stack_llhttpapi` — llhttp API integration
+- `protocol_http_stack_llhttphttp` — llhttp HTTP integration
+
+RTC/WebRTC:
+- `protocol_rtc_stun` — STUN packet parsing/building
+- `protocol_sdp` — SDP parsing/building
+- `protocol_rtp` — RTP packetizer (H.264/Opus → RTP packets)
+
+Other protocols:
+- `protocol_srt` — SRT socket wrapper
+- `protocol_rtsp_stack` — RTSP message parsing
+
+Media:
+- `protocol_raw_avc` — Raw H.264/H.265 stream (Annex-B ↔ AVCC conversion)
+- `protocol_format` — Media format: extract metadata, codec info from RTMP stream
+
+Infrastructure:
+- `protocol_io` — Protocol-level I/O interfaces (ISrsProtocolReader/Writer)
+- `protocol_st` — ST initialization, socket helpers, TCP/UDP wrappers
+- `protocol_stream` — SrsFastStream: merge-read buffered stream
+- `protocol_conn` — Base connection interface (ISrsConnection)
+- `protocol_log` — Thread context for logging (SrsThreadContext)
+- `protocol_json` — JSON parsing (SrsJsonAny)
+- `protocol_utility` — URL parsing, stream URL helpers
+- `protocol_protobuf` — Protobuf encoding helpers (for Prometheus/exporter)
+
+`app/` — Application logic (server features, connections, business logic):
+
+Server core:
+- `app_server` — SrsServer: main server, manages listeners and connections
+- `app_config` — Configuration parsing and access
+- `app_listener` — TCP/UDP listener management
+- `app_reload` — Config hot-reload handler interface
+- `app_st` — Coroutine implementations (SrsFastCoroutine, SrsExecutorCoroutine)
+- `app_log` — File-based logger implementation
+
+RTMP:
+- `app_rtmp_conn` — RTMP client connection lifecycle (publish, play)
+- `app_rtmp_source` — RTMP live source: manages consumers, GOP cache, hub
+
+HTTP:
+- `app_http_api` — HTTP API endpoints (/api/v1/...)
+- `app_http_conn` — HTTP connection handler (routes to static/stream/api)
+- `app_http_hooks` — HTTP callback hooks (on_connect, on_publish, etc.)
+- `app_http_static` — HTTP static file serving
+- `app_http_stream` — HTTP live streaming (FLV, TS, AAC, MP3 over HTTP)
+- `app_http_client` — HTTP client utilities
+
+WebRTC:
+- `app_rtc_server` — RTC server: manages RTC connections
+- `app_rtc_conn` — RTC connection: publish/play session, DTLS/SRTP
+- `app_rtc_source` — RTC source: manages RTC consumers and tracks
+- `app_rtc_api` — WHIP/WHEP API endpoints
+- `app_rtc_codec` — Audio transcoding (AAC ↔ Opus via FFmpeg)
+- `app_rtc_dtls` — DTLS certificate and handshake
+- `app_rtc_network` — RTC network I/O, UDP mux
+
+SRT:
+- `app_srt_server` — SRT server: manages SRT connections
+- `app_srt_conn` — SRT connection lifecycle (publish, play)
+- `app_srt_source` — SRT source: manages SRT consumers
+- `app_srt_listener` — SRT listener (bind/accept)
+
+RTSP:
+- `app_rtsp_conn` — RTSP connection handler
+- `app_rtsp_source` — RTSP source
+
+GB28181:
+- `app_gb28181` — GB28181 SIP signaling and PS stream ingestion
+
+HLS/DASH:
+- `app_hls` — HLS muxer (TS segments + M3U8 playlist)
+- `app_dash` — DASH muxer (fMP4 segments + MPD manifest)
+- `app_fragment` — Fragment/segment interface for HLS/DASH
+
+DVR:
+- `app_dvr` — DVR recording (FLV/MP4 to disk)
+
+Edge/Forward/Bridge:
+- `app_edge` — Edge mode: pull/push from origin
+- `app_forward` — Forward: push stream to another RTMP server
+- `app_stream_bridge` — Bridge between sources (RTMP↔RTC↔SRT)
+
+Ingest/Transcode:
+- `app_ingest` — Ingest: pull external streams via FFmpeg
+- `app_encoder` — Transcode: FFmpeg transcoding management
+- `app_ffmpeg` — FFmpeg process wrapper
+
+Utilities:
+- `app_security` — Security: allow/deny rules for publish/play
+- `app_refer` — Referer check
+- `app_statistic` — Server/stream/client statistics
+- `app_heartbeat` — HTTP heartbeat to API server
+- `app_utility` — System info, disk/CPU/memory stats
+- `app_process` — Child process management
+- `app_async_call` — Async HTTP callback execution
+- `app_recv_thread` — Background RTMP message receive thread
+- `app_ng_exec` — exec hooks (on_publish exec)
+- `app_factory` — Application-level factory (file I/O, paths)
+- `app_coworkers` — Origin cluster coordination
+- `app_latest_version` — Version check against upstream
+- `app_caster_flv` — HTTP-FLV push ingest (stream caster)
+- `app_mpegts_udp` — MPEG-TS over UDP ingest
+- `app_stream_token` — Stream publish token management
+- `app_circuit_breaker` — Circuit breaker for overload protection
+- `app_hds` — HDS (Adobe HTTP Dynamic Streaming)
+
+**File naming convention:** All C++ source files use `srs_{module}_{topic}.cpp/.hpp` — e.g. `srs_app_rtmp_conn.cpp`, `srs_protocol_amf0.hpp`, `srs_kernel_flv.cpp`.
+
+**Config**
+
+Config (`trunk/conf/`) is only for the C++ media server. The next-generation Go server does not use these config files.
+
+- `srs.conf` — Default config
+- `full.conf` — Full reference config with all options documented
+- Feature-specific configs: `rtc.conf`, `srt.conf`, `hls.conf`, `dvr.*.conf`, `edge.conf`, `forward.*.conf`, `gb28181.conf`, `dash.conf`, etc.
+
+### State Threads
+
+State Threads (`trunk/3rdparty/st-srs/`) is the coroutine library used by the C++ media server only. The Go server does not use ST.
+
+- `sched.c` — Scheduler (thread creation, context switch, run loop)
+- `io.c` — I/O: poll/epoll/kqueue wrappers, socket operations
+- `event.c` — Event system
+- `stk.c` — Stack allocation and management
+- `sync.c` — Mutex, condition variable
+- `key.c` — Thread-local storage
+- `common.c`/`common.h` — Shared internals
+- `public.h` — Public API
+- `md.h` — Platform detection and context switch macros
+- `md_linux.S`, `md_linux2.S`, `md_darwin.S`, `md_cygwin64.S` — Assembly context switch per platform
+
+### Next-Generation Server
+
+The next-generation server (`cmd/` + `internal/`) is written in Go and maintained by AI. It is the future of SRS. Currently it only supports proxy, but work is ongoing to support the full feature set including origin, edge, and proxy servers.
+
+`cmd/proxy` — A stateless reverse proxy that sits in front of one or more SRS C++ origin servers. Accepts client connections (RTMP, HTTP-FLV/HLS, WebRTC WHIP/WHEP, SRT), resolves a backend origin via the load balancer, and transparently proxies traffic. Does not cache streams or process media — only forwards bytes. Configuration entirely via environment variables (or `.env` file), no config file. Supports two deployment modes: single-proxy (in-memory LB) and multi-proxy (Redis-based shared LB for horizontal scaling behind a network load balancer).
+
+`internal/bootstrap` — Server startup and lifecycle orchestration. Sets up logging context, signal handlers, loads environment, installs force-quit timer, optionally starts pprof, initializes the load balancer (memory or Redis based on `PROXY_LOAD_BALANCER_TYPE`), then starts all six servers sequentially (RTMP, WebRTC, HTTP API, SRT, System API, HTTP Stream) and blocks until context is cancelled. Deferred `Close()` on each server ensures graceful shutdown.
+
+`internal/protocol` — Protocol proxy servers. Each server accepts client connections, parses just enough of the protocol to extract the stream URL, picks a backend via the load balancer, and proxies traffic bidirectionally. Contains five proxy servers: (1) **RTMP proxy** — TCP listener, simple handshake, parses connect/publish/play to get stream URL, bidirectional RTMP message copying, stateless. (2) **HTTP stream proxy** — serves static files, proxies HTTP-FLV/TS via reverse-proxy, proxies HLS m3u8 with `spbhid` rewriting so TS segment requests route to the same backend. (3) **WebRTC proxy** — two-phase: WHIP/WHEP signaling (SDP rewrite to replace backend UDP port with proxy's) + UDP media transport (identifies connections by STUN ufrag, supports address migration), stateful. (4) **SRT proxy** — intercepts SRT 4-step handshake locally, parses stream ID on handshake 2, replays full handshake with backend, then proxies UDP bidirectionally, stateful per-connection. (5) **HTTP API + System API** — HTTP API delegates WHIP/WHEP to WebRTC server; System API provides `/api/v1/srs/register` where backend SRS C++ servers register themselves so the load balancer knows about them.
+
+`internal/rtmp` — RTMP protocol implementation (parsing, not proxying). Full RTMP chunk stream and message protocol: simple handshake (C0/C1/C2), chunk stream reader/writer with all four format types, extended timestamp, message reassembly from chunks. Defines all RTMP message types, chunk stream IDs, and command names. Packet types include ConnectApp, CreateStream, Publish, Play, Call, SetChunkSize, WindowAcknowledgementSize, SetPeerBandwidth, UserControl. Uses Go generics (`ExpectPacket[T]`) to read until a specific packet type arrives. Also includes full AMF0 encoder/decoder supporting Number, Boolean, String, Object, Null, Undefined, EcmaArray, StrictArray, Date, LongString — with ordered key-value maps, auto-type-discovery, and safe type converters.
+
+`internal/lb` — Load balancer abstraction and two implementations. Defines `SRSLoadBalancer` interface (Initialize, Update, Pick, HLS/WebRTC state management) and `SRSServer` struct representing a backend origin (IP, listen endpoints for RTMP/HTTP/API/SRT/RTC, heartbeat tracking). **Memory LB** — in-memory using `sync.Map`, sticky random pick per stream URL, single-proxy deployment. **Redis LB** — Redis-backed shared state with TTL-based expiration, enables multi-proxy horizontal scaling behind a network load balancer. Also includes a debug helper that creates a fake backend from env vars when `PROXY_DEFAULT_BACKEND_ENABLED=on` for development without real SRS registration.
+
+`internal/logger` — Structured logging with context IDs. Four log levels: Verbose (discarded), Debug (stdout), Warn (stderr), Error (stderr). Format: `[level][pid][cid] message`. Each connection/request gets a unique 7-char hex context ID for log correlation, stored in `context.Context`.
+
+`internal/env` — Environment-based configuration. All settings via env vars (or `.env` file via godotenv). Exposes an `Environment` interface with methods for each config value. Default ports: RTMP=11935, HTTP API=11985, HTTP Stream=18080, WebRTC=18000, SRT=20080, System API=12025. Timeouts: grace=20s, force=30s. Supports Redis config and default backend config for debugging.
+
+`internal/version` — Version constants. `SRSProxy` v1.5.0. Used in HTTP API responses and startup logging.
+
+`internal/errors` — Error handling with stack traces, forked from `github.com/pkg/errors`. Provides `New`, `Errorf`, `Wrap`, `Wrapf`, `WithMessage`, `WithStack`, `Cause`. Every error captures a stack trace at creation; `%+v` prints the full trace. `Cause()` walks the error chain to find the root error.
+
+`internal/sync` — Generic sync primitives. `Map[K, V]`: type-safe generic wrapper around `sync.Map` with proper Go generics typing. Used throughout the codebase to avoid raw type assertions.
+
+`internal/signal` — OS signal handling. Listens for SIGINT/SIGTERM, cancels the root context. Installs a force-quit timer (default 30s) as a safety net if graceful shutdown hangs.
+
+`internal/debug` — Profiling. Starts a `net/http/pprof` server if `GO_PPROF` env var is set. Optional, for runtime profiling and debugging.
+
+`internal/utils` — Shared utility functions. HTTP helpers (JSON response, error response, CORS, body parsing). URL helpers (normalize to `vhost/app/stream` format, extract app/stream from HTTP requests). Protocol helpers (classify UDP payload as STUN/RTP/SRT, parse ICE ufrag/pwd from SDP, parse SRT stream ID). Network helpers (detect peer-closed/connection-closed errors, parse listen endpoints).
+
+## Knowledge Base Structure
+
+The knowledge base (`memory/srs-*.md`) captures William's knowledge about SRS — architecture, design decisions, protocols, and how things work. This is the AI's first stop for understanding *why* things are the way they are.
+
+- `memory/srs-overview.md` — What SRS is, protocols, ecosystem tools, and features list
+- `memory/srs-coroutines.md` — State Threads coroutine library, why SRS uses coroutines, how context switching works, platform matrix, multi-CPU strategy
+- `memory/srs-codebase-map.md` — This file: codebase structure, file navigation, module boundaries
+
+## Documentation Structure
+
+**Tracking** — Project changelog and version history:
+- `trunk/doc/CHANGELOG.md` — Full changelog of all SRS versions, one entry per merged PR with version bump
+
+**C++ Media Server Docs** (`trunk/3rdparty/srs-docs/doc/`) — User-facing documentation:
+- `introduction.md` — SRS overview: what it is, supported protocols (RTMP/WebRTC/HLS/SRT/etc.), features list, ST coroutine architecture, and learning path
+- `getting-started.md` — Quick start with Docker: live streaming (RTMP publish, HTTP-FLV/HLS play), WebRTC publish/play, RTMP-to-WebRTC conversion, HTTPS for WebRTC on remote servers, SRT publishing, and multiple streams with flexible URL patterns
+- `getting-started-ai.md` — AI tools for SRS: SRS Robot (Telegram/Discord), local agents (Claude Code, Codex, Kiro, OpenClaw) with pre-configured knowledge base, skills system for task-specific workflows, and the knowledge base philosophy (implicit knowledge made explicit)
+- `getting-started-build.md` — Build SRS from source: configure/make, live streaming and WebRTC setup, cross-build for ARM/MIPS
+- `getting-started-cdk.md` — Deploy SRS on AWS using srs-cdk (stub page, links to GitHub repo)
+- `getting-started-oryx.md` — Oryx (SRS Stack): out-of-the-box cloud solution with recording, forwarding, AI subtitles, HTTPS, Docker/HELM/aaPanel deployment
+- `rtmp.md` — RTMP protocol: usage, Enhanced RTMP (HEVC/AV1), config, RTMPS, comparison with SRT/WebRTC, codec support history
+- `hls.md` — HLS streaming: cross-platform compatibility, latency tradeoffs, config (segment duration, cleanup), HTTPS, audio transcoding from WebRTC
+- `webrtc.md` — WebRTC: WHIP/WHEP signaling, SFU architecture, RTMP-to-RTC conversion, TURN/ICE config, audio transcoding (AAC↔Opus), multi-platform usage
+- `flv.md` — HTTP-FLV live streaming: chunked HTTP delivery, ~3-5s latency, config, comparison with HLS and RTMP, browser compatibility (MSE)
+- `srt.md` — SRT protocol: UDP-based low-latency (300-500ms), TS encapsulation, HEVC support, config, streamid format, weak network advantages over RTMP
+- `rtsp.md` — RTSP playback server (v7.0.47+): TCP transport only, publish via RTMP then play via RTSP, config, compile with --rtsp=on
+- `http-server.md` — Embedded HTTP server: serves HLS/static files, API endpoint, config for port/root, works with NGINX/Caddy reverse proxy
+- `hevc.md` — H.265/HEVC support: Enhanced RTMP, protocol compatibility matrix (TS/SRT/HLS/RTMP/WebRTC), encoder setup, bandwidth savings vs H.264
+- `dvr.md` — DVR recording: save RTMP streams to FLV/MP4 files, config (plan/path), HTTP callbacks for dynamic DVR, Oryx for advanced features (S3, filters)
+- `ingest.md` — Ingest: pull external streams (files, RTSP cameras, HTTP) via FFmpeg and republish as RTMP to SRS, virtual live streaming use case
+- `forward.md` — Forward streams to other RTMP servers for fault backup, master/slave roles, config per vhost/app, comparison with edge mode
+- `security.md` — IP-based security: allow/deny rules for publish/play per vhost using IP addresses or CIDR ranges
+- `snapshot.md` — Stream thumbnails: capture snapshots via HTTP callbacks (on_publish/on_unpublish triggering FFmpeg) or transcoder
+- `http-api.md` — HTTP API (/api/v1/...): JSON endpoints for server/stream/client stats, srs-console integration, CORS support
+- `http-callback.md` — HTTP callbacks: SRS notifies your business server on events (on_connect, on_publish, on_play, on_dvr, etc.) for auth and custom logic
+- `exporter.md` — Prometheus exporter: metrics endpoint for Grafana integration, config for labels/tags, cloud-native observability
+- `origin-cluster.md` — Origin cluster: proxy-based load balancing across multiple origin servers, Go proxy architecture, replaces old RTMP-based origin cluster
+- `edge.md` — Edge server: caches streams from origin for massive playback scale, pull-on-play and push-on-publish, multi-level edge topology for CDN
+- `nginx-for-hls.md` — HLS/DASH distribution via NGINX reverse proxy with caching, edge cluster for file-based streaming (not RTMP edge)
+- `resource.md` — Ports reference: RTMP(1935), HTTP API(1985), HTTP streaming(8080), WebRTC(8000/udp), SRT(10080/udp), HTTPS, and optional converters
+- `low-latency.md` — Low-latency live streaming: RTMP tuning (0.8-3s), GOP/queue config, merge-write optimization, protocol comparison
+- `performance.md` — Performance tools: RTC UDP buffer tuning, perf/gprof/valgrind profiling, memory leak detection, ASAN, benchmarking methodology
+- `ffmpeg.md` — FFmpeg transcoding: SRS forks FFmpeg for 1-in-N-out transcoding, multi-bitrate output, stream filters (logo), config per vhost/app/stream
+
+**C++ Media Server Pages** (`trunk/3rdparty/srs-docs/pages/`) — Website pages (how SRS presents itself publicly):
+- `faq-oryx-en.md` — Oryx FAQ: getting started, upgrade, domain/HTTPS setup, push auth, recording (S3/filters/merge), re-streaming, FFmpeg replacement
+- `faq-server-en.md` — SRS server FAQ: CDN/VoD questions, common errors, protocol issues, links to Stack Overflow/GitHub Issues/Discord for support
+- `license-en.md` — License details: SRS is MIT, State Threads is MPL/GPL dual-license, plus licenses for all third-party libraries (OpenSSL, libsrt, ffmpeg, etc.)
+- `product-en.md` — Release history: milestones from v1.0 (2013) to v7.0 (2025+), codenames, key achievements per release, AI contributor era (2025+)
+- `security-advisories-en.md` — CVE reports: CVE-2024-29882 (JSONP XSS), CVE-2023-34105 (command injection in demo api-server), with patch versions and links
+
+**Next-Generation Server Docs** (`docs/proxy/`) — Documentation for the Go server:
+- `proxy-design.md` — Architecture: stateless proxy with built-in load balancing, single-proxy vs multi-proxy (Redis) deployment modes, horizontal scaling behind NLB
+- `proxy-protocol.md` — Backend registration protocol: default backend for debugging, automatic registration via SRS system API, heartbeat mechanism, env vars
+- `proxy-usage.md` — Step-by-step guide: build proxy, start SRS origin, verify registration, publish with FFmpeg, verify playback with ffprobe
+- `proxy-files.md` — Go codebase layout: cmd/proxy entry point, internal packages (debug, env, errors, lb, logger, protocol, rtmp, signal, sync, utils, version)
+- `proxy-load-balancer.md` — Load balancer design: memory vs Redis implementations, stream-to-server mapping, server health via heartbeats, protocol-specific state
+- `proxy-origin-cluster.md` — Origin cluster tutorial: build proxy + SRS, configure multi-origin with proxy, stream publishing and playback verification
+
+## Testing and Verification Structure
+
+How to verify SRS works correctly.
+
+`trunk/src/utest/` — Unit tests (white-box, testing internal logic):
+- **What it tests:** Internal logic — functions, classes, parsing, codec handling, config parsing — all without starting SRS. Links directly against SRS source code, uses mock objects (e.g., `MockSrsConfig`). No network, no server process. ~2,351 tests.
+- **Binary:** `./objs/srs_utest` (build with `cd trunk && ./configure --utest && make utest`)
+- 3 categories:
+- `srs_utest_ai01`–`ai24` — AI-written tests
+- `srs_utest_manual_*` — Manually written tests
+- `srs_utest_workflow_*` — Workflow/integration tests
+
+`trunk/3rdparty/srs-bench/blackbox/` — Black-box tests (testing SRS as a running server from outside):
+- **What it tests:** SRS as a running process, from the outside. Each test starts its own SRS server via `NewSRSServer()`, then uses FFmpeg/FFprobe to publish/play streams and verify output. The test manages the full SRS lifecycle. ~30 tests.
+- **Binary:** `./objs/srs_blackbox_test` (build with `make` in `trunk/3rdparty/srs-bench/`)
+- `rtmp_test.go` — RTMP black-box tests
+- `hls_test.go` — HLS black-box tests
+- `srt_test.go` — SRT black-box tests
+- `rtsp_test.go` — RTSP black-box tests
+- `hevc_test.go` — HEVC black-box tests
+- `dvr_test.go` — DVR black-box tests
+- `http_api_test.go` — HTTP API black-box tests
+- `mp3_test.go` — MP3 black-box tests
+
+`trunk/3rdparty/srs-bench/srs/` — E2E tests (end-to-end protocol testing):
+- **What it tests:** End-to-end protocol correctness against a pre-running SRS server (you start SRS yourself). Uses real protocol clients — Pion WebRTC library for RTC (WHIP/WHEP), RTMP client, HTTP API — to publish, play, and verify stream behavior. Heavy focus on WebRTC protocol correctness. ~45 tests.
+- **Binary:** `./objs/srs_test` (build with `make` in `trunk/3rdparty/srs-bench/`)
+- `rtc_test.go` — WebRTC E2E tests
+- `rtmp_test.go` — RTMP E2E tests
+- `srs_test.go` — General SRS E2E tests
+
+`trunk/3rdparty/srs-bench/` — Load test benchmark:
+- **What it tests:** Performance and load capacity — not correctness. A CLI tool that simulates many concurrent WHIP publishers, WHEP players, RTMP clients, etc. against a running SRS. Not a test suite — no pass/fail assertions, it's a benchmarking/stress tool.
+- **Binary:** `./objs/srs_bench` (entry: `main.go`, build with `make` in `trunk/3rdparty/srs-bench/`)
+- Publisher for WHIP
+- Player for WHEP
+- Multiple WHIP or WHEP for RTC
+- DVR for RTC Benchmark
+- RTC Plaintext
+- Reconnecting Load Test
+- Janus
+
+**Summary: The Key Differences**
+
+| | Unit Tests | Black-box | E2E | Benchmark |
+|---|---|---|---|---|
+| **SRS running?** | No | Yes (self-managed) | Yes (external) | Yes (external) |
+| **Tests what?** | Internal logic | Whole server behavior | Protocol correctness | Performance/load |
+| **Language** | C++ | Go | Go | Go |
+| **Network?** | No | Yes (real protocols) | Yes (real protocols) | Yes (real protocols) |
+| **Pass/fail?** | Yes | Yes | Yes | No (metrics only) |
+| **Count** | ~2,351 | ~30 | ~45 | N/A |
+
+Progression: unit (isolated logic) → black-box (server as a whole, self-contained) → E2E (protocol-level against live server) → benchmark (stress/capacity). Each layer catches different classes of bugs.

.openclaw/objs

@@ -0,0 +1 @@
+../trunk/objs

.openclaw/skills/srs-support/SKILL.md

@@ -7,79 +7,85 @@ description: Answer SRS (Simple Realtime Server) questions for developers and us
 
 Answer questions about SRS — a simple, high-efficiency, real-time media server — using the project's knowledge base.
 
-This skill is for **answering questions and providing guidance**. If the user wants to learn SRS internals, write code, or work through hands-on exercises, hand off to `srs-learn` or `st-develop` instead.
+This skill is for **answering questions and providing guidance**. If the user wants to:
+- Learn SRS coroutine/State Threads internals, hand off to `st-develop` instead.
 
-## Setup
+## Workflow
 
-Do **not** hardcode an absolute SRS path. Resolve `SRS_ROOT` dynamically:
+Follow these three steps in order for every question.
 
-1. If `SRS_ROOT` env is set and contains `trunk/src`, use it.
-2. Else, if current workspace (or its git root) contains `trunk/src`, use that.
-3. Else, if the parent folder of the workspace contains `trunk/src`, use that parent.
-4. Else, if `~/git/srs/trunk/src` exists, use `~/git/srs`.
-5. Else, ask the user for the SRS repo root.
+## Step 1: Setup
 
-## Loading Knowledge
+All files are in the current working directory. Find everything from here — no discovery logic needed.
 
-Load knowledge selectively based on the question topic:
+Available directories: `trunk/`, `cmd/`, `internal/`, `cmake/`, `docs/`, `memory/`
 
-- **Always load first:** `../../memory/srs-overview.md` — this covers protocols, codecs, transmuxing, configuration, features, ecosystem, performance, and most support questions.
-- **Load on demand:** `../../memory/srs-coroutines.md` — only load this when the question is specifically about SRS architecture internals, coroutines, State Threads, or how SRS handles concurrency. Most user questions don't need this. Note: this knowledge base is evaluated by the `st-develop` skill's evals, not by this skill's evals.
+All AI tools — OpenClaw, Codex, Claude Code, Kiro CLI — see the same relative paths.
 
-As the knowledge base grows, new `srs-*.md` files will appear. List `../../memory/srs-*.md` to discover them, and load only the ones relevant to the question.
+## Step 2: Load Knowledge
 
-## Answering by Topic
+Load knowledge in layers. Start minimal, expand only if needed.
 
-### Protocol Questions
+**Layer 1 — Always load:**
+- `memory/srs-overview.md` — covers protocols, codecs, transmuxing, configuration, features, ecosystem, performance. This answers most questions.
+
+**Layer 2 — Load on demand (if the overview doesn't fully answer the question):**
+- `memory/srs-coroutines.md` — load when the question is about SRS architecture internals, coroutines, State Threads, or concurrency. Most user questions don't need this. Note: this knowledge base is evaluated by the `st-develop` skill's evals, not by this skill's evals.
+
+**Layer 3 — Last resort (if knowledge files don't answer the question and you need source code):**
+- `memory/srs-codebase-map.md` — load the **entire file** (do not truncate or read partial content). Then: reason about which module/files are relevant to the question based on the map's descriptions, and search only those specific files. **DO NOT grep broadly** (e.g., `trunk/src/` or the repository root). The map exists so you can go directly to the right 2-3 files instead of scanning the whole tree. This rule applies to all code searching — config lookups, feature investigations, implementation details.
+
+## Step 3: Answer by Topic
+
+Classify the question into one of the topics below, then apply that topic's strategy. If a question spans multiple topics, combine the relevant strategies.
+
+**Answering rules (apply to all topics):**
+- Ground every answer in the knowledge files — do not guess or invent features
+- When you don't have information, say so: "The knowledge base doesn't cover that yet"
+- Keep answers practical — include commands, config snippets, or URLs when relevant
+- Use the `trunk/doc/source.flv` test file for publish examples (it ships with the repo)
+
+**Protocol Questions**
 - State which protocols SRS supports and their role (publish, play, or both)
 - Include the version and date when a protocol was added (from the Features list in srs-overview.md)
 - Clarify transport: which protocols use TCP vs UDP
 - For protocol comparisons, explain the tradeoffs (latency, compatibility, performance)
 
-### Codec Questions
+**Codec Questions**
 - Clarify codec support per protocol — not all codecs work with all protocols
 - When discussing transcoding, specify the direction (e.g., AAC→Opus for RTMP-to-WebRTC)
 - Distinguish built-in transcoding (audio only: AAC↔Opus, MP3→Opus) from external FFmpeg transcoding (video)
 - Note that SRS focuses on transmuxing (repackaging without re-encoding), not transcoding
 
-### Configuration Questions
-- Reference `$SRS_ROOT/conf/full.conf` as the complete configuration reference
+**Configuration Questions**
+- Reference `trunk/conf/full.conf` as the complete configuration reference
 - For specific features, point to the relevant config option and its vhost setting
 - Mention environment variable support for Docker/cloud-native deployments
-- For getting started, recommend `$SRS_ROOT/console.conf` for local testing
+- For getting started, recommend `trunk/conf/console.conf` for local testing
 
-### Deployment & Getting Started
-- Provide the standard build steps: `cd $SRS_ROOT/srs/trunk && ./configure && make`
+**Deployment & Getting Started**
+- Provide the standard build steps: `cd trunk && ./configure && make`
 - Show the basic publish/play workflow with FFmpeg and common players
-- For Docker questions, reference `$SRS_ROOT/docker.conf`
+- For Docker questions, reference `trunk/conf/docker.conf`
 - Note that SRS is Linux-only (use WSL on Windows, macOS works for development)
 
-### Architecture Questions
+**Architecture Questions**
 - SRS is C++ built on State Threads (ST) — a coroutine library providing Go-like concurrency
 - Single-threaded by design — scale horizontally via clustering, not multi-threading
-- Load `srs-coroutines.md` only if the user wants deeper architectural detail
-- For deep-dive architecture learning, suggest using the `srs-learn` skill instead
+- For deep-dive coroutine/ST internals, suggest using the `st-develop` skill instead
 
-### Performance Questions
+**Performance Questions**
 - TCP protocols (RTMP, HTTP-FLV) handle thousands of connections
 - UDP protocols (WebRTC, SRT) handle hundreds; with audio transcoding, dozens
 - Single-threaded — use origin cluster to scale across CPUs
 
-### Comparison Questions
+**Comparison Questions**
 - Compare against Nginx-RTMP, Janus, Red5 using facts from the knowledge base
 - Focus on protocol coverage, language/performance, and use case fit
 - Be objective — acknowledge where alternatives have strengths
 
-### Ecosystem Questions
+**Ecosystem Questions**
 - **srs-bench** — Benchmarking tool for RTMP, WebRTC, HTTP-FLV, HLS, GB28181
 - **state-threads** — Coroutine library, the foundation of SRS
 - **Oryx** — Mention it exists as an integrated solution but don't go into detail (out of scope for this skill)
 - SRS only maintains server-side projects — it doesn't maintain client-side tools
-
-## Answering Guidelines
-
-- Ground every answer in the knowledge files — do not guess or invent features
-- When you don't have information, say so: "The knowledge base doesn't cover that yet"
-- Keep answers practical — include commands, config snippets, or URLs when relevant
-- Use the `$SRS_ROOT/doc/source.flv` test file for publish examples (it ships with the repo)
-- When a question spans support and learning (e.g., "how does the RTMP handshake work internally?"), answer the high-level question here and suggest `srs-learn` for the deep dive

.openclaw/skills/st-develop/SKILL.md

@@ -9,25 +9,24 @@ State Threads (ST) is a C coroutine library.
 
 ## Setup
 
-Do **not** hardcode an absolute SRS path. Resolve `SRS_ROOT` dynamically:
+All files are in the current working directory. Find everything from here — no discovery logic needed.
 
-1. If `SRS_ROOT` env is set and contains `trunk/src`, use it.
-2. Else, if current workspace (or its git root) contains `trunk/src`, use that.
-3. Else, if the parent folder of the workspace contains `trunk/src`, use that parent.
-4. Else, if `~/git/srs/trunk/src` exists, use `~/git/srs`.
-5. Else, ask the user for the SRS repo root.
+Available directories: `trunk/`, `cmd/`, `internal/`, `cmake/`, `docs/`, `memory/`
+
+All AI tools — OpenClaw, Codex, Claude Code, Kiro CLI — see the same relative paths.
 
 ## Load Knowledge Base (MANDATORY)
 
 Before any ST work, use the `read` tool to load the knowledge base. Do NOT use memory_search — read the full file directly.
 
-- `../../memory/srs-coroutines.md`
+- `memory/srs-coroutines.md`
+- `memory/srs-codebase-map.md` — Load this when you need to find or navigate source files. Always use the codebase map to reason about which files are relevant before searching. Never grep from the repository root blindly.
 
 ## Loading ST Source Code (ON REQUEST)
 
 When the user asks to load the ST codebase (or needs you to work directly with the source), load **ALL** ST source files — no partial loads.
 
-All under `$SRS_ROOT/trunk/3rdparty/st-srs/`:
+All under `trunk/3rdparty/st-srs/`:
 
 Headers: `public.h`, `common.h`, `md.h`
 
@@ -41,7 +40,7 @@ Build: `Makefile`
 
 ## Unit Tests (utest)
 
-ST has a Google Test-based unit test suite in `$SRS_ROOT/trunk/3rdparty/st-srs/utest/`:
+ST has a Google Test-based unit test suite in `trunk/3rdparty/st-srs/utest/`:
 
 - `st_utest.cpp` / `st_utest.hpp` — Test main and shared helpers
 - `st_utest_coroutines.cpp` — Coroutine tests (start, params, multiple coroutines, addition across yields)
@@ -63,5 +62,5 @@ After any ST change (including utest-only changes), run the verifier script in t
 
 - `scripts/verify.sh`
 
-This script must resolve `SRS_ROOT` dynamically and run unit tests in `$SRS_ROOT/trunk/3rdparty/st-srs`.
+This script runs unit tests in `trunk/3rdparty/st-srs`.
 Always run verification before considering a change complete.

.openclaw/skills/st-develop/scripts/verify.sh

@@ -3,9 +3,9 @@
 set -e
 
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-# Navigate: scripts/ -> st-develop/ -> skills/ -> openclaw/ -> srs/
-SRS_ROOT="$(cd "$SCRIPT_DIR/../../../.." && pwd)"
-ST_DIR="$SRS_ROOT/trunk/3rdparty/st-srs"
+# Navigate: scripts/ -> st-develop/ -> skills/ -> .openclaw/
+WORKSPACE="$(cd "$SCRIPT_DIR/../../.." && pwd)"
+ST_DIR="$WORKSPACE/trunk/3rdparty/st-srs"
 
 if [[ ! -d "$ST_DIR" ]]; then
   echo "Error: ST_DIR does not exist: $ST_DIR" >&2
@@ -14,8 +14,8 @@ fi
 
 echo "ST source: $ST_DIR"
 
-CMAKE_DIR="$SRS_ROOT/cmake"
-BUILD_DIR="$SRS_ROOT/cmake/build"
+CMAKE_DIR="$WORKSPACE/cmake"
+BUILD_DIR="$WORKSPACE/cmake/build"
 
 mkdir -p "$BUILD_DIR"
 cd "$BUILD_DIR"

.openclaw/trunk

@@ -0,0 +1 @@
+../trunk

memory

@@ -0,0 +1 @@
+.openclaw/memory

proxy/README.md

@@ -1,3 +0,0 @@
-# Proxy
-
-Moved to [code](../cmd/proxy/main.go) and [doc](../docs/proxy/README.md).

trunk/3rdparty/srs-docs/doc/getting-started-ai.md

@@ -7,50 +7,109 @@ hide_table_of_contents: false
 
 # AI Agent
 
-AI Agents are powerful tools for maintaining SRS and helping you understand, debug, operate, and develop SRS applications. We use a comprehensive set of AI Agents to maintain the SRS community and have established guidelines for AI to follow, enabling you to use these tools more efficiently.
+SRS provides several ways to use AI: you can chat with the SRS Robot in Telegram or Discord for quick answers, or run AI locally with OpenClaw, Claude Code, Codex, or Kiro using the pre-configured SRS knowledge base.
 
-## Augment Code
+## SRS Robot
 
-Augment Code is an exceptionally powerful AI Agent that we highly recommend. We have configured specific settings and guidelines for Augment Code, allowing you to simply open the SRS project with VSCode and immediately leverage the full power of AI assistance. SRS provides comprehensive context for AI to work effectively, including code, documentation, and tests.
+SRS provides an AI-powered support robot built on OpenClaw, available in both the Telegram group and Discord channel. The robot has a deep knowledge base covering SRS code, documentation, and common usage scenarios, and is powered by the latest AI model.
 
-To use Augment Code, first install VSCode, then install the Augment Code extension. Follow the installation guide at [Install Augment for Visual Studio Code](https://docs.augmentcode.com/setup-augment/install-visual-studio-code).
+You can ask the SRS Robot anything about SRS — how to use it, how to match your use case, how to configure it, how to debug issues, or any other questions. The robot will give you accurate, up-to-date answers based on the latest SRS knowledge base.
 
-Next, clone the SRS code and ensure you open the root directory, which contains the `.augment-guidelines` file:
+Join the SRS Telegram group: [https://t.me/+RiynvKOxpQ42MGJl](https://t.me/+RiynvKOxpQ42MGJl)
+
+Join the SRS Discord channel: [https://discord.gg/yZ4BnPmHAd](https://discord.gg/yZ4BnPmHAd)
+
+Once you're in the group, @ the SRS Robot and ask your question directly.
+
+## Claude Code
+
+You can use Claude Code locally with the SRS codebase. SRS ships with a pre-configured `.claude` directory so Claude Code works out of the box with full context of the project.
+
+Clone the SRS code and start Claude Code:
 
 ```bash
 git clone https://github.com/ossrs/srs.git
 cd srs
-code .
+claude
 ```
 
-You can verify the Augment Code settings to ensure the `Context` is correctly configured, then test it by asking Augment Code a question like this:
+Claude Code will automatically load the configuration from `srs/.claude`, giving it deep knowledge of the SRS codebase so you can ask questions, debug issues, write code, and more.
 
-```
-Will you follow any .augment-guidelines and .augmentignore of this project?
+## Codex
+
+You can also use Codex locally with the SRS codebase. SRS ships with a pre-configured `.codex` directory so Codex works out of the box.
+
+Clone the SRS code and start Codex:
+
+```bash
+git clone https://github.com/ossrs/srs.git
+cd srs
+codex
 ```
 
-We've found that Augment Code demonstrates deep familiarity with the SRS codebase, comparable to that of experienced maintainers. For a practical example of using Augment Code to review pull requests and improve code quality, see [AI Agent for SRS](https://medium.com/@winlinam/f9eb12a1ce74).
+Codex will automatically load the configuration from `srs/.codex`.
 
-## GitHub Copilot
+## Kiro
 
-GitHub Copilot is an effective AI Agent for reading and writing SRS code. We also utilize it for pull request reviews. While it's a valuable AI tool, it doesn't quite match the expertise level of an experienced maintainer.
+You can also use Kiro locally with the SRS codebase. SRS ships with a pre-configured `.kiro` directory so Kiro works out of the box.
 
-## Pull Request
+Clone the SRS code and start Kiro:
 
-SRS also uses AI to help review pull requests, making it important to structure your pull requests in a way that AI can effectively understand your changes and code. To ensure optimal AI review, please follow these guidelines:
+```bash
+git clone https://github.com/ossrs/srs.git
+cd srs
+kiro-cli
+```
 
-* Avoid renaming variables and functions in your pull request, as this can confuse AI analysis.
-* Avoid reordering functions or restructuring code, as this makes it difficult for AI to understand the actual changes.
-* Avoid moving or renaming files, as these appear as major changes to AI systems.
+Kiro will automatically load the configuration from `srs/.kiro`.
 
-If you need to perform such refactoring tasks (renaming variables, functions, or files, or reordering functions), please submit a separate pull request before your main feature pull request. Clearly comment that the refactoring PR contains no logic changes, so we can skip AI review for that specific PR.
+## OpenClaw
 
-## Comments
+You can create an OpenClaw agent with the SRS knowledge base for local use. First clone the SRS code:
 
-Adding comments is highly beneficial and recommended, especially for complex logic that might confuse both you and AI. Generally, if you need AI assistance to understand or clarify code, you should also ask AI to add comments for that code.
+```bash
+git clone https://github.com/ossrs/srs.git
+```
 
-Comments are always valuable and welcome—think of them as prompts for AI. With accurate and thorough comments, AI can better understand complex code and implicit background knowledge. By maintaining these good practices, AI can continue to help improve project quality and create a better maintenance experience.
+There are two ways to point the agent at the SRS knowledge base:
 
-You should also leverage AI to generate brief and clear commit messages and pull request descriptions. There's no need for excessive text—just enough to clarify the special context and knowledge that is implicit in the code.
+- **Set the workspace directly** — when creating the agent, set the workspace path to `srs/.openclaw`.
+- **Soft link** — create the agent with its default workspace, then remove the default workspace directory and replace it with a soft link to `srs/.openclaw`:
+
+```bash
+ln -sf ~/git/srs/.openclaw ~/.openclaw/workspace
+```
+
+Once the agent is running, list the available skills and trigger them to load the knowledge base. The skills tell the AI which files to load and how to work more effectively with the SRS codebase.
+
+## Skills
+
+After starting OpenClaw, Claude Code, Codex, or Kiro with the SRS codebase, you should use skills to get the best results. Skills load the right knowledge base for your task and guide the AI through the correct workflow.
+
+The `srs-support` skill is provided for answering questions about the SRS project. It automatically loads the relevant knowledge base based on your question, so the AI can give you accurate and context-aware answers.
+
+More skills will be added over time. To see what skills are currently available, simply ask the AI:
+
+```
+What skills can I use for SRS?
+```
+
+## Knowledge Base
+
+Code and documentation alone are not enough for AI to truly understand and maintain a project. There is background knowledge, design thinking, accumulated experience, use cases, community communication, and debugging workflows that live only in people's heads — not in any file. The SRS knowledge base is an effort to make all of that explicit.
+
+The knowledge base is the OpenClaw memory — files that encode the background, experience, and context behind SRS. It is built by having AI read the code and documents, then talking with AI to surface the implicit knowledge and write it down. Over time, the knowledge base will cover everything: not just what the code does, but why it was designed that way, how to think about problems, and how to operate and maintain the project.
+
+The knowledge base and the code together are the single source of truth for SRS. The knowledge base captures what the code cannot — background, design decisions, use cases, debugging experience, and community knowledge. In the future, traditional documentation will be generated from the knowledge base and maintained entirely by AI.
+
+On top of the knowledge base, there are skills. Skills are workflows that tell AI how to handle specific tasks, such as:
+
+- **Support** — answering user questions and matching use cases
+- **Issue triage and fix** — understanding, reproducing, and resolving issues
+- **Feature development** — designing and implementing new features
+- **Maintenance** — reviewing pull requests, managing releases, keeping the project healthy
+- **Debugging** — diagnosing and tracing problems in the codebase
+
+Each skill loads the relevant parts of the knowledge base and guides the AI through the right workflow for that task. This is what makes AI effective at maintaining SRS — not just raw intelligence, but structured knowledge and workflows built up over time.
 
 ![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/getting-started-ai)

trunk/3rdparty/srs-docs/doc/origin-cluster.md

@@ -50,7 +50,7 @@ server by below command, and get the executable binary `./srs-proxy`:
 
 ```bash
 git clone https://github.com/ossrs/srs.git
-cd proxy && make
+cd srs && make
 ```
 
 > Note: You can also download the dependencies by running `go mod download` before building.

trunk/doc/CHANGELOG.md

@@ -7,6 +7,7 @@ The changelog for SRS.
 <a name="v7-changes"></a>
 
 ## SRS 7.0 Changelog
+* v7.0, 2026-03-26, Merge [#4654](https://github.com/ossrs/srs/pull/4654): OpenClaw: Restructure workspace with symlinks, add codebase map, and rewrite AI docs. v7.0.141 (#4654)
 * v7.0, 2026-03-22, Merge [#4653](https://github.com/ossrs/srs/pull/4653): OpenClaw: unify AI agent configs with shared persona symlinks. v7.0.140 (#4653)
 * v7.0, 2026-03-22, Merge [#4652](https://github.com/ossrs/srs/pull/4652): Proxy: restructure repo as Go project with proxy as first module. v7.0.139 (#4652)
 * v7.0, 2026-03-05, Merge [#4643](https://github.com/ossrs/srs/pull/4643): OpenClaw: add and refine ST knowledge-base and learning/review skills. v7.0.138 (#4643)

trunk/src/core/srs_core_version7.hpp

@@ -9,6 +9,6 @@
 
 #define VERSION_MAJOR 7
 #define VERSION_MINOR 0
-#define VERSION_REVISION 140
+#define VERSION_REVISION 141
 
 #endif