RFC: Rule authoring in the UI as a thin client over git PRs?

[julietshen]

The Rules and Features registries in 1.1.0 made it easier to see what an Osprey deployment is running. The natural next step a few of us have been kicking around (and is heavily requested by potential adopters) is making it easier to add a rule from the UI. For the MVP, maybe we could design it so it doesn't give up the git-based governance and source-of-truth model that production deployments rely on today.

Here's how I think it could work:

• User drafts a rule in the UI, with the engine's existing AST validator giving them compile-level feedback as they type.
• On save, the UI calls the configured git backend to create a branch, commit the SML file change, and open a PR.
• Review happens in the normal git review surface (PR comments, approvals, CI). Nothing about how rules land in production changes.
• During an incident, users and engineers fall back to the existing git workflow directly as there won't. be a separate emergency UX in the UI that overrides anything

This keeps git as the source of truth, preserves audit and review, and gives non-engineer operators a friendlier on-ramp for writing rules.

A few things I'd like input on:

1. Backend abstraction vs. GitHub-first: Where do most of you actually keep your Osprey rules? I lean towards using GitHub as the MVP, but if there's real demand for Tangled, GitLab, self-hosted Gerrit, or plain-filesystem repos, that argues for a RuleSubmissionBackend abstraction.
2. User git identity: Does it make sense to require per-operator OAuth (commits carry real attribution, requires every operator to have repo access), or is a service account with operator identity in the PR title/body good enough?
3. Preview-against-traffic: We're explicitly scoping the MVP out of "preview the draft rule against recent events"/run in background preview. Users can iterate locally or in a dev environment the same way they would today.

If this feels and sounds good, I'm happy to write up a more detailed design doc. If it doesn't, let me know!

[julietshen]

I made a proof of concept of how this works.

1. Create a new rule called "ContainsCat" looking for the word "Cat" in a PostText. Double check the SML and see an error if the validator rejects any of how it's built/formattted. The generated SML is below in a read-only state.

2. If you want to edit the SML directly, switch to "Code Editor".

3. Once all the fields are correct, the validator will say the Osprey engine accepts this new rule

4. If you hit 'submit for review' a banner shows up linking to the pull request that needs to be reviewed (github is typically the standard process for adding a new rule in Osprey today)

5. The Rules Registry page shows rules that are running in Osprey and a banner of pending rules

6. See the open PR created by Osprey in Github with the information provided from the Osprey UI

7. See the diff of the new rule added, and since I checked the checkbox for "run this rule once review is approved", a change to the main.sml file

8. The Rules Registry then updates with the new rule, showing that it's now running.

[julietshen]

Some thoughts I'm porting over from Discord:

1. Even for an MVP / experimental feature, having an abstracted backend so it's not Github exclusive is important.
2. This is an MVP but really a bandaid solution for the code being the source of truth for rules and authoring them. It might make more sense for Osprey to have a database for rules vs having to reference the source code itself

[ThisIsMissEm]

As mentioned on call, I'd drop all SCM integration, in favour of a simple database table + persistent links for pending rules, so like /rule-drafts/:id or something. This also moves you towards UI based rules management in general, and then you can have maybe a webhook or something that can sync them to an external system (or publish to etcd)

The pending rules list should also have one-click to access the rule source in SML such that it can be one click to view + one click to copy + whatever SCM stuff they need to do.

[wayjaywang]

For MVP UI, I don't have anything major to add.

One nice to do would be to move the "Submit for Review" action button into the validation card. Since you can only submit for review if there are no errors, I think it makes a lot of sense to have the button closer to the status info. I also wonder if the "turn this rule on once review is approved" check box should be in the validation card as well.

[ThisIsMissEm]

I'd probably keep the button where it is, but disable it if the rule hasn't been validated yet; or swap it for a "validate" button, and then once validated the button swaps to a "submit for review" button (make sure there's a minimal artificial delay between button click -> disabled for validating -> submit for review swap, as to prevent accidental submission; could also use a confirmation before submission)