feat: re-port the cli-harness novelties and ADR 0004 from upgrade_to_ironwood_03 - #2536
Open
zancas wants to merge 3 commits into
Open
feat: re-port the cli-harness novelties and ADR 0004 from upgrade_to_ironwood_03#2536zancas wants to merge 3 commits into
zancas wants to merge 3 commits into
Conversation
…eights TOML zingo-cli's --chain regtest previously carried only the compiled-in default schedule (every upgrade at height 1), which contradicts the infrastructure repository's ADR 0003: the running Validator is the single source of truth for regtest activation heights, and no wallet may substitute a second one. This commit adds an --activation-heights <PATH> flag, valid only with --chain regtest, through which a harness serializes the Validator-derived schedule into the binary. The schema is the one zcash-devtool already consumes and zcash_local_net already writes: one optional `<upgrade> = <height>` line per network upgrade, an omitted key meaning the upgrade never activates, an unknown key a hard error. ADR 0004 in this repository records the decision and the rejected alternatives. The parser validates that the schedule is prefix-contiguous and non-decreasing before handing it to the ActivationHeights builder, because the builder enforces that invariant by panicking and malformed operator input must produce an error message rather than a process abort. The NU6.2 schema deliberately has no nu6_3 key, so a schedule from an NU6.3 chain is refused loudly instead of being silently truncated; the key arrives with the Ironwood wallet work. Unit tests pin the harness NU6.2 shape, the omitted-key semantics, and the rejection paths, and the flag was smoke-verified against the built binary. This is the product-side half of the zingolib-wallet-impl-spec deliverable (infrastructure PR #280); the harness-side Wallet implementation follows separately. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…zingo-cli binary This crate is the harness-side half of the zingolib-wallet-impl-spec deliverable (infrastructure PR #280): ZingoCli and ZingoCliConfig implement zcash_local_net's Wallet and WalletConfig traits by driving the shipped zingo-cli executable as run-to-completion one-shot subprocess invocations against a persistent --data-dir, mirroring the harness's in-tree zcash-devtool implementation. The binary is located through TEST_BINARIES_DIR falling back to PATH, and regtest activation heights reach it through the --activation-heights TOML introduced in the previous commit, written from the Validator-derived schedule on every invocation. The sync policy is strict: every operation passes --nosync except Wallet::sync, which blocks on the startup sync with --waitsync and persists with `save`. balance and address are therefore pure local reads, and callers sequence act, mine, sync, assert explicitly, as the trait contract prescribes. rescan maps to `clear` because zingo-cli's own rescan command only launches a background task a one-shot process cannot wait for. Parsers for the txids JSON, the bracketed balance listing, the height and info JSON, and the addresses array are pinned by unit tests against recorded shapes; bare receivers derive from the unified address via zcash_address rather than adding invocation shapes to the output contract. The proof-scenario integration test exercises every trait operation on LocalNet<Zebrad, Zainod> at the NU6.2 chain shape: launch the faucet, mine, sync, verify the miner-reward ladder (accounting for the launch block a fresh zebrad mines), send to a recipient, fund and shield the transparent receiver with non-coinbase funds, rescan, and validate balance persistence. It is #[ignore]d because it needs zingo-cli, zebrad, and zainod binaries, which the container-test flow provides. The crate carries its own zcash_local_net pin on the bump_to_NU6.3 branch, where the Wallet traits live past the tag the rest of the workspace pins; the workspace moves wholesale later. The NU6.3/Ironwood leg of the spec's scenario is deliberately deferred to the Ironwood wallet work, and the test asserts ironwood_spendable is zero throughout. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
zancas
added a commit
that referenced
this pull request
Jul 26, 2026
Two ADRs claimed number 0015 after concurrent branches merged: the immediate-migration Drain record and the wallet-file-format record. The Drain record keeps 0015, because ADR 0016 already cites it by that number. The wallet-file-format record becomes ADR 0018, the next free number (0004 lands via PR #2536, and 0010, 0012, and 0013 are reserved by unmerged branches). The CONTEXT.md Shipped Format entry now points at 0018. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR re-ports the two novel commits from the abandoned
upgrade_to_ironwood_03branch onto the current mobile line. The branch's other six commits were not ported: their content (the workspace Ironwood migration, the darkside retirement, and their documentation) merged long ago through other routes, and a rebase probe showed every replayed commit conflicting against its own landed descendants.The first commit brings zingo-cli's
--activation-heights <PATH>flag: a TOML file of network-upgrade activation heights, in the schema zcash-devtool consumes and thezcash_local_netharness writes, accepted only with--chain regtest. It carries ADR 0004, which lands in mainline ancestry for the first time and closes the 0004 gap indocs/adr/.The second commit brings the
zingo-cli-harnesscrate, thezcash_local_netWalletimplementation that drives the real zingo-cli binary, with its parse layer and theproof_scenariotest.Both are conflict-resolved cherry-picks preserving the original authorship. Three deliberate deviations from the originals: the
zingo-climanifest resolves as a union (HEAD'sthiserroralongside the port'sserdeandtoml), the harness crate's privatebranch = "bump_to_NU6.3"pin ofzcash_local_netcollapses toworkspace = true(theWallet/WalletConfigtraits it existed for are present at the workspace's pinned rev, and the no-branch-pins rule forbids keeping it), and the lockfile was regenerated by cargo rather than merged.cargo check,cargo clippy(both crates, all targets), andcargo fmt --checkall pass; the liveproof_scenariorun is left to the container suite.🤖 Generated with Claude Code