Skip to content

Decompose large backend crates and strengthen typed runtime boundaries #114

@justinrayshort

Description

@justinrayshort

Summary

Decompose the largest backend crates into focused modules and reduce stringly typed runtime inputs at core boundaries while preserving contract compatibility.

Primary Architectural Plane

services / workflows / shared / platform / schemas

Owning Subsystem

services/knowledge-service, workflows/quant_strategy_promotion, shared core runtime crates, touched schema-facing types

Architectural References

  • ARCHITECTURE.md
  • docs/architecture/layer-boundaries.md
  • AGENTS.md

Integration Boundaries

Allowed touchpoints: touched backend crates, typed IDs or runtime wrappers, and additive contract updates required for compatibility-preserving cleanup.
Explicit non-goals: unrelated UI refactors or delivery pipeline work.

Scope In

  • Split knowledge service into focused modules for ingestion, governance, publication, analysis, rendering, and tests
  • Split quant strategy promotion into orchestration, research simulation, promotion gating, and report assembly modules
  • Introduce additive typed wrappers or enums for touched runtime identifiers and governance inputs where practical
  • Remove unnecessary boxing or trait-object usage where concrete generics or enums preserve clarity and performance

Scope Out

  • Placeholder service promotion
  • Sandbox runtime policy enforcement
  • Shared transaction work outside touched crates

Acceptance Criteria

  • Touched large backend crates no longer centralize most behavior in a single oversized source file
  • Touched runtime boundaries use fewer raw strings and preserve compile-time guarantees more effectively
  • Full repository validation remains green

Validation Requirements

  • cargo fmt --all --check
  • cargo clippy --workspace --all-targets --all-features -- -D warnings
  • cargo test --workspace --all-targets
  • cargo xtask architecture audit-boundaries

Rollback Considerations

Revert the decomposition commits and any additive typed wrappers in the same issue branch if the new module boundaries regress integration behavior.

Parent Issue

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions