vigiles 2.6.0 → 3.0.0

package/skills/edit-spec/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: edit-spec
+description: Edit a vigiles spec file to update instruction files (CLAUDE.md, AGENTS.md)
+disable-model-invocation: true
+argument-hint: <what to change — e.g., "add a rule about error handling" or "update the testing section">
+---
+
+Edit a `.spec.ts` file to update the project's instruction files. The spec is the source of truth — CLAUDE.md and AGENTS.md are compiled build artifacts that must not be edited directly.
+
+## Arguments
+
+$ARGUMENTS — What the user wants to change. Examples:
+
+- "add a rule about always using the custom logger"
+- "update the architecture section"
+- "add src/services/auth.ts to key files"
+- "add npm run lint to commands"
+- "change the testing guidance"
+
+## Instructions
+
+### Step 1: Find the Spec
+
+Look for spec files in the repo root:
+
+- `CLAUDE.md.spec.ts` — source for CLAUDE.md
+- `AGENTS.md.spec.ts` — source for AGENTS.md
+- Any `*.spec.ts` matching instruction files
+
+If no spec exists, suggest: `npx vigiles setup`
+
+### Step 2: Read and Understand the Spec
+
+Read the spec file. It's a TypeScript file that exports a `claude()` call with these fields:
+
+```typescript
+import { claude, enforce, guidance, check, every } from "vigiles/spec";
+
+export default claude({
+  // Optional: output target (defaults to "CLAUDE.md")
+  target: "CLAUDE.md",
+  // or multi-target:
+  // target: ["CLAUDE.md", "AGENTS.md"],
+
+  // Prose sections — become ## headings in compiled output
+  sections: {
+    positioning: "What this project does...",
+    architecture: "How the codebase is structured...",
+  },
+
+  // File paths verified to exist at compile time
+  keyFiles: {
+    "src/index.ts": "Main entry point",
+  },
+
+  // Commands verified against package.json
+  commands: {
+    "npm run build": "Compile the project",
+    "npm test": "Run all tests",
+  },
+
+  // Rules — three types
+  rules: {
+    // enforce() — backed by a linter rule, verified to exist AND be enabled
+    "no-any": enforce(
+      "@typescript-eslint/no-explicit-any",
+      "Use unknown and narrow with type guards.",
+    ),
+
+    // check() — filesystem assertion run by vigiles
+    "test-pairing": check(
+      every("src/**/*.service.ts").has("{name}.test.ts"),
+      "Every service must have tests.",
+    ),
+
+    // guidance() — prose only, no enforcement
+    "research-first": guidance("Google unfamiliar APIs before implementing."),
+  },
+});
+```
+
+### Step 3: Make the Changes
+
+Based on what the user asked for:
+
+**Adding a rule:**
+
+- Determine the type: `enforce()` if a linter rule exists, `check()` for filesystem conventions, `guidance()` for prose-only
+- For `enforce()`: find the actual linter rule name (e.g., `eslint/no-console`, `@typescript-eslint/no-explicit-any`, `ruff/T201`)
+- Add to the `rules` object with a descriptive key
+
+**Updating a section:**
+
+- Edit the string in `sections`. Sections are plain strings or tagged template literals with `file()`, `cmd()`, `ref()` for verified references
+- Do NOT add `#` or `##` headers inside sections — they break the document structure
+
+**Adding a key file or command:**
+
+- Add to `keyFiles` or `commands`. The compiler verifies these exist at compile time
+- For commands: must match a script in `package.json`
+- For key files: must exist on disk
+
+### Step 4: Compile
+
+After editing the spec, run:
+
+```bash
+npx vigiles compile
+```
+
+This regenerates the compiled instruction file(s). Review the output for any errors:
+
+- `stale-file` — a key file path doesn't exist
+- `stale-command` — a command isn't in package.json
+- `invalid-rule` — a linter rule doesn't exist or is disabled
+- `section-has-header` — a section contains `#` headers (break into separate named sections)
+
+### Step 5: Verify
+
+```bash
+npx vigiles check
+```
+
+If the PostToolUse hook is installed (via `npx skills add zernie/vigiles`), compilation happens automatically after you save the spec.
+
+## Important
+
+- **Never edit CLAUDE.md or AGENTS.md directly** — they have a vigiles hash comment and are build artifacts
+- **The spec is TypeScript** — you get type checking, autocomplete, and verified references
+- **`enforce()` rules are verified** — the compiler checks the rule exists AND is enabled in your linter config
+- **Sections must not contain `#` or `##` headers** — use separate named sections instead

package/skills/enforce-rules-format/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: enforce-rules-format
+description: Validate that all rules have proper enforcement classification (enforce/check/guidance)
+disable-model-invocation: true
+---
+
+Validate that every rule in the project's instruction files has a proper enforcement classification, and fix any that are missing.
+
+## Instructions
+
+### Step 1: Detect Format
+
+Check which format the project uses:
+
+**v2 (spec-based):** Look for `CLAUDE.md.spec.ts` or any `*.spec.ts` files. If found, this is a v2 project — rules must use `enforce()`, `check()`, or `guidance()`.
+
+**v1 (hand-written):** Look for `CLAUDE.md`, `AGENTS.md`, `.cursorrules`. If found without a spec file, this is a v1 project — rules need `**Enforced by:**` or `**Guidance only**` annotations.
+
+### Step 2: Validate
+
+**For v2 specs:**
+
+The TypeScript type system already prevents unannotated rules — you can't create a rule without calling `enforce()`, `check()`, or `guidance()`. So focus on:
+
+1. Do `enforce()` rules reference real linter rules? Run `npx vigiles compile` to check.
+2. Are there guidance rules that COULD be `enforce()`? Check linter configs for matching rules.
+3. Are there `check()` assertions that could be delegated to a linter? Suggest `enforce()` instead.
+
+```bash
+npx vigiles compile
+npx vigiles discover
+```
+
+**For v1 hand-written files:**
+
+Scan for `###` headings. Each must have one of:
+
+- `**Enforced by:** \`linter/rule-name\``
+- `**Guidance only** — reason`
+- `<!-- vigiles-disable -->`
+
+Report missing annotations with a summary table.
+
+### Step 3: Fix Issues
+
+For each issue found:
+
+1. Check the project's linter configuration for matching rules
+2. Suggest `enforce("linter/rule")` (v2) or `**Enforced by:** \`linter/rule\`` (v1)
+3. If no linter rule exists, suggest `guidance()` (v2) or `**Guidance only**` (v1)
+4. **Ask the user** before making changes
+
+### Step 4: Suggest Migration
+
+If the project uses v1 format, suggest migrating to v2 specs for type safety:
+
+> Your rules could benefit from type-safe specs. Run the `migrate-to-spec` skill to convert your CLAUDE.md to a typed .spec.ts file.
+
+### Step 5: Verify
+
+Run the appropriate command:
+
+```bash
+# v2
+npx vigiles compile && npx vigiles check
+
+# validate
+npx vigiles check
+```
+
+Report the validation result.

package/skills/generate-logo/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: generate-logo
+description: Generate or iterate on the vigiles logo using ImageRouter API
+---
+
+# Generate Logo
+
+Generate logo variations for vigiles using the ImageRouter API (imagerouter.io).
+
+## Setup
+
+Get an API key from https://imagerouter.io/api-keys. Pass it as an argument or set `IMAGEROUTER_API_KEY` env var. Do NOT commit the key.
+
+## API
+
+```
+Endpoint: https://api.imagerouter.io/v1/openai/images/generations
+Auth: Bearer token in Authorization header
+Method: POST, Content-Type: application/json
+```
+
+### Request body
+
+```json
+{
+  "prompt": "...",
+  "model": "google/nano-banana-2",
+  "quality": "high",
+  "size": "1024x1024",
+  "response_format": "url",
+  "output_format": "png"
+}
+```
+
+### Available models (image generation)
+
+List models: `GET https://api.imagerouter.io/v1/models`
+
+Known good models:
+
+- `google/nano-banana-2` — best quality, $0.07/image
+- `google/nano-banana-2:free` — free tier
+- `openai/gpt-image-1` — OpenAI's image model
+- `black-forest-labs/FLUX-1.1-pro` — FLUX pro
+
+### Response
+
+```json
+{
+  "created": 1775430873,
+  "data": [{ "url": "https://storage.imagerouter.io/..." }],
+  "cost": 0.069,
+  "latency": 27627
+}
+```
+
+Download the image from the URL in `data[0].url`.
+
+## Current logo
+
+The current logo (`logo.png`) is v6: overlapping translucent flame petals on dark background, amber-orange palette. Generated with `google/nano-banana-2`.
+
+### Prompt that produced it
+
+```
+A premium, refined logo icon for a developer tool called vigiles that compiles
+typed TypeScript specs to AI instruction files. Inspired by OpenAI geometric aesthetic and Apple
+minimalism. A single abstract geometric shape: an upward-pointing flame composed
+of 3 overlapping translucent rounded shapes, creating depth through overlap —
+similar to how the OpenAI logo uses overlapping curves. Warm amber to deep orange
+color palette. Black background. No text. No letters. Pure abstract mark. Clean
+enough to be an app icon. Luxurious, premium, modern tech company feel.
+```
+
+## Design principles
+
+- **Flame/torch motif** — vigiles were Rome's night watchmen who carried torches
+- **Amber/orange palette** — matches GitHub Action branding color
+- **No text in the icon** — must work at 16px favicon size
+- **Dark background variant** for README, light/transparent variant for npm
+
+## Example curl
+
+```bash
+curl 'https://api.imagerouter.io/v1/openai/images/generations' \
+  -H "Authorization: Bearer $IMAGEROUTER_API_KEY" \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "prompt": "YOUR PROMPT HERE",
+    "model": "google/nano-banana-2",
+    "quality": "high",
+    "size": "1024x1024",
+    "response_format": "url",
+    "output_format": "png"
+  }'
+```
+
+## Workflow
+
+1. Generate variations with different prompts
+2. Save as `logo-v*.png` (gitignored)
+3. Pick the best, copy to `logo.png`
+4. Commit `logo.png` only

package/skills/generate-rule/SKILL.md

@@ -0,0 +1,64 @@
+<!-- vigiles:sha256:a9df2c1748576753 compiled from skills/generate-rule/SKILL.md.spec.ts -->
+
+---
+
+name: generate-rule
+description: Add a new enforce(), check(), or guidance() rule to an existing spec file
+disable-model-invocation: true
+argument-hint: <rule>
+
+---
+
+## Arguments
+
+- `$1` **rule** — natural-language description of what the rule should enforce, e.g. "no console.log in production code"
+
+## Steps
+
+### Step 1
+
+**Find the spec file.** Look for `CLAUDE.md.spec.ts` in the repo root. If it doesn't exist:
+
+- If there's a hand-written `CLAUDE.md`, suggest running the `migrate-to-spec` skill first.
+- If there's no `CLAUDE.md` either, suggest `npx vigiles init` to scaffold one.
+
+### Step 2
+
+**Classify the rule** from the description ($1):
+
+- **enforce()** — if a linter rule can back it. Check the project's linter configs (ESLint, Ruff, Clippy, Pylint, RuboCop, Stylelint) for a matching rule; also consider an architectural tool (ast-grep, Dependency Cruiser, Steiger). If uncertain whether a rule exists, **ask the user** rather than guessing.
+- **check()** — if it's a filesystem structural convention ("every X needs a Y"). Only for file-pairing; never for code content.
+- **guidance()** — if it can't be mechanically enforced (subjective conventions, process rules, migration context).
+
+### Step 3
+
+**Generate the rule.** Create an entry with a kebab-case ID derived from the description. Examples:
+
+    "no-console": enforce("eslint/no-console", "Use structured logger for observability."),
+
+    "controller-tests": check(
+      every("src/**/*.controller.ts").has("{name}.controller.test.ts"),
+      "Every controller must have a co-located test file.",
+    ),
+
+    "research-before-implementing": guidance(
+      "Google unfamiliar APIs before implementing.",
+    ),
+
+### Step 4
+
+**Add it to the spec.** Read the existing spec file and add the new rule to the `rules` object, preserving alphabetical ordering if the existing rules are alphabetical. Import any new builders needed (e.g. `check` and `every` for the first `check()` rule).
+
+### Step 5
+
+**Compile and verify.** Build and recompile; if compilation fails (e.g. the linter rule doesn't exist), report the error and suggest alternatives. Show the user the updated spec and the compiled `CLAUDE.md` diff.
+
+**Gate** — run the project's build command (retry up to 2×); do not proceed until it passes.
+
+<!-- vigiles:gate role:build retry:2 -->
+
+## Result
+
+This skill is complete when the project's build command passes.
+
+<!-- vigiles:result role:build -->

package/skills/linter-docs/clippy.md

@@ -0,0 +1,241 @@
+# Clippy — Reference
+
+Shared linter reference for vigiles skills. Used by `strengthen` (find existing rules) and `pr-to-lint-rule` (write custom lints).
+
+## Check Existing Lints First
+
+Before writing a custom lint, search these lint groups — the pattern may already be covered:
+
+| Lint group    | Scope                                               | Key lints to know                                                                                                                                            |
+| ------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `correctness` | Code that is outright wrong or will panic           | `uninit_assumed_init`, `wrong_self_convention`, `nonsensical_open_options`, `mistyped_literal_suffixes`, `transmuting_null`, `undropped_manually_drops`      |
+| `suspicious`  | Code that is very likely a bug                      | `suspicious_else_formatting`, `suspicious_unary_op_formatting`, `suspicious_op_assign_impl`, `blanket_clippy_restriction_lints`, `almost_complete_range`     |
+| `style`       | Idiomatic Rust style violations                     | `needless_return`, `redundant_closure`, `match_bool`, `single_match`, `collapsible_if`, `len_zero`, `manual_map`, `if_let_mutex`                             |
+| `complexity`  | Code that can be simplified                         | `unnecessary_cast`, `needless_borrow`, `redundant_clone`, `type_complexity`, `manual_strip`, `option_map_unit_fn`, `useless_conversion`                      |
+| `perf`        | Code that can be made faster                        | `large_enum_variant`, `box_collection`, `redundant_allocation`, `manual_memcpy`, `iter_nth`, `unnecessary_to_owned`, `needless_collect`                      |
+| `pedantic`    | Stricter lints, off by default                      | `unwrap_used`, `expect_used`, `cast_possible_truncation`, `cast_sign_loss`, `missing_errors_doc`, `missing_panics_doc`, `doc_markdown`, `must_use_candidate` |
+| `restriction` | Lints for specific project policies, off by default | `print_stdout`, `print_stderr`, `dbg_macro`, `unimplemented`, `todo`, `unwrap_used`, `expect_used`, `mem_forget`, `shadow_reuse`, `float_arithmetic`         |
+| `nursery`     | Experimental lints, may have false positives        | `missing_const_for_fn`, `cognitive_complexity`, `use_self`, `option_if_let_else`, `redundant_pub_crate`, `significant_drop_tightening`                       |
+| `cargo`       | Cargo manifest issues                               | `multiple_crate_versions`, `wildcard_dependencies`, `negative_feature_names`, `redundant_feature_names`                                                      |
+
+**Tip:** Run `cargo clippy --warn clippy::pedantic` on your codebase to see what pedantic catches before manually hunting for rules. The full lint list is at <https://rust-lang.github.io/rust-clippy/stable/>.
+
+## Lint Configuration
+
+### Cargo.toml `[lints.clippy]` section (recommended)
+
+The modern way to configure Clippy project-wide. Checked into version control, applies to every `cargo clippy` invocation:
+
+```toml
+# Cargo.toml
+[lints.clippy]
+# Enable entire groups
+pedantic = "warn"
+nursery = "warn"
+
+# Override individual lints
+unwrap_used = "deny"
+expect_used = "warn"
+cast_possible_truncation = "allow"
+
+# Restriction lints — opt-in individually
+print_stdout = "warn"
+dbg_macro = "deny"
+```
+
+This replaces the older `#![warn(clippy::pedantic)]` crate-level attribute approach. vigiles reads `Cargo.toml` for `enforce()` verification.
+
+### Inline attributes
+
+Use `#[allow]`, `#[warn]`, and `#[deny]` for per-item overrides:
+
+```rust
+// Suppress a lint on a single function
+#[allow(clippy::too_many_arguments)]
+fn create_widget(a: u32, b: u32, c: u32, d: u32, e: u32, f: u32, g: u32) { /* ... */ }
+
+// Escalate a lint to a hard error for a module
+#[deny(clippy::unwrap_used)]
+mod payment_processing {
+    // Any .unwrap() in this module fails compilation
+}
+
+// Warn on a lint for a specific impl block
+#[warn(clippy::cast_possible_truncation)]
+impl Converter {
+    fn to_u32(&self, val: u64) -> u32 { val as u32 }
+}
+```
+
+Attribute precedence (highest to lowest): `#[forbid]` > `#[deny]` > `#[warn]` > `#[allow]`. `#[forbid]` cannot be overridden by inner attributes — use it for security-critical lints.
+
+### `clippy.toml` / `.clippy.toml`
+
+Project-level configuration for lint thresholds and behavior:
+
+```toml
+# clippy.toml
+too-many-arguments-threshold = 10
+type-complexity-threshold = 500
+cognitive-complexity-threshold = 30
+single-char-binding-names-threshold = 4
+msrv = "1.70.0"
+
+# Disallow certain types
+disallowed-types = [
+    { path = "std::collections::HashMap", reason = "Use indexmap::IndexMap for deterministic iteration" },
+]
+
+# Disallow certain methods
+disallowed-methods = [
+    { path = "std::env::var", reason = "Use config::get() for environment access" },
+]
+
+# Disallow certain macros
+disallowed-macros = [
+    { path = "std::println", reason = "Use tracing::info! instead" },
+]
+```
+
+`disallowed-types`, `disallowed-methods`, and `disallowed-macros` are particularly powerful — they let you ban specific APIs project-wide with custom error messages, no custom lint needed.
+
+## Custom Lints
+
+### dylint — custom Clippy-style lints
+
+[dylint](https://github.com/trailofbits/dylint) loads lint libraries as dynamic libraries, giving you the same compiler internals that Clippy uses:
+
+```rust
+// my_lint/src/lib.rs
+use clippy_utils::diagnostics::span_lint_and_help;
+use rustc_lint::{LateContext, LateLintPass, LintArray, LintPass};
+use rustc_session::{declare_lint, declare_lint_pass};
+
+declare_lint! {
+    /// Disallow direct database calls outside the `db` module.
+    pub NO_DIRECT_DB_CALL,
+    Warn,
+    "direct database calls should go through the db module"
+}
+
+declare_lint_pass!(NoDirectDbCall => [NO_DIRECT_DB_CALL]);
+
+impl<'tcx> LateLintPass<'tcx> for NoDirectDbCall {
+    fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx rustc_hir::Expr<'_>) {
+        if is_direct_db_call(cx, expr) {
+            span_lint_and_help(
+                cx,
+                NO_DIRECT_DB_CALL,
+                expr.span,
+                "direct database calls are not allowed here",
+                None,
+                "use the repository pattern — import from `crate::db` instead",
+            );
+        }
+    }
+}
+```
+
+**When to use dylint vs existing Clippy lints:**
+
+| Situation                                 | Use                                         |
+| ----------------------------------------- | ------------------------------------------- |
+| Ban a specific function/type/macro        | `clippy.toml` `disallowed-*` — zero code    |
+| Enforce naming or style convention        | Existing Clippy pedantic/style lints        |
+| Detect a pattern needing type information | dylint — access to rustc type checker       |
+| Enforce architectural boundaries          | dylint or `cargo-deny` for dependency rules |
+| One-off "don't use X" in a single crate   | `#[deny(clippy::...)]` attribute            |
+
+**dylint tradeoffs:**
+
+- Tied to a specific Rust nightly version (compiler internals are unstable)
+- Requires maintaining a separate crate with `rustc_private` dependencies
+- `clippy_utils` provides helper functions but its API changes between releases
+- Build times increase since the lint library compiles against `rustc` internals
+
+For vigiles, reference dylint lints via: `enforce("clippy/no_direct_db_call", "Use the repository pattern.")` — the lint name maps to the `declare_lint!` identifier (snake_case).
+
+## Edge Cases and Gotchas
+
+### False positives from macros
+
+Clippy lints operate on the expanded AST. Macros can trigger false positives because the expanded code looks different from what the author wrote:
+
+```rust
+// This macro expansion may trigger `clippy::redundant_clone`
+// even though the clone is structurally necessary in the macro output
+my_derive_macro! {
+    struct Foo { bar: String }
+}
+```
+
+Workarounds:
+
+- `#[allow(clippy::...)]` on the macro invocation site
+- Add `#[automatically_derived]` in proc-macro output — Clippy skips many lints for derived code
+- File an issue upstream if the false positive is in a common macro pattern
+
+### Nightly-only lints
+
+Some Clippy lints require nightly Rust because they depend on unstable compiler features. The `nursery` group is the most common source. If you enable `nursery` lints in CI:
+
+- Pin a specific nightly version: `rust-toolchain.toml` with `channel = "nightly-2025-01-15"`
+- Expect breakage on nightly updates — nursery lints can be renamed, removed, or change behavior
+- Never `#[deny]` nursery lints — use `#[warn]` so they don't block builds when behavior changes
+
+### `allow` vs `warn` on groups
+
+Enabling a group and then allowing individual lints works top-down:
+
+```toml
+# Cargo.toml
+[lints.clippy]
+pedantic = "warn"           # Enable all pedantic lints
+module_name_repetitions = "allow"   # But suppress this one
+```
+
+The reverse does NOT work — you cannot `allow` a group and then `warn` an individual lint from it. The group-level `allow` takes precedence. Always enable groups first, then suppress specific lints.
+
+### Interaction with `#[must_use]`
+
+Clippy's `must_use_candidate` lint (pedantic) suggests adding `#[must_use]` to functions that return values. This interacts with other lints:
+
+- Once `#[must_use]` is added, callers who ignore the return value get `unused_must_use` (a rustc warning, not Clippy)
+- `let _ = foo()` silences `unused_must_use` but triggers `let_underscore_must_use` (Clippy restriction)
+- `drop(foo())` silences both but may trigger `drop_non_drop` if the type doesn't implement `Drop`
+
+Recommendation: Enable `must_use_candidate` globally, but only `#[deny(unused_must_use)]` in modules where ignoring results is dangerous (I/O, error handling).
+
+### Unsafe code linting
+
+Clippy provides several lints for `unsafe` code, but they have limitations:
+
+- `undocumented_unsafe_blocks` (restriction) — requires a `// SAFETY:` comment above every `unsafe` block. Enable this project-wide.
+- `unsafe_derive_deserialize` (pedantic) — warns when `Deserialize` is derived on types with unsafe invariants
+- `multiple_unsafe_ops_per_block` (restriction) — each `unsafe` block should contain exactly one unsafe operation for precise `// SAFETY:` documentation
+
+These lints do NOT verify that safety invariants are actually upheld — they only enforce documentation conventions. Use `cargo miri test` and `#[cfg(miri)]` for runtime verification of unsafe code.
+
+### MSRV-aware lints
+
+Clippy respects the `msrv` field in `clippy.toml`. Some lints suggest replacements that require newer Rust versions. If you set `msrv = "1.65.0"`, Clippy won't suggest `let-else` (stabilized in 1.65) but will suppress suggestions for features from 1.66+. Always set this to match your `rust-version` in `Cargo.toml`.
+
+## Mapping PR Feedback to Lint Strategy
+
+| PR comment pattern                          | Best approach                                                                                                     |
+| ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
+| "Don't use `.unwrap()`"                     | `enforce("clippy/unwrap_used", "Use expect() with context or propagate with ?.")` — pedantic, enable project-wide |
+| "Don't call this function"                  | `clippy.toml` `disallowed-methods` — zero custom code, includes custom error message                              |
+| "Don't use this type"                       | `clippy.toml` `disallowed-types` — same approach, works for `HashMap`, `Mutex`, etc.                              |
+| "Don't use `println!`"                      | `enforce("clippy/print_stdout", "Use tracing macros.")` — restriction lint, opt-in                                |
+| "Add error context"                         | Not Clippy — use `#[deny(clippy::unwrap_used)]` + guidance for `anyhow`/`thiserror` patterns                      |
+| "This clone is unnecessary"                 | `enforce("clippy/redundant_clone", "Remove the unnecessary clone.")` — already in complexity group                |
+| "Use `Self` in impl blocks"                 | `enforce("clippy/use_self", "Use Self instead of repeating the type name.")` — nursery lint                       |
+| "Document safety invariants"                | `enforce("clippy/undocumented_unsafe_blocks", "Add a // SAFETY: comment.")` — restriction lint                    |
+| "Too many function parameters"              | `enforce("clippy/too_many_arguments", "Refactor into a config struct.")` — already in complexity group            |
+| "Wildcard deps in Cargo.toml"               | `enforce("clippy/wildcard_dependencies", "Pin dependency versions.")` — cargo group                               |
+| "Every public fn needs error docs"          | `enforce("clippy/missing_errors_doc", "Document the errors this function can return.")` — pedantic                |
+| "Avoid `as` casts"                          | `enforce("clippy/cast_possible_truncation", "Use try_from() or explicit checked conversion.")` — pedantic         |
+| "Don't leave `todo!()` in code"             | `enforce("clippy/todo", "Replace todo!() with an implementation or file an issue.")` — restriction lint           |
+| "Use the builder pattern"                   | Not Clippy — use vigiles `guidance()` for architectural patterns                                                  |
+| "Enforce import boundaries between modules" | Not Clippy — use `cargo-deny` for crate-level boundaries or dylint for module-level enforcement                   |