지자체 현장 조사나 인구주택총조사 등 대규모 행정 관리 시스템의 요구사항을 정의할 때 사용합니다.
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. ______________________________
출처 · prompts.chat · Create Project — 원문은 출처에 게시된 그대로이며, 권리는 원작자에게 있습니다.
Gemini로 프롬프트를 실행해 생성한 화면입니다. 화면 안에서 직접 조작하실 수 있습니다.
지자체의 대규모 현장 캠페인(인구조사, 시설 점검 등)을 설계하고 운영할 수 있는 통합 관리 플랫폼입니다. 부서 간 협업, 지리적 구역 할당, 동적 설문 양식 생성 및 현장 인력의 활동비 정산까지 모든 과정을 자동화된 대시보드와 인터랙티브한 UI로 구현했습니다.
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. Census 2027 should be implemented as an example campaign type: TPI 인구조사 2027. Other campaign types: TPI 학교 점검, TPI 도로 조사, TPI 홍수 피해 조사, TPI 마을 설문. Target entities: TPI 가구, TPI 학교, TPI 도로 구간, TPI 의료 시설. Organization: TPI 구청 → TPI 담당 부서 → TPI 팀장 → TPI 현장 조사원. Geographic hierarchy: TPI 광역시 → TPI 자치구 → TPI 행정동 → TPI 통/반. Employee availability: 가용, 배정됨, 업무 중, 휴가, 예비군. Payment: TPI 활동비 정산 시스템.
Gemini로 실행한 결과입니다. 입력 항목에는 국내 환경의 예시값을 적용했습니다(AI 생성 — 사실 확인 필요).
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. Census 2027 should be implemented as an example campaign type: TPI 인구조사 2027. Other campaign types: TPI 학교 점검, TPI 도로 조사, TPI 홍수 피해 조사, TPI 마을 설문. Target entities: TPI 가구, TPI 학교, TPI 도로 구간, TPI 의료 시설. Organization: TPI 구청 → TPI 담당 부서 → TPI 팀장 → TPI 현장 조사원. Geographic hierarchy: TPI 광역시 → TPI 자치구 → TPI 행정동 → TPI 통/반. Employee availability: 가용, 배정됨, 업무 중, 휴가, 예비군. Payment: TPI 활동비 정산 시스템.
지자체의 대규모 현장 캠페인(인구조사, 시설 점검 등)을 설계하고 운영할 수 있는 통합 관리 플랫폼입니다. 부서 간 협업, 지리적 구역 할당, 동적 설문 양식 생성 및 현장 인력의 활동비 정산까지 모든 과정을 자동화된 대시보드와 인터랙티브한 UI로 구현했습니다.