Add project_rename and config_rename agent tools#1850

_{P1 Badge} Move the dashboard context after a project rename

When project_rename is called from the sidebar while viewing that Project, this write changes its lookup name but nothing moves the dashboard to the new route. placeIn in dashboard/src/modules/agent/agent-chat.server.ts continues deriving every subsequent tool's default Project from the latest page-context block, which still contains the old URL/name; the regular settings rename explicitly navigates after committing for this reason. Consequently, a following environment_show, service_add, or other call that omits project targets the now-missing old name and returns not_found, while the page itself is left stale. Update the dashboard route/page context, or the agent's current Place, after this result.

Useful? React with 👍 / 👎.

Fixed in b5e2d373e: the sidebar's place now follows each project_rename result that ran after the newest page block (renamedSincePage), so later calls target the new name. Moving the page itself is left as a follow-up.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Make the expected-revision check atomic with the rename.

Cx::expect only reads the Environment revision. A concurrent write can occur before the separate cx.write call. The rename can then be staged after the caller’s expected revision is stale. Use cx.batch with self.expect_revision, as ConfigRemove does.

✅ Addressed in commit b5e2d37

Fixed in b5e2d373e: config_rename now writes through cx.batch with expect_revision, as config_remove does.

@nick-potts Thanks for the fix. config_rename now passes expect_revision through cx.batch, so the revision check and rename are atomic.

✅ Review thread resolved.

You are interacting with an AI system.

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Reuse the organization resolved before the write.

For a device credential, store_at makes another Cloud lookup after RenameProject has committed. If that lookup stalls until the MCP deadline, the outer call drops the link follow-up. The directory links retain the old Project name, and the error note at Line 614 never runs. Pass the organization resolved when the call started into this follow-up instead.

✅ Addressed in commit b5e2d37

Fixed in b5e2d373e: the call keeps the StoreAt it resolved before the write, and the link move reuses it.

@nick-potts Thanks. The supplied code retains StoreAt before the write and reuses it for the link move. This removes the second Cloud lookup from that path.

✅ Review thread resolved.

You are interacting with an AI system.

_{P1 Badge} Preserve renames across later stale page markers

When a member renames the currently open Project and then switches dashboard sections, this cutoff discards the successful rename because the new page marker becomes the start of the search. Fresh evidence in this revision is that use-agent-page.ts:15 continues deriving project from the unchanged route parameter, while dashboard-navigation-model.ts:115-123 reuses that old parameter when changing sections; unlike the settings rename flow, the agent rename never navigates to the new slug. The later marker therefore still names the old Project, renamedSincePage no longer sees the preceding rename result, and subsequent tools that omit project target the now-missing name and return not_found; preserve the rename chain across stale markers or navigate the route after the rename.

Useful? React with 👍 / 👎.

Fixed in df18cd701: followRenames applies every successful project_rename in the thread, so a later block that still names the old Project resolves to the new one.

Replaced in 5970ca590. followRenames is gone. The page context now carries the Environment's id, and before each tool phase the place resolves it to the Environment's and its Project's current names. A stale URL after a rename resolves to the new name, and a new Project that takes the old name resolves to itself. Environment renames are followed too. Every page that names a Project also names an Environment, so no page needs a name-only rule.

_{P1 Badge} Reconcile links after uncertain rename writes

When a Cloud rename commits but its reply is lost or the MCP deadline expires, written is an error with writes: unknown, so this guard skips the link migration even though the Store may already use the new name. Retrying the same project_rename cannot repair the link because the old source name no longer exists, and later calls that omit project continue reading the stale link and return not_found; reconcile uncertain writes or make the rename replayable before deciding not to move the link.

Useful? React with 👍 / 👎.

Deferred to a follow-up. An unknown write outcome needs a deadline or a lost reply after the commit. ployz project rename has the same gap. The next call refuses with not_found naming the linked Project, and ployz link fixes it.

_{P1 Badge} Stop applying old renames to newly reused names

If this thread previously renamed shop to store, and a member later creates or renames another Project to shop and opens it, the latest page context correctly supplies shop but this reduction replays the historical result and silently changes the default place to store. Subsequent omitted-project calls then act on the wrong Project; distinguish a stale post-rename route from a legitimately reused name, for example by tracking stable identity or navigating after the rename instead of replaying every historical mapping.

Useful? React with 👍 / 👎.

Fixed in 5970ca590. The replay is gone. The place resolves the page's Environment id, so a new Project that reuses the old name resolves to itself.

🚀 Performance & Scalability | 🟠 Major | 🏗️ Heavy lift

Avoid a sequential Environment read for every Project.

After a Project rename, the block’s old Project name is absent from the listing. Each tool boundary can then read Environment listings one Project at a time until it finds the ID. In a large organization, this adds up to one Store request per Project on every tool boundary. Resolve the Environment ID with an indexed lookup or a batched lookup instead.

Kept as is. The page's own Project is read first, so the scan only runs while a page still shows a name a rename moved away from. It stops at the first match, and Organizations hold a handful of Projects. The Store has no lookup by Environment id today. Adding one is a follow-up if this ever shows up in traces.

@nick-potts Thanks for the guidance. The Project-first lookup and small Organization size make this scan reasonable. I withdraw the Major finding.

Would you like a follow-up issue for an Environment ID lookup, or leave that decision to trace evidence?

✅ Review thread resolved.

You are interacting with an AI system.

_{P2 Badge} Isolate project renames from same-turn tool calls

When the model emits project_rename alongside another compiled tool that omits project, this resolves here.place only once before the whole tool phase, and the multi-call guard does not reject project_rename because it is Gate::Never. Both calls therefore use the old Project name; if the rename write lands first, the other call targets a name that no longer exists and returns not_found (and execution order makes the outcome nondeterministic). Require project_rename to run alone or refresh/update the shared place before other calls execute.

Useful? React with 👍 / 👎.

Deferred to a follow-up. A call that lands after a same-turn rename gets not_found naming the old Project, and the model retries it in the next turn, where the place has already moved. Nothing lands in the wrong Project.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Keep the catalog cap at the stated budget.

Line 8 sets CAP_BYTES to 50,760, but the PR objective specifies 50,700 B. This permits catalog sizes from 50,700 through 50,759 B. Set the cap to 50,700; the reported 50,641 B catalog remains below it.

Keeping 50,760. CI tests the merge with main, and main's server_forget already grew the merged catalog to 50,752 B, so 50,700 fails rust-tests (it did on 5970ca590). The PR body's 50,700 figure is stale.

@nick-potts Thanks for the clarification. The merged catalog at 50,752 B needs the 50,760 B cap. My finding relied on the stale PR-body figure, so I withdraw it.

✅ Review thread resolved.

You are interacting with an AI system.

_{P2 Badge} Avoid scanning every Project to resolve one Environment

When the current Project has just been renamed, named.project is absent from listed, so this loop issues sequential environments reads for every Project until it reaches the renamed one. Because Organizations support unlimited Projects and the stale page block is reused, renaming to a late-sorting name can make every subsequent agent tool phase perform hundreds or thousands of Store reads and potentially time out; resolve the stable Environment ID with one Store query or include Environment IDs in the Projects view instead.

Useful? React with 👍 / 👎.

Same point as the CodeRabbit thread on this loop: the page's own Project is checked first, Organizations are small, and the scan only runs in the turn after a Project rename. Keeping it; an Environment-id read in the Store is the follow-up if traces ever show it.

_{P1 Badge} Refuse unresolved page scopes instead of defaulting them

When the Environment identified by the latest page marker has been deleted, this returns { project: null, environment: null }, but Place interprets those nulls as Store defaults rather than an invalid location. In a single-Project organization, a subsequent tool such as service_add that omits its scope can therefore modify the Project's default Environment—often production—instead of refusing to act on the vanished page, contrary to the newly documented behavior in docs/user/account/agent-sidebar.md. Preserve an unresolved state that tool execution refuses rather than converting it to the default scope.

AGENTS.md reference: AGENTS.md:L6-L6

Useful? React with 👍 / 👎.