Add deployment_list, deployment_retry and deployment_start agent tools#1832

_{P1 Badge} Block local deployment lifecycle calls without a runner

When ployz mcp uses a local Store, its write backend only calls ConfigStore::write (handlers/mcp.rs:241-243), whereas the local CLI explicitly calls ship after retrying or starting (handlers/deploy.rs:886-912). Consequently, deployment_retry queues a Deployment that no runner receives, and deployment_start likewise reports success before repeatedly following an unchanged queued Deployment. Either refuse these tools for StoreAt::Local or have the local MCP path launch the deployment runner.

Useful? React with 👍 / 👎.

Not fixing in this PR. The gap is real but it predates these tools. The deploy tool (tools/release.rs) already writes Admit::Deploy through the same local ConfigStore::write with no ship, so a local ployz mcp deploy also queues a Deployment no runner takes. Refusing only retry and start locally would make them disagree with deploy. The fix belongs in the local MCP backend, which should run the runner after a local admit or start write for all three tools. I have noted it as a follow-up.

_{P1 Badge} Preserve the omitted retry target across keyed replays

When deployment is omitted and the first keyed retry succeeds but its response is lost, replaying the identical input resolves “latest” again, now selecting the newly created retry, and constructs Admit::Retry with a different source. The Store therefore sees the same minted ID with a different command body and returns conflict instead of the recorded Deployment, breaking the documented request_key recovery precisely in the lost-reply case. Resolve a keyed replay before looking up the latest Deployment, or require/persist the concrete source selected by the first call.

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

Useful? React with 👍 / 👎.

Fixed in d3f45520. When deployment is omitted, retry now reads the minted ID in the same step as the latest Deployment. If that ID already names a Deployment, it returns the recorded one and skips the write. With an explicit deployment, the Store's own replay already matches, and a reused key with a different source still conflicts. The new test is a_keyed_retry_of_the_latest_replays_after_it_becomes_the_latest. It fails with the replay branch disabled.

🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Run agent_tool_calls through the shared backend helper.

deploying() calls shop(), which hard-codes sqlite::memory:. The saved-revision assertions therefore run only on SQLite. The PostgreSQL CI command also omits agent_tool_calls, so changing the fixture alone is not sufficient. Use backend::open() and add this test binary to the PostgreSQL target list.

Not in this PR. Every test in agent_tool_calls.rs runs through shop(), which uses SQLite, and the PostgreSQL CI list omits the whole binary. That predates this change. The new assertions read tool output, which the Store computes the same way on both backends. Moving the file onto backend::open() and into the PostgreSQL target list belongs in its own change.

@nick-potts Thanks for clarifying. I withdraw this finding from #1832. The SQLite fixture and PostgreSQL CI omission predate this change; the new tool-output assertions do not justify migrating the whole test binary in this PR.

Would you like me to open a separate issue for the backend coverage change?

✅ Review thread resolved.

You are interacting with an AI system.

_{P2 Badge} Reject replay keys reused in another environment

When deployment is omitted, any Deployment found under the minted ID is accepted as a replay without validating the requested scope. For example, after key K retries production, { "environment": "staging", "request_key": "K" } returns the production Deployment as a successful result instead of reaching the Store's keyed-command check, which would reject the different body. Verify that the recorded Deployment belongs to the resolved scope—or persist and validate the original concrete command—before returning it.

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

Useful? React with 👍 / 👎.

Fixed in e3ef5256. A recorded Deployment counts as a replay only when it belongs to the resolved Environment. Otherwise the call carries on normally. The test now reuses the key against an empty preview Environment and expects not_found. It fails with the check removed.

_{P1 Badge} Serialize replay detection before resolving latest

Although the new ID lookup fixes sequential lost-reply replays, fresh evidence in handlers/mcp.rs shows these two Store reads are executed concurrently via join_all. If a retry begins while the original uncertain write is committing, the ID lookup can return not_found before the commit while the newest lookup observes the newly queued retry afterward; this call then selects that retry as its own source, and the Store rejects the reused ID with a different command instead of returning the recorded Deployment. Resolve the replay lookup before querying latest, or recheck the ID after that query, so documented lost-reply recovery is not timing-dependent.

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

Useful? React with 👍 / 👎.

Fixed in e3ef5256. The latest page now counts too: if the newest Deployment already carries the minted ID, the original landed between the two reads, so this call returns that Deployment instead of taking it as the source. This stays within the three-step limit. The harness can't order two reads that run together, so this path is covered by review, not a test.

Correction to my earlier reply: the harness can order the reads. a_keyed_retry_that_lands_between_its_replays_reads_is_the_replay (494cc850) answers the ID lookup with not_found, lands the original retry, then answers the newest-page read. It expects Deployment #2 back as the replay. Dropping the latest-page check makes it fail.

🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Apply request-key replay before the explicit deployment branch.

start creates a fresh state and runs the plan; it does not return an earlier result for a different call_key. Therefore, two deployment_retry calls with different outer call keys but the same request_key and explicit deployment number can both reach cx.write(&retry). The second write reuses the first deployment ID and can fail on the primary key instead of returning the original retry, which violates the request-key idempotency contract.

✅ Addressed in commit e3ef525

Declining. With an explicit deployment, the replay sends the same Retry body, so the Store already returns the recorded Deployment. Reading the ID first there would also turn a key reused against a different source from a conflict into a silent success. Only the omitted case needs the lookup.

@nick-potts Thanks for clarifying. I withdraw this finding.

With an explicit deployment, the same Retry body lets the Store return the recorded Deployment. Moving the ID lookup ahead of that branch would bypass the Store’s conflict check when the key names a different source. Only the omitted-deployment case needs the lookup because “latest” can change after the first retry.

✅ Review thread resolved.

You are interacting with an AI system.

_{P2 Badge} Reject request keys reused with a different retry target

When a key first retries an explicit Deployment and is later reused in the same Environment with deployment omitted, this branch finds the minted Deployment, passes the ID/environment filters, and reports success even though the call body changed. For example, retrying #1 with key K creates #2, then {request_key: K} silently returns #2 instead of rejecting an attempt whose resolved target is now #2; validate the original source as well as the Environment before treating this as a replay.

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

Useful? React with 👍 / 👎.

Declining. A request_key names one retry. In the same Environment, {request_key: K} returns the retry K already created, which is what a replay is for. Checking the original source would mean storing it on the Deployment, and the Store doesn't keep a retry's source. The rejection that matters still holds: an explicit deployment with a reused key reaches the Store and conflicts on a different body.

_{P2 Badge} Recheck the replay ID after resolving the newest Deployment

Fresh evidence after the earlier replay fix is that the fallback examines only the single newest Deployment. If the ID lookup misses just before the original retry commits, and another admission lands after that retry but before the concurrent newest query completes, the page contains the later Deployment rather than the minted one; this replay then selects the later Deployment as its source and the Store rejects the reused ID with a different command. Recheck the minted ID after the page read (or serialize the reads) so a lost-reply replay is not broken by an intervening admission.

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

Useful? React with 👍 / 👎.

Declining. This needs the original retry and a second admission to both commit inside one pair of concurrent reads. Even then nothing goes wrong: the call refuses with a conflict and writes nothing, and the next replay finds the minted ID on its first read and returns the recorded Deployment. Adding a fourth read would go over the three-step limit for a case that already fixes itself.