Systems Catalog is a Rust desktop app for documenting systems, their relationships, notes, and technology usage in a file-native project format.
- GUI:
eframe/egui - Persistence: file-native
FileStore - Error handling:
anyhow
src/models.rs- core data shapes such as systems, links, notes, tech items, and zonessrc/file_store.rs- file-native persistence with atomic writes and lazy entity loadingsrc/app.rs- shared app state, synchronization logic, and helperssrc/app/actions.rs- write-side actions and workflowssrc/app/ui.rs- rendering and interaction surfacessrc/project_store.rs- manifest and file format modelssrc/main.rs- startup and window bootstrap
- Hierarchical system catalog with service, database, API route, and step processor entities
- Directed interactions between systems
- Reusable tech catalog with per-system assignments
- Multiple notes per system
- Database column editing for database entities
- Visual map editing with draggable nodes and relationship creation
- Zone and grouping support in project metadata
- YAML import and export flows
- File-based project save and load
Projects are stored on disk using a lightweight manifest plus per-entity and per-interaction files.
project-root/
├── project.json
├── systems/
│ ├── service__users__2.json
│ └── api__orders__5.json
└── interactions/
└── 2__to__5__99.json
project.json stores the lightweight graph index. Entity files in systems/ store system-specific content such as notes, database columns, route methods, and assigned tech IDs. Interaction files in interactions/ store link metadata.
When a legacy Project.json manifest is present, it is still loaded for compatibility. Otherwise the app uses project.json and discovers interactions from interactions/*.json.
Schema definitions for project and entity files are available under assets/schemas/.
project.schema.json- lightweight project indexentity-base.schema.json- shared entity fieldsentity-service.schema.json- service entitiesentity-api.schema.json- API route entitiesentity-database.schema.json- database entitiesentity-step-processor.schema.json- step processor entitiesinteraction.schema.json- interaction files
See assets/schemas/README.md for schema details.
cargo runcargo build
cargo build --releaseRelease binaries are written to target/release/.
This repo includes a release workflow and publish helpers that manage semantic version bumps and tagging.
On macOS/Linux/Git Bash:
./publish --type major
./publish --type minor
./publish --type bugfixOn PowerShell:
./publish.ps1 -Type major
./publish.ps1 -Type minor
./publish.ps1 -Type bugfixWhat it does:
- Validates a clean git working tree
- Bumps
Cargo.tomlversion - Runs
cargo check - Commits version bump as
chore(release): vX.Y.Z - Creates and pushes git tag
vX.Y.Z
.github/workflows/release.yml listens for pushed tags matching v* and builds release binaries for:
- Windows (
systems_catalog-windows-x86_64.exe) - Linux (
systems_catalog-linux-x86_64) - macOS Apple Silicon (
systems_catalog-macos-aarch64)
The workflow then creates or updates the GitHub Release for that tag and uploads all binaries.
The app now performs a lazy update check in the background after startup.
- On startup it loads normally, then checks
https://api.github.com/repos/<owner>/<repo>/releases/latest - If a newer version is available, an
Update <version>badge appears in the top toolbar - Clicking the badge asks for confirmation
- If confirmed, the app downloads the platform asset from the release, stages it, and schedules replacement
- The app closes and restarts into the updated binary
Current update source defaults to mwalker/systems_catalog in src/app.rs (update_repo_owner and update_repo_name).
If your repository uses a different owner or name, update those values.
cargo check
cargo fmt --check
cargo test