Skip to content

emulebb-rust Agent Policy

Read the Workspace Policy first. This compact base is mandatory for emulebb-rust product work. Load only the task annexes selected below.

Task Routing

Do not load unrelated Rust annexes merely because the repository is active.

Product Direction

  • CI-gated nightlies from main are the current beta testing lane. Published beta tags remain immutable release evidence; do not rewrite their tags or artifacts, and do not promote stale tags as the current download path.
  • The product is an automation-first integrated suite delivered through hard- gated Client, Indexer, and Arr phases. Production work stays in the Client phase until every active client item, including newly accepted items, closes.
  • The Rust headless daemon and embedded SPA operations console are the active client and UI. A native desktop UI or recreation of the MFC GUI is outside scope.
  • Stock/community eMule owns wire behavior and externally visible protocol state. Maintained eMuleBB MFC owns only explicitly identified non-wire defaults, ceilings, and disk/network I/O outcomes. Current aMule is evidence and optimization inspiration, not a behavior authority. Rust-native async design owns internal implementation when required outcomes remain intact.
  • The bounded-monolith target is one daemon and one SQLite database with explicit client, indexer, and compatibility domain boundaries. The future autonomous indexer and Arr adapters must not introduce parallel client state.
  • API, configuration, and schema compatibility remain explicitly unstable through all three phases and freeze together only after the Arr gate. An incompatible schema requires an entirely fresh profile.
  • policy\rust-client.toml, its omission registry, and its extension registry are the machine-readable authority for platform, behavior authority, protocol, long-path, reviewed-omission, and intentional-extension policy.
  • Retired REST, settings, and metadata fields are hard errors. Do not ignore, alias, remap, or bridge them.

Source And Output Boundaries

  • Every Windows Cargo build, test, or run uses inherited CARGO_TARGET_DIR=%EMULEBB_WORKSPACE_OUTPUT_ROOT%\builds\rust\target. WSL compilation uses its separately derived target-wsl directory. Never create repo-local build or scratch output.
  • The only runnable Windows workspace binary is EMULEBB_WORKSPACE_OUTPUT_ROOT\tools\emulebb-rust\bin\emulebb-rust.exe. Cargo targets are intermediate cache and are not manual, soak, profiling, live-wire, or allow-list executables.
  • Windows long-path support applies only to shared-directory trees, incoming delivery, and category output paths. Config, logs, metadata DB, hash-named piece stores, and other internal paths remain short-path. Exact classes and mechanisms live in policy\rust-client.toml and emulebb_ed2k::long_path module documentation.

Use repos\emulebb-build orchestration for supported build and validation entrypoints.