feat: Phase 0 — QumuloDB foundation scaffold

[SST-Engineering]

What this is

The first PR for QumuloDB — the purpose-built project management database engine for the 21st century.

This is Phase 0: the complete foundation. Every type, every engine, and the full storage architecture is scaffolded and ready to build on.

---

What's in this PR

qdb-contract — Kernel boundary types

The single source of truth for every type that crosses the computation boundary. Pure data structs — no I/O, no async, no platform code. Compiles to wasm32-unknown-unknown unchanged.

• calendar — KernelCalendar, CalendarException with working-time arithmetic
• schedule — ActivityInput/Result, DependencyInput, ScheduleRequest/Result, ScheduleWarning
• evm — EVMPeriodInput/Result, EVMRequest, EVMResult (all standard EVM metrics)
• simulation — RiskInput, SimulationRequest/Result, HistogramBin, TornadoEntry, RiskContributionResult
• resources — ResourceInput, AssignmentInput, ResourceRequest/Result, PeriodLoadResult, LevellingAdjustment

qdb-kernel — Computation engines

Pure functions. No I/O. The kernel IS the product.

Engine	Implementation
CPM Scheduling	Forward/backward pass, FS/SS/FF/SF deps with lag, ASAP/MSO/MFO/SNET/SNLT/FNET/FNLT constraints, working-time calendar arithmetic, total float, critical path, deadline warnings
EVM	PV/EV/AC, CV/SV/CPI/SPI, EAC (CPI/SPI/remaining/manual methods), ETC/VAC/TCPI, S-curve period breakdown
Monte Carlo	PERT-Beta/Triangular/Uniform/Fixed distributions, configurable iterations + seed, percentile outputs, Pearson correlation, tornado chart
Resources	Per-resource period load profiles, over-allocation detection, utilisation ratios, total cost

qdb-store — Storage layer

Three-tier architecture using Apache Arrow, Parquet, and DataFusion as building materials:

• Hot tier: Apache Arrow RecordBatch sessions per project — zero-copy in-memory access
• Warm tier: Apache Parquet files, append-only, immutable, column-pruned reads
• Query tier: Apache DataFusion SQL engine — registers Arrow tables and Parquet scans

Bitemporal schema on every table: valid_from/valid_to (world time) + txn_from/txn_to (system time).

qdb-cli — qdb binary

# Schedule
echo '{...}' | qdb schedule

# EVM
qdb evm --input evm.json --output result.json

# Simulate
qdb simulate --input risks.json --persist

# Resources
qdb resources --input resources.json

# Read back
qdb get schedule PROJ-001

CI

• Build + test on ubuntu-latest
• Clippy (deny warnings)
• rustfmt check
• WASM compile check for qdb-contract and qdb-kernel

Docs

• docs/architecture.md — full three-tier storage, bitemporal model, crate graph, Gentia/Artemis parallel
• docs/qql.md — QQL language reference with AS OF VALID TIME, SCHEDULE_PERIOD OVERLAPS, native CPM/EVM columns

---

Design principles

"The computation kernel IS the product. One Rust codebase compiles to native binary, WASM (browser), iOS/Android FFI, and CLI — same intelligence on every surface."

QumuloDB draws its philosophy from Artemis (1977) and Gentia (1990s) — systems where the project model was the engine, not a layer over a general-purpose database. Artemis A2 had TIME, PERIOD, CALENDAR, ACTIVITY, RESOURCE, and COST-ACCOUNT as first-class language primitives. QumuloDB pursues the same idea in Rust for the 2020s and beyond.

---

Roadmap from here

Phase	Focus
0 ✅	This PR — contract + kernel + store + CLI scaffold
1	Full CPM engine hardening + calendar arithmetic edge cases
2	Resource levelling algorithm
3	Full Arrow/Parquet bitemporal writes
4	DataFusion QQL extensions (AS OF VALID TIME, SCHEDULE_PERIOD OVERLAPS)
5	WASM build + browser Web Worker harness
6	Foresight engine — ML-driven delay prediction
7	CRDT sync protocol

🤖 Generated with Claude Code