Project Atlas AetherDev project hub
Atlas project testing

titanhst_sync

Rust CLI for synchronizing staff user records into TitanHST with guarded plan/apply behavior and report artifacts; this is the intended successor to the legacy Integr8r runtime, which remains the active production path pending cutover.

Type
Component
Lifecycle
Active
Last touched
2026-03-26
Visibility
Public

Purpose

A fast, safe, and auditable commandline tool written in Rust to synchronize users from a CSV file into Titan HST. It creates and updates users, manages site role membership, removes users from sites when they no longer appear in your source, and produces humanfriendly reports (plain text, HTML, and email).

Current state

Core sync and reporting behavior is implemented, and initial testing is complete. Registry-backed runtime evidence still points to the Integr8r `TitanHST` job as the active production path, but this Rust CLI is the intended successor because it improves user assignment handling and should support more frequent delta updates. Staging, production testing, and cutover still need to be completed.

Next step

Stage and production-test `titanhst_sync`, publish the active host and scheduler model, and complete cutover from the legacy Integr8r path by summer 2026 at the latest.

Interfaces

Inputs
  • Config with API key and SMTP settings
  • CSV input
  • Configuration files (TOML)
  • CSV files
Outputs
  • Titan HST user/role updates
  • reports in logs/
  • HTML reports
  • Text reports

Reality to Action trace

Reality Ingestion

Contributes in this stage.

Canonical Storage

Not in scope.

Automation Engines

Not in scope.

Human Interfaces

Contributes in this stage.

Operational Adoption

Contributes in this stage.

Core workflow

TBD. Document the 5-10 steps that define the core workflow.

Artifacts

  • CSV requires external_id, first_name, last_name, email, site_name, role_names

Operational notes

Constraints and scars

  • Safety thresholds must be tuned per district size; CSV schema drift can break mapping.

Reliability posture

Strong local guardrails (delta limits, dry-run support, report artifacts) make this safer than ad hoc scripts, but production scheduler ownership and active write-mode governance are still unresolved.

Observability

  • Logs: Rust logging framework detected (log/tracing/env_logger).
  • Metrics/health checks: None documented; use reports and logs
  • Logs: Written under logs/ with HTML/text reports per run.

Security and privacy

Keep API keys and SMTP credentials out of source control. Prefer environment overrides for secrets. Reports and logs may contain user identifying information; handle according to your policies.

Dependencies

Upstream
  • Titan HST API
  • optional SMTP relay

Ownership

Owners

Josh Barton

Users

Josh Barton (owner)

titanhst_sync

Architecture & Major Components

  • High-level diagram (text):

    • Entry/trigger -> core logic -> outputs (details per docs below)

  • Entry points: src/main.rs

  • Top-level folders: data, docs, logs, src

  • Key abstractions: Safety preflight guardrails, site/role mapping, report generation

Setup / Build / Run

  • Build system(s): Cargo.
  • Build with Cargo and provide a config.toml + CSV input file.
  • Use –dry_run to review the HTML/text report before applying changes.

Registry Alignment

  • Related registry entry: INT-016.
  • The registry treats TitanHST as a live district integration, but strongest current production evidence still sits in Integr8r and not conclusively in this Rust binary.
  • Current runtime / active path: Integr8r TitanHST job (batch-disabled, diff-enabled) with SQL export and secure upload.
  • Modernization / successor path: this Rust CLI and Aether wrapper (titanhst_sync.sh), with initial testing complete and a planned production cutover window no later than summer 2026.
  • Scheduler / operator model: Integr8r scheduled or operator-run controls appear primary; this CLI path still needs declared production scheduler ownership.
  • Site/staff scope: district staff safety-account provisioning and role/site mapping.
  • This page remains the technical record for the newer implementation path while the production cutover/coexistence question stays unresolved.