This release includes behind-the-scenes maintenance and reliability improvements.
\n","_shaftware":{"version":"0.23.2","tags":[],"generic":true,"content_markdown":"This release includes behind-the-scenes maintenance and reliability improvements."}},{"id":"0.23.1","url":"https://www.obsolot.ai/changelog/0.23.1/","title":"Version 0.23.1","date_published":"2026-09-27T00:00:00.000Z","content_html":"This release includes behind-the-scenes maintenance and reliability improvements.
\n","_shaftware":{"version":"0.23.1","tags":[],"generic":true,"content_markdown":"This release includes behind-the-scenes maintenance and reliability improvements."}},{"id":"0.23.0","url":"https://www.obsolot.ai/changelog/0.23.0/","title":"Version 0.23.0","date_published":"2026-09-26T00:00:00.000Z","content_html":"Trying to link a deprecation notice to itself, add the same relationship twice,\nor attach an issue URL that's already linked now highlights exactly which\nfield caused the problem, right where you're working, instead of a generic\nerror message.
\n","_shaftware":{"version":"0.23.0","tags":["notices"],"tag_labels":{"notices":"Deprecation notices"},"generic":false,"content_markdown":"### Bug fixes\n\n#### Clearer errors when linking a duplicate notice or issue\n\nTrying to link a deprecation notice to itself, add the same relationship twice,\nor attach an issue URL that's already linked now highlights exactly which\nfield caused the problem, right where you're working, instead of a generic\nerror message."}},{"id":"0.22.1","url":"https://www.obsolot.ai/changelog/0.22.1/","title":"Version 0.22.1","date_published":"2026-09-22T00:00:00.000Z","content_html":"The sidebar now groups pages by what you're actually doing: Discovery (Repositories,\nBadges) for finding where deprecated things are used, Remediation (Campaigns,\nRemediation Dashboard) for tracking fixes, and Monitoring (Agent Activity) for\nreviewing what the AI agent has done.
\n","_shaftware":{"version":"0.22.1","tags":[],"generic":false,"content_markdown":"### Improvements\n\n#### Sidebar reorganized around your workflow\n\nThe sidebar now groups pages by what you're actually doing: Discovery (Repositories,\nBadges) for finding where deprecated things are used, Remediation (Campaigns,\nRemediation Dashboard) for tracking fixes, and Monitoring (Agent Activity) for\nreviewing what the AI agent has done."}},{"id":"0.22.0","url":"https://www.obsolot.ai/changelog/0.22.0/","title":"Version 0.22.0","date_published":"2026-09-21T00:00:00.000Z","content_html":"Notice owners can now record the known fix for a deprecation right on the notice\nitself — a before/after example, a deterministic codemod, or plain guidance —\nscoped to a language, file pattern, or repository. Recipes list, add, edit, and\nretire from a new Migration Recipes section, and a warning appears if a\nnotice's only recipe can't be applied automatically, so you're never left\nwondering why nothing happened.
\nWhen you set an integration's remediation delivery to "Open pull requests and\nrequest auto-merge," the settings page now shows the live branch-protection\nstate of every repository that currently matches your Allowed Repositories\npattern — for example, "No required checks configured" or "Required reviews:\n2." Previously you only saw static explanatory text about how the top\nautonomy rung works; now you can see, before turning it on, whether the\ntarget repositories actually have branch protection guarding them. Obsolot\nstill never merges anything itself — this is informational, not a gate.
\nA migration recipe backed by a deterministic tool (a jscodeshift/ts-morph\nscript, an OpenRewrite recipe, a Roslyn fixer) now renders as a precise,\nready-to-run command in the remediation brief — tool, version, and the exact\nfiles it applies to — instead of raw configuration. Obsolot never runs the\ntool itself: your CI or coding agent runs it, and whatever comes back is\nindependently re-verified the same way any other fix is. A recipe with an\ninvalid or missing codemod configuration now fails clearly when it's\ncreated, and — for any that slipped through earlier — shows up as a reason\non the remediation task instead of silently doing nothing.
\nOnce a remediation task has a deterministic codemod fix and autonomy allows\nit, Obsolot now opens an actual branch, commit, and pull or merge request on\nGitHub or GitLab — instead of only ever describing the change. The\ndescription states exactly what changed and what was left out (and why),\nand links back to the deprecation notice, the campaigns review page, and the\nrepository's badge. Before anything advances further, Obsolot independently\nre-checks its own verification ladder against what actually landed on the\nbranch — never just the change it generated locally.
\nWhen you approve a migration suggestion, its before/after fix is now saved as an example onto\nthat notice's own recipe. The automated Remediation agent reads those accumulated examples back\nwhen it generates a future patch for the same deprecation — so it starts from what you've already\nconfirmed works. Rejections are remembered too, along with your stated reason when you give one,\nso the Remediation agent doesn't propose the same rejected fix again. Both build up gradually,\ncapped to keep the most recent and varied examples rather than everything ever seen, and are\nvisible right on the recipe in the notice's Recipes tab.
\nGitHub and GitLab integrations can now be configured to send Obsolot a\nwebhook on push, so a re-scan starts right away instead of waiting for the\nnext scheduled run. Set it up from the integration's detail page: generate a\nsecret (shown once — copy it before closing the dialog), then add the\nprovided URL and secret to your repository or organization's webhook\nsettings. This is an accelerant, not a replacement — if a delivery is ever\nmissed (a provider outage, a dropped webhook), the scheduled scan still\ncatches it, so nothing is ever silently missed. Every integration starts\nwithout a webhook configured; setting one up is opt-in, and the URL, secret,\nand required event types are all shown together on the setup screen.
\nWhen a pull or merge request is opened or updated, Obsolot now checks the\nlines it actually changes against your active deprecation notices and, where\nautonomy is configured to allow it, leaves a review comment right on the\nline — a ready-to-apply suggested fix when one is available, or a flag for\nmanual review when it isn't. Each usage only ever gets one comment, and once\na reviewer resolves or dismisses it, Obsolot won't bring it up again on that\npull request.
\nDeprecation notices can now have one or more migration recipes attached —\nreusable guidance, before/after examples, or codemods scoped to specific\nlanguages, files, or package versions. When multiple recipes could apply to\nthe same code reference, the lowest-precedence active recipe wins, and every\nmigration suggestion now records which recipe (if any) produced it so you\ncan see exactly why a suggestion was authored the way it was.
\nMigration suggestions can now include a proposed code patch alongside (or\ninstead of) free-text advice. When a suggestion has one, the review UI shows\nit as a diff you can read and copy, along with the commit it applies to and\nany verification evidence — rather than a paragraph describing the change.\nSuggestions without a patch look exactly as they did before.
\nEvery integration now has a "Source-Content Egress" setting that controls how\nmuch of your source code the AI agent (built-in or an external MCP client) is\nallowed to see: nothing by default, just the short stored snippet, live file\ncontext on demand, or whole files. Automatic classification needs at least the\nsnippet tier; migration suggestions need live file context. If a task needs\nmore than you've allowed, it's skipped and the reason is shown right on the\nresult — not buried in a log — and the task picks the reference back up\nautomatically once you raise the tier.
\nIf you were already actively using the built-in agent before this release,\nnothing changes for you: your existing GitHub/GitLab integrations were set to\nwhichever tier your enabled tasks actually needed, so classification (and\nsuggestions, if you had those on) keep working exactly as before. Every new\nintegration starts closed, and raising the tier is an explicit choice you make\nper integration, along with an optional list of file paths (like\n**/secrets/**, matched the way .gitignore patterns are) that are never\nsent regardless of tier. The current tier is now shown on every integration's\ndetails view, not just in the edit dialog.
The built-in agent's settings now let you pick a different AI model for each\ntask it performs — for example a cheaper model for classification and a\nstronger one for generating migration suggestions. Any task left unset keeps\nusing the model you selected as your organization's default.
\nNotices that don't yet have a migration recipe no longer have to wait on someone to author one\nfrom scratch. The AI agent can now read a notice's own description and linked issues and propose\none or more candidate recipes for a maintainer to review — always saved as a draft, never applied\nautomatically. If the notice's description and linked issues don't actually say what the\nreplacement is, the agent says so and flags the notice for its owner instead of guessing.
\nBeyond classifying usages and suggesting prose fixes, the AI agent can now generate an actual\npatch for a deprecated usage — reading the surrounding file, applying the deprecation's own\nmigration recipe, and checking its own work before it ever reaches you: does the patch apply, does\nthe deprecated pattern actually go away, and does it avoid introducing another deprecated usage in\nits place? A patch that doesn't pass those checks is retried automatically within a limited number\nof attempts; if it still doesn't pass, it's left flagged for your review with the reasons why,\nrather than being silently discarded or accepted on the model's word alone.
\nThis only runs where a notice has a usable migration recipe. A notice without one is left alone\nfor its owner to supply a migration path, rather than have the agent guess.
\nRemediation delivery now climbs a six-rung autonomy ladder — from suggesting\na fix, to opening a draft pull request, to requesting the code host's own\nauto-merge — instead of one blunt on/off switch. The ceiling is set per\nintegration and can be lowered further for an individual notice or\nrepository, and is automatically capped by how risky the applied fix is.\nObsolot still never merges a pull request itself: the top rung only asks the\nrepository's own auto-merge feature to do it once that repository's required\nchecks and reviews pass, so the settings page can also show you whether a\nrepository has any of those configured at all.
\nAn external coding agent (or Obsolot's own built-in agent) can now pick up\nand complete remediation work entirely over MCP. GetRemediationBrief hands\nover everything needed to act — the notice, the known fix, the exact code\nlocations, any patch already generated, and the checks your change will be\nheld to. ClaimRemediationTask and AttachRemediationPullRequest record who\nis working on a task and where the resulting pull request landed, so\nconcurrent agents never collide. ReportRemediationOutcome closes the loop:\nObsolot never simply takes your word that a fix worked — it independently\nre-fetches your delivered code and re-runs its own verification before\nmarking anything Verified. A new "Remediation Tasks" category in the MCP\nconsent screen and personal-access-token creation dialog lets you scope a\ncredential to this workflow specifically.
Obsolot can now open a tracking issue in the target repository for remediation\nwork, instead of requiring an MCP-connected agent to pick it up. The issue\ncarries the same brief GetRemediationBrief hands to an MCP agent — what\nneeds to change and why, the exact code locations, and the checks the fix\nwill be held to — labeled so a reviewer can always trace it back to Obsolot,\nand optionally assigned to your configured coding-agent bot account.
Once a pull request references the issue, Obsolot finds it automatically and\nre-verifies the change itself before marking the task Verified — the same\nindependent verification the MCP workflow already gets. Nothing here trusts a\nplatform-reported outcome at face value.
\nA new Remediation Dashboard shows, at a glance, whether deprecation cleanup is\nactually working: how many usages were discovered, classified, patched,\ndelivered, and verified gone, plus resolution rate over time, how long fixes\ntake, how often the AI agent's suggestions are approved, and which notices are\napproaching their end-of-life date with the least progress. The same figures\nare available over the GraphQL API for anyone building their own reporting.
\nIf your organization already runs a coding agent from a GitHub Actions\nworkflow or GitLab CI pipeline, Obsolot can now trigger it directly for a\ndelegated remediation task — in addition to, or instead of, opening a\ntracking issue. Configure the workflow file (GitHub) or let Obsolot create a\npipeline (GitLab), and Obsolot passes along the task id so your workflow\nknows exactly what to work on.
\nA new Campaigns page shows how Obsolot is grouping the fixes for each\ndeprecation notice: every affected reference in a repository, on a given\nbranch, bundled into a single campaign rather than scattered one-by-one.\nEach campaign tracks its own progress — drafted, briefed to an agent,\nclaimed, delivered as a pull request, verified, and merged — so you can see\nat a glance where a notice's remediation stands across every repository it\ntouches.
\nCampaigns are read-only for now; nothing is delivered to a code host yet.\nThat follow-up release is next.
\nWhen a configured GitHub or GitLab webhook reports a push, Obsolot now\nre-checks only the files that push touched — no more waiting for the next\nscheduled scan to notice a deprecated usage is finally gone. A reference\nwhose pattern disappeared is marked resolved, with a note of which commit\n(or scan) resolved it. If a pattern that was resolved reappears later, the\nreference reopens and its remediation campaign is flagged as regressed, so a\npremature "fixed" never goes unnoticed. Once every reference in a campaign is\nresolved, the campaign is automatically marked verified. The scheduled full\nscan keeps running as a safety net for anything a webhook delivery misses.
\nGitHub and GitLab integrations can now be configured to deliver remediation\nwork back to your code host — not just suggest it inside Obsolot. A new\n"Remediation delivery" setting lets you choose how far Obsolot may go, from\nsuggestions only up through opening ready-for-review pull requests and\nrequesting your platform's own auto-merge; every level above the first\nrequires a write-capable credential, and Test Connection will tell you if\nyours isn't one. You control which repositories are ever eligible (glob\npatterns, so my-org/* covers a whole organization or you can list\nrepositories one at a time), who gets requested as a reviewer, and four caps\nthat limit the blast radius: how many pull requests can be open at once per\nrepository, how many can open per day, and how large any single pull request\nis allowed to get.
Every organization starts closed — nothing is delivered anywhere until you\nopt an integration in. A new kill switch on the Integrations page stops all\nremediation delivery for the whole organization immediately, including work\nalready queued, for when you need to pause everything at once.
\nNothing can be opened on a code host yet — this release wires up the\nconfiguration, the safety caps, and the kill switch. Actual delivery lands in\na follow-up release.
\nDiscovered code references now record the commit they were found at. Reference\nlinks in the UI open the file as it looked at that commit instead of the\ncurrent default branch, so the link stays correct even after the file moves or\nchanges later. References found before this change keep working exactly as\nbefore.
\nGitGud has shut down, so the integration that synced deprecation notices from it\nis gone. If you had one configured, the integration and its stored credentials\nare removed when you upgrade.
\nAny notices that had been synced from GitGud are kept. They become ordinary\nnotices owned by your organization, which you can now edit freely — previously a\nsync could overwrite them.
\nIf you had the AI agent enabled, it was reviewing your code references and then\nquietly dropping the results: the agent activity page filled up with runs, but\nno reference ever got classified and no migration suggestion ever appeared. The\nagent could not write anything back.
\nIt can now. Scheduled and on-demand runs classify references as true or false\npositives and file migration suggestions into the review queue, attributed to\nthe agent so you can tell its work from a person's. Each run also records every\naction the agent took, so you can see exactly what it did and why.
\nNothing about review changes: suggestions still arrive as Pending and wait for a\nhuman, and low-confidence results are still held for review.
\nWhen many activity log entries were recorded at the same instant (for example,\nafter enabling a stricter source-content egress tier skips a large batch of\ncode references in one run), paging through the Agent Activity log could show\na duplicate entry on one page and miss another entirely. Paging is now stable\nin every case.
\nClosing the Add/Edit Recipe dialog on a notice's Migration Recipes section —\nvia Escape, the close button, Cancel, or successfully saving — now returns\nkeyboard focus to the button that opened it (or a sensible fallback if that\nbutton no longer exists), instead of dropping it to the top of the page.
\nThe Agent Activity page failed to load with an error whenever a status filter,\nsearch term, or date range was applied. It now loads correctly with any\ncombination of filters.
\nThe "What's New" dialog now actually loads Obsolot's release notes, and the\nversion number at the bottom of the sidebar becomes a clickable link to the\nfull history. A configuration issue was silently blocking the connection to\nour website, so both always appeared empty before — you'll now see what's\nchanged since your last visit.
\nClosing the "Add Integration" dialog or an integration's detail dialog in\nOrganization Settings — via Escape, the close button, or completing the\naction — now returns keyboard focus to the button or row that opened it (or\na sensible fallback if it no longer exists), instead of dropping it to the\ntop of the page. Integration rows can now also be opened with the keyboard\n(Tab to focus, Enter or Space to open) — previously they were only\nclickable with a mouse.
\nScreen reader users navigating the Integrations section of Organization\nSettings by heading level would land on a second page-level heading nested\nunder the dialog's own title. The Integrations list, Add Integration, and\nintegration detail pages now correctly render their titles as section-level\nheadings within the dialog, consistent with the rest of Organization Settings.
\nThe migration suggestion review panel (and the equivalent REST endpoint) failed\nto load with an error whenever suggestions were filtered by code reference and\nsorted by creation date — which was every time. It now loads correctly.
\nOn the Notice Detail page, viewing a notice on a narrow screen (e.g. a phone)\ncould show the status badge overlapping the first word of the notice title.\nThe header now stacks the title above the status and action controls at\nnarrow widths instead of overlapping them.
\nThe Notices list page previously defaulted its Status filter to "Active" only,\nwhich made organizations with only Draft notices see a misleading "no notices\nfound" message. The list now shows notices of all statuses by default; you can\nstill narrow to a specific status using the Status filter.
\nScreen reader users navigating by heading level on the Notices, Repositories,\nTemplates, and Labels pages would jump from the page title directly to a\nlower heading level, skipping a level in between. Card titles and empty-state\nmessages on these pages are now one level below the page title, so the\nheading outline is sequential.
\nHard-reloading or opening a bookmarked/shared link to an organization page\n(repositories, notices, templates, labels, badges, integrations, agents, and\ntheir detail/create/edit variants) could briefly show a "No organization\nselected — please select one from the sidebar" message, even though the\norganization was already known from the URL. The page would then correct\nitself a second or two later once the organization finished loading.
\nThat message now only appears when there really is no organization to select.\nWhile the organization is still loading, the page shows a neutral loading\nplaceholder instead, so a normal page load no longer looks like an error.
\nOn the Organizations page, viewing the list on a narrow screen (e.g. a phone)\ncould push the "New organization" button past the edge of the screen with its\nlabel clipped. The header now stacks the title above the button at narrow\nwidths instead of overflowing.
\nScreen reader users navigating by heading level on any org-scoped page would,\nwhile no organization was selected, land on a heading with no page title\nbefore it. The "No organization selected" message is now marked up as the\npage's <h1>, consistent with the page's own title once an organization is\nselected.
The Remediation Dashboard's charts (funnel, campaign pipeline, resolution\nrate over time, time-to-resolution distribution, and verification rungs)\npreviously exposed no data to screen readers. Each chart now has an\naccessible name summarizing its current values, plus a hidden data table\nwith the full dataset.
\nScreen reader users navigating by heading level on the Campaigns, Agent\nActivity, Remediation Dashboard, Badges, and Integrations pages would jump\nfrom the page title directly to a lower heading level, or land on a visible\nsection title with no heading markup at all. Section titles, filter panel\nlabels, and empty-state messages on these pages now form a sequential\nheading outline, matching the fix already applied to the Notices,\nRepositories, Templates, and Labels pages.
\nClicking a repository from the Repositories list could land on a "Repository\nnot found" page even though the repository had active code references — this\nhappened for repositories whose integration has no configured base URL (the\ncommon case for default GitHub/GitLab integrations). The Repository Detail\npage now resolves correctly in this case.
\nKeyboard and screen-reader users previously had to tab through the entire\nsidebar navigation on every page before reaching page content, with no way\nto bypass it. A "Skip to main content" link — hidden until it receives\nkeyboard focus — now appears as the first focusable element on every page\nand jumps straight to the page content.
\nBefore/After code examples on an Exemplar migration recipe now render with\nlanguage-aware syntax highlighting (keywords, identifiers, and literals\nvisually distinguished) instead of plain unstyled text, using the recipe's\nconfigured language.
\n","_shaftware":{"version":"0.22.0","tags":["accessibility","agent","app-shell","code-references","codemod","integrations","mcp","migration-recipes","migration-suggestions","notices","organizations","remediation","repositories","security","ui","ux"],"tag_labels":{"agent":"AI agent","integrations":"Integrations","mcp":"MCP","notices":"Deprecation notices","repositories":"Repositories"},"generic":false,"content_markdown":"### New features\n\n#### Author migration recipes directly on a notice\n\nNotice owners can now record the known fix for a deprecation right on the notice\nitself — a before/after example, a deterministic codemod, or plain guidance —\nscoped to a language, file pattern, or repository. Recipes list, add, edit, and\nretire from a new Migration Recipes section, and a warning appears if a\nnotice's only recipe can't be applied automatically, so you're never left\nwondering why nothing happened.\n\n#### See a repository's branch protection before turning on auto-merge\n\nWhen you set an integration's remediation delivery to \"Open pull requests and\nrequest auto-merge,\" the settings page now shows the live branch-protection\nstate of every repository that currently matches your Allowed Repositories\npattern — for example, \"No required checks configured\" or \"Required reviews:\n2.\" Previously you only saw static explanatory text about how the top\nautonomy rung works; now you can see, before turning it on, whether the\ntarget repositories actually have branch protection guarding them. Obsolot\nstill never merges anything itself — this is informational, not a gate.\n\n#### Deterministic codemods render as a runnable invocation in the remediation brief\n\nA migration recipe backed by a deterministic tool (a jscodeshift/ts-morph\nscript, an OpenRewrite recipe, a Roslyn fixer) now renders as a precise,\nready-to-run command in the remediation brief — tool, version, and the exact\nfiles it applies to — instead of raw configuration. Obsolot never runs the\ntool itself: your CI or coding agent runs it, and whatever comes back is\nindependently re-verified the same way any other fix is. A recipe with an\ninvalid or missing codemod configuration now fails clearly when it's\ncreated, and — for any that slipped through earlier — shows up as a reason\non the remediation task instead of silently doing nothing.\n\n#### Remediation can now open real pull and merge requests\n\nOnce a remediation task has a deterministic codemod fix and autonomy allows\nit, Obsolot now opens an actual branch, commit, and pull or merge request on\nGitHub or GitLab — instead of only ever describing the change. The\ndescription states exactly what changed and what was left out (and why),\nand links back to the deprecation notice, the campaigns review page, and the\nrepository's badge. Before anything advances further, Obsolot independently\nre-checks its own verification ladder against what actually landed on the\nbranch — never just the change it generated locally.\n\n#### Approved and rejected suggestions now teach the recipe for their notice\n\nWhen you approve a migration suggestion, its before/after fix is now saved as an example onto\nthat notice's own recipe. The automated Remediation agent reads those accumulated examples back\nwhen it generates a future patch for the same deprecation — so it starts from what you've already\nconfirmed works. Rejections are remembered too, along with your stated reason when you give one,\nso the Remediation agent doesn't propose the same rejected fix again. Both build up gradually,\ncapped to keep the most recent and varied examples rather than everything ever seen, and are\nvisible right on the recipe in the notice's Recipes tab.\n\n#### GitHub/GitLab can now notify Obsolot directly, instead of waiting for the next scan\n\nGitHub and GitLab integrations can now be configured to send Obsolot a\nwebhook on push, so a re-scan starts right away instead of waiting for the\nnext scheduled run. Set it up from the integration's detail page: generate a\nsecret (shown once — copy it before closing the dialog), then add the\nprovided URL and secret to your repository or organization's webhook\nsettings. This is an accelerant, not a replacement — if a delivery is ever\nmissed (a provider outage, a dropped webhook), the scheduled scan still\ncatches it, so nothing is ever silently missed. Every integration starts\nwithout a webhook configured; setting one up is opt-in, and the URL, secret,\nand required event types are all shown together on the setup screen.\n\n#### Obsolot now comments directly on pull requests that introduce deprecated usages\n\nWhen a pull or merge request is opened or updated, Obsolot now checks the\nlines it actually changes against your active deprecation notices and, where\nautonomy is configured to allow it, leaves a review comment right on the\nline — a ready-to-apply suggested fix when one is available, or a flag for\nmanual review when it isn't. Each usage only ever gets one comment, and once\na reviewer resolves or dismisses it, Obsolot won't bring it up again on that\npull request.\n\n#### Migration recipes drive suggestion authoring\n\nDeprecation notices can now have one or more migration recipes attached —\nreusable guidance, before/after examples, or codemods scoped to specific\nlanguages, files, or package versions. When multiple recipes could apply to\nthe same code reference, the lowest-precedence active recipe wins, and every\nmigration suggestion now records which recipe (if any) produced it so you\ncan see exactly why a suggestion was authored the way it was.\n\n#### Migration suggestions can now carry a reviewable patch\n\nMigration suggestions can now include a proposed code patch alongside (or\ninstead of) free-text advice. When a suggestion has one, the review UI shows\nit as a diff you can read and copy, along with the commit it applies to and\nany verification evidence — rather than a paragraph describing the change.\nSuggestions without a patch look exactly as they did before.\n\n#### Source code content sent to AI models is now opt-in and tiered\n\nEvery integration now has a \"Source-Content Egress\" setting that controls how\nmuch of your source code the AI agent (built-in or an external MCP client) is\nallowed to see: nothing by default, just the short stored snippet, live file\ncontext on demand, or whole files. Automatic classification needs at least the\nsnippet tier; migration suggestions need live file context. If a task needs\nmore than you've allowed, it's skipped and the reason is shown right on the\nresult — not buried in a log — and the task picks the reference back up\nautomatically once you raise the tier.\n\nIf you were already actively using the built-in agent before this release,\nnothing changes for you: your existing GitHub/GitLab integrations were set to\nwhichever tier your enabled tasks actually needed, so classification (and\nsuggestions, if you had those on) keep working exactly as before. Every new\nintegration starts closed, and raising the tier is an explicit choice you make\nper integration, along with an optional list of file paths (like\n`**/secrets/**`, matched the way `.gitignore` patterns are) that are never\nsent regardless of tier. The current tier is now shown on every integration's\ndetails view, not just in the edit dialog.\n\n#### Choose a different AI model per agent task\n\nThe built-in agent's settings now let you pick a different AI model for each\ntask it performs — for example a cheaper model for classification and a\nstronger one for generating migration suggestions. Any task left unset keeps\nusing the model you selected as your organization's default.\n\n#### The AI agent can now propose migration recipes from a deprecation notice alone\n\nNotices that don't yet have a migration recipe no longer have to wait on someone to author one\nfrom scratch. The AI agent can now read a notice's own description and linked issues and propose\none or more candidate recipes for a maintainer to review — always saved as a draft, never applied\nautomatically. If the notice's description and linked issues don't actually say what the\nreplacement is, the agent says so and flags the notice for its owner instead of guessing.\n\n#### The AI agent can now write and verify real patches\n\nBeyond classifying usages and suggesting prose fixes, the AI agent can now generate an actual\npatch for a deprecated usage — reading the surrounding file, applying the deprecation's own\nmigration recipe, and checking its own work before it ever reaches you: does the patch apply, does\nthe deprecated pattern actually go away, and does it avoid introducing another deprecated usage in\nits place? A patch that doesn't pass those checks is retried automatically within a limited number\nof attempts; if it still doesn't pass, it's left flagged for your review with the reasons why,\nrather than being silently discarded or accepted on the model's word alone.\n\nThis only runs where a notice has a usable migration recipe. A notice without one is left alone\nfor its owner to supply a migration path, rather than have the agent guess.\n\n#### An autonomy ladder for remediation delivery\n\nRemediation delivery now climbs a six-rung autonomy ladder — from suggesting\na fix, to opening a draft pull request, to requesting the code host's own\nauto-merge — instead of one blunt on/off switch. The ceiling is set per\nintegration and can be lowered further for an individual notice or\nrepository, and is automatically capped by how risky the applied fix is.\nObsolot still never merges a pull request itself: the top rung only asks the\nrepository's own auto-merge feature to do it once that repository's required\nchecks and reviews pass, so the settings page can also show you whether a\nrepository has any of those configured at all.\n\n#### Claim and deliver remediation work over MCP\n\nAn external coding agent (or Obsolot's own built-in agent) can now pick up\nand complete remediation work entirely over MCP. `GetRemediationBrief` hands\nover everything needed to act — the notice, the known fix, the exact code\nlocations, any patch already generated, and the checks your change will be\nheld to. `ClaimRemediationTask` and `AttachRemediationPullRequest` record who\nis working on a task and where the resulting pull request landed, so\nconcurrent agents never collide. `ReportRemediationOutcome` closes the loop:\nObsolot never simply takes your word that a fix worked — it independently\nre-fetches your delivered code and re-runs its own verification before\nmarking anything Verified. A new \"Remediation Tasks\" category in the MCP\nconsent screen and personal-access-token creation dialog lets you scope a\ncredential to this workflow specifically.\n\n#### Dispatch remediation work to your platform's coding agent\n\nObsolot can now open a tracking issue in the target repository for remediation\nwork, instead of requiring an MCP-connected agent to pick it up. The issue\ncarries the same brief `GetRemediationBrief` hands to an MCP agent — what\nneeds to change and why, the exact code locations, and the checks the fix\nwill be held to — labeled so a reviewer can always trace it back to Obsolot,\nand optionally assigned to your configured coding-agent bot account.\n\nOnce a pull request references the issue, Obsolot finds it automatically and\nre-verifies the change itself before marking the task Verified — the same\nindependent verification the MCP workflow already gets. Nothing here trusts a\nplatform-reported outcome at face value.\n\n#### Remediation funnel and migration progress dashboard\n\nA new Remediation Dashboard shows, at a glance, whether deprecation cleanup is\nactually working: how many usages were discovered, classified, patched,\ndelivered, and verified gone, plus resolution rate over time, how long fixes\ntake, how often the AI agent's suggestions are approved, and which notices are\napproaching their end-of-life date with the least progress. The same figures\nare available over the GraphQL API for anyone building their own reporting.\n\n#### Remediation can now dispatch a workflow to run a coding agent\n\nIf your organization already runs a coding agent from a GitHub Actions\nworkflow or GitLab CI pipeline, Obsolot can now trigger it directly for a\ndelegated remediation task — in addition to, or instead of, opening a\ntracking issue. Configure the workflow file (GitHub) or let Obsolot create a\npipeline (GitLab), and Obsolot passes along the task id so your workflow\nknows exactly what to work on.\n\n#### Remediation campaigns\n\nA new Campaigns page shows how Obsolot is grouping the fixes for each\ndeprecation notice: every affected reference in a repository, on a given\nbranch, bundled into a single campaign rather than scattered one-by-one.\nEach campaign tracks its own progress — drafted, briefed to an agent,\nclaimed, delivered as a pull request, verified, and merged — so you can see\nat a glance where a notice's remediation stands across every repository it\ntouches.\n\nCampaigns are read-only for now; nothing is delivered to a code host yet.\nThat follow-up release is next.\n\n#### Push events now resolve, reopen, and advance remediation work automatically\n\nWhen a configured GitHub or GitLab webhook reports a push, Obsolot now\nre-checks only the files that push touched — no more waiting for the next\nscheduled scan to notice a deprecated usage is finally gone. A reference\nwhose pattern disappeared is marked resolved, with a note of which commit\n(or scan) resolved it. If a pattern that was resolved reappears later, the\nreference reopens and its remediation campaign is flagged as regressed, so a\npremature \"fixed\" never goes unnoticed. Once every reference in a campaign is\nresolved, the campaign is automatically marked verified. The scheduled full\nscan keeps running as a safety net for anything a webhook delivery misses.\n\n#### Write-capable code-host integrations, with a kill switch\n\nGitHub and GitLab integrations can now be configured to deliver remediation\nwork back to your code host — not just suggest it inside Obsolot. A new\n\"Remediation delivery\" setting lets you choose how far Obsolot may go, from\nsuggestions only up through opening ready-for-review pull requests and\nrequesting your platform's own auto-merge; every level above the first\nrequires a write-capable credential, and Test Connection will tell you if\nyours isn't one. You control which repositories are ever eligible (glob\npatterns, so `my-org/*` covers a whole organization or you can list\nrepositories one at a time), who gets requested as a reviewer, and four caps\nthat limit the blast radius: how many pull requests can be open at once per\nrepository, how many can open per day, and how large any single pull request\nis allowed to get.\n\nEvery organization starts closed — nothing is delivered anywhere until you\nopt an integration in. A new kill switch on the Integrations page stops all\nremediation delivery for the whole organization immediately, including work\nalready queued, for when you need to pause everything at once.\n\nNothing can be opened on a code host yet — this release wires up the\nconfiguration, the safety caps, and the kill switch. Actual delivery lands in\na follow-up release.\n\n### Improvements\n\n#### Code reference links now point to the exact commit, not the branch tip\n\nDiscovered code references now record the commit they were found at. Reference\nlinks in the UI open the file as it looked at that commit instead of the\ncurrent default branch, so the link stays correct even after the file moves or\nchanges later. References found before this change keep working exactly as\nbefore.\n\n#### The GitGud integration has been removed\n\nGitGud has shut down, so the integration that synced deprecation notices from it\nis gone. If you had one configured, the integration and its stored credentials\nare removed when you upgrade.\n\nAny notices that had been synced from GitGud are kept. They become ordinary\nnotices owned by your organization, which you can now edit freely — previously a\nsync could overwrite them.\n\n### Bug fixes\n\n#### The AI agent now actually files its findings\n\nIf you had the AI agent enabled, it was reviewing your code references and then\nquietly dropping the results: the agent activity page filled up with runs, but\nno reference ever got classified and no migration suggestion ever appeared. The\nagent could not write anything back.\n\nIt can now. Scheduled and on-demand runs classify references as true or false\npositives and file migration suggestions into the review queue, attributed to\nthe agent so you can tell its work from a person's. Each run also records every\naction the agent took, so you can see exactly what it did and why.\n\nNothing about review changes: suggestions still arrive as Pending and wait for a\nhuman, and low-confidence results are still held for review.\n\n#### Fixed possible duplicate or missing rows when paging the Agent Activity log\n\nWhen many activity log entries were recorded at the same instant (for example,\nafter enabling a stricter source-content egress tier skips a large batch of\ncode references in one run), paging through the Agent Activity log could show\na duplicate entry on one page and miss another entirely. Paging is now stable\nin every case.\n\n#### Fixed focus not returning to the Add Recipe button after closing the dialog\n\nClosing the Add/Edit Recipe dialog on a notice's Migration Recipes section —\nvia Escape, the close button, Cancel, or successfully saving — now returns\nkeyboard focus to the button that opened it (or a sensible fallback if that\nbutton no longer exists), instead of dropping it to the top of the page.\n\n#### Fixed the Agent Activity page failing to load with a status or search filter applied\n\nThe Agent Activity page failed to load with an error whenever a status filter,\nsearch term, or date range was applied. It now loads correctly with any\ncombination of filters.\n\n#### The What's New feed now loads\n\nThe \"What's New\" dialog now actually loads Obsolot's release notes, and the\nversion number at the bottom of the sidebar becomes a clickable link to the\nfull history. A configuration issue was silently blocking the connection to\nour website, so both always appeared empty before — you'll now see what's\nchanged since your last visit.\n\n#### Fixed focus not returning to the Add Integration button after closing the dialog, and made integration rows keyboard-operable\n\nClosing the \"Add Integration\" dialog or an integration's detail dialog in\nOrganization Settings — via Escape, the close button, or completing the\naction — now returns keyboard focus to the button or row that opened it (or\na sensible fallback if it no longer exists), instead of dropping it to the\ntop of the page. Integration rows can now also be opened with the keyboard\n(Tab to focus, Enter or Space to open) — previously they were only\nclickable with a mouse.\n\n#### Fixed a heading-hierarchy issue in the Integrations dialog\n\nScreen reader users navigating the Integrations section of Organization\nSettings by heading level would land on a second page-level heading nested\nunder the dialog's own title. The Integrations list, Add Integration, and\nintegration detail pages now correctly render their titles as section-level\nheadings within the dialog, consistent with the rest of Organization Settings.\n\n#### Fixed the migration suggestion review panel failing to load\n\nThe migration suggestion review panel (and the equivalent REST endpoint) failed\nto load with an error whenever suggestions were filtered by code reference and\nsorted by creation date — which was every time. It now loads correctly.\n\n#### Fixed the notice title being obscured by the status badge on mobile\n\nOn the Notice Detail page, viewing a notice on a narrow screen (e.g. a phone)\ncould show the status badge overlapping the first word of the notice title.\nThe header now stacks the title above the status and action controls at\nnarrow widths instead of overlapping them.\n\n#### Notices list no longer hides Draft notices behind a default \"Active\" filter\n\nThe Notices list page previously defaulted its Status filter to \"Active\" only,\nwhich made organizations with only Draft notices see a misleading \"no notices\nfound\" message. The list now shows notices of all statuses by default; you can\nstill narrow to a specific status using the Status filter.\n\n#### Fixed a skipped heading level on the Notices, Repositories, Templates, and Labels list pages\n\nScreen reader users navigating by heading level on the Notices, Repositories,\nTemplates, and Labels pages would jump from the page title directly to a\nlower heading level, skipping a level in between. Card titles and empty-state\nmessages on these pages are now one level below the page title, so the\nheading outline is sequential.\n\n#### Fixed a brief \"No organization selected\" flash on page reload\n\nHard-reloading or opening a bookmarked/shared link to an organization page\n(repositories, notices, templates, labels, badges, integrations, agents, and\ntheir detail/create/edit variants) could briefly show a \"No organization\nselected — please select one from the sidebar\" message, even though the\norganization was already known from the URL. The page would then correct\nitself a second or two later once the organization finished loading.\n\nThat message now only appears when there really is no organization to select.\nWhile the organization is still loading, the page shows a neutral loading\nplaceholder instead, so a normal page load no longer looks like an error.\n\n#### Fixed the \"New organization\" button overflowing on mobile\n\nOn the Organizations page, viewing the list on a narrow screen (e.g. a phone)\ncould push the \"New organization\" button past the edge of the screen with its\nlabel clipped. The header now stacks the title above the button at narrow\nwidths instead of overflowing.\n\n#### Fixed an orphan heading on the \"No organization selected\" fallback state\n\nScreen reader users navigating by heading level on any org-scoped page would,\nwhile no organization was selected, land on a heading with no page title\nbefore it. The \"No organization selected\" message is now marked up as the\npage's `Press / (or Ctrl+K / Cmd+K) on any page to open search. It finds deprecation\nnotices by title, summary or description, even if you mistype a word, and\njumps straight to the notice. The same box searches the Obsolot documentation,\nso "how do I embed a badge?" takes you to the right section of the guide. You\ncan also open any page or settings section from it. AI agents connected over\nMCP can use the same search, and can now read the Obsolot documentation to\nanswer questions about how Obsolot works.
\nThe authorization screen now names the application's destination before you\napprove it, and marks well-known clients such as Claude and ChatGPT as\nrecognized. Anything else is flagged as an unverified application, so a\nconnection you did not start is easy to spot and cancel. Cancelling never\nfollows an unverified link, and a client whose registration has been revoked\nnow gets clear steps for reconnecting instead of a form that cannot succeed.
\n","_shaftware":{"version":"0.21.0","tags":["mcp","notices"],"tag_labels":{"mcp":"MCP","notices":"Deprecation notices"},"generic":false,"content_markdown":"### New features\n\n#### Find notices and answers from anywhere\n\nPress / (or Ctrl+K / Cmd+K) on any page to open search. It finds deprecation\nnotices by title, summary or description, even if you mistype a word, and\njumps straight to the notice. The same box searches the Obsolot documentation,\nso \"how do I embed a badge?\" takes you to the right section of the guide. You\ncan also open any page or settings section from it. AI agents connected over\nMCP can use the same search, and can now read the Obsolot documentation to\nanswer questions about how Obsolot works.\n\n### Improvements\n\n#### See where an MCP connection will send you before you approve it\n\nThe authorization screen now names the application's destination before you\napprove it, and marks well-known clients such as Claude and ChatGPT as\nrecognized. Anything else is flagged as an unverified application, so a\nconnection you did not start is easy to spot and cancel. Cancelling never\nfollows an unverified link, and a client whose registration has been revoked\nnow gets clear steps for reconnecting instead of a form that cannot succeed."}},{"id":"0.20.0","url":"https://www.obsolot.ai/changelog/0.20.0/","title":"Version 0.20.0","date_published":"2026-09-15T00:00:00.000Z","content_html":"Click the version number at the bottom of the sidebar to read the full release history without leaving the app. When a release you haven't seen yet ships, a What's New entry appears in the same menu with a digest of everything since your last visit.
\n","_shaftware":{"version":"0.20.0","tags":[],"generic":false,"content_markdown":"### New features\n\n#### See what's new right inside Obsolot\n\nClick the version number at the bottom of the sidebar to read the full release history without leaving the app. When a release you haven't seen yet ships, a What's New entry appears in the same menu with a digest of everything since your last visit."}}]}