Skip to content

Core runtime hardening and service promotion program #111

@justinrayshort

Description

@justinrayshort

Summary

Execute the senior Rust systems review remediation program as a tracked GitOps effort, focusing first on core runtime hardening and then on promoting metadata-only crates into minimal operational services and workflows.

Primary Architectural Plane

platform / shared / services / workflows

Owning Subsystem

platform/runtime, shared/surrealdb-access, services/knowledge-service, workflows/knowledge_publication, workflows/quant_strategy_promotion, targeted placeholder service and workflow crates

Architectural References

  • ARCHITECTURE.md
  • docs/architecture/layer-boundaries.md
  • docs/architecture/runtime-composition.md
  • docs/adr/0001-sovereign-institutional-architecture.md
  • docs/adr/0010-durable-workflow-execution-plane.md
  • docs/adr/0015-gitops-and-policy-as-code-control-artifacts.md

Integration Boundaries

Allowed touchpoints: runtime enforcement, workflow orchestration, shared repository abstractions, typed contracts, service implementations, workflow implementations, and repository-owned governance automation.
Explicit non-goals: unrelated UI shell refactors, infrastructure delivery changes outside runtime contract needs, or breaking contract revisions without staged compatibility.

Scope In

  • Harden the strategy sandbox with real Wasmtime execution and memory controls
  • Make governed workflow persistence atomic and auditable
  • Decompose large backend crates and reduce stringly runtime inputs at core boundaries
  • Promote placeholder service and workflow crates into minimal operational slices with tests
  • Track each implementation stream in a dedicated child issue and issue-derived branch

Scope Out

  • Broad UI design or UX work
  • Non-runtime infrastructure rollout changes
  • Unrelated workspace-wide refactors that do not improve runtime correctness or operational reliability

Acceptance Criteria

  • The program is tracked by one umbrella issue with four concrete child issues
  • Each child issue has a dedicated short-lived branch derived from main
  • Implemented child issues land via PRs targeting main with Closes #<issue-id>
  • All touched work passes repository validation gates

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
  • cargo xtask plugin validate-manifests
  • cargo xtask github audit-process

Rollback Considerations

Each child issue must remain independently revertible. Revert by PR or git revert on the merge commit for the affected issue branch, then restore any required compatibility adapters or issue state.

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