Sorcero: Tesseract

What it involved

Microservices

A live map of the active microservices, each wired to the specs that cover it.

Visualization

Built with Three.js and D3, so coverage and health read spatially instead of in a terminal.

Test Orchestration

Playwright runs start from the map instead of the command line.

Disaster Recovery

Disaster-recovery drill results are compared side by side across two regions.

Multi-region

Both regions' runs are shown together, with history kept from each run's output.

About

A terminal is a poor instrument for reasoning about which of many microservices is covered, healthy, and under test — especially mid disaster-recovery drill, across two regions, under time pressure. Tesseract made the system spatial: a live map of active microservices, each wired to the specs in the Playwright repo that cover it, so runs were orchestrated by pointing at the architecture instead of remembering spec paths. Every run's output was retained, which turned DR drills into a comparable history rather than a one-off.

• Three.js
• D3.js
• Playwright
• TypeScript
• Microservices
• Disaster Recovery

How it's tested 5 checks

• ✓active microservices rendered as a live visual map

  Built with Three.js and D3.js so the running system could be seen rather than inferred from logs.

• ✓each service maps to the specs that cover it

  Bound the visual topology to the actual Playwright repo, so coverage of a given service was a thing you could look at.

• ✓runs orchestrated from the map instead of the command line

  Selecting services selected their specs — orchestration by architecture rather than by remembered file paths.

• ✓disaster recovery compared side by side across regions

  During DR exercises, two regions could be run and read against each other directly, which is the question a DR drill is actually asking.

• ✓run history retained from each run's output

  Persisted the output of each run so drills accumulated into a record that could be compared over time.