From 232568e3bc0e37d9ed64348a61bf62ee5ad43e3b Mon Sep 17 00:00:00 2001 From: Vikram Reddy Date: Sun, 5 Jul 2026 21:55:36 +0530 Subject: [PATCH 1/9] Update documentation for devspec installation and usage with WinGet and enhance README structure --- README.md | 289 ++++++------------------------------ docs/how-to/README.md | 259 ++++++++++++-------------------- docs/how-to/setup/winget.md | 7 +- 3 files changed, 138 insertions(+), 417 deletions(-) diff --git a/README.md b/README.md index f246de1..00a12b0 100644 --- a/README.md +++ b/README.md @@ -2,41 +2,40 @@ `devspec` is a spec-driven development framework for teams using GitHub Copilot and other AI coding agents. -It stores planning, implementation, review, and recovery state in Git-tracked files instead of relying on chat history. - -Use it when you want agents to follow the same workflow for: - -- project context, architecture, engineering rules, and coding standards -- feature, bug, and security work-item intake -- clarification, finalization, task planning, implementation, and review -- session recovery from repository artifacts +It stores planning, implementation, review, and recovery state in Git-tracked files instead of relying on chat history. Use it when you want agents to follow the same workflow for project context, engineering standards, work-item intake, implementation, review, and session recovery. ## Quick Start -Install with the `devspec` CLI. The recommended one-off path is `uvx`, which avoids a permanent global install and works well on machines where developers cannot write to shared PATH folders. +Install with the `devspec` CLI from the target repository. The recommended one-off path is `uvx`, which avoids a permanent global install and works well on restricted developer machines. + +```text +uvx devspec init --target . --profile all --repo-state existing +uvx devspec doctor --target . --profile all +``` -For install, workflow, AI coding agent, multi-repo, provider, validation, and upgrade examples, see [`docs/how-to/README.md`](docs/how-to/README.md). +Use `--repo-state new` for a new repository. After validation, commit the copied framework files, run the foundation flow, then start the first work item. -1. Open the target repository in VS Code or the selected AI coding tool. -2. Install all supported adapter files into the repository: +For the full setup manual, see [docs/how-to/README.md](docs/how-to/README.md). - ```text - uvx devspec init --target . --profile all --repo-state existing - ``` +## Setup Options - Use `--repo-state new` for a new repository. +| Situation | Start here | +| --- | --- | +| Simplest one-off setup | [uv and uvx setup](docs/how-to/setup/uv.md) | +| Persistent macOS/Linux package install | [Homebrew setup](docs/how-to/setup/homebrew.md) | +| Approved Windows package install | [WinGet setup](docs/how-to/setup/winget.md) | +| Package managers are blocked | [Manual copy setup](docs/how-to/setup/manual-copy.md) | -3. Validate the install: +Install profiles let you choose which AI coding agent files to copy. Most multi-agent teams can start with `--profile all`; single-tool teams can use a smaller profile such as `copilot`, `codex`, `cursor`, `claude`, `gemini`, or `antigravity`. - ```text - uvx devspec doctor --target . --profile all - ``` +## Core Workflow -4. Commit the copied files. -5. Run the foundation flow for a new or existing repository. -6. Start the first work item. +`devspec` has two workflow layers. -Manual copy remains supported as a fallback when package managers are blocked. Copy the framework folders listed in [Manual Copy Fallback](#manual-copy-fallback), then commit the copied files. +| Layer | Purpose | Full guide | +| --- | --- | --- | +| Foundation | Capture stable project context, architecture, stack, structure, standards, and rules. | [New repository](docs/how-to/README.md#foundation-flow-for-a-new-repository), [existing repository](docs/how-to/README.md#foundation-flow-for-an-existing-repository) | +| Work items | Move one feature, bug, security issue, or accepted change request from intake to review. | [Work-item lifecycle](docs/how-to/README.md#work-item-lifecycle) | For a new project: @@ -69,240 +68,36 @@ Then run the work-item flow: /devspec.review ``` -For related scope added after a work item is finalized or later, run `/devspec.story` again with change-request input. Related requests append as `CR-001`, `CR-002`, and so on inside the same work-item folder without rewriting the baseline story, completed tasks, implementation evidence, or review history. Independent requests ask whether to append to the current item, create a new linked work item, or provide `Custom Answer`. - -Use `/devspec.clarify` only when a work item records a blocking question. Use `/devspec.diagram` when a diagram would clarify architecture, workflow, state, sequence, or domain behavior; SVG is the default, with optional Mermaid or HTML via `format=` combinations. Example: `format=svg`, `format=html`, `format=mermaid`, `format=svg+html`, `format=svg+mermaid`, `format=svg+html+mermaid`, `format=html+mermaid`. - -## How It Works - -`devspec` has two workflow layers. - -| Layer | Purpose | Commands | -| --- | --- | --- | -| Foundation | Capture stable project context, architecture, stack, structure, standards, and rules. | `/devspec.extract`, `/devspec.projectcontext`, `/devspec.techstack`, `/devspec.codebase-structure`, `/devspec.coding-standards`, `/devspec.rules` | -| Work items | Move one feature, bug, security issue, or accepted change request from intake to review while preserving prior scope history. | `/devspec.story`, `/devspec.clarify`, `/devspec.finalize`, `/devspec.tasks`, `/devspec.implement`, `/devspec.review` | - -```mermaid -flowchart TD - Start["Start"] --> State{"Project state?"} - State -- "new" --> ProjectContext["/devspec.projectcontext"] - State -- "existing" --> Extract["/devspec.extract"] - Extract --> ProjectContext - ProjectContext --> TechStack["/devspec.techstack"] - TechStack --> Structure["/devspec.codebase-structure"] - Structure --> Standards["/devspec.coding-standards"] - Standards --> Rules["/devspec.rules"] - Rules --> Story["/devspec.story"] - Story --> Blocked{"Blocking question?"} - Blocked -- "yes" --> Clarify["/devspec.clarify"] - Clarify --> Story - Blocked -- "no" --> Finalize["/devspec.finalize"] - Finalize --> Ready{"Ready?"} - Ready -- "no" --> Clarify - Ready -- "yes" --> Tasks["/devspec.tasks"] - Tasks --> Implement["/devspec.implement"] - Implement --> Review["/devspec.review"] - Review --> Outcome{"Review outcome?"} - Outcome -- "changes requested" --> Implement - Outcome -- "approved" --> Done["Done"] -``` - -## Command Reference - -| Command | Use when | Main output | -| --- | --- | --- | -| `/devspec.extract` | Existing code/docs should seed the foundation. | Foundation, architecture, extraction, and diagram queue artifacts. | -| `/devspec.projectcontext` | Product and business context must be recorded; durable principles and operational governance route to their own artifacts. | `devspec/foundation/project-context.md` | -| `/devspec.techstack` | Stack, runtime, hosting, tooling, or support status must be recorded. | `devspec/foundation/tech-stack.md` | -| `/devspec.codebase-structure` | Repository layout, boundaries, multi-repo access, or integration contracts must be recorded. | `devspec/foundation/codebase-structure.md` | -| `/devspec.coding-standards` | Engineering standards and observed patterns must be recorded. | `devspec/foundation/coding-standards.md` | -| `/devspec.rules` | Operational rules, compliance requirements, governance procedures, and gates must be recorded. | `devspec/foundation/rules.md` | -| `/devspec.story` | A feature, bug, security issue, task, PBI, provider reference, or related post-baseline change request needs intake. | Work-item `meta.md`, `story.md`, `decisions.md`, `notes.md` | -| `/devspec.clarify` | A blocking question must be resolved. | Work-item `clarify.md` | -| `/devspec.finalize` | A work item needs an implementation-ready brief. | Work-item `finalize.md` | -| `/devspec.tasks` | A ready brief needs executable tasks. | Work-item `tasks.md` | -| `/devspec.implement` | Pending tasks should be implemented and recorded. | Work-item `implement.md` and code changes when applicable | -| `/devspec.review` | Implemented work needs review against the finalized brief. | Work-item `review.md` | -| `/devspec.diagram` | A diagram should be created or updated. | Architecture or work-item SVG diagram artifacts by default, with optional Mermaid or HTML artifacts | - -For exact command contracts, see `devspec/adapters/command-registry.md`. +Use `/devspec.clarify` only when a work item records a blocking question. Use `/devspec.diagram` when a diagram would clarify architecture, workflow, state, sequence, or domain behavior. ## AI Tool Support GitHub Copilot prompt and agent files are the reference implementation. Other adapters are thin wrappers around the same command registry and Git-tracked artifacts. -| Tool | Files | Notes | -| --- | --- | --- | -| GitHub Copilot | `.github/prompts/`, `.github/agents/`; optional `.github/skills/` | Native `/devspec.*` command implementation. | -| Claude Code | `.claude/skills/devspec-*/SKILL.md` | Project skills for canonical commands. | -| OpenAI Codex | `AGENTS.md`, `devspec/adapters/codex.md` | Repository instructions and Codex guidance. | -| Cursor | `.cursor/rules/devspec-workflow.mdc`, `AGENTS.md` | Project rules plus shared fallback instructions. | -| Gemini CLI | `GEMINI.md`, optional `.gemini/commands/devspec/*.toml` | `GEMINI.md` is enough for context; TOML files only add native `/devspec:*` shortcuts. | -| Google Antigravity | `.agents/rules/devspec-workflow.md`, `.agents/skills/devspec-*.md` | Workspace rule and skills using `/devspec-*` names. | - -Canonical command names remain `/devspec.*`. Some adapters expose host-native shortcuts such as `/devspec:story` or `/devspec-story`. - -Related docs: - -- [`docs/how-to/README.md`](docs/how-to/README.md) -- [`devspec/adapters/README.md`](devspec/adapters/README.md) -- [`devspec/adapters/compatibility-matrix.md`](devspec/adapters/compatibility-matrix.md) -- [`devspec/adapters/validation-flows.md`](devspec/adapters/validation-flows.md) -- [`devspec/adapters/enterprise-governance.md`](devspec/adapters/enterprise-governance.md) - -## Repository Layout - -| Path | Purpose | +| Tool | Setup notes | | --- | --- | -| `devspec/constitution.md` | Rare durable project principles across all work items and agents; principle changes require explicit confirmation. | -| `devspec/foundation/` | Product context, stack, structure, standards, operational rules, exclusions, and provider policy. | -| `devspec/architecture/` | Architecture overview, default SVG diagrams, optional Mermaid or HTML diagrams, ADR templates, and artifact queue. | -| `devspec/work-items/` | One folder per feature, bug, or security work item. | -| `devspec/adapters/` | Multi-agent registry, compatibility, validation, and governance docs. | -| `docs/how-to/` | User manual with install, workflow, AI coding agent, multi-repo, provider, validation, and upgrade examples. | -| `.github/prompts/` | Copilot slash-command prompts. | -| `.github/agents/` | Copilot agent definitions. | -| `.github/skills/` | Optional reusable skills. | -| `AGENTS.md` | Shared instructions for tools that read `AGENTS.md`. | -| `GEMINI.md` | Gemini-native repository context. | -| `.claude/`, `.cursor/`, `.gemini/`, `.agents/` | Optional adapter support. | - -## Manual Copy Fallback +| GitHub Copilot | Native `/devspec.*` prompt commands through `.github/prompts/` and `.github/agents/`. | +| Claude Code | Project skills expose `/devspec-*` command-style invocations. | +| OpenAI Codex | `AGENTS.md` provides always-on repository instructions and Codex workflow guidance. | +| Cursor | Project rules guide Cursor Agent and Inline Edit. | +| Gemini CLI | `GEMINI.md` provides context; optional commands expose `/devspec:*` shortcuts. | +| Google Antigravity | Workspace rules and skills expose `/devspec-*` command-style invocations. | -Use manual copy only when the CLI, `uvx`, package managers, and release ZIP automation are blocked. Copy these core framework files and folders from the `devspec` release into the target repository root: +Canonical command names remain `/devspec.*`. Some adapters expose host-native shortcuts such as `/devspec:story` or `/devspec-story`; see [Command Invocation by Agent](docs/how-to/README.md#command-invocation-by-agent). -```text -devspec/ -.github/prompts/ -.github/agents/ -AGENTS.md -``` +For command contracts, see [devspec/adapters/command-registry.md](devspec/adapters/command-registry.md). For copy-ready examples, see [Command Examples](docs/how-to/README.md#command-examples). -Then copy only the adapter files your team uses: +## More Documentation -| Tool | Additional files | +| Topic | Link | | --- | --- | -| GitHub Copilot | `.github/skills/` | -| Claude Code | `.claude/` | -| OpenAI Codex | No extra files beyond `AGENTS.md` | -| Cursor | `.cursor/` | -| Gemini CLI | `GEMINI.md`, `.gemini/` | -| Google Antigravity | `.agents/` | - -The release payload may also include this repository's `README.md` and `docs/how-to/` for reference. Do not copy them into the target repository as installed framework files, and do not overwrite a target project's root `README.md`. Keep credentials, provider tokens, local auth files, and personal settings outside copied framework files. - -Do not copy `.github/workflows/` into target repositories. Those workflows are this framework repository's CI/release automation, and target projects should own their own CI/CD configuration. - -## Operating Rules - -- Keep `.github/prompts/*.prompt.md` and `.github/agents/*.agent.md` as the protected reference contracts. -- Keep adapter support additive; do not change command intent for another tool. -- Store workflow state in Git-tracked `devspec/` artifacts, not chat memory. -- Use `devspec/glossary.md` for status values. -- Use `devspec/foundation/codebase-structure.md` for repository access requirements. -- Keep product facts in `devspec/foundation/project-context.md`, durable principles in `devspec/constitution.md`, and operational gates, compliance rules, enforcement details, and evolving governance in `devspec/foundation/rules.md`. -- Keep secrets and provider credentials outside prompt, agent, adapter, and artifact files. -- Record blockers instead of guessing. -- Recommend only registered `/devspec.*` commands. - -## Multi-Repo Work - -For multi-repo systems, open one workspace or tool project that includes every repository agents should inspect, edit, test, or coordinate. - -Record repository roles, local paths, access requirements, and boundaries in: - -```text -devspec/foundation/codebase-structure.md -``` - -Access values are defined in: - -```text -devspec/glossary.md#access-requirement-values -``` - -## Provider Integrations - -Use provider integrations when `/devspec.story` should resolve GitHub, Jira, Azure DevOps, or other external work-item references. - -Provider policy lives in: - -```text -devspec/foundation/provider-integrations.md -``` - -Keep authentication outside prompt artifacts. Prefer read-only provider access unless write-back is explicitly required. - -## Validation - -Enterprise readiness requires these flows to pass for each supported adapter: - -- new repository foundation flow -- existing repository extraction flow -- full story lifecycle -- append-only change-request flow -- cross-tool recovery from Git-tracked artifacts - -Use: - -```text -devspec/adapters/validation-flows.md -``` - -## Upgrade Notes - -Use the CLI to inspect and apply framework upgrades: - -```text -devspec diff --target . -devspec sync --target . --profile all --dry-run -devspec sync --target . --profile all -``` - -Framework-owned files may be replaced or diff-applied during upgrades: - -- `.github/prompts/` -- `.github/agents/` -- `.github/skills/` -- adapter support folders -- `AGENTS.md` -- `GEMINI.md` -- `devspec/adapters/` -- `devspec/**/_template/` - -The `.github/workflows/` directory is intentionally excluded from setup and sync. Those files are this repository's CI/release automation, and target projects should own their own CI/CD configuration. - -Project-owned files should be migrated or merged, not overwritten: - -- `devspec/foundation/*.md` -- `devspec/architecture/*.md` -- `devspec/architecture/diagrams/*.md` -- `devspec/architecture/images/*.svg` -- `devspec/architecture/html/*.html` -- `devspec/work-items/**` -- `devspec/constitution.md` -- `devspec/glossary.md` - -## Recommended Adoption - -1. Install into one target repository with `uvx devspec init --target . --profile all --repo-state existing`. -2. Run the foundation flow. -3. Complete one real feature work item. -4. Complete one real bug work item. -5. Add security-vulnerability flow validation if relevant. -6. Adjust foundation docs based on what the first runs teach the team. - -## Deployment Development - -When changing the installer, profile manifest, package metadata, or release automation, run: - -```text -uv run pytest -powershell -ExecutionPolicy Bypass -File scripts/test-local-install.ps1 -bash scripts/test-local-install.sh -``` - -Update `packaging/devspec-profiles.json` whenever adapter files are added, removed, or moved. +| Setup guides | [docs/how-to/setup/README.md](docs/how-to/setup/README.md) | +| Full workflow guide | [docs/how-to/README.md](docs/how-to/README.md) | +| Upgrades | [docs/how-to/README.md#upgrades](docs/how-to/README.md#upgrades) | +| Adapter guide | [devspec/adapters/README.md](devspec/adapters/README.md) | +| Compatibility matrix | [devspec/adapters/compatibility-matrix.md](devspec/adapters/compatibility-matrix.md) | +| Validation flows | [devspec/adapters/validation-flows.md](devspec/adapters/validation-flows.md) | +| Enterprise governance | [devspec/adapters/enterprise-governance.md](devspec/adapters/enterprise-governance.md) | ## License diff --git a/docs/how-to/README.md b/docs/how-to/README.md index 8ac41bf..ba3e8dd 100644 --- a/docs/how-to/README.md +++ b/docs/how-to/README.md @@ -9,9 +9,11 @@ This guide is practical usage documentation. The provider-neutral source of trut - [Install devspec](#install-devspec) - [Setup Guides](setup/README.md) - [Install Profiles](#install-profiles) +- [Repository Layout](#repository-layout) - [AI Coding Agent Setup](#ai-coding-agent-setup) - [Restricted Developer Machines](#restricted-developer-machines) - [Command Invocation by Agent](#command-invocation-by-agent) +- [Operating Rules](#operating-rules) - [Foundation Flow for a New Repository](#foundation-flow-for-a-new-repository) - [Foundation Flow for an Existing Repository](#foundation-flow-for-an-existing-repository) - [Work-Item Lifecycle](#work-item-lifecycle) @@ -20,6 +22,7 @@ This guide is practical usage documentation. The provider-neutral source of trut - [Diagrams](#diagrams) - [Multi-Repo Work](#multi-repo-work) - [Provider Integrations](#provider-integrations) +- [Recommended Adoption](#recommended-adoption) - [Validation](#validation) - [Upgrades](#upgrades) - [Troubleshooting](#troubleshooting) @@ -66,6 +69,25 @@ Choose the smallest profile that matches the tools your team uses. No install profile includes `.github/workflows/`. Those files are this repository's release and validation automation, not target-repository setup content. +## Repository Layout + +After installation, `devspec` stores framework guidance, project context, and work-item history in predictable Git-tracked locations. + +| Path | Purpose | +| --- | --- | +| `devspec/constitution.md` | Rare durable project principles across all work items and agents; principle changes require explicit confirmation. | +| `devspec/foundation/` | Product context, stack, structure, standards, operational rules, exclusions, and provider policy. | +| `devspec/architecture/` | Architecture overview, default SVG diagrams, optional Mermaid or HTML diagrams, ADR templates, and artifact queue. | +| `devspec/work-items/` | One folder per feature, bug, security issue, task, or accepted change request. | +| `devspec/adapters/` | Multi-agent registry, compatibility, validation, and governance docs. | +| `docs/how-to/` | User manual with install, workflow, AI coding agent, multi-repo, provider, validation, and upgrade examples. | +| `.github/prompts/` | GitHub Copilot slash-command prompts and canonical command contracts. | +| `.github/agents/` | GitHub Copilot agent definitions. | +| `.github/skills/` | Optional reusable GitHub Copilot skills. | +| `AGENTS.md` | Shared instructions for tools that read `AGENTS.md`. | +| `GEMINI.md` | Gemini-native repository context. | +| `.claude/`, `.cursor/`, `.gemini/`, `.agents/` | Optional adapter support for Claude Code, Cursor, Gemini CLI, and Google Antigravity. | + ## AI Coding Agent Setup | AI coding agent | Installed files | Notes | @@ -119,6 +141,20 @@ Canonical command names remain `/devspec.*`. Some AI coding agents expose host-n For OpenAI Codex and Cursor, exact slash-command registration is not assumed. If the tool does not invoke the command directly, type the example as a chat instruction and let the AI coding agent read `AGENTS.md`, `devspec/adapters/command-registry.md`, and the canonical prompt and agent files named in the registry. +## Operating Rules + +Use these rules when running or adapting `devspec` workflows: + +- Keep `.github/prompts/*.prompt.md` and `.github/agents/*.agent.md` as the protected reference contracts. +- Keep adapter support additive; do not change command intent for another tool. +- Store workflow state in Git-tracked `devspec/` artifacts, not chat memory. +- Use `devspec/glossary.md` for status values. +- Use `devspec/foundation/codebase-structure.md` for repository access requirements. +- Keep product facts in `devspec/foundation/project-context.md`, durable principles in `devspec/constitution.md`, and operational gates, compliance rules, enforcement details, and evolving governance in `devspec/foundation/rules.md`. +- Keep secrets and provider credentials outside prompt, agent, adapter, and artifact files. +- Record blockers instead of guessing. +- Recommend only registered `/devspec.*` commands. + ## Foundation Flow for a New Repository Use this flow when the repository is new or has little implementation evidence. @@ -382,204 +418,82 @@ Use `/devspec.diagram` when a diagram would clarify architecture, workflow, stat Examples: +System and application architecture: + ```text -/devspec.diagram runtime architecture -/devspec.diagram checkout payment flow -/devspec.diagram authentication state transitions -/devspec.diagram batch-generate queued process-flow diagrams -/devspec.diagram format=mermaid authentication state transitions -/devspec.diagram format=html runtime architecture -/devspec.diagram format=svg+html runtime architecture -/devspec.diagram format=svg+mermaid checkout payment flow -/devspec.diagram format=html+mermaid authentication state transitions -/devspec.diagram format=svg+html+mermaid runtime architecture +/devspec.diagram system architecture showing all major components, boundaries, integrations, data stores, and user entry points +/devspec.diagram service dependency map for identity, billing, notifications, reporting, and shared platform services +/devspec.diagram data ownership and flow across UI, API, domain services, operational database, analytics store, and external reporting tools ``` -Durable SVG images live under `devspec/architecture/images/` by default. Optional Mermaid diagram artifacts live as Markdown files under `devspec/architecture/diagrams/`. Optional standalone HTML diagrams live under `devspec/architecture/html/`. High-level architecture diagram references belong in `devspec/architecture/overview.md`. Temporary work-item-specific SVG diagrams belong under `devspec/work-items//images/`, with optional Mermaid in `diagrams.md` and optional HTML under `html/`. - -Extraction may seed diagram candidates into `devspec/architecture/artifact-queue.md`. Use `/devspec.diagram` as the normal follow-up when a queued diagram should be generated. `/devspec.extract` preserves requested diagram format preferences in queue notes and may generate at most one approved diagram artifact set during extraction, matching the diagram approval gate. - -Use `format=svg` or omit the format token for SVG output. Use `format=mermaid` when a Markdown/Mermaid artifact is needed. Use `format=html` when a standalone HTML artifact is needed. Example: `format=svg`, `format=html`, `format=mermaid`, `format=svg+html`, `format=svg+mermaid`, `format=svg+html+mermaid`, `format=html+mermaid`. - -Optional generated Mermaid diagrams should follow the shared readability rules: +Cloud infrastructure architecture: -- Keep `DIA-*` and `dia-NNN-*` names for the durable diagram file and diagram queue, not for Mermaid nodes. -- Use short alphanumeric node IDs, double-quoted node labels of 1-4 words, no `\n` or `
` line breaks, and 2-3 word edge labels. -- Keep architectural flowcharts focused on one primary domain at macro level, without overloaded graphs, cross-layer arrows, decision diamonds, UI micro-interactions, or return/error paths. -- Keep architectural flowcharts unidirectional and adjacent by layer. -- Use `sequenceDiagram` for exact step-by-step request and response behavior, showing happy-path messages between distinct participants with method-name labels. -- Keep runtime communication separate from compile-time project dependencies, exclude SDLC actors and build artifacts from logical architecture diagrams, and place owned application databases inside the system boundary. -- Avoid API, Swagger, tech stack, version, library, hosting, and framework boilerplate details in flowchart nodes unless the requested diagram specifically needs that detail. - -Example Mermaid style: - -```mermaid -flowchart LR - AuthCtrl["Authentication Controller"] -->|"Validates Session"| ProviderSvc["Provider Service"] - ProviderSvc -->|"Reads Profile"| UserDb["User Database"] +```text +/devspec.diagram infrastructure architecture for an Azure cloud-native distributed application with App Gateway, AKS, Functions, Service Bus, Key Vault, SQL, Storage, and Monitor +/devspec.diagram infrastructure architecture for an AWS cloud-native distributed application with CloudFront, API Gateway, ECS, Lambda, SQS, RDS, S3, Secrets Manager, and CloudWatch +/devspec.diagram infrastructure architecture for a Google Cloud distributed application with Load Balancing, GKE, Cloud Run, Pub/Sub, Cloud SQL, Cloud Storage, Secret Manager, and Cloud Monitoring ``` -Generated SVG diagrams should be standalone XML created from `devspec/architecture/_template/architecture-diagram.svg` or, for process-flow SVGs, `devspec/architecture/_template/process-flow-diagram.svg`, with inline styles, no external assets, no `