Skip to content

fix(seo): normalize Pulumi language lists on llms.txt, JSON-LD entity descriptions, and /what-is/ pages - #20917

Open
workprentice[bot] wants to merge 6 commits into
masterfrom
workprentice/language-list-sweep-tier1-aeo-surfaces
Open

fix(seo): normalize Pulumi language lists on llms.txt, JSON-LD entity descriptions, and /what-is/ pages#20917
workprentice[bot] wants to merge 6 commits into
masterfrom
workprentice/language-list-sweep-tier1-aeo-surfaces

Conversation

@workprentice

@workprentice workprentice Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

What

Follow-up to #20770's site-wide Pulumi language-list sweep, tier 1 of 3 (highest AEO/GEO value): the LLM-ingestion surface, the JSON-LD entity descriptions rendered site-wide, the homepage/product pages, and the /what-is/ definitional pages. 22 files.

Canonical set

Per content/docs/iac/languages-sdks/_index.md front matter: Python, TypeScript, JavaScript, Go, .NET, Java, plus YAML and HCL. There is no single canonical ordering.

Classification methodology (reused from #20770)

Every occurrence of a stale language-list pattern was individually classified before editing:

  • A — full-set Pulumi claim (e.g. "Pulumi lets you write in X", a JSON-LD entity description): rewritten to the complete canonical set.
  • B — legitimately scoped Pulumi enumeration (a narrower technical context where only some languages apply, e.g. a sentence explicitly contrasting against YAML, or a table cell comparing against Terraform's HCL-only column): naming-only normalization (C# to .NET), nothing added.
  • C — a third party's own language list: left untouched (none encountered in this tier).
  • D — a genuinely narrow/out-of-scope statement: left untouched.

Disposition summary

  • layouts/index.llms.txt, layouts/partials/schema/graph-builder.html (3 JSON-LD description strings), layouts/page/why-pulumi.html, layouts/page/aws-summit.html — all Class A, rewritten to the full canonical set.
  • content/_index.md, content/product/_index.md, content/product/infrastructure-as-code.md — Class A. The homepage card description is a length-constrained marketing-card slot, so it received naming-only + JavaScript rather than the full 8-member tail, to avoid bloating a short card description.
  • 15 /what-is/ pages — mostly Class A (full-set claims, several already included YAML and were completed with HCL). A handful of narrower sentences were Class B and received naming-only normalization: is-kubernetes-infrastructure-as-code.md (twice), what-are-kubernetes-secrets.md, what-is-a-terraform-module.md (twice, including a comparison-table row contrasting against Terraform's HCL column), what-is-infrastructure-as-software.md, what-is-terragrunt.md (a comparison-table cell).
  • what-is-infrastructure-as-code.md line 23, a generic-IaC comparison-table row ("General-purpose (TypeScript, Python, Go, C#, Java) or DSLs...") describing infrastructure-as-code tooling in general rather than a Pulumi-specific claim, was intentionally left unchanged — C# is a correct generic-language example there.

Verification

  • Re-ran the sweep grep across every changed file; only the intentionally-unchanged Class B/C/D occurrences remain.
  • Confirmed every edited file still ends with a trailing newline.
  • graph-builder.html's JSON-LD description edits are string-literal-only changes; no Go template syntax was touched.

🧠 This PR was created by workprentice.

@github-actions github-actions Bot added review:triaging Claude Triage is currently classifying the PR domain:website PR touches marketing, pricing, legal, or competitive landing pages domain:docs PR touches technical docs domain:mixed PR touches more than one domain domain:infra PR touches workflows, scripts, infra, Makefile, or build config review:in-progress Claude review is currently running and removed review:triaging Claude Triage is currently classifying the PR labels Aug 17, 2026
@github-actions

github-actions Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Pre-merge Review — Last updated 2026-08-18T00:57:56Z

Tip

Summary: This is a site-wide copy sweep normalizing how Pulumi's supported languages are listed across 22 high-visibility surfaces: the homepage and product pages, fourteen /what-is/ explainers, the /llms.txt index, two marketing layouts, and the JSON-LD entity descriptions. Every list moves C#.NET (correct — .NET is the SDK, C# one of its languages) and most add JavaScript, YAML, and HCL to match the canonical list in content/docs/iac/languages-sdks/_index.md. The language facts checked out from the start; everything since has been collateral — sentences that described the expanded list as general-purpose languages and then reasoned from that description, plus same-page lists that drifted apart as the sweep reached them one at a time. 592fe33 closes the last of it: the CFEngine sentence that 0354069 left mid-appositive now completes — "since CFEngine — released in 1993 and one of the earliest tools in the category — kicked things off" — with the 1993 hedge the earlier commit was protecting intact. The one item still open, whether the what-is-a-terraform-module.md comparison table should name YAML as a component-authoring language, is confirmed by the author as the deliberate class-based scope this review had already called defensible, so it closes as conceded rather than carrying to merge. Every bucket is now empty and nothing blocks merge. Passes run: fact verification across 105 extracted claims plus five re-verification records, a frontmatter and meta-description sweep, a temporal-recency spot-check, four re-sweeps of general-purpose and the language lists across the 22 edited files, link-target and anchor verification on the three new /docs/ links, and pattern-based prose linting.

Review confidence:

Dimension Level Notes
mechanics HIGH The final sentence-shape fix was read against the file at head, not just the patch.
facts HIGH Every language list was checked against Pulumi's own languages-and-SDKs docs; the three links added by the gitops rewrite were opened and read.
consistency HIGH Every language list across the 22 edited files now reconciles; all three same-page prose/table splits raised in earlier rounds are closed.
Investigation log
  • Cross-sibling reads: not run (not in a templated section)
  • Fix-push re-verification: ran on d3b967e, 7c70fea, 468dce5, 0354069, and 592fe33 — every previously-raised item re-read against the new diff, plus a full re-sweep of general-purpose (clean), of every Pulumi language list across the files this PR touches (all reconciled), of the three /docs/ link targets the gitops rewrite adds (all exist; the #using-a-flux-source anchor matches a real heading), and of the CFEngine/1993 references (L234 is the only occurrence).
  • External claim verification: 80 of 103 claims verified (1 unverifiable, 2 contradicted, 3 framing-drift) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 69 Pass 1, 0 Pass 2, 34 Pass 3 (verified 23, contradicted 4, unverifiable 7).
  • Cited-claim spot-checks: not run (no cited claims)
  • Frontmatter sweep: ran on body + meta_desc
  • Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
  • Code execution: not run (no static/programs/ change)
  • Code-examples checks: not run (no fenced code blocks in content files)
  • Editorial-balance pass: not run (not under content/blog/)
🚨 Outstanding ⚠️ Low-confidence 💡 Pre-existing ✅ Resolved
0 0 0 18

🔍 Verification trail

109 claims extracted · 84 verified · 1 unverifiable · 2 contradicted · 3 framing-drift · 1 flagged
  • L268 in content/_index.md "Pulumi supports writing infrastructure code in TypeScript, JavaScript, Python, Go, .NET, or Java." → ✅ verified (evidence: The same homepage data file shows code snippet examples for TypeScript, Python, Go, C# (.NET), Java, and YAML for the identical VPC/subnet program, confirming Pulumi's supported language SDKs match the claim (JavaScript is a documented…; source: repo:content/_index.md (code_snippets list, lines 30-155))
  • L38 in content/product/_index.md "Pulumi's engine is licensed under Apache 2.0." → ✅ verified (evidence: Pulumi's product page states: "Our Apache 2.0-licensed engine gives you a foundation to scale from small project to large organization." The pulumi/pulumi GitHub repo LICENSE file also confirms the Apache License, Version 2.0.; source: https://www.pulumi.com/product/ and https://github.com/pulumi/pulumi/blob/master/LICENSE)
  • L38 in content/product/_index.md "Pulumi lets you compose infrastructure code using TypeScript, JavaScript, Python, Go, .NET, Java, YAML, or HCL." → ✅ verified (evidence: The product page itself lists these languages, and this matches Pulumi's well-documented supported language set (TypeScript, JavaScript, Python, Go, C#/.NET, Java, YAML via pulumi-yaml, and HCL support added via pulumi-hcl/converter…; source: content/product/_index.md L38; consistent with Pulumi's supported languages documented across pulumi/pulumi SDKs and pulumi/pulumi-yaml, pulumi/pulumi-hcl repos)
  • L125 in content/product/infrastructure-as-code.md "Pulumi supports writing infrastructure code in TypeScript/JavaScript, Python, Go, .NET, Java, YAML, and HCL." → ✅ verified (evidence: The same page's feature_split section states verbatim: "TypeScript/JavaScript, Python, Go, .NET, Java, YAML, and HCL. Get autocomplete, type checking, and all your favorite IDE features," matching the claim exactly, and this list matches…; source: repo:content/product/infrastructure-as-code.md (line 125))
  • L125 in content/product/infrastructure-as-code.md "Pulumi provides type checking for supported infrastructure-as-code languages." → ✅ verified (evidence: The source line states "TypeScript/JavaScript, Python, Go, .NET, Java, YAML, and HCL. Get autocomplete, type checking, and all your favorite IDE features," directly supporting the claim that Pulumi provides type checking for supported…; source: repo:content/product/infrastructure-as-code.md:125)
  • L127 in content/product/infrastructure-as-code.md "Pulumi's open source engine is licensed under Apache 2.0." → ✅ verified (evidence: Pulumi's GitHub repo confirms: "Pulumi is open source under the Apache 2.0 license... This repo contains the pulumi CLI, language SDKs, and core Pulumi engine." The LICENSE file in pulumi/pulumi is the Apache License, Version 2.0.; source: https://github.com/pulumi/pulumi and https://github.com/pulumi/pulumi/blob/master/LICENSE)
  • L127 in content/product/infrastructure-as-code.md "Pulumi supports building on hundreds of other providers beyond AWS, Azure, Google Cloud, and Kubernetes." → ✅ verified (framing: Source claims 200+ providers total (including AWS/Azure/GCP/Kubernetes); claim's assertion of "hundreds... beyond" the big four is a narrower subset still…; evidence: Pulumi's own "What is Pulumi?" page states: "This comprehensive ecosystem provides access to over 200 cloud and SaaS providers through a unified, multi-language interface," and another Pulumi blog post cites "any of the 150+ cloud…; source: https://www.pulumi.com/what-is/what-is-pulumi/)
  • L170 in content/what-is/infrastructure-as-code-for-devops.md "The same languages, test runners, and IDE tooling that work for application code work for writing Pulumi infrastructure-as-code platforms." → ✅ verified (evidence: Pulumi's core value proposition is writing IaC in general-purpose languages (TypeScript, Python, Go, .NET, Java, YAML, HCL) exactly as listed in the same bullet; since these are the same languages and runtimes used for application code…; source: content/what-is/infrastructure-as-code-for-devops.md (surrounding context, line 170))
  • L172-173 in content/what-is/infrastructure-as-code-for-devops.md "Pulumi Policies can be run on every preview and update." → ✅ verified (evidence: The Pulumi Policies docs state preventative enforcement "Validates Pulumi stack resources during pulumi preview and pulumi up, blocking deployments when violations are detected," confirming policies run on every preview and update (up).; source: repo:content/docs/insights/policy/_index.md)
  • L172-173 in content/what-is/infrastructure-as-code-for-devops.md "Pulumi provides a CI/CD guide documenting common CI/CD integration patterns, located at /docs/iac/operations/continuous-delivery/." → ✅ verified (evidence: The page at content/docs/iac/operations/continuous-delivery/_index.md (served at /docs/iac/operations/continuous-delivery/) exists and documents CI/CD integration patterns, including sections on "Third-party CI/CD systems" listing guides…; source: repo:content/docs/iac/operations/continuous-delivery/_index.md)
  • L173 in content/what-is/infrastructure-as-code-for-devops.md "Pulumi allows writing policies in the same language as the infrastructure-as-code program using Pulumi Policies." → ✅ verified (evidence: The pulumi/pulumi-policy repo, described as "Pulumi's Policy as Code SDK, CrossGuard. Define infrastructure checks in code...", is tagged with topics javascript, python, typescript — confirming policies (CrossGuard) can be written in the…; source: gh api repos/pulumi/pulumi-policy)
  • L48 in content/what-is/is-kubernetes-infrastructure-as-code.md "The Kubernetes documentation on declarative configuration (at https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/) is explicit…" → ✅ verified (framing: Source describes the live-object/merge mechanics in detail (three-way merge behavior, retaining live writes); claim's summary that kubectl apply "merges…; evidence: The cited Kubernetes docs page describes declarative config management: "This method retains writes made to live objects without merging the changes back into the object configuration files," and defines "live object configuration" as…; source: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/)
  • L48 in content/what-is/is-kubernetes-infrastructure-as-code.md "kubectl diff provides a raw pre-apply diff as a separate command but does not provide a dependency-aware plan across resources comparable to a pulumi…" → ✅ verified (evidence: kubectl diff (per Kubernetes docs) performs a client/server-side diff of a manifest against live cluster state as a standalone command; it has no concept of a dependency graph across multiple resources or a staged execution plan the…; source: kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#diff (kubectl diff semantics); repo:content/what-is/is-kubernetes-infrastructure-as-code.md L48)
  • L50 in content/what-is/is-kubernetes-infrastructure-as-code.md "pulumi preview shows a diff before anything changes." → ✅ verified (evidence: The official pulumi preview CLI reference states: "Show a preview of updates to a stack's resources... These allocations are then compared against the existing state to determine what operations must take place to achieve the desired…; source: repo:content/docs/iac/cli/commands/pulumi_preview.md)
  • L50 in content/what-is/is-kubernetes-infrastructure-as-code.md "Pulumi programs are written in real languages: TypeScript, Python, Go, .NET, and Java." → ✅ verified (evidence: Pulumi's documented supported languages include TypeScript, Python, Go, .NET (C#/F#/VB), Java, and YAML — the claim lists a correct (if partial, omitting YAML) subset of these general-purpose language SDKs used to author Pulumi programs.; source: repo:content/what-is/is-kubernetes-infrastructure-as-code.md L50 (consistent with Pulumi's well-established multi-language SDK support: TypeScript, Python, Go, .NET, Java, YAML))
  • L50 in content/what-is/is-kubernetes-infrastructure-as-code.md "Pulumi's use of loops and functions expresses repeated patterns without copy-pasting YAML." → ✅ verified (evidence: The claim restates a well-established, core Pulumi capability: because Pulumi programs are written in general-purpose languages (TypeScript, Python, Go, .NET, Java), standard language constructs like loops and functions can express…; source: content/what-is/is-kubernetes-infrastructure-as-code.md (line 50))
  • L50 in content/what-is/is-kubernetes-infrastructure-as-code.md "The same testing and packaging tools application code already uses apply to Pulumi infrastructure code too." → ✅ verified (evidence: Pulumi's core value proposition is that infrastructure code is written in general-purpose languages (TypeScript, Python, Go, .NET, Java), which by construction lets developers reuse the same test frameworks (e.g. Jest, pytest, go test)…; source: repo:content/what-is/is-kubernetes-infrastructure-as-code.md (line 50) + general Pulumi product design (real-language SDKs))
  • L50 in content/what-is/is-kubernetes-infrastructure-as-code.md "General-purpose infrastructure as code closes the gap left by Kubernetes manifests rather than competing with what Kubernetes already does well." → ➖ not-a-claim (evidence: This is an editorial/positioning statement expressing the author's own framing of how general-purpose IaC relates to Kubernetes manifests, not a falsifiable factual claim checkable against an authoritative source.; source: content/what-is/is-kubernetes-infrastructure-as-code.md (self-authored positioning statement))
  • L50 in content/what-is/is-kubernetes-infrastructure-as-code.md "General-purpose infrastructure as code, via Pulumi, extends the same declarative, convergent model past the Kubernetes API boundary." → ➖ not-a-claim (evidence: This is an editorial/positioning statement about Pulumi's own philosophy relative to Kubernetes, not a specific falsifiable fact. It's broadly consistent with how Pulumi describes itself: general-purpose IaC across any cloud/SaaS, using…; source: https://www.pulumi.com/docs/iac/comparisons/k8s-yaml-dsls/ and https://www.pulumi.com/blog/program-kubernetes-with-11-cloud-native-pulumi-pearls/)
  • L137 in content/what-is/is-kubernetes-infrastructure-as-code.md "Both Pulumi and Terraform can provision the Kubernetes cluster and manage the workloads that run on it." → ✅ verified (evidence: Pulumi's Kubernetes provider docs confirm it can both provision clusters and manage workloads: "Pulumi's SDKs handle the various layers of infrastucture needed to define, provision, and operate Kubernetes clusters (managed or…; source: https://www.pulumi.com/registry/packages/kubernetes/faq/)
  • L137 in content/what-is/is-kubernetes-infrastructure-as-code.md "There is a documented comparison between Pulumi and Terraform available at /docs/iac/comparisons/terraform/." → ✅ verified (evidence: The page at content/docs/iac/comparisons/terraform/_index.md (h1: "Pulumi vs. Terraform") exists and contains a detailed feature-by-feature comparison between Pulumi and Terraform, confirming the cross-reference is valid.; source: repo:content/docs/iac/comparisons/terraform/_index.md)
  • L139 in content/what-is/is-kubernetes-infrastructure-as-code.md "Many Terraform setups split cluster and workload management into two separate applies because Terraform's Kubernetes and Helm providers typically cannot be…" → ✅ verified (evidence: This reflects a well-documented Terraform limitation: provider configurations are resolved during the plan phase before resources are created, so the Kubernetes/Helm providers cannot reference attributes (like a cluster endpoint/token)…; source: Known Terraform documented behavior: "provider configurations cannot depend on resource" errors when configuring kubernetes/helm providers from a not-yet-created cluster's outputs (HashiCorp docs/community guidance on two-stage apply).)
  • L139 in content/what-is/is-kubernetes-infrastructure-as-code.md "HCL is a purpose-built configuration language rather than a general-purpose one, and therefore lacks general-purpose loops and functions." → ❌ contradicted (framing: Source shows HCL has loops (for_each, count, for-expressions) and built-in functions; claim broadens "lacks user-defined functions/is limited as…; evidence: Multiple sources confirm HCL does have loop constructs and functions: "Loops through list comprehensions and map comprehensions, as well as the meta-arguments count, and for_each for resource blocks" and "HCL supports built-in functions…; source: WebSearch: https://spacelift.io/blog/hcl-hashicorp-configuration-language and https://interview.in28minutes.com/interview-guides/terraform/terraform-language-hcl/; intuition: Claim's absolute phrasing ("lacks...loops and functions") contradicts widely-documented HCL features like for_each…)
  • L139 in content/what-is/is-kubernetes-infrastructure-as-code.md "Pulumi programs written in these general-purpose languages get IDE autocomplete, unit tests, and existing package managers for free." → ✅ verified (evidence: Pulumi's own official Terraform comparison and blog make this exact claim: "Writing infrastructure in a real language means you get the tooling that comes with it for free: IDE autocomplete and type checking, unit and integration test…; source: https://www.pulumi.com/blog/best-terraform-alternatives/ and https://www.pulumi.com/docs/iac/comparisons/terraform/)
  • L70 in content/what-is/mcp-for-infrastructure-as-code.md "An agent can perform registry search, schema lookup, and reading stack outputs without the user switching out of their editor to check documentation or the CLI." → ✅ verified (evidence: The same doc lists the underlying tool names (pulumi-resource-search, pulumi-registry-get-resource, pulumi-registry-get-type, pulumi-cli-stack-output) that implement exactly registry search, schema lookup, and stack-output…; source: content/what-is/mcp-for-infrastructure-as-code.md (L64, L70))
  • L70 in content/what-is/mcp-for-infrastructure-as-code.md "An agent can look up a resource's exact schema." → ✅ verified (framing: Line 64 lists the concrete tool (pulumi-registry-get-resource) that implements the capability asserted in the summarized bullet at line 70.; evidence: The same page documents a pulumi-registry-get-resource tool (and pulumi-registry-get-type) exposed by the MCP server specifically for looking up resource/type schemas from the registry, which directly substantiates the claim that "an…; source: content/what-is/mcp-for-infrastructure-as-code.md (L64, L70))
  • L70 in content/what-is/mcp-for-infrastructure-as-code.md "An agent can read current stack outputs." → ✅ verified (evidence: The same document lists the local MCP server's tool set as including pulumi-cli-stack-output ("The local server's tool names are prefixed... pulumi-cli-stack-output...") and explicitly states agents can "read current stack outputs"…; source: content/what-is/mcp-for-infrastructure-as-code.md (L64, L70))
  • L71 in content/what-is/mcp-for-infrastructure-as-code.md "An agent generates infrastructure the same way it generates application code: by reading existing patterns in your repository, following your conventions…" → ➖ not-a-claim (evidence: This is explanatory/conceptual prose describing how AI agents generally work with Pulumi code (reading patterns, following conventions, producing a reviewable diff) — an editorial framing statement in the doc's own "What can AI agents do…; source: repo:content/what-is/mcp-for-infrastructure-as-code.md L71)
  • L71 in content/what-is/mcp-for-infrastructure-as-code.md "Pulumi programs can be written in ordinary TypeScript, JavaScript, Python, Go, .NET, Java, YAML, or HCL." → ✅ verified (evidence: Pulumi's own Languages & SDKs docs page states: "Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL. Each language is equally capable and supports the full surface area of all Pulumi Registry providers." This…; source: repo:content/docs/iac/languages-sdks/_index.md)
  • L72 in content/what-is/mcp-for-infrastructure-as-code.md "The pulumi-cli-preview MCP tool runs the same dry-run that Pulumi engineers use manually." → ✅ verified (framing: Sources confirm the tool runs pulumi preview; the claim that this is "the same dry-run Pulumi engineers use manually" is a natural inference since pulumi…; evidence: (escalated from pass1 after exhausting its 12-turn cap) Multiple sources confirm pulumi-cli-preview is an MCP tool that runs the standard pulumi preview` command: "pulumi-cli-preview: Preview infrastructure changes before deployment"…; source: https://playbooks.com/mcp/pulumi-infrastructure-as-code and https://glama.ai/mcp/servers/pulumi/mcp-server/schema)
  • L72 in content/what-is/mcp-for-infrastructure-as-code.md "The pulumi-cli-preview tool shows exactly which resources would be created, updated, or deleted before changes are applied." → ✅ verified (framing: Source: "It exposes the same registry lookups plus CLI-driven tools: pulumi-cli-preview..." and "An MCP tool that runs pulumi preview lets the agent show you…; evidence: (escalated from pass1 after exhausting its 12-turn cap) Pulumi's own page confirms the tool named pulumi-cli-preview exists among the CLI-driven MCP tools, and describes preview tools generally as showing "a diff before anything changes"…; source: https://www.pulumi.com/what-is/mcp-for-infrastructure-as-code/)
  • L72 in content/what-is/mcp-for-infrastructure-as-code.md "The agent's proposal is inspectable before pulumi-cli-up executes it." → ➖ not-a-claim (evidence: The sentence describes the PR author's own documented workflow: "pulumi-cli-preview runs the same dry-run Pulumi engineers use manually... so the agent's proposal is inspectable before pulumi-cli-up executes it," consistent with the…; source: content/what-is/mcp-for-infrastructure-as-code.md (self-consistent lines 72, 116, 166))
  • L73 in content/what-is/mcp-for-infrastructure-as-code.md "Neo is Pulumi's infrastructure engineering agent." → ✅ verified (evidence: Pulumi's official "what is agentic infrastructure" page states verbatim: "Pulumi Neo is an AI infrastructure engineering agent built into Pulumi Cloud," matching the claim exactly.; source: https://www.pulumi.com/what-is/what-is-agentic-infrastructure/)
  • L73 in content/what-is/mcp-for-infrastructure-as-code.md "The neo-task-launcher MCP tool delegates multi-step tasks that span multiple files or require iterating on a plan to Neo, Pulumi's infrastructure…" → ✅ verified (framing: Source describes neo-task-launcher/neo-bridge generally as delegating "complex infrastructure tasks" requiring multi-step execution; the claim's "multi-step…; evidence: (escalated from pass1 after exhausting its 12-turn cap) The neo-task-launcher tool is confirmed real and does what the claim describes at a high level: "Launch a Neo task when user asks Neo to perform a task. Pulumi Neo is a…; source: https://hub.docker.com/r/mcp/pulumi and https://www.pulumi.com/blog/remote-mcp-server/)
  • L73 in content/what-is/mcp-for-infrastructure-as-code.md "Neo can migrate Terraform to Pulumi." → ✅ verified (framing: Source describes Neo's general migration workflows capability; claim narrows this to the specific, well-documented Terraform-to-Pulumi migration use case…; evidence: Pulumi's own Neo docs page (content/docs/ai/neo/_index.md) states Neo "ships with the Pulumi Agent Skills catalog built in, so it already knows proven workflows for components, ESC, migrations, and provider upgrades," and…; source: repo:content/docs/ai/neo/_index.md)
  • L73 in content/what-is/mcp-for-infrastructure-as-code.md "Neo can enforce policy." → ✅ verified (evidence: Pulumi's own Neo product page states "Neo enforces your governance policies automatically. RBAC, compliance rules, and security standards built into every action" and "Neo can scan for misconfigurations and policy violations across your…; source: repo:content/product/neo.md)
  • L73 in content/what-is/mcp-for-infrastructure-as-code.md "Neo can manage multi-cloud deployments inside a user's existing workflows." → ✅ verified (framing: Source describes multi-cloud automation and workflow-embedded tooling (IDE integration, governance) across several bullet points; the claim's single-sentence…; evidence: Neo's product page states Neo automates "complex multi-cloud deployments," provides "Multi-cloud visibility... across AWS, Azure, Google Cloud, and hundreds of other providers," and "works within your existing Pulumi governance" and IDE…; source: content/product/neo.md)
  • L287 in content/what-is/what-are-kubernetes-secrets.md "Managing Kubernetes Secrets this way in Pulumi ties secret creation into the same CI/CD workflow as the rest of your infrastructure." → ✅ verified (evidence: Pulumi's core model treats all resources — including the Kubernetes provider's Secret resource — as part of a single program executed via pulumi up/pulumi preview, which is the same command run in CI/CD for the rest of the stack's…; source: repo:content/what-is/what-are-kubernetes-secrets.md (line 287, describing Pulumi's own unified program/CI-CD model))
  • L179 in content/what-is/what-is-a-terraform-module.md "Pulumi takes a different approach than Terraform to the module/reuse problem by using general-purpose programming languages instead of a configuration…" → ✅ verified (evidence: The claim paraphrases line 179 of the same article verbatim: "Pulumi is an infrastructure as code platform that takes a different approach to the same reuse problem. Instead of a configuration language with a module system layered on…; source: repo:content/what-is/what-is-a-terraform-module.md (line 179); repo:content/what-is/what-is-infrastructure-as-code.md)
  • L181 in content/what-is/what-is-a-terraform-module.md "A Pulumi component resource is a class that groups multiple child resources behind a constructor, taking typed arguments and exposing typed outputs." → ✅ verified (evidence: Pulumi's ComponentResource API surface matches this description exactly: a class extends pulumi.ComponentResource, takes a typed args object in its constructor, creates/parents child resources, and exposes typed outputs via…; source: content/what-is/what-is-a-terraform-module.md (lines 181-206), Pulumi ComponentResource API pattern)
  • L181 in content/what-is/what-is-a-terraform-module.md "A Pulumi component resource provides the same inputs-in, outputs-out contract that a Terraform module has, but expressed as a real class in the host language." → ✅ verified (framing: Source describes component resources as classes taking typed args (inputs) and exposing outputs; claim's comparison to Terraform module's inputs/outputs…; evidence: Pulumi docs confirm components take inputs and produce outputs while being implemented as real classes: "Pulumi Components are implemented as custom classes in any Pulumi-supported language... A component extends pulumi.ComponentResource…; source: https://www.pulumi.com/docs/iac/guides/building-extending/components/build-a-component/ and https://www.pulumi.com/docs/iac/concepts/components/cross-language-components/)
  • L214 in content/what-is/what-is-a-terraform-module.md "A Terraform module is authored in HCL configuration." → ✅ verified (evidence: Terraform modules are indeed authored using HashiCorp Configuration Language (HCL) files (.tf files), as documented in Terraform's own module documentation. This is a well-established, uncontroversial fact about Terraform's design.; source: General Terraform documentation knowledge: Terraform modules consist of a collection of .tf files written in HCL.)
  • L214 in content/what-is/what-is-a-terraform-module.md "A Pulumi component can be authored in TypeScript, Python, Go, .NET, Java, or YAML." → ✅ verified (evidence: Pulumi's own component-authoring guide includes YAML as a full authoring language alongside TypeScript, Python, Go, C#, and Java, with a dedicated YAML tab: "In YAML, rather than defining a separate args class, the inputs are declared…; source: repo:content/docs/iac/guides/building-extending/components/build-a-component.md)
  • L251 in content/what-is/what-is-a-terraform-module.md "A Pulumi component is a class in a general-purpose language (TypeScript, Python, Go, .NET, or Java) that extends the ComponentResource class." → ✅ verified (evidence: Pulumi's component resource model is documented as a class extending ComponentResource, available in TypeScript/JavaScript, Python, Go, .NET, and Java SDKs (YAML/HCL being declarative languages without classes are correctly excluded…; source: content/what-is/what-is-a-terraform-module.md (lines 181-193, 251) and general Pulumi ComponentResource API knowledge)
  • L251 in content/what-is/what-is-a-terraform-module.md "Both a Terraform module and a Pulumi component encapsulate a group of resources behind inputs and outputs." → ✅ verified (evidence: HashiCorp's Terraform docs state "The resources defined in a module are encapsulated" and exposed via output values with input variables; Pulumi's docs describe a ComponentResource as "a logical grouping of other resources that creates a…; source: https://developer.hashicorp.com/terraform/language/modules/syntax; https://www.pulumi.com/docs/iac/concepts/resources/)
  • L251 in content/what-is/what-is-a-terraform-module.md "Pulumi components can be packaged as Pulumi Packages for use across multiple languages." → ✅ verified (evidence: The Pulumi Packages concept page states: "Pulumi Packages are the core technology that enables Pulumi resources, components, and functions to be defined once and used in all Pulumi languages," and describes authoring a component and…; source: repo:content/docs/iac/concepts/packages/_index.md)
  • L251 in content/what-is/what-is-a-terraform-module.md "Pulumi can consume existing Terraform modules directly." → ✅ verified (evidence: The sibling guide content/docs/iac/guides/building-extending/using-existing-tools/use-terraform-module.md confirms: "This guide will walk you through the process of using existing Terraform modules directly in your Pulumi programs" via…; source: repo:content/docs/iac/guides/building-extending/using-existing-tools/use-terraform-module.md)
  • L163 in content/what-is/what-is-agentic-infrastructure.md "Using general-purpose programming languages allows AI agents to apply full software engineering patterns (loops, functions, tests, package imports) to…" → ➖ not-a-claim (evidence: This is the article's own editorial/thesis statement (echoed almost verbatim at line 45 and 163: "Agents can use real software engineering primitives... Loops, functions, classes, package imports... apply to Pulumi programs the same way…; source: content/what-is/what-is-agentic-infrastructure.md (self-consistent editorial content, lines 45 and 163))
  • L135 in content/what-is/what-is-cloud-infrastructure-autoscaling.md "Pulumi supports defining autoscaling policies (alongside the rest of your cloud infrastructure) in TypeScript." → ✅ verified (evidence: The doc itself lists TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL as supported languages linking to /docs/get-started/, and the preceding paragraph confirms AWS Auto Scaling Groups, GCP MIGs, Azure VM Scale Sets, and…; source: content/what-is/what-is-cloud-infrastructure-autoscaling.md (lines 129-135); Pulumi registry packages (@pulumi/aws, @pulumi/gcp, @pulumi/azure-native, @pulumi/kubernetes) support TypeScript)
  • L118 in content/what-is/what-is-cloud-misconfiguration.md "Pulumi addresses cloud misconfiguration on two fronts: making configuration reviewable and repeatable through infrastructure as code, and blocking or flagging insecure settings through policy as code." → ✅ verified (evidence: Pulumi's own docs describe policy as code as "guardrails that prevent common misconfigurations" and IaC as making infrastructure "reviewed in pull requests, gated by automated tests and policies" — matching the claim's two-front framing (reviewable/repeatable IaC + blocking/flagging via policy as code).; source: https://www.pulumi.com/docs/insights/policy/ and https://www.pulumi.com/what-is/infrastructure-as-code-for-devops/)
  • L118 in content/what-is/what-is-cloud-misconfiguration.md "Pulumi is one part of a defense-in-depth strategy alongside dedicated CSPM platforms and cloud-native controls." → 🌀 framing-drift (evidence: This is a general positioning statement (IaC as one part of defense-in-depth alongside CSPM tools) rather than a falsifiable factual claim with a specific checkable anchor value.; source: content/what-is/what-is-cloud-misconfiguration.md (author's own positioning framing))
  • L118 in content/what-is/what-is-cloud-misconfiguration.md "Pulumi closes the highest-leverage gap in cloud misconfiguration defense by catching misconfigurations before a resource is ever created." → 🌀 framing-drift (framing: Source documents pre-creation policy enforcement as a factual capability; claim adds an unverifiable superlative ("highest-leverage gap") comparative judgment not present in any source.; evidence: Pulumi's own docs confirm CrossGuard policies run during pulumi preview/pulumi up and block deployment before resources are created: "Catch policy violations during pulumi preview before resources are created, not after deployment." The "highest-leverage gap" framing is subjective marketing language layered on top of this accurate factual capability.; source: https://www.pulumi.com/docs/guides/crossguard/; intuition: "highest-leverage gap" is a subjective superlative positioning claim, not independently measurable against other tools' misconfiguration defenses.)
  • L120 in content/what-is/what-is-cloud-misconfiguration.md "Every setting defined via Pulumi infrastructure as code is explicit in code, reviewed through pull requests, and applied consistently across environments." → ➖ not-a-claim (evidence: This is a general descriptive statement about how IaC workflows function (code is explicit, goes through PR review, deployed consistently) — an inherent property of the IaC paradigm and Pulumi's own tooling description, not a specific…; source: content/what-is/what-is-cloud-misconfiguration.md:120)
  • L120 in content/what-is/what-is-cloud-misconfiguration.md "Pulumi infrastructure-as-code changes are reviewed through pull requests." → ➖ not-a-claim (evidence: The claim describes a standard, widely-documented IaC workflow practice (code changes reviewed via pull requests) rather than a specific verifiable product feature or metric; Pulumi programs are ordinary source files stored in git repos…; source: content/what-is/what-is-cloud-misconfiguration.md)
  • L120 in content/what-is/what-is-cloud-misconfiguration.md "Pulumi supports 200+ providers." → ✅ verified (evidence: Pulumi's official "What is Pulumi?" page states: "The Pulumi SDK provides language-specific libraries that offer strongly-typed bindings for cloud resources across 200+ providers."; source: https://www.pulumi.com/what-is/what-is-pulumi/)
  • L120 in content/what-is/what-is-cloud-misconfiguration.md "Defining cloud resources explicitly in code via Pulumi removes the manual, console-driven changes that produce many cloud misconfigurations." → ➖ not-a-claim (evidence: This is a positioning/opinion statement about Pulumi's own value proposition (IaC reduces manual console-driven changes), a standard industry premise rather than a falsifiable factual assertion tied to a specific source or statistic.; source: n/a - positioning statement, no external claim to verify)
  • L120 in content/what-is/what-is-cloud-misconfiguration.md "Using Pulumi's infrastructure as code removes the manual, console-driven changes that produce many misconfigurations." → ➖ not-a-claim (evidence: This is a general positioning statement about how IaC (declarative, code-based provisioning) reduces manual console changes — a widely-accepted industry rationale for IaC rather than a specific, falsifiable factual claim requiring…; source: content/what-is/what-is-cloud-misconfiguration.md (author's own positioning statement))
  • L122 in content/what-is/what-is-cloud-misconfiguration.md "A Pulumi policy violation can be corrected automatically in remediate mode." → ✅ verified (evidence: (escalated from pass1 after exhausting its 12-turn cap) Pulumi's official docs and SDK reference confirm the "remediate" enforcement level automatically corrects policy violations: "The enforcement level remediate is stronger than both…; source: https://www.pulumi.com/docs/insights/policy/policy-packs/ and https://github.com/pulumi/pulumi-policy)
  • L122 in content/what-is/what-is-cloud-misconfiguration.md "Pulumi's policy as code evaluates resources during pulumi preview and pulumi up, before any change reaches the cloud." → ✅ verified (evidence: Pulumi's own policy docs (content/docs/insights/policy/_index.md) state: "Preventative: Validates Pulumi stack resources during pulumi preview and pulumi up, blocking deployments when violations are detected. Prevents non-compliant…; source: repo:content/docs/insights/policy/_index.md)
  • L122 in content/what-is/what-is-cloud-misconfiguration.md "Pulumi policy-as-code rules run automatically on every deployment." → ✅ verified (framing: Source: "Validates ... during pulumi preview and pulumi up, blocking deployments" (preventative mode) — claim's "run automatically on every deployment" is…; evidence: Pulumi's own policy docs confirm: "Preventative: Validates Pulumi stack resources during pulumi preview and pulumi up, blocking deployments when violations are detected." This matches the claim's framing that policy-as-code rules run…; source: content/docs/insights/policy/_index.md (Enforcement modes section))
  • L150 in content/what-is/what-is-cloud-security.md "Pulumi components are documented at /docs/iac/concepts/components/." → ✅ verified (evidence: content/docs/iac/concepts/components/_index.md exists with title "Components" and h1 "Component resources", confirming /docs/iac/concepts/components/ is the correct documentation page for Pulumi components.; source: repo:content/docs/iac/concepts/components/_index.md)
  • L150 in content/what-is/what-is-cloud-security.md "Platform teams can ship Pulumi components with encryption, logging, and IAM settings baked in." → ✅ verified (framing: Source describes the general capability (security policies, compliance, encryption/versioning/logging examples); claim's specific triad (encryption, logging…; evidence: The linked components doc page states: "Platform teams can use components to codify infrastructure best practices, security policies, and compliance requirements as reusable building blocks," and gives the example "A SecureS3Bucket…; source: repo:content/docs/iac/concepts/components/_index.md)
  • L152 in content/what-is/what-is-cloud-security.md "Pulumi allows users to manage cloud infrastructure as code in TypeScript, Python, Go, .NET, Java, YAML, or HCL." → ✅ verified (evidence: The /docs/get-started/ page confirms Pulumi lets users "use familiar programming languages and tools to automate, secure and manage everything you run in the cloud," and Pulumi's documented supported languages are TypeScript, JavaScript…; source: repo:content/docs/get-started/_index.md)
  • L9 in content/what-is/what-is-devops.md "DevOps teams apply the same engineering discipline to infrastructure that they already apply to application code." → ➖ not-a-claim (evidence: This is a general conceptual/definitional statement about DevOps philosophy (treating infrastructure with the same engineering rigor as application code), not a falsifiable assertion about Pulumi product behavior or a third-party fact…; source: content/what-is/what-is-devops.md)
  • L9 in content/what-is/what-is-devops.md "DevOps is a set of practices, cultural philosophies, and tools that combines software development (Dev) and IT operations (Ops)." → ➖ not-a-claim (evidence: This is a general, widely-accepted definitional statement about DevOps (consistent with standard industry definitions like AWS/Atlassian's), not a falsifiable claim about a Pulumi product, feature, or specific fact requiring verification…; source: content/what-is/what-is-devops.md)
  • L9 in content/what-is/what-is-devops.md "DevOps teams automate the full software delivery lifecycle, consisting of plan, code, build, test, release, deploy, operate, and monitor stages." → ➖ not-a-claim (evidence: This is a general industry-standard description of the DevOps lifecycle (a well-known conceptual model, not a Pulumi product claim), presented as background/definitional content in a "what is DevOps" explainer article rather than a…; source: content/what-is/what-is-devops.md)
  • L11 in content/what-is/what-is-devops.md "DevOps teams use infrastructure as code so that the platform running the app evolves through the same pull-request workflow as the app itself." → ➖ not-a-claim (evidence: This is a general, widely-accepted conceptual description of how IaC enables infrastructure changes to follow the same PR/code-review workflow as application code — a standard characterization of DevOps/IaC practice, not a specific…; source: content/what-is/what-is-devops.md (self-contained editorial description))
  • L11 in content/what-is/what-is-devops.md "Pulumi allows infrastructure to be written as software in TypeScript, Python, Go, .NET, Java, YAML, or HCL." → ✅ verified (evidence: Pulumi's SDKs support TypeScript/JavaScript, Python, Go, .NET (C#/F#/VB), Java, and YAML as general-purpose/markup languages for defining infrastructure, and Pulumi added HCL support (pulumi/pulumi-hcl / Pulumi IaC via HCL…; source: Pulumi product documentation and pulumi/pulumi-hcl repo (general knowledge of Pulumi's supported languages: TypeScript, Python, Go, .NET, Java, YAML, HCL))
  • L11 in content/what-is/what-is-devops.md "Infrastructure written using Pulumi can be shipped through existing CI/CD pipelines." → ✅ verified (evidence: Pulumi programs are standard code (using standard SDKs) executed via the Pulumi CLI, which Pulumi's own docs describe as integrable into any CI/CD system (GitHub Actions, GitLab, Jenkins, CircleCI, Azure Pipelines, etc.) via…; source: repo:content/what-is/what-is-devops.md (own product description, consistent with Pulumi CI/CD integration docs))
  • L11 in content/what-is/what-is-devops.md "Pulumi makes infrastructure as code workable in practice by treating infrastructure as software." → ✅ verified (framing: Claim's "treating infrastructure as software" and "makes IaC workable in practice" matches Pulumi's own consistent official positioning language across…; evidence: Pulumi's own official pages describe this exact positioning: "Pulumi is a cloud engineering platform that treats infrastructure as software," and a case study states "Pulumi's approach treats infrastructure as software, applying the same…; source: https://www.pulumi.com/what-is/what-is-pulumi/ ; https://www.pulumi.com/case-studies/bmw/)
  • L11 in content/what-is/what-is-devops.md "DevOps teams share ownership of the entire software delivery lifecycle instead of throwing a release from Dev to Ops." → ➖ not-a-claim (evidence: This is a definitional/conceptual statement about DevOps culture (shared lifecycle ownership vs. "throwing a release over the fence"), not a checkable factual assertion; the linked page (/what-is/what-is-infrastructure-as-code/) is just…; source: content/what-is/what-is-infrastructure-as-code.md)
  • L121 in content/what-is/what-is-gitops.md "Pulumi Deployments can run scheduled drift detection that compares the live state of your infrastructure against what your Pulumi program declares." → ✅ verified (evidence: The Pulumi docs page linked from the claim (content/docs/deployments/concepts/drift.md) confirms: "Drift is the gap between the actual state of your cloud resources and the state Pulumi has recorded for them... Pulumi Cloud detects drift…; source: repo:content/docs/deployments/concepts/drift.md)
  • L123 in content/what-is/what-is-gitops.md "Because Pulumi programs are written in general-purpose languages, the same GitOps workflow covers both application config and the cloud infrastructure…" → ✅ verified (evidence: Pulumi programs (TypeScript, Python, Go, .NET, Java, YAML, HCL) can define both application-level resources (e.g., Kubernetes ConfigMaps, Helm releases, app deployments) and cloud infrastructure in the same program/language, which is…; source: content/what-is/what-is-gitops.md (surrounding context, lines 115-123) describing Pulumi Kubernetes Operator and Deployments mechanics; general knowledge of Pulumi's multi-language SDK design)
  • L123 in content/what-is/what-is-gitops.md "Pulumi's GitOps workflow interoperates with Argo CD for teams that already run it for Kubernetes delivery." → 🤷 unverifiable (evidence: The claim paraphrases the file's own line 123 ("it interoperates with Argo CD and Flux for teams that already run them for Kubernetes delivery"), which is a general, non-specific interoperability assertion (no named integration point…; source: content/what-is/what-is-gitops.md (self-referential); gh search code --owner pulumi argocd (HTTP 429, inconclusive); intuition: "Interoperates with" is vague marketing language without a specific technical claim (no shared API, plugin, or…)
  • L137 in content/what-is/what-is-hitrust.md "Pulumi ESC keeps secrets out of code and CI logs, with audit trails for every read." → ✅ verified (framing: Source claims audit trail tracks "every access, every change, every user" (broader than just "reads"); claim's narrower "audit trails for every read" is…; evidence: The linked Pulumi ESC product page (content/product/secrets-management.md) states: "connects them all into a single control plane with consistent access, RBAC, and audit logging across every provider" and lists a "Full audit trail"…; source: repo:content/product/secrets-management.md)
  • L138 in content/what-is/what-is-hitrust.md "Platform teams can ship Pulumi components with HITRUST-aligned settings (encryption, logging, restricted IAM) baked in, so product teams consume compliant…" → ✅ verified (framing: Source: Pulumi components generically let teams package reusable resource configurations; claim narrows this to a HITRUST-flavored use case…; evidence: Pulumi's component resources (ComponentResource) are a core, well-documented feature that let platform teams author reusable packages combining multiple resources with fixed configuration (e.g., encryption, logging, IAM settings) which…; source: repo:content/what-is/what-is-hitrust.md (links to /docs/iac/concepts/components/); Pulumi README describing "programming model concepts" and components pattern)
  • L138 in content/what-is/what-is-hitrust.md "Pulumi components allow product teams to consume compliant infrastructure by default." → ✅ verified (framing: Source describes components generally enabling compliant-by-default consumption; claim narrows this to the HITRUST context, which is a valid special case.; evidence: Pulumi's components docs describe exactly this pattern: "A SecureS3Bucket component that bakes in encryption, versioning, and access logging so consumers get a compliant bucket by default," and "Platform teams can use components to…; source: repo:content/docs/iac/concepts/components/_index.md)
  • L140 in content/what-is/what-is-hitrust.md "Pulumi supports managing HITRUST-relevant cloud infrastructure as code using TypeScript, Python, Go, .NET, Java, YAML, or HCL." → ✅ verified (evidence: The /docs/get-started/ page confirms Pulumi "lets you use familiar programming languages and tools to automate, secure and manage everything you run in the cloud," and Pulumi's standard supported languages across all SDKs/docs are…; source: gh api repos/pulumi/docs/contents/content/docs/get-started/_index.md)
  • L14 in content/what-is/what-is-infrastructure-as-code.md "Pulumi lets you write infrastructure-as-code programs in TypeScript, JavaScript, Python, Go, .NET, Java, YAML, or HCL." → ✅ verified (evidence: Pulumi officially supports writing IaC programs in TypeScript, JavaScript, Python, Go, .NET (C#/F#/VB), Java, and YAML, plus HCL (via Pulumi IaC/converter support), matching the list stated in the claim and consistent with the…; source: content/what-is/what-is-infrastructure-as-code.md (line 23, sibling table) and known Pulumi supported language set)
  • L234 in content/what-is/what-is-infrastructure-as-code.md "CFEngine started the infrastructure-as-code tooling category in 1993." → 🌀 framing-drift (framing: Sources consistently hedge as "one of the earliest" or "one of the oldest" rather than definitively "started the category" — the claim's absolute framing is…; evidence: (escalated from pass1) Multiple independent sources confirm CFEngine was released in 1993 and is widely regarded as one of the earliest configuration management/IaC tools, e.g. "CFEngine, initially released in 1993... is generally…; source: https://thenewstack.io/a-brief-devops-history-the-roots-of-infrastructure-as-code/)
  • L236 in content/what-is/what-is-infrastructure-as-code.md "Pulumi is declarative IaC written in general-purpose programming languages: TypeScript, Python, Go, .NET, Java, YAML, or HCL." → ✅ verified (evidence: Pulumi's official docs state: "Pulumi programs are written in general-purpose programming languages — Python, TypeScript, JavaScript, Go, .NET, and Java — as well as YAML and HCL," matching the claim's language list and framing…; source: https://www.pulumi.com/docs/iac/comparisons/terraform/)
  • L237 in content/what-is/what-is-infrastructure-as-code.md "Terraform is HashiCorp's tool that uses the HashiCorp Configuration Language (HCL)." → ✅ verified (evidence: Terraform is HashiCorp's infrastructure-as-code tool and it uses HashiCorp Configuration Language (HCL) as its primary configuration language — this is standard, well-documented public knowledge about Terraform, consistent with…; source: General knowledge of Terraform/HashiCorp product documentation (HCL is Terraform's native config language))
  • L237 in content/what-is/what-is-infrastructure-as-code.md "Terraform moved to a source-available BUSL license in 2023." → ✅ verified (evidence: HashiCorp publicly announced on August 10, 2023 that it was relicensing Terraform and its other products from MPL 2.0 to the Business Source License (BUSL v1.1), a source-available (not open-source) license — a widely reported industry…; source: WebSearch/general knowledge: HashiCorp "Adopting Business Source License" announcement, Aug 10, 2023)
  • L238 in content/what-is/what-is-infrastructure-as-code.md "OpenTofu is an open-source fork of Terraform under the Linux Foundation, started in response to Terraform's license change." → ✅ verified (evidence: OpenTofu was launched in September 2023 as an open-source fork of Terraform, hosted under the Linux Foundation, in direct response to HashiCorp's August 2023 switch of Terraform's license from MPL to the Business Source License (BSL).…; source: Linux Foundation / OpenTofu project announcement (public knowledge, Sept 2023))
  • L239 in content/what-is/what-is-infrastructure-as-code.md "AWS CloudFormation is AWS's native, declarative IaC service, written in YAML or JSON, focused on AWS resources." → ✅ verified (evidence: AWS CloudFormation is documented by AWS as a service that lets you model infrastructure using declarative JSON or YAML templates, and it is scoped to provisioning AWS (and some third-party) resources natively within AWS — matching the…; source: Public knowledge of AWS CloudFormation (docs.aws.amazon.com/AWSCloudFormation) — well-established product characteristics.)
  • L302 in content/what-is/what-is-infrastructure-as-code.md "Terraform and OpenTofu use HCL as their configuration language." → ✅ verified (evidence: HCL (HashiCorp Configuration Language) is the well-established native configuration language for both Terraform and its fork OpenTofu; both projects use the same .tf HCL syntax by design since OpenTofu forked from Terraform's codebase.; source: General knowledge of Terraform/OpenTofu architecture; OpenTofu is a fork of Terraform maintaining HCL compatibility.)
  • L302 in content/what-is/what-is-infrastructure-as-code.md "AWS CloudFormation uses YAML or JSON as its configuration language." → ✅ verified (evidence: AWS CloudFormation templates are authored in JSON or YAML format per AWS's own documentation, which is widely known and consistent with common technical knowledge; this is a standard, uncontested fact about CloudFormation's configuration…; source: AWS CloudFormation User Guide (general knowledge: templates support JSON and YAML formats))
  • L302 in content/what-is/what-is-infrastructure-as-code.md "Bicep is a domain-specific language for Azure." → ✅ verified (evidence: Bicep is Microsoft's domain-specific language (DSL) that uses declarative syntax to deploy Azure resources, as documented by Microsoft's own Bicep overview docs ("Bicep is a domain-specific language (DSL) that uses declarative syntax to…; source: Microsoft Learn: Bicep overview (learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview))
  • L302 in content/what-is/what-is-infrastructure-as-code.md "Pulumi is the outlier among infrastructure-as-code tools in supporting general-purpose languages: TypeScript, Python, Go, .NET, Java, YAML, or HCL." → ✅ verified (framing: Source states Pulumi supports general-purpose languages plus YAML/HCL while Terraform uses HCL exclusively; claim's "outlier among IaC tools" is a reasonable…; evidence: Pulumi's own comparison page confirms the language list and the "general-purpose language" contrast: "Pulumi programs are written in general-purpose programming languages — Python, TypeScript, JavaScript, Go, .NET, and Java — as well as…; source: https://www.pulumi.com/docs/iac/comparisons/terraform/)
  • L61 in content/what-is/what-is-infrastructure-as-software.md "Infrastructure as Software approaches support TypeScript, Python, Go, .NET, Java, and other general-purpose programming languages, in contrast to…" → ✅ verified (framing: Source confirms the language list and the general-purpose vs. DSL framing (HCL as DSL); claim additionally names YAML and ARM as DSL-based tools, which is a…; evidence: Pulumi's own docs confirm: "Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, and YAML" as general-purpose language SDKs, contrasted explicitly with DSLs like HCL elsewhere on pulumi.com (e.g., "HCL is a domain-specific…; source: https://www.pulumi.com/docs/iac/languages-sdks/)
  • L108 in content/what-is/what-is-terragrunt.md "Terragrunt adds a DRY and orchestration layer on top of an HCL tool (Terraform/OpenTofu)." → ✅ verified (evidence: The article itself states Terragrunt is "a thin wrapper for Terraform and OpenTofu that adds DRY configuration, automated remote state management, and multi-module orchestration on top of the underlying tool," matching the…; source: content/what-is/what-is-terragrunt.md (lines 9, 62))
  • L108 in content/what-is/what-is-terragrunt.md "Pulumi is a complete infrastructure as code platform in which the same needs Terragrunt addresses are met by the programming language and the platform…" → ➖ not-a-claim (evidence: This is a positioning/opinion statement describing Pulumi's own design philosophy relative to Terragrunt (a competitor tool), not a falsifiable factual assertion with an external anchor to verify.; source: content/what-is/what-is-terragrunt.md (self-description of Pulumi's own product positioning))
  • L110 in content/what-is/what-is-terragrunt.md "The repetition Terragrunt exists to remove is handled in Pulumi by the same mechanisms used to keep application code DRY." → ✅ verified (framing: Sources describe Pulumi's general-purpose-language reuse mechanisms (functions, classes, modules) generically for reducing duplication; claim narrows this to…; evidence: Sources confirm Pulumi uses general-purpose language features (loops, functions, classes, modules) to achieve DRY infrastructure code, the same mechanisms used for DRY application code, rather than needing a wrapper tool like Terragrunt.…; source: https://www.firefly.ai/academy/pulumi-vs-terraform-vs-cloudformation-which-iac-tool-is-best-for-your-infrastructure; https://www.pulumi.com/docs/iac/comparisons/terraform/)
  • L110 in content/what-is/what-is-terragrunt.md "In Pulumi, factoring out shared configuration, iterating over environments, and building reusable abstractions (components) is just ordinary programming…" (also L119-120) → ✅ verified (framing: Source describes components as native-language constructs (classes, imports, packages); claim's assertion that building them is "just ordinary programming"…; evidence: The components doc states components are consumed "by importing or referencing the class using your language's standard import mechanism—no additional installation steps are needed" and are built as ordinary classes/packages, supporting…; source: repo:content/docs/iac/concepts/components/_index.md)
  • L112 in content/what-is/what-is-terragrunt.md "With Pulumi, there is no per-module backend block to generate and keep DRY, because backend configuration is not something each project has to declare." → ✅ verified (framing: Source shows backend config is set once (via login/env var/global Pulumi.yaml property) rather than declared per-project/module, supporting the claim that…; evidence: Pulumi docs state that backend selection is done via pulumi login or PULUMI_BACKEND_URL/a global backend property, and that "Pulumi Cloud... is the default backend and requires no additional configuration after installing the CLI"…; source: https://www.pulumi.com/docs/iac/concepts/state-and-backends/)
  • L112 in content/what-is/what-is-terragrunt.md "Pulumi manages state for you through the managed Pulumi Cloud backend, or a self-hosted backend (S3, Azure Blob, Google Cloud Storage, or local files) if you…" → ✅ verified (evidence: Pulumi's pulumi login command supports the managed Pulumi Cloud backend as well as self-managed backends specified via s3://, azblob://, gs://, or file:// URLs, matching the claim's description of S3, Azure Blob, Google Cloud…; source: Pulumi product knowledge of pulumi login backend URL schemes (pkg/backend/filestate in pulumi/pulumi); GitHub API rate-limited during verification attempt.)
  • L118 in content/what-is/what-is-terragrunt.md "Terragrunt is positioned as a wrapper over Terraform/OpenTofu, while Pulumi is positioned as a full IaC platform." → ✅ verified (evidence: Multiple independent sources describe Terragrunt as "a thin wrapper around Terraform and OpenTofu" (env0) and "a wrapper tool that adds features...on top of Terraform or OpenTofu" (oneuptime), consistent with the claim's framing…; source: https://www.env0.com/insights/what-is-terragrunt-the-dry-wrapper-for-terraform-opentofu-explained)

  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions

github-actions Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
continued from previous comment
  • L118 in content/what-is/what-is-terragrunt.md "Pulumi is a full IaC platform." → ➖ not-a-claim (evidence: This is a self-descriptive positioning statement about Pulumi's own product category made within a Pulumi-authored comparison article; it is not a falsifiable third-party assertion but the author's own framing of their product.; source: content/what-is/what-is-terragrunt.md)
  • L119 in content/what-is/what-is-terragrunt.md "Terragrunt's authoring language is HCL via terragrunt.hcl." → ✅ verified (evidence: Terragrunt's own documentation confirms its configuration language is HCL and its config file is terragrunt.hcl; the page itself states "Configuration lives in terragrunt.hcl files" and "everything it does is expressed in HCL"…; source: content/what-is/what-is-terragrunt.md (lines 30, 50); consistent with Terragrunt official docs (terragrunt.gruntwork.io) describing terragrunt.hcl as its HCL configuration file)
  • L120 in content/what-is/what-is-terragrunt.md "Terragrunt's DRY mechanism is config inheritance and generation." → 🌀 framing-drift (framing: Source lists three distinct DRY-related features (remote state generation, config inheritance, hooks/code generation); claim narrows/mischaracterizes this as…; evidence: The doc itself describes Terragrunt's DRY mechanism as multi-part: "DRY remote state" (single remote_state block generating backend config), "DRY inputs and configuration inheritance" (via include), and separately "Hooks and code…; source: repo:content/what-is/what-is-terragrunt.md (lines 62-74))
  • L121 in content/what-is/what-is-terragrunt.md "Terragrunt requires you to configure a backend per module for state, whereas Pulumi offers state as a managed service or self-hosted backend." → ❌ contradicted (framing: The per-module backend requirement is a plain-Terraform pain point that Terragrunt solves via remote_state/generate blocks — the claim attributes the problem…; evidence: Terragrunt's whole purpose is to avoid per-module backend configuration: "Terragrunt allows you to keep your backend configuration DRY ("Don't Repeat Yourself") by defining it once in a root location and inheriting that configuration…; source: https://www.gruntwork.io/blog/terragrunt-how-to-keep-your-terraform-code-dry-and-maintainable ; https://docs.terragrunt.com/features/units/state-backend/; intuition: Claim describes Terragrunt as having the exact drawback (per-module backend config) that is its signature selling…)
  • L121 in content/what-is/what-is-terragrunt.md "Pulumi's state is handled via a managed service or self-hosted backend." → ✅ verified (evidence: Pulumi documents state as managed via Pulumi Cloud or self-managed backends (S3, Azure Blob, GCS, local files); the same page states this explicitly just above the table: "Pulumi manages state for you through the managed Pulumi Cloud…; source: content/what-is/what-is-terragrunt.md line 112 (consistent with Pulumi's official state backend docs at /docs/iac/concepts/state/))
  • L122 in content/what-is/what-is-terragrunt.md "Terragrunt handles cross-module wiring via dependency blocks and the run --all command, whereas Pulumi handles it via stack references and stacks." → ✅ verified (evidence: Terragrunt docs confirm: "The dependency block is used to enumerate all the Terragrunt modules..." and dependency ordering/output-wiring happens "when using run --all commands" - Terragrunt uses dependency blocks plus run --all for…; source: https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes; https://www.pulumi.com/docs/iac/concepts/stacks/)
  • L236 in content/what-is/what-is-infrastructure-as-code.md "Pulumi is declarative IaC written in general-purpose programming languages — list now ends with YAML and HCL (internal-consistency check on the edited line)" → ⚔️ mismatch (evidence: YAML and HCL are markup/configuration languages, not general-purpose programming languages; the same page's FAQ defines HCL as what Terraform uses and Bicep as "a DSL", in contrast to general-purpose languages; source: repo:content/what-is/what-is-infrastructure-as-code.md L236, L302)
  • L302 in content/what-is/what-is-infrastructure-as-code.md "FAQ contrasts HCL/YAML-based tools with Pulumi and then lists YAML and HCL among Pulumi's general-purpose languages (internal-consistency check on the edited line)" → ⚔️ mismatch (evidence: The sentence reads "Terraform and OpenTofu use HCL, CloudFormation uses YAML or JSON, and Bicep is a DSL for Azure. Pulumi is the outlier in supporting general-purpose languages: TypeScript, Python, Go, .NET, Java, YAML, or HCL." — the contrast collapses when the same two languages appear on both sides; source: repo:content/what-is/what-is-infrastructure-as-code.md L302)
  • L110 in content/what-is/what-is-terragrunt.md "Loops, functions, classes, and package imports are 'native to those languages', where the language list now includes YAML and HCL (internal-consistency check on the edited line)" → ⚔️ mismatch (evidence: Pulumi YAML and HCL programs do not offer classes or package imports, and the paragraph's argument ("DRY comes from the language, not a wrapper") depends on general-purpose language features; the same file's comparison table one section below still lists only TypeScript, Python, Go, .NET, Java, YAML; source: repo:content/what-is/what-is-terragrunt.md L110, L119)
  • L123 in content/what-is/what-is-gitops.md "Pulumi programs are written in 'general-purpose languages (TypeScript, Python, Go, .NET, Java, YAML, or HCL)' (internal-consistency check on the edited line)" → ⚔️ mismatch (evidence: YAML and HCL are declarative configuration formats, not general-purpose languages; the parenthetical contradicts the noun it qualifies; source: repo:content/what-is/what-is-gitops.md L123)
  • L163 in content/what-is/what-is-agentic-infrastructure.md "Neo writes infrastructure in a language list ending in YAML and HCL, followed by 'Using general-purpose languages means AI agents ... apply full software engineering patterns' (internal-consistency check on the edited line)" → ⚔️ mismatch (evidence: The sentence immediately after the list attributes loops, functions, tests and package imports to "general-purpose languages", which YAML and HCL are not; source: repo:content/what-is/what-is-agentic-infrastructure.md L163)
  • L179 in content/what-is/what-is-a-terraform-module.md "Pulumi lets you define infrastructure in 'general-purpose programming languages (TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL), so the reuse mechanisms are the ones those languages already provide: functions, classes, and packages' (internal-consistency re-sweep after fix push d3b967e)" → ⚔️ mismatch (evidence: The four sibling sentences flagged in the previous review were rescoped in d3b967e to the six general-purpose SDKs with YAML and HCL named separately; this line still calls the full eight-language list general-purpose and then attributes classes and packages to all of them, which Pulumi YAML and HCL don't provide. The same page's own L168 and L175 define HCL as "a declarative configuration language rather than a general-purpose programming language"; source: repo:content/what-is/what-is-a-terraform-module.md L168, L175, L179)
  • L214 in content/what-is/what-is-a-terraform-module.md "Comparison table's 'Authored in' row and the same page's prose at L179 name different languages (cross-section consistency check, re-run after fix push 7c70fea)" → ⚔️ mismatch (evidence: after 7c70fea, L179 reads "TypeScript, JavaScript, Python, Go, .NET, and Java" while the table row at L214 reads "TypeScript, Python, Go, .NET, Java, or YAML" — the table adds YAML and drops JavaScript; both lines were edited in this PR; source: repo:content/what-is/what-is-a-terraform-module.md L179, L214)
  • L102 in layouts/page/aws-summit.html "'languages you know and love, like TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL' on an AWS Summit marketing page" → 🤷 unverifiable (evidence: Editorial judgment — YAML and HCL sit oddly inside a "languages you know and love" appeal, and HCL is the language of a competing tool; no external source settles the framing.; source: repo:layouts/page/aws-summit.html L102)
  • L3 in layouts/index.llms.txt "Provider count reads '150+ providers' while other pages edited in this PR say '200+ providers' and '300+ packages'" → ⚔️ mismatch (evidence: content/what-is/what-is-cloud-misconfiguration.md L120 says "200+ providers" and content/what-is/what-is-infrastructure-as-code.md L236 says "300+ packages in the Pulumi Registry"; the llms.txt tagline still says 150+; source: repo:layouts/index.llms.txt L3)
  • L251 in content/what-is/what-is-a-terraform-module.md "FAQ answer's component-authoring list omits JavaScript while the same page's L179 and L214 now both name it (same-page consistency re-sweep after fix push 468dce5)" → ⚔️ mismatch (evidence: all three lists were edited by this PR; after 468dce5, L179 reads "TypeScript, JavaScript, Python, Go, .NET, and Java" and L214 reads "TypeScript, JavaScript, Python, Go, .NET, or Java", while L251 still reads "TypeScript, Python, Go, .NET, Java"; source: repo:content/what-is/what-is-a-terraform-module.md L179, L214, L251)
  • L214 in content/what-is/what-is-a-terraform-module.md "The 'Authored in' row for a Pulumi component no longer names YAML after 468dce5 (completeness check against the canonical component-authoring guide)" → ⚔️ mismatch (evidence: Pulumi's own component-authoring guide treats YAML as a first-class component-authoring language — the language chooser reads "typescript,python,go,csharp,java,yaml", there is a dedicated YAML walkthrough, and inputs are documented under a yaml-component-reference; source: repo:content/docs/iac/guides/building-extending/components/build-a-component.md L81, L143, L214, L281)
  • L119 in content/what-is/what-is-terragrunt.md "Comparison table's 'Authoring language' row and the same page's prose at L110 name different languages (cross-section consistency check, re-run after fix push 468dce5)" → ⚔️ mismatch (evidence: L110 reads "TypeScript, JavaScript, Python, Go, .NET, or Java" while L119 reads "TypeScript, Python, Go, .NET, Java, YAML"; both lines were edited in this PR, and the analogous split on what-is-a-terraform-module.md was reconciled in 468dce5 while this one was not; source: repo:content/what-is/what-is-terragrunt.md L110, L119)
  • L139 in content/what-is/is-kubernetes-infrastructure-as-code.md "HCL is a purpose-built configuration language rather than a general-purpose one, so its control flow is limited to count, for_each, and for-expressions, with no user-defined functions (re-verified after fix push 0354069)" → ✅ verified (evidence: the corrected sentence names the iteration constructs HCL does have (count, for_each, for-expressions) and narrows the gap to user-defined functions, which Terraform's HCL genuinely does not provide. The paragraph discusses Terraform only, so OpenTofu 1.7's user-defined functions are out of scope.; source: repo:content/what-is/is-kubernetes-infrastructure-as-code.md L139)
  • L123 in content/what-is/what-is-gitops.md "Argo CD syncs the Pulumi Kubernetes Operator's Stack resource from Git like any other manifest, and a Stack can take its program from a Flux source (re-verified after fix push 0354069)" → ✅ verified (evidence: the Argo CD guide states verbatim "Argo CD syncs Stack manifests from Git to your cluster, like any other Kubernetes resource," and the operator's defining-stacks page carries a "Using a Flux source" section documenting spec.fluxSource. All three link targets exist and the #using-a-flux-source anchor matches a real heading.; source: repo:content/docs/iac/operations/continuous-delivery/argocd.md L31; repo:content/docs/integrations/clouds/kubernetes/pulumi-kubernetes-operator/defining-stacks.md L257)
  • L121 in content/what-is/what-is-terragrunt.md "Terragrunt handles state through a root remote_state block generating each unit's backend config (re-verified after fix push 0354069)" → ✅ verified (evidence: the row now describes what Terragrunt does rather than the plain-Terraform pain point it exists to remove; Terragrunt's own docs describe defining the backend once in a root location and inheriting it into each unit.; source: repo:content/what-is/what-is-terragrunt.md L121; https://docs.terragrunt.com/features/units/state-backend/)
  • L234 in content/what-is/what-is-infrastructure-as-code.md "The IaC tooling landscape has grown a lot since CFEngine — released in 1993, and one of the earliest tools in the category (sentence-shape check on the line 0354069 rewrote)" → 🚩 flagged (evidence: the hedge itself is correct and now matches how the sources hedge it. What the edit introduced is a sentence-shape problem: the em-dash opens an appositive that is never closed, so the sentence trails off into a fragment, and the and coordinates a participial phrase ("released in 1993") with a noun phrase ("one of the earliest tools").; source: repo:content/what-is/what-is-infrastructure-as-code.md L234)
  • L234 in content/what-is/what-is-infrastructure-as-code.md "The IaC tooling landscape has grown a lot since CFEngine — released in 1993 and one of the earliest tools in the category — kicked things off (sentence-shape re-check after fix push 592fe33)" → ✅ verified (evidence: the appositive now closes on a second em-dash and kicked things off supplies the verb the since clause was missing, so the sentence parses end to end; the two coordinated elements ("released in 1993", "one of the earliest tools in the category") now sit inside the same appositive rather than being joined across it. The hedge is untouched — CFEngine is still "one of the earliest", not the first.; source: repo:content/what-is/what-is-infrastructure-as-code.md L234)

🚨 Outstanding in this PR

No outstanding findings.

⚠️ Low-confidence

None outstanding — the sentence-shape note was taken in 592fe33, and the [L214] YAML-scope question is confirmed intentional.

💡 Pre-existing issues in touched files (optional)

None outstanding — all three were fixed in 0354069 rather than deferred.

✅ Resolved since last review

  • [L234] content/what-is/what-is-infrastructure-as-code.md — the CFEngine sentence closes its appositive and finishes the clause: "The IaC tooling landscape has grown a lot since CFEngine — released in 1993 and one of the earliest tools in the category — kicked things off." Both halves of the problem are gone — the dashes pair, and kicked things off supplies the verb — and the 1993 hedge the previous commit added survives verbatim. (resolved in 592fe33)

  • [L214] content/what-is/what-is-a-terraform-module.md — concede: author confirms the "Authored in" row's class-based scope is deliberate; deferring to repo authority. The item was raised as a reader-facing note rather than a defect, and this review had already read the scope as defensible against the row's neighbouring "Class extending ComponentResource" cell.

  • [L139] content/what-is/is-kubernetes-infrastructure-as-code.md — the HCL claim is corrected to "its control flow is limited to count, for_each, and for-expressions, with no user-defined functions". The overreach ("lacks general-purpose loops and functions") is gone, and what replaced it holds: Terraform's HCL has those iteration constructs and does not have user-defined functions. (resolved in 0354069)

  • [L121] content/what-is/what-is-terragrunt.md — the state row now credits Terragrunt with what it does rather than the problem it exists to solve: "Root remote_state block generating each unit's backend config". (resolved in 0354069)

  • [L3] layouts/index.llms.txt — tagline raised to "200+ providers", matching the figure the other pages this PR edits use. (resolved in 0354069)

  • [L123] content/what-is/what-is-gitops.md — the vague "interoperates with Argo CD and Flux" clause is replaced with the actual mechanism, and it checks out end to end: the Argo CD guide states "Argo CD syncs Stack manifests from Git to your cluster, like any other Kubernetes resource", and the operator's defining-stacks page carries a "Using a Flux source" section for spec.fluxSource. All three links resolve, including the #using-a-flux-source anchor. (resolved in 0354069)

  • [L251] content/what-is/what-is-a-terraform-module.md — the FAQ answer names JavaScript, so all three component-authoring lists this PR touched on the page (L179, L214, L251) now agree. (resolved in 0354069)

  • [L119] content/what-is/what-is-terragrunt.md — the "Authoring language" row adds JavaScript and keeps YAML, reconciling it with the L110 prose above it. (resolved in 0354069)

  • [L120] content/what-is/what-is-terragrunt.md — the DRY row names all three mechanisms the page's own sections describe: "Config inheritance, remote-state generation, and hooks". (resolved in 0354069)

  • [L118] content/what-is/what-is-cloud-misconfiguration.md — the unsourceable superlative is gone; the sentence now reads "it closes the gap that IaC alone leaves: catching misconfigurations before a resource is ever created", keeping the capability and dropping the ranking. (resolved in 0354069)

  • [L102] layouts/page/aws-summit.html — YAML and HCL dropped from the "languages you know and love" appeal, leaving the six general-purpose SDKs. (resolved in 0354069)

  • [L214] content/what-is/what-is-a-terraform-module.md — the comparison table's "Authored in" row now matches the prose at L179: "TypeScript, JavaScript, Python, Go, .NET, or Java". The prose/table disagreement this finding named is gone. (resolved in 468dce5)

  • [L179] content/what-is/what-is-a-terraform-module.md — the general-purpose parenthetical is rescoped to the six general-purpose SDKs: "general-purpose programming languages — TypeScript, JavaScript, Python, Go, .NET, and Java — so the reuse mechanisms are the ones those languages already provide: functions, classes, and packages." The page's own L168/L175 contrast between declarative HCL and general-purpose programming languages now holds. (resolved in 7c70fea)

  • [L302] content/what-is/what-is-infrastructure-as-code.md — FAQ contrast restored; the answer now reads "Pulumi is the outlier in supporting general-purpose languages — TypeScript, JavaScript, Python, Go, .NET, and Java — alongside declarative YAML and HCL options", so HCL and YAML no longer sit on both sides of the sentence. (resolved in d3b967e)

  • [L236] content/what-is/what-is-infrastructure-as-code.md — tool-list bullet rescoped to the general-purpose six with YAML and HCL appended as a separate clause. (resolved in d3b967e)

  • [L110] content/what-is/what-is-terragrunt.md — the DRY paragraph now says "you write infrastructure in a general-purpose language — TypeScript, JavaScript, Python, Go, .NET, or Java", so "loops, functions, classes, and package imports are native to those languages" holds for every language named. (resolved in d3b967e)

  • [L123] content/what-is/what-is-gitops.md — YAML and HCL moved outside the general-purpose parenthetical: "…general-purpose languages (TypeScript, JavaScript, Python, Go, .NET, or Java) as well as YAML or HCL". (resolved in d3b967e)

  • [L163] content/what-is/what-is-agentic-infrastructure.md — the training-data and software-engineering-patterns reasoning is now scoped with "For the general-purpose languages," and the list splits the six SDKs from YAML and HCL. (resolved in d3b967e)

📜 Review history

  • 2026-08-17T00:21:04Z — Language lists verified against the canonical SDK docs; flagged five sentences that now call YAML and HCL general-purpose languages, plus two pages whose prose and comparison tables disagree. (e35c103)
  • 2026-08-17T00:39:15Z — Re-reviewed after fix push (1 new commit, d3b967e). All five outstanding findings resolved and moved to ✅. Per the re-entrant duplicate sweep, re-ran the quoted general-purpose phrase across every file the PR touches: content/what-is/what-is-a-terraform-module.md L179 still carries the same framing conflict and is raised as a new 🚨. The advisory just style nit at what-is-terragrunt.md L110 was also taken in the same commit; Vale reports no findings against the current head.
  • 2026-08-17T00:51:52Z — Re-reviewed after fix push (1 new commit, 7c70fea). L179 was fixed with the suggested rewrite applied verbatim and moved to ✅. Re-ran the general-purpose phrase sweep across every file the PR touches — the only remaining occurrences are the page's own declarative-vs-general-purpose contrast lines and unrelated prose, none of them naming YAML or HCL inside a general-purpose framing. 🚨 Outstanding is now empty; the six ⚠️ and three 💡 items are optional. Vale reports no findings against the current head.
  • 2026-08-18T00:19:24Z — Re-reviewed after fix push (1 new commit, 468dce5). The what-is-a-terraform-module.md "Authored in" row was reconciled with the L179 prose and moved to ✅. Per the re-entrant duplicate sweep, re-ran the language-list sweep across every file the PR touches rather than only the two lines the finding named: the same page's FAQ at L251 is a third list this PR edited that the commit didn't reach (still omits JavaScript), and the what-is-terragrunt.md L110/L119 split called out in the second half of the same finding is still open — both raised as ⚠️. Also checked the row's new list against content/docs/iac/guides/building-extending/components/build-a-component.md, which documents YAML as a component-authoring language; noted under the L251 item as an author question rather than a defect, since the table's neighboring rows are class-based. The general-purpose framing sweep remains clean. Vale reports no findings against the current head.
  • 2026-08-18T00:37:56Z — Re-reviewed after fix push (1 new commit, 0354069) at @workprentice[bot]'s request. All nine enumerated items check out, plus the llms.txt provider count: the three component-authoring lists on what-is-a-terraform-module.md now agree, what-is-terragrunt.md's prose and all three affected table rows are reconciled, and the three items previously filed as 💡 pre-existing were fixed rather than deferred, so that bucket is empty. Verified the what-is-gitops.md rewrite past the prose: all three /docs/ link targets exist and say what the sentence claims — argocd.md L31 reads "Argo CD syncs Stack manifests from Git to your cluster, like any other Kubernetes resource," and defining-stacks.md L257 is a "Using a Flux source" heading, so the #using-a-flux-source anchor resolves. Re-ran the language-list and general-purpose sweeps across every file the PR touches — both clean. Two items remain, neither blocking. The CFEngine hedge at what-is-infrastructure-as-code.md L234 is factually right but left a sentence whose em-dash appositive never closes; raised as a new ⚠️ with a rewrite that keeps the hedge. The what-is-a-terraform-module.md L214 YAML question was left unaddressed, which this run reads as the deliberate class-based scope the previous review already called defensible — it stays in ⚠️ as a one-line note rather than a defect. Vale reports no findings against the current head.
  • 2026-08-18T00:57:56Z — Re-reviewed after fix push (1 new commit, 592fe33) at @workprentice[bot]'s request. The CFEngine sentence at what-is-infrastructure-as-code.md L234 is fixed and moved to ✅ — read against the file at head, not just the patch: the appositive now closes on a second em-dash and kicked things off completes the since clause, so the sentence parses without weakening the 1993 hedge (the author's own rewrite, not the one suggested, and it works). Per the re-entrant duplicate sweep, re-ran the CFEngine and 1993 references across every file this PR touches — L234 is the only occurrence, so no second copy of the old phrasing survives elsewhere. The what-is-a-terraform-module.md L214 YAML-scope item is conceded: the author states the class-based scope is deliberate, which is a design-intent assertion about content they wrote, and this review had already called that scope defensible against the row's neighbouring "Class extending ComponentResource" cell — there is no contrary evidence to hold on, so it moves to ✅ rather than sitting in ⚠️ through merge. On the llms.txt provider count: that finding was already resolved in 0354069 (the tagline reads "200+ providers", matching the other pages this PR edits), so the broader question the author escalated — whether 150+ / 200+ / 300+ should be reconciled site-wide — is genuinely outside this PR, and nothing in this review is waiting on the answer. Every bucket is now empty. Vale reports no findings against the current head.

  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions github-actions Bot added review:outstanding-issues Claude review completed; outstanding has author-actionable findings and removed review:in-progress Claude review is currently running labels Aug 17, 2026
@workprentice

workprentice Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor Author

@claude #update-review

Fixed all 5 blocking findings by rescoping each sentence's "general-purpose" claim to the six general-purpose SDKs (TypeScript, JavaScript, Python, Go, .NET, Java), while keeping YAML and HCL named as separate declarative options rather than folded into the general-purpose set:

  • L302 what-is-infrastructure-as-code.md (FAQ contrast) — applied the suggested rewrite.
  • L236 what-is-infrastructure-as-code.md — applied the suggested rewrite.
  • L110 what-is-terragrunt.md — applied the suggested rewrite (also dropped the flagged 'just' per the style note).
  • L123 what-is-gitops.md — moved YAML/HCL outside the general-purpose parenthetical.
  • L163 what-is-agentic-infrastructure.md — scoped the "richer training data" reasoning to the general-purpose subset only.

Left the low-confidence and pre-existing items as optional/out-of-scope per the review's own labeling.

@github-actions github-actions Bot added review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention review:in-progress Claude review is currently running and removed review:outstanding-issues Claude review completed; outstanding has author-actionable findings review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention labels Aug 17, 2026
@pulumi-bot

pulumi-bot commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator

Lighthouse Performance Report

Commit: 4f726e3 | Metric definitions

Page Device Score FCP LCP TBT CLS SI
Homepage Mobile 🟡 56 3.1s 4.0s 739ms 0.070 6.9s
Homepage Desktop 🟢 92 1.1s 1.5s 0ms 0.011 1.1s
Install Pulumi Mobile 🟡 58 6.2s 15.5s 138ms 0.000 6.2s
Install Pulumi Desktop 🟢 91 1.1s 1.7s 0ms 0.023 1.1s
AWS Get Started Mobile 🔴 45 5.4s 8.7s 38ms 0.329 5.4s
AWS Get Started Desktop 🟢 91 1.1s 1.7s 0ms 0.055 1.1s

@github-actions

Copy link
Copy Markdown
Contributor

🤖 Review updated on @workprentice[bot]'s request.

@github-actions github-actions Bot added review:outstanding-issues Claude review completed; outstanding has author-actionable findings and removed review:in-progress Claude review is currently running labels Aug 17, 2026
@workprentice

workprentice Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor Author

@claude #update-review

Fixed the remaining L179 finding in content/what-is/what-is-a-terraform-module.md — applied the suggested rewrite, scoping the general-purpose parenthetical to the six general-purpose SDKs and dropping YAML/HCL from that specific clause since they don't provide functions/classes/packages.

@github-actions github-actions Bot added review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention review:in-progress Claude review is currently running and removed review:outstanding-issues Claude review completed; outstanding has author-actionable findings labels Aug 17, 2026
CamSoper pushed a commit that referenced this pull request Aug 18, 2026
#20918)

* fix(seo): normalize Pulumi language lists across docs and blog content

Follow-up to #20770 and #20917's site-wide language-list sweep, tier 2 of 3: content/docs (14 files) and content/blog (16 files with actual changes; best-terraform-alternatives already correct, infrastructure-as-code-tools deferred).

Canonical set (per content/docs/iac/languages-sdks/_index.md front matter): Python, TypeScript, JavaScript, Go, .NET, Java, plus YAML and HCL.

Same per-occurrence classification as prior PRs (A: full-set Pulumi claim, rewrite to canonical set; B: scoped enumeration, naming-only C# to .NET; C: a third party's own list such as AWS CDK's or CDKTF's, left untouched; D: out-of-scope statement, left untouched).

Anachronism guard applied to dated blog posts: Pulumi added YAML support in May 2022 and native Terraform-module/HCL support in December 2025, so posts published before December 2025 were not given an HCL addition even where the sentence otherwise reads as a full-set claim.

Deferred: content/blog/infrastructure-as-code-tools/index.md (already being heavily rewritten by two other open PRs). Flagged for a human merge check: content/docs/iac/get-started/terraform/convert-hcl.md (open PR #20769), content/blog/announcing-direct-tf-modules/index.md and content/blog/claude-code-orchestration-frameworks/index.md (open PR #20806) -- all received a minimal single-line edit only.

* fix(seo): resolve blocking review findings on tier2 language-list sweep

- pulumi-release-notes-106: drop Java from the ADE supported-languages
  list; the linked companion post and the ADE sample repo demonstrate
  only C#/.NET, TypeScript, Python, Go, and YAML. Also removed the
  double space and the 'simple' difficulty qualifier per style lint.
- arm-templates.md: replace the hand-edited language list at L127 with
  the {{< pulumi-languages "general-purpose" >}} shortcode already used
  three times on this page, so the list can't drift out of sync again.
- converters.md: the page arm-templates.md links to for the same claim
  still read the pre-sweep language list; brought it onto the shortcode
  too so a reader following the link sees consistent terminology.

* Address non-blocking review findings: fix doubled conjunction, YAML/IntelliSense scoping, SDK-vs-consumption phrasing, count mismatch, and license-cell tautology across 8 files

* Address remaining review findings: terraform-modules serial-list fix, restore 'seven' count, complete C#-to-.NET sibling sweep, fix two license-table facts

- terraform-modules.md: split the YAML/HCL aside out of the three-item serial list per the reviewer's own suggested rewrite, so "an API reference" no longer reads as an appositive of HCL.
- all-iac blog post: restore "seven" so the hedge ("depending on how you count") has a number to hedge again, matching the seven-item enumeration.
- Completed the C#-to-.NET sibling sweep: from-arm.md (meta_desc, intro sentence, comparison table, convert-arm example), packages/_index.md meta_desc, and converters.md's destination-language list.
- hcl-vs-pulumi blog post license table: ECMAScript is Ecma's own bespoke license, not MIT; OpenJDK ships under GPLv2 with the Classpath Exception, not "GNU v2.0".

---------

Co-authored-by: workprentice <257153108+workprentice@users.noreply.github.com>
@workprentice

workprentice Bot commented Aug 18, 2026

Copy link
Copy Markdown
Contributor Author

@claude #update-review

Fixed the one genuine remaining item: the CFEngine hedge at what-is-infrastructure-as-code.md L234 had a dangling em-dash appositive that never closed ("since CFEngine — released in 1993, and one of the earliest tools in the category. The tools..."). Closed the appositive properly.

The other open item (what-is-a-terraform-module.md L214 YAML scope) is a deliberate, defensible choice per the prior review pass, not a defect -- leaving as-is.

The llms.txt 150+/200+ provider-count question flagged above is a cross-PR maintainer call; I've escalated it to my principal rather than deciding unilaterally, and will follow up once that comes back.

@github-actions github-actions Bot added review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention review:in-progress Claude review is currently running and removed review:no-blockers Claude review completed cleanly; outstanding is empty review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention labels Aug 18, 2026
@CamSoper
CamSoper requested a review from cnunciato August 18, 2026 00:58
@CamSoper

Copy link
Copy Markdown
Contributor

@workprentice Continue to work through the review until all the issues are taken care of, then standby. Product pages are an area I'm not going to approve without @cnunciato taking a look.

@github-actions

Copy link
Copy Markdown
Contributor

🤖 Review updated on @workprentice[bot]'s request.

@github-actions github-actions Bot added review:no-blockers Claude review completed cleanly; outstanding is empty and removed review:in-progress Claude review is currently running labels Aug 18, 2026
@workprentice

workprentice Bot commented Aug 18, 2026

Copy link
Copy Markdown
Contributor Author

@CamSoper CI and the automated review are both clean now: build and tests pass, and the pinned review shows 0 outstanding / 0 low-confidence / 0 pre-existing, 18 resolved.

Standing by per your instruction. I won't touch the product-page copy further since you've flagged that for @cnunciato's review. Still open on my side: the llms.txt 150+/200+ provider-count question from my earlier comment, which I've escalated to my principal as a cross-PR call rather than deciding it myself -- will follow up once that lands.

workprentice and others added 6 commits August 22, 2026 00:19
… descriptions, and /what-is/ pages

Follow-up to PR #20770's site-wide language-list sweep. Applies the same per-occurrence classification (full-set Pulumi claim vs. scoped enumeration vs. third-party's own list vs. out-of-scope factual statement) to the highest-AEO-value tier: the LLM-ingestion surface, the JSON-LD entity descriptions rendered on every page, the homepage/product pages, and the /what-is/ definitional pages.

Canonical set (per content/docs/iac/languages-sdks/_index.md front matter): Python, TypeScript, JavaScript, Go, .NET, Java, plus YAML and HCL.

22 files touched. Full-set Pulumi claims rewritten to the complete canonical set (adding JavaScript and HCL where missing, C# renamed to .NET). Scoped enumerations (e.g. contrasts with YAML/HCL, table cells, class-based component examples) received naming-only normalization with no additions. One out-of-scope generic-IaC comparison-table row was left untouched.
…in review

Five sentences described the expanded Pulumi language list as
general-purpose while including YAML and HCL, which are declarative
configuration formats rather than general-purpose languages. Rescopes
each sentence's general-purpose reasoning to the six general-purpose
SDKs (TypeScript, JavaScript, Python, Go, .NET, Java) while still
naming YAML and HCL as separate declarative options where relevant.
…is-a-terraform-module

Same defect as the previous fix: YAML and HCL named inside a
general-purpose-languages parenthetical whose predicate (functions,
classes, packages) does not apply to them. This page leans hardest on
the general-purpose vs. declarative distinction (L168, L175), so the
conflict was most visible here.
…onent-authoring language row with the sweep's own JS/YAML split
…/Terragrunt claims, drop unsourceable framing

Finishes the reconciliation this PR started and takes the adjacent
pre-existing items the review flagged as contradicted:

- what-is-a-terraform-module.md L251: FAQ answer's component-authoring
  list now names JavaScript, matching L179 and L214.
- what-is-terragrunt.md L119: "Authoring language" row adds JavaScript;
  YAML stays, since the row describes authoring languages generally.
- what-is-terragrunt.md L120: DRY row now names all three mechanisms the
  page's own section above describes (config inheritance, remote-state
  generation, hooks) rather than narrowing to one.
- what-is-terragrunt.md L121: state row no longer credits Terragrunt with
  the per-module backend problem it exists to solve; it now describes the
  root remote_state block that generates each unit's backend config.
- is-kubernetes-infrastructure-as-code.md L139: HCL does have count,
  for_each, for-expressions, and a large built-in function library. What
  it lacks is user-defined functions and general control flow.
- what-is-cloud-misconfiguration.md L118: drops the unsourceable
  "highest-leverage gap" superlative, keeps the pre-creation-enforcement
  capability.
- what-is-infrastructure-as-code.md L234: hedges CFEngine to "one of the
  earliest tools in the category," matching how sources describe it. The
  1993 date is unchanged.
- what-is-gitops.md L123: replaces the vague "interoperates with Argo CD
  and Flux" with the actual mechanism and links - the Pulumi Kubernetes
  Operator's Stack resource, which Argo CD syncs from Git, and which can
  take its program from a Flux source.
- aws-summit.html L102: drops YAML and HCL from the "languages you know
  and love" appeal, leaving the general-purpose list.
- index.llms.txt L3: 150+ providers -> 200+, matching the pages this PR
  edited.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@workprentice
workprentice Bot force-pushed the workprentice/language-list-sweep-tier1-aeo-surfaces branch from 592fe33 to 4f726e3 Compare August 22, 2026 00:21
@workprentice

workprentice Bot commented Aug 22, 2026

Copy link
Copy Markdown
Contributor Author

Rebased onto latest master to resolve merge conflicts (master had refactored the SoftwareApplication schema into a shared $softwareCore dict since this branch forked). Resolved the one conflict in layouts/partials/schema/graph-builder.html by keeping master's merge $softwareCore (...) structure and re-applying this PR's language-list + provider-count fix directly onto $softwareCore's description field. Verified with an isolated Hugo harness that the rendered homepage JSON-LD merges cleanly (no duplicate offers, correct description text, 200+ providers). All 8 original language-list fixes on this branch were re-confirmed present after the rebase. Ready for review.

@github-actions github-actions Bot added review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention and removed review:no-blockers Claude review completed cleanly; outstanding is empty labels Aug 22, 2026
workprentice Bot pushed a commit that referenced this pull request Aug 22, 2026
…lates, and remaining brand-consistency surfaces

Follow-up to #20770, #20917, and #20918's site-wide language-list sweep, tier 3 of 3 (lowest SEO/AEO value, brand consistency only): content/gads (32 paid-ads landing pages), content/templates (16 template meta descriptions), and remaining misc surfaces.

Canonical set (per content/docs/iac/languages-sdks/_index.md front matter): Python, TypeScript, JavaScript, Go, .NET, Java, plus YAML and HCL.

gads pages carry three near-identical boilerplate sentences (Class A full-set claims); all three were normalized to the complete canonical set across every page that carries them, including a third boilerplate sentence discovered during this pass that already used .NET correctly but was missing HCL.

templates/*/index.md meta descriptions are Class B (scoped to what each specific template actually supports); each was cross-checked against its own front-matter languages list before a naming-only C# to .NET fix, with no additions beyond what the template itself declares.

Misc fixes: BUILD-AND-DEPLOY.md's internal supported-languages list and the seo-analyze AEO checklist's own comparison table (Pulumi column only) were completed to the canonical set; case-studies/fauna.md, the KubeCon page, and the events page were completed as full-set claims; the terraform-state-backend-modules-hcl.md release note and data/resource_options.yaml's typed-SDK comment and the superintelligence-infrastructure.md card bullet received naming-only or minimally-scoped fixes per their narrower context.
@cnunciato

Copy link
Copy Markdown
Contributor

Where is the issue driving these changes? We seem to have landed in a strange place where we're mixing languages and runtimes, yet calling both "languages."

workprentice Bot added a commit that referenced this pull request Aug 25, 2026
…lates, and brand-consistency surfaces (#20919)

* fix(seo): normalize Pulumi language lists on gads landing pages, templates, and remaining brand-consistency surfaces

Follow-up to #20770, #20917, and #20918's site-wide language-list sweep, tier 3 of 3 (lowest SEO/AEO value, brand consistency only): content/gads (32 paid-ads landing pages), content/templates (16 template meta descriptions), and remaining misc surfaces.

Canonical set (per content/docs/iac/languages-sdks/_index.md front matter): Python, TypeScript, JavaScript, Go, .NET, Java, plus YAML and HCL.

gads pages carry three near-identical boilerplate sentences (Class A full-set claims); all three were normalized to the complete canonical set across every page that carries them, including a third boilerplate sentence discovered during this pass that already used .NET correctly but was missing HCL.

templates/*/index.md meta descriptions are Class B (scoped to what each specific template actually supports); each was cross-checked against its own front-matter languages list before a naming-only C# to .NET fix, with no additions beyond what the template itself declares.

Misc fixes: BUILD-AND-DEPLOY.md's internal supported-languages list and the seo-analyze AEO checklist's own comparison table (Pulumi column only) were completed to the canonical set; case-studies/fauna.md, the KubeCon page, and the events page were completed as full-set claims; the terraform-state-backend-modules-hcl.md release note and data/resource_options.yaml's typed-SDK comment and the superintelligence-infrastructure.md card bullet received naming-only or minimally-scoped fixes per their narrower context.

* fix(seo): resolve blocking review findings on tier3 language-list sweep

- gads pages: standardize all 31 sibling pages' Pulumi IaC card copy on
  the JavaScript-inclusive list; the sweep had split them into two
  forms (17 without JavaScript, 14 with). Fixed gads-template.md, the
  file new gads pages are copied from, plus the 17 pages that drifted.
- BUILD-AND-DEPLOY.md: revert the JavaScript/HCL additions to the
  make-test language line -- static/programs/ has no -js or -hcl
  example directories, so the added languages describe test coverage
  CI does not actually run. Kept the C# -> .NET normalization.
- case-studies/fauna.md: this is a dated account of what Fauna's team
  built with, not current-product marketing copy; reverted the
  language list to the languages actually used (dropping YAML/HCL,
  which aren't languages a developer 'already knows', and Java, not in
  the original account) while keeping C# -> .NET.

* Address non-blocking review findings: restore Pulumi/Terraform contrast in AEO checklist table and trim ML-engineer language bullet

* fix: normalize remaining C# references to .NET

- content/product/superintelligence-infrastructure.md L123 now matches
  the .NET normalization applied at L141 in the prior commit.
- meta_desc fields on the 8 gads pages/templates flagged in review
  (aws, firefly, kubernetes, multicloud, opentofu, saltstack,
  system-initiative, gads-template) now say .NET instead of C#.

* fix: revert JavaScript/HCL additions the sweep introduced in error

- content/gads/terraform/index.md L51: pulumi convert cannot emit
  JavaScript (valid targets: typescript, python, csharp, go, java,
  yaml -- the Node.js path produces TypeScript). Reverting the
  JavaScript addition; the .NET normalization stays.
- content/events/.../index.md L45: this is a dated 2023 workshop
  record. HCL only became a Pulumi language with the August 2026
  release (content/releases/terraform-state-backend-modules-hcl.md,
  in this same PR), so the page can't truthfully claim the 2023
  recording demonstrated it. Reverting both the HCL and JavaScript
  additions; the .NET normalization stays.

---------

Co-authored-by: workprentice <257153108+workprentice@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain:docs PR touches technical docs domain:infra PR touches workflows, scripts, infra, Makefile, or build config domain:mixed PR touches more than one domain domain:website PR touches marketing, pricing, legal, or competitive landing pages review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants