Skip to content

feat(providers): centralize provider registry - #866

Merged
Astro-Han merged 3 commits into
mainfrom
feat/issue-860-provider-registry
Jul 13, 2026
Merged

feat(providers): centralize provider registry#866
Astro-Han merged 3 commits into
mainfrom
feat/issue-860-provider-registry

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Make the shared provider registry the authoritative source for provider defaults, catalog placement, recommendations, runtime adapter selection, and model discovery behavior.
  • Derive provider ids and ordered provider sets from registry entries while preserving all existing persisted ids and ordering.
  • Migrate Settings and runtime consumers to registry metadata without changing provider behavior.

Why

Issue #860 requires one generic provider extension path before the remaining provider workstreams can proceed. The current implementation still distributes provider behavior across hand-maintained lists and provider-specific runtime branches, which makes each new provider require parallel edits.

This change completes the Phase 2 registry foundation while preserving existing connections and behavior.

Refs #860

Scope

This PR only implements Phase 2.

It does not add Phase 3–5 providers, change first-run onboarding, or redesign existing OAuth account flows. Onboarding continues to use its current list until Phase 6 consumes the shared recommended set.

Verification

  • npm run typecheck
  • npm test
  • npm --workspace @maka/desktop run e2e — 13 passed
  • npm run check:stale — dist is fresh

No visual evidence is included because this is a behavior-preserving registry migration with no intended UI or interaction changes. The existing provider Settings E2E flow verifies the affected catalog path.

Impact

Existing persisted provider ids, provider ordering, defaults, runtime routing, discovery behavior, and visible Settings behavior remain compatible. No data migration, documentation update, or release-note entry is required.

Reviewer notes

PROVIDER_DEFAULTS remains as a compatibility alias to the same registry object; it does not create a second source of state. The two commits are independently revertible: the first establishes and migrates the shared registry/runtime seam, and the second moves Settings catalog recommendations and placement onto that seam.

Ready for review

  • Verification is complete and the results above are current
  • Impact, compatibility, migration, documentation, and release-note needs are addressed
  • User-visible UI/UX changes include visual evidence, or Verification explains why it is not applicable

@Astro-Han
Astro-Han marked this pull request as ready for review July 13, 2026 11:57
@Astro-Han
Astro-Han merged commit 24d8f20 into mainJul 13, 2026
3 checks passed
@Astro-Han
Astro-Han deleted the feat/issue-860-provider-registry branch July 13, 2026 11:57
This was referenced Jul 13, 2026
Closed
Merged
Merged
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

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

@Astro-Han
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
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;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
feat(providers): centralize provider registry by Astro-Han · Pull Request #866 · apache/maka · GitHub
Skip to content
feat(providers): centralize provider registry - #866
Merged
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Jul 13, 2026
Merged
feat(providers): centralize provider registry#866
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Conversation
@Astro-Han
@Astro-HanAstro-Han
commented
Jul 13, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Make the shared provider registry the authoritative source for provider defaults, catalog placement, recommendations, runtime adapter selection, and model discovery behavior.
  • Derive provider ids and ordered provider sets from registry entries while preserving all existing persisted ids and ordering.
  • Migrate Settings and runtime consumers to registry metadata without changing provider behavior.
Why
Issue #860 requires one generic provider extension path before the remaining provider workstreams can proceed. The current implementation still distributes provider behavior across hand-maintained lists and provider-specific runtime branches, which makes each new provider require parallel edits.
This change completes the Phase 2 registry foundation while preserving existing connections and behavior.
Refs #860
Scope
This PR only implements Phase 2.
It does not add Phase 3–5 providers, change first-run onboarding, or redesign existing OAuth account flows. Onboarding continues to use its current list until Phase 6 consumes the shared recommended set.
Verification
  • npm run typecheck
  • npm test
  • npm --workspace @maka/desktop run e2e — 13 passed
  • npm run check:stale — dist is fresh
No visual evidence is included because this is a behavior-preserving registry migration with no intended UI or interaction changes. The existing provider Settings E2E flow verifies the affected catalog path.
Impact
Existing persisted provider ids, provider ordering, defaults, runtime routing, discovery behavior, and visible Settings behavior remain compatible. No data migration, documentation update, or release-note entry is required.
Reviewer notes
PROVIDER_DEFAULTS remains as a compatibility alias to the same registry object; it does not create a second source of state. The two commits are independently revertible: the first establishes and migrates the shared registry/runtime seam, and the second moves Settings catalog recommendations and placement onto that seam.
Ready for review
  •  Verification is complete and the results above are current
  •  Impact, compatibility, migration, documentation, and release-note needs are addressed
  •  User-visible UI/UX changes include visual evidence, or Verification explains why it is not applicable
@Astro-Han
Astro-Han
marked this pull request as ready for review
July 13, 2026 11:57
@Astro-Han
Astro-Han
merged commit 24d8f20
into
mainJul 13, 2026

3 checks passed

@Astro-Han
Astro-Han
deleted the

feat/issue-860-provider-registry

branch
July 13, 2026 11:57

This was referenced Jul 13, 2026

Closed

 Merged

 Merged

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

Reviewers


No reviews


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

@Astro-Han

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
feat(providers): centralize provider registry by Astro-Han · Pull Request #866 · apache/maka · GitHub
Skip to content
feat(providers): centralize provider registry - #866
Merged
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Jul 13, 2026
Merged
feat(providers): centralize provider registry#866
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Conversation
@Astro-Han
@Astro-HanAstro-Han
commented
Jul 13, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Make the shared provider registry the authoritative source for provider defaults, catalog placement, recommendations, runtime adapter selection, and model discovery behavior.
  • Derive provider ids and ordered provider sets from registry entries while preserving all existing persisted ids and ordering.
  • Migrate Settings and runtime consumers to registry metadata without changing provider behavior.
Why
Issue #860 requires one generic provider extension path before the remaining provider workstreams can proceed. The current implementation still distributes provider behavior across hand-maintained lists and provider-specific runtime branches, which makes each new provider require parallel edits.
This change completes the Phase 2 registry foundation while preserving existing connections and behavior.
Refs #860
Scope
This PR only implements Phase 2.
It does not add Phase 3–5 providers, change first-run onboarding, or redesign existing OAuth account flows. Onboarding continues to use its current list until Phase 6 consumes the shared recommended set.
Verification
  • npm run typecheck
  • npm test
  • npm --workspace @maka/desktop run e2e — 13 passed
  • npm run check:stale — dist is fresh
No visual evidence is included because this is a behavior-preserving registry migration with no intended UI or interaction changes. The existing provider Settings E2E flow verifies the affected catalog path.
Impact
Existing persisted provider ids, provider ordering, defaults, runtime routing, discovery behavior, and visible Settings behavior remain compatible. No data migration, documentation update, or release-note entry is required.
Reviewer notes
PROVIDER_DEFAULTS remains as a compatibility alias to the same registry object; it does not create a second source of state. The two commits are independently revertible: the first establishes and migrates the shared registry/runtime seam, and the second moves Settings catalog recommendations and placement onto that seam.
Ready for review
  •  Verification is complete and the results above are current
  •  Impact, compatibility, migration, documentation, and release-note needs are addressed
  •  User-visible UI/UX changes include visual evidence, or Verification explains why it is not applicable
@Astro-Han
Astro-Han
marked this pull request as ready for review
July 13, 2026 11:57
@Astro-Han
Astro-Han
merged commit 24d8f20
into
mainJul 13, 2026

3 checks passed

@Astro-Han
Astro-Han
deleted the

feat/issue-860-provider-registry

branch
July 13, 2026 11:57

This was referenced Jul 13, 2026

Closed

 Merged

 Merged

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

Reviewers


No reviews


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

@Astro-Han

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

Copy link


Copy Markdown

Contributor
Summary
  • Make the shared provider registry the authoritative source for provider defaults, catalog placement, recommendations, runtime adapter selection, and model discovery behavior.
  • Derive provider ids and ordered provider sets from registry entries while preserving all existing persisted ids and ordering.
  • Migrate Settings and runtime consumers to registry metadata without changing provider behavior.
Why
Issue #860 requires one generic provider extension path before the remaining provider workstreams can proceed. The current implementation still distributes provider behavior across hand-maintained lists and provider-specific runtime branches, which makes each new provider require parallel edits.
This change completes the Phase 2 registry foundation while preserving existing connections and behavior.
Refs #860
Scope
This PR only implements Phase 2.
It does not add Phase 3–5 providers, change first-run onboarding, or redesign existing OAuth account flows. Onboarding continues to use its current list until Phase 6 consumes the shared recommended set.
Verification
  • npm run typecheck
  • npm test
  • npm --workspace @maka/desktop run e2e — 13 passed
  • npm run check:stale — dist is fresh
No visual evidence is included because this is a behavior-preserving registry migration with no intended UI or interaction changes. The existing provider Settings E2E flow verifies the affected catalog path.
Impact
Existing persisted provider ids, provider ordering, defaults, runtime routing, discovery behavior, and visible Settings behavior remain compatible. No data migration, documentation update, or release-note entry is required.
Reviewer notes
PROVIDER_DEFAULTS remains as a compatibility alias to the same registry object; it does not create a second source of state. The two commits are independently revertible: the first establishes and migrates the shared registry/runtime seam, and the second moves Settings catalog recommendations and placement onto that seam.
Ready for review
  •  Verification is complete and the results above are current
  •  Impact, compatibility, migration, documentation, and release-note needs are addressed
  •  User-visible UI/UX changes include visual evidence, or Verification explains why it is not applicable
@Astro-Han
Astro-Han
marked this pull request as ready for review
July 13, 2026 11:57
@Astro-Han
Astro-Han
merged commit 24d8f20
into
mainJul 13, 2026

3 checks passed

@Astro-Han
Astro-Han
deleted the

feat/issue-860-provider-registry

branch
July 13, 2026 11:57

This was referenced Jul 13, 2026

Closed

 Merged

 Merged

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

Reviewers


No reviews


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

@Astro-Han

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
feat(providers): centralize provider registry by Astro-Han · Pull Request #866 · apache/maka · GitHub
Skip to content
feat(providers): centralize provider registry - #866
Merged
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Jul 13, 2026
Merged
feat(providers): centralize provider registry#866
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Conversation
@Astro-Han
@Astro-HanAstro-Han
commented
Jul 13, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Make the shared provider registry the authoritative source for provider defaults, catalog placement, recommendations, runtime adapter selection, and model discovery behavior.
  • Derive provider ids and ordered provider sets from registry entries while preserving all existing persisted ids and ordering.
  • Migrate Settings and runtime consumers to registry metadata without changing provider behavior.
Why
Issue #860 requires one generic provider extension path before the remaining provider workstreams can proceed. The current implementation still distributes provider behavior across hand-maintained lists and provider-specific runtime branches, which makes each new provider require parallel edits.
This change completes the Phase 2 registry foundation while preserving existing connections and behavior.
Refs #860
Scope
This PR only implements Phase 2.
It does not add Phase 3–5 providers, change first-run onboarding, or redesign existing OAuth account flows. Onboarding continues to use its current list until Phase 6 consumes the shared recommended set.
Verification
  • npm run typecheck
  • npm test
  • npm --workspace @maka/desktop run e2e — 13 passed
  • npm run check:stale — dist is fresh
No visual evidence is included because this is a behavior-preserving registry migration with no intended UI or interaction changes. The existing provider Settings E2E flow verifies the affected catalog path.
Impact
Existing persisted provider ids, provider ordering, defaults, runtime routing, discovery behavior, and visible Settings behavior remain compatible. No data migration, documentation update, or release-note entry is required.
Reviewer notes
PROVIDER_DEFAULTS remains as a compatibility alias to the same registry object; it does not create a second source of state. The two commits are independently revertible: the first establishes and migrates the shared registry/runtime seam, and the second moves Settings catalog recommendations and placement onto that seam.
Ready for review
  •  Verification is complete and the results above are current
  •  Impact, compatibility, migration, documentation, and release-note needs are addressed
  •  User-visible UI/UX changes include visual evidence, or Verification explains why it is not applicable
@Astro-Han
Astro-Han
marked this pull request as ready for review
July 13, 2026 11:57
@Astro-Han
Astro-Han
merged commit 24d8f20
into
mainJul 13, 2026

3 checks passed

@Astro-Han
Astro-Han
deleted the

feat/issue-860-provider-registry

branch
July 13, 2026 11:57

This was referenced Jul 13, 2026

Closed

 Merged

 Merged

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

Reviewers


No reviews


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

@Astro-Han

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
feat(providers): centralize provider registry by Astro-Han · Pull Request #866 · apache/maka · GitHub
Skip to content
feat(providers): centralize provider registry - #866
Merged
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Jul 13, 2026
Merged
feat(providers): centralize provider registry#866
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Conversation
@Astro-Han
@Astro-HanAstro-Han
commented
Jul 13, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Make the shared provider registry the authoritative source for provider defaults, catalog placement, recommendations, runtime adapter selection, and model discovery behavior.
  • Derive provider ids and ordered provider sets from registry entries while preserving all existing persisted ids and ordering.
  • Migrate Settings and runtime consumers to registry metadata without changing provider behavior.
Why
Issue #860 requires one generic provider extension path before the remaining provider workstreams can proceed. The current implementation still distributes provider behavior across hand-maintained lists and provider-specific runtime branches, which makes each new provider require parallel edits.
This change completes the Phase 2 registry foundation while preserving existing connections and behavior.
Refs #860
Scope
This PR only implements Phase 2.
It does not add Phase 3–5 providers, change first-run onboarding, or redesign existing OAuth account flows. Onboarding continues to use its current list until Phase 6 consumes the shared recommended set.
Verification
  • npm run typecheck
  • npm test
  • npm --workspace @maka/desktop run e2e — 13 passed
  • npm run check:stale — dist is fresh
No visual evidence is included because this is a behavior-preserving registry migration with no intended UI or interaction changes. The existing provider Settings E2E flow verifies the affected catalog path.
Impact
Existing persisted provider ids, provider ordering, defaults, runtime routing, discovery behavior, and visible Settings behavior remain compatible. No data migration, documentation update, or release-note entry is required.
Reviewer notes
PROVIDER_DEFAULTS remains as a compatibility alias to the same registry object; it does not create a second source of state. The two commits are independently revertible: the first establishes and migrates the shared registry/runtime seam, and the second moves Settings catalog recommendations and placement onto that seam.
Ready for review
  •  Verification is complete and the results above are current
  •  Impact, compatibility, migration, documentation, and release-note needs are addressed
  •  User-visible UI/UX changes include visual evidence, or Verification explains why it is not applicable
@Astro-Han
Astro-Han
marked this pull request as ready for review
July 13, 2026 11:57
@Astro-Han
Astro-Han
merged commit 24d8f20
into
mainJul 13, 2026

3 checks passed

@Astro-Han
Astro-Han
deleted the

feat/issue-860-provider-registry

branch
July 13, 2026 11:57

This was referenced Jul 13, 2026

Closed

 Merged

 Merged

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

Reviewers


No reviews


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

@Astro-Han

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
feat(providers): centralize provider registry by Astro-Han · Pull Request #866 · apache/maka · GitHub
Skip to content
feat(providers): centralize provider registry - #866
Merged
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Jul 13, 2026
Merged
feat(providers): centralize provider registry#866
Astro-Han merged 3 commits into
mainfrom 
feat/issue-860-provider-registry
Conversation
@Astro-Han
@Astro-HanAstro-Han
commented
Jul 13, 2026

Copy link


Copy Markdown

Contributor
Summary
  • Make the shared provider registry the authoritative source for provider defaults, catalog placement, recommendations, runtime adapter selection, and model discovery behavior.
  • Derive provider ids and ordered provider sets from registry entries while preserving all existing persisted ids and ordering.
  • Migrate Settings and runtime consumers to registry metadata without changing provider behavior.
Why
Issue #860 requires one generic provider extension path before the remaining provider workstreams can proceed. The current implementation still distributes provider behavior across hand-maintained lists and provider-specific runtime branches, which makes each new provider require parallel edits.
This change completes the Phase 2 registry foundation while preserving existing connections and behavior.
Refs #860
Scope
This PR only implements Phase 2.
It does not add Phase 3–5 providers, change first-run onboarding, or redesign existing OAuth account flows. Onboarding continues to use its current list until Phase 6 consumes the shared recommended set.
Verification
  • npm run typecheck
  • npm test
  • npm --workspace @maka/desktop run e2e — 13 passed
  • npm run check:stale — dist is fresh
No visual evidence is included because this is a behavior-preserving registry migration with no intended UI or interaction changes. The existing provider Settings E2E flow verifies the affected catalog path.
Impact
Existing persisted provider ids, provider ordering, defaults, runtime routing, discovery behavior, and visible Settings behavior remain compatible. No data migration, documentation update, or release-note entry is required.
Reviewer notes
PROVIDER_DEFAULTS remains as a compatibility alias to the same registry object; it does not create a second source of state. The two commits are independently revertible: the first establishes and migrates the shared registry/runtime seam, and the second moves Settings catalog recommendations and placement onto that seam.
Ready for review
  •  Verification is complete and the results above are current
  •  Impact, compatibility, migration, documentation, and release-note needs are addressed
  •  User-visible UI/UX changes include visual evidence, or Verification explains why it is not applicable
@Astro-Han
Astro-Han
marked this pull request as ready for review
July 13, 2026 11:57
@Astro-Han
Astro-Han
merged commit 24d8f20
into
mainJul 13, 2026

3 checks passed

@Astro-Han
Astro-Han
deleted the

feat/issue-860-provider-registry

branch
July 13, 2026 11:57

This was referenced Jul 13, 2026

Closed

 Merged

 Merged

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

Reviewers


No reviews


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

@Astro-Han

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

Copy link


Copy Markdown

Contributor
Summary
  • Make the shared provider registry the authoritative source for provider defaults, catalog placement, recommendations, runtime adapter selection, and model discovery behavior.
  • Derive provider ids and ordered provider sets from registry entries while preserving all existing persisted ids and ordering.
  • Migrate Settings and runtime consumers to registry metadata without changing provider behavior.
Why
Issue #860 requires one generic provider extension path before the remaining provider workstreams can proceed. The current implementation still distributes provider behavior across hand-maintained lists and provider-specific runtime branches, which makes each new provider require parallel edits.
This change completes the Phase 2 registry foundation while preserving existing connections and behavior.
Refs #860
Scope
This PR only implements Phase 2.
It does not add Phase 3–5 providers, change first-run onboarding, or redesign existing OAuth account flows. Onboarding continues to use its current list until Phase 6 consumes the shared recommended set.
Verification
  • npm run typecheck
  • npm test
  • npm --workspace @maka/desktop run e2e — 13 passed
  • npm run check:stale — dist is fresh
No visual evidence is included because this is a behavior-preserving registry migration with no intended UI or interaction changes. The existing provider Settings E2E flow verifies the affected catalog path.
Impact
Existing persisted provider ids, provider ordering, defaults, runtime routing, discovery behavior, and visible Settings behavior remain compatible. No data migration, documentation update, or release-note entry is required.
Reviewer notes
PROVIDER_DEFAULTS remains as a compatibility alias to the same registry object; it does not create a second source of state. The two commits are independently revertible: the first establishes and migrates the shared registry/runtime seam, and the second moves Settings catalog recommendations and placement onto that seam.
Ready for review
  •  Verification is complete and the results above are current
  •  Impact, compatibility, migration, documentation, and release-note needs are addressed
  •  User-visible UI/UX changes include visual evidence, or Verification explains why it is not applicable
@Astro-Han
Astro-Han
marked this pull request as ready for review
July 13, 2026 11:57
@Astro-Han
Astro-Han
merged commit 24d8f20
into
mainJul 13, 2026

3 checks passed

@Astro-Han
Astro-Han
deleted the

feat/issue-860-provider-registry

branch
July 13, 2026 11:57

This was referenced Jul 13, 2026

Closed

 Merged

 Merged

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

Reviewers


No reviews


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

@Astro-Han