ci(release): keep feat commits on a patch bump below 1.0 - #807

Merged
joryirving merged 1 commit into
mainfrom
ci/patch-bump-below-1.0
Aug 19, 2026
Merged

ci(release): keep feat commits on a patch bump below 1.0#807
joryirving merged 1 commit into
mainfrom
ci/patch-bump-below-1.0

Conversation

@joryirving

@joryirvingjoryirving commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Adds bump-patch-for-minor-pre-major: true so a feat: commit bumps the patch while the project is below 1.0.

Why

The first release-please run wants 0.6.0. That is correct by conventional commits: there are no breaking markers in the unreleased range, and the bump comes entirely from five feat: commits against ten fix:.

It does not match how this repo has actually been versioned. There are 38 consecutive patch releases on 0.5.x going back to at least 2026-07-21, and those ranges contained features. The previous tooling bumped patch regardless of commit type, so release-please is the first thing here to honour feat: as a minor.

A version number should mean the same thing before and after a tooling change. Without this, 0.6.0 reads to a future maintainer as though something significant shipped, when what actually changed is the release mechanism.

bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.

Effect on the pending release

10x fix: -> patch
5x feat: -> patch (was minor)
0 breaking
0.5.38 -> 0.5.39

Note

Applies below 1.0 only. Whenever this repo goes 1.0, both flags stop having any effect and feat: returns to bumping the minor, which is the desired behaviour at that point.

@joryirving
joryirving enabled auto-merge (squash) August 19, 2026 16:24
@joryirving
joryirving merged commit 248fb12 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/patch-bump-below-1.0 branch August 19, 2026 16:26
its-saffron[bot]
its-saffronBot approved these changes Aug 19, 2026
View reviewed changes

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. This is a minimal, well-scoped CI configuration change that adds bump-patch-for-minor-pre-major: true to release-please-config.json. The change is consistent with the repository's actual versioning history and the PR body provides a clear rationale. No blockers or issues found.

Change-by-Change Findings

release-please-config.json (+1 line)

  • Adds bump-patch-for-minor-pre-major: true alongside the existing bump-minor-pre-major: true.
  • This is a valid release-please configuration option. When bump-minor-pre-major is true, this flag causes feat: commits to bump the patch version instead of the minor version while the project is below 1.0.
  • The PR body explains the rationale: the repo has 38 consecutive patch releases on 0.5.x (going back to at least 2026-07-21), and the previous tooling bumped patch regardless of commit type. Without this flag, the first release-please run would produce 0.6.0, which would misrepresent the actual change magnitude.
  • The PR body correctly notes that bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
  • The change is a single-line JSON addition with valid syntax (verified against the full file content).

Sources

  • PR PR 807 body: explains the rationale and expected effect (0.5.38 → 0.5.39).
  • Git history: commit e2d8251 "ci(release): keep feat commits on a patch bump below 1.0" and prior commit 0dd04c9 "ci(release): maintain a standing release PR with release-please (PR 791)" — this PR builds on the existing release-please setup.
  • Repository impact scan: .release-please-manifest.json shows current version 0.5.38, confirming the project is below 1.0 and the flag will apply.
  • CI checks: all passed (Docker Build, Lint, Typecheck, Build, Tests, Coverage, npm audit).

Standards Compliance

This change does not touch application code, environment variables, Prisma schema, or any of the areas covered by the repository standards (AGENTS.md). The change is purely a release tooling configuration. No standards violations identified.

Unknowns or Needs Verification

  • The linked source (release-please config schema at raw.githubusercontent.com) was skipped because it is not on the allowlisted hosts. However, the bump-patch-for-minor-pre-major option is a well-documented release-please configuration option, and the change is consistent with the PR's stated intent. No further verification is needed for this review.
  • No linked issue context was provided for this PR, so no Linked Issue Fit section is applicable.
  • No evidence provider findings were present in the corpus.
  • No tool harness findings were present in the corpus.

@joryirvingjoryirving mentioned this pull request Aug 19, 2026
Merged
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@its-saffronits-saffron[bot]its-saffron[bot] approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
ci(release): keep feat commits on a patch bump below 1.0 - #807
Merged
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Aug 19, 2026
Merged
ci(release): keep feat commits on a patch bump below 1.0#807
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Conversation
@joryirving
@joryirvingjoryirving
commented
Aug 19, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Adds bump-patch-for-minor-pre-major: true so a feat: commit bumps the patch while the project is below 1.0.
Why
The first release-please run wants 0.6.0. That is correct by conventional commits: there are no breaking markers in the unreleased range, and the bump comes entirely from five feat: commits against ten fix:.
It does not match how this repo has actually been versioned. There are 38 consecutive patch releases on 0.5.x going back to at least 2026-07-21, and those ranges contained features. The previous tooling bumped patch regardless of commit type, so release-please is the first thing here to honour feat: as a minor.
A version number should mean the same thing before and after a tooling change. Without this, 0.6.0 reads to a future maintainer as though something significant shipped, when what actually changed is the release mechanism.
bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
Effect on the pending release
10x fix: -> patch
5x feat: -> patch (was minor)
0 breaking
0.5.38 -> 0.5.39

Note
Applies below 1.0 only. Whenever this repo goes 1.0, both flags stop having any effect and feat: returns to bumping the minor, which is the desired behaviour at that point.
@joryirving
joryirving
enabled auto-merge (squash)
August 19, 2026 16:24
@joryirving
joryirving
merged commit 248fb12
into
mainAug 19, 2026

8 checks passed

@joryirving
joryirving
deleted the

ci/patch-bump-below-1.0

branch
August 19, 2026 16:26
its-saffron[bot]
its-saffronBot
approved these changes
Aug 19, 2026
View reviewed changes
@its-saffronits-saffronBot
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review
Full PR review.
Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route
Recommendation
Approve. This is a minimal, well-scoped CI configuration change that adds bump-patch-for-minor-pre-major: true to release-please-config.json. The change is consistent with the repository's actual versioning history and the PR body provides a clear rationale. No blockers or issues found.
Change-by-Change Findings
release-please-config.json (+1 line)
  • Adds bump-patch-for-minor-pre-major: true alongside the existing bump-minor-pre-major: true.
  • This is a valid release-please configuration option. When bump-minor-pre-major is true, this flag causes feat: commits to bump the patch version instead of the minor version while the project is below 1.0.
  • The PR body explains the rationale: the repo has 38 consecutive patch releases on 0.5.x (going back to at least 2026-07-21), and the previous tooling bumped patch regardless of commit type. Without this flag, the first release-please run would produce 0.6.0, which would misrepresent the actual change magnitude.
  • The PR body correctly notes that bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
  • The change is a single-line JSON addition with valid syntax (verified against the full file content).
Sources
  • PR PR 807 body: explains the rationale and expected effect (0.5.38 → 0.5.39).
  • Git history: commit e2d8251 "ci(release): keep feat commits on a patch bump below 1.0" and prior commit 0dd04c9 "ci(release): maintain a standing release PR with release-please (PR 791)" — this PR builds on the existing release-please setup.
  • Repository impact scan: .release-please-manifest.json shows current version 0.5.38, confirming the project is below 1.0 and the flag will apply.
  • CI checks: all passed (Docker Build, Lint, Typecheck, Build, Tests, Coverage, npm audit).
Standards Compliance
This change does not touch application code, environment variables, Prisma schema, or any of the areas covered by the repository standards (AGENTS.md). The change is purely a release tooling configuration. No standards violations identified.
Unknowns or Needs Verification
  • The linked source (release-please config schema at raw.githubusercontent.com) was skipped because it is not on the allowlisted hosts. However, the bump-patch-for-minor-pre-major option is a well-documented release-please configuration option, and the change is consistent with the PR's stated intent. No further verification is needed for this review.
  • No linked issue context was provided for this PR, so no Linked Issue Fit section is applicable.
  • No evidence provider findings were present in the corpus.
  • No tool harness findings were present in the corpus.
@joryirvingjoryirving
mentioned this pull request
Aug 19, 2026
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@its-saffronits-saffron[bot]its-saffron[bot] approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ci(release): keep feat commits on a patch bump below 1.0 - #807
Merged
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Aug 19, 2026
Merged
ci(release): keep feat commits on a patch bump below 1.0#807
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Conversation
@joryirving
@joryirvingjoryirving
commented
Aug 19, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Adds bump-patch-for-minor-pre-major: true so a feat: commit bumps the patch while the project is below 1.0.
Why
The first release-please run wants 0.6.0. That is correct by conventional commits: there are no breaking markers in the unreleased range, and the bump comes entirely from five feat: commits against ten fix:.
It does not match how this repo has actually been versioned. There are 38 consecutive patch releases on 0.5.x going back to at least 2026-07-21, and those ranges contained features. The previous tooling bumped patch regardless of commit type, so release-please is the first thing here to honour feat: as a minor.
A version number should mean the same thing before and after a tooling change. Without this, 0.6.0 reads to a future maintainer as though something significant shipped, when what actually changed is the release mechanism.
bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
Effect on the pending release
10x fix: -> patch
5x feat: -> patch (was minor)
0 breaking
0.5.38 -> 0.5.39

Note
Applies below 1.0 only. Whenever this repo goes 1.0, both flags stop having any effect and feat: returns to bumping the minor, which is the desired behaviour at that point.
@joryirving
joryirving
enabled auto-merge (squash)
August 19, 2026 16:24
@joryirving
joryirving
merged commit 248fb12
into
mainAug 19, 2026

8 checks passed

@joryirving
joryirving
deleted the

ci/patch-bump-below-1.0

branch
August 19, 2026 16:26
its-saffron[bot]
its-saffronBot
approved these changes
Aug 19, 2026
View reviewed changes
@its-saffronits-saffronBot
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review
Full PR review.
Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route
Recommendation
Approve. This is a minimal, well-scoped CI configuration change that adds bump-patch-for-minor-pre-major: true to release-please-config.json. The change is consistent with the repository's actual versioning history and the PR body provides a clear rationale. No blockers or issues found.
Change-by-Change Findings
release-please-config.json (+1 line)
  • Adds bump-patch-for-minor-pre-major: true alongside the existing bump-minor-pre-major: true.
  • This is a valid release-please configuration option. When bump-minor-pre-major is true, this flag causes feat: commits to bump the patch version instead of the minor version while the project is below 1.0.
  • The PR body explains the rationale: the repo has 38 consecutive patch releases on 0.5.x (going back to at least 2026-07-21), and the previous tooling bumped patch regardless of commit type. Without this flag, the first release-please run would produce 0.6.0, which would misrepresent the actual change magnitude.
  • The PR body correctly notes that bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
  • The change is a single-line JSON addition with valid syntax (verified against the full file content).
Sources
  • PR PR 807 body: explains the rationale and expected effect (0.5.38 → 0.5.39).
  • Git history: commit e2d8251 "ci(release): keep feat commits on a patch bump below 1.0" and prior commit 0dd04c9 "ci(release): maintain a standing release PR with release-please (PR 791)" — this PR builds on the existing release-please setup.
  • Repository impact scan: .release-please-manifest.json shows current version 0.5.38, confirming the project is below 1.0 and the flag will apply.
  • CI checks: all passed (Docker Build, Lint, Typecheck, Build, Tests, Coverage, npm audit).
Standards Compliance
This change does not touch application code, environment variables, Prisma schema, or any of the areas covered by the repository standards (AGENTS.md). The change is purely a release tooling configuration. No standards violations identified.
Unknowns or Needs Verification
  • The linked source (release-please config schema at raw.githubusercontent.com) was skipped because it is not on the allowlisted hosts. However, the bump-patch-for-minor-pre-major option is a well-documented release-please configuration option, and the change is consistent with the PR's stated intent. No further verification is needed for this review.
  • No linked issue context was provided for this PR, so no Linked Issue Fit section is applicable.
  • No evidence provider findings were present in the corpus.
  • No tool harness findings were present in the corpus.
@joryirvingjoryirving
mentioned this pull request
Aug 19, 2026
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@its-saffronits-saffron[bot]its-saffron[bot] approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ci(release): keep feat commits on a patch bump below 1.0 - #807
Merged
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Aug 19, 2026
Merged
ci(release): keep feat commits on a patch bump below 1.0#807
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Conversation
@joryirving
@joryirvingjoryirving
commented
Aug 19, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Adds bump-patch-for-minor-pre-major: true so a feat: commit bumps the patch while the project is below 1.0.
Why
The first release-please run wants 0.6.0. That is correct by conventional commits: there are no breaking markers in the unreleased range, and the bump comes entirely from five feat: commits against ten fix:.
It does not match how this repo has actually been versioned. There are 38 consecutive patch releases on 0.5.x going back to at least 2026-07-21, and those ranges contained features. The previous tooling bumped patch regardless of commit type, so release-please is the first thing here to honour feat: as a minor.
A version number should mean the same thing before and after a tooling change. Without this, 0.6.0 reads to a future maintainer as though something significant shipped, when what actually changed is the release mechanism.
bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
Effect on the pending release
10x fix: -> patch
5x feat: -> patch (was minor)
0 breaking
0.5.38 -> 0.5.39

Note
Applies below 1.0 only. Whenever this repo goes 1.0, both flags stop having any effect and feat: returns to bumping the minor, which is the desired behaviour at that point.
@joryirving
joryirving
enabled auto-merge (squash)
August 19, 2026 16:24
@joryirving
joryirving
merged commit 248fb12
into
mainAug 19, 2026

8 checks passed

@joryirving
joryirving
deleted the

ci/patch-bump-below-1.0

branch
August 19, 2026 16:26
its-saffron[bot]
its-saffronBot
approved these changes
Aug 19, 2026
View reviewed changes
@its-saffronits-saffronBot
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review
Full PR review.
Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route
Recommendation
Approve. This is a minimal, well-scoped CI configuration change that adds bump-patch-for-minor-pre-major: true to release-please-config.json. The change is consistent with the repository's actual versioning history and the PR body provides a clear rationale. No blockers or issues found.
Change-by-Change Findings
release-please-config.json (+1 line)
  • Adds bump-patch-for-minor-pre-major: true alongside the existing bump-minor-pre-major: true.
  • This is a valid release-please configuration option. When bump-minor-pre-major is true, this flag causes feat: commits to bump the patch version instead of the minor version while the project is below 1.0.
  • The PR body explains the rationale: the repo has 38 consecutive patch releases on 0.5.x (going back to at least 2026-07-21), and the previous tooling bumped patch regardless of commit type. Without this flag, the first release-please run would produce 0.6.0, which would misrepresent the actual change magnitude.
  • The PR body correctly notes that bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
  • The change is a single-line JSON addition with valid syntax (verified against the full file content).
Sources
  • PR PR 807 body: explains the rationale and expected effect (0.5.38 → 0.5.39).
  • Git history: commit e2d8251 "ci(release): keep feat commits on a patch bump below 1.0" and prior commit 0dd04c9 "ci(release): maintain a standing release PR with release-please (PR 791)" — this PR builds on the existing release-please setup.
  • Repository impact scan: .release-please-manifest.json shows current version 0.5.38, confirming the project is below 1.0 and the flag will apply.
  • CI checks: all passed (Docker Build, Lint, Typecheck, Build, Tests, Coverage, npm audit).
Standards Compliance
This change does not touch application code, environment variables, Prisma schema, or any of the areas covered by the repository standards (AGENTS.md). The change is purely a release tooling configuration. No standards violations identified.
Unknowns or Needs Verification
  • The linked source (release-please config schema at raw.githubusercontent.com) was skipped because it is not on the allowlisted hosts. However, the bump-patch-for-minor-pre-major option is a well-documented release-please configuration option, and the change is consistent with the PR's stated intent. No further verification is needed for this review.
  • No linked issue context was provided for this PR, so no Linked Issue Fit section is applicable.
  • No evidence provider findings were present in the corpus.
  • No tool harness findings were present in the corpus.
@joryirvingjoryirving
mentioned this pull request
Aug 19, 2026
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@its-saffronits-saffron[bot]its-saffron[bot] approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
ci(release): keep feat commits on a patch bump below 1.0 - #807
Merged
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Aug 19, 2026
Merged
ci(release): keep feat commits on a patch bump below 1.0#807
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Conversation
@joryirving
@joryirvingjoryirving
commented
Aug 19, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Adds bump-patch-for-minor-pre-major: true so a feat: commit bumps the patch while the project is below 1.0.
Why
The first release-please run wants 0.6.0. That is correct by conventional commits: there are no breaking markers in the unreleased range, and the bump comes entirely from five feat: commits against ten fix:.
It does not match how this repo has actually been versioned. There are 38 consecutive patch releases on 0.5.x going back to at least 2026-07-21, and those ranges contained features. The previous tooling bumped patch regardless of commit type, so release-please is the first thing here to honour feat: as a minor.
A version number should mean the same thing before and after a tooling change. Without this, 0.6.0 reads to a future maintainer as though something significant shipped, when what actually changed is the release mechanism.
bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
Effect on the pending release
10x fix: -> patch
5x feat: -> patch (was minor)
0 breaking
0.5.38 -> 0.5.39

Note
Applies below 1.0 only. Whenever this repo goes 1.0, both flags stop having any effect and feat: returns to bumping the minor, which is the desired behaviour at that point.
@joryirving
joryirving
enabled auto-merge (squash)
August 19, 2026 16:24
@joryirving
joryirving
merged commit 248fb12
into
mainAug 19, 2026

8 checks passed

@joryirving
joryirving
deleted the

ci/patch-bump-below-1.0

branch
August 19, 2026 16:26
its-saffron[bot]
its-saffronBot
approved these changes
Aug 19, 2026
View reviewed changes
@its-saffronits-saffronBot
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review
Full PR review.
Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route
Recommendation
Approve. This is a minimal, well-scoped CI configuration change that adds bump-patch-for-minor-pre-major: true to release-please-config.json. The change is consistent with the repository's actual versioning history and the PR body provides a clear rationale. No blockers or issues found.
Change-by-Change Findings
release-please-config.json (+1 line)
  • Adds bump-patch-for-minor-pre-major: true alongside the existing bump-minor-pre-major: true.
  • This is a valid release-please configuration option. When bump-minor-pre-major is true, this flag causes feat: commits to bump the patch version instead of the minor version while the project is below 1.0.
  • The PR body explains the rationale: the repo has 38 consecutive patch releases on 0.5.x (going back to at least 2026-07-21), and the previous tooling bumped patch regardless of commit type. Without this flag, the first release-please run would produce 0.6.0, which would misrepresent the actual change magnitude.
  • The PR body correctly notes that bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
  • The change is a single-line JSON addition with valid syntax (verified against the full file content).
Sources
  • PR PR 807 body: explains the rationale and expected effect (0.5.38 → 0.5.39).
  • Git history: commit e2d8251 "ci(release): keep feat commits on a patch bump below 1.0" and prior commit 0dd04c9 "ci(release): maintain a standing release PR with release-please (PR 791)" — this PR builds on the existing release-please setup.
  • Repository impact scan: .release-please-manifest.json shows current version 0.5.38, confirming the project is below 1.0 and the flag will apply.
  • CI checks: all passed (Docker Build, Lint, Typecheck, Build, Tests, Coverage, npm audit).
Standards Compliance
This change does not touch application code, environment variables, Prisma schema, or any of the areas covered by the repository standards (AGENTS.md). The change is purely a release tooling configuration. No standards violations identified.
Unknowns or Needs Verification
  • The linked source (release-please config schema at raw.githubusercontent.com) was skipped because it is not on the allowlisted hosts. However, the bump-patch-for-minor-pre-major option is a well-documented release-please configuration option, and the change is consistent with the PR's stated intent. No further verification is needed for this review.
  • No linked issue context was provided for this PR, so no Linked Issue Fit section is applicable.
  • No evidence provider findings were present in the corpus.
  • No tool harness findings were present in the corpus.
@joryirvingjoryirving
mentioned this pull request
Aug 19, 2026
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@its-saffronits-saffron[bot]its-saffron[bot] approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ci(release): keep feat commits on a patch bump below 1.0 - #807
Merged
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Aug 19, 2026
Merged
ci(release): keep feat commits on a patch bump below 1.0#807
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Conversation
@joryirving
@joryirvingjoryirving
commented
Aug 19, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Adds bump-patch-for-minor-pre-major: true so a feat: commit bumps the patch while the project is below 1.0.
Why
The first release-please run wants 0.6.0. That is correct by conventional commits: there are no breaking markers in the unreleased range, and the bump comes entirely from five feat: commits against ten fix:.
It does not match how this repo has actually been versioned. There are 38 consecutive patch releases on 0.5.x going back to at least 2026-07-21, and those ranges contained features. The previous tooling bumped patch regardless of commit type, so release-please is the first thing here to honour feat: as a minor.
A version number should mean the same thing before and after a tooling change. Without this, 0.6.0 reads to a future maintainer as though something significant shipped, when what actually changed is the release mechanism.
bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
Effect on the pending release
10x fix: -> patch
5x feat: -> patch (was minor)
0 breaking
0.5.38 -> 0.5.39

Note
Applies below 1.0 only. Whenever this repo goes 1.0, both flags stop having any effect and feat: returns to bumping the minor, which is the desired behaviour at that point.
@joryirving
joryirving
enabled auto-merge (squash)
August 19, 2026 16:24
@joryirving
joryirving
merged commit 248fb12
into
mainAug 19, 2026

8 checks passed

@joryirving
joryirving
deleted the

ci/patch-bump-below-1.0

branch
August 19, 2026 16:26
its-saffron[bot]
its-saffronBot
approved these changes
Aug 19, 2026
View reviewed changes
@its-saffronits-saffronBot
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review
Full PR review.
Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route
Recommendation
Approve. This is a minimal, well-scoped CI configuration change that adds bump-patch-for-minor-pre-major: true to release-please-config.json. The change is consistent with the repository's actual versioning history and the PR body provides a clear rationale. No blockers or issues found.
Change-by-Change Findings
release-please-config.json (+1 line)
  • Adds bump-patch-for-minor-pre-major: true alongside the existing bump-minor-pre-major: true.
  • This is a valid release-please configuration option. When bump-minor-pre-major is true, this flag causes feat: commits to bump the patch version instead of the minor version while the project is below 1.0.
  • The PR body explains the rationale: the repo has 38 consecutive patch releases on 0.5.x (going back to at least 2026-07-21), and the previous tooling bumped patch regardless of commit type. Without this flag, the first release-please run would produce 0.6.0, which would misrepresent the actual change magnitude.
  • The PR body correctly notes that bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
  • The change is a single-line JSON addition with valid syntax (verified against the full file content).
Sources
  • PR PR 807 body: explains the rationale and expected effect (0.5.38 → 0.5.39).
  • Git history: commit e2d8251 "ci(release): keep feat commits on a patch bump below 1.0" and prior commit 0dd04c9 "ci(release): maintain a standing release PR with release-please (PR 791)" — this PR builds on the existing release-please setup.
  • Repository impact scan: .release-please-manifest.json shows current version 0.5.38, confirming the project is below 1.0 and the flag will apply.
  • CI checks: all passed (Docker Build, Lint, Typecheck, Build, Tests, Coverage, npm audit).
Standards Compliance
This change does not touch application code, environment variables, Prisma schema, or any of the areas covered by the repository standards (AGENTS.md). The change is purely a release tooling configuration. No standards violations identified.
Unknowns or Needs Verification
  • The linked source (release-please config schema at raw.githubusercontent.com) was skipped because it is not on the allowlisted hosts. However, the bump-patch-for-minor-pre-major option is a well-documented release-please configuration option, and the change is consistent with the PR's stated intent. No further verification is needed for this review.
  • No linked issue context was provided for this PR, so no Linked Issue Fit section is applicable.
  • No evidence provider findings were present in the corpus.
  • No tool harness findings were present in the corpus.
@joryirvingjoryirving
mentioned this pull request
Aug 19, 2026
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@its-saffronits-saffron[bot]its-saffron[bot] approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ci(release): keep feat commits on a patch bump below 1.0 - #807
Merged
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Aug 19, 2026
Merged
ci(release): keep feat commits on a patch bump below 1.0#807
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Conversation
@joryirving
@joryirvingjoryirving
commented
Aug 19, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Adds bump-patch-for-minor-pre-major: true so a feat: commit bumps the patch while the project is below 1.0.
Why
The first release-please run wants 0.6.0. That is correct by conventional commits: there are no breaking markers in the unreleased range, and the bump comes entirely from five feat: commits against ten fix:.
It does not match how this repo has actually been versioned. There are 38 consecutive patch releases on 0.5.x going back to at least 2026-07-21, and those ranges contained features. The previous tooling bumped patch regardless of commit type, so release-please is the first thing here to honour feat: as a minor.
A version number should mean the same thing before and after a tooling change. Without this, 0.6.0 reads to a future maintainer as though something significant shipped, when what actually changed is the release mechanism.
bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
Effect on the pending release
10x fix: -> patch
5x feat: -> patch (was minor)
0 breaking
0.5.38 -> 0.5.39

Note
Applies below 1.0 only. Whenever this repo goes 1.0, both flags stop having any effect and feat: returns to bumping the minor, which is the desired behaviour at that point.
@joryirving
joryirving
enabled auto-merge (squash)
August 19, 2026 16:24
@joryirving
joryirving
merged commit 248fb12
into
mainAug 19, 2026

8 checks passed

@joryirving
joryirving
deleted the

ci/patch-bump-below-1.0

branch
August 19, 2026 16:26
its-saffron[bot]
its-saffronBot
approved these changes
Aug 19, 2026
View reviewed changes
@its-saffronits-saffronBot
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review
Full PR review.
Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route
Recommendation
Approve. This is a minimal, well-scoped CI configuration change that adds bump-patch-for-minor-pre-major: true to release-please-config.json. The change is consistent with the repository's actual versioning history and the PR body provides a clear rationale. No blockers or issues found.
Change-by-Change Findings
release-please-config.json (+1 line)
  • Adds bump-patch-for-minor-pre-major: true alongside the existing bump-minor-pre-major: true.
  • This is a valid release-please configuration option. When bump-minor-pre-major is true, this flag causes feat: commits to bump the patch version instead of the minor version while the project is below 1.0.
  • The PR body explains the rationale: the repo has 38 consecutive patch releases on 0.5.x (going back to at least 2026-07-21), and the previous tooling bumped patch regardless of commit type. Without this flag, the first release-please run would produce 0.6.0, which would misrepresent the actual change magnitude.
  • The PR body correctly notes that bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
  • The change is a single-line JSON addition with valid syntax (verified against the full file content).
Sources
  • PR PR 807 body: explains the rationale and expected effect (0.5.38 → 0.5.39).
  • Git history: commit e2d8251 "ci(release): keep feat commits on a patch bump below 1.0" and prior commit 0dd04c9 "ci(release): maintain a standing release PR with release-please (PR 791)" — this PR builds on the existing release-please setup.
  • Repository impact scan: .release-please-manifest.json shows current version 0.5.38, confirming the project is below 1.0 and the flag will apply.
  • CI checks: all passed (Docker Build, Lint, Typecheck, Build, Tests, Coverage, npm audit).
Standards Compliance
This change does not touch application code, environment variables, Prisma schema, or any of the areas covered by the repository standards (AGENTS.md). The change is purely a release tooling configuration. No standards violations identified.
Unknowns or Needs Verification
  • The linked source (release-please config schema at raw.githubusercontent.com) was skipped because it is not on the allowlisted hosts. However, the bump-patch-for-minor-pre-major option is a well-documented release-please configuration option, and the change is consistent with the PR's stated intent. No further verification is needed for this review.
  • No linked issue context was provided for this PR, so no Linked Issue Fit section is applicable.
  • No evidence provider findings were present in the corpus.
  • No tool harness findings were present in the corpus.
@joryirvingjoryirving
mentioned this pull request
Aug 19, 2026
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@its-saffronits-saffron[bot]its-saffron[bot] approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
ci(release): keep feat commits on a patch bump below 1.0 - #807
Merged
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Aug 19, 2026
Merged
ci(release): keep feat commits on a patch bump below 1.0#807
joryirving merged 1 commit into
mainfrom 
ci/patch-bump-below-1.0
Conversation
@joryirving
@joryirvingjoryirving
commented
Aug 19, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Adds bump-patch-for-minor-pre-major: true so a feat: commit bumps the patch while the project is below 1.0.
Why
The first release-please run wants 0.6.0. That is correct by conventional commits: there are no breaking markers in the unreleased range, and the bump comes entirely from five feat: commits against ten fix:.
It does not match how this repo has actually been versioned. There are 38 consecutive patch releases on 0.5.x going back to at least 2026-07-21, and those ranges contained features. The previous tooling bumped patch regardless of commit type, so release-please is the first thing here to honour feat: as a minor.
A version number should mean the same thing before and after a tooling change. Without this, 0.6.0 reads to a future maintainer as though something significant shipped, when what actually changed is the release mechanism.
bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
Effect on the pending release
10x fix: -> patch
5x feat: -> patch (was minor)
0 breaking
0.5.38 -> 0.5.39

Note
Applies below 1.0 only. Whenever this repo goes 1.0, both flags stop having any effect and feat: returns to bumping the minor, which is the desired behaviour at that point.
@joryirving
joryirving
enabled auto-merge (squash)
August 19, 2026 16:24
@joryirving
joryirving
merged commit 248fb12
into
mainAug 19, 2026

8 checks passed

@joryirving
joryirving
deleted the

ci/patch-bump-below-1.0

branch
August 19, 2026 16:26
its-saffron[bot]
its-saffronBot
approved these changes
Aug 19, 2026
View reviewed changes
@its-saffronits-saffronBot
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review
Full PR review.
Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route
Recommendation
Approve. This is a minimal, well-scoped CI configuration change that adds bump-patch-for-minor-pre-major: true to release-please-config.json. The change is consistent with the repository's actual versioning history and the PR body provides a clear rationale. No blockers or issues found.
Change-by-Change Findings
release-please-config.json (+1 line)
  • Adds bump-patch-for-minor-pre-major: true alongside the existing bump-minor-pre-major: true.
  • This is a valid release-please configuration option. When bump-minor-pre-major is true, this flag causes feat: commits to bump the patch version instead of the minor version while the project is below 1.0.
  • The PR body explains the rationale: the repo has 38 consecutive patch releases on 0.5.x (going back to at least 2026-07-21), and the previous tooling bumped patch regardless of commit type. Without this flag, the first release-please run would produce 0.6.0, which would misrepresent the actual change magnitude.
  • The PR body correctly notes that bump-minor-pre-major: true stays, so a genuine breaking change still takes the minor rather than promoting to 1.0.0.
  • The change is a single-line JSON addition with valid syntax (verified against the full file content).
Sources
  • PR PR 807 body: explains the rationale and expected effect (0.5.38 → 0.5.39).
  • Git history: commit e2d8251 "ci(release): keep feat commits on a patch bump below 1.0" and prior commit 0dd04c9 "ci(release): maintain a standing release PR with release-please (PR 791)" — this PR builds on the existing release-please setup.
  • Repository impact scan: .release-please-manifest.json shows current version 0.5.38, confirming the project is below 1.0 and the flag will apply.
  • CI checks: all passed (Docker Build, Lint, Typecheck, Build, Tests, Coverage, npm audit).
Standards Compliance
This change does not touch application code, environment variables, Prisma schema, or any of the areas covered by the repository standards (AGENTS.md). The change is purely a release tooling configuration. No standards violations identified.
Unknowns or Needs Verification
  • The linked source (release-please config schema at raw.githubusercontent.com) was skipped because it is not on the allowlisted hosts. However, the bump-patch-for-minor-pre-major option is a well-documented release-please configuration option, and the change is consistent with the PR's stated intent. No further verification is needed for this review.
  • No linked issue context was provided for this PR, so no Linked Issue Fit section is applicable.
  • No evidence provider findings were present in the corpus.
  • No tool harness findings were present in the corpus.
@joryirvingjoryirving
mentioned this pull request
Aug 19, 2026
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@its-saffronits-saffron[bot]its-saffron[bot] approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving