# Add Muting Users to a Rails App from a Linear Issue

Yes. An agent picks up the Linear issue, adds user muting so stories and comments hide everywhere, runs RSpec and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/add-user-mute/rails/), in a Project that has your repository.

## What the agent does

The agent starts from the Linear issue and the repository in its own sandbox, and studies how hiding already works. In a codebase like lobsters/lobsters (Rails on Ruby 4.0.0 per `.ruby-version`, RSpec under `spec/`), users can hide individual stories through `HiddenStory` (`app/models/hidden_story.rb`) with `hide_story_for_user` / `unhide_story_for_user`, and `Story.not_hidden_by` / `Comment.not_on_story_hidden_by` filter those rows. `User` has `has_many :hidings` but there is no mute-user association that drops another author's stories and comments everywhere. Settings live in `SettingsController` and the `/settings` UI.

It adds a mute model (or equivalent join) from muter to muted user, migrations, and scopes so home, newest, story and comment listings omit muted authors for the signed-in viewer. It exposes mute/unmute actions and a mute list on the settings page, reusing the app's auth and CSRF patterns. It does not reuse `HiddenStory` for whole users, because that table keys on `story_id`.

It adds RSpec request or model specs beside existing hide/settings examples: muting hides that user's stories and comments from the muter's feeds, unmute restores them, and the settings mute list shows the muted username. It runs `bundle exec rspec`, using the project's SQLite setup from the Gemfile unless the suite says otherwise.

Last, it opens a pull request that links the Linear issue, lists migration, model, controller, settings views and specs, and points reviewers at the RSpec transcript.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A Linear issue labeled agent says: \"Add Muting Users to a Rails App. Let a signed-in user mute another user so their stories and comments are hidden from them everywhere, with a mute list in settings.\" Do the work in this repository, add tests for it, run bundle exec rspec, and open a pull request that links back to the issue.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request on its own branch. The description contrasts story-level `HiddenStory` with the new user mute, shows where feeds filter muted authors and where settings list mutes. The Linear issue is linked.

The transcript keeps `bundle exec rspec` (and any migration steps) with full output. A broken scope that hides everyone or nobody fails in that log before merge.

Before merging, a reviewer checks that mutes are per-viewer only, that moderators still see content when required, that unique constraints prevent duplicate mutes and that the new specs fail if the feed scopes skip the mute join.

## Run it on every Linear issue labelled agent

In the console, an automation with a `linear` trigger on `linear.issue.labeled` and the label `agent` starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.

From your own server, the same run is one `POST /o/{org}/sessions` per issue: put the repository in `resources`, and add the issue's `https://linear.app/<workspace>/issue/<ID>` URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts `run.completed` or `run.failed` when the turn finishes, with the `session_url` to read the result.

## Why run it on Rush?

Lobsters-scale feed scopes touch stories, comments and settings together; a wrong join is only obvious under RSpec with fixtures. In a Rush sandbox the agent runs `bundle exec rspec` on an isolated database and keeps every failure, so the mute feature is proven without loading a reviewer's local SQLite file.

A Linear label becomes a reviewable social feature PR. Several Rails issues can run in parallel sandboxes under the key's `max_concurrent` limit, each with its own branch and transcript.

## Frequently asked questions

### Is this the same as hiding a story?

No. `HiddenStory` hides one story. Muting hides that author's stories and comments from the muter everywhere until unmute. The agent keeps both features.

### Can I mute a moderator?

The agent follows product rules already in the app for blocks or similar. If none exist, the PR states whether staff accounts can be muted and reviewers can tighten it.

### Does the muted user get notified?

Not in the basic issue. Mute is private to the muter unless a follow-up asks for notifications.

### Where is the mute list?

On the settings page (`SettingsController` / `/settings`), listing muted usernames with an unmute control, matching how Lobsters already centralises account preferences.