Create Project

Role from Awesome ChatGPT Prompts (prompts.csv, CC0-1.0). The prompt is the persona's instructions; ratings and installs below are from this marketplace.

MASTER AI SOFTWARE DEVELOPMENT PROMPT District Administration — Generic Campaign Management, Field Operations, Survey, Verification, Reporting & Payment Platform Build a production-grade, full-stack, enterprise-level web application for District Administration that can be used to create and operate large-scale government field campaigns. The platform must support campaigns involving: • One department. • Multiple departments. • Joint inter-department teams. • Senior officers. • Supervisors. • Field officers. • Reserve/backup employees. • Institutions. • Villages. • Wards. • Mohallas. • Households. • Other configurable target entities. The system must allow District Administration to create a campaign, divide it into multiple phases, create different forms for each phase, assign employees and teams to geographic areas and target entities, collect field data through mobile devices, verify submissions through a configurable hierarchy, request corrections, track final results, calculate authorized duty payments/honorarium according to configurable government guidelines, and generate dashboards and reports. The system must be generic. Do not hard-code the application for Census only. Census 2027 should be implemented as an example campaign type. Other campaign types must be possible without changing the core software. Examples: • Census 2027. • School Inspection. • Hospital Inspection. • Road Survey. • Flood Damage Survey. • Village Survey. • PDS Inspection. • Anganwadi Inspection. • Infrastructure Survey. • Government Scheme Verification. • Disaster Assessment. • Public Grievance Field Verification. • Any future district campaign.

1. CORE BUSINESS MODEL The complete system should follow this structure: District → Campaign → Campaign Phase → Geographic Scope → Departments → Workforce → Teams → Target Entities → Tasks → Dynamic Forms → Field Submission → Verification → Correction/Re-submission → Final Approval → Phase Result → Payment/Honorarium → Reports Every part must be configurable.

2. MAIN OBJECTIVE The application must solve the real-world problem of: "A District Administration has thousands of employees from different departments and wants to conduct multiple field campaigns simultaneously across different geographic areas, with different teams, forms, workloads, verification processes, deadlines, payment rules and reporting requirements." The platform should reduce manual Excel/WhatsApp/paper-based coordination. It should provide one central command system for District Administration.

3. MULTIPLE CAMPAIGNS District Administration must be able to run multiple campaigns simultaneously. Example: • Census 2027. • School Inspection. • Road Survey. • Flood Assessment. • Drinking Water Survey. Each campaign is independent. Each campaign can have: • Different departments. • Different employees. • Different geographic areas. • Different forms. • Different workflow. • Different deadlines. • Different payment rules. • Different target entities. • Different reporting structure.

4. MULTI-PHASE CAMPAIGN Every campaign can have multiple phases. Example: Census 2027 Phase 1 House Listing Phase 2 Household Enumeration Phase 3 Verification Phase 4 Correction/Re-enumeration Each phase must be able to have: • Different dates. • Different forms. • Different workforce. • Different teams. • Different geographic assignments. • Different instructions. • Different workload. • Different verification workflow. • Different payment rules. • Different results. Do not assume that all phases use the same employees or form.

5. CAMPAIGN TYPES Create configurable campaign types. Examples: • Census. • Inspection. • Survey. • Verification. • Enumeration. • Monitoring. • Assessment. • Disaster response. • Infrastructure survey. • Custom. Admin can create a new campaign type.

6. ORGANIZATIONAL HIERARCHY The organization must be configurable. Example: District Admin → Department Head → Subdivision Officer → Tehsil Officer → Block Officer → Supervisor → Field Team → Field Officer But another department may have a different structure. Therefore do not hard-code hierarchy levels. Use: OrganizationNode with configurable parent/child relationships.

7. GEOGRAPHIC HIERARCHY Support flexible geographic hierarchy. Example rural: State → District → Subdivision → Tehsil → Block → Village → Mohalla/Hamlet → Household Example urban: State → District → Municipality/Nagar Palika → Zone → Ward → Mohalla → Household The system must support both. Do not assume every area has the same structure.

8. GEOGRAPHIC MASTER DATA Create geographic master data management. Admin can manage: • District. • Subdivision. • Tehsil. • Block. • Municipality. • Ward. • Village. • Mohalla. • GPS coordinates. • Boundary/polygon where available. Support bulk import through: • CSV. • Excel. • Government master-data API where available. Validate duplicate geographic records.

9. TARGET ENTITY ENGINE Do not make "household" the only target. Create a generic target entity system. Possible entities: • Household. • Person. • School. • Hospital. • Road. • Village. • Shop. • Anganwadi. • Government building. • Water source. • Custom entity. Example: Campaign: School Inspection Target: School Campaign: Census Target: Household Campaign: Road Survey Target: Road segment.

10. ENTITY MASTER RECORD Every target entity should have a permanent master record. Example: Household ID: HH-000001 School ID: SCH-000001 Road ID: ROAD-000001 The master entity can have multiple campaign/phase submissions. This prevents duplication.

11. HOUSEHOLD MODEL For Census-type campaigns support: Household → Household members → Individual person records The household can have: • Household ID. • Address. • Geographic hierarchy. • House number. • GPS. • Status. • Source. • Phase history. The individual/person structure must support variable number of persons.

12. EMPLOYEE MASTER Create a central employee database. Fields: • Employee ID. • Name. • Mobile number. • Designation. • Department. • Office. • Posting location. • District. • Subdivision. • Tehsil. • Block. • Role. • Employment status. • Availability. • Reserve status. • Training status. Employee ID should be unique. Mobile number should be unique where applicable.

13. BULK EMPLOYEE IMPORT Support import of thousands of employees. Formats: • Excel. • CSV. Before import: • Validate. • Detect duplicate Employee IDs. • Detect duplicate mobile numbers. • Detect missing fields. • Detect invalid departments. • Show row-level errors. Allow: Import Valid Records without losing valid records because of invalid rows.

14. EMPLOYEE AVAILABILITY Employee status: • Available. • Assigned. • On Duty. • On Leave. • Unavailable. • Reserve. • Activated Reserve. • Released. • Suspended. Campaign assignment must check availability. Prevent incompatible double assignment.

15. MULTI-DEPARTMENT CAMPAIGNS A campaign can include multiple departments. Example: School Inspection: • Education. • PWD. • Food. • Revenue. Each department can have different responsibilities.

16. JOINT TEAMS Create a team engine. A team can contain employees from different departments. Example: Team 001: • Revenue employee. • Education employee. • PWD employee. Each team has: • Team ID. • Team leader. • Members. • Department. • Geographic responsibility. • Campaign. • Phase. • Status.

17. TEAM FORMATION Allow: Manual Admin selects employees. Automatic System creates teams based on configured rules. Rules may include: • Team size. • Department combination. • Geographic area. • Designation. • Skill. • Availability. • Workload.

18. TEAM LEADER Team leader can: • See team members. • See assigned tasks. • Monitor progress. • Review team-level work where authorized. • Report employee absence. • Request replacement. • Submit team reports. Do not automatically grant access to all data just because someone is team leader. Permissions must still apply.

19. RESERVE EMPLOYEE SYSTEM Every large campaign should support reserve employees. Reserve employees can replace active staff when necessary. Reasons: • Leave. • Illness. • Transfer. • Emergency. • Administrative requirement. • Other authorized reasons. Workflow: Active Employee → Unavailable → Supervisor reports → Authorized officer approves → Reserve employee selected → Reserve activated → Assignment transferred → Audit record created.

20. RESERVE TEAM Support reserve teams in addition to reserve individuals. Example: Active Team: Team 001 Reserve Team: Team R001 If an entire team becomes unavailable, the reserve team can be activated.

21. WORKLOAD MANAGEMENT Before launching a campaign phase, show: Total target entities. Required workforce. Available workforce. Reserve workforce. Expected workload per employee. Expected workload per team. Example: Targets: 1,000,000 Teams: 10,000 Average: 100 targets/team. Allow authorized admins to adjust distribution.

22. WORKLOAD BALANCING Support: • Equal distribution. • Geographic distribution. • Random distribution. • Manual distribution. • Skill-based distribution. • Workload balancing. The system should detect overloaded employees/teams. Example: Employee A: 300 tasks Employee B: 80 tasks Show warning.

23. RANDOM ASSIGNMENT Support random assignment where required. Example: 10,000 schools 1,000 officers System randomly assigns schools. Prevent duplicate assignments. Allow administrators to preview before activation. Maintain assignment history.

24. GEOGRAPHIC ASSIGNMENT Tasks can be assigned based on: • District. • Subdivision. • Tehsil. • Block. • Village. • Ward. • Mohalla. • GPS boundary. Support polygon-based geographic assignment where feasible.

25. CAMPAIGN CREATION WIZARD Create a professional multi-step wizard. Step 1 Campaign details. Step 2 Campaign type. Step 3 Geographic scope. Step 4 Departments. Step 5 Workforce. Step 6 Teams. Step 7 Target entities. Step 8 Form. Step 9 Assignment. Step 10 Verification workflow. Step 11 Payment rules. Step 12 Guidelines/documents. Step 13 Preview. Step 14 Launch.

26. CAMPAIGN VALIDATION BEFORE LAUNCH Before launch check: • No target entities. • No teams. • No officers. • Missing form. • Missing mandatory questions. • Missing geographic assignment. • Missing verification workflow. • Missing payment configuration where required. • Employee conflicts. • Duplicate assignments. • Insufficient workforce. • Invalid dates. Show warnings and errors. Do not allow launch when critical requirements are missing.

27. DYNAMIC FORM BUILDER District Admin must create forms without coding. Question types: • Short text. • Long text. • Integer. • Decimal. • Percentage. • Currency/amount. • Date. • Date/time. • Yes/No. • Radio. • Checkbox. • Dropdown. • Multi-select. • Image. • Multiple image. • Video. • File. • GPS. • Signature. • Rating. • Table. • Repeating group. • Calculated field.

28. FORM SECTIONS Forms can contain sections. Example: School Inspection:
29. School Information.
30. Infrastructure.
31. PWD.
32. Food.
33. Education.
34. Final Remarks.

29. CONDITIONAL QUESTIONS Support rules. Example: IF: Building damaged = YES THEN: Show: • Damage type. • Damage severity. • Damage photo. • Repair estimate. Otherwise hide these fields. Create a visual condition builder.

30. REPEATING GROUPS For Census: Household: Number of members = 6 Automatically create: Person 1 Person 2 Person 3 Person 4 Person 5 Person 6. Support nested repeating data where required.

31. FORM VALIDATION Each question can have: • Required. • Minimum. • Maximum. • Length. • Regex. • Allowed options. • Dependency. • Evidence requirement. • GPS requirement. Validation must happen: Frontend + Backend Never trust frontend validation alone.

32. FORM VERSIONING Forms must be versioned. Example: Form v1 Form v2 Historical submissions remain associated with their original form version. Changing a form must not change old submissions.

33. CAMPAIGN FORM Each phase can have its own form. Example: Campaign: Census 2027 Phase 1: Form A Phase 2: Form B Phase 3: Form C

34. FIELD OFFICER MOBILE APP Build a mobile-first PWA. Field employee dashboard: Campaigns → Active Phase → Assigned Area → Assigned Tasks → Completed → Pending → Corrections → Drafts → Sync → Notifications

35. FIELD TASK Each task contains: • Task ID. • Campaign. • Phase. • Target. • Geographic location. • Assigned team. • Assigned employee. • Deadline. • Priority. • Status. • Instructions.

36. TASK STATUS Use: • Not Started. • Assigned. • Accepted. • In Progress. • Draft. • Submitted. • Under Verification. • Correction Required. • Resubmitted. • Approved. • Rejected. • Reassigned. • Overdue. • Completed.

37. FIELD DATA COLLECTION Field officer should be able to: • Open task. • Start task. • Fill form. • Save draft. • Resume later. • Capture GPS. • Capture image. • Upload video. • Add remarks. • Submit.

38. GPS When configured: Capture: • Latitude. • Longitude. • Accuracy. • Timestamp. Optionally calculate distance from target location. Configurable: • Warning. • Supervisor review. • Block submission.

39. PHOTO Support: • Camera. • Gallery. • Multiple images. • Compression. • Preview. • Retake. Associate image with: • Campaign. • Phase. • Task. • Question. • Employee.

40. VIDEO Support: • Record. • Select. • Preview. • Upload. • Progress. • Retry. • Maximum size. • Maximum duration. Use object storage. Do not store large videos directly in PostgreSQL.

41. OFFLINE MODE Mobile application must work with poor connectivity. Use: • PWA. • IndexedDB. • Local draft. • Offline task list. • Sync queue. Status: Online Offline Syncing Synced Failed.

42. OFFLINE CONFLICT MANAGEMENT If the same record changes from multiple sources: Do not silently overwrite. Create conflict: Conflict requires review. Maintain version history.

43. SUBMISSION Before final submission: Show review page. Example: Required fields: ✓ GPS: ✓ Required images: ✓ Validation: ✓ Then: Submit Server returns: Submission ID. Never show successful submission before server confirmation.

44. VERIFICATION ENGINE Create configurable workflow. Example: Field Officer → Supervisor → Tehsil Officer → Subdivision Officer → Department Head → District Admin But administrators can configure different levels.

45. VERIFICATION ACTIONS Reviewer can: • Approve. • Reject. • Request correction. • Add comment. • Escalate. • Reassign. • View history.

46. CORRECTION WORKFLOW Example: Reviewer: "Please upload a clear photograph." Status: Correction Required. Employee receives notification. Employee edits only permitted fields. Resubmits. Reviewer receives notification.

47. DATA VERSIONING Every submission must preserve: • Version. • Answers. • Files. • GPS. • User. • Timestamp. • Changes. • Reason. Never destroy historical versions.

48. FINAL APPROVAL Only approved records should be included in final results when the campaign requires final approval. Allow reports to distinguish: • Preliminary. • Submitted. • Verified. • Final Approved.

49. DATA QUALITY ENGINE Create automatic quality checks. Examples: • Duplicate household. • Duplicate task. • Missing GPS. • Impossible values. • Inconsistent totals. • Required evidence missing. • Conflicting phase data. • Unusual completion speed. • Repeated identical GPS coordinates where suspicious. • Excessive submissions in a short time. Flag anomalies for review. Do not automatically accuse an employee of misconduct. Mark: Data Quality Exception

50. EXCEPTION MANAGEMENT Create a central Exception Center. Examples: • Missing household. • Duplicate household. • GPS issue. • Incomplete form. • Conflicting data. • Overdue task. • Employee unavailable. • Team unavailable. • Payment failure. • Sync failure. Admin can assign exceptions.

51. CENSUS 2027 EXAMPLE Create Census 2027 as a sample campaign. Do not invent official Census questions. Use placeholder/configurable forms or officially supplied forms. Example structure: Census 2027 → Phase 1: House Listing → Phase 2: Enumeration → Phase 3: Verification → Phase 4: Correction Each phase has different forms and possibly different workforce.

52. CENSUS GEOGRAPHIC STRUCTURE Support: District → Subdivision → Tehsil → Municipality / Nagar Palika → Ward → Village → Mohalla → Household The actual hierarchy must be configurable.

53. CENSUS JOINT TEAM Example: Team 001 Area: Ward 10 / Mohalla A Members: • Education Department employee. • Revenue Department employee. • Municipal employee. The team visits households within its assigned area.

54. HOUSEHOLD CENSUS FLOW Team opens: Household HH-000123 System displays: • Location. • Address. • Previous phase information if authorized. • Current phase form. Team collects required information. Submits. Result goes through configured verification workflow.

55. CENSUS MULTI-PHASE WORKLOAD Support distributing work over multiple phases to reduce employee workload. Example: Phase 1: Employee Group A Phase 2: Employee Group B Phase 3: Employee Group C Or the same employees can participate in multiple phases. The system must support both.

56. PAYMENT/HONORARIUM ENGINE Create a dedicated payment module. IMPORTANT: Never hard-code government payment amounts. Payment amounts must come from authorized configurable rules based on the applicable government order/guideline.

57. PAYMENT RULE Payment rule fields: • Campaign. • Phase. • Role. • Department if applicable. • Duty type. • Calculation method. • Amount/rate. • Effective date. • Government order reference. • Version. • Approval status.

58. PAYMENT CALCULATION Possible calculation models: • Fixed amount. • Per day. • Per task. • Per approved household. • Role-based. • Phase-based. • Component-based. Do not assume these are legally applicable. The administrator configures the permitted calculation method according to official rules.

59. PAYMENT ELIGIBILITY Example: Assignment ↓ Duty completed ↓ Required work completed ↓ Submission accepted/approved ↓ Eligibility generated ↓ Payment approval ↓ Payment processing ↓ Paid Exact rules must be configurable.

60. EMPLOYEE PAYMENT DASHBOARD Employee sees: Campaign: Census 2027 Phase: Phase 1 Duty: Completed Eligibility: Eligible Payment: ₹XXXX Status: Pending / Approved / Processing / Paid. Sensitive financial information must be protected.

61. PAYMENT STATUS Statuses: • Not Eligible. • Pending Eligibility. • Eligible. • Pending Approval. • Approved. • Processing. • Paid. • Failed. • Returned. • On Hold. • Disputed.

62. PAYMENT REMINDERS If payment is pending: Send: • In-app notification. • SMS where configured. • Email where configured. Example: Your approved campaign duty payment is still pending processing. Do not make unverified claims about payment timing.

63. PAYMENT EXCEPTIONS Support: • Failed payments. • Incorrect records. • Missing approval. • Duplicate payment prevention. • Hold. • Retry. • Resolution. Maintain complete audit trail.

64. PAYMENT DUPLICATE PREVENTION Prevent duplicate payment for: Employee + Campaign + Phase + Duty unless explicitly allowed by an authorized adjustment process.

65. ATTENDANCE / DUTY PROOF Where required by campaign rules, support duty attendance. Possible methods: • Start duty. • End duty. • GPS. • Team leader confirmation. • Supervisor approval. • Task completion. Do not assume attendance equals payment eligibility. Make it configurable.

66. TRAINING Track: • Training assigned. • Training completed. • Training date. • Training material. • Assessment. • Certification. A campaign phase can optionally require training before assignment.

67. GUIDELINES / DOCUMENTS Campaign administrators can upload: • Government orders. • Guidelines. • SOPs. • Training documents. • Circulars. • Forms. • Payment orders. Documents should be versioned.

68. NOTIFICATION ENGINE Support: • In-app. • SMS. • Email. • Push notifications. Notifications: • New task. • New campaign. • Phase starting. • Deadline. • Overdue. • Correction. • Approval. • Reassignment. • Reserve activation. • Payment update.

69. ESCALATION ENGINE Create configurable escalation. Example: Task overdue by 2 days: → Supervisor notification. Overdue by 4 days: → Tehsil Officer. Overdue by 7 days: → District Admin. The escalation schedule must be configurable.

70. REMINDER ENGINE Support scheduled reminders. Examples: 7 days before deadline. 3 days before. 1 day before. Due date. Overdue. Payment pending for X days.

71. DISTRICT COMMAND DASHBOARD Create a professional command center. Show: Campaigns Total. Active. Completed. Delayed. Workforce Total. Assigned. Available. Reserve. Unavailable. Tasks Total. Completed. Pending. Overdue. Correction. Verification Submitted. Under review. Approved. Rejected. Payment Eligible. Approved. Paid. Pending. Failed.

72. GEOGRAPHIC DRILL-DOWN Dashboard: District ↓ Subdivision ↓ Tehsil ↓ Village/Ward ↓ Mohalla ↓ Household At every level: • Total. • Assigned. • Completed. • Pending. • Verified. • Exceptions.

73. MAP Provide interactive map. Show: • Assigned areas. • Completed targets. • Pending targets. • Exceptions. • GPS submissions where authorized. Use clustering for large datasets. Do not attempt to render millions of points simultaneously.

74. DEPARTMENT DASHBOARD Department Head sees: • Campaign participation. • Employees. • Teams. • Workload. • Completion. • Verification. • Exceptions. • Payment. Only authorized department data.

75. SUBDIVISION / TEHSIL DASHBOARD Show local progress. Example: Tehsil A: Targets: 100,000 Completed: 92,000 Pending: 8,000 Completion: 92%

76. TEAM DASHBOARD Team Leader sees: • Members. • Assigned targets. • Completed. • Pending. • Corrections. • Overdue. • Sync status.

77. EMPLOYEE DASHBOARD Employee sees: • My campaigns. • My phases. • My tasks. • My progress. • Corrections. • Notifications. • Payment. • Guidelines.

78. REPORTING ENGINE Create configurable reports. Reports: • Campaign. • Phase. • Department. • Employee. • Team. • Geography. • Target entity. • Verification. • Exception. • Payment. • Workforce. • Productivity.

79. REPORT FILTERS Filters: • Campaign. • Phase. • Date. • Department. • Employee. • Team. • District. • Subdivision. • Tehsil. • Village. • Ward. • Mohalla. • Status.

80. EXPORT Support: • Excel. • CSV. • PDF. Large reports must be generated asynchronously.

81. REPORT SCHEDULING Allow authorized users to schedule reports. Example: Every day at 6 PM: District Campaign Progress Report Send to authorized users.

82. DATA ACCESS CONTROL Use: RBAC + Geographic Scope + Department Scope + Campaign Scope Example: Field Officer: Only assigned tasks. Tehsil Officer: Authorized tehsil. Department Head: Authorized department. District Admin: District-wide. Never rely only on frontend restrictions.

83. SUPER ADMIN Super Admin manages: • Districts. • Departments. • Users. • Roles. • Permissions. • System settings. • Master data. • Integrations.

84. DISTRICT ADMIN District Admin can: • Create campaigns. • Create phases. • Create forms. • Select departments. • Manage workforce. • Create teams. • Assign areas. • Assign tasks. • Configure verification. • Configure payment rules where authorized. • Monitor progress. • Approve/review data. • Generate reports.

85. DEPARTMENT HEAD Can: • View department campaigns. • Manage department workforce. • Review submissions. • Verify data. • Monitor department performance. • Generate authorized reports.

86. FIELD OFFICER Can: • Login. • View assigned duties. • Collect field data. • Capture GPS. • Capture media. • Save drafts. • Submit. • Correct. • Resubmit. • View payment status. • View guidelines.

87. PAYMENT OFFICER Can: • Review eligibility. • Approve payment. • Process payment. • View failures. • Retry authorized payments. • Generate payment reports. Do not give payment officers unnecessary household-data access.

88. SYSTEM SECURITY Implement: • Password hashing. • Secure authentication. • OTP. • Session security. • JWT or secure session architecture. • Refresh token rotation where applicable. • Rate limiting. • API authorization. • Input validation. • File validation. • Secure headers. • CORS. • CSRF protection where applicable. • SQL injection protection. • XSS protection. • Audit logs.

89. DATA PRIVACY Collect only officially required information. Sensitive information should have: • Strict access control. • Encryption where appropriate. • Audit logs. • Retention rules. • Export restrictions. Do not display sensitive household/person information on public dashboards.

90. AUDIT LOG Record every important operation. Examples: • Login. • OTP. • Campaign creation. • Phase creation. • Form changes. • Employee assignment. • Team creation. • Household assignment. • Submission. • Correction. • Approval. • Reassignment. • Reserve activation. • Payment calculation. • Payment approval. • Payment processing. • Export. Audit log should be immutable for normal users.

91. SYSTEM LOGGING Use structured application logs. Separate: • Application logs. • Security logs. • Audit logs. • Error logs. Do not expose internal errors to users.

92. DATABASE Use: PostgreSQL ORM: Prisma Design a normalized schema. Important entities: • State. • District. • Department. • OrganizationNode. • GeographicNode. • User. • Employee. • Role. • Permission. • Campaign. • CampaignPhase. • CampaignDepartment. • CampaignGeography. • TargetEntity. • Household. • Person. • Team. • TeamMember. • ReserveEmployee. • Task. • TaskAssignment. • Form. • FormVersion. • FormSection. • FormQuestion. • FormOption. • FormCondition. • Submission. • SubmissionVersion. • SubmissionAnswer. • SubmissionFile. • GPSRecord. • Verification. • CorrectionRequest. • Exception. • PaymentRule. • PaymentRuleVersion. • EmployeePayment. • PaymentComponent. • PaymentTransaction. • Notification. • GuidelineDocument. • Training. • AuditLog. • Report. • ReportJob. Use appropriate: • Foreign keys. • Unique constraints. • Indexes. • Soft deletion where appropriate. • Timestamps.

93. DATA RETENTION Build configurable retention policies. Different records may have different retention requirements. Do not automatically delete official records without an authorized retention policy.

94. BACKUP Design: • Automated database backups. • Point-in-time recovery where supported. • Object storage backup. • Backup monitoring. • Restore testing.

95. DISASTER RECOVERY Document: • Recovery procedure. • Backup restoration. • Database recovery. • File recovery. • Queue recovery. • Disaster scenarios.

96. SCALABILITY Design for: • 50,000+ employees. • Millions of targets. • Millions of submissions. • Large file uploads. • Thousands of concurrent mobile users. Use: • Pagination. • Cursor pagination where appropriate. • Database indexes. • Redis. • Queue workers. • Object storage. • Background jobs. • Horizontal scaling. • Database connection pooling.

97. BACKGROUND JOB SYSTEM Use: Redis + BullMQ or equivalent. Jobs: • Report generation. • Excel export. • PDF generation. • Notifications. • SMS. • Email. • Image processing. • Video processing. • Payment processing integration. • Reminder jobs. • Escalation. • Data aggregation.

98. FILE STORAGE Use: • S3-compatible storage. Store only metadata in PostgreSQL. Metadata: • File ID. • Name. • Type. • Size. • Storage path. • Upload user. • Campaign. • Phase. • Task. • Question. • Timestamp. Use signed URLs for private files.

99. MOBILE PERFORMANCE Optimize for: • Low-end Android devices. • Slow networks. • Limited storage. • Intermittent connectivity. Avoid unnecessary animations. Keep forms lightweight. Compress images. Use resumable uploads where practical.

100. ACCESSIBILITY Support: • High contrast. • Large touch targets. • Keyboard navigation. • Screen readers. • Proper labels. • Accessible validation messages.

101. USER INTERFACE Admin desktop: Sidebar → Dashboard → Campaigns → Phases → Workforce → Teams → Geography → Targets → Forms → Tasks → Verification → Payments → Reports → Maps → Notifications → Audit Logs → Settings Field mobile: Home My Campaigns My Tasks Corrections Notifications Payment Guidelines Profile

102. DESIGN STYLE Use a professional government administration design. Primary: Navy/blue. Secondary: White/gray. Use: • Tables. • Cards. • Status badges. • Charts. • Maps. • Progress bars. Avoid excessive decorative UI. Prioritize usability.

103. BULK OPERATIONS Admin must be able to: • Import employees. • Import geography. • Import target entities. • Assign teams in bulk. • Reassign tasks in bulk. • Activate reserve employees in bulk. • Generate reports in bulk. Always show confirmation before large operations.

104. BULK OPERATION SAFETY For every bulk action:
105. Preview.
106. Validate.
107. Show number of affected records.
108. Confirm.
109. Execute.
110. Show result.
111. Provide error report.
112. Record audit event.

105. SEARCH Global search across authorized data: • Campaign. • Employee. • Team. • Household. • Institution. • Task. • Submission. • Geographic area.

106. DUPLICATE DETECTION Detect: • Duplicate employee. • Duplicate target. • Duplicate household. • Duplicate task. • Duplicate assignment. • Duplicate payment. Do not automatically delete records. Flag them for review.

107. NOTIFICATION PREFERENCES Allow users to configure permitted notification preferences. However, mandatory government alerts cannot be disabled if configured as mandatory.

108. API ARCHITECTURE Use a clean REST API or equivalent. Organize APIs by module: /auth /users /employees /departments /geography /campaigns /phases /teams /targets /tasks /forms /submissions /verifications /exceptions /payments /notifications /reports /audit /files

109. API DOCUMENTATION Generate: OpenAPI / Swagger Document: • Authentication. • Request. • Response. • Errors. • Permissions.

110. ERROR HANDLING Use consistent API responses. Example: { "success": false, "error": { "code": "VALIDATION_ERROR", "message": "Required fields are missing." } } Never expose: • Database errors. • Stack traces. • Secrets. • Internal infrastructure details.

111. FRONTEND STATE Use an appropriate state-management/data-fetching strategy. Use: • Server-side fetching where appropriate. • Query caching. • Optimistic updates only when safe. • Offline state.

112. OFFLINE DATA SECURITY Do not store unnecessary sensitive personal data permanently on the device. Encrypt/local-protect sensitive offline storage where practical. Provide device/session expiration.

113. SESSION SECURITY Support: • Session timeout. • Device/session management. • Logout all devices where authorized. • Token revocation. • Suspicious login detection.

114. OTP SECURITY OTP: • Expiration. • Rate limiting. • Attempt limit. • Resend cooldown. • Secure storage. • Audit logging. Never store OTP in plain text longer than necessary.

115. LOGIN Support: Mobile Number → OTP for initial verification → Password creation Then: Mobile Number → Password → Dashboard Forgot password: Mobile → OTP → New Password

116. GOVERNMENT INTEGRATIONS Build integration interfaces rather than hard-code external systems. Possible future integrations: • SMS gateway. • Government employee master database. • Official GIS. • Payment/treasury system. • Identity/authentication system. • Email. • Notification gateway. Use adapters/interfaces so providers can be changed.

117. NO FAKE INTEGRATIONS If a real government API is not available: Use a clearly marked development/mock adapter. Do not pretend that a fake integration is real.

118. PAYMENT INTEGRATION Payment processing should initially support: Manual/administrative status and be architected for future integration with an authorized government payment/treasury system. Do not invent a government payment API.

119. IMPORT/EXPORT SECURITY Exports must respect authorization. Do not allow field officers to export all district data. Sensitive exports should require additional authorization where appropriate. Log every export.

120. DATA QUALITY DASHBOARD Show: • Missing data. • Invalid data. • Duplicate data. • GPS exceptions. • Correction rates. • Rejection rates. • Unusual activity.

121. PRODUCTIVITY METRICS Show: • Tasks completed per day. • Average task duration. • Completion rate. • Correction rate. • Approval rate. • Overdue rate. Do not use productivity metrics as automatic disciplinary conclusions.

122. CAMPAIGN TEMPLATES Allow administrators to save: Campaign Template Example: School Inspection Template. When creating a new campaign: Use Template Then modify: • Form. • Departments. • Geography. • Workforce. • Dates. • Payment.

123. FORM TEMPLATE LIBRARY Allow reusable forms. Examples: • Inspection form. • Survey form. • Household form. • Verification form. Forms must remain versioned.

124. WORKFLOW TEMPLATE Allow reusable workflows. Example: Field Officer → Supervisor → Department Head → District Admin. Save as: Standard Inspection Workflow.

125. PAYMENT TEMPLATE Allow authorized users to reuse payment structures. Example: Field Duty Payment Template. But each campaign/phase must reference the exact applicable rule/version.

126. CAMPAIGN PAUSE Admin can pause a campaign. When paused: • No new tasks can start. • Existing drafts remain safe. • Admin can resume later. Clearly display: Campaign Paused.

127. CAMPAIGN EXTENSION Authorized admin can extend deadline. Require: • New date. • Reason. • Approval if configured. Record audit history.

128. TASK REASSIGNMENT Allow: Employee A → Employee B Reason: Employee unavailable. Maintain full history.

129. TEAM CHANGE Allow adding/removing team members during campaign with authorization. Do not rewrite old historical assignments.

130. TARGET REASSIGNMENT If a household/institution is reassigned: Maintain: Old Team → New Team Reason Date Authorized By

131. FINALIZATION When a phase is finalized: • Prevent normal editing. • Allow authorized correction workflow only. • Lock official result. • Preserve historical versions.

132. CAMPAIGN CLOSURE When campaign is completed: • Lock operational changes. • Finalize reports. • Finalize payment eligibility. • Preserve audit logs. • Archive according to retention policy.

133. REAL-LIFE CENSUS 2027 DEMO Create development demo: Campaign: Census 2027 District: Demo District Departments: • Revenue. • Education. • Municipal Administration. • Panchayat. Create sample: • 2 subdivisions. • 4 tehsils. • 3 municipalities. • 10 villages. • 20 wards. • 50 mohallas. • 500 households. • 100 employees. • 20 teams. • 5 reserve teams. Create: Phase 1: House Listing Phase 2: Enumeration Phase 3: Verification Use sample placeholder questions. Clearly label: DEMO DATA — NOT OFFICIAL CENSUS DATA

134. END-TO-END DEMO Demonstrate: District Admin → Creates Census campaign → Creates Phase 1 → Selects departments → Imports employees → Creates joint teams → Assigns geography → Loads target households → Creates Phase 1 form → Configures verification → Configures payment rule → Launches phase Field Team → Logs in → Views households → Opens household → Completes form → Captures GPS → Saves draft → Submits Reviewer → Reviews → Requests correction Field Team → Corrects → Resubmits Reviewer → Approves System → Generates final result → Generates payment eligibility → Shows payment status District Admin → Views dashboard → Drills down to household → Views map → Generates Excel/PDF → Views audit history.

135. TESTING Create: Unit Tests For: • Assignment. • Permissions. • Form validation. • GPS. • Payment calculation. • Workflow. Integration Tests For: • Authentication. • Campaign. • Teams. • Forms. • Submission. • Verification. • Payment. E2E Tests Test complete campaign lifecycle.

136. LOAD TESTING Test realistic loads. At minimum test: • 50,000 employees. • Large task volumes. • Large submission volumes. • Concurrent mobile users. • Large report generation. • Large file uploads. Identify bottlenecks.

137. DATABASE INDEXING Create indexes for frequently queried: • Employee ID. • Mobile. • Campaign ID. • Phase ID. • Team ID. • Geographic ID. • Target ID. • Task status. • Submission status. • Payment status. • Created date. Review query plans for large tables.

138. ARCHITECTURE Preferred stack: Frontend Next.js React TypeScript Tailwind CSS shadcn/ui PWA IndexedDB Backend NestJS TypeScript Database PostgreSQL Prisma Cache / Queue Redis BullMQ Storage S3-compatible storage Maps Provider abstraction supporting: OpenStreetMap / Mapbox / Google Maps

139. PROJECT STRUCTURE Use a clean modular architecture. Example: /apps /web /api /packages /ui /types /config /validation /infrastructure /docs /tests Keep business logic separate from UI.

140. ENVIRONMENT VARIABLES Create: .env.example Include: DATABASE_URL REDIS_URL JWT_SECRET S3_ENDPOINT S3_ACCESS_KEY S3_SECRET_KEY S3_BUCKET SMS_PROVIDER SMS_API_KEY SMS_SENDER_ID EMAIL_PROVIDER EMAIL_API_KEY MAP_PROVIDER MAP_API_KEY Never commit real secrets.

141. DOCKER Provide: Dockerfile docker-compose.yml Services: • Web. • API. • PostgreSQL. • Redis. • Object storage for local development.

142. DEVELOPMENT README Provide complete instructions:
143. Install dependencies.
144. Configure .env.
145. Start PostgreSQL.
146. Start Redis.
147. Run migrations.
148. Seed database.
149. Start backend.
150. Start frontend.
151. Login using demo credentials.
152. Run tests.

143. SEED DATA Create realistic but clearly fake development data. Include: • Admin. • Department Heads. • Supervisors. • Field Officers. • Reserve employees. • Departments. • Geographic hierarchy. • Teams. • Households. • Campaigns. • Phases. • Forms. • Tasks. Never use real personal information.

144. DEMO CREDENTIALS Provide development-only demo accounts. Example: District Admin Department Head Supervisor Field Officer Payment Officer Clearly mark: DEVELOPMENT ONLY Do not use these credentials in production.

145. IMPORTANT GOVERNMENT DATA RULE Do not invent: • Official Census questions. • Government payment amounts. • Government orders. • Government employee records. • Official geographic datasets. • Government APIs. • Official Census procedures. Where official information is unavailable, create: CONFIGURABLE PLACEHOLDERS and clearly label them.

146. IMPORTANT DESIGN RULE Do not create separate applications for: • Census. • School inspection. • Road survey. • Flood survey. Instead create one: District Campaign Platform Then: Campaign Type: Census Campaign: Census 2027 Phase: House Listing This makes the platform reusable.

147. MOST IMPORTANT ARCHITECTURAL MODULES The application must be built around these engines:
148. Campaign Engine Campaigns and phases.
149. Organization Engine Departments and hierarchy.
150. Geography Engine District/tehsil/village/ward/mohalla.
151. Workforce Engine Employees and availability.
152. Team Engine Joint teams and reserve teams.
153. Target Entity Engine Households, schools, roads, etc.
154. Assignment Engine Assign targets to teams/employees.
155. Form Engine Dynamic forms and versions.
156. Field Data Engine Mobile data collection.
157. Offline Sync Engine Mobile offline operation.
158. Verification Engine Review and approval.
159. Exception Engine Data quality and operational exceptions.
160. Payment Engine Configurable government-guideline-based payment.
161. Notification Engine SMS/email/push/in-app.
162. Reporting Engine Dashboards and reports.
163. Audit Engine Complete history.

148. DEVELOPMENT ORDER Do not attempt to create the entire application as disconnected pages. Build in this order: Phase A — Foundation • Architecture. • Database. • Authentication. • RBAC. • Organization. • Geography. Phase B — Campaign • Campaign. • Phase. • Department. • Workforce. • Team. Phase C — Target & Assignment • Target entities. • Household. • Geographic assignment. • Task engine. • Workload. Phase D — Forms • Form builder. • Dynamic questions. • Conditions. • Repeating groups. • Validation. • Versioning. Phase E — Mobile • Field officer UI. • Offline. • GPS. • Image. • Video. • Sync. Phase F — Workflow • Verification. • Correction. • Resubmission. • Approval. • Exceptions. Phase G — Payment • Payment rules. • Eligibility. • Approval. • Status. • Reminders. • Exceptions. Phase H — Intelligence • Dashboards. • Maps. • Analytics. • Reports. • Exports. Phase I — Production • Security. • Testing. • Load testing. • Monitoring. • Backups. • Disaster recovery. • Docker. • Documentation.

149. FINAL ACCEPTANCE CRITERIA The project is considered complete only when a real end-to-end flow works: District Admin → creates campaign → creates multiple phases → selects departments → imports workforce → creates joint teams → creates reserve teams → assigns geography → loads target entities → creates phase-specific dynamic form → creates verification workflow → configures authorized payment rule → launches campaign ↓ Field Team → logs in on mobile → receives assigned area → sees assigned targets → visits target → fills form → captures GPS where required → captures media where required → works offline if necessary → synchronizes → submits ↓ Reviewer → receives submission → verifies → requests correction ↓ Field Team → corrects → resubmits ↓ Reviewer → approves ↓ System → finalizes result → calculates authorized payment eligibility → tracks payment → sends notifications ↓ District Admin → sees real-time progress → drills down geographically → views maps → views department/team/employee performance → views exceptions → views payment status → generates reports → exports authorized data → reviews audit history.

150. FINAL INSTRUCTION TO THE AI DEVELOPER Do not build a toy project. Do not build only frontend screens. Do not use hard-coded arrays for core business data. Do not make fake buttons. Do not create disconnected demo pages. Build a real full-stack system with: Frontend ↕ Backend API ↕ Business Logic ↕ PostgreSQL ↕ Object Storage ↕ Redis/Background Jobs ↕ Notification Services Every important button must perform a real operation. Every important record must be persisted. Every permission must be enforced on the backend. Every official submission must be versioned. Every important change must be audited. Every large operation must be designed for scale. Every mobile workflow must consider poor connectivity. Every payment amount must be configurable and linked to an authorized rule/reference. Every campaign must be configurable. Every phase must be independently configurable. Every form must be dynamically configurable. Every organization/geographic hierarchy must be configurable. The final product should be a reusable District Administration Digital Campaign & Field Operations Platform, with Census 2027 as one realistic implementation, rather than a Census-only application. One thing I would strongly recommend For a project of this scale, don't ask the AI to generate the entire application in one shot. Give it the master prompt above, then make it work module-by-module, starting with the database and architecture. The most important foundation is: Organization → Geography → Workforce → Campaign → Phase → Team → Target → Task → Form → Submission → Verification → Result → Payment If that data model is correct, the rest of the application can evolve without needing to rebuild it later