Architecture
From workflow code to production, one pipeline
A build tool invokes WoGu, which discovers your workflow classes, traverses their call graph, evaluates every rule against it, and reports results back to the build — before code ever reaches CI/CD or production.
Developer
A developer writes Temporal workflow code as part of a normal feature or fix — nothing WoGu-specific is required in the workflow code itself.
Maven / Gradle Plugin
The plugin is bound to the build lifecycle: wogu:validate runs on mvn verify by default, and woguValidate wires into gradle build once the java plugin is present.
Workflow Scanner
Discovers workflow implementation classes and their entry points — the methods matching an @WorkflowMethod-annotated interface method.
Rule Engine
A call-graph analyzer follows every resolvable method call from each entry point, however many hops deep, and evaluates every declarative rule against what it finds — stopping precisely at an Activity boundary.
Validation Report
Every rule's outcome is aggregated into a build summary: console output, and a self-contained HTML report with a violation card and full call path for each failure.
CI/CD
Because WoGu fails the build like a test failure would, a violation blocks a merge in CI the same way any other build-time gate does.
Production
Only workflow code that has passed every rule reaches a worker — determinism bugs are caught before they can cause a NonDeterministicException in production.
Under the hood
Call graph analysis
The core of WoGu's rule engine — how it finds a violation reachable through a helper class or service, and knows precisely where to stop.
Follows every reachable call
Starting from a workflow's entry point, WoGu follows every method call it can resolve to source elsewhere in the project, however many hops deep — not just the workflow implementation class itself.
Stops at an Activity boundary
Activities are not replayed, so the traversal deliberately stops there — this is what keeps every rule free of false positives inside Activity code.
Modules
Built to be additive
wogu-core and wogu-report depend only on the shared API module and discover or render engine output reflectively — a new rule, or a new workflow engine, is additive, never a change to the pipeline above.