Make a first change in 30 minutes

This path is for a small, reviewable Rust/RHDL change. It is an orientation exercise, not a promise that every hardware change can be completed in half an hour. Read Build and inspect locally first if the workspace is not already available.

Completion warning: the highest passed signer-performance tier is generated RTL. The reported 481.6875-cycle sustained interval and its 519,008.693-results/s normalization at 250 MHz are not measured U280 results. U280 synthesis, route, and card execution remain pending, so the project must not be described as hardware-complete.

Minute 0–5: choose the cryptographic contract

Choose the profile before interpreting a key, signature, or hash. The two profiles are separate Rust types and separate compatibility promises.

Profile	Compatibility promise	Active hardware boundary	Never infer
`LEGACY_KECCAK` / `LegacyKeccak`	Byte-compatible with pinned HashSigsRS commit `2d315dd4168804b7cbc51c51a1bf7ca27bf74140`; legacy Keccak `0x01` domain byte	Keccak compatibility engine; no active hardware verifier	SHA3-256 behavior or compatibility with the SHA-256 profile
`HASHSIGS_SHA256_GENERIC_V1` / `HashSigsSha256GenericV1`	Deliberately incompatible SHA-256 profile using the same WOTS parameters	Active 3×4 signer and fail-closed 3×4 verifier	Pinned HashSigsRS key or signature compatibility

There is no automatic profile fallback. A surrounding protocol must authenticate the profile before it parses untagged bytes. See Two incompatible profiles for the full boundary table and vector provenance.

Minute 5–10: find the owning source

Start at the narrowest owner. Do not edit generated Verilog; change its Rust/RHDL producer and regenerate only through the documented gate.

Intended change	Owning source	First focused gate
Profile-safe wire types	`crates/hashsigs-types/src/lib.rs`	`cargo test -p hashsigs-types --locked -j1`
Legacy software compatibility	`crates/hashsigs-reference/src/lib.rs`	`cargo test -p hashsigs-reference --test upstream_compatibility --locked -j1`
Legacy Keccak datapath	`crates/keccak-rhdl/src/`	`cargo test -p keccak-rhdl --test compatibility --locked -j1`
SHA-256 primitive, lane, or farm	`crates/sha256-rhdl/src/`	`cargo test -p sha256-rhdl --locked -j1`
WOTS digits, tags, or block construction	`crates/wots-rhdl/src/blocks.rs`	`cargo test -p wots-rhdl --test tag_and_blocks --locked -j1`
Signer task graph	`crates/wots-rhdl/src/engine.rs`	`cargo test -p wots-rhdl --test engine --locked -j1`
Four-context signer cluster	`crates/wots-rhdl/src/cluster.rs`	`cargo test -p wots-rhdl --test cluster --locked -j1`
Three-cluster signer top	`crates/wots-rhdl/src/top.rs`	`cargo test -p wots-rhdl --test top --locked -j1`
SHA-256 verifier context or top	`crates/wots-rhdl/src/verify/`	`cargo test -p wots-rhdl --test verify_sha --locked -j1` or `--test verify_top`
RTL registry and export gates	`crates/rhdl-gen/src/`	`cargo test -p rhdl-gen --test cli --locked -j1`

Use the complete Source map when a change crosses one of these boundaries. U280 scripts and constraints live under fpga/u280/, but they are evidence infrastructure rather than a suitable first cryptographic change.

Minute 10–20: make one test-backed change

Read the owning module’s public contract and its focused test.
Add or update an expectation derived from a pinned vector or independent software oracle—not a second call into the datapath under test.
Keep the cryptographic datapath in Rust/RHDL. Shell adapters, constraints, Tcl, and testbench wrappers are separate integration boundaries.
Keep profile types explicit. A convenience conversion must not make legacy and SHA-256 keys or signatures interchangeable.
Keep the patch inside one source owner unless the test demonstrates why a boundary must move.

Minute 20–30: run the narrow gate and report honestly

Run the focused command from the ownership table, then expand only as the change requires. The broader order is leaf crate, owning integration test, workspace tests, generated-RTL equivalence, synthesis, route, then card execution. Some full-lane and descriptor tests are intentionally ignored by default; a skipped expensive test is not a pass.

In the handoff, record:

the profile and source owner changed;
the exact commands actually run and their outcomes;
the highest evidence tier reached;
every relevant test or hardware gate not run; and
whether generated artifacts were refreshed.

The Evidence ladder defines what each result can establish. Do not promote a source-simulation result into an RTL claim or a normalized RTL rate into an FPGA claim.

Hardware target box

These are gates for a future exact U280 artifact chain, not properties already proved by the current evidence set.

Gate	Exact project boundary
250 MHz basis	4.000 ns; 500,000 fused results/s permits at most 500 cycles/result
Current generated-RTL interval	23,121 cycles / 48 results = 481.6875 cycles/result; 519,008.693 results/s when normalized at 250 MHz only
Clock goal	3.333 ns / 300 MHz in a separate run; the same rate target permits 600 cycles/result only after that clock is justified
LUT limit	At most 200,000
Register limit	At most 300,000
DSP limit	At most 4,000; this is the absolute project ceiling

The 250 MHz run is the normalization basis and first hardware gate. The 300 MHz goal does not replace it and cannot be claimed from synthesis estimates alone. Every future remote U280 Vivado, Vitis, XRT, or card flow must first have explicit ownership in both coordination ledgers and enter through the checked-in U280 lock wrapper. It ignores caller-controlled HOME, uses the effective user’s canonical passwd-home lock, and fails immediately rather than waiting. The ledger acknowledgment and same-UID advisory lock prevent accidental competing work; they are not cryptographic ledger proof or a boundary against a malicious same-UID process. If the lock cannot be acquired immediately, stop; do not wait, probe another owner’s work, or start a competing flow. See Read throughput correctly and the U280 evidence workflow before staging any hardware run.