opc-backup/docs/身份体系与端口权限设计方案.md

云超服·身份体系与端口权限设计方案

依据《云南省OPC超级个体综合服务平台（云超服）系统设计方案》编写。 本方案定义丰富的身份体系、六大端口的管理能力、权限与数据范围模型，作为后续编码与功能完善的设计蓝本。

---

一、总体设计原则

1. 账号 ↔ 端口多身份：一个账号可绑定多个端口身份；身份即权限来源，不再由账号编码决定角色。
2. RBAC + 数据范围：权限按「角色-权限」矩阵下发；政务端叠加「省/市/区县」三级数据范围。
3. 一账号多身份，登录选择，头像可切换：登录返回全部身份；多身份弹选择器；运行中经头像菜单直接切换。
4. 端口数据互通、权限隔离：运营端最高权限；政务端按层级看数据；业务端口管自身业务。
5. 演示数据一律由服务端提供：前端不落地任何演示数据。

---

二、六大端口身份体系

每个端口定义 port（端口）+ role（端口角色码）+ sub_role（端口内细分角色）+ org/region（归属与数据范围）。

2.1 平台运营端 operator（总控中心，最高权限）

sub_role	名称	核心权限
op_super_admin	超级管理员	全平台一切管理、用户/角色/权限、审计
op_admin	运营管理员	用户管理、任务/服务商/内容审核、运营
op_customer_service	客服管理员	工单、争议调解、用户咨询
op_finance	财务管理员	结算、资金托管、佣金对账
op_analyst	数据分析师	全平台数据看板、报表、导出
op_techops	技术运维	系统配置、字典、运维

管理功能：用户管理、角色权限、任务管理（审核/上下架）、服务商准入与评级、内容管理、政策发布、数据大屏、系统配置、审计日志、资金/结算。

2.2 政务端 government（三级联动 + 组织角色）

数据范围：上级看下级，下级只看本级及以下（省→市→区县）。

sub_role	名称	数据范围	核心功能
gov_province	省级政务	全省	全省数据总览、省级政策、市/载体/服务商管理、补贴、分析报告
gov_city	市级政务	本市	本市数据看板、区县管理、市级政策、载体监管、补贴
gov_district	区县级政务	本区县	区县数据、载体/OPC 入驻审核、区县政策、补贴初审
gov_org_admin	组织机构管理员	按机构	本机构内账号与数据管理
gov_op_account	操作账号	按分配	仅操作、无管理

共性功能：数据看板（按范围）、载体管理（查看范围内载体及其中 OPC）、OPC 管理（范围内入驻审核/信息）、政策发布（起草→审核→发布→推送→效果追踪）、补贴管理、收入/交易数据（范围内订单金额、任务成交额）、审计。

2.3 企业端 enterprise（需求方：挑人才、发任务）

sub_role	名称	说明
enterprise	企业账号	基础身份
admin	企业管理员	企业档案、发布任务、资金托管、结算
operator	企业操作者	查看、人才挑选、项目协作

管理功能：企业介绍/档案、人才搜索（按技能/信用/地域）、任务发布（发标）、我的任务/项目管理（接单、进度、验收、评价）、资金托管、合同与保障。详见第五章「任务发标标准」。

2.4 服务商端 provider（为入驻 OPC 提供各类专业服务）

sub_role	名称	说明
provider	服务商账号	基础身份
admin	服务商管理员	服务商品、订单、结算、团队
operator	服务商操作者	服务交付、客户沟通

服务商等级：certified 认证 → premium 优质 → gold 金牌 → official 官方。 管理功能：服务商品管理（标准化/定制/订阅/按次/免费）、订单交付、为入驻 OPC 提供服务（财税/工商/法务/知识产权/云服务等）、客户运营、评级与结算、评价。

2.5 载体/园区端 carrier（管理载体内的 OPC）

sub_role	名称	说明
carrier	园区账号	基础身份
admin	园区管理员	入驻 OPC 管理、工位/空间、服务对接
operator	园区操作者	日常运营、数据查看

管理功能：入驻 OPC 管理（审核/绑定/工位分配）、空间/工位管理、园区数据（入驻率、订单）、服务对接（引荐服务商给园区内 OPC）、载体政策申报。

2.6 OPC 端 opc_member（平台核心服务对象）

sub_role	名称	说明
certified	认证 OPC	已完成实名/工商/技能认证
independent	独立 OPC	未绑定载体的自由个体

核心功能：认证（实名/工商/技能）、绑定载体（所属园区）、任务（广场/接单/竞标/交付）、服务市场（购买服务商商品）、政策匹配、财税/工商、金融/信用、智能体助手。

---

三、权限模型

3.1 权限码体系

• menu:*：菜单/功能入口权限（如 menu:gov_data、menu:admin_user_mgmt）。
• action:*：操作权限（如 action:task.audit、action:policy.publish、action:fund.release）。
• 数据范围（scope_region_ids）：政务端由 region 推导「本级+后代」，企业/载体/服务商按 org 归属。

3.2 角色-权限矩阵（示例）

role|sub_role 两级合并取权限：

enterprise|admin    -> menu:enterprise_dashboard, action:task.publish, action:fund.deposit, action:org.manage
enterprise|operator -> menu:enterprise_dashboard, action:task.view
government|gov_district -> menu:government_dashboard, menu:gov_data, action:carrier.audit, action:opc.audit, action:policy.publish
provider|admin      -> menu:provider_dashboard, action:service.manage, action:order.deliver
carrier|admin       -> menu:carrier_dashboard, action:opc.bind, action:space.manage
opc_member|certified-> menu:opc_dashboard, action:task.bid, action:task.deliver, action:service.buy

3.3 政务数据范围（三级）

• 省级 → 全省 region（省+市+区县后代）。
• 市级 → 本市 + 所辖区县。
• 区县级 → 本区县。
• 越权访问一律 403；写操作写审计。

---

四、各端管理功能矩阵

功能	运营	政务(按范围)	企业	服务商	载体	OPC
用户/账号管理	✅	本机构	—	—	—	本人
任务发布(发标)	审核	监管	✅	—	—	—
任务接单/交付	—	监管	验收	—	—	✅
服务商品/交付	评级	监管	—	✅	引荐	购买
载体/入驻OPC	监管	✅	—	—	✅管理	绑定
政策发布	✅	✅	查看	查看	查看	匹配
财税/结算	✅	收入数据	托管	✅	—	查看
数据看板	✅全平台	✅按范围	—	自身	自身	自身
系统配置/审计	✅	本级	—	—	—	—

---

五、企业端任务发标标准（详细逻辑与操作）

5.1 发标状态机

draft 草稿 → pending 待审核 → published 已发布
   →(接单模式)
      grab 抢单: OPC 抢单直接锁定
      bid 竞标:  多 OPC 提交方案 → 企业选标 → 中标锁定
      designated 指定: 企业指定 OPC
      dispatch 派单: 平台派单
   → in_progress 进行中 → delivered 已交付 → review 验收
      ├─ 通过 → completed 已完成(资金结算/双方评价)
      ├─ 驳回 → in_progress(要求修改)
      └─ 争议 → 平台介入仲裁
   → cancelled 取消(任一方违约/超时)

5.2 发标操作流（企业端页面）

1. 选分类：一级/二级分类（设计创意/技术开发/文案写作/营销推广/咨询服务/…）。
2. 填详情：标题、描述、需求文档、附件。
3. 设参数：预算范围、交付周期、难度、所需技能标签。
4. 选交付方式：线上/线下/混合。
5. 设接单模式：抢单/竞标/指定/派单。
6. 资金托管：任务预算托管到平台（校验托管金 ≥ 预算下限）。
7. 提交审核：平台审核合规性 → 通过后进入任务广场并推送匹配 OPC。

5.3 发标规则与校验

• 预算校验：budget_min ≤ budget_max，且为正；托管金 ≥ 预算下限。
• 期限校验：deadline 晚于当前时间。
• 合规校验：禁止违禁/敏感内容；平台审核队列。
• 竞标模式：至少 1 份有效标书才可评标；评标后未中标自动释放保证金。
• 违约处理：超时未交付/恶意抢单 → 信用扣分、保证金扣除。

5.4 验收与结算

• OPC 提交交付物 → 企业验收（通过/驳回/要求修改，最多 N 次）。
• 通过 → 托管金划付 OPC（按比例扣除平台佣金）→ 双方评价 → 信用更新。
• 争议 → 平台仲裁记录。

---

六、服务商服务入驻 OPC 流程

1. OPC 在服务市场浏览/搜索服务商品。
2. 查看详情、评价、案例；可咨询。
3. 下单 → 支付（资金托管）。
4. 服务商接单开始服务（绑定该 OPC 为「服务对象」）。
5. 交付/确认 → 评价 → 服务商等级与信用更新。
6. 载体端可「引荐」服务商给园区内 OPC，形成三方服务关系。

---

七、与现有代码的落点

设计项	现状	下一步
账号↔多身份	✅ user_identities，登录选择/头像切换已实现	补充更多角色 seed（各端口 admin/operator）
六端口菜单/页面	✅ 全部页面有真实数据	深化各端 CRUD/审核流
权限矩阵	✅ role_permissions 已 seed	扩充 action:* 权限码并按页面接入
政务数据范围	✅ scope_region_ids 按 region	数据看板/载体/OPC/收入按范围过滤
企业发标	🟡 有基础 tasks 表 + 发布接口	落地 5.1 状态机 + 竞标/托管/验收
服务商服务 OPC	🟡 有 provider/order 数据	落地「服务对象绑定 + 交付结算」
载体管理 OPC	🟡 有 carrier/opc 数据	落地入驻审核/工位/绑定

---

八、待确认事项

1. 发标状态机粒度：是否本期实现完整竞标+资金托管，还是先做「发布→广场→接单(抢单)→验收」最小闭环？
2. 政务收入数据：范围过滤口径（按载体/任务/服务商归属 region）？
3. 载体-服务商引荐：是否需要「三方绑定」实体表？