update
This commit is contained in:
1
.gitattributes
vendored
1
.gitattributes
vendored
@@ -1 +0,0 @@
|
||||
* text=auto eol=lf
|
||||
9
.vscode/extensions.json
vendored
9
.vscode/extensions.json
vendored
@@ -1,9 +0,0 @@
|
||||
{
|
||||
"recommendations": [
|
||||
"Vue.volar",
|
||||
"vitest.explorer",
|
||||
"dbaeumer.vscode-eslint",
|
||||
"EditorConfig.EditorConfig",
|
||||
"esbenp.prettier-vscode"
|
||||
]
|
||||
}
|
||||
19
AGENTS.md
19
AGENTS.md
@@ -1,19 +0,0 @@
|
||||
# Repository Guidelines
|
||||
|
||||
## Project Structure & Module Organization
|
||||
The Vue 3 frontend lives under `src/`. `main.ts` wires the router and Pinia, while `App.vue` hosts global layout. Page-level views sit in `src/views/` (e.g. `AnalyticsView.vue`), with shared widgets under `src/components/`. Pinia logic is grouped in `src/stores/` (one file per domain such as `energy.ts` or `room.ts`), and API/WebSocket helpers in `src/services/`. Reusable hooks belong in `src/composables/`. Static files and icons stay in `public/` or `src/assets/`. Keep demo tooling like `test-websocket.html` at the repo root; production builds land in `dist/`.
|
||||
|
||||
## Build, Test, and Development Commands
|
||||
Run `npm install` once after cloning. `npm run dev` starts Vite locally; use `npm run dev-server` when you need LAN access. `npm run build` performs a type-safe production build (calls `npm run type-check` plus `vite build`). `npm run preview` serves the built bundle. Execute `npm run test:unit` for Vitest suites, `npm run lint` for ESLint (auto-fix enabled), and `npm run format` to apply Prettier to `src/`.
|
||||
|
||||
## Coding Style & Naming Conventions
|
||||
Follow the ESLint + Prettier flat config: 2-space indentation, single quotes in TS, and script setup in Vue SFCs when practical. Name Vue files in PascalCase (`EnergyOverviewCard.vue`), stores in camelCase (`energy.ts` exporting `useEnergyStore`), and composables with the `use` prefix. Keep Tailwind utility classes readable by grouping per concern. Avoid unchecked `console.log`; prefer the logging helpers already present in stores.
|
||||
|
||||
## Testing Guidelines
|
||||
Vitest with the `jsdom` environment powers unit tests; place suites alongside features in `src/**/__tests__/` using `*.spec.ts`. Mock API and WebSocket calls by leveraging Pinia store injection or `vi.mock('../services/api')`. Every new store action or view-level computed branch should gain coverage. Run `npm run test:unit -- --run --coverage` before opening a PR if you add complex domain logic.
|
||||
|
||||
## Commit & Pull Request Guidelines
|
||||
Commits use short, imperative summaries without prefixes (see `git log`). Keep subject lines under ~70 characters and include the affected area, e.g., `Refine room status badges`. Squash fixups locally rather than pushing noisy history. PRs should link to Jira/GitHub issues when relevant, include screenshots or GIFs for UI changes, list test commands run, and call out backend dependencies (e.g., new API fields).
|
||||
|
||||
## Environment & Configuration
|
||||
Frontend defaults to `http://localhost:8000`; override with `VITE_API_BASE_URL` in a `.env.local`. Document new environment flags in `README.md`. Never commit real credentials—use the provided TypeScript definitions in `env.d.ts` to keep variable access typed.
|
||||
15
Tasks.md
Normal file
15
Tasks.md
Normal file
@@ -0,0 +1,15 @@
|
||||
|
||||
Medium
|
||||
- Replace `any` usage with specific types to satisfy lint checks in src/main.ts:27, src/stores/room.ts:315, src/stores/room.ts:319, src/views/ModelsView.vue:707, src/views/ModelsView.vue:714
|
||||
Low
|
||||
- Remove or use unused Vue emits and lifecycle hooks flagged by lint in src/components/cards/DetailedSensorCard.vue:177, src/components/cards/SimpleSensorCard.vue:83, src/components/modals/RoomManagementModal.vue:175, src/components/modals/RoomManagementModal.vue:181, src/main.ts:21, src/stores/energy.ts:19, src/views/AnalyticsView.vue:324, src/views/SensorManagementView.vue:260
|
||||
|
||||
Possible Features
|
||||
- Add real-time toast notifications for critical events surfaced by analyticsApi.getEvents
|
||||
- Provide comparative trend dashboards with configurable periods and benchmarks
|
||||
- Introduce role-based access control screens for managing API tokens and room permissions
|
||||
|
||||
Database Enhancements
|
||||
- Persist user dashboard preferences (selected rooms, time ranges, chart settings) for personalized views
|
||||
- Track sensor metadata history (calibration, firmware updates, maintenance logs) to power diagnostics
|
||||
- Store aggregated room efficiency scores and anomaly flags to speed up analytics queries
|
||||
Reference in New Issue
Block a user