terraphim / terraphim/terraphim-ai
[Architecture][P1] Phase 1: Extract reusable bootstrap and unify server routes
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 62
- Forks
- 5
- Avg merge
- 2h 27m
- Merged PRs (30d)
- 1
Description
Parent: https://github.com/terraphim/terraphim-ai/issues/520
Related plan: docs/architecture-improvement-plan.md
Goal
Extract reusable startup boundaries in the server layer so composition roots stay thin and test/prod router behavior stays in sync.
Deliverables
- Reusable runtime bootstrap module/crate for rolegraph + indexing initialization
- Shared route composition function used by both production and test router constructors
- Thin composition-root entrypoints in
terraphim_server/src/main.rsandterraphim_server/src/lib.rs
Tasks
- Extract startup indexing logic from
terraphim_server/src/lib.rsinto a reusable initializer component - Replace duplicated route lists with a single route composition function
- Add focused tests to verify production/test router parity
- Document the new boundary in module/crate README or ADR references
Acceptance Criteria
- No duplicated route registration blocks across production/test constructors
- Startup/indexing orchestration can be reused from tests or other adapters
- Build/test paths pass for server with default and relevant feature sets
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with terraphim_server/src/lib.rs and terraphim_server/src/main.rs, then read docs/architecture-improvement-plan.md and the parent issue for the intended boundaries. Trace the startup indexing logic and the production/test route constructors before deciding how to extract them. Done means shared route registration, reusable startup orchestration, focused parity tests, documentation, and passing server builds/tests across relevant feature sets.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100