Architect Pipeline

Outputs reports/03_design/aggregates/aggregate-manifest.json (AGG- IDs). For each aggregate, defines the root, interior entities, value objects, invariants (with concrete examples on both the satisfied and violated branches), commands (actor, consistency class, emitted event), factories, specifications, and exactly one repository per root.

rules/aggregate-design.md states the seven well-formedness rules — including the one-command / one-aggregate / one-transaction contract — and tools/lib/aggregate_manifest.py enforces them. This aggregate list becomes the candidate list for the following design-state-machine phase, and is consumed by design-scalardb/design-data-layer, design-api, design-implementation, generate-test-specs, review-consistency, and report.

Events an aggregate publishes are also written out as the Domain Event Catalog (reports/03_design/domain-event-catalog.json/.md) — the context map’s Published Language itself, recording each event’s publisher, the contexts that consume it, and its delivery contract (guarantee level, idempotency key, version). design-microservices completes the consumer side once the service split is known, and design-api’s asyncapi/ is generated from this catalog.

Outputs reports/03_design/state-machines/state-machine-manifest.json. For each aggregate with a lifecycle, defines states, events, and transitions ((from, event) [guard] → to, each with an actor, a consistency class, and an idempotency verdict), and decides every cell of the state × event matrix as reject, ignore, or defer — leaving no blank cell for the runtime to interpret.

• Events that create an aggregate (place, open, register, etc.) are treated as a special column with no from state, and their idempotency verdict is derived mechanically from the API’s idempotency contract.
• It also builds a “contention table” — one row per pair of actors that can race against the same aggregate (an orchestrator vs. a recovery worker, the request path vs. a sweeper, etc.), naming who wins and what the loser does. A pair with no row is a race nobody designed.
• tools/lib/state_machine_manifest.py (29 checks) enforces well-formedness rules — exactly one initial state, every state reachable, no undeclared dead end, and so on. design-scalardb/design-data-layer, design-api, generate-test-specs, review-consistency, and report all read this model.

Outputs golden-master tests recorded from the running legacy system — a seam inventory per module, fixtures whose every value the code actually produced, @KnownDefect(DEBT-xx) markers that pin a known bug without blessing it — plus reports/07_test-specs/characterization-test-coverage.md.

design-microservices’s migration plan now requires every transformation-plan step to be tied to this characterization-test gate — a safety net for transforming behavior without breaking it.

Outputs Cucumber-JVM step definitions for the Gherkin scenarios in reports/07_test-specs/ (tied to RULE-/EX-), plus reports/07_test-specs/acceptance-test-coverage.md. Runs over an API/application-layer driver built on the Fakes, with a fixed Clock.

Scenarios whose implementation hasn’t landed yet get a @wip tag — excluded from the pass/fail verdict but still counted. This is what makes the ATDD outer loop in rules/tdd-workflow.md executable.

Outputs: authentication infrastructure (OAuth2/OIDC, service-to-service mTLS); an authorization model (RBAC/ABAC, including object-level authorization, not just role-level); a tenant isolation model; secret management (Vault/KMS, rotation strategy); network security (zero trust, segmentation); data classification (which fields are sensitive, and whether they may appear in API responses/logs/error details); audit logging; and a compliance checklist. Also covers OWASP API Security Top 10 compliance.

Outputs: SLI/SLO definitions (per service, tied to business KPIs); distributed tracing (OpenTelemetry, tracking requests that span multiple services via correlation IDs); log aggregation; metrics (RED/USE methods); alert design; and ScalarDB-specific metrics (transaction success rate, OCC conflict rate). When using ScalarDB Saga, also adds Saga state counts and compensation failure rates.

Outputs: RTO/RPO per service tier (recovery time objective and the amount of data loss that’s acceptable); a backup strategy (frequency, retention, restore-test plan); failover design (cross-region, cross-AZ); data recovery procedures (including ScalarDB’s Coordinator table); runbooks per failure scenario; and a recovery test plan that includes chaos engineering (deliberately inducing failures to verify resilience).

Provides multi-faceted estimates covering: cloud infrastructure costs (AWS/Azure/GCP compute, storage, and network); ScalarDB licensing costs (by edition, whether contracted directly or via AWS Marketplace); operational costs (monitoring tools, support, staffing); and ScalarDB sizing (pod count, cluster configuration, DB capacity).

Outputs: Kubernetes cluster configuration (node pools, resource quotas, namespace strategy); container orchestration (deployment strategy, HPA, PDB); network design (mTLS, NetworkPolicy, Ingress/Gateway); IaC configuration (Terraform modules, state management); and a multi-environment strategy (dev/staging/prod, Kustomize overlays). When using ScalarDB Cluster, also designs the Helm chart configuration and Coordinator placement.

The output is strictly a logical design — /infra:design in the infra plugin takes the same area further into a concrete, multi-cloud-ready design (see the panel below).

Scores three perspectives on a 5-point scale: structural consistency (35%), traceability (35%), and terminology consistency (30%). Outputs findings in JSON format covering things like orphaned sections, places where the requirements→design→implementation trace can’t be followed, and cases where the same concept has been given different names.

Evaluates operational readiness across four perspectives: monitoring/observability (30%), disaster recovery (30%), security posture (20%), and deployment safety (20%).

Evaluates four perspectives — distributed system risk (30%), failure mode analysis (30%), Saga design validity (25%), and data integrity risk (15%) — deliberately from an adversarial standpoint. The goal is to surface risks the designer is unlikely to notice themselves, and it digs the deepest of the six perspectives.

Evaluates the validity of the design from a business-requirements standpoint across four perspectives: requirements traceability (35%), NFRs expressed as measurable values (30%), stakeholder alignment (20%), and ROI/feasibility (15%).

Specific to projects that use ScalarDB. Evaluates three perspectives: the cross-service transaction mechanism (40%), OCC conflict analysis (35%), and schema/API compatibility (25%).

Specific to projects that don’t use ScalarDB. Evaluates three perspectives: transaction safety (40%), data integrity (35%), and schema design quality (25%). Mutually exclusive with review-scalardb — only one of the two runs.

Takes in results from 2–6 perspectives and consolidates them in the following order.

Has the user select which source database (Oracle/MySQL/PostgreSQL) is involved, and routes to the corresponding dedicated skill. It doesn’t perform any schema extraction or conversion itself.

Uses six subagents — three sequential stages followed by three parallel runs — to handle everything from schema extraction to Java code generation.

Follows the same approach as migrate-oracle (sequential extraction → parallel analysis/conversion) to perform schema extraction, migration analysis, and Java conversion of stored procedures/triggers. Advanced Queuing integration is out of scope, since it’s an Oracle-specific feature.

Follows the same approach as migrate-oracle to perform schema extraction, migration analysis, and Java conversion of stored procedures/triggers. Advanced Queuing integration is out of scope, since it’s an Oracle-specific feature.