Merge branch 'main' into tl/comparaison-pages

Author: rubenfiszel

.claude/review-prompt.md

@@ -0,0 +1,4 @@
+# Claude output format
+
+- Use inline comments at the relevant lines for specific issues.
+- Use a top-level comment for the summary, severity-tagged finding list, AGENTS.md / writing_style_guide.md compliance check, and the verification assessment.

.claude/skills/pricing-feature-audit/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: pricing-feature-audit
+description: Audit src/components/pricing/FeatureList.js for EE/Cloud/Team features that are mentioned in docs or live in the windmill repo but missing from the pricing comparison table. Use when asked to "flag missing pricing features", "audit FeatureList.js", "check if EE features are listed", or to add features (with verified tier flags) to the pricing page.
+---
+
+# Pricing FeatureList audit
+
+## Context
+
+`src/components/pricing/FeatureList.js` is the source of the feature comparison table on https://www.windmill.dev/pricing. Its rows have five tier columns:
+
+- `tier-free-selfhost` — Community Edition (self-host, no license)
+- `tier-enterprise-selfhost` — Enterprise self-host
+- `tier-enterprise-cloud` — Enterprise cloud
+- `tier-free` — free tier on cloud
+- `tier-team` — Team plan on cloud
+
+Each row also has an optional `link` (must be a real URL on the docs site) and `tooltip`.
+
+This file drifts. Engineering ships EE-gated features that get docs and changelogs but never show up here, and previously-EE features sometimes become available to all editions without the row being updated. Both states mislead customers.
+
+## Goal
+
+Find features that:
+
+1. **Should be in the table but aren't** — EE-gated (or Cloud-only / Team-only) features that have docs or shipped commits but no row in `FeatureList.js`.
+2. **Are in the table with the wrong tier flags** — rows that claim EE-only when the runtime is actually open to CE, or vice versa.
+
+Fix the rows, and update the corresponding doc pages so the EE/CE prose matches reality.
+
+## Sources of truth (in priority order)
+
+When deciding whether a feature is EE-gated, **the code is the source of truth, not the docs**. Doc prose lags shipping changes. Verify in this order:
+
+1. **Engineering confirmation** — if you have a direct answer from a Windmill engineer, that wins.
+2. **Backend code in `../windmill`**:
+   - Compile-time gate: `#[cfg(feature = "enterprise")]`, `#[cfg(all(feature = "private", feature = "enterprise"))]`
+   - Runtime gate: `LICENSE_KEY` checks, `require_super_admin_or_admin`, "enterprise edition" error strings
+   - File hint: handlers under `backend/windmill-api/src/` named `*_ee.rs` or `*_ext.rs` are usually EE
+3. **Frontend gate** in `../windmill/frontend`:
+   - `$enterpriseLicense` store, `disabled={!$enterpriseLicense}`
+   - `ee_only: true` flag in `frontend/src/lib/components/instanceSettings.ts`
+4. **Cloud-vs-self-host availability** — check `frontend/src/lib/stores.ts` or any `is_cloud_hosted()` checks. Some features (Kubernetes operator, Windows workers, autoscaling on private clusters) are self-host-only regardless of EE.
+5. **Docs prose** — only as a starting hint, never as the final answer. A line like "this feature requires Enterprise Edition" can be stale.
+
+If a feature has no runtime gate but limits behaviour by other means (e.g., workspace forks count toward the CE 3-workspace cap), reflect that in the tier value as a string, not a boolean — see "Tier value patterns" below.
+
+## Workflow
+
+1. **Ask for scope** — date range, specific feature name, or "audit the whole file".
+2. **Inventory candidates**:
+   - Grep `docs/` for `enterprise edition`, `/pricing`, `EE only`, `enterprise license`, `$enterpriseLicense` references.
+   - Grep recent changelogs in `changelog/` for `ee: true` frontmatter.
+   - For a date-bounded audit, also run `git log --oneline --no-merges` in `../windmill` for `feat:` commits and inspect ones with EE-gated changes.
+3. **For each candidate**, verify against the sources above and produce a row plan: name, suggested section (Platform / Security & Support / Observability / Developers & Deployments / Performance / Flows / Apps), tier flags, doc URL, tooltip.
+4. **Verify every doc URL resolves**:
+   - Folders use numeric prefixes (`16_roles_and_permissions`) but URLs strip them (`/docs/core_concepts/roles_and_permissions`).
+   - Don't fabricate paths — open the file and confirm the exact heading anchor (lower-case, hyphenated, no punctuation) before writing the link.
+5. **Present the plan** to the user before editing. Group additions by section. Flag any rows already in the file whose tier flags conflict with what the code shows.
+6. **On approval**, make the edits to `src/components/pricing/FeatureList.js` (one section at a time, ordered to keep diffs reviewable) and fix any doc pages that mis-state the EE gate.
+7. **Run `npm run build`** and confirm no new broken-link warnings were introduced. Pre-existing warnings (the script-editor / changelog ones) are not yours to fix.
+
+## Tier value patterns
+
+- `true` / `false` for binary availability.
+- A string when the tier has a meaningful limit: `'Up to 2 users'`, `'Counts toward 3-workspace limit'`, `'Maximum 4 groups'`, `'Unlimited'`. Strings render in place of the check/cross icon, so keep them short.
+- Use `tooltip` for self-host vs cloud distinctions that don't fit in the row name (e.g., `'Self-hosted only'`, `'Cloud only'`).
+
+## Common gotchas
+
+- **"EE in docs" ≠ "EE in code"**: a feature page saying "this requires EE" can be wrong. Always grep the backend.
+- **Self-host-only ≠ EE-only**: features like the Kubernetes operator or Windows workers run on CE self-host too — they're absent from cloud, not gated by license.
+- **Cloud Team availability**: features that work on EE cloud usually work on Team unless the backend explicitly blocks Team workspace IDs. Don't copy `tier-enterprise-cloud: true` to `tier-team: false` without checking.
+- **Existing duplicates**: this file has previously had duplicate rows (e.g., a removed Postgres triggers duplicate). Before adding a row, grep the file for the feature name to avoid re-adding it under a different label.
+- **Don't add billing knobs as features**: Non-prod / dev instance mode is a billing affordance, not a feature — skip it.
+
+## When fixing a wrong tier flag
+
+If a row already exists but the tier flags are wrong, also audit any related doc pages — the same misconception that produced the wrong row often shows up as "Enterprise Edition only" prose in the docs. Fix both at once and grep for cross-references in `docs/advanced/23_canonical_deployment_setups/index.mdx` and other "edition requirements" callouts that may inherit the same claim.

.github/codex/pr-review.prompt.md

@@ -0,0 +1,5 @@
+# Codex output format
+
+- Read `./.github/codex/pr-review-context.md` for PR metadata and the diff commands.
+- Return a markdown PR comment starting with `## Codex Review`.
+- Tag each finding with a severity (P0 / P1 / P2), file path, and line number when known confidently.

.github/pi/pr-review.prompt.md

@@ -0,0 +1,6 @@
+# Pi output format
+
+- Read `./.github/pi/pr-review-context.md` for PR metadata and the diff commands.
+- Return a markdown PR comment starting with `## Pi Review`.
+- Tag each finding with a severity (P0 / P1 / P2), file path, and line number when known confidently.
+- Output ONLY the final review markdown — no preamble, no thinking, no tool transcripts.

.github/review-prompt-shared.md

@@ -0,0 +1,57 @@
+# Pull request review — shared policy (windmilldocs)
+
+You are reviewing a GitHub pull request for the **windmilldocs** repository (the public Windmill documentation site, built with Docusaurus). Apply this policy alongside your tool's output requirements.
+
+## Read the project rules first
+
+- Read `AGENTS.md` (repo root), `CLAUDE.md`, and `writing_style_guide.md` before reviewing — they are the canonical contributor guide for documentation.
+- Quote the exact rule from `AGENTS.md` or `writing_style_guide.md` when flagging a violation.
+
+## Review policy
+
+- Only report issues you are confident are real and introduced by this pull request.
+- Focus on factual mistakes, broken links/anchors, MDX/markdown issues, missing or invalid frontmatter, sidebar misregistration, and clear `AGENTS.md` / `writing_style_guide.md` violations.
+- Do not report style nits, speculative concerns, pre-existing issues, or anything Docusaurus's own build (`npm run build`) would obviously catch (build errors are caught by the `check docs build` workflow).
+- Self-validate each finding before posting: "is this definitely a real issue?" If uncertain, discard it.
+- Read additional files only when the diff is not enough to validate a finding.
+- Do not modify any files.
+
+## Severity triage
+
+Tag each finding with a severity. Always report P0 and P1. Report P2 only when the diff invites it (a new docs page, a new section in `sidebars.js`, a new landing page, a new component, or a meaningful restructure).
+
+- **P0** — factually wrong claim about a Windmill feature that could mislead users (e.g. wrong CLI flag, wrong default value, wrong tier gating like "this is free" when it's Enterprise), broken link to a critical onboarding page, secrets/credentials accidentally committed, security misinformation.
+- **P1** — broken internal link or anchor, missing/invalid frontmatter `description`, page not registered in `sidebars.js` when it should be, image referenced but missing from the directory, code example that won't run as written, Enterprise/Cloud/Pro feature not labeled as such on first mention, missing `[Enterprise Edition](/pricing)` link on first mention of EE on the page.
+- **P2** — `AGENTS.md` / `writing_style_guide.md` violations (em dashes, bold misuse, title case in headings, marketing-style language, missing backlinks on first mention of a concept), JSON-LD missing on a non-doc page that needs it, `description` outside the recommended length (120–160 chars for docs/changelog, up to ~300 for blog/case studies), missing `textAnswer` field on FAQ entries, image only in PNG (no WebP) or vice versa, file/folder naming that doesn't follow the underscore + numeric prefix convention.
+
+## Documentation-specific checks
+
+For each new or significantly edited `.md` / `.mdx` page in the diff, verify:
+
+- (a) Frontmatter has a `description` field, between 120–160 chars for docs/changelog, ideally question-based ("How do I ...?").
+- (b) The first mention of "Enterprise Edition" / "EE" links to `/pricing`. Subsequent mentions on the same page do not need to be linked.
+- (c) Internal links use **relative paths** (e.g. `../../8_triggers/index.mdx`) on first mention of a concept, and external links are absolute URLs.
+- (d) If the page introduces a new feature, a backlink exists from related main pages (and ideally a `DocCard` component on the parent index).
+- (e) If a new page is added under `docs/`, it appears in `sidebars.js`. If it's a major feature, it should also be considered for `docs/core_concepts/index.mdx` and `src/components/pricing/FeatureList.js` (when EE/Cloud/Team).
+- (f) Code blocks specify a language (`ts`, `python`, `bash`, etc.).
+- (g) No em dashes ('—') in prose — use sentences without them or '-' instead.
+- (h) Headings use sentence case ('Like this'), not title case ('Like This'). No bold in headings or titles. No HTML colour styling on titles.
+- (i) Images live in the same directory as the related MDX file, with both PNG and optimized WebP versions, and meaningful filenames.
+
+For new non-doc pages (landing/marketing, case studies, product pages, FAQ sections), also verify the JSON-LD `<script type="application/ld+json">` block is present in `<Head>` per the patterns in `AGENTS.md` (`SoftwareApplication`, `FAQPage`, `ItemList`, etc.) and that any rich/JSX FAQ content has a plain-text counterpart (`textAnswer`).
+
+## Test coverage assessment
+
+End your review with a short "Verification" section:
+
+- Note whether `npm run build` was likely to succeed (broken links / anchors, missing files referenced from `sidebars.js`, MDX validity). The CI `npm check` workflow runs this — call out any failure mode you spot in the diff that would block CI.
+- For non-doc page changes (React components, schema, config), describe what manual verification is still useful (navigate to the page locally, click the new link, confirm the FAQ renders, etc.).
+- If the diff has no in-app surface to exercise (purely text edits, image swaps), say that plainly.
+
+## Additional reviewer instructions
+
+If the prompt or context includes an "Additional reviewer instructions" section, treat it as extra guidance from the human who triggered this review and follow it.
+
+## Prior PR discussion
+
+If the prompt or context includes a "Prior PR discussion" section, this PR has already received review activity. Look for your own previous comment, take it into account, focus on what changed in the latest commits, and do not repeat findings the human already pushed back on or addressed.

.github/workflows/build.yml

@@ -5,6 +5,7 @@ on:
     paths:
       - 'src/**'
       - 'docs/**'
+      - 'blog/**'
   push:
     branches:
       - main