pukpuklouis/website-enchun-mgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: regenerate tasks.md to align with corrected route structure

Browse Source
This commit is contained in:
Louis Chen
2025-09-22 16:49:16 +08:00
parent b297dedf2c
commit e7747c1c3e
14 changed files with 143 additions and 209 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
AGENTS.md Normal file
View File

@@ -0,0 +1,19 @@
# Repository Guidelines
## Project Structure & Module Organization
This migration pairs an Astro frontend with a Payload CMS backend. Keep UI work in `frontend/src/components`, route files in `frontend/src/pages`, and shared helpers in `frontend/src/services` or `frontend/src/lib`. Backend collections, auth flows, and integrations belong in `backend/src`, with companion contract tests under `backend/tests`. Product specs, research, and data contracts stay versioned in `specs/001-users-pukpuk-dev/`; mirror that layout when adding new feature folders so planning artifacts remain traceable.
## Build, Test, and Development Commands
Run `pnpm install` once per clone to sync dependencies. Use `pnpm dev` for the Astro dev server at http://localhost:4321 while Payload runs via the same workspace. Before pushing, execute `pnpm test:unit` (Vitest) and `pnpm test:e2e` (Playwright) to guard regressions; record failures with the scenario name. If a production bundle is required, run `pnpm build` and confirm the output passes Payload schema checks.
## Coding Style & Naming Conventions
Author frontend code in TypeScript/TSX with strict typing enabled. Prefer `PascalCase` for Astro components, `camelCase` for variables and functions, and `kebab-case` for file names below `pages/`. Align UI tokens with the palette in `style-css.md` and keep CSS modules scoped. On the backend, name Payload collections with singular `PascalCase` and expose slugs in `kebab-case`. Lint with the workspace Prettier config once it lands, and guard formatted diffs in pull requests.
## Testing Guidelines
Write Vitest suites beside the module under test (`*.spec.ts`) and focus on rendering logic or domain helpers. Playwright feature specs live in `frontend/tests/e2e/` and should mirror user flows from `specs/001-users-pukpuk-dev/spec.md`. Target meaningful coverage for auth, collection validation, and key marketing funnels. When introducing new endpoints, pair them with contract tests derived from `contracts/*.yaml`.
## Commit & Pull Request Guidelines
Follow Conventional Commits as shown in `git log` (e.g., `feat: generate tasks.md for website migration`). Each PR should describe scope, link the corresponding spec or issue, and summarize manual or automated test results. Include screenshots or terminal captures for UX or CLI changes, note schema updates, and flag env variable additions.
## Security & Configuration Tips
Store secrets in `.env` with `PAYLOAD_CMS_URL` and `PAYLOAD_CMS_API_KEY`; never commit the file. Rotate keys whenever staging or production data is refreshed and document rotations in the PR description. Validate that new integrations degrade gracefully when credentials are missing, and prefer typed accessors over reading directly from `process.env` within components.