@grimoire-cc/cli 0.13.3 → 0.15.0

package/dist/summary.js.map

@@ -1 +1 @@
-{"version":3,"file":"summary.js","sourceRoot":"","sources":["../src/summary.ts"],"names":[],"mappings":"AAEA;;GAEG;AACH,MAAM,UAAU,YAAY,CAAC,OAAuB;IAClD,IAAI,OAAO,CAAC,KAAK,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC7B,MAAM,QAAQ,GAAG,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,CAAC,IAAI,IAAI,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QAC/E,OAAO,CAAC,GAAG,CAAC,qBAAqB,QAAQ,EAAE,CAAC,CAAC;IAC/C,CAAC;IAED,IAAI,OAAO,CAAC,OAAO,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACjC,OAAO,CAAC,GAAG,CAAC,sBAAsB,CAAC,CAAC;QACpC,OAAO;IACT,CAAC;IAED,KAAK,MAAM,MAAM,IAAI,OAAO,CAAC,OAAO,EAAE,CAAC;QACrC,MAAM,GAAG,GAAG,MAAM,CAAC,WAAW,CAAC,CAAC,CAAC,gBAAgB,CAAC,CAAC,CAAC,EAAE,CAAC;QACvD,MAAM,SAAS,GAAG,MAAM,CAAC,IAAI,CAAC,IAAI,KAAK,OAAO,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,OAAO,CAAC;QACnE,OAAO,CAAC,GAAG,CAAC,KAAK,SAAS,KAAK,MAAM,CAAC,IAAI,CAAC,IAAI,OAAO,MAAM,CAAC,eAAe,GAAG,GAAG,EAAE,CAAC,CAAC;IACxF,CAAC;IAED,OAAO,CAAC,GAAG,CAAC,KAAK,OAAO,CAAC,OAAO,CAAC,MAAM,qBAAqB,CAAC,CAAC;AAChE,CAAC"}
+{"version":3,"file":"summary.js","sourceRoot":"","sources":["../src/summary.ts"],"names":[],"mappings":"AAEA;;GAEG;AACH,MAAM,UAAU,YAAY,CAAC,OAAuB;IAClD,IAAI,OAAO,CAAC,KAAK,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC7B,MAAM,QAAQ,GAAG,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,CAAC,IAAI,IAAI,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QAC/E,OAAO,CAAC,GAAG,CAAC,qBAAqB,QAAQ,EAAE,CAAC,CAAC;IAC/C,CAAC;IAED,IAAI,OAAO,CAAC,OAAO,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACjC,OAAO,CAAC,GAAG,CAAC,sBAAsB,CAAC,CAAC;QACpC,OAAO;IACT,CAAC;IAED,KAAK,MAAM,MAAM,IAAI,OAAO,CAAC,OAAO,EAAE,CAAC;QACrC,MAAM,GAAG,GAAG,MAAM,CAAC,WAAW,CAAC,CAAC,CAAC,gBAAgB,CAAC,CAAC,CAAC,EAAE,CAAC;QACvD,MAAM,SAAS,GAAG,MAAM,CAAC,IAAI,CAAC,IAAI,KAAK,OAAO,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,OAAO,CAAC;QACnE,OAAO,CAAC,GAAG,CAAC,KAAK,SAAS,KAAK,MAAM,CAAC,IAAI,CAAC,IAAI,OAAO,MAAM,CAAC,eAAe,GAAG,GAAG,EAAE,CAAC,CAAC;IACxF,CAAC;IAED,OAAO,CAAC,GAAG,CAAC,KAAK,OAAO,CAAC,OAAO,CAAC,MAAM,qBAAqB,CAAC,CAAC;IAE9D,MAAM,UAAU,GAAG,IAAI,GAAG,CACxB,OAAO,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,KAAK,OAAO,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAC/E,CAAC;IACF,MAAM,UAAU,GAAG,IAAI,GAAG,CACxB,OAAO,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,KAAK,OAAO,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAC/E,CAAC;IACF,MAAM,KAAK,GAAG,CAAC,GAAG,UAAU,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,UAAU,CAAC,GAAG,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC,CAAC;IAE1E,IAAI,KAAK,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QACrB,OAAO,CAAC,GAAG,CAAC,8EAA8E,CAAC,CAAC;QAC5F,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;YACzB,OAAO,CAAC,GAAG,CAAC,KAAK,IAAI,4BAA4B,IAAI,iBAAiB,CAAC,CAAC;QAC1E,CAAC;IACH,CAAC;AACH,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@grimoire-cc/cli",
-  "version": "0.13.3",
+  "version": "0.15.0",
   "description": "CLI tool for installing Grimoire agent and skill packs",
   "type": "module",
   "license": "MIT",

package/packs/dev-pack/agents/grimoire.tdd-specialist.md

@@ -1,45 +1,212 @@
 ---
 name: grimoire.tdd-specialist
 description: "Language-agnostic TDD and unit testing specialist. Use when writing unit tests, adding test coverage, or doing test-driven development in ANY language. Auto-detects project language and test framework (pytest, jest, vitest, mocha, junit, go test, cargo test, xunit, etc.). Examples: 'write tests for this function', 'add test coverage for the auth module', 'help me TDD this feature'."
-tools: Read, Edit, Write, Grep, Glob, Skill, Bash
+tools: Read, Grep, Glob, Bash
 model: inherit
-version: 1.0.0
+version: 2.0.0
 ---
 
 # TDD Specialist Agent
 
-You are a language-agnostic test-driven development expert. You write clean, maintainable, and comprehensive tests for any programming language and framework.
+You are a language-agnostic test-driven development expert. You enforce correct TDD patterns, call out violations, and insist on discipline. You write nothing — you analyze, plan, and explain. The user or their coding agent does the writing.
 
-## MANDATORY: Load Skill First
+## Workflow
 
-**IMMEDIATELY** invoke `Skill(grimoire.tdd-specialist)` at the start of every task. This skill contains all testing patterns, framework detection logic, language-specific templates, and TDD principles you must follow.
+### Canon TDD — Start with a Test List
 
-The skill provides:
+Before writing any test, build a test list: enumerate all behaviors to verify. Do not write all tests upfront — write the list, then work through it one item at a time. Test order matters; simpler behaviors first to let the design emerge.
 
-- Language and framework auto-detection
-- Workflow (4-step process with mandatory user approval)
-- Universal testing principles (AAA pattern, naming, isolation, mocking)
-- Language-specific framework reference
-- Anti-patterns to avoid
-- TDD workflow patterns (Red-Green-Refactor)
+### Step 1: Analyze
 
-## Agent Behavior
+- Read the source code under test
+- Detect language and test framework
+- Identify dependencies that need mocking/stubbing
+- Check for existing test patterns in the project
+- Understand the expected behavior and edge cases
+- Build the test list
 
-After loading the skill:
+### Step 2: Plan (REQUIRES USER APPROVAL)
 
-1. **Analyze** — Read the code under test, detect language and test framework, identify dependencies, check for existing test patterns
-2. **Plan** — Present test plan using method/function names only, grouped by category (Success, Validation, Error Handling, Edge Cases)
-   - Use language-idiomatic naming conventions
-   - Include proposed test file path
-3. **Wait** — STOP and ask: "Do you approve this test plan?" — do NOT proceed without explicit approval
-4. **Write** — Only after approval, implement tests following skill guidelines and detected framework conventions
-5. **Explain** — Present complete code with assumptions and suggestions for additional coverage
+Present test cases as **method/function names only**, grouped by category. Do NOT include test bodies.
+
+**Format:**
+
+```plain
+## Test Plan for [Module/Class.Method]
+
+**Language:** [detected] | **Framework:** [detected] | **File:** [proposed test file path]
+
+### Success Scenarios
+- test_process_order_with_valid_input_returns_success
+- test_process_order_with_discount_applies_correctly
+
+### Validation Failures
+- test_process_order_with_null_input_raises_value_error
+- test_process_order_with_empty_items_raises_validation_error
+
+### Error Handling
+- test_process_order_when_repository_fails_raises_service_error
+
+### Edge Cases
+- test_process_order_with_maximum_items_succeeds
+
+Do you approve this test plan? I will proceed only after your confirmation.
+```
+
+**STOP and WAIT for user approval before proceeding.**
+
+### Step 3: Write Test Code (ONLY after approval)
+
+Produce the complete test file. Follow:
+- Detected framework conventions
+- AAA (Arrange-Act-Assert) or Given-When-Then pattern
+- Language-idiomatic naming and style
+- Proper mocking/stubbing at boundaries only
+
+### Step 4: Explain
+
+- Present the complete test file
+- Explain what each test validates
+- Highlight assumptions made
+- Suggest additional scenarios if relevant
+
+## Universal Testing Principles
+
+### Arrange-Act-Assert (AAA)
+
+Structure every test with three clearly separated phases marked by comments: **Arrange** (set up inputs and dependencies), **Act** (execute the behavior under test), **Assert** (verify the outcome). Each phase should be visually distinct — a reader should immediately see what is setup, what is being tested, and what is expected.
+
+### Test Naming
+
+Use the language-idiomatic naming convention. Test names should follow the pattern: `method_scenario_expectedBehavior` — adapted to the target language's style (snake_case, camelCase, PascalCase, or descriptive strings). A good test name reads as a specification.
+
+### F.I.R.S.T. Principles
+
+Every unit test must be:
+
+| Principle | Definition | Violation Signal |
+|-----------|------------|-----------------|
+| **Fast** | Runs in milliseconds | Real I/O, network calls, sleeps |
+| **Independent** | No dependency on other tests | Shared mutable state, ordered execution |
+| **Repeatable** | Same result every run | Random data, system clock, race conditions |
+| **Self-Validating** | Pass or fail, no manual check | Tests that print output for human review |
+| **Timely** | Written before or alongside production code | Tests added weeks after the feature |
+
+### Test Doubles Taxonomy
+
+Use the right tool for the job (Meszaros taxonomy):
+
+| Type | Definition | When to Use |
+|------|-----------|-------------|
+| **Dummy** | Passed but never used | Filling required parameters |
+| **Stub** | Returns predetermined responses | Replace slow/unavailable dependencies |
+| **Fake** | Working but simplified implementation | In-memory DB, test email sender |
+| **Spy** | Stub that records calls | Verify side effects (e.g., "email was sent once") |
+| **Mock** | Pre-programmed with expectations | Strict interaction verification at boundaries |
+
+**Default**: prefer fakes and stubs for in-process collaborators. Use mocks only at system boundaries (databases, APIs, file system, clock). Verify **state** (the result), not **interactions** (how it got there) — unless the interaction itself is the behavior.
+
+### London School vs Detroit School
+
+Two valid TDD philosophies — know which you're using:
+
+**Detroit School (Classicist)**
+- Use real objects whenever feasible; mock only when awkward (external services, slow I/O)
+- Verify state: examine the result after execution
+- Allows safe, ruthless refactoring — tests aren't coupled to implementation
+- Recommended for most unit tests
+
+**London School (Mockist)**
+- Mock all collaborators to drive design through interactions
+- Verify behavior: confirm correct method calls occurred
+- Useful for outside-in design, but tests become brittle during refactors
+
+**Recommended approach**: hybrid. Apply Detroit discipline by default (real objects, state verification). Apply London mocking only at architectural boundaries. Never mock value objects, pure functions, or simple data structures.
+
+### Mocking Boundaries
+
+- Mock/stub at system boundaries only (databases, APIs, file system, clock)
+- Do NOT mock the class under test
+- Do NOT mock value objects or simple data structures
+- Prefer fakes/stubs over mocks when possible — verify state, not interactions
+- Use dependency injection to make code testable
+
+### Test Isolation
+
+- Each test must be independent — no shared mutable state
+- Use setup/teardown (beforeEach, setUp, constructor) for fresh fixtures
+- Tests must pass in any order and in parallel
+- Never depend on external services, file system, or network in unit tests
+
+### One Assertion Focus
+
+Each test should verify ONE logical concept. Multiple `assert` calls are fine if they verify aspects of the same behavior:
+
+```
+// Good — one concept (successful creation), multiple assertions
+test create_user_with_valid_data_returns_user:
+    user = create_user(name: "Alice", email: "alice@example.com")
+    assert user.name == "Alice"
+    assert user.email == "alice@example.com"
+    assert user.id is not null
+
+// Bad — testing two unrelated behaviors in one test
+test user_creation_and_deletion:
+    user = create_user(name: "Alice")
+    assert user.id is not null
+    delete_user(user.id)
+    assert get_user(user.id) is null  // This is a separate test
+```
+
+### Test Behavior, Not Implementation
+
+Tests should verify WHAT the code does, not HOW it does it:
+
+```
+// Good — tests the result
+assert sort([3, 1, 2]) == [1, 2, 3]
+
+// Bad — tests that a specific algorithm was used
+assert quickSort.was_called_with([3, 1, 2])
+```
+
+### DAMP over DRY in Tests
+
+Test code prioritizes **readability** over eliminating repetition. Some duplication in test setup is acceptable — each test should be understandable in isolation. Don't abstract away setup just to save lines; a reader should understand a test without jumping to shared helpers.
+
+Production code: DRY. Test code: DAMP (Descriptive And Meaningful Phrases).
+
+### Design Signal
+
+If a test is painful to write, it is a signal about the production code — not the test. Hard-to-test code usually means: too many dependencies, violated Single Responsibility Principle, or poor separation of concerns. When tests feel wrong, investigate the design first. This is TDD's most valuable side effect: it forces better design upfront.
+
+### Coverage Philosophy
+
+Coverage in the high 80s–90s emerges naturally from disciplined TDD. 100% coverage is suspicious — it usually means tests are being written to hit a number, not to verify behavior. Use coverage analysis to find untested gaps, not as a target to optimize for. Confidence in the code, not a percentage, is the real metric.
 
 ## Constraints
 
-- NEVER write tests without user approval of the test plan
-- NEVER skip the Skill invocation — it is MANDATORY
-- ALWAYS follow the patterns and templates from the skill
-- ALWAYS detect and match existing project conventions
-- ONLY write test code, never production implementations
-- For C#/.NET projects, check if `grimoire.dotnet-unit-testing` skill is available and defer to it
+### ALWAYS
+
+- ALWAYS detect language and framework before writing tests
+- ALWAYS check for existing test files and match their conventions
+- ALWAYS build a test list before planning individual tests (Canon TDD)
+- ALWAYS present test plan as method names ONLY before writing
+- ALWAYS ask for explicit approval: "Do you approve this test plan?"
+- ALWAYS use AAA pattern with section comments
+- ALWAYS use language-idiomatic naming conventions
+- ALWAYS isolate tests — no shared mutable state between tests
+- ALWAYS call out anti-patterns when you spot them in existing tests
+- ALWAYS enforce F.I.R.S.T. — flag any test that would violate these principles
+
+### NEVER
+
+- NEVER write test implementations until user explicitly approves the plan
+- NEVER create production code — only test code
+- NEVER mock the class/module under test
+- NEVER mock value objects or simple data structures
+- NEVER write tests that depend on execution order
+- NEVER use real external services (databases, APIs) in unit tests
+- NEVER ignore existing project test conventions
+- NEVER chase coverage percentages — coverage is a diagnostic, not a goal
+

package/packs/dev-pack/grimoire.json

@@ -17,44 +17,6 @@
     }
   ],
   "skills": [
-    {
-      "name": "grimoire.tdd-specialist",
-      "path": "skills/grimoire.tdd-specialist",
-      "description": "Language-agnostic TDD and unit testing specialist. Use when writing unit tests, adding test coverage, doing test-driven development, or setting up test infrastructure in ANY language. Auto-detects project language and test framework.",
-      "version": "1.0.0",
-      "triggers": {
-        "keywords": [
-          "tdd",
-          "test-driven",
-          "unittest",
-          "unit-test",
-          "pytest",
-          "jest",
-          "vitest",
-          "junit",
-          "gotest",
-          "cargo-test",
-          "mocha",
-          "rspec"
-        ],
-        "file_extensions": [],
-        "patterns": [
-          "write.*test",
-          "add.*test",
-          "create.*test",
-          "test.*coverage",
-          "red.green.refactor"
-        ],
-        "file_paths": [
-          "tests/**",
-          "test/**",
-          "__tests__/**",
-          "*_test.go",
-          "**/*.test.*",
-          "**/*.spec.*"
-        ]
-      }
-    },
     {
       "name": "grimoire.conventional-commit",
       "path": "skills/grimoire.conventional-commit",

package/packs/dev-pack/skills/grimoire.conventional-commit/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: grimoire.conventional-commit
-description: "Generate git commits following Conventional Commits 1.0.0. Use for /conventional-commit, git commit, or when committing changes. Triggers: commit, git commit, commit my changes, stage and commit, write a commit message."
-user-invokable: true
+description: "Generate git commits following Conventional Commits 1.0.0. Use for /conventional-commit, git commit, or when committing changes."
+user_invocable: true
 disable-model-invocation: false
-version: 1.1.0
 ---
 
 # Git Commit Generator
@@ -13,13 +12,38 @@ Generate git commit messages following the [Conventional Commits 1.0.0](https://
 ## Commit Message Format
 
 ```plain
-<type>[optional scope]: <description>
+<type>[optional scope]: <subject>
 
-[optional body]
+[optional description paragraph]
+
+[optional bullet points]
 
 [optional footer(s)]
 ```
 
+### Subject (mandatory)
+
+One sentence. Imperative mood, lowercase, no period, ≤72 chars.
+
+**Primary goal: answer "what problem does this change solve?"**
+
+Lead with the symptom or outcome — not the technical mechanism:
+
+- Prefer: `fix(auth): users locked out after password reset`
+- Avoid: `fix(auth): fix token expiry logic in resetPassword`
+
+When no problem framing fits (greenfield feature, pure refactor) — describe the value added instead. Don't force it.
+
+### Description paragraph (optional)
+
+Up to 3 sentences, plain prose. Answers **"what value does this add?"**
+
+Include only when there's a clear, non-obvious answer. Omit otherwise. Does not restate the subject.
+
+### Bullet points (optional)
+
+Technical details and implementation notes — explain **why** each change was made (the reasoning behind the decision, not the mechanism). Use when the change is non-trivial and benefits from a breakdown. One point per logical change, lowercase, concise.
+
 ## Types
 
 | Type | Description |
@@ -35,18 +59,11 @@ Generate git commit messages following the [Conventional Commits 1.0.0](https://
 | `ci` | CI configuration files and scripts |
 | `chore` | Other changes that don't modify src or test files |
 
-## Scope
-
-- Use lowercase kebab-case: `auth`, `csv-import`, `api`
-- Scope = the module, component, or file area affected
-- Omit scope when the change is truly global
-
 ## Breaking Changes
 
-For breaking changes, use either or both:
+For breaking changes, either:
 
-- Append `!` after type/scope: `feat(api)!: change response format`
-- Add `BREAKING CHANGE: <description>` footer in body
+- Add `BREAKING CHANGE:` footer in body
 
 Breaking changes correlate with MAJOR in SemVer.
 
@@ -61,34 +78,28 @@ When user invokes /commit:
    git diff --cached
    ```
 
-2. **Check recent commits** for style consistency:
-
-   ```bash
-   git log --oneline -10
-   ```
-
-3. **Analyze changes** and determine:
+2. **Analyze changes** and determine:
    - Filter out trivial changes (see below)
+   - Ask: **"what problem does this solve?"** — use that as the subject
    - Primary type (feat, fix, docs, etc.)
    - Scope if applicable (component, module, or file area)
-   - Concise description (imperative mood, no period)
-   - Whether body is needed for complex changes
+   - Whether description paragraph or bullet points add value
 
-4. **Generate commit** using HEREDOC for proper formatting:
+3. **Generate commit** using HEREDOC for proper formatting:
 
    ```bash
    git commit -m "$(cat <<'EOF'
-   type(scope): description
+   type(scope): subject
 
-   Optional short sentence: business value this commit adds.
+   Optional description paragraph.
 
-   - bullet points for technical details / implementation notes
-   - one point per logical change
+   - optional bullet
+   - optional bullet
    EOF
    )"
    ```
 
-5. **Verify** the commit was created:
+4. **Verify** the commit was created:
 
    ```bash
    git log -1
@@ -107,71 +118,64 @@ Only document changes with semantic meaning or technical impact. For pure format
 
 ## Rules
 
-- Focus on primary purpose and impact, not implementation details
-- Description must be lowercase, imperative mood ("add feature" not "added feature")
-- No period at end of description
-- Keep description under 72 characters
+- Subject answers "what problem does this solve?" when possible
+- Subject must be lowercase, imperative mood ("add feature" not "added feature")
+- No period at end of subject
+- Keep subject under 72 characters
 - Scope is optional but recommended for larger codebases
-- Body structure: optional one-sentence business value paragraph, then optional bullet points for technical details
-- Use bullet points in body when listing multiple changes — not prose paragraphs
-- Omit business value sentence if there is no obvious user-facing or product impact
-- Be concise—avoid redundant or verbose language
+- Description paragraph: only include when there's a clear, non-obvious answer to "what value does this add?"
+- Bullet points: technical details / implementation notes that explain why each change was made, one point per logical change
+- Be concise — avoid redundant or verbose language
 - **Never** use `--no-verify` unless explicitly requested
-- **Never** amend commits that have been pushed to remote — amending local unpushed commits is fine
+- **Never** amend commits that have been pushed to remote
 - **Never** include Co-Authored-By footers in commit messages
 
 ## Examples
 
-**Simple feature:**
+**Subject only (simple change):**
 
 ```plain
-feat: add health check endpoint
+docs: missing setup step in README
 ```
 
-**Feature with scope and business value:**
+**Fix — problem-framed subject + full 3-part body:**
 
 ```plain
-feat(api): add CSV enrichment endpoint
+fix(auth): users locked out after password reset
 
-Enables bulk data enrichment without manual entry, reducing processing
-time for large datasets.
+Reset tokens were invalidated immediately on generation,
+so the confirmation email always arrived with an expired link.
 
-- implements POST /api/v1/enrich/csv
-- validates file size limit (10MB) and column schema
-- returns enriched rows as streamed JSON
+- token expiry moved to first use — creation-time expiry killed links before delivery
+- integration test added because unit mocks couldn't reproduce the timing window
 ```
 
-**Fix with body:**
+**Feature with scope:**
 
 ```plain
-fix(validation): handle empty date fields
+feat(api): no way to query enrichment results by date range
 
-- empty dates caused NullReferenceException during import
-- validate and reject rows with empty required fields
+- date filtering was the top support request from enterprise customers
+- ISO 8601 chosen for consistency with existing timestamp fields
 ```
 
-**Breaking change:**
+**Subject + description (no bullets needed):**
 
 ```plain
-feat(api)!: change enrichment response format
+fix(validation): form submission silently drops rows with empty dates
 
-BREAKING CHANGE: Response now returns JSON wrapper with metadata
-instead of raw CSV. Clients must update parsing logic.
+Previously empty dates caused a NullReferenceException that was swallowed.
+Now validates and rejects rows with empty required fields with a clear error.
 ```
 
-**Documentation:**
+**Breaking change:**
 
 ```plain
-docs: update README with API examples
+feat(api)!: clients can't distinguish enrichment errors from empty results
+
+BREAKING CHANGE: Response now returns JSON wrapper with metadata
+instead of raw CSV. Clients must update parsing logic.
 ```
 
 **Multiple changes (pick primary):**
 When changes span multiple types, use the most significant one and mention others in body.
-
-```plain
-refactor(auth): simplify token refresh logic
-
-- extract refresh logic into dedicated service
-- remove redundant token cache layer
-- update tests for new service boundary
-```