sozo/v1.8.7

This release reverses a regression that was causing rejected transactions, makes sozo more tolerant of RPC version drift, and fixes a stale return value in the deployer that was breaking idempotent redeploys.

Behavior changes

sozo migrate no longer rejects transactions when gas prices move between blocks (#3406)

Since 67871d66, the account used by sozo migrate was pinned to Latest, so both nonce lookups and fee estimation read the most recently mined block. When gas prices moved, the resulting max_*_price could fall below what the next block actually required and the transaction was rejected.

The default is now back to PreConfirmed (the pre-0.17.0 behavior), so fee estimation and nonce lookups both target the block the transaction will land in.

A new global flag --account-block-id <latest | <block_number> | <block_hash>> lets you override this if you actually want the old Latest semantics.

If you scripted around the rejection (e.g. by inflating fee bounds or retrying), you can now drop those workarounds.

RPC spec version mismatch is a warning, not a fatal error (#3402)

Sozo was hard-erroring whenever a node reported a starknet_specVersion other than the one sozo was compiled against (0.9.0):

Unsupported Starknet RPC version: <x>, expected 0.9.0.

Every spec bump on a node sozo talked to therefore broke every command. This was overly defensive: the Starknet RPC spec is backward compatible across minor versions — a node serving a newer spec still answers the methods sozo uses with the same shape sozo expects. There's no need to abort up front.

The version mismatch (and any parse failure on the version string) is now a ui.warn(...) and execution continues. If a future spec bump ever turns out to be genuinely incompatible (a method removed, a field renamed), the failing RPC call will surface a specific error at the actual call site rather than a blanket abort at startup.

Assumption change: sozo previously assumed that any spec version other than 0.9.0 was unsafe and refused to proceed. It now assumes future RPC specs remain backward compatible and only warns. Treat the warning as a signal that you may want to upgrade sozo, not as a sign that the current run will fail.

dojo-utils Deployer::deploy_via_udc returns the real address on the already-deployed path (#3404)

When the target contract was already deployed at the UDC-derived address, deploy_via_udc returned (Felt::ZERO, TransactionResult::Noop) instead of (real_address, Noop). Re-running a deploy with the same salt therefore wrote 0x0 into any downstream state file, breaking idempotent orchestration (this is what was hitting saya-ops core-contract deploy --salt <X> on retry).

The address is now always surfaced.

Breaking for direct dojo-utils consumers: the internal helper deploy_via_udc_getcall changed signature from Result<Option<(Felt, Call)>> to Result<(Felt, Option<Call>)>. The Option now encodes "does a call need to be made", and the address is unconditional. Callers outside this repo that import dojo-utils directly (notably saya-ops) will need to update destructuring. End-users of the sozo binary are not affected at the CLI level — they just stop seeing 0x0 on re-runs.

Housekeeping (no behavior change for users of the sozo binary)

• ci: pin starknet-foundry to 0.55.0 to unblock the test workflow (#3403)
• dojoup: add saya to the install script (#3399)
• ci: enable and improve docs-sync workflow (#3398)
• chore: agent skills and standards (#3397, #3396)

Full Changelog: sozo/v1.8.6...sozo/v1.8.7