Files
lobbs/.cursor/rules/lobbs-project.mdc
T

36 lines
1.8 KiB
Plaintext

---
description: LoBBS project context. Greenfield on-firmware BBS for Meshtastic + MeshCore, plugin + thin forks
alwaysApply: true
---
# LoBBS
Cross-platform, on-firmware BBS for **Meshtastic** and **MeshCore**. Greenfield: no backward compatibility, no legacy code paths. Delete rather than dual-path, simplify rather than preserve old APIs.
## Architecture
**Plugin owns everything, forks stay upstream.**
1. **Plugin** (this repo, PlatformIO library): core, apps, LoScalar, LoDB, LoFS, protocol, and the platform providers under `platforms/<platform>/`. On MeshCore the plugin also owns the firmware app (`setup()`/`loop()`).
2. **Firmware forks** (`../lobbs-meshtastic-firmware`, `../lobbs-meshcore-firmware`, both on `lobbs`): upstream plus one new `variants/lobbs/` folder that defines the `*_lobbs` envs and pins the plugin in `lib_deps`.
The repos are siblings under `/Volumes/Code/repos/meshenvy/`. No submodules anywhere: PlatformIO clones git deps with `--recursive`, and MeshForge builds a fork repo alone.
Until extraction finishes, LoBBS code still lives in-tree at `../lobbs-meshtastic-firmware/src/modules/LoBBS/`.
## Fork diff policy
- Allowed: one new `variants/lobbs/` folder per fork (ini, `.gitignore` for the local override, README pointer).
- No edits to upstream files. If an extension point is missing, make the smallest possible change, list it in [`README.md`](README.md), and open an upstream PR.
## Pins and releases
Local dev uses a gitignored `symlink://../lobbs` override. Committed fork config only ever pins a plugin commit. Tagging and pin procedure: [`release.mdc`](release.mdc).
## Style
- Bad: keep `#ifdef LEGACY_…` branches "just in case".
Good: delete the old path.
- Bad: grow BBS logic inside a firmware fork.
Good: implement it in the plugin; the fork only selects the env.