terraphim / terraphim/terraphim-ai

[Architecture][P1] Phase 1: Extract reusable bootstrap and unify server routes

Open
#523 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

architecture enhancement
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.rs and terraphim_server/src/lib.rs

Tasks

  • Extract startup indexing logic from terraphim_server/src/lib.rs into 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.