# SAL Repository Structure

## Introduction

This document describes the recommended structure for the SAL repository, reflecting the new modular architecture. The goal is to enable robust, maintainable, and WASM-compatible development, while supporting a CLI binary and Rhai scripting.

---

## Recommended Directory Layout

```
sal/
├── arch/
│   ├── Architecture.md
│   └── RepoStructure.md   # ← this file
├── Cargo.toml             # Workspace manifest
├── kvstore/
│   ├── Cargo.toml
│   └── src/
├── vault/
│   ├── Cargo.toml
│   └── src/
├── evm_client/
│   ├── Cargo.toml
│   └── src/
├── cli_app/
│   ├── Cargo.toml
│   └── src/
│       ├── main.rs        # CLI binary entry point
│       └── commands.rs
├── web_app/
│   ├── Cargo.toml
│   └── src/
├── rhai/
│   └── src/
│       └── lib.rs         # Rhai bindings and script API
└── README.md
```

- **Each core component (`kvstore`, `vault`, `evm_client`, `rhai`) is a separate crate at the repo root.**
- **CLI binary** is in `cli_app` and depends on the core crates.
- **WebAssembly target** is in `web_app`.
- **Rhai bindings** live in their own crate (`rhai/`), so both CLI and WASM can depend on them.

---

## Sample Workspace `Cargo.toml`

```toml
[workspace]
members = [
    "kvstore",
    "vault",
    "evm_client",
    "cli_app",
    "web_app",
    "rhai",
]
```

---

## Component Details

### kvstore
- Async trait for key-value storage.
- Native and WASM backends selected by features or `cfg`.

### vault
- Manages encrypted keyspaces and cryptographic operations.
- Uses `kvstore` for persistence.

### evm_client
- Handles EVM RPC, uses `vault` for signing.

### cli_app (Binary)
- Provides CLI interface using `vault`, `evm_client`, and `rhai`.
- Entry point: `cli_app/src/main.rs`.

### web_app (WASM)
- Exposes Rust APIs to JS using `wasm-bindgen`.
- Depends on `vault`, `evm_client`, and `rhai`.

### rhai
- Contains all Rhai script bindings and API glue.
- Shared by both CLI and WASM targets.

---

## Integration & Migration Notes

- Move code from `src/hero_vault` and related modules into the new crates.
- The CLI binary is now in `cli_app/src/main.rs`, depending on all core crates.
- Rhai bindings are centralized in the `rhai/` crate, making them reusable.
- If you need to keep a legacy `src/` for migration, do so temporarily—plan to remove it once the transition is complete.

---

## Rationale

- **Idiomatic Rust**: Each crate at the root, easy to manage, test, and publish.
- **Maintainability**: Clear separation of concerns, easy to extend.
- **WASM & CLI**: Both targets are first-class, sharing as much code as possible.
- **Rhai Integration**: Centralized, reusable scripting interface.

---

## Example: How to Build the CLI Binary

```sh
cd cli_app
cargo build --release
cargo run -- <args>
```

The CLI binary will be compiled as `target/release/cli_app`.

---

## Example: How to Build the WASM Target

```sh
cd web_app
wasm-pack build --target web
```

---

## Summary

This structure enables modular, scalable development for both CLI and browser targets, with robust support for async, WASM, and scripting via Rhai.