agents/gcp_solution_architecture_agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: refactored manually
Some checks failed
validation / verify (push) Failing after 15s
Details

Browse Source
This commit is contained in:
Jonathan Boniface
2026-09-02 16:08:12 +01:00
parent 43cbd215e2
commit b9a924cf4a
63 changed files with 1398 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
solution-architecture-guide.md
View File

@@ -4,12 +4,13 @@
This guide packages manifest steps 0 through 7 for `gcp_solution_architecture_agent`, derived from the workflow-agent template. It is a reference baseline because no application-specific workflow request was supplied. Product selection was deferred during discovery and then made explicitly from the documented assumptions.
## Requirements
See [`docs/requirements.md`](docs/requirements.md). It contains functional requirements, non-functional requirements, constraints, assumptions, and open questions. The principal unresolved items are identity, scale/SLOs, data model, edge exposure, compliance, DR, and delivery governance.
See [`docs/requirements.md`](docs/requirements.md). It contains Functional requirements, Non-functional requirements, constraints, assumptions, and open questions. The principal unresolved items are identity, scale/SLOs, data model, edge exposure, compliance, DR, and delivery governance.
## Selected products
Cloud Run, Pub/Sub, Cloud Storage, Firestore, VPC, Serverless VPC Access, Cloud Logging, Cloud Monitoring, Artifact Registry, IAM, and Service Usage.
## Architecture
Mermaid Diagram:
```mermaid
flowchart LR
C[External clients] -->|HTTPS| R[Cloud Run service]
@@ -27,6 +28,7 @@ flowchart LR
Clients use the HTTPS service. The service persists structured state and objects, emits events, and relies on a separate idempotent worker for asynchronous processing. The runtime has a dedicated identity, controlled egress, and managed encryption defaults. Public invocation is a deliberate baseline pending the ingress and identity answers in the open questions.
## Infrastructure as code
Terraform configuration:
The deployable Terraform root is in [`terraform/`](terraform/). It enables APIs, creates a custom VPC/subnet and serverless connector, runtime service account, uniformly private object bucket, Firestore database, event/dead-letter topics, Artifact Registry repository, and Cloud Run service. Variables keep project, region, image, and labels configurable. No credentials or backend state are committed.
Apply only after review:
@@ -37,9 +39,9 @@ terraform -chdir=terraform apply
```
## Validation
See [`validation-results.md`](validation-results.md). The repository supplies formatting, initialization without a backend, Terraform validation, an opt-in refresh-free plan, and Python artifact tests. Resource deployment is not part of validation. In this generation environment, these commands are **not_run** because required executables, provider downloads, and credentials are unavailable; CI must run them and record the results.
See [`validation-results.md`](validation-results.md) for full Validation results. The repository supplies formatting, initialization without a backend, Terraform validation, an opt-in refresh-free plan, and Python artifact tests. Resource deployment is not part of validation. In this generation environment, these commands are **not_run** because required executables, provider downloads, and credentials are unavailable; CI must run them and record the results.
## Repository verification
## Repository Verification
- Step 4 guide persistence: represented by this non-empty file at the required path.
- Step 5 template/workflow conformance: represented by `workflow.yaml`, four phase entries, Terraform, diagram, requirements, and validation artifacts.
- Step 6 publication: performed by the repository generation commit.