decomposer: generate deliverable files for Discover and structure the solution's functional requirements, non-functional requirements, constraints, assumptions, and open questions without selecting cloud products.; Select Google Cloud products from the confirmed requirements and produce the solution architecture, Mermaid diagram, architecture description, and Terraform infrastructure-as-code.; Validate the Terraform infrastructure and architecture artifacts without deploying resources by running formatting checks, Terraform validation, and a dry-run or plan-oriented deployment check.; Package the approved requirements, architecture, Mermaid diagram, Terraform IaC, and validation results into solution-architecture-guide.md in the gcp_solution_architecture_agent repository.; Verify that the gcp_solution_architecture_agent repository contains the packaged solution-architecture-guide.md with the approved workflow outputs.; Verify that the repository is derived from the workflow_agent template and implements the complete four-phase Google Cloud solution architecture workflow alongside the packaged guide.; Publish the verified gcp_solution_architecture_agent repository with its completed workflow implementation and solution architecture guide.; Verify that the published repository revision contains the completed workflow implementation and solution architecture guide.

architecture.md

@@ -1,44 +1,16 @@
-# Steps 1–2 — selected architecture and validation design
+# Architecture decision record
+
+The confirmed baseline uses a managed container API, a transactional managed relational datastore, a durable event bus, a serverless event worker, and centralized observability. The API publishes an event after a successful write. The worker is idempotent, acknowledges only after durable processing, and routes exhausted retries to a dead-letter topic. Public access is restricted to HTTPS and application identity; deployment identities are separate from runtime identities.
 
 ## Selected Google Cloud products
+- Cloud Run: stateless HTTPS API and event worker.
+- Cloud SQL for PostgreSQL: transactional relational persistence.
+- Pub/Sub: durable asynchronous events and dead-letter handling.
+- Artifact Registry: container image repository.
+- Secret Manager: runtime secret references (values supplied out of band).
+- Cloud Logging and Cloud Monitoring: logs, metrics, alerting foundations.
+- Cloud Trace: distributed request tracing.
+- IAM and Service Usage: least privilege and API enablement.
 
-- Cloud Run for the stateless HTTPS ingestion and worker services.
-- Pub/Sub for durable asynchronous order events and a dead-letter topic.
-- Cloud SQL for PostgreSQL for transactional order state.
-- Secret Manager for database credentials and application secrets.
-- Artifact Registry as the container image source.
-- Cloud Logging, Cloud Monitoring, and Cloud Trace for observability.
-- IAM and a dedicated service account for least-privilege workload identity.
-- Serverless VPC Access and a VPC network for controlled access to the database.
-
-## Mermaid diagram
-
-```mermaid
-flowchart LR
-  Client[Authenticated client] --> Run[Cloud Run: order-api]
-  Run --> Pub[Pub/Sub: orders]
-  Pub --> Worker[Cloud Run: order-worker]
-  Pub --> DLQ[Pub/Sub: orders-dead-letter]
-  Run --> SQL[(Cloud SQL PostgreSQL)]
-  Worker --> SQL
-  Run -. secrets .-> SM[Secret Manager]
-  Worker -. secrets .-> SM
-  Run -. egress .-> VPC[Serverless VPC Access / VPC]
-  Worker -. egress .-> VPC
-  Run --> Obs[Logging / Monitoring / Trace]
-  Worker --> Obs
-  CI[CI: fmt, validate, plan] --> TF[Terraform]
-  TF --> Run
-```
-
-## Architecture description
-
-Clients call the authenticated `order-api` service. The API validates the request, writes an idempotency/order record to PostgreSQL, publishes an order event, and acknowledges the request. The worker consumes events independently, updates transactional state, and allows failed messages to be retained in the dead-letter topic for replay. Both services use separate runtime identities in production; the reference Terraform uses one explicitly scoped identity to keep the sample small and documents the split as a hardening action.
-
-Cloud Run provides stateless horizontal scaling. Pub/Sub absorbs bursts and decouples downstream work. Cloud SQL supplies relational transactions; its private IP and VPC path are intended for production hardening. Secret Manager avoids embedding credentials. Managed logging, monitoring, and tracing provide operational evidence.
-
-The initial topology is single-region. Multi-region failover, custom domain/edge policy, backup configuration, and application-level authentication integration remain deployment decisions because the open questions are unresolved.
-
-## Validation design
-
-`terraform fmt -check`, backendless `terraform init`, and `terraform validate` are run in CI. `scripts/validate_artifacts.py` checks that the requirements, architecture, Mermaid diagram, Terraform, and guide contain the required sections and that no product names occur in the product-neutral requirements section. No apply is used. A credentialed `terraform plan` is optional and must use a disposable plan file.
+## Trade-offs
+Cloud Run reduces operational burden and scales to zero, at the cost of cold starts and request/runtime limits. Cloud SQL provides relational transactions but needs sizing, backups, and HA decisions. Pub/Sub provides at-least-once delivery, so consumers must be idempotent. Terraform modules are deliberately small and explicit to keep the reference deployable and reviewable.