# Add Live Search to a Phoenix LiveView Page from a Linear Issue

Yes. An agent picks up the Linear issue, adds debounced live song search on your Phoenix LiveView profile page, runs mix test and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/add-song-search/phoenix-liveview/), 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 reads the profile LiveView before adding inputs. In a codebase like fly-apps/live_beats (Phoenix `~> 1.7.1`, LiveView from the Phoenix GitHub override, Elixir `~> 1.12`), `lib/live_beats_web/live/profile_live.ex` streams songs with `MediaLibrary.list_profile_songs(profile, 50)` into `#songs`, with upload and delete flows but no search box. `LiveBeats.MediaLibrary.Song` has `title` and `artist` fields. Tests in `test/live_beats_web/live/profile_live_test.exs` cover upload and delete on the owner's profile. `config/test.exs` points at Postgres database `live_beats_test` on localhost.

It adds a search input on the profile template with `phx-change` and a debounce attribute, holds the query in socket assigns, and filters the streamed songs by title and artist (either in `list_profile_songs` with a query argument or in the LiveView before `stream`). Empty query restores the full list. It does not disturb presence, the player `switch_profile` buttons or the upload modal.

It extends `profile_live_test.exs` with LiveViewTest cases: type a query and assert non-matching rows disappear from the render, clear the query and assert they return. The agent starts Postgres in the sandbox, runs `mix test`, and fixes flaky stream assertions against the `#songs` table markup.

Last, it opens a pull request that links the Linear issue, names the LiveView and MediaLibrary touches and points reviewers at the new search tests.

## 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 Live Search to a Phoenix LiveView Page. Add a search box on the profile page that filters songs by title and artist as the user types, debounced, using phx-change.\" Do the work in this repository, add tests for it, run mix test with Postgres started in the sandbox, 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 notes the profile page listed up to 50 songs with no filter, then shows the debounced `phx-change` search and how filtering applies to title and artist. The Linear issue is linked.

The transcript keeps Postgres startup, `mix test` and any compilation warnings. Failures from stream DOM ids or missing assigns stay visible in the session record.

Before merging, a reviewer checks debounce timing, case-insensitive matching if promised, that uploads still work with a query active and that the new tests fail when the filter handler is removed.

## 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?

LiveView tests need a migrated Postgres database and the project's test support fixtures. In a Rush sandbox the agent starts Postgres, runs `mix test` against `live_beats_test` and keeps the output, so search regressions do not depend on a developer's local Docker Compose state.

Labelling the Linear issue is enough to get a PR with LiveViewTest proof. Several LiveView issues can run at once in separate sandboxes and branches, up to the key's `max_concurrent` limit.

## Frequently asked questions

### Is filtering server-side or only in the browser?

Server-side through the LiveView (`phx-change`). The agent filters assigns or the MediaLibrary query and restreams `#songs`; it does not add a client-only JS filter that drifts from the server list.

### Does search include transcripts?

The issue asks for title and artist. Transcript text stays out of the filter unless a follow-up issue expands it.

### Will it break the 50-song cap?

It keeps the existing `list_profile_songs(profile, 50)` limit unless the PR explicitly raises it. Search filters within that loaded set or pushes the query into the SQL limit consistently; the PR states which.

### Why Postgres in the sandbox?

Because `config/test.exs` uses the Postgres adapter and `Ecto.Adapters.SQL.Sandbox`. SQLite would not match how this app's tests are written.