지자체 캠페인 및 데이터 수집 기획

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:
Scho

출처 · prompts.chat 공개 프롬프트 모음 · 작성 aarif khatri — CC0(저작권 포기)로 공개된 원문을 그대로 싣습니다. 한국어 제목 · 설명은 AI 번역이며, 실행 결과는 아직 없습니다.