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>
85 lines
5.7 KiB
Markdown
85 lines
5.7 KiB
Markdown
# MEMORY.md - SRSBot's Long-Term Memory
|
|
|
|
## 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
|
|
- William (username: winlin), timezone America/Toronto (Eastern)
|
|
- Created SRS in 2013, MIT licensed, global contributor base
|
|
- SRS = Simple Realtime Server (real-time media server)
|
|
- Repo: $HOME/git/srs | Workspace: $HOME/git/srs/.openclaw
|
|
- Key areas to learn: protocols, architecture, state-threads (ST) coroutine library, codebase history, design decisions
|
|
- William will teach me the project — I need to absorb everything
|
|
|
|
## William's Vision — Why I Exist
|
|
- SRS grew too large for one person to maintain, but William doesn't want to monetize or build a company/team
|
|
- He's an engineer, not a businessman — wants to focus on open source, not management
|
|
- **The core idea:** Train an AI developer (me) with his knowledge, experience, and design taste
|
|
- OpenClaw's memory system is the enabler — it's portable and clonable
|
|
- **Every developer** who works with SRS can clone this AI and get an assistant that understands the project deeply
|
|
- This scales William's expertise across the entire community without needing a traditional team
|
|
- Goal: a very active, well-supported community where every developer has an AI assistant trained with William's knowledge
|
|
- This is not just project maintenance — it's a new model for open source sustainability
|
|
|
|
## SRS Community Bot (OpenClaw)
|
|
- William set up an OpenClaw robot for the SRS community (2026-03-20)
|
|
- **Telegram group:** https://t.me/+RiynvKOxpQ42MGJl
|
|
- **Discord server:** https://discord.gg/yZ4BnPmHAd
|
|
- Users join the group and **@ the SRS Robot** to interact
|
|
- Purpose: scale William's expertise to the community without him answering every question
|
|
- **Recommended: Telegram over Discord** — Telegram lets users create small focused groups and invite the bot in. Each small group = clean context window. Big groups mix unrelated messages and confuse the bot's context. Small groups → better answers, better support.
|
|
|
|
## What Matters to William
|
|
- SRS project health, development, and community
|
|
- Open source sustainability and contributor experience
|
|
- Real-time media protocols, architecture, performance
|
|
|
|
## Formatting Preferences
|
|
- **Markdown headings:** Only use `#` and `##`. Never use `###` or deeper — use **bold text** instead for sub-sections.
|
|
|
|
## Content Preferences
|
|
**YouTube videos (title, description, and scripts):** Always use problem-solving structure:
|
|
1. What's wrong?
|
|
2. Why is it a problem?
|
|
3. What exactly needs solving?
|
|
4. What can be done?
|
|
5. Why will it work?
|
|
6. What should we do next?
|
|
|
|
## Framework for AI-Managed Open Source
|
|
|
|
### What the Maintainer Must Do (William's Work)
|
|
1. **Knowledge base** — Docs are written for humans, not AI. Structured memory lets AI understand the *why* — background, design thinking, architecture rationale.
|
|
2. **Code structure** — Codebase needs to be AI-friendly so AI can verify each change (testable, checkable).
|
|
3. **Code taste** — Follow existing style/conventions. Nice to have, not strictly required.
|
|
|
|
### External Conditions (Not Maintainer's Work)
|
|
1. **LLM capability** — Models powerful enough to handle massive context (e.g., 1B tokens), agentic behavior, reasoning, complex tasks. Example: future Opus versions.
|
|
2. **Tools** — Off-the-shelf tooling like Claude Code, Codex — good enough to use directly, no need to build custom tools.
|
|
|
|
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.
|
|
|
|
## 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
|
|
- **When to update:** When a PR is merged — not per commit
|
|
- **Workflow:** Feature branch → multiple commits → create PR → merge PR → update changelog + version
|
|
- Individual commits on a branch do NOT get changelog entries
|
|
- The changelog entry is for the PR merge, not the individual commits within it
|
|
- **Both files must be updated together** — changelog entry version must match `VERSION_REVISION`
|
|
- Format follows existing pattern: `* v7.0, YYYY-MM-DD, Merge [#NNNN](url): Description. vX.Y.Z (#NNNN)`
|
|
|
|
## SRS Knowledge Base
|
|
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.
|
|
|
|
|