dave
30 lines
1.4 KiB
Markdown
30 lines
1.4 KiB
Markdown
# Future Service Module Extractions
|
|
|
|
Recommended order for extracting remaining HTTP handlers into `service/<domain>/`
|
|
modules, following the conventions in [service-modules.md](service-modules.md).
|
|
|
|
## Recommended Order
|
|
|
|
1. **`settings`** — small surface, few dependencies, good warm-up
|
|
2. **`oauth`** — reads/writes token files; pure validation logic separates cleanly
|
|
3. **`wizard`** — stateless generation logic is already mostly pure; thin I/O layer
|
|
4. **`project`** — project scaffolding; wraps `io::fs::scaffold`, clean separation
|
|
5. **`io`** (search/shell) — wraps `io::search` and `io::shell`; pure query-building separable
|
|
6. **`anthropic`** — token-proxy handler; pure request-shaping + thin HTTP I/O
|
|
7. **`stories`** (workflow) — CRDT-backed story ops; typed errors for 400/404/409/500
|
|
8. **`events`** — SSE handler; mostly framework wiring, but event filtering is pure
|
|
|
|
## Special Case: `ws`
|
|
|
|
The WebSocket handler (`http/ws.rs`) is a **dedicated harder extraction** because
|
|
it mixes multiple concerns (chat dispatch, permission forwarding, SSE bridging)
|
|
and depends on long-lived async streams. Extract it last, after the above list
|
|
is complete and the service module pattern is well-established.
|
|
|
|
## Notes
|
|
|
|
- Each extraction should link back to `docs/architecture/service-modules.md`
|
|
in the story description to maintain consistency.
|
|
- The `agents` extraction (story 604) is the reference implementation every
|
|
future extraction should follow.
|