| | |
|---|
| | | # Repository Guidelines |
|---|
| | | |
|---|
| | | ## Project Structure & Module Organization |
|---|
| | | - `pages/` hosts the multi-tab MES screens; treat each subdirectory as a self-contained feature view. |
|---|
| | | - `components/` collects reusable modules such as `WorkOrder.vue`, `PrintInit.vue`, and Bluetooth helpers—prefer extending these before creating new ones. |
|---|
| | | - `common/` exposes global mixins and permission utilities loaded in `main.js`; align new cross-cutting logic here. |
|---|
| | | - `utils/` provides device integrations (Bluetooth, printing, scanning). Reuse these helpers instead of duplicating platform calls. |
|---|
| | | - `store/index.js` defines runtime server endpoints; keep environment toggles (`serverInfo`) in sync with deployment plans. |
|---|
| | | - `static/` and `unpackage/` store shared assets and build outputs—never edit generated files in `unpackage/`. |
|---|
| | | `pages/` hosts the multi-tab MES screens—treat each subdirectory as an isolated feature. Shared UI and device helpers live in `components/`, `common/`, and `utils/`; extend these before adding new modules so tablet flows stay consistent. Global state and server toggles sit in `store/index.js`; adjust `serverURL`, `serverAPI`, `pdaMac`, and `machineNo` here before packaging. Keep generated build assets in `unpackage/` untouched, and store documentation under `docs/`. |
|---|
| | | |
|---|
| | | ## Build, Test, and Development Commands |
|---|
| | | - Day-to-day development: open the project in HBuilderX → `Run > Run to Mobile Device` for live debugging on an Android tablet. |
|---|
| | | - Packaging: HBuilderX → `Build > Native App-Cloud Packaging` (select `App-Plus`). |
|---|
| | | - CLI fallback: `npx @dcloudio/uni-cli-service dev -p app-plus` for local preview, `npx @dcloudio/uni-cli-service build -p app-plus` for production bundles. |
|---|
| | | - Update API targets by editing `store/index.js` (`serverURL`, `serverAPI`) before each build. |
|---|
| | | Primary workflow uses HBuilderX: `Run > Run to Mobile Device` for live debugging, `Build > Native App-Cloud Packaging` targeting `App-Plus`. CLI fallback commands: `npx @dcloudio/uni-cli-service dev -p app-plus` for local preview and `npx @dcloudio/uni-cli-service build -p app-plus` for production bundles. Run these from the repo root with UTF-8 terminals to avoid encoding drift. |
|---|
| | | |
|---|
| | | ## Coding Style & Naming Conventions |
|---|
| | | - Vue 2 single-file components with `<template>`, `<script>`, `<style lang="scss">`; keep component names in PascalCase. |
|---|
| | | - Use tabs (width 4) to mirror existing templates and scripts; SCSS files prefer two-space indentation. |
|---|
| | | - Follow camelCase for data keys and methods, UPPER_SNAKE_CASE only for immutable constants. |
|---|
| | | - Keep inline comments concise and in Chinese when matching existing context. |
|---|
| | | Components follow Vue 2 SFC format with tab (width 4) indentation in `<template>`/`<script>` and two spaces in SCSS. Name components in PascalCase, data/methods in camelCase, and reserve UPPER_SNAKE_CASE for constants. All files must be UTF-8 encoded; inline comments should stay concise and in Chinese to match existing context. Prefer reusing mixins/utilities from `common/` and `utils/` instead of reimplementing device logic. |
|---|
| | | |
|---|
| | | ## Testing Guidelines |
|---|
| | | - No automated test suite is tracked; document manual verification covering work-order flow, barcode printing, and Bluetooth pairing. |
|---|
| | | - Validate builds on actual industrial tablets (1280×800 or 1920×1080) via HBuilderX device preview. |
|---|
| | | - Capture console output (`HBuilderX > Debug > View Log`) when reporting regressions. |
|---|
| | | No automated suite exists; document manual verification covering work-order flow, barcode printing, Bluetooth pairing, and tablet layouts (1280×800, 1920×1080). Capture logs via `HBuilderX > Debug > View Log` when issues appear, and note the API environment configured in `store/index.js`. |
|---|
| | | |
|---|
| | | ## Commit & Pull Request Guidelines |
|---|
| | | - Git history shows terse messages (`1111`, `优化`); prefer descriptive imperative titles such as `feat: improve WorkOrder polling`. |
|---|
| | | - Group related changes per commit and reference affected modules (`components/WorkOrder.vue`). |
|---|
| | | - Pull requests should list environment used, manual test steps, and screenshots for UI adjustments; link tracker items when available. |
|---|
| | | Write descriptive imperative commit subjects (e.g., `feat: improve WorkOrder polling`) instead of legacy numeric messages. Each PR should state the device/environment used, list manual test steps, and attach screenshots for UI tweaks. Reference affected modules (`components/WorkOrder.vue`) and link tracker items when possible; keep unrelated changes out of scope. |
|---|
| | | |
|---|
| | | ## Configuration & Security Notes |
|---|
| | | - Never hard-code credentials; rely on `uni.getStorageSync` and backend-issued tokens. |
|---|
| | | - Reset device bindings (`pdaMac`, `machineNo`) in `store/index.js` before shipping shared builds. |
|---|
| | | - Clean `unpackage/` artifacts prior to committing to avoid bloating the repository. |
|---|
| | | ## Security & Configuration Tips |
|---|
| | | Never hard-code credentials; fetch tokens via `uni.getStorageSync`. Reset device bindings and API targets before distributing shared builds, and clean `unpackage/` artifacts prior to committing to keep the repo lean. |
|---|
