|
| 1 | +# Shieldmaiden |
| 2 | + |
| 3 | +D&D combat tracker web app built with Vue 2 + Quasar 1 + Firebase. |
| 4 | + |
| 5 | +## Tech Stack |
| 6 | + |
| 7 | +- **Framework**: Vue 2.7 + Quasar 1 (SSR mode) |
| 8 | +- **Build**: Webpack 4 via `@quasar/app ~2.4.3` |
| 9 | +- **Backend**: Firebase v8 (namespaced API — do NOT migrate to modular v10+ API) |
| 10 | +- **State**: Vuex with modules in `src/store/modules/` |
| 11 | +- **Node**: >= 24, npm >= 10.2.4 |
| 12 | + |
| 13 | +## Dev Commands |
| 14 | + |
| 15 | +```bash |
| 16 | +npm run ssr # Start dev server (SSR mode) |
| 17 | +npm run build # quasar build -m ssr |
| 18 | +npm run lint # ESLint |
| 19 | +``` |
| 20 | + |
| 21 | +## Key Constraints |
| 22 | + |
| 23 | +- **Firebase v8 namespaced API** is used across 63+ files — do not switch to modular API |
| 24 | +- Vue 2 / Quasar 1 ecosystem locks transitive deps (postcss 7, webpack 4, etc.) |
| 25 | +- Many audit vulnerabilities are unfixable without framework migration — do not attempt to fix them |
| 26 | +- `package.json` uses `overrides` to force-update transitive deps |
| 27 | + |
| 28 | +## Project Structure |
| 29 | + |
| 30 | +``` |
| 31 | +src/ |
| 32 | + boot/ # Quasar boot files (plugins, firebase-auth, etc.) |
| 33 | + components/ # Vue components |
| 34 | + layouts/ # App layouts |
| 35 | + views/ # Page-level views |
| 36 | + store/ # Vuex store |
| 37 | + modules/ |
| 38 | + userContent/ # User data (campaigns, encounters, players, etc.) |
| 39 | + content/ # API content (spells, monsters, items, conditions) |
| 40 | + services/ # Firebase service layer (one file per resource) |
| 41 | + utils/ |
| 42 | + generalFunctions.js # Shared utility functions |
| 43 | + generalConstants.js # Shared constants |
| 44 | +``` |
| 45 | + |
| 46 | +## Patterns |
| 47 | + |
| 48 | +- Services in `src/services/` handle Firebase reads/writes |
| 49 | +- Vuex modules dispatch to services and cache results in state |
| 50 | +- Extension communication uses `window.postMessage` bridge (not `chrome.runtime` directly) |
| 51 | +- Utility functions go in `src/utils/generalFunctions.js` |
| 52 | + |
| 53 | +## Git Workflow |
| 54 | + |
| 55 | +We use **Git Flow**. Follow these rules strictly: |
| 56 | + |
| 57 | +### Branch Structure |
| 58 | +- `main` — production releases only |
| 59 | +- `develop` — integration branch |
| 60 | +- `feature/*` — new features, branched from `develop` |
| 61 | +- `release/*` — release preparation, branched from `develop` |
| 62 | +- `hotfix/*` — urgent production fixes, branched from `main` |
| 63 | + |
| 64 | +### Merging Rules |
| 65 | +- **Features**: open a PR from `feature/*` → `develop` |
| 66 | +- **Releases**: merge `release/*` → `main` AND `develop` (no PR required) |
| 67 | +- **Hotfixes**: merge `hotfix/*` → `main` AND `develop` (no PR required) |
| 68 | +- Never merge features directly to `main` |
| 69 | + |
| 70 | +### Tags |
| 71 | +- Tag every merge to `main` with the version number (e.g. `2.39.2`) |
| 72 | + |
| 73 | +### Commits & PRs |
| 74 | +- Do NOT add Claude as a co-author in commits or PR descriptions |
0 commit comments