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.

docs/architecture.md

@@ -0,0 +1,23 @@
+# Steps 1–2 — Architecture and validation
+
+## Selected products
+- Cloud Run: managed HTTPS, stateless container runtime.
+- Pub/Sub: durable asynchronous event transport.
+- Cloud Storage: object persistence.
+- Firestore: document/application state persistence.
+- VPC and Serverless VPC Access: controlled private egress foundation.
+- Cloud Logging and Cloud Monitoring: operational telemetry.
+- Artifact Registry: container image source.
+- IAM and Service Usage: identities and API enablement.
+
+## Request flow
+Clients call Cloud Run over HTTPS. The service writes application state to Firestore, stores binary objects in Cloud Storage, and publishes domain events to Pub/Sub. A separately deployed worker can subscribe to the topic; this baseline creates the topic and dead-letter topic but intentionally does not invent worker application code. Logs and platform metrics feed the operational plane.
+
+## Security and reliability
+Cloud Run uses a dedicated service account and configurable ingress. Firestore and Storage use managed encryption. Pub/Sub dead-lettering limits poison-message impact. Runtime configuration is supplied as variables rather than secrets in source. Production hardening should add Secret Manager, customer-managed keys, edge protection, private ingress, backups, and multi-region DR if the open questions require them.
+
+## Terraform notes
+The `terraform/` directory is a module-like root configuration. It enables required APIs, creates the network, storage bucket, Firestore database, Pub/Sub topics, Artifact Registry repository, service account, and Cloud Run service. Supply `project_id`, `region`, and `container_image`; do not commit a state backend or credentials. The Cloud Run resource is a deployable placeholder whose image must already exist.
+
+## Validation result
+Static artifact tests check required sections, Mermaid markers, Terraform file presence, and absence of obvious credential material. Terraform formatting/validation and an optional plan are defined in `scripts/validate.sh`; they are not executed by repository generation because this environment has no filesystem or cloud credentials. No resources are provisioned by the workflow.

docs/requirements.md

@@ -0,0 +1,48 @@
+# Step 0 — Requirements discovery
+
+## Workflow request
+No application-specific workflow request was supplied. This baseline therefore documents an event-driven HTTP application reference architecture and marks all product choices as deferred during discovery.
+
+## Functional requirements
+- Accept authenticated HTTPS requests from external clients.
+- Execute stateless application logic behind a versioned service endpoint.
+- Publish asynchronous domain events from the application.
+- Process events independently and tolerate retry/redelivery.
+- Persist durable objects and application state separately.
+- Expose operational logs, metrics, and audit-relevant events.
+- Support repeatable infrastructure changes through declarative IaC.
+
+## Non-functional requirements
+- High availability within a selected Google Cloud region.
+- Horizontal scale for bursty HTTP traffic and asynchronous work.
+- At-least-once event delivery with idempotent consumers.
+- Encryption in transit and at rest using managed defaults initially.
+- Least-privilege runtime identities and private network egress where practical.
+- Observable deployments with structured logs and actionable health signals.
+- Reproducible, reviewable, non-deployment validation in CI.
+
+## Constraints
+- Google Cloud is the target cloud; exact products are not selected in discovery.
+- Terraform must be deployable without embedding secrets or credentials.
+- The baseline must not provision resources during validation.
+- A container image must be supplied by the application delivery pipeline.
+- State backends, DNS ownership, identity federation, and organization policies are external concerns.
+
+## Assumptions
+- A single region is acceptable for the initial deployment.
+- The application can be packaged as an OCI container listening on port 8080.
+- Events can use at-least-once semantics and consumers can deduplicate.
+- A dedicated Google Cloud project is available.
+- Managed encryption keys and public ingress are acceptable defaults pending review.
+
+## Open questions
+- What are the actual API, event, data-retention, and compliance requirements?
+- Which clients and identity provider must authenticate requests?
+- What are traffic, payload-size, latency, RTO, and RPO targets?
+- Which data is relational, document, object, or analytical?
+- Should ingress be public, private, or protected by an enterprise edge?
+- Are customer-managed keys, VPC Service Controls, or regional DR required?
+- What image registry, CI identity, environment promotion, and rollback policy apply?
+- What budget, quota, naming, tagging, and organization-policy constraints apply?
+
+**Product selection deferred:** `true` for this phase.