fix(seo): correct unsourceable claims and stale enumerations across blog

content/blog/announcing-7-0-of-the-pulumi-aws-provider/index.md

@@ -2,6 +2,7 @@
 title: "Pulumi AWS Provider 7.0: Multi-Region Support, IAM Role Chaining, and S3 Resource Simplification"
 allow_long_title: true
 date: 2025-08-05T09:00:00-04:00
+updated: 2026-08-22
 draft: false
 meta_desc: "Pulumi AWS Provider 7.0 adds multi-region support, IAM role chaining, and improved S3 resource management for seamless AWS infrastructure as code."
 authors:
@@ -14,7 +15,7 @@ category: product
 ---
 
 
-[Pulumi AWS provider 7.0](https://www.pulumi.com/registry/packages/aws/) is here with powerful new capabilities that simplify and scale **infrastructure as code on AWS**. As the most widely used provider in the Pulumi ecosystem, it offers access to the full surface area of the upstream Terraform AWS Provider in Pulumi projects in all supported languages, like TypeScript, Python, Go, .NET, Java, and YAML.
+[Pulumi AWS provider 7.0](https://www.pulumi.com/registry/packages/aws/) is here with powerful new capabilities that simplify and scale **infrastructure as code on AWS**. As the most widely used provider in the Pulumi ecosystem, it offers access to the resource surface of the upstream Terraform AWS Provider in Pulumi projects in all supported languages, like TypeScript, Python, Go, .NET, Java, and YAML.
 
 The [7.0 release](https://github.com/pulumi/pulumi-aws/releases/tag/v7.0.0) brings fixes and improvements to the provider, including several breaking changes as part of the major version release.
 

content/blog/aws-cdk-vs-pulumi-why-sst-switched/index.md

@@ -8,7 +8,7 @@ title: "AWS CDK vs Pulumi: Why SST Chose Pulumi"
 # the time portion of the date value; posts are sorted in descending order by
 # date/time.
 date: 2024-09-25T07:32:40Z
-updated: 2025-03-05
+updated: 2026-08-22
 
 # The draft setting determines whether a post is published. Set it to true if
 # you want to be able to merge the post without publishing it.
@@ -156,7 +156,7 @@ One of Pulumi's most significant benefits for SST users is the simplified mental
 Instead of having to navigate the complexities of intermediary formats, deployment pipelines, and the separation between infrastructure code and deployment code, SST users can now focus on writing their infrastructure logic in the same programming languages they use for their application code. This makes it much easier for them to understand, maintain, and extend their infrastructure as their needs evolve.
 
 {{< blog/cta-card title="Build across any cloud with Pulumi" >}}
-Define your infrastructure in TypeScript, Python, Go, or C#, and deploy it across AWS, Azure, Google Cloud, and on-premises environments from one consistent workflow.
+Define your infrastructure in TypeScript, JavaScript, Python, Go, .NET, or Java, and deploy it across AWS, Azure, Google Cloud, and on-premises environments from one consistent workflow.
 {{< /blog/cta-card >}}
 
 ## The Future of SST with Pulumi

content/blog/azure-container-apps/index.md

@@ -1,7 +1,7 @@
 ---
 title: "Deploy Azure Container Apps with Docker and Pulumi"
 date: 2021-11-02T09:00:00-07:00
-updated: 2025-03-24
+updated: 2026-08-22
 meta_desc: "Learn how to deploy Docker containers to Azure Container Apps using Pulumi. A step-by-step guide for building scalable serverless apps in any language."
 authors:
     - mikhail-shilkov
@@ -75,7 +75,7 @@ Comparing to other vendors: Azure Container Apps are in the same space as **Goog
 
 ## Example: Run an HTTP API with Azure Container Apps and Pulumi
 
-Let's walk through the steps to build an example application with Azure Container Apps using infrastructure as code in familiar languages. In this scenario, we create an HTTP application that is available via a public domain name. We'll use Pulumi to provision the necessary resources. In this example, we will use TypeScript however you could also use JavaScript, Python, Go, and C#.
+Let's walk through the steps to build an example application with Azure Container Apps using infrastructure as code in familiar languages. In this scenario, we create an HTTP application that is available via a public domain name. We'll use Pulumi to provision the necessary resources. In this example, we will use TypeScript however you could also use JavaScript, Python, Go, and .NET.
 
 You can check out the complete source code in the Pulumi Examples:
 
@@ -489,7 +489,7 @@ $ curl $(pulumi stack output url)
 
 Azure Container Apps enable you to build applications in your favorite language with any dependencies and tools, package them as a container image, and deploy them in seconds. Container Apps abstract away infrastructure management by automatically scaling up and down to zero and only charging for the exact resources you use.
 
-This post shows how to use Pulumi to build a container image and publish it as an Azure Container App. Pulumi makes it easy to create artifacts and provision and manage cloud infrastructure on any cloud using familiar programming languages, including C#, TypeScript, Python, and Go. Docker images, ACR registries, container environments, and Apps can be managed within the same infrastructure definition.
+This post shows how to use Pulumi to build a container image and publish it as an Azure Container App. Pulumi makes it easy to create artifacts and provision and manage cloud infrastructure on any cloud using familiar programming languages, including .NET, TypeScript, Python, and Go. Docker images, ACR registries, container environments, and Apps can be managed within the same infrastructure definition.
 
 ### Further steps
 

content/blog/build-publish-containers-iac/index.md

@@ -6,6 +6,7 @@ tags: [containers, docker, kubernetes]
 category: tutorials
 meta_desc: "Go from Dockerfile to a fully running containerized service on your cloud of choice using infrastructure as code."
 date: "2020-12-08"
+updated: 2026-08-22
 
 ---
 
@@ -21,7 +22,7 @@ The general approach will be to create a new infrastructure as code project that
 * Builds and publishes your container image to that registry
 * Optionally, consumes the resulting image URL from a containerized task definition in Kubernetes, Amazon ECS, or any other container orchestrator
 
-All told, this will be just a few dozen lines of code. This article demonstrates doing this in AWS, Azure, Google Cloud, DigitalOcean, and Docker Hub, and offers code examples in each supported Pulumi language, namely Python, JavaScript, TypeScript, Go, and C#. These steps will work for any application that has a `Dockerfile` and is buildable by Docker. In principle, similar steps could be applied if you prefer to build your container image using different means, such as Buildpack.
+All told, this will be just a few dozen lines of code. This article demonstrates doing this in AWS, Azure, Google Cloud, DigitalOcean, and Docker Hub, and offers code examples in Python, JavaScript, TypeScript, Go, and .NET. These steps will work for any application that has a `Dockerfile` and is buildable by Docker. In principle, similar steps could be applied if you prefer to build your container image using different means, such as Buildpack.
 
 For purposes of illustration, we'll create a simple Nginx web server whose `Dockerfile` contains:
 

content/blog/claude-code-orchestration-frameworks/index.md

@@ -2,6 +2,7 @@
 title: "Superpowers, GSD, and GSTACK: Picking the Right Framework for Your Coding Agent"
 allow_long_title: true
 date: 2026-04-13
+updated: 2026-08-22
 draft: false
 meta_desc: "Three frameworks for AI coding agents compared: Superpowers enforces TDD, GSD prevents context rot, and GSTACK adds role-based governance."
 feature_image: feature.png
@@ -34,7 +35,7 @@ social:
         Here's how they compared.
 ---
 
-Three community frameworks have emerged that fix the specific ways AI coding agents break down on real projects. [Superpowers](https://github.com/obra/superpowers) enforces test-driven development. [GSD](https://github.com/gsd-build/get-shit-done) prevents context rot. [GSTACK](https://github.com/garrytan/gstack) adds role-based governance. All three started with Claude Code but now work across Cursor, Codex, Windsurf, Gemini CLI, and more.
+Three community frameworks have emerged that fix the specific ways AI coding agents break down on real projects. [Superpowers](https://github.com/obra/superpowers) enforces test-driven development. [GSD](https://github.com/gsd-build/get-shit-done) prevents context rot. [GSTACK](https://github.com/garrytan/gstack) adds role-based governance. All three started with Claude Code and have since added support for Cursor and Codex, though each has its own further list of supported agents beyond that shared core.
 
 Pulumi uses general-purpose programming languages to define infrastructure. TypeScript, JavaScript, Python, Go, .NET, Java. Every framework that makes AI agents write better TypeScript also makes your `pulumi up` better. After spending a few weeks with each one, I have opinions about when to use which.
 

content/blog/incident-response-as-code-pagerduty-pulumi/index.md

@@ -1,6 +1,7 @@
 ---
 title: "Incident Response as Code: Managing PagerDuty with Pulumi"
 date: 2026-07-20
+updated: 2026-08-22
 draft: false
 meta_desc: "Manage PagerDuty teams, schedules, escalation policies, and services with Pulumi, and wire alerting to the AWS infrastructure in the same program."
 feature_image: feature.png
@@ -55,7 +56,7 @@ flowchart LR
     EP -->|"level 2, after 15 min"| Lead["Team lead"]
 ```
 
-Everything on both sides of that diagram is one TypeScript program. If you would rather write Python, JavaScript, Go, .NET, Java, or YAML, the [Pulumi PagerDuty provider](https://www.pulumi.com/registry/packages/pagerduty/) supports all of them. It is bridged from PagerDuty's official Terraform provider (which started life as a community project by Alexander Hellbom before PagerDuty adopted it), so the resource coverage is identical.
+Everything on both sides of that diagram is one TypeScript program. If you would rather write Python, JavaScript, Go, .NET, Java, or YAML, the [Pulumi PagerDuty provider](https://www.pulumi.com/registry/packages/pagerduty/) supports all of them. It is bridged from PagerDuty's official Terraform provider (which started life as a community project by Alexander Hellbom before PagerDuty adopted it), so its resource coverage closely tracks the upstream provider.
 
 ## Prerequisites
 

content/blog/why-choose-pulumi-over-terraform/index.md

@@ -1,7 +1,7 @@
 ---
 title: "Why Choose Pulumi Over Terraform?"
 date: 2026-06-02
-lastmod: 2026-06-05
+lastmod: 2026-08-22
 meta_desc: "See why teams choose Pulumi over Terraform for modern infrastructure as code, with examples for refactoring, secrets, testing, and safer changes."
 feature_image: feature.png
 authors:
@@ -59,7 +59,7 @@ The tradeoff is important: Pulumi is still an infrastructure as code engine. Pro
 
 Terraform modules are powerful, but larger HCL codebases can require teams to maintain separate conventions for composition, validation, and reuse. Pulumi lets infrastructure teams use the features of whichever [supported programming language](https://www.pulumi.com/docs/iac/languages-sdks/) they choose, such as classes, functions, types, loops, package managers, linters, and test frameworks.
 
-Teams with HCL muscle memory are not left out, either. Pulumi now [supports HCL natively](https://www.pulumi.com/docs/iac/languages-sdks/hcl/) as one of its languages, alongside Python, TypeScript, JavaScript, Go, .NET, Java, and YAML. Part of a team can keep authoring in HCL while the project still benefits from Pulumi components, testing, and the same engine and package workflows as every other language.
+Teams with HCL muscle memory are not left out, either. Pulumi now [supports HCL natively](https://www.pulumi.com/docs/iac/languages-sdks/hcl/) as one of its languages, alongside Python, TypeScript, JavaScript, Go, .NET, Java, and YAML. A project written in Pulumi HCL runs your existing `.tf` files largely unchanged, backed by the same state management, secrets handling, and deployment engine as every other Pulumi language.
 
 For example, a platform team can wrap a standard storage pattern in a `ComponentResource` and share it like any other TypeScript abstraction:
 

content/blog/why-switch-to-pulumi/index.md

@@ -327,8 +327,9 @@ scalability, and collaboration.
     infrastructure engineer that works inside your existing workflow: it proposes
     changes, runs previews, responds to failures, and opens pull requests in tight
     feedback loops, grounded in the real state of your infrastructure in Pulumi
-    Cloud. Because that infrastructure is defined in Python, TypeScript, Go, .NET, or
-    Java rather than a bespoke configuration language, Neo can read, reason about,
+    Cloud. Because that infrastructure is defined in a [general-purpose
+    programming language](https://www.pulumi.com/docs/iac/languages-sdks/) rather
+    than a bespoke configuration language, Neo can read, reason about,
     test, and ship it the same way an AI coding agent already handles the rest of
     your codebase. Terraform, by contrast, is defined in HCL, a domain-specific
     configuration language that AI agents can generate and reason about less