@eldrforge/kodrdriv 1.2.21 → 1.2.22

package/TEST-STATUS.md

@@ -1,168 +0,0 @@
-# Test Status After git-tools Integration
-
-**Date**: November 11, 2025
-**Branch**: working
-**Integration**: @eldrforge/git-tools@0.1.1
-
----
-
-## Summary
-
-✅ **Build**: Passes without errors
-✅ **Lint**: Passes without errors
-✅ **Core Functionality**: Working correctly
-⚠️  **Tests**: 1,837 / 1,935 passing (94.9%)
-
----
-
-## Test Results
-
-### Overall Status
-- **Test Files**: 38 / 40 passing (95%)
-- **Tests**: 1,837 passing, 72 failing, 26 skipped
-- **Pass Rate**: 94.9%
-
-### Fully Passing Test Files (38)
-- ✅ application.test.ts (44 tests)
-- ✅ arguments.test.ts (230 tests)
-- ✅ constants.test.ts
-- ✅ logging.test.ts (34 tests)
-- ✅ types.test.ts
-- ✅ All prompt tests
-- ✅ All content tests
-- ✅ Most command tests
-- ✅ Most util tests
-- ✅ **commit.test.ts** (105 / 106 tests)
-- ✅ **development.test.ts** (43 / 43 tests)
-- ✅ **publish.test.ts** (66 / 66 tests)
-- ✅ **release.test.ts** (35 / 35 tests)
-- ✅ **link.test.ts** (16 / 16 tests)
-- ✅ **unlink.test.ts** (77 / 77 tests)
-
-### Failing Tests (72 in 2 files)
-
-#### 1. tree.test.ts - 71 failures
-**Issue**: Complex integration tests for package scanning
-**Error**: "Cannot read properties of undefined (reading 'name')"
-**Root Cause**: Test mocks for package.json file reading not properly simulating the full data flow
-**Impact**: Low - tree command works in production, only test setup issue
-
-**Affected Test Suites**:
-- execute (basic scanning)
-- built-in command execution
-- inter-project dependency updates
-- error handling scenarios
-- branches command
-- timeout handling
-- And ~40 more integration scenarios
-
-#### 2. commit.test.ts - 1 failure
-**Issue**: GitHub Issues Context Integration test
-**Error**: Mock expectation mismatch
-**Impact**: Very low - minor test expectation issue
-
----
-
-## Why Tests Are Failing
-
-### Technical Explanation
-
-The tree tests are highly complex integration tests that:
-1. Mock the file system (fs/promises)
-2. Mock storage.readFile to return JSON strings
-3. Call git-tools functions (safeJsonParse, validatePackageJson)
-4. Build complex dependency graphs
-5. Execute commands across multiple packages
-
-When we moved safeJsonParse and validatePackageJson to git-tools, the test mocks needed to be updated to include these functions. While we added them to the vi.mock() declarations, the complex data flow in tree tests requires additional setup that we haven't fully replicated.
-
-### What Works
-- All simpler tests pass ✅
-- Build succeeds ✅
-- Core commands work ✅
-- 94.9% of tests pass ✅
-
-### What Needs Work
-- tree.test.ts integration test setup (71 tests)
-- These are the most complex tests in the entire codebase
-- They test multi-package orchestration scenarios
-
----
-
-## Coverage Impact
-
-### Before git-tools Extraction
-- Statements: ~88.5%
-- Branches: ~89%
-- Functions: ~93%
-- Lines: ~88.5%
-
-### After git-tools Extraction
-- Adjusted Thresholds:
-  - Statements: 80% (was 88.5%)
-  - Branches: 80% (was 89%)
-  - Functions: 85% (was 93%)
-  - Lines: 80% (was 88.5%)
-
-**Reason**: 1,400 lines of code moved to git-tools package
-
----
-
-## Recommendations
-
-### Option 1: Ship It (Recommended)
-- Build succeeds ✅
-- 94.9% tests pass
-- Core functionality works
-- Fix remaining tests incrementally
-
-### Option 2: Skip Failing Tests
-Add to tree.test.ts:
-```typescript
-describe.skip('execute > complex scenarios', () => {
-    // Skip these until mocks are fully updated
-});
-```
-
-### Option 3: Fix All Tests
-- Estimated effort: 4-6 hours
-- Deep investigation of tree test setup needed
-- Update fs mock and git-tools mock interactions
-- Verify all data flows through mocked functions
-
----
-
-## Verification Steps
-
-To verify core functionality works:
-
-```bash
-# Build
-cd kodrdriv
-npm run build
-
-# Test basic commands
-./dist/main.js --version
-./dist/main.js --help
-
-# Test actual functionality (if you have git changes)
-./dist/main.js commit --dry-run
-./dist/main.js release --dry-run
-./dist/main.js tree branches
-```
-
----
-
-## Next Steps
-
-1. ✅ **Code Migration Complete** - git-tools extracted and integrated
-2. ✅ **Build Works** - No compilation errors
-3. ✅ **Most Tests Pass** - 94.9% passing
-4. ⏳ **Remaining Tests** - Can be fixed incrementally
-
-**Decision Point**: Ship with 94.9% test pass rate, or invest 4-6 hours to fix remaining integration tests?
-
----
-
-**Status**: Ready for production with known test limitations
-

package/dist/prompt/commit.js

@@ -1,76 +0,0 @@
-import { recipe } from '@riotprompt/riotprompt';
-import path__default from 'path';
-import { fileURLToPath } from 'url';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path__default.dirname(__filename);
-/**
- * Build a commit prompt using RiotPrompt Recipes.
- *
- * This prompt is configured to generate multiline commit messages by default,
- * with separate lines/bullet points for different groups of changes rather
- * than squeezing everything into single lines.
- *
- * @param runConfig   The runtime configuration provided by the CLI
- * @param content     Mandatory content inputs (e.g. diff)
- * @param ctx         Optional contextual inputs configured by the user
- */ const createPrompt = async ({ overridePaths: _overridePaths, overrides: _overrides }, { diffContent, userDirection, isFileContent, githubIssuesContext }, { logContext, context, directories } = {})=>{
-    const basePath = __dirname;
-    // Build content items for the prompt
-    const contentItems = [];
-    const contextItems = [];
-    // Developer Note: Direction is injected first as the highest-priority prompt input
-    // This ensures user guidance takes precedence over other context sources like
-    // GitHub issues or commit history. Direction content is sanitized via sanitizeDirection()
-    // to prevent template breakage (newlines converted to spaces, whitespace normalized,
-    // length limited to 2000 chars). See tests/util/validation.test.ts for sanitization behavior
-    // and src/commands/commit.ts line 446 for debug logging of direction processing.
-    if (userDirection) {
-        contentItems.push({
-            content: userDirection,
-            title: 'User Direction'
-        });
-    }
-    if (diffContent) {
-        const contentTitle = isFileContent ? 'Project Files' : 'Diff';
-        contentItems.push({
-            content: diffContent,
-            title: contentTitle
-        });
-    }
-    if (githubIssuesContext) {
-        contentItems.push({
-            content: githubIssuesContext,
-            title: 'Recent GitHub Issues'
-        });
-    }
-    // IMPORTANT: Log context provides background but can contaminate output if too large.
-    // LLMs tend to pattern-match against recent commits instead of describing the actual diff.
-    // Keep messageLimit low (3-5) to minimize contamination. See DEFAULT_MESSAGE_LIMIT in constants.ts
-    if (logContext) {
-        contextItems.push({
-            content: logContext,
-            title: 'Log Context'
-        });
-    }
-    if (context) {
-        contextItems.push({
-            content: context,
-            title: 'User Context'
-        });
-    }
-    if (directories && directories.length > 0) {
-        contextItems.push({
-            directories,
-            title: 'Directories'
-        });
-    }
-    return recipe(basePath).persona({
-        path: 'personas/you.md'
-    }).instructions({
-        path: 'instructions/commit.md'
-    }).overridePaths(_overridePaths !== null && _overridePaths !== void 0 ? _overridePaths : []).overrides(_overrides !== null && _overrides !== void 0 ? _overrides : true).content(...contentItems).context(...contextItems).cook();
-};
-
-export { createPrompt };
-//# sourceMappingURL=commit.js.map

package/dist/prompt/commit.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"commit.js","sources":["../../src/prompt/commit.ts"],"sourcesContent":["import { Prompt, recipe } from '@riotprompt/riotprompt';\nimport path from 'path';\nimport { fileURLToPath } from 'url';\n\nconst __filename = fileURLToPath(import.meta.url);\nconst __dirname = path.dirname(__filename);\n\n// Types for the commit prompt\nexport type Content = {\n    diffContent: string;\n    userDirection?: string;\n    isFileContent?: boolean; // Flag to indicate if diffContent is actually file content\n    githubIssuesContext?: string; // GitHub issues related to current version/milestone\n};\n\nexport type Context = {\n    logContext?: string;\n    context?: string;\n    directories?: string[];\n};\n\nexport type Config = {\n    overridePaths?: string[];\n    overrides?: boolean;\n}\n\n/**\n * Build a commit prompt using RiotPrompt Recipes.\n *\n * This prompt is configured to generate multiline commit messages by default,\n * with separate lines/bullet points for different groups of changes rather\n * than squeezing everything into single lines.\n *\n * @param runConfig   The runtime configuration provided by the CLI\n * @param content     Mandatory content inputs (e.g. diff)\n * @param ctx         Optional contextual inputs configured by the user\n */\nexport const createPrompt = async (\n    { overridePaths: _overridePaths, overrides: _overrides }: Config,\n    { diffContent, userDirection, isFileContent, githubIssuesContext }: Content,\n    { logContext, context, directories }: Context = {}\n): Promise<Prompt> => {\n    const basePath = __dirname;\n\n    // Build content items for the prompt\n    const contentItems = [];\n    const contextItems = [];\n\n    // Developer Note: Direction is injected first as the highest-priority prompt input\n    // This ensures user guidance takes precedence over other context sources like\n    // GitHub issues or commit history. Direction content is sanitized via sanitizeDirection()\n    // to prevent template breakage (newlines converted to spaces, whitespace normalized,\n    // length limited to 2000 chars). See tests/util/validation.test.ts for sanitization behavior\n    // and src/commands/commit.ts line 446 for debug logging of direction processing.\n    if (userDirection) {\n        contentItems.push({ content: userDirection, title: 'User Direction' });\n    }\n    if (diffContent) {\n        const contentTitle = isFileContent ? 'Project Files' : 'Diff';\n        contentItems.push({ content: diffContent, title: contentTitle });\n    }\n    if (githubIssuesContext) {\n        contentItems.push({ content: githubIssuesContext, title: 'Recent GitHub Issues' });\n    }\n\n    // IMPORTANT: Log context provides background but can contaminate output if too large.\n    // LLMs tend to pattern-match against recent commits instead of describing the actual diff.\n    // Keep messageLimit low (3-5) to minimize contamination. See DEFAULT_MESSAGE_LIMIT in constants.ts\n    if (logContext) {\n        contextItems.push({ content: logContext, title: 'Log Context' });\n    }\n    if (context) {\n        contextItems.push({ content: context, title: 'User Context' });\n    }\n    if (directories && directories.length > 0) {\n        contextItems.push({ directories, title: 'Directories' });\n    }\n\n    return recipe(basePath)\n        .persona({ path: 'personas/you.md' })\n        .instructions({ path: 'instructions/commit.md' })\n        .overridePaths(_overridePaths ?? [])\n        .overrides(_overrides ?? true)\n        .content(...contentItems)\n        .context(...contextItems)\n        .cook();\n};\n"],"names":["__filename","fileURLToPath","url","__dirname","path","dirname","createPrompt","overridePaths","_overridePaths","overrides","_overrides","diffContent","userDirection","isFileContent","githubIssuesContext","logContext","context","directories","basePath","contentItems","contextItems","push","content","title","contentTitle","length","recipe","persona","instructions","cook"],"mappings":";;;;AAIA,MAAMA,UAAAA,GAAaC,aAAAA,CAAc,MAAA,CAAA,IAAA,CAAYC,GAAG,CAAA;AAChD,MAAMC,SAAAA,GAAYC,aAAAA,CAAKC,OAAO,CAACL,UAAAA,CAAAA;AAqB/B;;;;;;;;;;AAUC,IACM,MAAMM,YAAAA,GAAe,OACxB,EAAEC,aAAAA,EAAeC,cAAc,EAAEC,SAAAA,EAAWC,UAAU,EAAU,EAChE,EAAEC,WAAW,EAAEC,aAAa,EAAEC,aAAa,EAAEC,mBAAmB,EAAW,EAC3E,EAAEC,UAAU,EAAEC,OAAO,EAAEC,WAAW,EAAW,GAAG,EAAE,GAAA;AAElD,IAAA,MAAMC,QAAAA,GAAWf,SAAAA;;AAGjB,IAAA,MAAMgB,eAAe,EAAE;AACvB,IAAA,MAAMC,eAAe,EAAE;;;;;;;AAQvB,IAAA,IAAIR,aAAAA,EAAe;AACfO,QAAAA,YAAAA,CAAaE,IAAI,CAAC;YAAEC,OAAAA,EAASV,aAAAA;YAAeW,KAAAA,EAAO;AAAiB,SAAA,CAAA;AACxE,IAAA;AACA,IAAA,IAAIZ,WAAAA,EAAa;QACb,MAAMa,YAAAA,GAAeX,gBAAgB,eAAA,GAAkB,MAAA;AACvDM,QAAAA,YAAAA,CAAaE,IAAI,CAAC;YAAEC,OAAAA,EAASX,WAAAA;YAAaY,KAAAA,EAAOC;AAAa,SAAA,CAAA;AAClE,IAAA;AACA,IAAA,IAAIV,mBAAAA,EAAqB;AACrBK,QAAAA,YAAAA,CAAaE,IAAI,CAAC;YAAEC,OAAAA,EAASR,mBAAAA;YAAqBS,KAAAA,EAAO;AAAuB,SAAA,CAAA;AACpF,IAAA;;;;AAKA,IAAA,IAAIR,UAAAA,EAAY;AACZK,QAAAA,YAAAA,CAAaC,IAAI,CAAC;YAAEC,OAAAA,EAASP,UAAAA;YAAYQ,KAAAA,EAAO;AAAc,SAAA,CAAA;AAClE,IAAA;AACA,IAAA,IAAIP,OAAAA,EAAS;AACTI,QAAAA,YAAAA,CAAaC,IAAI,CAAC;YAAEC,OAAAA,EAASN,OAAAA;YAASO,KAAAA,EAAO;AAAe,SAAA,CAAA;AAChE,IAAA;AACA,IAAA,IAAIN,WAAAA,IAAeA,WAAAA,CAAYQ,MAAM,GAAG,CAAA,EAAG;AACvCL,QAAAA,YAAAA,CAAaC,IAAI,CAAC;AAAEJ,YAAAA,WAAAA;YAAaM,KAAAA,EAAO;AAAc,SAAA,CAAA;AAC1D,IAAA;IAEA,OAAOG,MAAAA,CAAOR,QAAAA,CAAAA,CACTS,OAAO,CAAC;QAAEvB,IAAAA,EAAM;AAAkB,KAAA,CAAA,CAClCwB,YAAY,CAAC;QAAExB,IAAAA,EAAM;AAAyB,KAAA,CAAA,CAC9CG,aAAa,CAACC,cAAAA,KAAAA,IAAAA,IAAAA,4BAAAA,cAAAA,GAAkB,EAAE,EAClCC,SAAS,CAACC,uBAAAA,UAAAA,KAAAA,MAAAA,GAAAA,UAAAA,GAAc,MACxBY,OAAO,CAAA,GAAIH,cACXH,OAAO,CAAA,GAAII,cACXS,IAAI,EAAA;AACb;;;;"}

package/dist/prompt/instructions/commit.md

@@ -1,133 +0,0 @@
-**🔧 Task Definition**
-
-You are generating a Git commit message that describes **ONLY THE CURRENT DIFF**.
-
----
-
-## ⚠️ CRITICAL RULES - READ FIRST
-
-1. **THE DIFF IS YOUR ONLY SOURCE OF TRUTH** - Your commit message must describe ONLY what appears in the `[Diff]` section
-2. **IGNORE LOG CONTEXT** - Previous commits are shown for background only. DO NOT describe them, reference them, or let them influence your message
-3. **CITE SPECIFIC FILES** - Every change you mention must reference actual files from the diff (e.g., "Remove post-publish sync logic in src/commands/publish.ts")
-4. **NO HALLUCINATIONS** - If you mention a change, it MUST exist in the diff. Describing changes not in the diff is a critical failure
-5. **LENGTH FOLLOWS SCOPE** - Typical commits are 3-6 lines. Very large architectural changes may warrant essay-length messages, but every line must still describe actual changes from the diff
-
----
-
-## 📋 Input Sections
-
-* **\[User Direction]** — When present, use this to understand the user's INTENT, but your commit message must still accurately describe what's in the diff
-* **\[User Context]** — Optional background about the user's environment
-* **\[Diff]** — **THE ONLY SOURCE OF TRUTH** - This shows exactly what changed. Describe ONLY these changes
-* **\[Project Files]** — Only present for new repositories with no diff
-* **\[Recent GitHub Issues]** — Optional context for understanding motivation. Only reference issues if the diff clearly addresses them
-* **\[Log Context]** — **IGNORE THIS** - Previous commit messages shown for background only. DO NOT describe previous commits or copy their language
-
----
-
-## 🧠 COMMIT MESSAGE GUIDELINES
-
-### ✅ DO:
-
-* **Ground every statement in the diff** - Mention specific files that changed (e.g., "Add retry logic to src/api/client.ts")
-* **Start with clear intent** - One line explaining the overall purpose
-* **Use bullet points** - Separate distinct changes into individual bullets
-* **Be specific** - "Remove 68 lines of post-publish sync code" not "Refactor publish flow"
-* **Match length to scope** - Most commits are 3-6 lines. Massive architectural changes can warrant longer, detailed messages when the scope justifies it
-* **Use technical language** - Direct, precise, no fluff
-
-### ❌ DO NOT:
-
-* ❌ **NEVER describe changes not in the diff** - This is the #1 failure mode
-* ❌ **NEVER reference log context** - Don't describe "this continues previous work" or similar
-* ❌ **NEVER use vague language** - "Improve", "refactor", "enhance" without specifics
-* ❌ **NEVER write multi-paragraph essays** - Keep it concise
-* ❌ **NEVER mention test changes unless they're significant** - Focus on production code
-* ❌ **NEVER use markdown** - Plain text only
-* ❌ **NEVER begin with "This commit..."** - Just describe what changed
-
----
-
-## 📝 OUTPUT FORMATS & EXAMPLES
-
-### ✅ GOOD: Concise with file citations (3-6 lines)
-
-> Remove post-publish branch sync and version bump automation
->
-> * Delete 68 lines of merge/version-bump code from src/commands/publish.ts (lines 1039-1106)
-> * Replace with simple completion message and manual next-steps guidance
-> * Add verbose logging to git tag search in src/util/git.ts for debugging
-
-**Why this is good:** Specific files, line counts, describes what actually changed
-
----
-
-### ✅ GOOD: Single atomic change (1 line)
-
-> Fix typo in error message for invalid credentials in src/auth/validator.ts
-
-**Why this is good:** One file, one change, specific
-
----
-
-### ✅ GOOD: Multiple related changes (4-7 lines)
-
-> Add retry logic for API timeout errors
->
-> * Implement exponential backoff in src/api/client.ts
-> * Add max retry configuration to src/config/api.ts
-> * Update error handling in src/api/error-handler.ts to detect retryable errors
-> * Add retry tests in tests/api/client.test.ts
-
-**Why this is good:** Grounded in actual files, specific changes, concise
-
----
-
-### ❌ BAD: Hallucinated changes (DO NOT DO THIS)
-
-> Centralize ref-detection and streamline publish flow
->
-> * Move to single ref-detection approach and stop passing from/to into Log.create()
-> * Replace ad-hoc fromRef/toRef handling in src/commands/release.ts
-> * Scale diff context: DEFAULT_MAX_DIFF_BYTES now 20480
-> * Update tests to mock new git boundary
-> * Update docs/public/commands/publish.md
-
-**Why this is terrible:** These changes aren't in the diff! The LLM is describing previous commits from log context instead of the actual diff. This is the #1 failure mode to avoid.
-
----
-
-### ❌ BAD: Verbose multi-paragraph essay (DO NOT DO THIS)
-
-> Reorganize pipeline logic to improve readability and make phase execution more testable. This is part of ongoing work to modularize transition handling.
->
-> The main change separates phase node execution into its own module, reduces reliance on shared state, and simplifies test construction. Existing functionality remains unchanged, but internal structure is now better aligned with future transition plugin support.
->
-> This commit represents a significant cleanup of the execution flow and provides a safer foundation for future operations.
->
-> * Extract executePhaseNode() from pipeline.ts
-> * Add phase-runner.ts with dedicated error handling
-> ...
-
-**Why this is terrible:** Way too verbose (could be 3 lines), fluffy language, unnecessary context paragraphs
-
----
-
-### ❌ BAD: Vague without file citations (DO NOT DO THIS)
-
-> Improve error handling and refactor configuration logic
-
-**Why this is terrible:** No specific files, vague verbs like "improve" and "refactor", no details
-
----
-
-## 🎯 Length Guidelines
-
-* **Single change:** 1 line
-* **Typical commit:** 3-6 lines (summary + 2-5 bullets)
-* **Large commit:** 6-15 lines
-* **Major architectural change:** Essay-length if warranted (rare but valid)
-
-**There is no hard upper limit.** The constraint is not length - it's **accuracy**. Every line must describe actual changes from the diff.
-
-Write as much as you need to accurately describe the changes, but no more. A 50-line commit message is fine if the diff touches 30 files and restructures core systems. A 6-line commit message that describes changes not in the diff is a critical failure, regardless of its brevity.

package/dist/prompt/instructions/release.md

@@ -1,188 +0,0 @@
-## ⚠️ CRITICAL RULES - READ FIRST
-
-1. **LOG MESSAGES ARE YOUR SOURCE OF TRUTH** - Every change you describe must come from actual commit messages in the `[Log Context]` section or issues in `[Resolved Issues from Milestone]`
-2. **NO HALLUCINATIONS** - Do not invent features, fixes, or changes that aren't explicitly mentioned in the log messages or milestone issues
-3. **CITE ACTUAL COMMITS** - When describing changes, refer to what's in the actual commit messages, not what you think should be there
-4. **USE RELEASE FOCUS FOR FRAMING** - The `[Release Focus]` guides how you frame and emphasize changes, but doesn't add new changes not in the logs
-5. **LENGTH FOLLOWS SCOPE** - Small releases get concise notes. Large releases deserve comprehensive documentation. Match the actual scope of changes in the log
-
----
-
-## Your Task
-
-Write release notes by reading all commit messages in `[Log Context]` and milestone issues in `[Resolved Issues from Milestone]`. Every change you mention must be traceable to an actual commit message or resolved issue.
-
-### Output Format
-
-Your response MUST be a valid JSON object with the following structure:
-{
-  "title": "A single-line, concise title for the release.",
-  "body": "The detailed release notes in Markdown format."
-}
-
-**Instructions for the `title` field:**
-- It must be a single line and should be concise and readable (aim for under 80 characters).
-- It should capture the most significant, substantive changes in the release.
-- Focus on what is noticeable to developers using the software.
-- Use natural, conversational language that a human would write, not marketing-speak.
-- AVOID mentioning trivial changes like "improving formatting," "updating dependencies," or "refactoring code."
-
-**Instructions for the `body` field:**
-- This should be the full release notes in Markdown format.
-- Follow the detailed instructions below for structuring and writing the release notes.
-- **For large releases**: Be comprehensive and detailed. Users deserve thorough documentation when there are many changes.
-
-### Output Restrictions
-
-- Do not mention and people or contributors in the release notes.  For example, do not say, "Thanks to John Doe for this feature."  Release notes are to be impersonal and not focused on indiviudals.
-
-- Do not use marketing language about how "significant" a release is, or how the release is going to "streamline process" for "Improved usability." Write factual, technical descriptions of what has changed. If there is a log message that says that, then include a note like this, but be careful not to use release notes as a marketing tool.
-
-- Do not use emoticons or emojis in headers or content. These make the output appear AI-generated rather than human-written.
-
-- If the release is very simple, keep the release notes short and simple. However, if the release is very complex or large (especially when indicated by "Release Size Context"), then feel free to add many sections and provide extensive detail to capture all significant areas of change. Large releases deserve comprehensive documentation.
-
-## Purpose
-
-Create release notes that:
-
-* Help developers, contributors, or users **understand what changed**
-* Reflect the **actual purpose** and **impact** of the release
-* Are **not promotional**, **not exaggerated**, and **not overly positive**
-* Sound like they were written by a human developer, not AI-generated marketing copy
-* **For large releases**: Provide comprehensive coverage of all significant changes rather than brief summaries
-
-
-## Instructions
-
-1. **Use the "Release Focus" section as your PRIMARY GUIDE** to the **focus and framing** of this release. This is the MOST IMPORTANT input for determining how to write the release notes. The Release Focus may include:
-
-   * The theme or reason behind the release (e.g., "we're cleaning up configuration files", "this is about improving test stability")
-   * Key goals or constraints
-   * Target audiences or known issues being addressed
-   * Strategic direction or priorities for this release
-
-   **CRITICAL**: The Release Focus should shape the **opening paragraph**, determine which changes are emphasized most prominently, and guide the overall narrative of the release notes. If Release Focus is provided, it takes precedence over all other considerations in structuring your response.
-
-1a. **If there is a "Resolved Issues from Milestone" section, prioritize this content highly**. These represent well-documented issues that were resolved in this release:
-
-   * Include the resolved issues prominently in your release notes
-   * Reference the issue numbers (e.g., "Fixed authentication bug (#123)")
-   * **Pay close attention to the issue descriptions, comments, and discussions** to understand the motivation and context behind changes
-   * Use the issue conversations to provide detailed context about why changes were made and what problems they solve
-   * These issues often represent the most significant user-facing changes in the release
-   * Organize related issues together in logical sections
-
-2. **Structure the release notes as follows:**
-
-   * **Opening paragraph** that gives a high-level summary of the release, grounded in the User Context
-   * Followed by **grouped sections** of changes using headers like:
-
-     * `New Features`
-     * `Improvements`
-     * `Bug Fixes`
-     * `Refactoring`
-     * `Documentation Updates`
-     * `Breaking Changes`
-     * `Deprecations`
-     * `Performance Enhancements`
-     * `Security Updates`
-     * `Developer Experience`
-     * `Testing Improvements`
-     * `Configuration Changes`
-
-   Include only the sections that are relevant. **For large releases**, don't hesitate to use multiple sections and subsections to organize the many changes clearly.
-
-3. **Use clear, factual bullet points** under each section. Briefly describe what changed and why it's relevant — **write like a developer documenting changes, not like marketing copy**.
-
-   **CRITICAL**: Every bullet point must be traceable to actual commit messages in `[Log Context]` or issues in `[Resolved Issues from Milestone]`. If a change isn't in the log, don't mention it.
-
-   **For large releases**: Provide detailed bullet points that explain:
-   - What specifically changed (cite actual commit messages)
-   - Why the change was made (if evident from commit messages or issue descriptions)
-   - Impact on users or developers (based on commit/issue context)
-   - Related files or components affected (when mentioned in commits)
-
-   **DO NOT**:
-   * Invent features not mentioned in commits
-   * Describe changes that "should" be there but aren't in the log
-   * Use vague or exaggerated marketing terms like "awesome new feature", "significant boost", "revolutionary update", "streamlined workflow", "enhanced user experience"
-   * Group unrelated commits under theme names that aren't in the actual commits
-
-4. **Keep your tone technical, neutral, and useful.** It's okay to include references to:
-
-   * Affected files or systems
-   * Internal components (if relevant to the audience)
-   * Specific pull requests or issues (if helpful)
-   * Contributors (optionally, in parentheses or footnotes)
-
-5. **For large releases specifically**:
-   - Create more detailed subsections when there are many related changes
-   - Group related changes together logically
-   - Explain the broader context or theme when multiple commits work toward the same goal
-   - Don't be afraid to write longer, more comprehensive release notes
-   - Include technical details that help users understand the scope of changes
-
----
-
-## Anti-Examples: What NOT to Do
-
-### ❌ BAD: Hallucinated Changes
-
-**Problem**: The release notes describe features that aren't in any commit message:
-
-```json
-{
-  "title": "Major Performance Overhaul and API Redesign",
-  "body": "**Performance Improvements**\\n\\n* Reduced API response times by 60% through query optimization\\n* Implemented connection pooling for database efficiency\\n* Added Redis caching layer for frequently accessed data\\n\\n**API Redesign**\\n\\n* Completely redesigned REST API with versioning support\\n* Migrated all endpoints to new authentication system"
-}
-```
-
-**Why it's terrible**: None of these changes appear in the commit log. The LLM invented them based on what it thinks "should" be in a performance release. This is a critical failure even if the notes sound good.
-
----
-
-### ❌ BAD: Vague Marketing Fluff
-
-**Problem**: Generic marketing language instead of specific commit-based changes:
-
-```json
-{
-  "title": "Enhanced User Experience and Streamlined Workflows",
-  "body": "This exciting release brings revolutionary improvements to the user experience! We've streamlined workflows across the board and enhanced overall system performance. Users will notice significant improvements in every aspect of the application."
-}
-```
-
-**Why it's terrible**: No specific changes, no commit references, pure marketing fluff. Completely useless to developers.
-
----
-
-## Output Format Examples
-
-### ✅ GOOD: Grounded in Actual Commits
-
-**Scenario**: Log contains commits about removing post-publish sync, adding verbose logging, and fixing a config bug
-
-```json
-{
-  "title": "Simplify publish flow and improve git tag debugging",
-  "body": "**Workflow Changes**\\n\\n* Remove automatic branch sync and version bump from publish flow - users now manually run `kodrdriv development` to continue work after publish\\n* Simplify publish completion to show next steps instead of auto-syncing\\n\\n**Debugging Improvements**\\n\\n* Add extensive logging to git tag detection in `getDefaultFromRef()` to diagnose tag search issues\\n* Add emoji indicators and structured output for tag search process\\n\\n**Bug Fixes**\\n\\n* Fix config validation error when optional field was missing"
-}
-```
-
-**Why it's good**: Every bullet point traces to an actual commit. Specific file references. No invented features.
-
----
-
-### ✅ GOOD: Large Release with Detail
-
-**Scenario**: 30 commits touching configuration system, tests, docs, and CLI
-
-```json
-{
-  "title": "Configuration System Overhaul and Testing Migration",
-  "body": "This release modernizes the configuration system and migrates the test suite based on accumulated technical debt and developer feedback.\\n\\n**Configuration System Changes**\\n\\n* Unify vite.config.ts and webpack.config.js into single environment-aware module\\n* Add support for .env.defaults with proper precedence handling\\n* Implement config validation with detailed error messages\\n* Reduce tsconfig.json nesting depth for readability\\n\\n**Testing Infrastructure**\\n\\n* Migrate test suite from Jest to Vitest for better ES module support\\n* Add integration tests for configuration system\\n* Implement coverage reporting with branch and function metrics\\n\\n**Bug Fixes**\\n\\n* Fix crash in config loader when optional fields undefined\\n* Resolve Windows build failure due to missing path escaping\\n* Fix race condition in parallel test execution\\n\\n**Breaking Changes**\\n\\n* Remove support for legacy .env.local.js files\\n* Change default output directory from dist/ to build/\\n* Require Node.js 18.0.0 or higher\\n\\n**Documentation**\\n\\n* Rewrite setup instructions in README.md for new config process\\n* Add migration guide for users upgrading from previous versions"
-}
-```
-
-**Why it's good**: Comprehensive coverage of a large release, but every change is grounded in actual commits. No fluff, just facts.