024342910d
- Add a comprehensive ST knowledge base document: - openclaw/memory/srs-coroutines.md - Add ST-focused developer skill: - openclaw/skills/st-develop/SKILL.md - openclaw/skills/st-develop/scripts/verify.sh - Add KB workflow skills that support ST documentation quality and learning: - openclaw/skills/kb-review/SKILL.md - openclaw/skills/srs-learn/SKILL.md - Update openclaw/skills/srs-support/SKILL.md to use dynamic SRS_ROOT path resolution, improving portability for KB/source loading. --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: chatgpt-codex-connector[bot] <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>
68 lines
2.9 KiB
Markdown
68 lines
2.9 KiB
Markdown
---
|
|
name: st-develop
|
|
description: Anything related to coroutines, State Threads (ST), or SRS's concurrency model. Use when discussing coroutine concepts, updating coroutine knowledge (srs-coroutines.md), developing/debugging/porting ST source code, porting ST to new CPU architectures or OSes, debugging coroutine context switching, analyzing ST scheduler behavior, adding new platform assembly, fixing ASAN/Valgrind/SEH issues, or understanding ST internals (sched, stk, sync, key, io, event, context switch ASM).
|
|
---
|
|
|
|
# ST Development
|
|
|
|
State Threads (ST) is a C coroutine library. Source lives in `trunk/3rdparty/st-srs/` inside the SRS repo.
|
|
|
|
Default SRS repo path is `~/git/srs`, but do **not** hardcode this path.
|
|
Always resolve `SRS_ROOT` dynamically:
|
|
|
|
1. If `SRS_ROOT` env is set and contains `trunk/3rdparty/st-srs`, use it.
|
|
2. Else, if current workspace (or its git root) contains `trunk/3rdparty/st-srs`, use that.
|
|
3. Else, if `~/git/srs/trunk/3rdparty/st-srs` exists, use `~/git/srs`.
|
|
4. Else, ask the user for the SRS repo root.
|
|
|
|
All ST source paths below are relative to `$SRS_ROOT`.
|
|
|
|
## Setup: 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`
|
|
|
|
## 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/`:
|
|
|
|
Headers: `public.h`, `common.h`, `md.h`
|
|
|
|
Core C: `sched.c`, `stk.c`, `sync.c`, `key.c`, `io.c`, `event.c`, `common.c`
|
|
|
|
Platform ASM: `md_darwin.S`, `md_linux.S`, `md_linux2.S`, `md_cygwin64.S`
|
|
|
|
Build: `Makefile`
|
|
|
|
**Load every single file listed above — no shortcuts, no skipping.**
|
|
|
|
## Unit Tests (utest)
|
|
|
|
ST has a Google Test-based unit test suite in `$SRS_ROOT/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)
|
|
- `st_utest_tcp.cpp` — TCP connection test
|
|
- `gtest-fit/` — Embedded Google Test framework
|
|
|
|
**Build targets** (in the ST Makefile):
|
|
- `darwin-debug-utest` — macOS debug build + utest
|
|
- `linux-debug-utest` — Linux debug build + utest
|
|
- `cygwin64-debug-utest` — Cygwin64 debug build + utest
|
|
|
|
Coverage variants: `darwin-debug-gcov`, `linux-debug-gcov` (adds `-fprofile-arcs -ftest-coverage`).
|
|
|
|
The build compiles ST as a static library first, then builds and links the utest binary at `obj/st_utest`.
|
|
|
|
## Verifying Changes
|
|
|
|
After any ST change (including utest-only changes), run the verifier script in this skill folder (not in the ST codebase):
|
|
|
|
- `scripts/verify.sh`
|
|
|
|
This script must resolve `SRS_ROOT` dynamically and run unit tests in `$SRS_ROOT/trunk/3rdparty/st-srs`.
|
|
Always run verification before considering a change complete.
|