Improve no-any convention with concrete repo-specific patterns

Author: sdkennedy2

.claude/rules/plugin-development.md

@@ -0,0 +1,9 @@
+---
+paths: "packages/plugins/**"
+---
+# Plugin Development Conventions
+
+- Inject bundler functionality (e.g., `vite.build`, bundler references) as parameters rather than importing bundler packages directly. This improves testability and avoids dynamic import issues.
+- When a plugin needs bundler-specific behavior, encapsulate it in a bundler-specific sub-plugin (e.g., `getVitePlugin()`) and pass bundler functionality in from the top-level plugin entry point.
+- The bundler reference is available through the factory's global context — don't import bundler APIs directly when the context already provides what you need.
+- When adding new functionality, check if similar patterns already exist in other plugins. Follow established patterns for consistency.

.claude/rules/testing.md

@@ -0,0 +1,10 @@
+---
+paths: "**/*.test.ts"
+---
+# Testing Conventions
+
+- Use existing test infrastructure from `packages/tests/src/_jest/helpers/` — check for mock helpers (e.g., `getMockLogger` from `mocks.ts`) before creating ad-hoc mocks.
+- Avoid timing-based waits (`setTimeout`, `sleep`) in tests. Wait for specific conditions instead.
+- Tests should exercise meaningful behavior, not just repeat the implementation. If a test only asserts what the code literally does with no edge cases or integration value, it's low-value.
+- Follow the `cases` + `test.each` pattern for unit tests with multiple inputs/outputs.
+- Use `nock` for HTTP mocking and `memfs` for filesystem mocking in integration tests.

.gitignore

@@ -8,6 +8,8 @@ yarn-error.log
 
 .claude/*
 !.claude/commands/*
+!.claude/rules/
+!.claude/rules/*
 !.claude/settings.json
 
 node_modules/

CLAUDE.md

@@ -114,6 +114,18 @@ Code formatting and linting are configured via:
 ### Yarn Workspace Commands
 Yarn provides "prefixed" scripts using the `<scope>:<action>` pattern. Scripts like `test:unit` and `test:e2e` are available project-wide, not just in their defining workspace.
 
+### Code Conventions
+
+- **No `any` or `as` casts**: Don't use `any` types or `as` type assertions as an escape hatch. Instead use patterns the repo already follows: import types directly from external packages (e.g. `import type { UserConfig } from 'vite'`), use `typeof`/`instanceof`/`in` guards for narrowing (see `wrapPlugins.ts`), derive types from constants with `(typeof MY_CONST)[number]`, or use constrained generics (`<T extends SomeType>`). If you think you need `any`, something is wrong.
+- **Use existing repo utilities**: Before writing new helpers, check what already exists:
+  - HTTP requests: `doRequest` from `@dd/core/helpers/request` (not raw `fetch`)
+  - File operations: `rm` from `@dd/core/helpers/fs` (not `fs/promises` directly)
+  - Types: `@dd/core/types` for shared types like `GlobalContext`, `Logger`, etc.
+  - Test mocks: `getMockLogger` and other helpers from `packages/tests/src/_jest/helpers/mocks`
+- **No unnecessary optionality**: Don't make parameters optional (`?`) when they are always provided. If a value must exist at the call site, make the type reflect that.
+- **DRY with existing code**: Before writing a new implementation, search for existing code that does the same thing. Reuse and extend rather than duplicate.
+- **Consistent dependency versions**: When adding a new dependency, check what version is already used elsewhere in the monorepo (`grep` across `package.json` files) and use the same version. Don't introduce a second version of a package that already exists in the repo.
+
 ### Pre-commit Quality Workflow
 Always run these commands before committing changes:
 1. `yarn format` - Check and fix linting issues