Imported from wwkevin8/website-homepage (
.tmp-dpl-3ReB2SCYt-output/static/AGENTS.md). Install upstream withnpx skills add wwkevin8/website-homepage --skill static. Copyright stays with the author.
AGENTS.md
Usage Rules For Every New Task
- Before any analysis, implementation, or review, read the current
E:\webside\AGENTS.md. - Before any analysis, implementation, or review, also read
E:\webside\docs\current-status.md; this is mandatory, not optional. - Before making any change, explicitly tell the user which rule files and status files were read for this task.
- Treat this file as the project's cross-session working contract.
- Do not store temporary chat notes, one-off conclusions, or short-term progress logs in this file.
What Belongs In This File
Only keep long-lived project information here:
- Stable project rules and constraints
- Important directory and module responsibilities
- Local run and verification commands
- Acceptance criteria that remain valid across tasks
Status Tracking Rule
- At the end of every task, update
E:\webside\docs\current-status.md. - If
docs/current-status.mddoes not exist, create it first. - Keep
current-status.mdstructured and deduplicated. - Summarize the latest completed work, current status, open issues, and recommended next steps there instead of adding session history to
AGENTS.md. - Rewrite outdated or repeated status content in place instead of stacking more history below it.
Project Overview
- Project name:
webside-transport-dispatch - Type: static multi-page website plus Vercel serverless APIs
- Main domain context: transport dispatch, public transport board, service pages, admin operations
- Deployment model: Vercel
- Node requirement:
24.x
Key Directories And Files
api/: Vercel serverless API handlersapi/_lib/: shared server-side transport logic and email-related helpersapi/transport-requests/: transport request CRUD endpointsapi/transport-groups/: transport group CRUD and member-management endpointsapi/public/[...action].js: public API aggregation entry, should not be casually split apartpublic-api-handlers/: shared public-facing API dispatch logicpublic-api-handlers/transport-board.js: public transport board data shaping and exposure boundaryscripts/: QA and utility scriptssupabase/: Supabase-related assets or SQL/workflow materialimg/: image assetsoutput/: generated outputs and captureswork-log/: historical work artifacts, not the canonical cross-session handofftransport-admin.js: main admin-side transport interaction logictransport-api.js: client-side transport API integration layertransport-shared.js: shared transport constants and helper behaviortransport-board.html: public board pagepickup.html: public-facing transport service pagepickup-form.html/pickup-form.js: pickup form UI and submission logicservice-center.html/service-center.js: service center entry pagesscript.js/styles.css: main site-wide frontend assetsdev-server.js: local helper serververcel.json: deployment and cron configurationpackage.json: source of truth for local scripts and Node version
Critical Modules Requiring Extra Caution
- Public transport display flow:
transport-board.htmltransport-public.jsapi/public/[...action].jspublic-api-handlers/transport-board.js
- Transport admin flow:
transport-admin-requests.htmltransport-admin-request-edit.htmltransport-admin-groups.htmltransport-admin-group-edit.htmltransport-admin.js
- Transport data and server behavior:
api/_lib/transport.jsapi/transport-requests/api/transport-groups/api/transport-group-members/
- User-facing pickup flow:
pickup.htmlpickup-form.htmlpickup-form.js
These modules should not be changed casually. For work touching them:
- Keep the requested scope tight.
- Avoid rewriting flows that operators or users already depend on unless explicitly required.
- Preserve privacy boundaries on public pages and public APIs.
- Prefer incremental edits over broad refactors.
Stable Project Constraints
Business Constraints
- Public-facing pages must avoid exposing private user data.
- Admin workflows should favor operational efficiency and avoid breaking existing operator habits without a clear task requirement.
- Changes related to transport orders, groups, and public board behavior should preserve the current business flow unless the task explicitly requires a process change.
- Do not lightly change transport order grouping logic, public board field exposure, payment-email behavior, or admin request/group workflows.
- Do not casually repurpose
transport-admin.js,transport-api.js,transport-shared.js, orapi/_lib/transport.js; they are core integration points.
Deployment Constraints
- Assume deployment remains on Vercel.
- Be cautious with serverless function count, route sprawl, and cron weight.
- Any deployment-affecting change should consider
vercel.json, Vercel local emulation, and existing public API dispatch structure.
Documentation Constraints
AGENTS.mdis for durable rules only.docs/current-status.mdis the canonical per-task handoff and status file.- Avoid duplicating the same status details in multiple documents unless there is a durable reason.
- At the start of each new task, both files must be read together:
AGENTS.mdfor durable rules,docs/current-status.mdfor the current handoff snapshot. - Only update
AGENTS.mdwhen the current task produces a new long-term rule, constraint, workflow, directory note, run method, or acceptance standard that should persist across future sessions.
Local Run Commands
- Install deps:
npm install - Local helper server:
npm run dev - Vercel local emulation:
npm run dev:vercel - Smoke QA:
npm run qa:playwright:smoke - Transport flow QA:
npm run qa:playwright:transport-flow - Preview build:
npm run build:preview - Production build:
npm run build:prod - Preview deploy:
npm run deploy:preview - Production deploy:
npm run deploy:prod
Task Close-Out Requirement
Every completed task must update E:\webside\docs\current-status.md explicitly:
- Replace or refresh the relevant sections to reflect the newest truth.
- Record what was completed in the current task.
- Record the current project state after the change.
- Record unresolved issues, risks, or follow-up items.
- Record the recommended next step for the next session.
- Do not append raw chronological logs if a section can be rewritten more cleanly.
- If any note is outdated, superseded, or duplicated, rewrite or remove the old note instead of adding another layer of history.
Acceptance Baseline
Before considering a task complete, verify as applicable:
- The requested change is implemented without unrelated business-code churn.
- Relevant local commands still match the repo's expected workflow.
- If behavior changed, run the narrowest meaningful verification available.
- Update
docs/current-status.mdwith:- completed work
- current project status
- open issues or risks
- recommended next steps
- Keep documentation concise, readable, and non-repetitive.
