Nick Vigilante
bdf0e417b1
Closes DOCS-425. ## Summary Collapse `.vale.ini` to load only the Coder rule package. Drop `Packages = Google, alex, write-good`. Replace `BasedOnStyles = Google, write-good, Coder` with `BasedOnStyles = Coder`. Drop every `Google.X`, `write-good.X`, and `alex.X` per-rule line. Add a rule-rollout doctrine under `docs/.style/README.md`. ## Why The previous config carried roughly 12,000 baseline findings across `docs/`: 412 errors / 5380 warnings / 6247 suggestions, almost entirely from third-party rules whose false-positive patterns Vale cannot distinguish from author intent. - `Google.Headings` false-positives on every acronym and product name: VM, AWS, GCP, Coder, Vale, JetBrains, VS Code. - `Google.Will` fires on legitimate event-sequencing prose. - `Google.Acronyms` fires on widely-known terms the audience reads fluently (AWS, RDP, VPC). - `alex.*` rules shipped in DOCS-40 without a corpus cleanup commit. When CI surfaces false positives, engineers stop reading annotations. PR #25501 review surfaced this concretely on `Google.Headings`. The fix is a tight, trustworthy ruleset rather than tuning around individual false positives. ## Doctrine Full text in `docs/.style/README.md`. Summary: | Element | Value | | --- | --- | | PR title | `feat(docs/.style): enable <RuleName>` | | Commits | (1) corpus-wide cleanup, (2) rule enable + `style-guide.md` section + custom YAML if applicable | | Acceptance | zero baseline findings at merge, at the rule's chosen severity | | Severity | deliberate per-rule choice: `error` blocks merge; `warning` and `suggestion` annotate without failing CI | | False-positive policy | one confirmed FP after enable, refine or revert; applies regardless of severity | Applies equally to Coder-authored rules and third-party rules. Third-party rules return through the same per-rule pattern after their corpus is clean. ### Severity ladder The three-severity ladder is deliberate. Some rules catch hard policy where any violation is wrong (brand names, banned first-person pronouns, em-dashes); those ship at `error` and block merge. Other rules catch strong guidance with legitimate human-judgment exceptions (`disabled` as a technical state vs. ableist usage); those ship at `warning` and annotate without failing CI. Soft guidance (noun-as-adjective patterns like `desired state`, wordiness) ships at `suggestion` as a `notice` annotation. The cleanup discipline applies at every severity. A rule landing at `warning` or `suggestion` still ships with zero baseline findings; the rule's purpose is to catch new violations, not to surface a backlog of existing ones. Standing backlogs train contributors to ignore the annotation channel. The `error`-blocks-merge half of this contract lands operationally via PR [#26587](https://github.com/coder/coder/pull/26587) (DOCS-426), which removes `continue-on-error: true` and `vale --no-exit` from the CI step. ## Effect on the corpus baseline | Metric | Before | After | | --- | --- | --- | | Errors | 412 | 0 | | Warnings | 5380 | 0 | | Suggestions | 6247 | 0 | | Files | 465 | 465 | Verified locally with `mise exec aqua:errata-ai/vale -- vale --no-exit docs/`. ## Functional state after merge The CI `Vale prose lint` step stays advisory (`continue-on-error: true`, `--no-exit`) until PR #26587 lands. With no rules loaded except Coder's package (currently empty on `main`), the step is effectively a no-op until `Coder.BrandNames` lands via PR #25501 (DOCS-34). At that point the lint step becomes a `Coder.BrandNames`-only check. Subsequent per-rule PRs extend coverage one rule at a time per the doctrine, each rule choosing the severity that matches its policy strictness. The Makefile target `docs/.style/.vale-synced: .vale.ini` still runs `vale sync`, which is now a no-op because `Packages` is empty. The previously-synced `docs/.style/styles/{Google,alex,write-good}/` directories remain on developers' disks (they're gitignored) but are no longer loaded by Vale. ## Sequencing 1. **This PR merges first** 2. PR #26587 (DOCS-426) installs the CI merge gate and the severity-rendering fix 3. PR #25501 (DOCS-34) rebases onto main, drops its now-redundant `Google.Parens = NO` change, lands `Coder.BrandNames` as the first concrete rule 4. DOCS-424 (Vale rule audit) is complete; per-rule re-enablement work begins per the doctrine <details> <summary>Decision log</summary> - **Strip everything vs. partial disable**: chose full strip because each third-party rule loaded by default is a tacit endorsement. The doctrine requires every enabled rule to be deliberate. A partial disable still loads styles whose other rules haven't been audited. - **`alex.*` rules**: yanked in this PR. They were enabled in DOCS-40 without a corpus cleanup commit. The "audit then keep" call returns them via dedicated per-rule PRs once the audit confirms baseline violation counts and the doctrine accepts them. - **`Packages` directive dropped**: with no third-party rules loaded, `vale sync` had no work to do. Removing the directive avoids implying we intend to re-add packages without a per-rule PR. The directive returns when a future PR opts in a Google or write-good rule. - **Doctrine location**: under `docs/.style/README.md` rather than a dedicated `docs/.style/RULE_ROLLOUT.md`. Keeps the contributor-facing entry point single, and the section sits alongside the existing "Editing the style guide" and "Editing the content guidelines" sections. - **Three-severity ladder vs. error-only**: chose deliberate per-rule severity because the rule catalogue contains rules at different policy strictness. Forcing every rule to `error` would either reject useful warning- and suggestion-level rules (noun-as-adjective patterns, wordiness guidance) or push them onto an inappropriate gate. The CI severity rendering and merge-gate work in PR #26587 was built specifically to support this ladder. </details> --- *Filed via [Coder Agents](https://coder.com/docs/ai-coder/agents) on Nick's behalf.*
About
Coder is a self-hosted platform for running AI coding agents and cloud development environments on infrastructure you control. It works with any cloud, IDE, OS, Git provider, and IDP.
Coder Workspaces
Coder Workspaces are cloud development environments defined with Terraform, connected through a secure Wireguard tunnel, and automatically shut down when not in use. Agents and developers share the same workspace infrastructure.
- Defined in Terraform: Templates describe the infrastructure for each workspace, from EC2 VMs and Kubernetes Pods to Docker containers.
- Any architecture and OS: Support ARM and x86-64 across Windows, Linux, and macOS from a single deployment.
- Managed by admins: Platform teams create and maintain templates that enforce approved images, resource limits, and security policies.
- Accessed from any IDE: Connect through VS Code, JetBrains, Cursor, a web terminal, remote desktop, or SSH.
- Automatic shutdown: Idle workspaces stop automatically to reduce cloud spend, and restart in seconds when needed.
Coder Agents
Coder Agents is a native AI coding agent built into Coder. The agent loop runs in the Coder control plane on your infrastructure, not in the workspace and not in a vendor's cloud. Developers interact with agents through the web UI or the REST API for programmatic and CI-driven workflows.
- Self-hosted agent loop: The control plane handles planning, model calls, and tool dispatch. Workspaces have zero AI awareness.
- No API keys in workspaces: LLM credentials stay in the control plane.
- Any model: Anthropic, OpenAI, Google, Bedrock, or self-hosted endpoints. Switching is a configuration change.
- Governance and cost controls: Centralized model approval, per-user spend limits, and audit logging.
- Open source and inspectable: The full platform is available to audit and extend.
IDE support
You can use:
-
Any Web IDE, such as
- code-server
- JetBrains Projector
- Jupyter
- And others
-
Your existing remote development environment:
-
A file sync such as Mutagen
Why remote development
Provisioning consistent development environments for a large engineering team is difficult. Each developer has preferences for operating systems, editors, and toolchains, and ensuring a reliable build environment across all of them is a maintenance burden. A missed step during onboarding or an unsupported local configuration can cost hours of debugging.
Remote development solves this by moving the environment off the developer's machine and into managed infrastructure. The developer's laptop becomes a portal into the actual compute where work happens. If a device is lost or replaced, access is simply revoked; no source code or credentials are stored locally.
This approach provides:
- Speed: Server-grade hardware accelerates builds, tests, and large workloads without requiring expensive local machines.
- Consistency: Infrastructure tools such as Terraform, nix, Docker, and Dev Containers produce identical environments for every developer.
- Security: Source code stays on private servers. Users and groups are managed through SSO and RBAC.
- Compatibility: Workspaces share infrastructure configurations with staging and production, reducing configuration drift.
- Accessibility: Browser-based IDEs and remote IDE extensions let developers work from any device, including lightweight laptops, Chromebooks, and tablets.
Read more on the Coder blog, the Slack engineering blog, or from Alex Ellis at OpenFaaS.
Why Coder
The key difference between Coder and other platforms is that the entire system, agent loop, control plane, model routing, and workspace provisioning, runs on infrastructure you control.
For agents, this means platform teams can:
- Run the entire agent loop on their infrastructure, with no SaaS dependency for orchestration.
- Define MCP servers, skills, and system prompts centrally so every agent session starts with the same tools, policies, and context.
- Keep LLM credentials out of workspaces entirely.
- Tie every agent action to an authenticated user identity.
- Support air-gapped and restricted-network deployments with self-hosted models.
For workspaces, this means admins can:
- Support any architecture (ARM, x86-64) and operating system (Windows, Linux, macOS).
- Modify pod/container specs, such as adding disks, managing network policies, or setting/updating environment variables.
- Use VM or dedicated workspaces, developing with Kernel features (no container knowledge required).
- Enable persistent workspaces, which are like local machines, but faster and hosted by a cloud service.
Pricing
Coder is free and open source under the GNU Affero General Public License v3.0. All developer productivity features are included in the open source version. A Premium license is available for enhanced support and custom deployments.
How Coder works
Coder workspaces are represented with Terraform, but you do not need to know Terraform to get started. The Coder Registry provides production-ready templates for AWS EC2, Azure, Google Cloud, Kubernetes, and other providers.
Providers and compute environments
Workspaces can include more than just compute. Terraform can add storage buckets, secrets, sidecars, and other resources.
See the templates documentation for details.
What Coder is not
-
Coder is not an infrastructure as code (IaC) platform.
- Terraform is the first IaC provisioner in Coder, allowing Coder admins to define Terraform resources as Coder workspaces.
-
Coder is not a DevOps/CI platform.
- Coder workspaces can be configured to follow best practices for cloud-service-based workloads, but Coder is not responsible for how you define or deploy the software you write.
-
Coder is not an online IDE.
- Coder supports common editors, such as VS Code, vim, and JetBrains, all over HTTPS or SSH.
-
Coder is not a collaboration platform.
- You can use Git with your favorite Git platform and dedicated IDE extensions for pull requests, code reviews, and pair programming.
-
Coder is not a SaaS/fully-managed offering.
- Coder is a self-hosted solution. You must host Coder in a private data center or on a cloud service, such as AWS, Azure, or GCP.