What the agent does
The agent identifies both editor routes and the editor's actual state. In realworld-apps/angular-realworld-example-app, src/app/app.routes.ts has an editor parent with empty-path and :slug children. Both lazy-load the same editor component and already use requireAuth for activation. The change adds a functional CanDeactivate check to the relevant child routes without replacing authentication. Covering only the new-article route would leave existing article edits unprotected.
src/app/features/article/pages/editor/editor.component.ts uses a reactive articleForm for title, description and body. It also keeps tags in a tagList signal and pending tag text in tagField. Loading an article calls patchValue and sets its tags, while addTag and removeTag update the signal directly. The agent includes those edits in the unsaved-change definition; checking only the form's dirty flag would miss changes outside that form.
It defines the saved baseline after an existing article loads, and updates it only when a save succeeds. submitForm currently adds any pending tag, chooses create or update from the route slug and navigates to the saved article in the success callback. The guard must allow that successful navigation while retaining protection after a failed save. Tests cover declining and accepting confirmation, leaving an untouched editor, changing only tags and navigating after a successful submission.
The repository's package.json uses Angular 21.2.12, sets test to vitest and build to ng build, and supplies test:e2e through Playwright. angular.json also references assets from the realworld submodule. The agent follows bun run setup for that prerequisite, then runs bun run test --run and bun run build. Router-level checks exercise navigation rather than only calling a guard function with a hand-built dirty flag.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent requests confirmation when leaving the Angular article editor with unsaved changes, using a functional CanDeactivate guard. Inspect app.routes.ts and the existing editor component. Cover both editor routes, preserve requireAuth and include title, description, body, tag changes and pending tag input in the unsaved-change policy. Establish the clean baseline after loading, permit navigation after a successful save and preserve protection after a failed save. Add real router navigation tests for clean state, accept/cancel, tag-only edits and save success/failure. Follow the repository setup instructions, including its realworld submodule. Run bun run test --run and bun run build, and report any additional browser checks separately. Open a pull request linking the supplied Linear issue URL and describing the exact protected navigation scope.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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.
- 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.
- 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
The PR contains the guard, its route registrations, the editor changes needed to expose unsaved state and tests for actual navigation outcomes. Its description states when the baseline becomes clean and how tag edits participate. It also names the confirmation interaction and any browser coverage. A function that returns a boolean without exercising the router is insufficient evidence that users can cancel navigation.
Before merging, a reviewer opens both new and existing articles, makes an edit and tries to leave. Cancelling must keep the route and content; accepting must allow departure. Saving successfully must lead to the article without a redundant warning, while a failed save keeps the draft protected. Build output confirms that the guard and lazy-loaded route configuration compile together, and the session record supplies the test commands rather than an invented account of a completed run.
Run it on every Linear issue labelled unsaved-changes
Your Linear receiver selects the label and sends the issue description and URL in input, along with the app's installed repository as a resource. Include the editor routes, what counts as a change and whether browser-tab closing is in scope. The receiver calls POST https://api.prix.dev/o/{org}/sessions with an API key; the label itself is outside the API body. Reuse an idempotency header for retries of the same issue revision.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Unsaved-change behavior crosses route configuration, form state and asynchronous submission. Rush gives the agent an isolated sandbox to follow that path and run the repository's router tests and build. The work does not interrupt your local editor session, and its output shows whether the implementation considered tags and loaded data instead of treating a dirty checkbox as the whole requirement.
Different applications can receive separate guard tasks at once, each with its own route assumptions and reviewable result. The transcript keeps tool calls and their output, so the reviewer can inspect the setup and test behavior behind a PR. A follow-up after the turn ends can refine the confirmation policy without discarding the investigation or starting with a generic guard example.
Frequently asked questions
Does this replace the existing authentication guard?
No. The inspected editor routes already use requireAuth for activation, and the request preserves it. The new check controls leaving an editor whose content has changed.
Are tag-only edits protected?
They must be included for this editor because tagList is a signal separate from articleForm. The task also requires a policy for unsaved text in tagField. Router tests should show that these changes receive the same protection as the article body.
Will publishing an article trigger a warning?
A successful save should establish the new clean state before the existing navigation completes. A failed request must leave the editor protected. The PR includes both paths so a save-in-progress flag cannot accidentally discard an unsaved draft.
Does CanDeactivate cover closing the browser tab?
This task covers Angular router navigation. Browser reload and tab closing require a separate unload policy if your issue asks for them. The PR must distinguish that scope instead of presenting an in-app guard as complete protection against every way of leaving.