mirror of
https://github.com/rzuasti/oott.git
synced 2026-07-08 19:21:54 +02:00
rzuastiandClaude Opus 4.8
587e097291
Backend:
- Add db::devices::delete to erase a device and its events atomically
- Expose DELETE /api/devices/{mac}/permanently, wired to OpenAPI
- Cover the new db method and endpoint with tests
Frontend:
- Delete action for not-registered devices (detail screen + list row)
and an opt-in "permanently delete" checkbox in the Forget dialog
- Navigate to the devices list after deleting from the detail screen
- Refine button emphasis to M3: single filled primary, error-colored
text buttons for destructive actions, Test demoted to filled-tonal
- Flash the backend-config Test button red on a failed connection test
- Render snackbars through a top-level ScaffoldMessenger host so they
show above dialogs; keep the built-in SnackBar (with an Overlay host)
Docs:
- CLAUDE.md: rustfmt edition 2024, don't revert formatter-only changes,
prefer built-in Flutter components, follow existing patterns + M3
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
67 lines
5.1 KiB
Markdown
67 lines
5.1 KiB
Markdown
# Project OOTT
|
|
|
|
OOTT is an easy to setup network monitoring and alert system aimed at notifying when new or unknown devices join a local area network.
|
|
|
|
It has two major components:
|
|
- A backend service that runs the monitoring and other processes and provides a REST API. This is built with [Rust](https://rust-lang.org/).
|
|
- A front-end that enables the user to configure the system and access the data it stores. This is built with [Flutter](https://flutter.dev/) - a front-end framework based on the [Dart](https://dart.dev/) language.
|
|
|
|
|
|
## Code style
|
|
|
|
For Rust code:
|
|
- Use the standard [Rust style guide](https://doc.rust-lang.org/style-guide/)
|
|
- Use `rustfmt` to format the code. This crate is edition 2024, so always pass `--edition 2024` when invoking `rustfmt` directly (e.g. `rustfmt --edition 2024 <file>`) to avoid spurious import-ordering changes
|
|
|
|
For Flutter/Dart code:
|
|
- Use the standard [Dart style guide](https://dart.dev/effective-dart/style)
|
|
- Use `dart format --output show` to format the code
|
|
|
|
## Project commands
|
|
|
|
- `cd backend && ./build.sh` from the `backend/` folder - Build the backend
|
|
- `cd backend && ./run.sh` from the `backend/` folder - Run the backend
|
|
- `cd frontend && ./run_web.sh` from the `frontend/` folder - Run the front-end for the web
|
|
- `cd frontend && ./run_android_emulator.sh` from the `frontend/` folder - Boot the Android emulator (if needed) and run the front-end on it
|
|
- `cd backend && ./run_tests.sh` - Run the backend tests
|
|
- `cd frontend && ./run_tests.sh` - Run the front-end tests
|
|
- `cd backend && ./lint.sh` - Run the clippy linter for Rust code
|
|
- `dart analyze` - Run the Dart linter
|
|
- `cd backend/data && ./update_mac_vendors --llm` - Update the MAC vendors list from the web and re-calculate the vedors -> device type list
|
|
|
|
## Architecture
|
|
|
|
### General
|
|
- All backend source code is under the `backend/` folder
|
|
- All front-end source code is under the `frontend/` folder
|
|
- All interactions between the front-end and the backend are via the backend REST API
|
|
|
|
### Backend
|
|
- System state and events are stored in a SQLite database (`oott.db` by default) which is accessed and managed exclusively by the backend via a data access layer (`db.rs` and files under the `backend/src/db/` folder)
|
|
- Database structure is handled through incremental migrations (stored under the `backend/database_migrations` folder). Each set of structural changes should be a new database migration file.
|
|
- The backend's entry point is `src/main.rs` which starts two threads using the [Tokyo](https://tokio.rs/) framework: one for the network scanning process and another one for the web server that exposes the API and hosts the Flutter app (front-end) assets when deployed in a live environment (ie not development)
|
|
|
|
### Front-end
|
|
- The front-end's entry point is `lib/main.dart`
|
|
- It uses the [Material 3](https://m3.material.io/develop/flutter) framework for Flutter
|
|
- The application needs to be responsive and adapt to a web experience in the desktop, tablets and phones
|
|
- The application is also available in iOS and Android as a native experience (via de App Store and Play store)
|
|
- Backend API access is implemented in the `utils/oott_api.dart` component
|
|
|
|
## Important notes
|
|
- NEVER add or commit .env files or files with secrets (passwords, API keys or similar information)
|
|
- Code must be as simple as possible, human readable and modularized
|
|
- ALWAYS write and/or update unit tests for new or modified backend components
|
|
- ALWAYS write and/or update unit, API and widget tests for new or modified frontend components
|
|
- ALWAYS run all tests after making a new change and do not continue until all tests pass
|
|
- When adding a new API endpoint, ALWAYS wire it to the OpenAPI generation
|
|
- When adding a significant chunk of new code (either Rust or Dart), run the corresponding linter
|
|
- In the frontend, use the UISnackbars component to display messages to the user that do not require action on their part.
|
|
- In the frontend, always use colors from the selected theme. Never hard code colors any other way. If a color is needed and it's not covered semantically by the theme, suggest an addition to the theme extension implemented in the project.
|
|
- In the frontend, prefer built-in Flutter/Material components over custom-built ones. Only build a custom component when it is genuinely a better fit for the requirements — and in that case, present the pros/cons of custom vs. built-in to the human and get confirmation before proceeding.
|
|
- In the frontend, when building a new screen, widget, or dialog, make it consistent: follow the patterns already used by similar widgets in this project, and follow Material 3 guidance and best practices (e.g. button emphasis hierarchy, action placement, theming).
|
|
- In the backend Rust code, avoid import aliases ("use ... as ...") unless necessary
|
|
- Do not create branches by default, commit directly to main (this is a single developer project)
|
|
- When files are changed by the formatter do not revert them to keep the commit pure, just add them to the current commit.
|
|
- Never revert a file solely because the formatter reformatted it (even files you did not otherwise touch) — keep the formatter's changes. Only revert if the formatting change actually introduces a bug or other issue.
|