Aura/docs/project-layout.md

# How aura is used — engine, projects, and a day in the life

This document describes the *outside* of aura: how you sit in front of it and
what a research session looks like. The *inside* (the engine's contracts) is the
design ledger (`docs/design/INDEX.md`).

## Engine vs. project (the game-engine split)

aura is a **game engine for traders**, and like any game engine it is separate
from the things built with it:

- **This repo (`aura`)** is the **engine**: `aura-core` (the shared contract),
  `aura-std` (universal standard nodes), `aura-engine` (the deterministic sim
  runtime), `aura-cli` (the `aura` binary), and later the egui playground. It
  ships at most `examples/` fixture nodes for its own tests — never your real
  signals.
- **A research project** is its **own external repo** (e.g. `~/dev/ger40-lab/`),
  with its own git history, its own Gitea repo (its own forward-queue), and a
  cargo dependency on aura. **It is itself a Rust crate** (a `cdylib` library of
  node / strategy / experiment blueprints); the `aura` host loads and runs it
  during research (hot-reload), and freezes a chosen strategy + broker into a
  standalone binary for deploy. This is where you and Claude author signals *and
  experiments* — all in Rust — and where the runs live. (Contracts **C16**, **C20**.)

The `aura` CLI is a tool you run *inside* a project directory — it finds the
project root by walking up to an `Aura.toml`, the way `cargo` finds `Cargo.toml`.
A project is always a Rust program built on the engine.

## A project repo

```
ger40-lab/                 # your research project — a separate Rust crate (cdylib)
├── Aura.toml              # STATIC context only: data paths, instrument/pip
│                          # metadata, default broker & window, runs dir (no logic)
├── Cargo.toml             # cdylib; depends on aura-core/aura-std (+ shared node crates)
├── CLAUDE.md              # the project's own skills wiring (authoring discipline)
├── .claude/dev-cycle-profile.yml
├── nodes/                 # project-local node & strategy blueprints (Rust)
│   └── third-candle-long/
├── experiments/           # experiment/harness definitions (Rust): matrices, sweeps
├── runs/                  # the run registry: manifest + metrics per run
└── (frozen bots, …)
```

## Where reusable nodes live (three tiers)

Everything that plugs into the engine is fractally a `Node`. Reuse is plain
cargo, layered by maturity (contract C16):

1. **`aura-std`** — universal blocks shipped with the engine (SMA/ATR/RSI,
   resamplers, the `SessionNode`, standard combinators, broker profiles).
2. **Shared node crates** — cross-project-reusable blocks in their own repos
   (e.g. `Brummel/aura-nodes-fx`), pulled in as cargo git dependencies.
3. **Project-local `nodes/`** — experimental, project-specific blocks.

Promotion is the ordinary Rust gradient: a node proves itself project-local →
gets extracted into a shared crate → if it turns universal, into `aura-std`.
Shared nodes are `rlib` dependencies; the hot-reload unit stays the project-side
`cdylib` that composes them, so editing a shared node still rebuilds and reloads
the dependent.

## Authoring happens in Claude Code (contract C17)

aura has no built-in coding-LLM. You author by talking to Claude Code, which
writes the Rust — nodes, strategies, *and experiments* — builds it, runs it, and
reports back. Declarative config (`Aura.toml`) holds only static context, never
logic. IONOS LLMs appear only as a *runtime data source* (e.g. a news-agent node
emitting a bias), recorded before it enters a backtest, and only with your
per-session consent.

## A day in the life

1. **You** (in Claude Code, inside `ger40-lab/`): "I suspect the 3rd 15m candle
   after GER40 open is long-biased when the first two close bullish — build it as
   a signal."
2. **Claude** (via the skills pipeline) writes `nodes/third-candle-long/`,
   implements `schema` + `eval` against `aura-core`.
3. **Backtest:** `aura backtest nodes/third-candle-long --symbol GER40
   --from 2020 --to 2024` → the strategy produces a broker-independent
   **position table** (open/close events); the default **sim-optimal broker**
   projects it into a synthetic **pip**-equity, yielding a metrics table
   (trades, hit-rate, pip-P&L, max-DD, Sharpe) + a run record (manifest +
   metrics) under `runs/`. Brokers are consumer **nodes**, and several can be
   attached at once: add `--broker pepperstone` to get a realistic currency
   curve *alongside* the default sim-optimal pip curve — two comparable equity
   curves from the same position table. (Contract C10.)
4. **Sweep / Monte-Carlo / matrix — a Rust experiment.** Anything beyond a
   single backtest is an *experiment* in `experiments/` (Rust, builder API): a
   parameter sweep, Monte-Carlo over seeds, or a structural matrix like "these 10
   strategies × these 3 instruments × {sim-optimal, pepperstone}". The matrix is
   plain Rust loops, not a config schema (C20). `aura run experiments/compare`
   bootstraps the matrix, fans the disjoint sims over all cores (C1), and writes
   the comparable runs to `runs/`.
5. **Compose:** "combine it with `momentum-filter` as a weighted sum" → Claude
   writes a composite node (fractal, C9).
6. **Walk-forward:** another experiment kind (rolling in-sample optimize +
   out-of-sample test) → an out-of-sample verdict.
7. **Freeze:** `aura freeze nodes/strategy-y --broker pepperstone
   --out bots/strategy-y` → a standalone, statically-linked bot (C13).
8. **(Later) Look:** `aura play` opens the egui playground — equity curve, trade
   overlays on the chart, sweep heatmaps. For *looking*, not authoring (C14).

CLI command names and `Aura.toml` are illustrative; the concrete surface is
designed with the relevant milestone (see the open threads in the design ledger).
The forward-queue — what to try next — lives in the project's Gitea tracker, not
in code (contract C18).