tari-ootle: Instructions file for Codex

Tari Ootle - Agent Cheatsheet

Before Every Commit

CI rejects unformatted code. Rust formatting needs the pinned nightly: stable rustfmt skips the nightly-only options in rustfmt.toml with a warning, so cargo fmt on stable passes locally and fails CI.

rustup toolchain install nightly-2025-12-05 --component rustfmt
cargo +nightly-2025-12-05 fmt --all
cargo +nightly-2025-12-05 fmt --all -- --check   # must pass; CI runs this

If the commit touches .ts/.tsx files, also run pnpm run fmt (CI runs pnpm run fmt:check).

Project Structure

• The project is called "Ootle" or "Tari Ootle" (not "DAN" or "Tari DAN")
• Crates are in crates/, applications in applications/, clients in clients/
• Wallet daemon package: tari_ootle_walletd (in applications/tari_walletd/)
• Wallet CLI: tari_wallet_cli (in applications/tari_wallet_cli/)
• Transaction manifest parser: tari_transaction_manifest (in crates/transaction_manifest/)
• Transaction types/instructions: tari_ootle_transaction (in crates/transaction/)
• Template lib types (OwnerRule, RistrettoPublicKeyBytes, etc.): tari_template_lib_types (in crates/template_lib_types/)
• CBOR serialization: tari_bor (in crates/tari_bor/) - wraps ciborium, re-exports serde

Code Comments

IMPORTANT: Comments must help a future reader understand code that isn't self-explanatory — non-obvious invariants, the reason for a non-obvious approach, tricky edge cases. They must NOT narrate changes.

• When fixing a bug, lint, or doing a refactor, do not add a comment explaining what was wrong or why you changed it. The corrected code no longer has the issue, so such a comment describes a problem that isn't in the code — it serves no future reader.
• Rationale for a fix belongs in the commit message and PR description, not in the source.
• Never answer a reviewer in a code comment. When addressing review feedback, the justification goes in the reply on the review thread; the source gets only what a reader who never saw the review needs. A comment that argues for the new code over what the reviewer objected to is narrating a change — the thing it contrasts against isn't in the file.
• Write present-tense statements of intent/invariant ("X must be Y because Z"), never history ("changed this from A to B", "without this guard X would happen", "previously this did A").