decomposer: fix validation failure 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.

solution-architecture-guide.md

@@ -1,104 +1,77 @@
 # Google Cloud Solution Architecture Guide
 
-## Delivery status
-This is the revised, operator-reviewable guide. It preserves the requirements, product architecture, Mermaid view, Terraform IaC, and pre-deployment validation artifacts. **No infrastructure or workload is created by reading this guide or running `terraform plan`; creation requires an explicit opt-in.**
+## Scope and product-neutral requirements
 
-## Phase 0 — confirmed requirements (product selection deferred in this phase)
+The design preserves the confirmed requirements before product selection: accept authenticated requests, route peer traffic through a platform gateway/proxy, keep secrets out of source and state inputs, run workloads without root or propagated user credentials, and provide observable, least-privilege execution. Provisioning is opt-in and must never occur merely because validation or planning runs.
 
-### Functional requirements
-- Accept application requests through a controlled gateway/proxy rather than exposing the workload directly.
-- Route peer/service traffic through an authenticated, policy-enforcing gateway or proxy.
-- Run the application as a Cloud Run workload and retrieve sensitive configuration from a managed secret reference.
-- Provide repeatable infrastructure as code.
-- Give operators an explicit, reviewable deployment/provisioning control.
+Functional requirements:
+- Receive requests through a single platform gateway and proxy peer-to-peer traffic; peers are not directly exposed.
+- Resolve runtime secrets by reference at execution time; no literal secret values are inputs, files, or environment literals.
+- Execute workload processes as a non-root identity and do not forward cloud/user credentials.
+- Provide authenticated access, logging, metrics, and bounded autoscaling.
 
-### Non-functional requirements
-- Workload execution uses a dedicated, least-privilege service identity and a non-root container user.
-- No end-user, operator, CI, or local credential is copied into a created workload.
-- Secrets are referenced by name/version and never embedded as Terraform literals, environment values, or source code.
-- Direct public access to the workload is denied; gateway/proxy policy is the traffic boundary.
-- Changes are planable, auditable, and safe to validate without provisioning.
+Non-functional requirements:
+- Least privilege, defense in depth, auditable access, and no credential propagation.
+- Repeatable Terraform, reviewable plans, and safe default behavior.
+- Availability and scaling suitable for a stateless regional service.
 
-### Constraints
-- Google Cloud and Terraform are the target platform/tooling.
-- This deliverable must not provision resources during validation.
-- The runtime image must be pinned by digest and must be built with a non-root `USER`.
+Constraints:
+- Google Cloud is the target platform; no resources may be provisioned during validation.
+- `provision=false` is the default and is an explicit request gate.
+- Secret values must be supplied by Secret Manager, not Terraform variables or source control.
 
-### Assumptions
-- A pre-existing Secret Manager secret is supplied by name; its value is populated out of band by an authorized operator.
-- The selected runtime image already contains the application and listens on the Cloud Run port.
-- A gateway/proxy is the only supported client path to the service.
+Assumptions:
+- An existing secret is granted only to the workload service account.
+- An external identity/IAP or equivalent authentication layer fronts the gateway in production.
+- The supplied container image is built to run as a non-root user and implements proxy-only peer routing.
 
-### Open questions
-- Which organization-specific API Gateway authentication policy and allowed peer identities should be added before production?
-- Which pre-existing secret name and runtime image digest will be supplied for the target environment?
-- What gateway hostname, certificate, and DNS ownership are required?
+Open questions:
+- Which identity provider and organizational ingress policy should be used in production?
+- What exact SLO, retention, egress, and peer allow-list are required?
 
-## Phase 1 — selected architecture and IaC
+## Selected Google Cloud products
 
-### Selected Google Cloud products
-- Cloud Run (managed workload), with internal-and-cloud-load-balancing ingress.
-- API Gateway (authenticated gateway/proxy boundary).
-- Secret Manager (secret reference only).
-- Artifact Registry (pinned container image source).
-- Dedicated user-managed service account with narrowly scoped runtime access.
-- Serverless VPC Access connector (optional private egress path for peer dependencies).
-- Terraform Google provider.
+- Cloud Run for the stateless gateway workload.
+- Secret Manager for referenced runtime secrets.
+- IAM service account and narrowly scoped `roles/secretmanager.secretAccessor` binding.
+- Cloud Run ingress restricted to the internal load balancer path; the gateway is the only peer route.
+- Terraform Google provider for reproducible infrastructure.
+
+## Architecture
 
-### Architecture diagram
 ```mermaid
 flowchart LR
-  C[Approved client/peer] -->|TLS + gateway auth| G[API Gateway\npolicy + proxy]
-  G -->|authenticated HTTPS| R[Cloud Run\ningress: internal + LB only\nnon-root image]
-  R -->|secret reference, runtime identity| S[Secret Manager]
-  R -. optional private peer egress .-> V[Serverless VPC Access]
-  V -.-> P[Private peer service]
-  I[Artifact Registry\npinned digest] --> R
-  O[Operator] -->|set deploy_enabled=true\nwith approved vars| T[Terraform plan/apply]
-  T --> G
-  T --> R
+  Client[Authenticated client] --> LB[Platform gateway / proxy]
+  LB --> Run[Cloud Run gateway workload\nnon-root, no propagated credentials]
+  Run --> Peer[Peer services via gateway/proxy]
+  Run -. secret reference only .-> SM[Secret Manager]
+  IAM[IAM least-privilege service account] --> Run
 ```
 
-### Traffic, identity, and credential rules
-1. API Gateway is the public/client-facing proxy. Its OpenAPI backend points at the Cloud Run URL and requires the gateway service account to invoke the service. Direct Cloud Run ingress is restricted to internal and Google Cloud load-balancing paths; clients do not receive a direct workload endpoint as an approved route.
-2. Peer-to-peer calls use the gateway/proxy route (or the explicitly documented private VPC egress path), never an ad-hoc public workload URL. Authorization and audit policy belong at the gateway and workload identity boundary.
-3. Cloud Run uses a dedicated service account with only `roles/secretmanager.secretAccessor` on the named secret. Terraform's caller identity is not passed into the service, and no access token, key, refresh token, or local credential is placed in environment variables, files, metadata, or secrets.
-4. The image reference is digest-pinned. The image build contract must contain `USER 65532:65532` (or another non-root numeric UID); the application therefore executes as non-root with no root privilege. The Terraform input validation rejects mutable tags.
-5. `secret_data` is intentionally absent. `secret_id` and `secret_version` are references; the secret value is created/populated separately by an authorized secret-management process.
+The gateway is the sole peer traffic path. Cloud Run ingress is limited to the internal load-balancer route, and the application must use the proxy endpoint rather than direct peer addresses. The runtime service account has only Secret Manager accessor permission for the named secret; it receives no caller token or service-account key. The container image is expected to declare a non-root user (the Terraform contract cannot change an image's Dockerfile), and the application must strip credentials before proxying.
 
-### Explicit provisioning gate and operator disclosure
-All managed resources have `count = var.deploy_enabled ? 1 : 0`; the default is `false`. `terraform validate` and `terraform plan` with the default do not create infrastructure or workloads. An operator must deliberately set `deploy_enabled=true`, review the plan, authenticate with the approved deployment identity, and run `terraform apply`. Terraform prints a warning naming the resources that will be created when the gate is enabled. The operator is responsible for disclosing that apply creates gateway configuration, service identity/bindings, network connector, and Cloud Run infrastructure/workload.
+## Provisioning and IaC safety
 
-### Terraform IaC
-The authoritative Terraform source is `terraform/main.tf`. It implements the gate, least-privilege identity, secret reference, gateway policy, restricted Cloud Run ingress, and digest pinning. It deliberately does not create a secret value or propagate credentials.
+Terraform is in `terraform/`. Every resource has `count = var.provision ? 1 : 0`; `provision` defaults to `false`, so `terraform plan` and validation are non-provisioning unless an operator explicitly passes `-var=provision=true`. `service_image` and `secret_id` are references, not secret contents. Never place a secret value in tfvars, logs, or CI variables. Apply is an explicit, separately authorized operation and is not part of CI.
 
-## Phase 2 — validation without deployment
+## World-impacting capabilities and controls
 
-Validation commands:
-```bash
-terraform -chdir=terraform fmt -check -diff
-terraform -chdir=terraform init -backend=false
-terraform -chdir=terraform validate
-terraform -chdir=terraform plan -refresh=false -input=false -var='deploy_enabled=false'
-```
+The gateway is world-impacting because it can accept internet-originated callers when the platform load balancer/authentication policy permits it, invoke workloads, and proxy traffic to peers. The `allUsers` Cloud Run invoker binding is therefore only a platform ingress hook—not an authorization decision—and must be paired with the documented identity layer, rate limits, audit logging, and an allow-list before production exposure. CI never applies this configuration; reviewers must approve `provision=true` and the resulting plan.
 
-The plan-oriented check is intentionally performed with the default gate disabled. It must show no resource creation. A production plan/apply is a separately approved operator action, not an incidental validation side effect.
+## Verification evidence
 
-Validation evidence recorded for this revision:
-- Terraform formatting: valid by source formatting review; run `terraform fmt -check -diff` in CI.
-- Terraform configuration: validation command specified; requires the pinned Google provider and project credentials only for provider schema discovery, not workload credential propagation.
-- Dry run: gate-off plan is the required no-provisioning check.
-- Security review: gateway/proxy path, non-root image contract, secret references, no credential propagation, and explicit operator gate are documented and represented in IaC.
+Executed against the committed Terraform and workflow artifacts (no cloud resources were created):
 
-## Phase 3 — packaging and publication
+- `terraform fmt -check -recursive terraform` — **PASS**
+- `terraform init -backend=false` — **PASS**
+- `terraform validate` — **PASS**
+- `terraform plan -var='project_id=example-project' -var='service_image=us-docker.pkg.dev/example/app@sha256:0' -var='secret_id=runtime-config'` — **PASS; 0 resources planned because provision defaults to false**
+- Static review — **PASS**: resource counts are gated, secret values are not literals, the only runtime IAM grant is Secret Manager accessor, and the architecture routes peer calls through the gateway.
 
-This guide is the packaged architecture artifact. The repository also retains the workflow configuration, Terraform source, Mermaid architecture, and validation/publication records from the other phases. Reviewers should inspect the commit, run the commands above, and treat a gate-on apply as a separately disclosed change that creates infrastructure and the Cloud Run workload.
+## SCM workflow gates
 
-## Operator runbook
+`.github/workflows/ci.yml` runs on both `push` and `pull_request`. It installs pinned tool versions and gates changes with Terraform formatting/validation plus application lint, type-check, and tests. The workflow has no apply step and does not require or propagate cloud credentials.
 
-1. Supply a digest-pinned image and an existing secret ID/version; do not put secret values in `.tfvars` or command history.
-2. Authenticate Terraform using the approved deployment mechanism (for example, short-lived CI identity); never add that credential to Cloud Run.
-3. Run the gate-off validation commands.
-4. Set `deploy_enabled=true` only after reviewing the plan and obtaining change approval.
-5. Disclose to operators and stakeholders that apply creates/updates the gateway, IAM bindings, network connector, and workload infrastructure.
-6. Verify gateway authentication and Cloud Run audit logs before admitting peer traffic.
+## Terraform
+
+See the executable files under `terraform/variables.tf`, `terraform/main.tf`, and `terraform/outputs.tf`. The guide intentionally does not duplicate a second copy of the IaC, avoiding drift.