06 ਦਸੰ 2025·7 ਮਿੰਟ
CRUD ਐਪ ਲਈ Vibe ਕੋਡਿੰਗ ਪ੍ਰੌਮਪਟ: ਫੁੱਲ-ਸਟੈਕ ਕਾਪੀ-ਪੇਸਟ ਸੈੱਟ
CRUD ਐਪ ਲਈ Vibe ਕੋਡਿੰਗ ਪ੍ਰੌਮਪਟ ਵਰਤ ਕੇ ਸਕ੍ਰੀਨ, ਪ੍ਰਮਾਣਿਕਤਾ, ਰੋਲ ਅਤੇ ਇੱਕ Postgres API ਤਿਆਰ ਕਰੋ। ਕਾਪੀ-ਪੇਸਟ ਪ੍ਰੌਮਪਟ ਸੈੱਟ ਅਤੇ ਸਮੱਸਿਆ-ਨਿਪਟਾਰਾ ਸੁਝਾਅ।
CRUD ਐਪ ਲਈ Vibe ਕੋਡਿੰਗ ਪ੍ਰੌਮਪਟ ਵਰਤ ਕੇ ਸਕ੍ਰੀਨ, ਪ੍ਰਮਾਣਿਕਤਾ, ਰੋਲ ਅਤੇ ਇੱਕ Postgres API ਤਿਆਰ ਕਰੋ। ਕਾਪੀ-ਪੇਸਟ ਪ੍ਰੌਮਪਟ ਸੈੱਟ ਅਤੇ ਸਮੱਸਿਆ-ਨਿਪਟਾਰਾ ਸੁਝਾਅ।
\nYou are building a complete full-stack CRUD app.\n\nTech targets (do not change):\n- Frontend: React web app\n- Backend: Go REST API\n- Database: PostgreSQL\n\nBefore writing any code, produce a short plan (max 25 lines) that includes:\n1) Screens + key UI components\n2) Routes/navigation\n3) Roles and permissions\n4) PostgreSQL tables (with columns and relationships)\n5) API endpoints (method + path) for auth and CRUD\n\nAssumptions:\n- If any detail is missing, make a reasonable default and list it under “Assumptions”.\n- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.\n\nRules:\n- Use simple, boring CRUD first. No “nice to have” features unless asked.\n- Include input validation, basic error messages, and loading states.\n- Use clear names that match across layers (same field names in UI, API, and DB).\n\nNon-goals (do NOT implement):\n- Payments, subscriptions, invoices\n- Complex workflows/approvals\n- Multi-tenant org hierarchy\n- Real-time chat/notifications\n\nNow ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.\n\n\nਇੱਕ ਮਿਸਾਲ: ਜੇ ਯੋਜਨਾ role: admin|member ਚੁਣਦੀ ਹੈ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਇਹ manager ਨਾ ਬਣਾਏ। ਇਹ ਪ੍ਰੌਮਪਟ ਮਾਡਲ ਨੂੰ ਰੁੱਕ ਕੇ ਤੁਹਾਡੀ ਮਨਜ਼ੂਰੀ ਮੰਗਣ ਲਈ ਬਾਂਧਦਾ ਹੈ बजाय ਡ੍ਰਿਫਟ ਕਰਨ ਦੇ।\n\n## ਕਾਪੀ-ਪੇਸਟ ਪ੍ਰੌਮਪਟ: ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ\n\nਚੰਗੀਆਂ ਸਕ੍ਰੀਨਾਂ ਇੱਕ ਸਪਸ਼ਟ ਪੇਜ ਮੈਪ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਡੇਟਾਬੇਸ ਜਾਂ API ਕੋਡ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਹੇਠਾਂ ਦਿੱਤੇ ਪ੍ਰੌਮਪਟਾਂ ਨੂੰ ਵਰਤੋ। ਇਹ ਰੂਟਾਂ ਅਤੇ UI ਨਾਮਾਂ ਨੂੰ ਅੱਗੇ ਸਥਿਰ ਰੱਖਦਾ ਹੈ, ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੇ ਬਿਲਡ ਟੁਟ ਜਾਂਦੇ ਹਨ।\n\n### ਪ੍ਰੌਮਪਟ 1: ਪੇਜ ਲਿਸਟ ਅਤੇ ਯੂਜ਼ਰ ਫਲੋਜ਼\n\ntext\nYou are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.\n\nApp concept (1 sentence): <PASTE YOUR APP CONCEPT>\nEntities (list): <ENTITY_1>, <ENTITY_2>\nRoles: <ROLE_1>, <ROLE_2> (include an Admin role)\n\nDeliverables:\n1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.\n2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.\n3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.\n4) Component naming rules: PascalCase, one top-level page component per route.\nAsk me 5 questions max only if needed.\n\n\nਜਦ ਉਹ ਜਵਾਬ ਦੇਵੇ, ਤਾਂ ਨਾਮ ਲਾਕ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਰੂਟਾਂ ਦੇ ਨਾਮ ਬਦਲਦੇ ਹੋ, ਤਾਂ API ਅਤੇ ਟੈਸਟ ਡ੍ਰਿਫਟ ਹੋ ਜਾਣਗੇ।\n\n### ਪ੍ਰੌਮਪਟ 2: ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਫਾਰਮ ਜੋ ਚੰਗੇ ਤਰ੍ਹਾਂ ਵਰਤਦੇ ਹਨ\n\ntext\nUsing the approved page list and route names, generate:\n\nA) Navigation\n- A simple top nav for desktop and a compact mobile menu.\n- Show which items appear for each role.\n- Add a clear "You do not have access" page and redirect rules.\n\nB) Page skeletons\nFor each page, create a minimal UI with:\n- A visible page title and short helper text.\n- Loading state, empty state, error state.\n- A primary button for the main action.\n\nC) Accessible forms\nFor all create/edit forms:\n- Labels tied to inputs, required markers, inline validation errors.\n- Disable submit while saving, show a spinner, prevent double submits.\n- Toast or inline success message after save.\n\nD) Consistent action names\nUse these verbs exactly: list, view, create, update, delete.\nUse these UI actions: onCreate, onUpdate, onDelete, onSearch.\n\n\nਜੇ UI ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਆਖੋ ਕਿ ਸਿਰਫ ਇੱਕ ਲੇਆਉਟ, ਇੱਕ ਟੇਬਲ ਸਟਾਈਲ, ਅਤੇ ਇੱਕ ਫਾਰਮ ਪੈਟਰਨ ਰੱਖੋ।\n\n## ਕਾਪੀ-ਪੇਸਟ ਪ੍ਰੌਮਪਟ: ਅਥੈਂਟੀਕੇਸ਼ਨ ਅਤੇ ਰੋਲ\n\nਜੇ ਤੁਸੀਂ ਪੇਸ਼ਗੋਈਯੋਗ ਨਤੀਜੇ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸ ਗੱਲ ਨੂੰ ਸਪਸ਼ਟ ਰੱਖੋ ਕਿ ਯੂਜ਼ਰ ਕਿਵੇਂ ਲੋਗਿਨ ਕਰਦੇ ਹਨ, ਸੈਸ਼ਨ ਕਿੰਨੀ ਦੇਰ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਹਰ ਭੂਮਿਕਾ ਕੀ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਪ੍ਰੌਮਪਟ ਸਲਪਲ 이메일 + ਪਾਸਵਰਡ ਲੌਗਿਨ ਅਤੇ ਸੈਸ਼ਨ-ਅਧਾਰਿਤ ਦ੍ਰਿਸ਼ਟੀ ਨੂੰ ਮੰਨਦੇ ਹਨ (ਸਕ੍ਰੀਨਾਂ ਅਤੇ APIs 'ਤੇ ਪਰਖਣਾ ਆਸਾਨ)।\n\nਇਹ ਪਹਿਲਾਂ ਪੇਸਟ ਕਰੋ ਤਾਂ ਕਿ ਲਾਗਿਨ, ਲਾਗਆਉਟ, ਅਤੇ ਸੈਸ਼ਨ ਹੈਂਡਲਿੰਗ ਬਣਾਈ ਜਾ ਸਕੇ:\n\n\nImplement authentication for this app.\n\nRequirements:\n- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.\n- Use email + password login.\n- Session handling: keep the user logged in across refresh; include a clear “Log out” button.\n- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.\n- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.\n\nSecurity (keep it simple):\n- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.\n- Store passwords securely (hash + salt). Never store plain text.\n- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.\n\nDeliverables:\n- Working UI flows + backend endpoints.\n- Seed one default admin user for local testing and tell me the credentials.\n- Add clear comments explaining where to change password rules and session duration.\n\n\nਹੁਣ ਰੋਲ ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯਮ ਜੋੜੋ। ਆਸਾਨੀ ਨਾਲ ਟੈਸਟ ਕਰਨ ਲਈ ਨਿਯਮ ਛੋਟੇ ਰੱਖੋ:\n\n\nAdd role-based access control (RBAC) with these roles: admin, manager, viewer.\n\nRules:\n- admin: can create, edit, delete, and manage users/roles.\n- manager: can create and edit records, cannot delete, cannot manage users.\n- viewer: read-only.\n\nEnforcement:\n- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.\n- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.\n\nDeliverables:\n- A simple “Users” admin screen to list users and change roles.\n- A clear table (in text) mapping each route + API endpoint to required role.\n- Add automated checks or middleware so every protected endpoint enforces the rules.\n\n\nਤੇਜ਼ੀ ਨਾਲ ਆਮ ਗਲਤੀਆਂ ਪਕੜਨ ਲਈ ਮਨੁਅਲ ਚੈੱਕ:\n\n- ਹਰ ਭੂਮਿਕਾ ਦੇ ਨਾਲ ਲਾਗਿਨ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਦੇਖ ਸਕਦੇ ਹੋ ਅਤੇ ਕੀ ਨਹੀਂ।\n- ਇੱਕ ਸੀਮਤ ਕਾਰਵਾਈ ਜ਼ਰੂਰ ਕਰੋ (ਜਿਵੇਂ delete) ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ 403 ਮਿਲਦਾ ਹੈ।\n- ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਲਾਗਆਉਟ ਸੈਸ਼ਨ ਸਾਫ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਐਪ Login ਸਕ੍ਰੀਨ ਤੇ ਵਾਪਸ ਜਾਦਾ ਹੈ।\n\nਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ auth ਅਤੇ RBAC ਬਦਲਾਅ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰ ਸਕੋ ਜੇ ਅਨੁਮਤੀਆਂ ਉਲਝਣ।\n\n## ਕਾਪੀ-ਪੇਸਟ ਪ੍ਰੌਮਪਟ: PostgreSQL ਸਕੀਮਾ ਅਤੇ ਡੇਟਾ ਮਾਡਲ\n\nਇੱਕ ਚੰਗਾ ਸਕੀਮਾ ਪ੍ਰੌਮਪਟ ਦੋ ਕੰਮ ਕਰਦਾ ਹੈ: ਇਹ ਸਪਸ਼ਟ ਟੇਬਲ ਰਿਸ਼ਤੇ ਮੰਗਦਾ ਹੈ (ਤਾਕਿ ਸਕ੍ਰੀਨ ਅਤੇ API ਸਥਿਰ ਰਹਿਣ), ਅਤੇ ਇਹ "ਲਗਭਗ ਠੀਕ" ਡੇਟਾਬੇਸ ਨੂੰ ਰੋਕਦਾ ਹੈ (ਗਾਇਬ ਇੰਡੈਕਸ, ਟਾਈਮਸਟੈਂਪ, ਜਾਂ ਰੋਲ ਮੈਪਿੰਗ)।\n\nਪੇਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਦੋ ਟੌਗਲ ਨਿਰਧਾਰਤ ਕਰੋ (ਹਰ ਇੱਕ ਇਕ ਲਾਈਨ):\n\n- Primary keys: uuid ਜਾਂ bigserial\n- Soft delete: yes (use deleted_at) ਜਾਂ no (hard delete)\n\nਇਹ ਪਹਿਲਾ ਪ੍ਰੌਮਪਟ ਪੇਸਟ ਕਰੋ ਤਾਂ ਕਿ ਡੇਟਾ ਮਾਡਲ ਲਾਕ ਹੋ ਜਾਵੇ:\n\n\nYou are building the PostgreSQL data model for a full-stack CRUD app.\n\nDomain: <DESCRIBE YOUR APP IN 1 SENTENCE>\nCore entities: <LIST 3-6 ENTITIES>\n\nRules:\n- Use PostgreSQL.\n- Choose primary key type: <uuid|bigserial>.\n- Timestamps: every table must have created_at and updated_at.\n- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.\n- Define users, roles, and permissions storage:\n - users table (email unique, password_hash, status)\n - roles table (name unique)\n - user_roles join table (user_id, role_id) with unique(user_id, role_id)\n- For each core entity: define columns, types, required vs optional, and relationships.\n- Call out any many-to-many relationships and introduce join tables.\n- Propose indexes for common lookups (foreign keys, email, name/search fields).\n\nOutput:\n1) A short ERD description in plain English.\n2) The final table list with columns and constraints.\n3) The index list with rationale.\n\n\nਫਿਰ ਇਹ ਪ੍ਰੌਮਪਟ ਪੇਸਟ ਕਰੋ ਤਾਂ ਕਿ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜਾਂ ਸੈਟਅਪ ਕਦਮ ਮਿਲ ਸਕਣ ਜੋ ਪ੍ਰੋਜੈਕਟ ਨਾਲ ਮਿਲਦੇ ਹਨ:\n\n\nNow generate the actual database setup for this project.\n\nRequirements:\n- Provide SQL migrations (up and down) for all tables, constraints, and indexes.\n- Ensure foreign keys and on-delete behavior are explicit.\n- Include extensions you rely on (for example uuid generation), but only if needed.\n- Add a seed migration for: one admin user, one admin role, and the user_roles link.\n\nOutput:\n- migrations/ file names in order\n- contents of each up/down migration\n- brief notes on how to apply migrations in the project\n\n\nਜੇ ਕੁਝ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ ਇੱਕ ਹੋਰ ਲਾਈਨ ਜੋੜੋ: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”\n\n## ਕਾਪੀ-ਪੇਸਟ ਪ੍ਰੌਮਪਟ: Go CRUD API (Postgres-backed)\n\nਜੇ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਆਉਟਪੁੱਟ ਅਧੂਰੇ ਆ ਰਹੇ ਹਨ, ਤਾਂ ਇਹ ਪ੍ਰੌਮਪਟ ਮੁੱਖ ਗੱਲਾਂ ਨੂੰ ਜ਼ੋਰਦਾ ਹੈ: ਸਪਸ਼ਟ ਰੂਟ, ਵੈਲੀਡੇਸ਼ਨ, ਪੇਜੀਨੇਸ਼ਨ, ਅਤੇ ਹਰ ਹੈਂਡਲਰ 'ਤੇ ਰੋਲ ਚੈੱਕ।\n\nਇਸਨੂੰ ਜਿਵੇਂ ਹੈ ਕਾਪੀ-ਪੇਸਟ ਕਰੋ, ਫਿਰ ਥਾਂ-ਚਿੰਨ੍ਹ (RESOURCE, FIELDS, ROLES) ਨੂੰ ਆਪਣੀਆਂ ਐਪ ਡੀਟੇਲ ਨਾਲ ਬਦਲੋ।\n\ntext\nYou are building the backend API in Go for a Postgres-backed CRUD resource.\n\nResource\n- RESOURCE name (singular/plural): <Item/items>\n- Table: <items>\n- Primary key: <id UUID>\n- Fields (name, type, required?, rules):\n - <name TEXT required, 2..80 chars>\n - <qty INT required, min 0>\n - <status TEXT optional, one of: active, archived>\n- Ownership: <tenant_id UUID required> and <created_by UUID required>\n\nAuth and roles\n- Roles: <admin, manager, viewer>\n- Authorization rules:\n - Every endpoint must check role and tenant_id.\n - admin: full access\n - manager: create, read, update, list; cannot delete\n - viewer: read and list only\n\nAPI requirements\n1) Implement REST endpoints:\n- POST /api/items\n- GET /api/items/{id}\n- PUT /api/items/{id}\n- DELETE /api/items/{id}\n- GET /api/items\n\n2) Define request/response JSON shapes for each endpoint, including examples.\n\n3) Validation\n- Return 400 with field-level errors (clear messages) when invalid.\n- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.\n\n4) List endpoint\n- Support filtering by: <status>\n- Support sorting by: <created_at,name> with order asc/desc\n- Support pagination: page, page_size; return total, page, page_size, items.\n\n5) Data access\n- Use database/sql (or pgx) with parameterized queries only.\n- Include migrations SQL for the table and indexes (tenant_id + created_at).\n\nDeliverables\n- Go code: routes, handlers, DTOs, validation helpers, repository layer\n- SQL: migration(s)\n- Notes: any assumptions\n\n\nਉਤਪੰਨ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਛੋਟੀ ਸਮੀਖਿਆ ਕਰੋ ਕਿ ਵੈਲੀਡੇਸ਼ਨ ਕੋਡ, ਸਥਿਤੀ ਕੋਡ, ਲਿਸਟ ਆਉਟਪੁੱਟ ਆਦਿ ਸਟੈਂਡਰਡ ਹਨ ਅਤੇ ਹਰ ਹੈਂਡਲਰ ਰੋਲ ਅਤੇ ਟੇਨੈਂਟ ਮਲਕੀਅਤ ਦੋਹਾਂ ਨੂੰ ਚੈਕ ਕਰਦਾ ਹੈ।\n\nਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਵੀ ਦਰਸਾਓ ਕਿ ਬੈਕਐਂਡ Go ਵਿੱਚ ਅਤੇ ਡੇਟਾਬੇਸ PostgreSQL ਵਿੱਚ ਹੀ ਰਹੇ ਤਾਂ ਜੋ ਨਿਰਯਾਤ ਕੋਡ ਉਮੀਦ ਕੀਤਾ ਗਿਆ ਸਟੈਕ ਨਾਲ ਮੇਲ ਖਾਏ।\n\n## ਕਦਮ-ਦਰ-ਕਦਮ: ਉਤਪੰਨ ਕਰੋ, ਚਲਾਓ, ਅਤੇ ਪਰਖੋ\n\nਸਭ ਕੁਝ (UI, API, ਡੇਟਾਬੇਸ) ਜਨਰੇਟ ਕਰੋ, ਫਿਰ ਸਖ਼ਤ ਵੈਰੀਫਾਈ ਮੋਡ 'ਤੇ ਜਾਓ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਸਿਰਫ਼ ਸਕ੍ਰੀਨ ਦੇਖਣਾ ਨਹੀਂ ਹੈ—ਲਕੜੀ ਇਹ ਸਾਬਤ ਕਰਨੀ ਹੈ ਕਿ ਪੂਰਾ ਲੂਪ ਕੰਮ ਕਰਦਾ ਹੈ: UI - auth - roles - Postgres - API - UI।\n\n### ਇੱਕ ਸਧਾਰਣ ਵੈਰੀਫਿਕੇਸ਼ਨ ਰਨ\n\n1) ਐਪ ਚਲਾਓ ਅਤੇ ਹੋਮ ਸਕ੍ਰੀਨ ਲੋਡ ਕਰੋ। ਨੈਵੀਗੇਸ਼ਨ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ placeholder ਡੇਟਾ ਨਹੀਂ ਵੇਖਦੇ—ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਪੇਜ ਖਾਲੀ ਹੈ, ਤਾਂ ਪਹਿਲਾ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਐਰਰ ਸੂਚਨ (UI ਟੋਸਟ, ਕੰਸੋਲ, ਜਾਂ ਸਰਵਰ ਲੌਗ) ਨੋਟ ਕਰੋ।\n\n2) ਹਰ ਭੂਮਿਕਾ ਲਈ ਇੱਕ ਟੈਸਟ ਅਕਾਊਂਟ ਬਣਾਓ (Admin, Manager, Viewer). ਹਰ ਯੂਜ਼ਰ ਨਾਲ ਲאָגਇਨ ਅਤੇ ਲੱਗਆਉਟ ਕਰੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪ ਵਿੱਚ ਭੂਮਿਕਾ ਕਿਸੇ ਥਾਂ ਦਿੱਤੀ ਹੋਈ ਹੈ (ਪ੍ਰੋਫਾਈਲ ਮੇਨੂ, ਸੈਟਿੰਗਜ਼, ਜਾਂ ਛੋਟਾ ਬੈਜ)।\n\n3) ਇੱਕ CRUD ਸਕ੍ਰੀਨ ਚੁਣੋ ਅਤੇ ਪੂਰਾ ਚੱਕਰ ਕਰੋ: ਇੱਕ ਰਿਕਾਰਡ ਬਣਾਓ, ਪੇਜ਼ ਰਿਫ੍ਰੈਸ਼ ਕਰੋ, ਫਿਰ ਸੋਧੋ ਅਤੇ ਮਿਟਾਓ। ਮੁੱਖ ਜਾਂਚ ਪਾਇੰਟ ਹੈ ਪੈਰਿਸਟੈਂਸ: ਰਿਫ੍ਰੈਸ਼ ਤੋਂ ਬਾਅਦ, ਰਿਕਾਰਡ Postgres ਵਿੱਚ ਜੋ ਹੈ ਉਹ ਹੀ ਦਰਸਾਇਆ ਜਾਵੇ, ਸਿਰਫ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਨਹੀਂ।\n\n4) ਜਾਣ-ਬੁਝ ਕੇ ਮਨਾਹੀ ਕੀਤੀ ਕਾਰਵਾਈاں ਕਰੋ। ਸਭ ਤੋਂ ਘੱਟ ਅਧਿਕਾਰ ਵਾਲੀ ਭੂਮਿਕਾ ਨਾਲ ਲਾਗਿਨ ਕਰਕੇ ਇੱਕ ਐਡਮਿਨ-ਨਿਰਧਾਰਿਤ ਸਕ੍ਰੀਨ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਇਕ ਸੀਮਤ ਕਾਰਵਾਈ (ਜਿਵੇਂ delete) ਕਾਲ ਕਰੋ, ਅਤੇ ਇੱਕ ਰਿਕਾਰਡ ਸੋਧੋ ਜੋ ਤੁਹਾਨੂੰ ਨਹੀਂ ਚਾਹੀਦਾ। ਤੁਹਾਨੂੰ ਸਪੱਸ਼ਟ ਨਤੀਜੇ ਚਾਹੀਦੇ ਹਨ: ਜਾਂ ਤਾਂ UI ਬਲੌਕ ਕਰੇ ਇਕ ਸੁਨੇਹੇ ਨਾਲ, ਜਾਂ ਇੱਕ 403-ਸਟਾਈਲ ਐਰਰ ਦੇ ਨਾਲ ਕੋਈ ਡੇਟਾ ਬਦਲਾਅ ਨਾ ਹੋਵੇ।\n\n5) ਬੇਸਿਕ ਏਜ ਕੇਸ ਟੈਸਟ ਕਰੋ: ਖਾਲੀ ਲਿਸਟ, ਬਹੁਤ ਲੰਬੇ ਨਾਂ, ਗੁੰਮ ਫੀਲਡ, ਅਤੇ ਗਲਤ ਫਾਰਮੈਟ (email, dates). ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪ ਮਦਦਗਾਰ ਵੈਲੀਡੇਸ਼ਨ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਹੁੰਦਾ।\n\nਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲੀ ਸਫਲ end-to-end CRUD ਟੈਸਟ ਤੋਂ ਬਾਅਦ ਸਨੈਪਸ਼ਾਟ ਲਓ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਰੋਲਬੈਕ ਦੇ ਸਕਦੇ ਹੋ।\n\n## ਆਮ ਪ੍ਰੌਮਪਟ نقصانات ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਹੱਲ\n\nਜ਼ਿਆਦਾਤਰ “ਟੁੱਟੇ” ਬਿਲਡ ਅਸਲ ਵਿੱਚ ਟੁੱਟੇ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਇੱਕ ਸੀਮਤ ਨਿਯਮ ਦੇ ਘਾਟ ਹੋ ਜਾਂਦੇ ਹਨ ਜੋ UI, API, ਅਤੇ ਡੇਟਾ ਨੂੰ ਇਕੱਠੇ ਰੱਖੇ।\n\n### 1) ਤੁਸੀਂ ਇਕ ਵਾਰੀ ਬਹੁਤ ਕੁਝ ਮੰਗ ਲਿਆ\n\nਜਦੋਂ ਤੁਸੀਂ ਸਕ੍ਰੀਨ, auth, ਰੋਲ, ਸਕੀਮਾ, ਅਤੇ ਹਰ ਏਜ ਕੇਸ ਇਕੱਠੇ ਮੰਗਦੇ ਹੋ, ਤਾਂ ਐਪ ਅਕਸਰ ਅਸਮੰਜਸ ਹੋ ਜਾਂਦੀ ਹੈ (ਰੂਟ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਮਾਡਲ ਡ੍ਰਿਫਟ ਹੋ ਜਾਂਦੇ, ਅਧੂਰੇ ਪੇਜ਼)।\n\nਹੱਲ: ਲੇਅਰ-ਵਾਈਜ਼ ਵੰਡੋ ਅਤੇ ਟੂਲ ਨੂੰ ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਦੱਸਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰੋ ਕਿ ਉਹ ਕੀ ਉਤਪੰਨ ਕਰਨਗੇ। Koder.ai ਵਿੱਚ, ਇਹ ਵੀ ਵੱਖ-ਵੱਖ ਏਜੈਂਟਾਂ ਨੂੰ ਸੰਗਤ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।\n\n### 2) ਭੂਮਿਕਾਵਾਂ ਧੁੰਦਲੀ ਹਨ, ਇਸ ਲਈ ਚੈੱਕ ਮਿਸਿੰਗ ਹੁੰਦੇ ਹਨ\n\nਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ "admin ਅਤੇ user" ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ UI ਵਿੱਚ ਇੱਕ ਰੋਲ ਲੇਬਲ ਮਿਲ ਸਕਦੀ ਹੈ ਪਰ ਸਰਵਰ-ਸਾਈਡ ਅਧਿਕਾਰ ਨਹੀਂ ਮਿਲਦੇ।\n\nਹੱਲ: Permissions ਨੂੰ ਐਕਸ਼ਨਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰੋ (create, read, update, delete) ਪ੍ਰਤੀ ਰਿਸੋਰਸ, ਅਤੇ ਹਰ ਐਂਡਪੌਇੰਟ 'ਤੇ ਸਰਵਰ-ਪਾਸਿੰਗ ਮੰਗੋ।\n\n### 3) ਫੀਲਡ ਕਿਸਮਾਂ ਦੇ ਘਾਟ ਨਾਲ UI ਅਤੇ DB ਡ੍ਰਿਫਟ\n\nਜੇ ਤੁਸੀਂ ਫੀਲਡਾਂ ਨੂੰ ਸਿਰਫ਼ ਆਮ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵੇਖਾਉਂਦੇ ਹੋ ("price", "date", "status"), ਤਾਂ ਫਾਰਮਾਂ ਟੈਕਸਟ ਇਨਪੁੱਟ ਵਾਂਗ ਬਣ ਸਕਦੀਆਂ ਹਨ ਜਦਕਿ Postgres ਸੰਖਿਆਵਾਂ, ਤਾਰੀਖਾਂ, ਜਾਂ enums ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।\n\nਹੱਲ: ਫੀਲਡ ਕਿਸਮਾਂ, ਨਲਇਬਲਟੀ, ਡਿਫਾਲਟ ਅਤੇ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਸਾਂਝੇ ਵੈਲੀਡੇਸ਼ਨ ਨਿਯਮ ਮੰਗੋ।\n\n### 4) ਲੋਡਿੰਗ ਅਤੇ ਐਰਰ ਸਟੇਟ ਨਾ ਹੋਣ ਨਾਲ UI ਟੁੱਟਿਆ ਲੱਗਦਾ ਹੈ\n\nਲੋਡਿੰਗ ਅਤੇ ਐਰਰ ਸਟੇਟ ਬਿਨਾਂ, ਇੱਕ ਫੇਲ ਹੋਈ ਬਿਨੈ ਇਕ ਜਮ੍ਹਿਆ ਹੋਇਆ ਪੇਜ਼ ਵਾਂਗ ਲੱਗਦੀ ਹੈ।\n\nਹੱਲ: ਹਰ ਸਕ੍ਰੀਨ ਲਈ ਲੋਡਿੰਗ ਸਪਿਨਰ, ਖਾਲੀ ਸਟੇਟ, ਅਤੇ ਦ੍ਰਿਸ਼੍ਯ ਐਰਰ ਸੰਦਰਭ ਲਾਜ਼ਮੀ ਕਰੋ।\n\n### 5) ਨਾਂ ਬਦਲਣ ਨਾਲ ਬਿਲਡ ਵਿਚ ਖਰਾਬੀ ਆਉਂਦੀ ਹੈ\n\n"Projects" ਨੂੰ ਅੱਧੇ ਰਸਤੇ "Workspaces" ਬਦਲ ਦੇਣ ਨਾਲ ਅਕਸਰ ਰੂਟ, ਹੈਂਡਲਰ, ਅਤੇ ਟੇਬਲ ਨਾਂ ਟੁੱਟ ਜਾਂਦੇ ਹਨ।\n\nਹੱਲ: ਪਹਿਲਾਂ ਇੱਕ ਗਲੋਸਰੀ ਲਾਕ ਕਰੋ। ਜਦ ਤੁਸੀਂ ਨਾਂ ਬਦਲੋ, ਤਦ ਇੱਕ ਰੀਨੇਮ ਯੋਜਨਾ ਮੰਗੋ (search, replace, migrate) ਬਜਾਏ ਕਿ ਮਾਡਲ ਨੂੰ ਆਪਣਾ ਮਰਜ਼ੀ ਨਾਲ ਇਮਪ੍ਰੋਵਾਈਜ਼ ਕਰਨ ਦਿਓ।\n\nਜਦ ਕੁਝ ਗਲਤ ਹੋ ਜਾਵੇ ਤਾਂ ਇਸ ਰਿਪੇਅਰ ਪ੍ਰੌਮਪਟ ਵਰਤੋ:\n\ntext\nAudit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.\nThen propose a minimal patch plan.\nRules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.\nOutput: a checklist of changes, then apply them.\n\n\nਜੇ ਤੁਸੀਂ ਲਗਾਤਾਰ ਅਸਮੰਜਸ ਆ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸੰਭਵਤ: ਇੱਕ "single source of truth" ਬਿਆਨ ਦੀ ਘਾਟ ਹੈ। ਇੱਕ ਵਾਕ ਜੋੜੋ: “The Postgres schema is the source of truth; UI and API must match it exactly.”\n\n## ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਕਹੋ ਮੁਕੰਮਲ ਹੈ\n\nਪਲਿਸ ਸੈਸ਼ਨ ਪੂਰਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਤੇਜ਼ ਪਾਸ ਕਰੋ ਤਾਂ ਕਿ ਐਪ ਇੱਕ ਅਸਲ ਉਤਪਾਦ ਵਾਂਗ ਵਰਤੋਂਯੋਗ ਲੱਗੇ। ਬਹੁਤ ਸਾਰੇ ਫੁੱਲ-ਸਟੈਕ CRUD ਐਪ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਸਕ੍ਰੀਨ, ਨਿਯਮ, ਅਤੇ ਡੇਟਾ ਵਿੱਚ ਛੋਟੀ-ਛੋਟੀ ਅਸਮੰਜਸ।\n\n- Screens match the entity spec: ਹਰ ਸਕ੍ਰੀਨ (list, details, create, edit) ਉਹੀ ਇਕਾਈ ਨਾਮ ਅਤੇ ਫੀਲਡ ਲਿਸਟ ਵਰਤੇ ਜੋ ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਕੀਤੀ।\n- Roles are unambiguous: ਹਰ ਭੂਮਿਕਾ ਲਈ ਇੱਕ ਸਧਾਰਨ allow/deny ਟੇਬਲ ਲਿਖੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ UI ਅਤੇ API ਇਕੋ ਨਿਯਮ ਲਾਗੂ ਕਰਦੇ ਹਨ।\n- API responses are consistent: ਇੱਕ ਪੈਟਰਨ ਚੁਣੋ (status codes, error shape, pagination shape) ਅਤੇ ਰੱਖੋ ਕਿ ਹਰ ਐਂਡਪੌਇੰਟ ਇਸ ਦਾ ਪਾਲਣ ਕਰੇ।\n- Database constraints match form validation: ਜੇ DB ਯੂਨੀਕ email ਜਾਂ non-null name ਮੰਗਦਾ ਹੈ, ਤਾਂ ਸਬਮਿਟ ਤੋਂ ਪਹਿਲਾਂ ਵੈਲੀਡੇਸ਼ਨ ਕਰੋ ਅਤੇ ਜਦ API ਰਿਜੈਕਟ ਕਰੇ ਤਾਂ ਇੱਕ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਓ।\n- Create/edit/delete survives a refresh: ਇੱਕ ਰਿਕਾਰਡ ਬਣਾਓ, ਰਿਫ੍ਰੈਸ਼ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਊਥੇ ਹੈ; ਸੋਧ ਕਰੋ, ਰਿਫ੍ਰੈਸ਼ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ; ਮਿਟਾਓ, ਰਿਫ੍ਰੈਸ਼ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ।\n\nA concrete test: lowest-permission ਭੂਮਿਕਾ ਨਾਲ ਲოგਿਨ ਕਰੋ ਅਤੇ ਇੱਕ ਐਸਾ ਐਕਸ਼ਨ ਕਰੋ ਜੋ ਤੁਸੀਂ ਰੋਕਣਾ ਚਾਹੁੰਦੇ ਹੋ (ਜਿਵੇਂ delete). ਜੇ ਇਹ ਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਪਾਲਿਸੀ ਨੂੰ ਇੱਕ ਜਗ੍ਹਾ (API) 'ਚ ਫਿਕਸ ਕਰੋ, ਫਿਰ UI ਨੂੰ ਮਿਲਾਓ।\n\n## ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਇੱਕ ਸਾਦਾ ਇਨਵੈਂਟਰੀ ਟ੍ਰੈਕਰ\n\nਸੋਚੋ ਇੱਕ ਛੋਟੀ IT ਟੀਮ ਜਿਸ ਨੇ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਲੈਪਟਾਪ, ਮਾਨੀਟਰ, ਅਤੇ ਐਡਪਟਰ ਉਧਾਰ 'ਤੇ ਦੇਣੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਥਾਂ ਚਾਹੀਦੀ ਹੈ ਜਿੱਥੇ ਮਿਲ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਉਪਲਬਧ ਹੈ, ਕਿਸ ਨੇ ਕੀ ਲਿਆ ਹੈ, ਅਤੇ ਵਾਪਸੀ ਕਦੋਂ ਹੈ। ਇਹ ਚੰਗਾ ਟੈਸਟ ਹੈ ਕਿਉਂਕਿ ਇਹ ਭੂਮਿਕਾਵਾਂ, ਕੁਝ ਸਕ੍ਰੀਨ, ਅਤੇ ਇੱਕ ਸਰਲ ਡੇਟਾਬੇਸ ਲਈ ਜ਼ੋਰ ਲਾਉਂਦਾ ਹੈ।\n\n### ਭਰਿਆ ਹੋਇਆ ਤਿਆਰੀ ਵਰਕਸ਼ੀਟ\n\nਇਸ ਨੂੰ ਆਪਣੇ ਤਿਆਰੀ ਕਦਮ ਲਈ ਬਿਲਕੁਲ ਇਸੇ ਢੰਗ ਨਾਲ ਵਰਤੋ (ਕਾਪੀ ਕਰੋ, ਫਿਰ ਨਾਮ ਬਦਲੋ):\n\ntext\nApp name: IT Equipment Loans\nGoal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.\nRoles:\n- admin: manage inventory, approve/deny requests, edit any loan, see all\n- staff: browse inventory, create a request, see own requests/loans\n- viewer: read-only access to inventory and aggregate loan status\nCore screens:\n- Login\n- Inventory list + item detail\n- Request item (staff)\n- Admin requests queue\n- Loans list (filter: active/overdue)\nData rules:\n- An item can have 0 or 1 active loan at a time\n- Due date required for approved loans\n- Overdue if due_date < today and not returned\nSample data:\n- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)\n- Users: alice(admin), ben(staff), carla(viewer)\n\n\n### ਪੇਸਟ ਕਰਨ ਦਾ ਕ੍ਰਮ\n\nਐਪ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਲਈ ਆਪਣੇ ਪ੍ਰੌਮਪਟ ਇਹ ਆਲੜੀ ਅਨੁਕ੍ਰਮ ਵਿੱਚ ਪੇਸਟ ਕਰੋ:\n\n1) Base prompt (ਗਲੋਬਲ ਨਿਯਮ, ਟੈਕ ਸਟੈਕ, ਨਾਂਕਰਨ, ਐਰਰ ਹੈਂਡਲਿੰਗ)\n2) Screens and navigation (Inventory, Requests, Loans, Admin queue)\n3) Authentication and roles (admin, staff, viewer permissions)\n4) PostgreSQL schema and seed data (items, loans, requests, users)\n5) Go CRUD API (endpoints and validation that match the rules)\n\nਇੱਕ ਚੰਗਾ ਨਤੀਜਾ ਐਸਾ ਹੋਵੇਗਾ: staff "MBP-014" ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ, admin ਇਸਨੂੰ ਮਨਜ਼ੂਰ ਕਰਕੇ ਇੱਕ due date ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਨਵੈਂਟਰੀ ਲਿਸਟ ਇਸਨੂੰ ਅਣਉਪਲੱਬਧ ਦਿਖਾਏਗਾ ਜਿਸ ਤੇ ਆਪਣੇ ਨਾਂ ਦਰਸਾਇਆ ਹੋਵੇ।\n\nਜੇ ਬਿਲਡ ਨੇੜੇ ਹੈ ਪਰ ਠੀਕ ਨਹੀਂ, ਤਾਂ ਇਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਹੀ ਚੀਜ਼ ਠੀਕ ਕਰੋ: ਰੋਲ ਅਨੁਮਤੀਆਂ ਕਠੇ ਕਰੋ (viewer ਨੂੰ ਕਦੇ edit ਬਟਨ ਨਹੀਂ ਦਿਖਾਓ), "only one active loan per item" ਨਿਯਮ ਦੁਬਾਰਾ ਦੱਸੋ, ਜਾਂ ਮੰਗੋ ਕਿ ਉਹ ਫੀਲਡਾਂ ਦਾ ਨਾਮ ਬਦਲੇ ਤਾਂ UI ਲੇਬਲ ਅਤੇ DB ਕਾਲਮ ਮਿਲ ਜਾਵਣ।\n\n## ਅਗਲੇ ਕਦਮ: ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਧਾਓ ਅਤੇ ਪ੍ਰੌਮਪਟ ਸੈੱਟ ਫੇਰ ਵਰਤੋ\n\nਜਦੋਂ ਮੂਲ ਚੀਜ਼ਾਂ ਕੰਮ ਕਰਨ ਲੱਗਣ, ਅਗਲੇ ਬਦਲਾਅ ਨੂੰ ਛੋਟੇ ਰੀਲੀਜ਼ ਵਾਂਗਲੋ। ਇੱਕ ਫੀਚਰ ਚੁਣੋ, "done" ਕੀ ਮਤਲਬ ਹੈ ਇਹ ਪਰਿਭਾਸ਼ਤ ਕਰੋ, ਫਿਰ ਉਸ ਲਈ ਪ੍ਰੌਮਪਟ ਕਰੋ।\n\nਅਕਸਰ ਇਕ ਸਮਝਦਾਰ ਕ੍ਰਮ:\n\n- Audit log: ਕੌਣ, ਕਿਵੇਂ, ਅਤੇ ਕਦੋਂ ਬਦਲਿਆ, ਇਹ ਰਿਕਾਰਡ ਕਰਨਾ, ਅਤੇ admin-ਕੇਵਲ ਸਕ੍ਰੀਨ 'ਤੇ ਦਿਖਾਉਣਾ।\n- File uploads: ਰਿਕਾਰਡ ਨਾਲ ਇੱਕ ਡਾਕਯੂਮੈਂਟ ਜਾਂ ਇਮेज ਜੋੜਨਾ, metadata Postgres ਵਿੱਚ ਰੱਖਣਾ, ਅਤੇ access ਨੂੰ auth ਦੇ ਪਿੱਛੇ ਰੱਖਣਾ।\n- Simple notifications: in-app alerts ਦਿਖਾਉਣਾ (ਉਦਾਹਰਨ: “low stock” ਜਾਂ “new comment”), ਅਤੇ “mark as read” ਕਾਰਵਾਈ।\n\nਜਦ ਇੱਕ ਬਦਲਾਅ ਬਿਲਡ ਨੂੰ ਤੋੜ ਦੇਵੇ, ਤਦ ਸਾਰਿਆਂ ਨੂੰ ਇੱਕ ਵਾਰੀ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਰੋਲਬੈਕ ਕਰੋ, ਫਿਰ ਵੱਧ ਖਾਸ, ਛੋਟੇ ਪ੍ਰੌਮਪਟ ਨਾਲ ਫਿਰ ਲਾਗੂ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ snapshots ਅਤੇ rollback ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਸੁਰੱਖਿਆ ਜਾਲ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦ ਤਬਦੀਲੀਆਂ DB ਸਕੀਮਾ, auth ਨਿਯਮ, ਜਾਂ ਸਾਂਝੇ UI ਕੰਪੋਨੇਟ ਛੂਹਦੀਆਂ ਹਨ।\n\nPlanning Mode ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਫੀਚਰ ਕਈ ਲੇਅਰਾਂ 'ਤੇ ਫੈਲਿਆ ਹੋਵੇ। ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਯੋਜਨਾ ਦੁਬਾਰਾ ਕਹਾਣ ਦੀ ਮੰਗ ਕਰੋ (ਸਕ੍ਰੀਨ, API ਐਂਡਪੌਇੰਟ, ਡੇਟਾਬੇਸ ਬਦਲਾਅ, ਰੋਲ), ਫਿਰ ਉਸ ਯੋਜਨਾ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰੋ ਪਹਿਲਾਂ ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਤੋਂ। ਇਹ ਰੋਕਦਾ ਹੈ ਆਮ ਅਸਮੰਜਸ ਨੂੰ ਜਿੱਥੇ UI ਉਹ ਫੀਲਡ ਉਮੀਦ ਕਰਦੀ ਹੈ ਜੋ API ਵਾਪਸ ਨਹੀਂ ਕਰਦਾ, ਜਾਂ API ਕਾਲਮਾਂ 'ਤੇ ਲਿਖਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਨਹੀਂ।\n\nਜੇ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮ ਤੋਂ ਬਾਹਰ ਅਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਰੋਤ ਕੋਡ export ਕਰੋ ਅਤੇ ਆਪਣੀ ਪਸੰਦੀਦਾ ਵਰਕਫਲੋ ਵਿੱਚ ਤਬਦੀਲੀ ਜਾਰੀ ਰੱਖੋ। ਪ੍ਰੌਮਪਟ ਸੈੱਟ ਨੂੰ ਰੇਪੋ ਦੇ ਨਾਲ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਐਪ ਨੂੰ ਮੁੜ ਬਣਾਉਣ ਜਾਂ ਕਿਸੇ ਨਵੇਂ ਵਿਅਕਤੀ ਨੂੰ onboard ਕਰਨ ਲਈ ਉਨ੍ਹਾਂ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਵਰਤ ਸਕੋ।\n\nਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਤੇ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਪ੍ਰੌਮਪਟ ਸੈੱਟ ਪਲੇਟਫਾਰਮ ਦੇ React + Go + PostgreSQL ਡਿਫ਼ੌਲਟ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲਾਈਨ ਅਪ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ snapshots ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇਟਰੈਟ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਲੋੜਾਂ ਨੂੰ ਸੁਧਾਰਦੇ ਹੋ।\n\nਅੰਤ ਵਿੱਚ, ਆਪਣੀ ਅਗਲੀ ਪ੍ਰੋਜੈਕਟ ਲਈ ਇੱਕ ਦੁਬਾਰਾ ਵਰਤਣ ਯੋਗ ਟੈਮਪਲੇਟ ਪ੍ਰੌਮਪਟ ਸੰਭਾਲੋ। ਸਥਿਰ ਭਾਗ (ਸਟੈਕ, CRUD ਨਿਯਮ, auth ਅਤੇ ਰੋਲ ਸਹੀਤ, Postgres ਪੈਟਰਨ) ਰੱਖੋ ਅਤੇ ਸਿਰਫ਼ ਡੋਮੇਨ ਨਾਮ ਬਦਲੋ। ਸਮੇਂ ਦੇ ਨਾਲ, ਤੁਹਾਡੇ ਪ੍ਰੌਮਪਟ ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਨੁਸਖਾ ਬਣ ਜਾਂਦੇ ਹਨ।Start with the core entity and its 6–12 fields (name, type, required/optional, examples). Then lock roles + permissions in plain language, and ask for a short plan before any code.\n\nA good default is to generate in this order:\n\n- Global rules (stack, naming, error handling)\n- Screens + routes\n- Auth + RBAC\n- PostgreSQL schema + seed data\n- Go CRUD API
Because it forces the model to treat UI, API, and database as a single contract. Vague prompts usually create drift:\n\n- UI uses one field name, API expects another\n- routes don’t match navigation\n- auth exists in UI but not enforced in the API\n\nA tight prompt makes names, rules, and validations match across layers.
Pick a core entity you’ll manage every day (Customer, Task, Item). Keep it to one entity on day one unless a second entity is truly required for the workflow.\n\nA practical default:\n\n- 1 main entity + optional 1 supporting entity (like Category)\n- 6–12 fields with types and examples\n- 2–3 roles with clear CRUD permissions
Because examples guide labels, formatting, and validation. If you only say “date” or “status,” you’ll often get mismatched UI inputs (text box) versus DB types (date/enum).\n\nUse a consistent field line format:\n\n- field_name: type - example (rules)\n\nThis helps the React form, Go validation, and PostgreSQL constraints stay aligned.
Use 2–3 roles max, mapped to the CRUD verbs list, view, create, update, delete.\n\nA solid default:\n\n- admin: full CRUD + manage users/roles\n- manager: create/read/update/list; no delete; no user management\n- viewer: read-only (list + view)\n\nThen require enforcement in both UI routes and API endpoints.
Implement and test both:\n\n- UI protection: hide nav items and block routes with a “Not allowed” page\n- API protection: return 401 when not logged in, 403 when logged in but not allowed\n\nA practical rule: if the UI blocks an action, the API must still reject it if called directly.
Default to email + password with session persistence across refresh.\n\nMinimum requirements to request:\n\n- UI: Login page, logout action, “My account” page (shows email + role)\n- API: POST /auth/login, POST /auth/logout, GET /auth/me\n- Security basics: hashed passwords, rate-limit login attempts, generic error text\n\nSeed a single admin user for local testing.
Pick one convention and enforce it everywhere:\n\n- Routes: kebab-case, consistent singular/plural\n- Components: PascalCase, one top-level page component per route\n- Fields: same names in UI form, API JSON, and DB columns\n\nIf you rename anything later, request a rename plan (search/replace + migrations) instead of letting the model improvise.
Ask the model to return the same shape from every list endpoint:\n\n- Query params: page, page_size, plus your filters\n- Response: total, page, page_size, items\n\nAlso require stable sorting (for example then ) so pagination doesn’t skip or duplicate items.
Use an audit prompt that compares:\n\n- UI routes vs API paths\n- Form fields vs request/response JSON\n- JSON fields vs DB columns\n- Validation rules vs DB constraints\n\nThen apply a minimal patch plan.\n\nA good rule is: don’t add features while fixing mismatches—only align names, routes, validations, and permissions.
created_atid