fetchira CLAUDE.md

Commit Messages

Use Conventional Commits with short subject line only. No body, no footers, no explanations. Good examples:

• fix(wallet): refresh JWT after setup completes
• feat(wallet): cut over to type-3 deposit wallet contract
• refactor(commands): simplify error mapping for deposits
• chore(tauri): update capability for filesystem access

Never write long commit bodies or "This change does X because...".

Core Philosophy — Write Code That Looks Human

• Match existing code 1:1 — Before touching any file, read the surrounding functions and module. Copy naming, style, error patterns, and level of abstraction exactly. Do not "improve" the local style.
• Minimal viable solution — Solve the task with the smallest amount of code possible. No extra abstractions, traits, newtypes, builder patterns, or "future-proofing" unless there is a clear, immediate reduction in duplication or readability win in this exact context.
• Avoid churny refactors — Never introduce a one-use temporary variable just to name it before passing it on. Keep the expression inline unless the name carries real domain meaning or eliminates real duplication.
• Be slightly lazy where it makes sense — If the surrounding code is concise and works, match it. Don't add ceremony that isn't already present.
• Comments:
  • Never comment what the code does (code should be self-documenting).
  • Only comment why — a non-obvious business reason, important trade-off, or invariant the type system doesn't enforce.
  • No emojis. No corporate fluff ("leverage", "utilize", "robustly", "seamlessly", "best practice", etc.).
• After writing code — Re-read the changed functions. Remove any defensive checks, clones, or unwraps that are now guaranteed safe by the caller or surrounding invariants.
• Naming — Use the short, domain-specific names already established in the project (e.g. tx, addr, bal, wallet). Never default to generic names like data, result, item, processed, response, value, obj, entity, etc.