[simlarsen]

The question, and the answer

Should incident investigation rule and remediation rule be the same entity - we can call it Incident AI rules ... Since its not possible to remediate without investigation. Do you think we should merge these together into one? If you think so, you can do the same for alerts.

Yes. This PR merges them, for incidents and for alerts. The reasons:

• The conditions were written twice. Both kinds of rule matched incidents the same way: monitors, severities, labels, monitor labels, title and description. Users had to keep two lists in step, and the lists drifted. A user could set up a fix for incidents that no investigation rule let OneUptime AI look at.
• Every fix already waits for its investigation ("RCA first" on the AI SRE page). A fix is the second half of an investigation, so one rule that says when it investigates and whether and how it fixes describes what actually happens.
• Shared settings live in one place. Both kinds of rule set the LLM provider, MCP servers and code repositories for the same incidents. Now each rule sets them once.
• One table instead of two under More settings, and one less kind of rule to learn.

What changes on the AI settings page

Incidents → AI → Settings → More settings (and the same page for Alerts) now has one AI rules table. Before, it had Investigation rules and Auto remediation rules.

• Creating a rule takes three steps, then a name:
  • Match: all incidents, or conditions.
  • Investigate: right away, or only if the incident is still open after a wait.
  • Fix: Don't fix, Ask before fixing (the default for a new rule) or Fix without asking.
• More fields is folded. It holds the settings every rule uses: code repositories, MCP servers and LLM provider. For a rule that fixes, it also holds the runbooks, "Run them every time", the Runner and the two pull-request switches.
• The table has four columns: Name, Match Criteria, Investigates and fixes (when the rule investigates, and under that how it fixes) and Status.
  • It is one column, not two. With two, Status was pushed under the row's buttons at 1280px beside the side menu, by about 130px in German. The offline suite measures the table in English and German.
• Which rules investigate:
  • A rule made on the dashboard always investigates.
  • A rule that was an auto remediation rule, or one an older API client creates, may only fix. Its Investigate step says so and offers Investigate too.
  • A rule that neither investigates nor fixes is refused.
• With no rules, nothing changes. Every new incident is investigated, and fixed while fixing is on.

Migration: no project's AI behaves differently

AddAiRuleInvestigation adds three columns to the auto remediation rules' table: investigates (default false), fixes (default true) and onlyIfOpenAfterMinutes.

MergeInvestigationRulesIntoAiRules then works through each project, for incidents and for alerts separately:

1. Matching pairs become one rule. This applies to an investigation rule and an auto remediation rule with the same conditions, the same enabled state and the same MCP servers, repositories and LLM provider. The auto remediation rule is kept, now investigates too, and takes the investigation rule's wait. Its name, order, enabled state, runbooks, Runner, pull-request switches and provider stay as they were.
2. Every other investigation rule becomes an AI rule that only investigates. It keeps its id, name, conditions, wait, MCP servers, repositories and provider.
3. Every other auto remediation rule fixes as before. Whether it also investigates depends on the project:
   • Where enabled investigation rules decided what was investigated, it does not investigate.
   • Where none did, it investigates too, unless it picks an LLM provider.
   • If that leaves rules that investigate only some incidents, the project gets an Investigate every incident (or alert) rule, so every incident is still investigated.
4. A gap in fixing is filled. Some projects had investigation rules deciding what was investigated but no auto remediation rule deciding what was fixed. If fixing is on, the project gets a Fix every incident (or alert) rule, which fixes every incident the way OneUptime AI did with no rule. If fixing is off, it gets nothing.
   • The catch: if such a project turns fixing on later, nothing is fixed until someone adds a rule that fixes. The incident's Remediation card then says why it was not fixed (for example, that the rule it matched only investigates) and links to the rules, and the upgrade note says to add a rule that fixes first. Adding a fixing rule to a project that never fixed anything would have put a rule that changes infrastructure where nobody asked for one.

It is safe to stop and run again:

• It runs in one transaction, so stopping it rolls everything back.
• It only reads the old table. The copies keep the investigation rules' ids, and the two added rules get ids made from their project and kind.
• Every insert skips a row that is already there, and every update writes the same value each time.
• down() removes what up() added.

How it is tested: a Postgres suite seeds sixteen projects. They cover every combination of rules, pairs and near-pairs, incidents and alerts, fixing on and off, and deleted rules and projects. For 36 incidents and 36 alerts per project, it uses the real matcher to check that these are the same before and after: what is investigated, the wait, the LLM provider, MCP servers and repositories, the rules that fix, and both pull requests. It also runs up() twice, then down(), then up() again.

API, Terraform and MCP

• API: kept. An AI rule is an AutoRemediationRule at /api/auto-remediation-rule, with the same route, ids and permissions. It has new fields investigates and fixes, which default to false and true, so a client written before this change still creates rules that only fix. It also has onlyIfOpenAfterMinutes.
• Terraform: kept, renamed. The resource is oneuptime_ai_rule. oneuptime_auto_remediation_rule stays as a deprecated alias (from the model's formerSingularName and the tag's x-former-names), and a moved block switches over without replacing anything.
• Investigation rules: retired, with a clear path.
  • /api/ai-investigation-rule answers 410 Gone. The message names /api/auto-remediation-rule, oneuptime_ai_rule and investigates: true, fixes: false.
  • oneuptime_investigation_rule is gone.
  • Why not keep it as a shim: the rules live in one table now, and a second writable view of half of that table would let two resources disagree about the same rule.
• MCP: nothing to keep. Neither model was an MCP tool.
• Permissions:
  • The enum values are kept, so every custom role keeps what it may do. The titles now read Create / Edit / Delete / Read AI Rule.
  • A custom role with these permissions can now also manage rules that only investigate. Before, only Project Owner or Project Admin could.

Docs (17 languages)

• AI SRE: "Which incidents are investigated and fixed" is rewritten for the three steps, and there is a new paragraph on the API and Terraform.
• Every other page that named either kind of rule: incident settings, external MCP servers, LLM providers, API reference, run rules now, declaring incidents, postmortems, runbooks (index, running, agents), Infrastructure AI agents, Kubernetes agent and AI agent (Code).
• Upgrade note: "Investigation rules and auto remediation rules are now AI rules", in the 13 → 14 notes.
• Anchors are localized (docs:localize-anchors), and docs:check-anchors is clean.

Tests

• Common (jest):

  • AiRulesTable, AiRuleCopy, AiRule, AiRuleCriteria and AiRulesInLocale (every new sentence in 16 languages, and the retired ones gone).
  • AutoRemediationRuleAiRuleChecks: shape, wait, and conditions on create and update.
  • The engine: an incident that matches only rules that don't fix is not fixed, and its card says so.
  • Pull requests, and the plan, execution and MCP runners (a rule set to only investigate stops).
  • The investigation scope reads only rules that investigate.
  • Permission titles, AiRuleApiAndTerraform (the 410, the Terraform names), and every suite that named the old models.

• Postgres: MergeInvestigationRulesIntoAiRulesPostgres (described above) runs in the schema drift workflow. MergeInvestigationRulesIntoAiRulesMigration pins the statements.

• Offline browser (Playwright, real Chromium): the AutoRemediationRules suite (68 tests) and the InvestigationRules suite (10) are rewritten for the AI rule. They cover:

  • the three steps, Don't fix, rules that only fix and Investigate too;
  • More fields, with the Runner, repositories, MCP servers and provider;
  • the table fitting its card at 1280px beside the side menu, in English and German;
  • a viewer, a phone, and German;
  • the AI card and the rule dialog at 1280px and 390px, light and dark.

  PostmortemRules (26) covers the card order. All 104 pass.

• App: the docs suites (labels in every language, anchors, the upgrade note's shape, permission names) and the AI settings page suites.

• Mutation checks: each of these breaks was caught by its suite:

  • the update's shape check;
  • the investigation scope's investigates: true;
  • "rules that fix" in the engine and in the pull requests;
  • each runner's gate;
  • the fix columns written on create;
  • the answer "Fix like a new rule" sets;
  • the single column.

Not run here

• packages/E2E/Tests/Dashboard/AutoRemediationRulePullRequests.spec.ts needs a deployed stack. It is updated for the 410 route and for investigates/fixes, and it type-checks.
• The generated Terraform provider build, and a real LLM investigation or fix.

UI review

What I looked at. The real pages and dialogs, bundled from this branch in Chromium with the Dashboard's Tailwind runtime, theme and Inter, beside the real side menu (layout=page): at 1280px, and at 1024, 768 and 390px; light and dark; English, German, Russian and Japanese; no rules, rules of every kind (the four that were auto remediation rules, the two that were investigation rules), a full table of nine, and a viewer.

• Incidents and Alerts → AI → Settings → More settings, folded (the "AI rules: 5" chip) and open: the AI rules table, its empty state, the row's ⋯ menu and the Delete dialog, a bulk selection.
• The Create and Edit AI Rule dialog: Match, Investigate (right away, and a wait), Fix with each answer, More fields on a rule that fixes and on one that doesn't, the note on a rule that only fixes and Investigate too, the notes on older rules and Fix like a new rule, and the refusal when a rule that only fixes is set to Don't fix, at 1280px and on a phone.
• The incident's Remediation card, rule lane: one rule that only investigates matched, two did, none matched, and a rule that asks first.

What I changed, and why.

1. The fix pill says it is about fixing. It now reads Asks before fixing, Fixes without asking or Doesn't fix. The column is called "Investigates and fixes", so "Asks first" under "Right away" read as asking before the investigation, and "Without asking" didn't say what happens. The new pills use the words of the Fix step's answers. The pill wraps onto a second line instead of being cut short, as Russian's "Спрашивает перед исправлением" would be. 16 languages.
2. The card's line follows the rule's three steps. It now reads "…Add rules to choose which incidents it works on, when, and how each is fixed": Match, Investigate, Fix, in order. It is 205 characters. Before, it was 224, over the 210 that ShortDescriptionsGuard allows a card's line, and it ran to three lines in German. The guard can't read AI_LANE_RULES_COPY[props.lane], so AiRuleCopy's tests now hold the line to the limit. The translations already said this, so they are kept under the new key. "Pull requests included" stays, as AISettingsSwitchesFirst requires.
3. The fields every rule shares say only what is true of every rule. Code Repositories and MCP Servers now read "OneUptime AI may use all of your connected repositories (MCP servers). Pick some to let it use only those." Before, a Don't fix rule's form said OneUptime AI would "open pull requests in them". On a rule that fixes, the pull-request switches below say that. 16 languages, made from the old investigation-rule wording.
4. Description under More fields no longer shows the line "Description of this AI rule."
5. The Remediation card now says "With rules set up, OneUptime AI fixes only what matches a rule that fixes." Before, it said "only what a rule that fixes matches is fixed". Every translation already said it the new way, so they are kept.
6. Keyboard. Investigate too and Fix like a new rule both take their note away. Focus then fell back to the page, and the next Tab started again at the top of the dialog. Now focus moves to the question that takes the note's place: the checked "When to investigate" answer, or the Fix answer it now asks ("Ask before fixing"). It looks only inside the dialog, waits until the note is gone, and never takes focus back from where someone has moved it. This is the new Components/AISettings/FocusWhenDrawn.
7. A stale comment said the "only fixes" note explains what turning investigating on changes when it is the first such rule. It doesn't, so the comment now says what the button does.

Tests added or changed.

• Common/Tests/App/Dashboard/FocusWhenDrawn.test.ts (new):
  • focus goes to the picked answer, and to the first answer when none is picked;
  • it waits while the note is still drawn, and keeps looking while the form redraws;
  • it gives up after a few tries and leaves no timer behind;
  • it never takes focus back, and looks only inside the note's dialog.
• AiRuleCopy.test.ts:
  • every fix pill names fixing, in the words of its Fix answer;
  • both lanes' card lines stay within 210 characters and name the three steps;
  • the shared fields' lines say nothing about fixing or pull requests;
  • the focus selectors.
• AiRulesTable.test.tsx:
  • the pill wraps rather than ellipsizes;
  • Description has no column line;
  • the timing field's test id;
  • in both lanes, Investigate too and Fix like a new rule hand focus to the right answer;
  • the new texts.
• AiRulesInLocale.test.ts: the new sentences in 16 languages, and the replaced ones retired from every locale. RemediationDecisionLines.test.ts: the new sentence.
• Offline Playwright, AutoRemediationRules.spec.ts:
  • pressing Enter on Investigate too leaves focus on "Right away", and the arrow keys carry on from there;
  • pressing Enter on Fix like a new rule leaves focus on "Ask before fixing";
  • the new texts. The MCP servers check is now scoped to the folded line, because the field's own line starts with the same words.
• Offline Playwright, InvestigationRules.spec.ts: at 1280px, with rules that fix and rules that don't, every pill is drawn whole and Status stays in sight, in English and in German.
• That is 4 new offline tests, adding about 10 seconds to App Test group 7.

Merged master twice. Master's AddNetworkDeviceDiscoveredDetails took 1806800000000, so this PR's migrations are now AddAiRuleInvestigation1806900000000 and MergeInvestigationRulesIntoAiRules1806910000000, after it in Index.ts and in the tests that name them. The locale files were merged key by key: master's 29 new keys plus this branch's, with no key changed on both sides.

Verification after the last merge.

• Migrations, on a fresh postgres:15: the whole chain (784 migrations, master's first, then these two), the drift check ("No schema drift") and the merge's Postgres suite (27/27).
• Type checks: Common compile-tests, Dashboard tsc, App compile and E2E compile all pass. --listFiles shows nothing outside each package and Common.
• Common jest:
  • the 32 suites that read a changed module by basename (1,360 tests);
  • Locale (40 suites);
  • Guard, plus UpdateChecksReadHeldRows, DeleteChecksReadHeldRows, HookWritesCallersMayMake, ListOrderColumnModels and PermissionCatalogueCoverage (167 suites).
• App jest:
  • the suites that read a changed module (AISettingsSeparation, AISettingsSwitchesFirst, PostmortemRulesSettings, RemediationCardDarkMode and eleven docs suites);
  • ShortDescriptionsGuard, CardDescriptionBoilerplateGuard, CardDescriptionsSayWhatFor, DashboardLocalesGuard and DocsCriteriaConditions;
  • Locale;
  • the root-level suites and NormalizeListOrder.
• With ee/ hidden: the changed Common suites and AISettingsSwitchesFirst / ShortDescriptionsGuard pass.
• Offline Playwright: AutoRemediationRules + InvestigationRules 82/82, PostmortemRules 26/26.
• Other checks: i18n extract (no change), i18n check, the regex checker, prettier on every changed code file, and eslint on every changed .ts/.tsx.

Left alone on purpose, or for later.

• At 1280px in Russian, the table runs 14px past its card. Every column is at its minimum width, and "Редактировать" makes the Edit button wide. This was already so before this review. German and French fit.
• At 1024px beside the side menu, the table scrolls sideways under its sticky actions, as the other rules tables do.
• Two sentences are quoted in bold by the docs in 17 languages, so I left them: the AI Investigation card's "This incident was outside the AI rules that investigate at creation", and the upgrade note's "OneUptime AI fixes only what a rule that fixes matches".
• If every rule in a project is Don't fix, nothing is fixed even while "Fix new incidents automatically" is on. The card's line and each incident's Remediation card say so, but the switch doesn't. A line under the switch would be a follow-up.
• Rolling the images back after this upgrade, without running down(), is a risk. The older code reads every enabled AutoRemediationRule as one that fixes. The copied investigation rules and Investigate every incident would then propose fixes, asking first, while fixing is on.

🤖 Generated with Claude Code

[simlarsen]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.