@event4u/agent-config 1.9.1

package/.agent-src/skills/override-management/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: override-management
+description: "Creates and manages project-level overrides for shared skills, rules, and commands — extending or replacing originals from .augment/ with project-specific behavior in agents/overrides/."
+source: package
+execution:
+  type: assisted
+  handler: internal
+  allowed_tools: []
+---
+
+# Override Skill
+
+## When to use
+
+Use when creating or managing project-level overrides for shared skills, rules, commands, or guidelines — customizing `.augment/` content without modifying originals.
+
+Do NOT use when:
+- Changing shared content that should affect all projects (edit `.agent-src.uncompressed/` directly)
+- Creating new skills from scratch (use `skill-writing` skill)
+
+## Purpose
+
+The `.augment/` directory is delivered as a **Composer package** and is **read-only** at project level.
+It contains shared skills, rules, commands, guidelines, and templates that work across all projects.
+
+The `agents/overrides/` directory is **project-specific** and lives in the project's own repository.
+It customizes shared behavior for a particular codebase **without modifying the originals**.
+
+**Critical rule:** Never edit files in `.augment/` to fix a project-specific need.
+Changes to `.augment/` affect ALL projects. Use overrides instead.
+
+## Procedure: Create an override
+
+Before creating, understand the original:
+
+1. **Read the original** from `.augment/{type}/{name}` — understand purpose and behavior
+2. **Check existing overrides** in `agents/overrides/{type}/` — avoid duplicates
+3. **Identify what needs changing** — only override specific behavior that differs
+
+When loading any skill, rule, or command:
+
+1. **Load the original** from `.augment/{type}/{name}`
+2. **Check for override** in `agents/overrides/{type}/{name}`
+3. **If override exists**, read its `Mode` header:
+   - **`extend`** — Apply the original first, then layer the override on top (additive)
+   - **`replace`** — Ignore the original entirely, use only the override
+
+## Directory Structure
+
+```
+agents/overrides/
+├── rules/           ← Override .augment/rules/*.md
+│   └── .gitkeep
+├── skills/          ← Override .augment/skills/*/SKILL.md
+│   └── .gitkeep
+├── commands/        ← Override .augment/commands/*.md
+│   └── .gitkeep
+├── guidelines/      ← Override .augment/guidelines/**/*.md
+│   └── .gitkeep
+└── templates/       ← Override .augment/templates/*.md
+    └── .gitkeep
+```
+
+## File Naming Convention
+
+Override files **must match the original filename** exactly:
+
+| Original | Override |
+|---|---|
+| `.augment/rules/php-coding.md` | `agents/overrides/rules/php-coding.md` |
+| `.augment/skills/eloquent/SKILL.md` | `agents/overrides/skills/eloquent.md` |
+| `.augment/commands/feature-plan.md` | `agents/overrides/commands/feature-plan.md` |
+| `.augment/guidelines/php/controllers.md` | `agents/overrides/guidelines/php-controllers.md` |
+| `.augment/templates/roadmaps.md` | `agents/overrides/templates/roadmaps.md` |
+
+**Skills** are flattened: the original lives in a directory (`skills/{name}/SKILL.md`),
+but the override is a single file (`skills/{name}.md`).
+
+**Guidelines** are flattened with a prefix: `guidelines/php/controllers.md` → `guidelines/php-controllers.md`.
+
+**Templates** keep their original filename: `templates/roadmaps.md` → `templates/roadmaps.md`.
+
+## Override File Format
+
+Every override file **must** have this header:
+
+```markdown
+# Override: {Type} — {name}
+
+> Override for `.augment/{path-to-original}`
+
+---
+**Mode:** `extend`
+**Original:** `.augment/{path-to-original}`
+---
+```
+
+### Mode: extend
+
+- The original is loaded first
+- The override adds, modifies, or removes specific parts
+- Reference original sections by heading name
+- Only write what changes — everything else stays as-is
+
+### Mode: replace
+
+- The original is completely ignored
+- The override is the sole source of truth
+- Must be self-contained and complete
+
+## When to Create Overrides
+
+| Situation | Action |
+|---|---|
+| Shared skill doesn't match project conventions | **extend** — add project-specific rules |
+| Shared command needs extra steps for this project | **extend** — inject additional steps |
+| Shared rule is too strict/lenient for this project | **extend** — adjust specific rules |
+| Shared guideline misses project-specific patterns | **extend** — add examples or sections |
+| Shared template needs extra fields for this project | **extend** — add project-specific fields |
+| Shared skill is completely wrong for this project | **replace** — write from scratch |
+| Project needs behavior not in any shared skill | Create a new skill in `.augment/skills/` instead |
+
+## When NOT to Create Overrides
+
+- **Don't override to fix bugs in the shared package** — fix the original in the `.augment/` package repo instead
+- **Don't override for temporary changes** — use branch-specific notes instead
+- **Don't create empty overrides** — only create when there's actual content
+- **Don't duplicate the original** — `extend` mode should only contain the delta
+
+## Checking for Overrides (Agent Behavior)
+
+Before executing any skill, rule, or command, agents **must**:
+
+1. Note the original path (e.g., `.augment/skills/eloquent/SKILL.md`)
+2. Check if `agents/overrides/skills/eloquent.md` exists
+3. If it exists, read the `Mode` header
+4. Apply accordingly:
+   - `extend` → Load original, then apply override additions/changes
+   - `replace` → Skip original, use override only
+
+## Templates
+
+Override templates are in `.augment/templates/overrides/`:
+
+| Template | For |
+|---|---|
+| `rule.md` | Overriding a rule |
+| `skill.md` | Overriding a skill |
+| `command.md` | Overriding a command |
+| `guideline.md` | Overriding a guideline |
+| `template.md` | Overriding a template |
+
+## Related
+
+- **Commands:** `/override-create`, `/override-manage`
+- **Skill:** `agent-docs-writing` (documentation hierarchy)
+- **Templates:** `.augment/templates/overrides/`
+
+### Validate
+
+- Verify the override file exists at the correct path in `agents/overrides/`.
+- Confirm the override actually takes effect (test the behavior it modifies).
+- Check that the original in `.augment/` is not modified.
+
+## Output format
+
+1. Override file in agents/overrides/ matching the original's structure
+2. Summary of what was overridden and why
+
+## Gotcha
+
+- Overrides are invisible to other projects — only the current project sees them.
+- Replace mode discards the original entirely — use extend mode unless you need a full rewrite.
+- If the override stops working after a package update, the original's structure likely changed.
+
+## Do NOT
+
+- Do NOT create overrides for things that should be changed in the original.
+- Do NOT use replace mode when extend mode is sufficient.
+
+## Auto-trigger keywords
+
+- override
+- project override
+- extend skill
+- replace skill

package/.agent-src/skills/performance/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: performance
+description: "Use when optimizing application performance — caching strategies, eager loading, query optimization, Redis patterns, or background job design."
+source: package
+---
+
+# performance
+
+## When to use
+
+Use when optimizing slow endpoints, designing caching, or improving query performance.
+
+Do NOT use when:
+- Database schema design (use `database` skill)
+- Queue job creation (use `jobs-events` skill)
+
+## Procedure: Optimize performance
+
+### Step 0: Identify the bottleneck
+
+1. Don't optimize prematurely — measure first.
+2. Use `DB::enableQueryLog()` or Telescope to find slow queries.
+3. Check for N+1 queries on list endpoints.
+4. Search for existing cache services in the project.
+
+### Step 1: Apply the right fix
+
+| Bottleneck | Fix |
+|---|---|
+| N+1 queries | Eager loading with `with()` |
+| Slow queries | Add indexes, optimize (see `database` skill) |
+| Repeated expensive queries | Cache with TTL |
+| Blocking API calls | Queue as background job |
+| Large datasets | Paginate, chunk, cursor |
+| Missing counts | `withCount()` instead of loading relations |
+
+### Step 2: Verify
+
+Re-measure after fix. Check that cache invalidation works correctly.
+
+## Conventions
+
+→ See guideline `php/performance.md` for caching patterns, Redis, response time targets.
+
+## Output format
+
+1. Optimized code with before/after performance comparison
+2. Caching strategy or query optimization applied
+
+## Gotcha
+
+- Cache invalidation bugs are worse than slow queries — don't add caching everywhere.
+- Eager loading N+1 is the #1 win — always check list endpoints.
+- Don't cache Eloquent collections with loaded relations — too large.
+- Always include tenant ID in cache keys (multi-tenant).
+
+## Do NOT
+
+- Do NOT cache without tenant isolation in multi-tenant contexts.
+- Do NOT use `get()` or `all()` on large tables — paginate or chunk.
+- Do NOT add indexes blindly — analyze query patterns first.
+
+## Auto-trigger keywords
+
+- performance
+- caching
+- eager loading
+- query optimization
+- Redis

package/.agent-src/skills/performance-analysis/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: performance-analysis
+description: "ONLY when user explicitly requests: performance audit, bottleneck analysis, or N+1 query detection. NOT for regular feature work."
+source: package
+---
+
+# performance-analysis
+
+## Mission
+
+Find performance bottlenecks before they affect users. This skill is **proactive** — it
+analyzes code for performance issues, not just responds to "it's slow" reports.
+
+For writing performant code patterns (caching, eager loading, Redis), use the `performance` skill.
+For test suite performance, use `test-performance`.
+
+## When to use
+
+Use this skill when:
+
+- Auditing a codebase or flow for performance bottlenecks
+- `analysis-autonomous-mode` routes here after detecting slow patterns
+- Reviewing code that handles large datasets, loops, or external calls
+- Investigating why a specific endpoint or job is slow
+
+Do NOT use when:
+
+- Writing new caching/optimization code → use `performance`
+- Optimizing test suite speed → use `test-performance`
+- Hunting for functional bugs → use `bug-analyzer` (proactive mode)
+
+## Procedure: Performance analysis
+
+### 1. Identify hotspots
+
+Focus on code paths with high execution frequency or large data volumes:
+
+- API endpoints called frequently (list endpoints, dashboards)
+- Queue jobs processing batches
+- Scheduled commands running on large datasets
+- Import/export operations
+- Report generation
+
+### 2. Database query analysis
+
+| Pattern | What to look for |
+|---|---|
+| **N+1 queries** | `->load()` or relationship access in loops, missing `->with()` |
+| **Missing indexes** | `WHERE` clauses on unindexed columns, slow `ORDER BY` |
+| **Full table scans** | `SELECT *` without `WHERE`, `LIKE '%term%'` |
+| **Unnecessary queries** | Same query executed multiple times in one request |
+| **Large result sets** | Loading thousands of models when only counts or IDs are needed |
+| **Missing pagination** | `->get()` on unbounded queries |
+| **Suboptimal joins** | Multiple queries that should be a single JOIN |
+| **Transaction scope** | Transactions holding locks longer than necessary |
+
+### 3. Application-level bottlenecks
+
+| Pattern | What to look for |
+|---|---|
+| **Synchronous I/O** | HTTP calls, file operations, or API calls in the request cycle |
+| **Memory bloat** | Loading entire collections when chunking would work |
+| **Redundant computation** | Same calculation repeated without caching |
+| **Missing cache** | Data that rarely changes but is queried on every request |
+| **Stale cache** | Cache that is never invalidated or has wrong TTL |
+| **Serialization overhead** | Large models serialized to JSON unnecessarily |
+| **Loop inefficiency** | O(n²) patterns with nested loops or repeated array searches |
+
+### 4. Queue and job analysis
+
+- Jobs that should be batched but run individually
+- Missing `chunk()` for large dataset processing
+- Retry storms from failing jobs without backoff
+- Jobs that hold database connections too long
+- Missing `WithoutOverlapping` for idempotency-critical jobs
+
+### 5. Infrastructure-level checks
+
+- Missing Redis for session/cache (using file/database driver)
+- Missing CDN for static assets
+- Missing response caching for read-heavy endpoints
+- Database connection pooling and limits
+- Queue worker concurrency vs database connection limits
+
+## Output format
+
+For each bottleneck:
+
+- **Issue:** concise title
+- **Location:** file, line, or endpoint
+- **Severity:** Low / Medium / High / Critical
+- **Impact:** estimated effect (e.g., "adds ~500ms per request", "causes N+1 on 100+ records")
+- **Evidence:** code reference, query pattern, or measurement
+- **Fix:** concrete optimization
+- **Effort:** Low / Medium / High
+- **Confidence:** Low / Medium / High
+
+## Integration with other skills
+
+- **analysis-autonomous-mode** — routes here when performance concerns are detected
+- **performance** — complementary: performance is about writing fast code, this is about finding slow code
+- **test-performance** — for test suite speed specifically
+- **bug-analyzer** — some performance issues are actually bugs (N+1, infinite loops)
+- **database** — for deep DB optimization guidance
+
+## Gotcha
+
+- Don't present raw numbers without context — "200ms" means nothing without knowing the baseline.
+- The model tends to focus on code-level optimization when the bottleneck is a database query.
+- Profiling in development differs from production — different data volumes, different query plans.
+
+## Do NOT
+
+- Do NOT micro-optimize code that runs infrequently or on small datasets
+- Do NOT recommend caching without considering invalidation
+- Do NOT assume bottlenecks — measure or trace the actual code path
+- Do NOT confuse code style preferences with performance issues
+- Do NOT recommend infrastructure changes when code fixes would suffice

package/.agent-src/skills/pest-testing/SKILL.md

@@ -0,0 +1,321 @@
+---
+name: pest-testing
+description: "Use when writing, generating, or improving Pest tests for Laravel — clear intent, good coverage, maintainable structure, and alignment with project testing conventions."
+source: package
+---
+
+# pest-testing
+
+## When to use
+
+Use this skill for all Laravel testing tasks, especially when working with:
+
+- Feature tests
+- Unit tests
+- API endpoint tests
+- Model tests
+- Service tests
+- Authorization tests
+- Validation tests
+- Database interaction tests
+- Factories, fakes, mocks, and test setup
+
+This skill extends `php-coder`, `laravel`, and `eloquent`.
+
+## Procedure: Write Pest tests
+
+1. **Read the base skills first** — apply `php-coder`, `laravel`, and `eloquent` where relevant.
+2. **Check the project's test framework** — confirm Pest is used and inspect existing tests.
+3. **Match the current test style** — naming, helpers, datasets, expectations, setup, traits, and folder structure.
+4. **Check available factories and seeders** — reuse existing test data patterns.
+5. **Understand the behavior under test** — inspect controllers, services, requests, policies, jobs, and models before writing tests.
+6. **Prefer existing helpers** — authentication helpers, custom assertions, base test classes, and shared setup.
+
+## Core testing principles
+
+- Test behavior, not implementation details.
+- Prefer clear, intention-revealing tests over overly clever abstractions.
+- One test should verify one meaningful behavior.
+- Keep setup minimal and relevant.
+- Favor confidence and maintainability over excessive mocking.
+- Cover happy path, validation failures, authorization failures, and important edge cases.
+
+## TDD workflow (Red-Green-Refactor)
+
+For bug fixes and new features, prefer test-driven development:
+
+1. **RED** — Write a failing test that describes the expected behavior.
+2. **Verify RED** — Run the test, confirm it fails for the expected reason (missing feature,
+   not a typo or syntax error). If the test passes immediately, it tests existing behavior — fix it.
+3. **GREEN** — Write the **minimal** code to make the test pass. No extras, no "while I'm here".
+4. **Verify GREEN** — Run all tests, confirm the new test passes and nothing else broke.
+5. **REFACTOR** — Clean up code while keeping tests green.
+
+### Why test-first matters
+
+Tests written **after** implementation pass immediately. Passing immediately proves nothing:
+- The test might test the wrong thing.
+- The test might test implementation, not behavior.
+- You never saw it catch the bug — so you don't know if it would.
+
+### Bug fix TDD
+
+For every bug fix: write a failing test that reproduces the bug FIRST, then fix it.
+The test proves the fix works AND prevents regression.
+
+### TDD rationalization prevention
+
+| Excuse | Reality |
+|---|---|
+| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
+| "I'll test after" | Tests passing immediately prove nothing. |
+| "Manual test is faster" | Manual doesn't prevent regression. You'll re-test every change. |
+| "Test is hard to write" | Hard to test = hard to use. Simplify the design. |
+| "Need to explore first" | Fine — throw away exploration code, start fresh with TDD. |
+| "Existing code has no tests" | You're improving it. Add tests for what you touch. |
+
+## Laravel testing rules
+
+- Use **Feature tests** for HTTP endpoints, request validation, middleware behavior, authorization, and end-to-end application flow.
+- Use **Unit tests** for isolated services or pure logic when true isolation adds value.
+- Prefer Feature tests over Unit tests when framework integration is part of the behavior.
+- Use `RefreshDatabase` or the project's standard database reset strategy where appropriate.
+- Reuse factories instead of manually creating large fixture arrays.
+
+## Pest style rules
+
+- Write descriptive test names in plain language.
+- Use `it()` / `test()` according to existing project conventions.
+- Group related tests logically.
+- Use datasets when they improve readability and reduce duplication.
+- Keep each test focused and concise.
+
+## Pest-specific PHP rules
+
+- Do NOT use `readonly` or `final` on Pest test classes.
+- Do NOT mark classes `final` if they need to be mocked via `Mockery::mock()`.
+- Pest test files (without a `namespace` declaration) treat all PHP built-in classes as global.
+  Do **NOT** add `use` statements for global classes like `DateTimeImmutable`, `Exception`,
+  `stdClass`, etc. — PHP will warn: *"The use statement with non-compound name has no effect"*.
+- Only `use` statements for **namespaced** classes (e.g., `use App\Models\...`) are needed.
+
+## Avoiding flaky tests
+
+- **Time-dependent tests:** Use `$this->travel(5)->seconds()` (Laravel's time travel) to create
+  a clear gap between "before" and "after" timestamps. Never rely on `now()` being different
+  between two lines of code — on fast hardware, they can be identical.
+- **Database-dependent tests:** Don't assume column values are `null` just because the seeder
+  doesn't set them — previous tests in parallel may have modified the same record.
+- **Parallel testing:** The project may use parallel testing (8+ processes). Avoid relying on
+  global state, specific row counts, or auto-increment IDs.
+
+## HTTP and API tests
+
+- Test:
+    - status codes
+    - response structure
+    - validation errors
+    - authorization behavior
+    - persistence side effects
+- For JSON APIs, assert:
+    - exact relevant fields
+    - error structure when applicable
+    - database state after the request
+- Do not only assert `200` — verify meaningful behavior.
+
+## Validation tests
+
+- Validate important request rules explicitly.
+- Cover required fields, invalid formats, boundary values, and business-critical constraints.
+- Prefer focused validation tests over giant "all fields invalid" tests unless the project already uses that pattern.
+
+## Authorization tests
+
+- Always test protected actions for:
+    - guest users
+    - unauthorized users
+    - authorized users
+- Match the project's auth setup and policy usage.
+- Do not assume authorization works just because a policy exists.
+
+## Database assertions
+
+- Assert persistence effects with:
+    - `assertDatabaseHas`
+    - `assertDatabaseMissing`
+    - relation checks where relevant
+- Keep assertions focused on meaningful fields.
+- Do not assert every column unless necessary.
+
+## Snapshot testing with `coduo/php-matcher`
+
+This project uses [`coduo/php-matcher`](https://github.com/coduo/php-matcher) for flexible snapshot assertions.
+Pattern files live in `snapshots/` directories next to the test files.
+
+### Pattern variables
+
+Use pattern variables instead of hardcoded values in snapshot files.
+This makes snapshots resilient to data changes while still enforcing type correctness.
+
+| Pattern | Matches | Example |
+|---|---|---|
+| `@boolean@` | `true` or `false` | `'is_active' => '@boolean@'` |
+| `@integer@` | Any integer | `'id' => '@integer@'` |
+| `@string@` | Any string | `'name' => '@string@'` |
+| `@null@` | `null` | `'deleted_at' => '@null@'` |
+| `@datetime@` | ISO datetime string | `'created_at' => '@datetime@'` |
+| `@uuid@` | UUID string | `'uuid' => '@uuid@'` |
+| `@array@` | Any array | `'items' => '@array@'` |
+| `@double@` | Any float | `'amount' => '@double@'` |
+| `@wildcard@` | Anything | `'data' => '@wildcard@'` |
+
+Combine with `||` for nullable fields: `'deleted_at' => '@null@||@datetime@'`
+
+### Rules
+
+- **Never hardcode dynamic values** (IDs, timestamps, UUIDs) in snapshots — use pattern variables or `$replacements`.
+- **Never hardcode boolean defaults** (e.g., `false`) when other booleans in the same file use `@boolean@` — be consistent.
+- Use `$variable ?? '@pattern@'` syntax to allow test-specific overrides via `replacements` parameter.
+- Use `PhpMatcherHelper::ruleBackedEnum(EnumClass::class, 'string')` for enum fields.
+
+### Example snapshot file
+
+```php
+// snapshots/user-resource.php
+return [
+    'id' => $id ?? '@integer@',
+    'name' => $name ?? '@string@',
+    'email' => $email ?? '@string@',
+    'is_active' => $is_active ?? '@boolean@',
+    'created_at' => $created_at ?? '@datetime@',
+    'deleted_at' => $deleted_at ?? '@null@||@datetime@',
+];
+```
+
+### Example test usage
+
+```php
+expect($response->json())
+    ->toMatchPhpPatternFile(
+        patternFile: __DIR__ . '/snapshots/user-resource.php',
+        replacements: ['id' => $user->getId()],
+    );
+```
+
+## Fakes, mocks, and external boundaries
+
+- Use Laravel fakes for framework integrations when appropriate:
+    - `Queue::fake()`
+    - `Bus::fake()`
+    - `Event::fake()`
+    - `Mail::fake()`
+    - `Notification::fake()`
+    - `Storage::fake()`
+- Mock only true external boundaries or expensive dependencies.
+- Avoid mocking internal application code unless isolation is necessary for the specific test.
+
+## Factories and fixtures
+
+- Prefer factories with explicit state over large inline setup.
+- Use named states for meaningful scenarios.
+- Keep test data realistic and minimal.
+- Do not create unnecessary records.
+
+## Test quality analysis
+
+When reviewing or auditing existing tests, check for these anti-patterns:
+
+### Test smells to detect
+
+| Smell | Description | Fix |
+|---|---|---|
+| **Overmocking** | Too many mocks disconnect the test from reality | Replace mocks with real implementations or fakes |
+| **Fragile tests** | Tests break with unrelated changes (e.g., asserting exact JSON structure) | Assert only meaningful fields |
+| **Flaky tests** | Non-deterministic results (time, ordering, parallel state) | Use time travel, explicit ordering, isolated data |
+| **Giant tests** | One test covers 5+ behaviors | Split into focused tests |
+| **Missing assertions** | Test runs code but doesn't verify outcomes | Add meaningful assertions |
+| **Test duplication** | Same scenario tested in multiple places | Consolidate or use datasets |
+| **Assertion roulette** | Many assertions without clear failure messages | Use named assertions or split tests |
+| **Eager test** | Tests too many things, making failures hard to diagnose | One behavior per test |
+
+### FIRST principles
+
+- **Fast** — Tests should run quickly. Avoid unnecessary DB operations.
+- **Isolated** — Tests should not depend on each other or shared state.
+- **Repeatable** — Same result every time, regardless of environment or order.
+- **Self-validating** — Pass or fail, no manual inspection needed.
+- **Timely** — Written close to the code they test.
+
+### Mock usage guidelines
+
+- Mock **external boundaries** (APIs, file systems, third-party services).
+- Use Laravel fakes (`Queue::fake()`, `Http::fake()`) over manual mocks.
+- Do NOT mock the class under test.
+- Do NOT mock value objects or DTOs.
+- If a test needs 3+ mocks, consider testing at a higher level (Feature test).
+
+## What NOT to do
+
+- Do not test private methods directly.
+- Do not over-mock Laravel internals.
+- Do not assert implementation details when behavior assertions are enough.
+- Do not write brittle tests tied to formatting or irrelevant response noise.
+- Do not create giant tests that cover many behaviors at once.
+- Do not skip authorization or validation coverage for important endpoints.
+
+## Output expectations
+
+When generating Pest tests:
+
+- follow the existing folder and naming conventions
+- test behavior clearly and directly
+- cover success, failure, and authorization paths
+- use factories and Laravel test helpers
+- assert both response and side effects where relevant
+- keep tests readable, isolated, and maintainable
+
+
+## Output format
+
+1. Pest test file with descriptive test names and clear assertions
+2. Tests organized by happy path, validation, edge cases
+
+## Gotcha
+
+- Don't use `readonly` or `final` on Pest test helper classes — it breaks mocking.
+- Don't add `use` statements for global classes (`Exception`, `DateTimeImmutable`) in Pest files — they're auto-imported.
+- The model forgets `$this->travel(5)->seconds()` for time-dependent tests — never rely on `now()` differing between lines.
+- Parallel tests share the database — don't assume column values are null unless you explicitly set them.
+
+## Do NOT
+
+- Do NOT mark classes final if they need to be mocked via Mockery.
+- Do NOT use PHPUnit class-based syntax — use Pest syntax.
+
+## What to test (generation checklist)
+
+When generating new tests, focus on:
+- **Business logic**: calculations, status transitions, validation rules, data transformations
+- **Edge cases**: null, empty string, zero, negative numbers, boundary values, max length
+- **Error paths**: invalid input, missing dependencies, exception handling
+- **Different code branches**: if/else, early returns, fallback behavior
+
+What NOT to test:
+- Trivial getters/setters without logic
+- Parameter counts, method existence, class names
+- Framework internals (Eloquent, routing)
+- Private methods directly — test through public API
+
+**Quality over quantity** — 5 meaningful tests beat 20 trivial ones.
+
+## Auto-trigger keywords
+
+- Pest test
+- PHPUnit
+- test writing
+- test quality
+- TDD
+- generate tests
+- write tests
+- test coverage
+- test scenarios