# Repository Reality

- This repository now contains the WeChat Mini Program, the uniapp/Vue 3 admin console, a Tencent Cloud SCF HTTP backend, deployment docs, and design/planning references.
- Current backend implementation lives in `server/` and targets Tencent Cloud HTTP Function + TencentDB MySQL + COS.
- The previous WeChat Cloud Development function directories have been removed from the active architecture.
- Do not treat older planning/review documents as current implementation truth unless they explicitly say they are current.

# Verified System Scope

- Mini Program: native WeChat `WXML` / `WXSS` / `JS` under `miniprogram/`.
- Device communication: BLE 5.0 GATT via `miniprogram/services/ble.js`.
- Mini Program cloud API: HTTPS requests through `miniprogram/utils/request.js` to the configured API base in `miniprogram/config/env.js`.
- Backend: Tencent Cloud HTTP Function, package root uses executable `server/scf_bootstrap` to start `node scripts/local-server.js` on port `9000`.
- Database: TencentDB MySQL schema in `server/sql/schema.sql`.
- Storage: Tencent COS for firmware/admin H5 artifacts.
- Admin console: uniapp + Vue 3 under `admin-console/`, H5 build can be uploaded to COS.

# Current Deployment Facts

- Test API base is configured as `https://1426323813-ilxkhlxf4p.ap-guangzhou.tencentscf.com` in both Mini Program and admin console test configs.
- SCF function name used during deployment: `jw-beauty-api`.
- SCF is an HTTP function, not an event function. Use `scf_bootstrap`, not `index.main_handler`, for this function type.
- SCF must be attached to the TencentDB VPC/subnet when using the database private endpoint.
- Real secrets must remain in local `.env` or SCF environment variables. Never commit `server/.env`.

# Integration Facts Worth Preserving

- BLE frame format implemented in code: header `0xAA 0x55`, length, type, payload, XOR checksum over header/length/type/payload.
- BLE services in the document/code: `FFE0` device info, `FFE1` data communication, `FFE2` OTA.
- Device binding is two-phase: backend bind request creates pending token, Mini Program sends BLE bind, device returns bind success, Mini Program confirms backend binding.
- Device commands are queued in MySQL `device_commands`; Mini Program pulls pending commands and executes BLE commands.
- Current main cloud path is HTTPS API through the Mini Program, not MQTT/IoT direct device-cloud communication.

# User Profile / Login Reality

- `wx.login()` only provides a code for backend `openid/session_key` exchange.
- The current login page uses `wx.getUserProfile()` to request WeChat's official profile authorization popup and then stores returned nickname/avatar if WeChat provides them.
- WeChat may still return masked values such as `微信用户` and default avatar. This is platform policy, not a backend bug.
- If reliable nickname/avatar capture becomes required, use the newer `chooseAvatar` + `input type="nickname"` flow, but that is not the current requested UX.
- Phone number authorization is scaffolded through `open-type="getPhoneNumber"` and backend `/api/v1/user/phone`, currently hidden in the login UI.

# Build And Deploy Commands

Backend local:

```bash
cd server
npm install
npm run db:init
npm start
```

Admin H5:

```bash
cd admin-console
npm install
npm run build:h5
npm run deploy:cos
```

Mini Program BLE frame test:

```bash
cd miniprogram
node scripts/test-ble-frame.js
```

# Working Rules For Future Sessions

- Use current executable config and code as the source of truth before relying on older planning docs.
- Do not reintroduce `wx.cloud`, WeChat Cloud Development functions, or MQTT unless the architecture is explicitly changed again.
- Do not commit `.env`, cloud credentials, database passwords, signed COS URLs, or generated build artifacts.
- Before committing, check `git status --short` and scan staged files for secret-looking values.