smart-commit-copilot-cli 0.1.5 → 0.1.7

package/CHANGELOG.md

@@ -6,6 +6,43 @@ The format is based on Keep a Changelog, and this project follows Semantic Versi
 
 ## [Unreleased]
 
+## [0.1.7] - 2026-04-26
+
+### Added
+
+- optional AI pull request summary generation after successful `bridge` runs, writing timestamped Markdown under a configurable directory or the default `.smart-commit-cli/pr-summaries`
+- `pullRequestSummary.*` settings (`enabled`, `language`, `outputDirPath`, `prompt`) across CLI flags, environment variables, config files, JSON schema output, and legacy `smartCommit.*` mappings
+- structured `pullRequestSummary` in bridge output (`generated`, `outputFilePath`, `provider`, `error`) plus user-facing text render lines and non-fatal warnings when generation fails after an otherwise successful run
+- regression coverage for pull request summary plumbing and configuration resolution
+- a dedicated `0.1.7` draft release note for the current publish target
+
+### Changed
+
+- public config and bridge JSON contracts now include `pullRequestSummary` fields; `schema print --target bridge` reflects the updated shape
+- built-in `conventional` and `semantic` commit-message skill docs now note extracting a Jira or work item id from the branch name when prepending to the subject
+- publish guidance now points to the `0.1.7` release draft during pre-publish review
+
+## [0.1.6] - 2026-04-18
+
+### Added
+
+- bundled built-in review skill assets for generic and domain-specific profiles, including `c-code-review`
+- `report generate --period yesterday` with previous-natural-day time window handling
+- configurable `connection.llmResponseCorrectionRetryCount` and `passHistory.writeStage` across CLI args, environment variables, config files, schema output, and legacy `smartCommit.*` mappings
+- a dedicated `0.1.6` draft release note for the current publish target
+
+### Changed
+
+- review prompt augmentation now loads bundled review-skill instructions and references, and adds diff-domain guidance with generic fallback when a specialized skill does not match the staged diff
+- review repair and commit-message regeneration now use the configurable response-correction retry budget and enforce the requested output language during retryable validation
+- pass-history writes now upsert a single record across review, commit, and push success stages so `eventType` reflects the furthest successful stage reached by the run
+- publish guidance now points to the `0.1.6` release draft during pre-publish review
+
+### Fixed
+
+- successful local commits are now preserved in pass history when a later push cannot start, is rejected, or times out, unless `passHistory.writeStage` explicitly requires push completion
+- machine-facing contracts, docs, and regression coverage now match the new correction-retry bounds, built-in review skill exposure, and `yesterday` reporting support
+
 ## [0.1.5] - 2026-04-15
 
 ### Added

package/README.md

@@ -15,10 +15,12 @@ It can:
 - inspect staged changes
 - run AI review and gate on the result
 - generate or validate commit messages
+- retry malformed review or commit-message responses with configurable correction passes
+- use bundled review skills, including `c-code-review`, with diff-aware generic fallback
 - optionally create a commit
 - optionally push the current branch
 - persist successful run history
-- generate Markdown work reports
+- generate daily, yesterday, weekly, monthly, quarterly, or yearly Markdown work reports
 
 ## Who This Is For
 
@@ -276,7 +278,8 @@ Use this when you want a more realistic team default without enabling automatic
     "connection": {
       "baseUrl": "https://api.openai.com/v1",
       "apiKey": "env:SMART_COMMIT_API_KEY",
-      "model": "gpt-5"
+      "model": "gpt-5",
+      "llmResponseCorrectionRetryCount": 1
     },
     "review": {
       "threshold": 6,
@@ -289,6 +292,7 @@ Use this when you want a more realistic team default without enabling automatic
     },
     "passHistory": {
       "enabled": true,
+      "writeStage": "review_passed",
       "dirPath": ".smart-commit-cli",
       "maxEntries": 3000
     },
@@ -306,6 +310,14 @@ This is usually the best starting point for teams because it:
 - allows local history for reporting
 - stays safe for hooks and automation
 
+### Review skills and correction retries
+
+Built-in review skills are bundled with the CLI. The default `code-review` skill stays generic, while domain skills such as `frontend-code-review`, `python-code-review`, `c-code-review`, `cpp-code-review`, and `csharp-code-review` add domain-focused guidance. These built-in review skills share a lightweight diff classifier: if the staged diff does not match the selected domain, the CLI falls back to generic review rules automatically without changing your configured skill id.
+
+If you set `review.skill.path`, the CLI keeps the current file-based custom-skill behavior and loads that file as custom prompt input instead of the bundled built-in skill assets.
+
+`connection.llmResponseCorrectionRetryCount` controls how many extra repair or regeneration attempts the CLI may request when a review result or generated commit message fails protocol, JSON-shape, or language validation. The default is `1`, the supported range is `0..5`, and network, HTTP, timeout, or provider failures are not retried by this setting.
+
 ### About the example config in this repo
 
 This repository ships a fuller example at `examples/config/smart-commit.json`.
@@ -387,12 +399,13 @@ smart-commit report generate --repo . --config ./smart-commit.json --period week
 Supported `--period` values:
 
 - `daily`
+- `yesterday`
 - `weekly`
 - `monthly`
 - `quarterly`
 - `yearly`
 
-If you omit `--period`, it defaults to `weekly`.
+If you omit `--period`, it defaults to `weekly`. `yesterday` always means the previous natural local day.
 
 If `passHistory.enabled=true`, successful bridge runs are written locally and later summarized into a Markdown report.
 
@@ -404,6 +417,14 @@ smart-commit report generate --repo . --config ./smart-commit.json --period week
 
 If AI report generation fails, the CLI falls back to local Markdown generation automatically.
 
+### I want a pull request summary after a passing review
+
+```bash
+smart-commit bridge --repo . --config ./smart-commit.json --no-commit --enable-pull-request-summary
+```
+
+When enabled, `bridge` writes a Markdown PR description after the reviewed action succeeds. It runs after review-only success, after local commit success when `--no-push` is used, or after push success when auto-push is enabled. Review blocks, dry runs, and commit/push failures do not generate a PR summary.
+
 ### I want machine-readable schemas
 
 ```bash
@@ -553,9 +574,17 @@ Most practical flags for daily use:
 --api-key
 --model
 --threshold
+--llm-response-correction-retry-count
 --review-language
+--code-review-skill-id
 --commit-language
+--commit-message-structure
 --commit-message
+--pass-history-write-stage
+--enable-pull-request-summary
+--pull-request-summary-language
+--pull-request-summary-output-dir
+--pull-request-summary-prompt
 --no-commit
 --no-push
 --dry-run
@@ -579,12 +608,20 @@ SMART_COMMIT_API_KEY
 SMART_COMMIT_BASE_URL
 SMART_COMMIT_MODEL
 SMART_COMMIT_THRESHOLD
+SMART_COMMIT_LLM_RESPONSE_CORRECTION_RETRY_COUNT
 SMART_COMMIT_REVIEW_LANGUAGE
+SMART_COMMIT_CODE_REVIEW_SKILL_ID
 SMART_COMMIT_COMMIT_LANGUAGE
+SMART_COMMIT_COMMIT_MESSAGE_STRUCTURE
 SMART_COMMIT_AUTO_COMMIT
 SMART_COMMIT_AUTO_PUSH
+SMART_COMMIT_PASS_HISTORY_WRITE_STAGE
 SMART_COMMIT_REPORT_LANGUAGE
 SMART_COMMIT_REPORT_OUTPUT_DIR
+SMART_COMMIT_ENABLE_PULL_REQUEST_SUMMARY
+SMART_COMMIT_PULL_REQUEST_SUMMARY_LANGUAGE
+SMART_COMMIT_PULL_REQUEST_SUMMARY_OUTPUT_DIR
+SMART_COMMIT_PULL_REQUEST_SUMMARY_PROMPT
 ```
 
 ## Reporting
@@ -595,11 +632,22 @@ If `passHistory.enabled=true`, successful bridge runs are written to local histo
 smart-commit report generate --repo . --config ./smart-commit.json --period weekly
 ```
 
-Successful bridge runs are categorized in pass history as:
+`passHistory.writeStage` controls the earliest successful stage that can create a record. Once a record exists, later successful stages update the same pass-history entry, so `eventType` always reflects the furthest successful stage reached by that run.
+
+- `review_passed` writes as soon as review passes. If that same run later reaches a local commit or push, the existing record is upgraded instead of duplicated.
+- `commit_completed` waits until the local commit succeeds. If a later push succeeds, that same record is upgraded to `commit_push_completed`.
+- `commit_push_completed` writes only after both the local commit and the push succeed.
+
+If a run never reaches the configured write stage, no pass-history record is written. For example:
+
+- with `passHistory.writeStage=commit_completed`, a successful local commit is still preserved even if the later push cannot start, fails, or times out
+- with `passHistory.writeStage=commit_push_completed`, those same push failures produce no pass-history record
+
+Stored pass-history `eventType` values mean:
 
-- `review_passed`: review passed, but automatic commit is disabled
-- `commit_completed`: a local commit was created, but automatic push is disabled
-- `commit_push_completed`: a local commit was created and the current branch was pushed
+- `review_passed`: review passed, and no later success stage was reached
+- `commit_completed`: a local commit succeeded, and no later push success stage was reached
+- `commit_push_completed`: both the local commit and the remote push succeeded
 
 Report summaries use these records to show:
 

package/docs/configuration.md

@@ -142,7 +142,8 @@ Recommended early team setup:
     "connection": {
       "baseUrl": "https://api.openai.com/v1",
       "apiKey": "env:SMART_COMMIT_API_KEY",
-      "model": "gpt-5"
+      "model": "gpt-5",
+      "llmResponseCorrectionRetryCount": 1
     },
     "review": {
       "threshold": 6,
@@ -155,6 +156,7 @@ Recommended early team setup:
     },
     "passHistory": {
       "enabled": true,
+      "writeStage": "review_passed",
       "dirPath": ".smart-commit-cli",
       "maxEntries": 3000
     },
@@ -186,12 +188,14 @@ These settings tell the CLI how to reach your AI endpoint. `bridge` requires all
 | `connection.apiKey` | empty string | `env:SMART_COMMIT_API_KEY` | Change it only if you intentionally inject secrets another way | Putting raw secrets into committed config files |
 | `connection.model` | empty string | A model name that your chosen `baseUrl` actually serves | Change it when you switch cost, quality, or provider capabilities | Using a model name unsupported by your gateway |
 | `connection.requestTimeoutMs` | `1000000` | Leave default first | Change it only if your provider is too slow or your requests time out unexpectedly | Setting it below `5000`, which fails validation |
+| `connection.llmResponseCorrectionRetryCount` | `1` | `1` | Change it when you want `0..5` repair or regeneration retries for protocol, format, or language validation failures | Expecting it to retry provider, network, HTTP, or timeout failures |
 | `connection.extraHeaders` | `{}` | Leave empty first | Add values only if your proxy or API gateway requires custom headers | Adding provider-specific headers that your endpoint does not expect |
 
 Practical guidance:
 
 - if you do not know what to choose, ask one question first: "What OpenAI-compatible base URL and model name does our environment support?"
 - if you use an internal gateway, use the gateway's supported model list instead of guessing
+- `connection.llmResponseCorrectionRetryCount` applies to review-response repair and commit-message regeneration only when the model output fails local protocol validation; it does not hide transport or provider errors
 
 ### `review.*`
 
@@ -211,6 +215,7 @@ Supported built-in review skill ids:
 - `code-review`
 - `frontend-code-review`
 - `mobile-code-review`
+- `c-code-review`
 - `python-code-review`
 - `golang-code-review`
 - `java-code-review`
@@ -219,6 +224,8 @@ Supported built-in review skill ids:
 - `rust-code-review`
 - `php-code-review`
 
+Built-in review skills load bundled guidance and references from the CLI package. They also share a diff-domain classifier that can fall back to generic review rules when the staged diff does not match the selected domain. If you set `review.skill.path`, the CLI keeps the current file-based custom-skill behavior and does not switch to the bundled built-in skill assets for that run.
+
 When to choose a custom skill path:
 
 - your team has a fixed review checklist
@@ -233,6 +240,7 @@ These settings control where the commit message comes from and how it is validat
 | --- | --- | --- | --- | --- |
 | `commitMessage.input` | empty string | Leave empty first | Set it when you already know the exact message you want | Setting it and expecting auto-generation to replace it |
 | `commitMessage.language` | `zh` | `zh` or `en` | Change it to match your team's commit language | Mixing a team English convention with a non-English expectation |
+| `commitMessage.structure` | `subjectOnly` | `subjectOnly` | Change it when your team wants optional commit bodies or footers | Expecting body/footer to be allowed while the default single-line mode is still active |
 | `commitMessage.autoGenerate` | `true` | `true` | Set `false` only if users always provide a message themselves | Turning it off with no provided message, which causes a commit-message-required error |
 | `commitMessage.hybridGenerate` | `false` | `false` | Set `true` when users provide a draft and want AI to refine it | Enabling it without understanding that it uses `commitMessage.input` as a draft |
 | `commitMessage.validation.protocol` | `none` | `none` first, then `conventional` if your team standardizes on it | Change it when your team enforces a commit style | Enabling validation before the team is ready |
@@ -250,6 +258,14 @@ How `hybridGenerate` actually works:
 - if `commitMessage.input` is empty and `autoGenerate=true`, the CLI generates from the diff
 - if `commitMessage.input` is empty and `autoGenerate=false`, the CLI errors because no message source exists
 
+Supported commit message structures:
+
+- `subjectOnly`: exactly one non-empty subject line
+- `subjectBody`: a subject plus optional body separated by one blank line
+- `subjectBodyFooter`: a subject plus optional body and optional footer/trailer lines
+
+Protocol, language, ticket, and regex validation apply to the subject. Ticket injection from the branch preserves any accepted body or footer.
+
 Supported validation protocols:
 
 - `none`
@@ -286,11 +302,18 @@ These settings control local storage for successful run history.
 | Field | Built-in default | Recommended first value | When to change it | Common mistake |
 | --- | --- | --- | --- | --- |
 | `passHistory.enabled` | `false` | `true` if you want reporting later | Turn it on when you want local historical reporting | Forgetting to enable it and then expecting `report generate` to summarize past work |
+| `passHistory.writeStage` | `review_passed` | `review_passed` | Change it when you want pass-history records to start only after commit or push success | Assuming it changes the stored `eventType`, when it actually changes the earliest write point |
 | `passHistory.dirPath` | empty string | Leave empty first or set `.smart-commit-cli` explicitly | Change it only if you want a custom location | Thinking empty means broken, when it actually falls back to the repo-local default directory |
 | `passHistory.maxEntries` | `3000` | `3000` | Change it only if you need much shorter or longer retention | Setting it to `0` or a non-integer, which fails validation |
 
 If `passHistory.dirPath` is empty, the CLI automatically stores pass history under the repository's `.smart-commit-cli` directory.
 
+`passHistory.writeStage` means "the earliest successful stage that is allowed to create a record." After a record exists, later successful stages update the same record instead of appending duplicates, so the stored `eventType` always shows the furthest successful stage reached by that run.
+
+- `review_passed` writes immediately after review success and can later upgrade to `commit_completed` or `commit_push_completed`
+- `commit_completed` waits for a successful local commit and still preserves that record if a later push cannot start, fails, or times out
+- `commit_push_completed` waits for both commit and push success; if push never succeeds, no record is written
+
 ### `reporting.*`
 
 These settings control report generation behavior.
@@ -305,6 +328,19 @@ These settings control report generation behavior.
 
 If `reporting.outputDirPath` is empty, the CLI writes reports to `.smart-commit-cli/reports` under the repository root.
 
+### `pullRequestSummary.*`
+
+These settings control optional Markdown PR summary generation after a passing `bridge` run.
+
+| Field | Built-in default | Recommended first value | When to change it | Common mistake |
+| --- | --- | --- | --- | --- |
+| `pullRequestSummary.enabled` | `false` | `false` first | Set `true` when you want a PR description after review success | Expecting it to run for dry-run, blocked review, or failed commit/push paths |
+| `pullRequestSummary.language` | `zh` | Match your reviewer language | Change it independently from review and commit-message language | Assuming it changes review output language |
+| `pullRequestSummary.outputDirPath` | empty string | Leave empty first | Set it when your automation needs a specific artifact location | Thinking empty means invalid; it writes under `.smart-commit-cli/pr-summaries` |
+| `pullRequestSummary.prompt` | empty string | Leave empty first | Add concise team PR template guidance | Asking it to invent tests, reviewers, links, or review findings |
+
+The generated summary uses only the reviewed staged diff, commit message, branch, changed files, and run facts. Review scores, thresholds, findings, and suggestions are treated as internal gate data and are not included in the PR description.
+
 ### `output.*`
 
 These settings control how results are presented.
@@ -372,9 +408,17 @@ Most practical flags:
 --api-key
 --model
 --threshold
+--llm-response-correction-retry-count
 --review-language
+--code-review-skill-id
 --commit-language
+--commit-message-structure
 --commit-message
+--pass-history-write-stage
+--enable-pull-request-summary
+--pull-request-summary-language
+--pull-request-summary-output-dir
+--pull-request-summary-prompt
 --no-commit
 --no-push
 --dry-run
@@ -398,12 +442,20 @@ SMART_COMMIT_API_KEY
 SMART_COMMIT_BASE_URL
 SMART_COMMIT_MODEL
 SMART_COMMIT_THRESHOLD
+SMART_COMMIT_LLM_RESPONSE_CORRECTION_RETRY_COUNT
 SMART_COMMIT_REVIEW_LANGUAGE
+SMART_COMMIT_CODE_REVIEW_SKILL_ID
 SMART_COMMIT_COMMIT_LANGUAGE
+SMART_COMMIT_COMMIT_MESSAGE_STRUCTURE
 SMART_COMMIT_AUTO_COMMIT
 SMART_COMMIT_AUTO_PUSH
+SMART_COMMIT_PASS_HISTORY_WRITE_STAGE
 SMART_COMMIT_REPORT_LANGUAGE
 SMART_COMMIT_REPORT_OUTPUT_DIR
+SMART_COMMIT_ENABLE_PULL_REQUEST_SUMMARY
+SMART_COMMIT_PULL_REQUEST_SUMMARY_LANGUAGE
+SMART_COMMIT_PULL_REQUEST_SUMMARY_OUTPUT_DIR
+SMART_COMMIT_PULL_REQUEST_SUMMARY_PROMPT
 ```
 
 Useful boolean environment variables accept:
@@ -456,12 +508,13 @@ smart-commit bridge --repo . --config ./smart-commit.json --no-commit --no-push
 Supported periods:
 
 - `daily`
+- `yesterday`
 - `weekly`
 - `monthly`
 - `quarterly`
 - `yearly`
 
-If `--period` is omitted, it defaults to `weekly`.
+If `--period` is omitted, it defaults to `weekly`. `yesterday` always uses the previous natural local day.
 
 ## Validation Workflow
 

package/docs/contracts.md

@@ -36,6 +36,8 @@ Stable top-level fields:
 
 Use it to validate merged config before wiring `bridge` or `report generate` into automation.
 
+Contract consumers can safely read newly added resolved settings such as `config.connection.llmResponseCorrectionRetryCount`, `config.passHistory.writeStage`, `config.review.skill.id`, `config.commitMessage.structure`, and `config.pullRequestSummary.enabled` from the returned `config` object.
+
 ## `bridge`
 
 Command:
@@ -55,6 +57,7 @@ Stable top-level fields:
 - `didPush`
 - `commitSha`
 - `passHistory`
+- `pullRequestSummary`
 - `reviewDecision`
 - `score`
 - `summary`
@@ -63,19 +66,27 @@ Stable top-level fields:
 Stable nested fields often used by automations:
 
 - `passHistory.eventType`
+- `pullRequestSummary.generated`
+- `pullRequestSummary.outputFilePath`
 - `reviewDetails`
 
+`passHistory.writeStage` controls when a pass-history record is first allowed to exist. Once a record exists, later successful stages update that same record, so `passHistory.eventType` always reflects the furthest successful stage reached by the run.
+
 `passHistory.eventType` semantics:
 
 - `review_passed`
-  Review passed, but no local commit was created because automatic commit is disabled.
+  Review passed, and no later success stage was reached.
 - `commit_completed`
-  Review passed and a local commit was created, but no remote push was performed.
+  Review passed and a local commit was created, but no later push success stage was reached.
 - `commit_push_completed`
   Review passed, a local commit was created, and the current branch was pushed.
 - `null`
   Pass history is disabled or no pass-history record was written.
 
+For example, when `passHistory.writeStage = "commit_completed"`, a successful local commit can still leave `passHistory.eventType = "commit_completed"` if the later push cannot start, fails, or times out. When `passHistory.writeStage = "commit_push_completed"`, those same push failures keep `passHistory.eventType = null` because no record is written.
+
+`pullRequestSummary` is always present in bridge output. When `pullRequestSummary.enabled = true`, the CLI attempts generation only after the review/commit/push action for that run succeeds. Generation failures are reported in `pullRequestSummary.error` and do not change the already successful bridge exit code.
+
 Status semantics:
 
 - `ready`
@@ -112,6 +123,8 @@ Command:
 smart-commit report generate --repo /path/to/repo --period weekly
 ```
 
+Supported `periodType` values are `daily`, `yesterday`, `weekly`, `monthly`, `quarterly`, and `yearly`.
+
 Stable top-level fields:
 
 - `schemaVersion`

package/docs/getting-started.md

@@ -129,6 +129,8 @@ This config is intentionally conservative:
 - `autoCommit=false` prevents creating a local commit
 - `autoPush=false` prevents pushing to remote
 
+The built-in default for `connection.llmResponseCorrectionRetryCount` is already `1`, which means the CLI will allow one extra repair or regeneration pass when a review result or generated commit message fails local protocol validation. Set it to `0` later if you want to disable that behavior.
+
 If you want a fuller example, see `examples/config/smart-commit.json`, but do not copy its side-effect settings blindly for first use.
 
 ## Step 3: Validate The Final Config
@@ -213,6 +215,8 @@ without creating a commit or pushing to remote.
 
 When the review returns a numeric score, the final pass or block result is determined by comparing that score with the configured `review.threshold`.
 
+If your repository is mainly C code, you can switch the built-in review skill with `--code-review-skill-id c-code-review` or `review.skill.id = "c-code-review"`. Built-in `*-code-review` skills load bundled guidance and automatically fall back to generic review rules when the staged diff does not actually match the selected domain.
+
 ## Step 7: Enable Pass History When You Are Ready
 
 If you want reporting later, enable pass history in config or with flags.
@@ -224,16 +228,25 @@ smart-commit bridge \
   --repo . \
   --config ./smart-commit.json \
   --enable-pass-history=true \
+  --pass-history-write-stage=review_passed \
   --no-commit \
   --no-push
 ```
 
 This writes local JSONL history for successful bridge runs.
 
-The stored event type depends on what the bridge actually completed:
+`passHistory.writeStage` controls the earliest successful stage that is allowed to create a record. After that point, the same run updates the same record if it later reaches commit or push success, so the stored `eventType` always reflects the furthest successful stage reached by that run.
+
+- `review_passed` writes as soon as review succeeds
+- `commit_completed` waits until the local commit succeeds
+- `commit_push_completed` waits until both the local commit and push succeed
+
+If you set `commit_completed`, a successful local commit is still preserved even if a later push cannot start, fails, or times out. If you set `commit_push_completed`, those same push failures write nothing.
+
+Stored event types mean:
 
-- `review_passed` when review succeeds but automatic commit is disabled
-- `commit_completed` when a local commit succeeds but automatic push is disabled
+- `review_passed` when review succeeds and no later success stage is reached
+- `commit_completed` when a local commit succeeds and no later push success stage is reached
 - `commit_push_completed` when both local commit and push succeed
 
 ## Step 8: Generate A Report
@@ -245,12 +258,13 @@ smart-commit report generate --repo . --config ./smart-commit.json --period week
 Supported periods:
 
 - `daily`
+- `yesterday`
 - `weekly`
 - `monthly`
 - `quarterly`
 - `yearly`
 
-If `--period` is omitted, the CLI defaults to `weekly`.
+If `--period` is omitted, the CLI defaults to `weekly`. `yesterday` always uses the previous natural local day in local time.
 
 Useful follow-up checks:
 

package/docs/publish.md

@@ -21,7 +21,7 @@ Current package name:
 3. Run `npm run pack:dry-run`
 4. Review [`CHANGELOG.md`](../CHANGELOG.md)
 5. Review [`docs/release-checklist.md`](./release-checklist.md)
-6. Review the matching release draft in [`docs/releases/0.1.5-draft.md`](./releases/0.1.5-draft.md)
+6. Review the matching release draft in [`docs/releases/0.1.7-draft.md`](./releases/0.1.7-draft.md)
 
 ## Recommended Release Order
 

package/docs/releases/0.1.6-draft.md

@@ -0,0 +1,72 @@
+# `smart-commit-copilot-cli` 0.1.6 Draft Release Notes
+
+## Summary
+
+`smart-commit-copilot-cli` 0.1.6 is a Smart Commit behavior-alignment release for the standalone CLI.
+
+This release focuses on bringing the CLI closer to the Smart Commit plugin across review-skill loading, response-correction retries, pass-history lifecycle updates, and reporting windows.
+
+## Highlights
+
+- bundled built-in review skill assets now ship for generic and specialized review profiles, including `c-code-review`
+- specialized review prompts now include diff-domain detection and generic fallback guidance when the selected skill does not match the staged diff
+- `connection.llmResponseCorrectionRetryCount` now controls repair or regeneration retries for review and generated commit-message responses
+- retryable validation now includes requested output-language checks for review summaries, review details, and generated commit-message subjects
+- pass-history writes now upsert a single record across review, commit, and push milestones, gated by configurable `passHistory.writeStage`
+- `report generate` now supports `--period yesterday`
+
+## Why This Release Matters
+
+This version improves real automation reliability and parity with the Smart Commit plugin:
+
+- built-in review skills now behave like real bundled capabilities rather than config-only ids
+- malformed or wrong-language model responses can be retried predictably with an explicit retry budget
+- pass-history consumers now see one upgraded record per successful run instead of duplicate entries across phases
+- local-commit success is preserved correctly even when a later push cannot complete
+- daily reporting workflows can target the previous natural local day directly
+
+## Notable Behavior Updates
+
+### Review skills and prompt guidance
+
+- built-in review skills now load bundled `SKILL.md` instructions and reference material
+- the generic `code-review` skill is available as a bundled asset alongside domain-specific skills
+- `c-code-review` is now part of the supported built-in review skill set
+- specialized review skills use diff-domain classification and fall back to generic review guidance when the staged diff does not match the selected domain
+
+### Response correction and validation
+
+- review-response repair and generated commit-message regeneration now share the same configurable retry budget
+- a retry is triggered only for local protocol, JSON-shape, format, or language validation failures
+- transport, provider, HTTP, and timeout failures still surface directly instead of being retried by this setting
+
+### Pass history and reporting
+
+- `passHistory.writeStage` now controls the earliest successful phase allowed to create a pass-history record
+- once created, the same pass-history record is updated in place as the run advances from review to commit to push success
+- `eventType` now represents the furthest successful stage reached by the run
+- `report generate --period yesterday` now uses the previous natural local day, including cross-month and cross-year boundaries
+
+## Verification Coverage Added Or Strengthened
+
+The project now has stronger regression protection for:
+
+1. review-response repair when the provider returns the wrong language
+2. generated commit-message regeneration when the summary uses the wrong language
+3. schema output for correction retry bounds and built-in review skill exposure
+4. pass-history upsert behavior across review, commit, push-success, push-rejected, and push-timeout branches
+5. CLI-level `report generate --period yesterday`
+
+## Suggested Upgrade Path
+
+1. update to `0.1.6`
+2. run `npm test`
+3. run `npm run smoke:test`
+4. run `npm run pack:dry-run`
+5. publish only after all three checks pass
+
+## Known Follow-Up Areas
+
+- schema-versioning or compatibility strategy if later releases need to evolve the pass-history contract again
+- richer custom local review-skill protocols if CLI-side file-based custom skills need to converge further with the plugin
+- broader remote-aware release validation if publish-time verification grows beyond the current local and test-controlled flows

package/docs/releases/0.1.7-draft.md

@@ -0,0 +1,55 @@
+# `smart-commit-copilot-cli` 0.1.7 Draft Release Notes
+
+## Summary
+
+`smart-commit-copilot-cli` 0.1.7 adds optional pull request description generation to the `bridge` workflow, alongside full configuration and contract support for automation consumers.
+
+This release focuses on turning a successful review-and-commit run into a ready-to-paste PR summary artifact without changing the bridge exit code when summary generation fails.
+
+## Highlights
+
+- opt-in `pullRequestSummary.enabled` with independent `language`, optional `outputDirPath`, and optional free-form `prompt` template guidance
+- generation runs only after the applicable successful `bridge` outcome (review-only, commit, or push, depending on your flow); failures surface in `pullRequestSummary.error` and optional stderr warnings
+- Markdown files use a stable `smart-commit-pr-summary-*.md` naming pattern under the chosen or default output directory
+- legacy `smartCommit.pullRequestSummary*` keys map into the same resolved `pullRequestSummary` object as other Smart Commit settings
+
+## Why This Release Matters
+
+This version closes the loop for teams that open pull requests immediately after local automation:
+
+- hooks and agents can enable one setting and receive a file path in structured JSON output
+- consumers can treat summary failure as telemetry without losing a green bridge result
+- configuration remains consistent with the rest of the CLI resolution order (args, env, file, defaults)
+
+## Notable Behavior Updates
+
+### Pull request summary
+
+- when disabled, bridge output still includes `pullRequestSummary` with `generated: false` and null file or provider fields as appropriate
+- when enabled, the CLI uses the same AI connection as review and commit-message generation; empty or invalid model output is reported without failing the bridge
+- text output includes whether a file was written and any error string for operator visibility
+
+### Commit message skills
+
+- bundled `conventional` and `semantic` skill documentation now explicitly calls out extracting Jira or work item identifiers from the branch when present
+
+## Verification Coverage Added Or Strengthened
+
+The project now has stronger regression protection for:
+
+1. `pullRequestSummary` defaults and legacy key mapping in config resolution
+2. bridge JSON shape and schema output for the new fields
+3. mock-provider success and empty-output failure paths for pull request summary generation
+
+## Suggested Upgrade Path
+
+1. update to `0.1.7`
+2. run `npm test`
+3. run `npm run smoke:test`
+4. run `npm run pack:dry-run`
+5. publish only after all three checks pass
+
+## Known Follow-Up Areas
+
+- richer provider options or templates if teams need multiple PR formats per repository
+- deeper integration tests against real OpenAI-compatible endpoints if mock coverage is not enough for your release bar

package/docs/roadmap.md

@@ -27,7 +27,7 @@ Focus:
 
 Expected stability:
 
-- `schemaVersion: "1.0.0"` machine contracts should remain stable unless there is a strong reason to break them
+- `schemaVersion: "1.1.0"` machine contracts should remain stable unless there is a strong reason to break them
 - `smartCommitCli` remains the canonical config namespace
 - legacy `smartCommit.*` remains compatibility-only
 

package/docs/verification.md

@@ -48,3 +48,18 @@ The smoke test checks these command shapes:
 - The smoke test does not push to a remote
 - The smoke test does not require a real API key value
 - Temporary repositories are created under the system temp directory
+
+## Broader Unit Coverage
+
+For the full regression suite, run:
+
+```bash
+npm test
+```
+
+That suite additionally covers:
+
+- configurable review and commit-message correction retries, including `0` retries and retry exhaustion
+- bundled review-skill loading, including `c-code-review` and diff-domain fallback to generic review
+- pass-history `writeStage` thresholds and same-record `upsert` behavior across review, commit, and push stages
+- `report generate --period yesterday`, including previous-day windows across month and year boundaries