TetrisUI
Composable, modular application runtime. Software that upgrades and maintains itself.
TetrisUI is the module system for DOSS applications. Every feature is a self-contained ZSL package with explicit imports and exports. Customers mix and match modules into an application, and when the platform ships a new version the runtime merges upstream changes with local customizations automatically — the way git does for text, but at the application-graph level.
Why Gen3 rots
- 01
Customization and upgrade diverge
Every customer-specific tweak in a legacy ERP makes the next vendor release harder to apply. At some point, the customer is on a branch they can't merge back.
- 02
The cost compounds
After a few years of drift, 'upgrade' stops being a button and becomes a six-figure consulting engagement. The vendor has shipped four versions; the customer is still on one.
- 03
Eventually the customer forks
Either they stop upgrading or they pay to keep up. Both outcomes are bad for everyone — the customer loses new features; the vendor carries a long tail of bespoke versions.
The TetrisUI answer
Every module is a ZSL package
A schema, a set of workflows, a few forms, and a manifest of what it imports and exports. Small surface, clear contracts.
Customizations live inside the module system
A customer extending Finance.InvoiceApproval doesn't fork it; they publish a local overlay module that's also just ZSL. The runtime knows how to combine them.
Upgrades are three-way merges
Upstream (platform v1.2), base (platform v1.1), local (customer overlays). Tetris computes the merged graph, runs automated tests, and escalates conflicts to a human.
No mystery state
Because everything is ZSL and every change is a commit, `zsl diff` tells you exactly what changed between versions — in both the platform and the customer overlays.
How an upgrade actually runs
- 01
1. Snapshot
Runtime captures the customer's current application graph — modules, versions, overlays, overrides.
- 02
2. Diff
Compute the graph-space delta between platform v(n) and v(n+1). Structural changes (renames, moves, splits) are first-class, not text diffs.
- 03
3. Merge candidate
Apply upstream changes on top of the customer's overlays. Record conflicts (same path changed on both sides) but don't block on them yet.
- 04
4. Test
Run the customer's ENT-Bench-style regression suite against the candidate in a sandbox with a cloned Z-Table. Record every pass/fail.
- 05
5. Route
Clean merges auto-land. Conflicts or failed tests route to a human reviewer with a structured diff and a rationale.
In the stack
Every module is a ZSL package — the import/export graph is a ZSL concept.
Vapor generates the UI for whatever module graph TetrisUI composes at runtime.
Merge and test lifecycles themselves run as durable ZFlow workflows.
The automated test pass during a merge is an ENT-Bench-style run against the candidate graph.
