提示词中文站 prompts.chat 中文镜像
首页 全部提示词 Web Development

创建项目

Create Project

文本 @maarifkhatri91 25,372 字符 在 prompts.chat 查看 译文有问题？

中文译文

MASTER AI 软件开发提示词 District Administration — 通用活动管理、外勤作业、调查、核查、报告与支付平台 为 District Administration 构建一个生产级、全栈、企业级 Web 应用程序，可用于创建和运营大规模政府外勤活动。 该平台必须支持涉及以下内容的活动： • 单个部门。 • 多个部门。 • 跨部门联合团队。 • 高级官员。 • 主管。 • 外勤官员。 • 储备/后备员工。 • 机构。 • 村庄。 • 选区。 • Mohalla。 • 家庭。 • 其他可配置的目标实体。 系统必须允许 District Administration 创建活动、将其划分为多个阶段、为每个阶段创建不同表单、将员工和团队分配到地理区域和目标实体、通过移动设备采集外勤数据、通过可配置的层级核查提交内容、请求更正、跟踪最终结果、根据可配置的政府指南计算经授权的值班报酬/酬金，并生成仪表盘和报告。 系统必须是通用的。 不要将应用程序硬编码为仅用于 Census。 Census 2027 应作为一种示例活动类型来实现。 其他活动类型必须能够在不更改核心软件的情况下实现。 示例： • Census 2027。 • 学校检查。 • 医院检查。 • 道路调查。 • 洪水损失调查。 • 村庄调查。 • PDS 检查。 • Anganwadi 检查。 • 基础设施调查。 • 政府计划核查。 • 灾害评估。 • 公众申诉外勤核查。 • 任何未来的地区活动。

  1. 核心业务模型 完整系统应遵循以下结构： 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 每一部分都必须可配置。
  1. 主要目标 应用程序必须解决以下现实世界问题： “District Administration 拥有来自不同部门的数千名员工，并希望在不同地理区域同时开展多个外勤活动，且涉及不同团队、表单、工作量、核查流程、截止日期、支付规则和报告要求。” 该平台应减少基于 Excel/WhatsApp/纸质的手工协调。 它应为 District Administration 提供一个中央指挥系统。
  1. 多个活动 District Administration 必须能够同时运行多个活动。 示例： • Census 2027。 • 学校检查。 • 道路调查。 • 洪水评估。 • 饮用水调查。 每个活动都是独立的。 每个活动可以拥有： • 不同的部门。 • 不同的员工。 • 不同的地理区域。 • 不同的表单。 • 不同的工作流程。 • 不同的截止日期。 • 不同的付款规则。 • 不同的目标实体。 • 不同的汇报结构。
  1. 多阶段活动 每个活动可以有多个阶段。 示例： 2027年人口普查 阶段1 房屋登记 阶段2 住户普查 阶段3 核查 阶段4 更正/重新普查 每个阶段必须能够拥有： • 不同的日期。 • 不同的表单。 • 不同的工作人员。 • 不同的团队。 • 不同的地理分配。 • 不同的指令。 • 不同的工作量。 • 不同的核查工作流程。 • 不同的付款规则。 • 不同的结果。 不要假设所有阶段使用相同的员工或表单。
  1. 活动类型 创建可配置的活动类型。 示例： • 人口普查。 • 检查。 • 调查。 • 核查。 • 普查。 • 监测。 • 评估。 • 灾害响应。 • 基础设施调查。 • 自定义。 管理员可以创建新的活动类型。
  1. 组织层级 组织必须是可配置的。 示例： 地区管理员 → 部门主管 → 分区官员 → 乡级官员 → 街区官员 → 督导员 → 现场团队 → 现场官员 但另一个部门可能有不同的结构。 因此不要硬编码层级。 使用： OrganizationNode 具有可配置的父/子关系。
  1. 地理层级 支持灵活的地理层级。 农村示例： 州 → 地区 → 分区 → 乡 → 街区 → 村庄 → 社区/小村 → 住户 城市示例： 州 → 地区 → 市政/自治市 → 区域 → 选区 → 社区 → 住户 系统必须同时支持两者。 不要假设每个区域都有相同的结构。
  1. 地理主数据 创建地理主数据管理。 管理员可以管理： • 地区。 • 分区。 • 乡。 • 街区。 • 市政。 • 选区。 • 村庄。 • 社区。 • GPS坐标。 • 边界/多边形（如有）。 支持通过以下方式批量导入： • CSV。 • Excel。 • 政府主数据API（如有）。 验证重复的地理记录。
  1. 目标实体引擎 不要将“住户”作为唯一目标。 创建通用的目标实体系统。 可能的实体： • 住户。 • 个人。 • 学校。 • 医院。 • 道路。 • 村庄。 • 商店。 • 安格瓦迪。 • 政府建筑。 • 水源。 • 自定义实体。 示例： 活动： 学校检查 目标： 学校 活动： 人口普查 目标： 住户 活动： 道路调查 目标： 路段。
  1. 实体主记录 每个目标实体应有一个永久的主记录。 示例： 住户ID： HH-000001 学校ID： SCH-000001 道路ID： ROAD-000001 主实体可以有多个活动/阶段提交。 这可以防止重复。
  1. 住户模型 对于普查类活动，支持： 住户 → 住户成员 → 个人记录 住户可以拥有： • 住户 ID。 • 地址。 • 地理层级。 • 门牌号。 • GPS。 • 状态。 • 来源。 • 阶段历史。 个人/人员结构必须支持可变人数。
  1. 员工主数据 创建中央员工数据库。 字段： • 员工 ID。 • 姓名。 • 手机号码。 • 职务。 • 部门。 • 办公室。 • 任职地点。 • 区。 • 分区。 • Tehsil。 • Block。 • 角色。 • 在职状态。 • 可用性。 • 储备状态。 • 培训状态。 员工 ID 应唯一。 手机号码在适用情况下应唯一。
  1. 员工批量导入 支持导入数千名员工。 格式： • Excel。 • CSV。 导入前： • 校验。 • 检测重复员工 ID。 • 检测重复手机号码。 • 检测缺失字段。 • 检测无效部门。 • 显示行级错误。 允许： 导入有效记录 而不因无效行丢失有效记录。
  1. 员工可用性 员工状态： • 可用。 • 已分配。 • 值班中。 • 休假中。 • 不可用。 • 储备。 • 已激活储备。 • 已释放。 • 已暂停。 活动分配必须检查可用性。 防止不兼容的重复分配。
  1. 多部门活动 一个活动可以包含多个部门。 示例： 学校检查： • 教育。 • PWD。 • 食品。 • 税务。 每个部门可以有不同的职责。
  1. 联合团队 创建团队引擎。 一个团队可以包含来自不同部门的员工。 示例： 团队 001： • 税务员工。 • 教育员工。 • PWD 员工。 每个团队拥有： • 团队 ID。 • 团队负责人。 • 成员。 • 部门。 • 地理责任。 • 活动。 • 阶段。 • 状态。
  1. 团队组建 允许： 手动 管理员选择员工。 自动 系统根据配置的规则创建团队。 规则可以包括： • 团队规模。 • 部门组合。 • 地理区域。 • 职务。 • 技能。 • 可用性。 • 工作量。
  1. 团队负责人 团队负责人可以： • 查看团队成员。 • 查看已分配任务。 • 监控进度。 • 在获得授权的情况下审查团队级工作。 • 报告员工缺勤。 • 请求替换。 • 提交团队报告。 不要仅仅因为某人是团队负责人就自动授予其访问所有数据的权限。 权限仍必须适用。
  1. 储备员工系统 每个大型活动都应支持储备员工。 储备员工可以在必要时替换在岗人员。 原因： • 休假。 • 疾病。 • 调动。 • 紧急情况。 • 行政要求。 • 其他经授权的原因。 工作流： 在岗员工 → 不可用 → 主管报告 → 授权官员批准 → 已选择后备员工 → 后备已激活 → 任务已转移 → 审计记录已创建。
  1. 后备团队 除后备个人外，还支持后备团队。 示例： 活跃团队： 团队 001 后备团队： 团队 R001 如果整个团队无法工作，可以激活后备团队。
  1. 工作量管理 在启动活动阶段之前，显示： 目标实体总数。 所需人力。 可用人力。 后备人力。 每位员工的预期工作量。 每个团队的预期工作量。 示例： 目标： 1,000,000 团队： 10,000 平均： 100 个目标/团队。 允许授权管理员调整分配。
  1. 工作量平衡 支持： • 平均分配。 • 地理分配。 • 随机分配。 • 手动分配。 • 基于技能的分配。 • 工作量平衡。 系统应检测超负荷的员工/团队。 示例： 员工 A： 300 个任务 员工 B： 80 个任务 显示警告。
  1. 随机分配 在需要时支持随机分配。 示例： 10,000 所学校 1,000 名官员 系统随机分配学校。 防止重复分配。 允许管理员在激活前预览。 保留分配历史。
  1. 地理分配 任务可以根据以下条件分配： • 区。 • 分区。 • Tehsil。 • Block。 • 村庄。 • Ward。 • Mohalla。 • GPS 边界。 在可行的情况下支持基于多边形的区域分配。
  1. 活动创建向导 创建一个专业的多步骤向导。 第 1 步 活动详情。 第 2 步 活动类型。 第 3 步 地理范围。 第 4 步 部门。 第 5 步 人力。 第 6 步 团队。 第 7 步 目标实体。 第 8 步 表单。 第 9 步 分配。 第 10 步 验证工作流。 第 11 步 支付规则。 第 12 步 指南/文档。 第 13 步 预览。 第 14 步 启动。
  1. 启动前的活动验证 启动前检查： • 没有目标实体。 • 没有团队。 • 没有官员。 • 缺少表单。 • 缺少必填问题。 • 缺少地理分配。 • 缺少验证工作流。 • 在需要时缺少支付配置。 • 员工冲突。 • 重复分配。 • 人力不足。 • 日期无效。 显示警告和错误。 当缺少关键要求时，不允许启动。
  1. 动态表单构建器 地区管理员必须无需编码即可创建表单。 问题类型： • 短文本。 • 长文本。 • 整数。 • 小数。 • 百分比。 • 货币/金额。 • 日期。 • 日期/时间。 • 是/否。 • 单选。 • 复选框。 • 下拉菜单。 • 多选。 • 图片。 • 多张图片。 • 视频。 • 文件。 • GPS。 • 签名。 • 评分。 • 表格。 • 重复组。 • 计算字段。
  1. 表单部分 表单可以包含多个部分。 示例： 学校检查：
  2. 学校信息。
  3. 基础设施。
  4. 残疾人。
  5. 食品。
  6. 教育。
  7. 最终意见。
  1. 条件问题 支持规则。 示例： 如果： 建筑物受损 = 是 那么： 显示： • 损坏类型。 • 损坏严重程度。 • 损坏照片。 • 维修估价。 否则隐藏这些字段。 创建一个可视化条件构建器。
  1. 重复组 用于人口普查： 家庭： 成员数量 = 6 自动创建： 人员 1 人员 2 人员 3 人员 4 人员 5 人员 6。 在需要时支持嵌套重复数据。
  1. 表单验证 每个问题可以具有： • 必填。 • 最小值。 • 最大值。 • 长度。 • 正则表达式。 • 允许的选项。 • 依赖关系。 • 证据要求。 • GPS 要求。 验证必须发生在： 前端 + 后端 绝不只信任前端验证。
  1. 表单版本控制 表单必须进行版本控制。 示例： 表单 v1 表单 v2 历史提交仍与其原始表单版本关联。 更改表单不得更改旧提交。
  1. 活动表单 每个阶段可以有自己的表单。 示例： 活动： 2027 年人口普查 阶段 1： 表单 A 阶段 2： 表单 B 阶段 3： 表单 C
  1. 外勤人员移动应用 构建一个移动优先的 PWA。 外勤员工仪表板： 活动 → 当前阶段 → 分配区域 → 分配任务 → 已完成 → 待处理 → 更正 → 草稿 → 同步 → 通知
  1. 外勤任务 每个任务包含： • 任务 ID。 • 活动。 • 阶段。 • 目标。 • 地理位置。 • 分配团队。 • 分配员工。 • 截止日期。 • 优先级。 • 状态。 • 说明。
  1. 任务状态 使用： • 未开始。 • 已分配。 • 已接受。 • 进行中。 • 草稿。 • 已提交。 • 验证中。 • 需要更正。 • 已重新提交。 • 已批准。 • 已拒绝。 • 已重新分配。 • 已逾期。 • 已完成。
  1. 外勤数据收集 外勤人员应能够： • 打开任务。 • 开始任务。 • 填写表单。 • 保存草稿。 • 稍后继续。 • 捕获 GPS。 • 拍摄图像。 • 上传视频。 • 添加备注。 • 提交。
  1. GPS 当配置后： 捕获： • 纬度。 • 经度。 • 精度。 • 时间戳。 可选计算与目标位置的距离。 可配置： • 警告。 • 主管审核。 • 阻止提交。
  1. 照片 支持： • 相机。 • 图库。 • 多张图像。 • 压缩。 • 预览。 • 重拍。 将图像关联到： • 活动。 • 阶段。 • 任务。 • 问题。 • 员工。
  1. 视频 支持： • 录制。 • 选择。 • 预览。 • 上传。 • 进度。 • 重试。 • 最大大小。 • 最大时长。 使用对象存储。 不要将大型视频直接存储在 PostgreSQL 中。
  1. 离线模式 移动应用必须能在网络连接较差的情况下工作。 使用： • PWA。 • IndexedDB。 • 本地草稿。 • 离线任务列表。 • 同步队列。 状态： 在线 离线 同步中 已同步 失败。
  1. 离线冲突管理 如果同一条记录从多个来源发生变更： 不要静默覆盖。 创建冲突： 冲突需要审核。 保留版本历史。
  1. 提交 在最终提交之前： 显示审核页面。 示例： 必填字段： ✓ GPS： ✓ 必填图片： ✓ 验证： ✓ 然后： 提交 服务器返回： 提交 ID。 绝不要在服务器确认之前显示提交成功。
  1. 验证引擎 创建可配置的工作流。 示例： 现场官员 → 主管 → Tehsil 官员 → 分区官员 → 部门负责人 → 地区管理员 但管理员可以配置不同的层级。
  1. 验证操作 审核人可以： • 批准。 • 拒绝。 • 要求更正。 • 添加评论。 • 上报。 • 重新分配。 • 查看历史。
  1. 更正工作流 示例： 审核人： “请上传一张清晰的照片。” 状态： 需要更正。 员工收到通知。 员工只能编辑允许编辑的字段。 重新提交。 审核人收到通知。
  1. 数据版本管理 每次提交都必须保留： • 版本。 • 答案。 • 文件。 • GPS。 • 用户。 • 时间戳。 • 变更。 • 原因。 绝不销毁历史版本。
  1. 最终批准 当活动需要最终批准时，只有已批准的记录才应纳入最终结果。 允许报告区分： • 初步。 • 已提交。 • 已验证。 • 最终批准。
  1. 数据质量引擎 创建自动质量检查。 示例： • 重复住户。 • 重复任务。 • 缺少 GPS。 • 不可能的值。 • 总计不一致。 • 缺少必需证据。 • 阶段数据冲突。 • 异常的完成速度。 • 可疑的重复相同 GPS 坐标。 • 短时间内提交过多。 标记异常以供审核。 不要自动指控员工存在不当行为。 标记： 数据质量异常
  1. 异常管理 创建集中式异常中心。 示例： • 缺少住户。 • 重复住户。 • GPS 问题。 • 表单不完整。 • 数据冲突。 • 任务逾期。 • 员工不可用。 • 团队不可用。 • 支付失败。 • 同步失败。 管理员可以分配异常。
  1. 2027 年人口普查示例 创建 2027 年人口普查作为示例活动。 不要编造官方人口普查问题。 使用占位符/可配置表单或官方提供的表单。 示例结构： 2027 年人口普查 → 阶段 1：房屋登记 → 阶段 2：逐户清点 → 阶段 3：核验 → 阶段 4：更正 每个阶段有不同的表单，可能也有不同的工作人员。
  1. 人口普查地理结构 支持： 区 → 分区 → 乡 → 市镇 / Nagar Palika → 选区 → 村 → Mohalla → 户 实际层级必须可配置。
  1. 人口普查联合小组 示例： 小组 001 区域： 第 10 选区 / Mohalla A 成员： • 教育部门员工。 • 税务部门员工。 • 市政员工。 小组在其指定区域内走访住户。
  1. 住户普查流程 小组打开： 住户 HH-000123 系统显示： • 位置。 • 地址。 • 如获授权，显示前一阶段信息。 • 当前阶段表单。 小组采集所需信息。 提交。 结果进入已配置的核验工作流。
  1. 人口普查多阶段工作量分配 支持将工作分配到多个阶段，以减轻员工工作量。 示例： 阶段 1： 员工组 A 阶段 2： 员工组 B 阶段 3： 员工组 C 或者同一批员工可以参与多个阶段。 系统必须同时支持这两种方式。
  1. 报酬/酬金引擎 创建专门的报酬模块。 重要： 绝不硬编码政府报酬金额。 报酬金额必须来自基于适用政府命令/指南的、经授权的可配置规则。
  1. 报酬规则 报酬规则字段： • 行动。 • 阶段。 • 角色。 • 适用时的部门。 • 职责类型。 • 计算方式。 • 金额/费率。 • 生效日期。 • 政府命令引用。 • 版本。 • 审批状态。
  1. 报酬计算 可能的计算模型： • 固定金额。 • 按天。 • 按任务。 • 按已批准的住户。 • 基于角色。 • 基于阶段。 • 基于组成部分。 不要假定这些在法律上适用。 管理员根据官方规则配置允许的计算方式。
  1. 报酬资格 示例： 任务分配 ↓ 职责完成 ↓ 所需工作完成 ↓ 提交被接受/批准 ↓ 生成资格 ↓ 报酬审批 ↓ 报酬处理 ↓ 已支付 确切规则必须可配置。
  1. 员工报酬仪表板 员工看到： 行动： Census 2027 阶段： 阶段 1 职责： 已完成 资格： 符合资格 报酬： ₹XXXX 状态： 待处理 / 已批准 / 处理中 / 已支付。 敏感财务信息必须受到保护。
  1. 报酬状态 状态： • 不符合资格。 • 待确定资格。 • 符合资格。 • 待审批。 • 已批准。 • 处理中。 • 已支付。 • 失败。 • 已退回。 • 暂停。 • 有争议。
  1. 报酬提醒 如果报酬待处理： 发送： • 应用内通知。 • 已配置时通过短信。 • 已配置时通过电子邮件。 示例： 您已获批的活动任务款项仍在等待处理。 不要对付款时间做出未经证实的声明。
  1. 付款异常 支持： • 失败付款。 • 错误记录。 • 缺少审批。 • 防止重复付款。 • 暂扣。 • 重试。 • 解决。 维护完整的审计追踪。
  1. 防止重复付款 防止以下组合的重复付款： 员工 + 活动 + 阶段 + 任务 除非经授权的调整流程明确允许。
  1. 出勤 / 任务证明 在活动规则要求的情况下，支持任务出勤。 可能的方法： • 开始任务。 • 结束任务。 • GPS。 • 团队负责人确认。 • 主管审批。 • 任务完成。 不要假定出勤等同于付款资格。 使其可配置。
  1. 培训 跟踪： • 已分配培训。 • 已完成培训。 • 培训日期。 • 培训材料。 • 评估。 • 认证。 活动阶段可以选择性地要求在分配前完成培训。
  1. 指南 / 文档 活动管理员可以上传： • 政府命令。 • 指南。 • 标准作业程序（SOP）。 • 培训文档。 • 通函。 • 表单。 • 付款命令。 文档应进行版本管理。
  1. 通知引擎 支持： • 应用内。 • 短信。 • 电子邮件。 • 推送通知。 通知： • 新任务。 • 新活动。 • 阶段开始。 • 截止日期。 • 逾期。 • 更正。 • 审批。 • 重新分配。 • 储备激活。 • 付款更新。
  1. 升级引擎 创建可配置的升级。 示例： 任务逾期 2 天： → 主管通知。 逾期 4 天： → Tehsil 官员。 逾期 7 天： → 地区管理员。 升级时间表必须可配置。
  1. 提醒引擎 支持定时提醒。 示例： 截止日期前 7 天。 前 3 天。 前 1 天。 到期日。 逾期。 付款待处理 X 天。
  1. 地区指挥仪表板 创建一个专业的指挥中心。 显示： 活动 总计。 进行中。 已完成。 已延迟。 劳动力 总计。 已分配。 可用。 储备。 不可用。 任务 总计。 已完成。 待处理。 逾期。 更正。 验证 已提交。 审核中。 已批准。 已拒绝。 付款 符合条件。 已批准。 已支付。 待处理。 失败。
  1. 地理下钻 仪表板： 地区 ↓ 分区 ↓ Tehsil ↓ 村庄/选区 ↓ Mohalla ↓ 家庭 在每个层级： • 总计。 • 已分配。 • 已完成。 • 待处理。 • 已验证。 • 异常。
  1. 地图 提供交互式地图。 显示： • 已分配区域。 • 已完成目标。 • 待处理目标。 • 异常。 • 在授权情况下提交 GPS。 对大型数据集使用聚类。 不要尝试同时渲染数百万个点。
  1. 部门仪表板 部门负责人可见： • 活动参与情况。 • 员工。 • 团队。 • 工作量。 • 完成情况。 • 核查。 • 异常。 • 付款。 仅限授权的部门数据。
  1. 分区 / 乡级仪表板 显示本地进度。 示例： Tehsil A： 目标：100,000 已完成：92,000 待处理：8,000 完成率： 92%
  1. 团队仪表板 团队负责人可见： • 成员。 • 已分配目标。 • 已完成。 • 待处理。 • 更正。 • 逾期。 • 同步状态。
  1. 员工仪表板 员工可见： • 我的活动。 • 我的阶段。 • 我的任务。 • 我的进度。 • 更正。 • 通知。 • 付款。 • 指南。
  1. 报表引擎 创建可配置的报表。 报表： • 活动。 • 阶段。 • 部门。 • 员工。 • 团队。 • 地理区域。 • 目标实体。 • 核查。 • 异常。 • 付款。 • 劳动力。 • 生产力。
  1. 报表筛选器 筛选条件： • 活动。 • 阶段。 • 日期。 • 部门。 • 员工。 • 团队。 • 区。 • 分区。 • 乡。 • 村。 • 选区。 • 街区。 • 状态。
  1. 导出 支持： • Excel。 • CSV。 • PDF。 大型报表必须异步生成。
  1. 报表定时 允许授权用户定时生成报表。 示例： 每天下午 6 点： 区活动进度报表 发送给授权用户。
  1. 数据访问控制 使用： RBAC + 地理范围 + 部门范围 + 活动范围 示例： 现场工作人员： 仅限已分配任务。 乡级工作人员： 授权的乡。 部门负责人： 授权的部门。 区管理员： 全区范围。 绝不只依赖前端限制。
  1. 超级管理员 超级管理员管理： • 区。 • 部门。 • 用户。 • 角色。 • 权限。 • 系统设置。 • 主数据。 • 集成。
  1. 区管理员 区管理员可以： • 创建活动。 • 创建阶段。 • 创建表单。 • 选择部门。 • 管理劳动力。 • 创建团队。 • 分配区域。 • 分配任务。 • 配置核查。 • 在授权范围内配置付款规则。 • 监控进度。 • 审批/审核数据。 • 生成报表。
  1. 部门负责人 可以： • 查看部门活动。 • 管理部门劳动力。 • 审核提交内容。 • 核查数据。 • 监控部门绩效。 • 生成授权报表。
  1. 现场工作人员 可以： • 登录。 • 查看已分配职责。 • 采集现场数据。 • 采集 GPS。 • 采集媒体。 • 保存草稿。 • 提交。 • 更正。 • 重新提交。 • 查看支付状态。 • 查看指南。
  1. 支付专员 可以： • 审核资格。 • 批准支付。 • 处理支付。 • 查看失败记录。 • 重试已授权的支付。 • 生成支付报告。 不要给支付专员不必要的家庭数据访问权限。
  1. 系统安全 实施： • 密码哈希。 • 安全认证。 • OTP。 • 会话安全。 • JWT 或安全会话架构。 • 适用时进行刷新令牌轮换。 • 速率限制。 • API 授权。 • 输入验证。 • 文件验证。 • 安全响应头。 • CORS。 • 适用时进行 CSRF 防护。 • SQL 注入防护。 • XSS 防护。 • 审计日志。
  1. 数据隐私 仅收集官方要求的信息。 敏感信息应具备： • 严格的访问控制。 • 适当情况下的加密。 • 审计日志。 • 保留规则。 • 导出限制。 不要在公开仪表板上显示敏感的家庭/个人 information。
  1. 审计日志 记录每一项重要操作。 示例： • 登录。 • OTP。 • 活动创建。 • 阶段创建。 • 表单变更。 • 员工分配。 • 团队创建。 • 家庭分配。 • 提交。 • 更正。 • 批准。 • 重新分配。 • 储备激活。 • 支付计算。 • 支付批准。 • 支付处理。 • 导出。 审计日志对普通用户应不可更改。
  1. 系统日志 使用结构化应用日志。 分离： • 应用日志。 • 安全日志。 • 审计日志。 • 错误日志。 不要向用户暴露内部错误。
  1. 数据库 使用： PostgreSQL ORM： Prisma 设计规范化 schema。 重要实体： • 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。 使用适当的： • 外键。 • 唯一约束。 • 索引。 • 适当情况下的软删除。 • 时间戳。
  1. 数据保留 构建可配置的保留策略。 不同记录可能有不同的保留要求。 未经授权的保留策略，不要自动删除官方记录。
  1. 备份 设计： • 自动化数据库备份。 • 在支持的情况下进行时间点恢复。 • 对象存储备份。 • 备份监控。 • 恢复测试。
  1. 灾难恢复 记录： • 恢复流程。 • 备份还原。 • 数据库恢复。 • 文件恢复。 • 队列恢复。 • 灾难场景。
  1. 可扩展性 设计目标： • 50,000+ 名员工。 • 数百万个目标。 • 数百万份提交。 • 大文件上传。 • 数千名并发移动用户。 使用： • 分页。 • 在适当情况下使用游标分页。 • 数据库索引。 • Redis。 • 队列工作进程。 • 对象存储。 • 后台任务。 • 水平扩展。 • 数据库连接池。
  1. 后台任务系统 使用： Redis + BullMQ 或同等方案。 任务： • 报告生成。 • Excel 导出。 • PDF 生成。 • 通知。 • 短信。 • 电子邮件。 • 图像处理。 • 视频处理。 • 支付处理集成。 • 提醒任务。 • 升级。 • 数据聚合。
  1. 文件存储 使用： • 兼容 S3 的存储。 仅在 PostgreSQL 中存储元数据。 元数据： • 文件 ID。 • 名称。 • 类型。 • 大小。 • 存储路径。 • 上传用户。 • 活动。 • 阶段。 • 任务。 • 问题。 • 时间戳。 对私有文件使用签名 URL。
  1. 移动端性能 优化目标： • 低端 Android 设备。 • 慢速网络。 • 有限存储空间。 • 间歇性连接。 避免不必要的动画。 保持表单轻量。 压缩图像。 在可行的情况下使用可续传上传。
  1. 无障碍 支持： • 高对比度。 • 大触控目标。 • 键盘导航。 • 屏幕阅读器。 • 正确的标签。 • 无障碍验证消息。
  1. 用户界面 管理端桌面： 侧边栏 → 仪表盘 → 活动 → 阶段 → 劳动力 → 团队 → 地理 → 目标 → 表单 → 任务 → 验证 → 支付 → 报告 → 地图 → 通知 → 审计日志 → 设置 现场移动端： 首页 我的活动 我的任务 更正 通知 支付 指南 个人资料
  1. 设计风格 使用专业的政府行政设计。 主色： 海军蓝/蓝色。 辅助色： 白色/灰色。 使用： • 表格。 • 卡片。 • 状态徽章。 • 图表。 • 地图。 • 进度条。 避免过多的装饰性 UI。 优先考虑可用性。
  1. 批量操作 管理员必须能够： • 导入员工。 • 导入地理数据。 • 导入目标实体。 • 批量分配团队。 • 批量重新分配任务。 • 批量激活储备员工。 • 批量生成报告。 在执行大型操作前始终显示确认。
  1. 批量操作安全 对于每个批量操作：
  2. 预览。
  3. 验证。
  4. 显示受影响记录的数量。
  5. 确认。
  6. 执行。
  7. 显示结果。
  8. 提供错误报告。
  9. 记录审计事件。
  1. 搜索 在授权数据范围内进行全局搜索： • 活动。 • 员工。 • 团队。 • 家庭。 • 机构。 • 任务。 • 提交。 • 地理区域。
  1. 重复检测 检测： • 重复员工。 • 重复目标。 • 重复家庭。 • 重复任务。 • 重复分配。 • 重复付款。 不要自动删除记录。 将其标记以供审核。
  1. 通知偏好 允许用户配置允许的通知偏好。 但是，如果强制性的政府警报被配置为强制性的，则不能禁用。
  1. API 架构 使用干净的 REST API 或等效方案。 按模块组织 API： /auth /users /employees /departments /geography /campaigns /phases /teams /targets /tasks /forms /submissions /verifications /exceptions /payments /notifications /reports /audit /files
  1. API 文档 生成： OpenAPI / Swagger 记录： • 认证。 • 请求。 • 响应。 • 错误。 • 权限。
  1. 错误处理 使用一致的 API 响应。 示例： { "success": false, "error": { "code": "VALIDATION_ERROR", "message": "Required fields are missing." } } 绝不暴露： • 数据库错误。 • 堆栈跟踪。 • 密钥。 • 内部基础设施细节。
  1. 前端状态 使用适当的状态管理/数据获取策略。 使用： • 在适当的情况下进行服务端获取。 • 查询缓存。 • 仅在安全时进行乐观更新。 • 离线状态。
  1. 离线数据安全 不要将不必要的敏感个人数据永久存储在设备上。 在可行的情况下，对敏感的离线存储进行加密/本地保护。 提供设备/会话过期。
  1. 会话安全 支持： • 会话超时。 • 设备/会话管理。 • 在授权的情况下登出所有设备。 • 令牌撤销。 • 可疑登录检测。
  1. OTP 安全 OTP： • 过期。 • 速率限制。 • 尝试次数限制。 • 重发冷却。 • 安全存储。 • 审计日志记录。 绝不在超出必要时间的情况下以明文存储 OTP。
  1. 登录 支持： 手机号码 → 用于初始验证的 OTP → 创建密码 然后： 手机号码 → 密码 → 仪表板 忘记密码： 手机 → OTP → 新密码
  1. 政府集成 构建集成接口，而不是硬编码外部系统。 可能的未来集成： • SMS 网关。 • 政府员工主数据库。 • 官方 GIS。 • 支付/财政系统。 • 身份/认证系统。 • 电子邮件。 • 通知网关。 使用适配器/接口，以便可以更换提供商。
  1. 禁止伪造集成 如果无法使用真实的政府 API： 使用明确标记的开发/模拟适配器。 不要假装伪造的集成是真实的。
  1. 支付集成 支付处理初期应支持： 手动/行政状态 并且其架构应便于未来与经授权的政府支付/财政系统集成。 不要凭空捏造政府支付 API。
  1. 导入/导出安全 导出必须遵守授权。 不允许现场工作人员导出全部地区数据。 敏感导出在适当情况下应需要额外授权。 记录每一次导出。
  1. 数据质量仪表板 显示： • 缺失数据。 • 无效数据。 • 重复数据。 • GPS 异常。 • 更正率。 • 拒绝率。 • 异常活动。
  1. 生产力指标 显示： • 每日完成任务数。 • 平均任务时长。 • 完成率。 • 更正率。 • 批准率。 • 逾期率。 不要将生产力指标用作自动纪律处分的依据。
  1. 活动模板 允许管理员保存： 活动模板 示例： 学校检查模板。 创建新活动时： 使用模板 然后修改： • 表单。 • 部门。 • 地理范围。 • 工作人员。 • 日期。 • 支付。
  1. 表单模板库 允许可复用表单。 示例： • 检查表单。 • 调查表单。 • 住户表单。 • 核实表单。 表单必须保持版本化。
  1. 工作流模板 允许可复用工作流。 示例： 现场工作人员 → 主管 → 部门负责人 → 地区管理员。 保存为： 标准检查工作流。
  1. 支付模板 允许经授权的用户复用支付结构。 示例： 现场执勤支付模板。 但每个活动/阶段必须引用确切适用的规则/版本。
  1. 活动暂停 管理员可以暂停活动。 暂停时： • 不能开始新任务。 • 现有草稿保持安全。 • 管理员可以稍后恢复。 清楚显示： 活动已暂停。
  1. 活动延期 经授权的管理员可以延长截止日期。 要求： • 新日期。 • 原因。 • 如已配置，需审批。 记录审计历史。
  1. 任务重新分配 允许： 员工 A → 员工 B 原因： 员工不可用。 保留完整历史。
  1. 团队变更 允许在活动期间经授权添加/移除团队成员。 不要改写旧的历史分配。
  1. 目标重新分配 如果住户/机构被重新分配： 保留： 旧团队 → 新团队 原因 日期 授权人
  1. 最终确定 当一个阶段被最终确定时： • 阻止常规编辑。 • 仅允许授权更正工作流。 • 锁定官方结果。 • 保留历史版本。
  1. 活动结束 当活动完成时： • 锁定运营变更。 • 最终确定报告。 • 最终确定付款资格。 • 保留审计日志。 • 根据保留策略归档。
  1. 2027 年真实人口普查演示 创建开发演示： 活动： Census 2027 区： Demo District 部门： • Revenue。 • Education。 • Municipal Administration。 • Panchayat。 创建示例： • 2 个分区。 • 4 个 tehsil。 • 3 个市镇。 • 10 个村庄。 • 20 个 ward。 • 50 个 mohalla。 • 500 个家庭。 • 100 名员工。 • 20 个团队。 • 5 个后备团队。 创建： 阶段 1： 房屋登记 阶段 2： 普查登记 阶段 3： 核查 使用示例占位问题。 明确标注： DEMO DATA — NOT OFFICIAL CENSUS DATA
  1. 端到端演示 演示： District Admin → 创建人口普查活动 → 创建阶段 1 → 选择部门 → 导入员工 → 创建联合团队 → 分配地理区域 → 加载目标家庭 → 创建阶段 1 表单 → 配置核查 → 配置付款规则 → 启动阶段 Field Team → 登录 → 查看家庭 → 打开家庭 → 填写表单 → 采集 GPS → 保存草稿 → 提交 Reviewer → 审核 → 请求更正 Field Team → 更正 → 重新提交 Reviewer → 批准 System → 生成最终结果 → 生成付款资格 → 显示付款状态 District Admin → 查看仪表板 → 下钻到家庭 → 查看地图 → 生成 Excel/PDF → 查看审计历史。
  1. 测试 创建： 单元测试 用于： • 分配。 • 权限。 • 表单验证。 • GPS。 • 付款计算。 • 工作流。 集成测试 用于： • 身份验证。 • 活动。 • 团队。 • 表单。 • 提交。 • 核查。 • 付款。 E2E 测试 测试完整的活动生命周期。
  1. 负载测试 测试真实负载。 至少测试： • 50,000 名员工。 • 大任务量。 • 大提交量。 • 并发移动用户。 • 大型报告生成。 • 大型文件上传。 识别瓶颈。
  1. 数据库索引 为频繁查询的字段创建索引： • Employee ID。 • Mobile。 • Campaign ID。 • Phase ID。 • Team ID。 • Geographic ID。 • Target ID。 • Task status。 • Submission status。 • Payment status。 • Created date。 审查大表的查询计划。
  1. 架构 首选技术栈： 前端 Next.js React TypeScript Tailwind CSS shadcn/ui PWA IndexedDB 后端 NestJS TypeScript 数据库 PostgreSQL Prisma 缓存 / 队列 Redis BullMQ 存储 S3 兼容存储 地图 提供商抽象支持： OpenStreetMap / Mapbox / Google Maps
  1. 项目结构 采用清晰的模块化架构。 示例： /apps /web /api /packages /ui /types /config /validation /infrastructure /docs /tests 保持业务逻辑与 UI 分离。
  1. 环境变量 创建： .env.example 包含： 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 绝不提交真实密钥。
  1. DOCKER 提供： Dockerfile docker-compose.yml 服务： • Web。 • API。 • PostgreSQL。 • Redis。 • 用于本地开发的对象存储。
  1. 开发 README 提供完整说明：
  2. 安装依赖。
  3. 配置 .env。
  4. 启动 PostgreSQL。
  5. 启动 Redis。
  6. 运行迁移。
  7. 填充数据库种子数据。
  8. 启动后端。
  9. 启动前端。
  10. 使用演示凭据登录。
  11. 运行测试。
  1. 种子数据 创建真实但明显虚假的开发数据。 包含： • 管理员。 • 部门负责人。 • 主管。 • 外勤人员。 • 储备员工。 • 部门。 • 地理层级。 • 团队。 • 住户。 • 活动。 • 阶段。 • 表单。 • 任务。 绝不使用真实个人信息。
  1. 演示凭据 提供仅用于开发的演示账户。 示例： 地区管理员 部门负责人 主管 外勤人员 付款专员 明确标注： 仅用于开发 不要在生产环境中使用这些凭据。
  1. 重要的政府数据规则 不要编造： • 官方人口普查问题。 • 政府付款金额。 • 政府命令。 • 政府雇员记录。 • 官方地理数据集。 • 政府 API。 • 官方人口普查程序。 在官方信息不可用时，创建： 可配置占位符 并明确标注。
  1. 重要设计规则 不要为以下各项创建独立应用： • 人口普查。 • 学校检查。 • 道路调查。 • 洪水调查。 而是创建一个： 地区活动平台 然后： 活动类型： 人口普查 活动： 2027 年人口普查 阶段： 住房登记 这使平台可复用。
  1. 最重要的架构模块 应用程序必须围绕以下引擎构建：
  2. 活动引擎 活动和阶段。
  3. 组织引擎 部门和层级。
  4. 地理引擎 地区/tehsil/村庄/选区/mohalla。
  5. 劳动力引擎 员工和可用性。
  6. 团队引擎 联合团队和储备团队。
  7. 目标实体引擎 住户、学校、道路等。
  8. 分配引擎 将目标分配给团队/员工。
  9. 表单引擎 动态表单和版本。
  10. 外勤数据引擎 移动数据采集。
  11. 离线同步引擎 移动端离线运行。
  12. 核查引擎 审核和批准。
  13. 异常引擎 数据质量和运营异常。
  14. 支付引擎 可配置的、基于政府指导方针的支付。
  15. 通知引擎 短信/邮件/推送/应用内通知。
  16. 报表引擎 仪表盘和报表。
  17. 审计引擎 完整历史记录。
  1. 开发顺序 不要试图将整个应用程序构建为互不关联的页面。 按以下顺序构建： 阶段 A — 基础 • 架构。 • 数据库。 • 身份验证。 • RBAC。 • 组织。 • 地理。 阶段 B — 活动 • 活动。 • 阶段。 • 部门。 • 劳动力。 • 团队。 阶段 C — 目标与分配 • 目标实体。 • 家庭。 • 地理分配。 • 任务引擎。 • 工作量。 阶段 D — 表单 • 表单构建器。 • 动态问题。 • 条件。 • 重复组。 • 验证。 • 版本控制。 阶段 E — 移动端 • 现场工作人员界面。 • 离线。 • GPS。 • 图像。 • 视频。 • 同步。 阶段 F — 工作流 • 核实。 • 更正。 • 重新提交。 • 审批。 • 异常。 阶段 G — 支付 • 支付规则。 • 资格。 • 审批。 • 状态。 • 提醒。 • 异常。 阶段 H — 智能 • 仪表盘。 • 地图。 • 分析。 • 报表。 • 导出。 阶段 I — 生产 • 安全。 • 测试。 • 负载测试。 • 监控。 • 备份。 • 灾难恢复。 • Docker。 • 文档。
  1. 最终验收标准 只有当真实的端到端流程能够运行时，项目才被视为完成： 地区管理员 → 创建活动 → 创建多个阶段 → 选择部门 → 导入劳动力 → 创建联合团队 → 创建后备团队 → 分配地理 → 加载目标实体 → 创建阶段特定的动态表单 → 创建核实工作流 → 配置授权支付规则 → 启动活动 ↓ 现场团队 → 在移动端登录 → 接收分配区域 → 查看分配的目标 → 访问目标 → 填写表单 → 在需要时采集 GPS → 在需要时采集媒体 → 必要时离线工作 → 同步 → 提交 ↓ 审核员 → 接收提交 → 核实 → 请求更正 ↓ 现场团队 → 更正 → 重新提交 ↓ 审核员 → 批准 ↓ 系统 → 最终确定结果 → 计算授权支付资格 → 跟踪支付 → 发送通知 ↓ 地区管理员 → 查看实时进度 → 按地理下钻 → 查看地图 → 查看部门/团队/员工绩效 → 查看异常 → 查看支付状态 → 生成报表 → 导出授权数据 → 查看审计历史。
  1. 给 AI 开发者的最终指令 不要构建一个玩具项目。 不要只构建前端界面。 不要为核心业务数据使用硬编码数组。 不要制作虚假按钮。 不要创建互不关联的演示页面。 构建一个真实的全栈系统，包含： 前端 ↕ 后端 API ↕ 业务逻辑 ↕ PostgreSQL ↕ 对象存储 ↕ Redis/后台任务 ↕ 通知服务 每个重要的按钮都必须执行真实操作。 每条重要的记录都必须被持久化。 每项权限都必须在后端强制执行。 每一份正式提交都必须有版本管理。 每一项重要变更都必须可审计。 每一项大型操作都必须按规模化来设计。 每一条移动端工作流都必须考虑网络连接不佳的情况。 每一笔付款金额都必须可配置，并关联到一条经授权的规则/依据。 每一个活动都必须可配置。 每一个阶段都必须可独立配置。 每一张表单都必须可动态配置。 每一层组织/地理层级都必须可配置。 最终产品应当是一个可复用的「地区行政数字活动与现场运营平台」，以 2027 年人口普查作为一个真实的落地实现，而不是一个只服务于人口普查的应用。 有一点我强烈建议 对于这种规模的项目，不要让 AI 一次性生成整个应用。先把上面的主提示词给它，然后让它一个模块一个模块地推进，从数据库和架构开始。 最重要的基础是： 组织 → 地理 → 人力 → 活动 → 阶段 → 团队 → 目标 → 任务 → 表单 → 提交 → 核验 → 结果 → 付款 如果这个数据模型是正确的，应用的其余部分就可以持续演进，而不必日后推倒重建。

English original

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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. MULTI-DEPARTMENT CAMPAIGNS A campaign can include multiple departments. Example: School Inspection: • Education. • PWD. • Food. • Revenue. Each department can have different responsibilities.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. GEOGRAPHIC ASSIGNMENT Tasks can be assigned based on: • District. • Subdivision. • Tehsil. • Block. • Village. • Ward. • Mohalla. • GPS boundary. Support polygon-based geographic assignment where feasible.
  1. 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.
  1. 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.
  1. 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.
  1. FORM SECTIONS Forms can contain sections. Example: School Inspection:
  2. School Information.
  3. Infrastructure.
  4. PWD.
  5. Food.
  6. Education.
  7. Final Remarks.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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
  1. 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
  1. FIELD TASK Each task contains: • Task ID. • Campaign. • Phase. • Target. • Geographic location. • Assigned team. • Assigned employee. • Deadline. • Priority. • Status. • Instructions.
  1. TASK STATUS Use: • Not Started. • Assigned. • Accepted. • In Progress. • Draft. • Submitted. • Under Verification. • Correction Required. • Resubmitted. • Approved. • Rejected. • Reassigned. • Overdue. • Completed.
  1. 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.
  1. GPS When configured: Capture: • Latitude. • Longitude. • Accuracy. • Timestamp. Optionally calculate distance from target location. Configurable: • Warning. • Supervisor review. • Block submission.
  1. PHOTO Support: • Camera. • Gallery. • Multiple images. • Compression. • Preview. • Retake. Associate image with: • Campaign. • Phase. • Task. • Question. • Employee.
  1. VIDEO Support: • Record. • Select. • Preview. • Upload. • Progress. • Retry. • Maximum size. • Maximum duration. Use object storage. Do not store large videos directly in PostgreSQL.
  1. 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.
  1. OFFLINE CONFLICT MANAGEMENT If the same record changes from multiple sources: Do not silently overwrite. Create conflict: Conflict requires review. Maintain version history.
  1. 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.
  1. VERIFICATION ENGINE Create configurable workflow. Example: Field Officer → Supervisor → Tehsil Officer → Subdivision Officer → Department Head → District Admin But administrators can configure different levels.
  1. VERIFICATION ACTIONS Reviewer can: • Approve. • Reject. • Request correction. • Add comment. • Escalate. • Reassign. • View history.
  1. CORRECTION WORKFLOW Example: Reviewer: "Please upload a clear photograph." Status: Correction Required. Employee receives notification. Employee edits only permitted fields. Resubmits. Reviewer receives notification.
  1. DATA VERSIONING Every submission must preserve: • Version. • Answers. • Files. • GPS. • User. • Timestamp. • Changes. • Reason. Never destroy historical versions.
  1. 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.
  1. 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
  1. 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.
  1. 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.
  1. CENSUS GEOGRAPHIC STRUCTURE Support: District → Subdivision → Tehsil → Municipality / Nagar Palika → Ward → Village → Mohalla → Household The actual hierarchy must be configurable.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. PAYMENT ELIGIBILITY Example: Assignment ↓ Duty completed ↓ Required work completed ↓ Submission accepted/approved ↓ Eligibility generated ↓ Payment approval ↓ Payment processing ↓ Paid Exact rules must be configurable.
  1. 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.
  1. PAYMENT STATUS Statuses: • Not Eligible. • Pending Eligibility. • Eligible. • Pending Approval. • Approved. • Processing. • Paid. • Failed. • Returned. • On Hold. • Disputed.
  1. 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.
  1. PAYMENT EXCEPTIONS Support: • Failed payments. • Incorrect records. • Missing approval. • Duplicate payment prevention. • Hold. • Retry. • Resolution. Maintain complete audit trail.
  1. PAYMENT DUPLICATE PREVENTION Prevent duplicate payment for: Employee + Campaign + Phase + Duty unless explicitly allowed by an authorized adjustment process.
  1. 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.
  1. TRAINING Track: • Training assigned. • Training completed. • Training date. • Training material. • Assessment. • Certification. A campaign phase can optionally require training before assignment.
  1. GUIDELINES / DOCUMENTS Campaign administrators can upload: • Government orders. • Guidelines. • SOPs. • Training documents. • Circulars. • Forms. • Payment orders. Documents should be versioned.
  1. 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.
  1. 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.
  1. REMINDER ENGINE Support scheduled reminders. Examples: 7 days before deadline. 3 days before. 1 day before. Due date. Overdue. Payment pending for X days.
  1. 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.
  1. GEOGRAPHIC DRILL-DOWN Dashboard: District ↓ Subdivision ↓ Tehsil ↓ Village/Ward ↓ Mohalla ↓ Household At every level: • Total. • Assigned. • Completed. • Pending. • Verified. • Exceptions.
  1. 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.
  1. DEPARTMENT DASHBOARD Department Head sees: • Campaign participation. • Employees. • Teams. • Workload. • Completion. • Verification. • Exceptions. • Payment. Only authorized department data.
  1. SUBDIVISION / TEHSIL DASHBOARD Show local progress. Example: Tehsil A: Targets: 100,000 Completed: 92,000 Pending: 8,000 Completion: 92%
  1. TEAM DASHBOARD Team Leader sees: • Members. • Assigned targets. • Completed. • Pending. • Corrections. • Overdue. • Sync status.
  1. EMPLOYEE DASHBOARD Employee sees: • My campaigns. • My phases. • My tasks. • My progress. • Corrections. • Notifications. • Payment. • Guidelines.
  1. REPORTING ENGINE Create configurable reports. Reports: • Campaign. • Phase. • Department. • Employee. • Team. • Geography. • Target entity. • Verification. • Exception. • Payment. • Workforce. • Productivity.
  1. REPORT FILTERS Filters: • Campaign. • Phase. • Date. • Department. • Employee. • Team. • District. • Subdivision. • Tehsil. • Village. • Ward. • Mohalla. • Status.
  1. EXPORT Support: • Excel. • CSV. • PDF. Large reports must be generated asynchronously.
  1. REPORT SCHEDULING Allow authorized users to schedule reports. Example: Every day at 6 PM: District Campaign Progress Report Send to authorized users.
  1. 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.
  1. SUPER ADMIN Super Admin manages: • Districts. • Departments. • Users. • Roles. • Permissions. • System settings. • Master data. • Integrations.
  1. 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.
  1. DEPARTMENT HEAD Can: • View department campaigns. • Manage department workforce. • Review submissions. • Verify data. • Monitor department performance. • Generate authorized reports.
  1. FIELD OFFICER Can: • Login. • View assigned duties. • Collect field data. • Capture GPS. • Capture media. • Save drafts. • Submit. • Correct. • Resubmit. • View payment status. • View guidelines.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. SYSTEM LOGGING Use structured application logs. Separate: • Application logs. • Security logs. • Audit logs. • Error logs. Do not expose internal errors to users.
  1. 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.
  1. DATA RETENTION Build configurable retention policies. Different records may have different retention requirements. Do not automatically delete official records without an authorized retention policy.
  1. BACKUP Design: • Automated database backups. • Point-in-time recovery where supported. • Object storage backup. • Backup monitoring. • Restore testing.
  1. DISASTER RECOVERY Document: • Recovery procedure. • Backup restoration. • Database recovery. • File recovery. • Queue recovery. • Disaster scenarios.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. ACCESSIBILITY Support: • High contrast. • Large touch targets. • Keyboard navigation. • Screen readers. • Proper labels. • Accessible validation messages.
  1. 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
  1. 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.
  1. 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.
  1. BULK OPERATION SAFETY For every bulk action:
  2. Preview.
  3. Validate.
  4. Show number of affected records.
  5. Confirm.
  6. Execute.
  7. Show result.
  8. Provide error report.
  9. Record audit event.
  1. SEARCH Global search across authorized data: • Campaign. • Employee. • Team. • Household. • Institution. • Task. • Submission. • Geographic area.
  1. DUPLICATE DETECTION Detect: • Duplicate employee. • Duplicate target. • Duplicate household. • Duplicate task. • Duplicate assignment. • Duplicate payment. Do not automatically delete records. Flag them for review.
  1. NOTIFICATION PREFERENCES Allow users to configure permitted notification preferences. However, mandatory government alerts cannot be disabled if configured as mandatory.
  1. 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
  1. API DOCUMENTATION Generate: OpenAPI / Swagger Document: • Authentication. • Request. • Response. • Errors. • Permissions.
  1. 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.
  1. 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.
  1. 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.
  1. SESSION SECURITY Support: • Session timeout. • Device/session management. • Logout all devices where authorized. • Token revocation. • Suspicious login detection.
  1. OTP SECURITY OTP: • Expiration. • Rate limiting. • Attempt limit. • Resend cooldown. • Secure storage. • Audit logging. Never store OTP in plain text longer than necessary.
  1. LOGIN Support: Mobile Number → OTP for initial verification → Password creation Then: Mobile Number → Password → Dashboard Forgot password: Mobile → OTP → New Password
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. DATA QUALITY DASHBOARD Show: • Missing data. • Invalid data. • Duplicate data. • GPS exceptions. • Correction rates. • Rejection rates. • Unusual activity.
  1. 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.
  1. 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.
  1. FORM TEMPLATE LIBRARY Allow reusable forms. Examples: • Inspection form. • Survey form. • Household form. • Verification form. Forms must remain versioned.
  1. WORKFLOW TEMPLATE Allow reusable workflows. Example: Field Officer → Supervisor → Department Head → District Admin. Save as: Standard Inspection Workflow.
  1. 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.
  1. 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.
  1. CAMPAIGN EXTENSION Authorized admin can extend deadline. Require: • New date. • Reason. • Approval if configured. Record audit history.
  1. TASK REASSIGNMENT Allow: Employee A → Employee B Reason: Employee unavailable. Maintain full history.
  1. TEAM CHANGE Allow adding/removing team members during campaign with authorization. Do not rewrite old historical assignments.
  1. TARGET REASSIGNMENT If a household/institution is reassigned: Maintain: Old Team → New Team Reason Date Authorized By
  1. FINALIZATION When a phase is finalized: • Prevent normal editing. • Allow authorized correction workflow only. • Lock official result. • Preserve historical versions.
  1. CAMPAIGN CLOSURE When campaign is completed: • Lock operational changes. • Finalize reports. • Finalize payment eligibility. • Preserve audit logs. • Archive according to retention policy.
  1. 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
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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
  1. 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.
  1. 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.
  1. DOCKER Provide: Dockerfile docker-compose.yml Services: • Web. • API. • PostgreSQL. • Redis. • Object storage for local development.
  1. DEVELOPMENT README Provide complete instructions:
  2. Install dependencies.
  3. Configure .env.
  4. Start PostgreSQL.
  5. Start Redis.
  6. Run migrations.
  7. Seed database.
  8. Start backend.
  9. Start frontend.
  10. Login using demo credentials.
  11. Run tests.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. MOST IMPORTANT ARCHITECTURAL MODULES The application must be built around these engines:
  2. Campaign Engine Campaigns and phases.
  3. Organization Engine Departments and hierarchy.
  4. Geography Engine District/tehsil/village/ward/mohalla.
  5. Workforce Engine Employees and availability.
  6. Team Engine Joint teams and reserve teams.
  7. Target Entity Engine Households, schools, roads, etc.
  8. Assignment Engine Assign targets to teams/employees.
  9. Form Engine Dynamic forms and versions.
  10. Field Data Engine Mobile data collection.
  11. Offline Sync Engine Mobile offline operation.
  12. Verification Engine Review and approval.
  13. Exception Engine Data quality and operational exceptions.
  14. Payment Engine Configurable government-guideline-based payment.
  15. Notification Engine SMS/email/push/in-app.
  16. Reporting Engine Dashboards and reports.
  17. Audit Engine Complete history.
  1. 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.
  1. 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.
  1. 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

同类提示词

更多「Web Development」→