20 个章节 · 支持关键词组合搜索
组织分层、冲突与例外
实践 / 建议公司、团队、岗位、项目：把差异变成可检查的配置
六种身份分开登记
业务项目可以包含多个团队和仓库；Multica Project 当前默认映射一个 repo；岗位决定方法， 技术栈决定工具，运行环境决定权限。它们不能共用一个“project”字段包办。
建议在现有清单扩展业务项目、团队、仓库、岗位、技术栈和运行环境的关联，
保留 fs-ai-hub 当前 frontend/backend/qa/ops/pm 与 Project 机制。
Android/iOS 等差异先作为资源包或技术栈 profile，确有独立岗位资源时再扩角色，避免角色组合爆炸。
当前实际登记的 Project 只有 IDP，其他团队接入应作为实施任务，不能当作已经全覆盖。
规则合并不能只用“越局部越优先”
建议给规则增加或映射稳定 rule ID、强制级别、scope、版本、维护责任、验证器和例外条件。 以下为推荐合并语义，需要落进现有 schema/编译器与 CI，不能只写成提示词。
| 情况 | 处理语义 | 实战例子 |
|---|---|---|
| 公司强制底线与项目弱化冲突 | 阻断生成，要求正式例外；项目无权自行削弱 | 必需测试不能用 ignore failure 变成通过 |
| 团队在公司底线上加严 | 在适用范围内合并 | PaaS 公共接口增加租户隔离和兼容矩阵 |
| 公司提供可覆盖默认值 | 由明确的团队/项目参数替换，并显示来源 | 默认验证时限按移动端设备任务调整 |
| 同 scope 同 ID 不同正文 | 视为维护冲突，要求归并或改名 | 两个权限规范拥有相同 ID 却要求不同 |
| 两条强制规则同时适用且无法兼容 | 暂停相关步骤，提交责任方裁决 | 数据隔离要求与现有集成环境不能同时满足 |
| 项目确有暂时无法满足项 | 记录受影响 验收标准、补偿控制、授权人、到期日和退出条件 | 老工程暂缺契约测试，由指定验证环境补偿 |
“例外获批”只代表允许承担明确风险，验证结果仍保留 partial/unknown。 规则锁版也要有升级通道：普通更新通过 MR 扩散；严重规则撤销后停止使用失效包的新任务， 在途任务按影响评估重验，不在会话中途静默换包。
保留多种交付方法，统一交接字段
FSpec 适合复杂规格、跨仓分解和阶段产物；IDP 的 Issue/EARS 适合可明确验收的轻量任务； Egress 的 VERIFY 清单适合行为与运行证据较重的改动；Golden Path 提供默认小队编排。 公司统一需求来源、验收条件、规则版本、输入 SHA、验证结果、人工门和关闭语义。 团队在这一合同下选择流程，不要求 500 个仓重新编号为相同 L1/L2。
具体对齐：FSpec L0–L3 是任务路由，Golden Path L1–L3 是发布验证深度， IDP/Egress 的测试层次各有定义，组织成熟度另用 M1–M5，字段必须带维度名。
本文新提出的阶段、层次和步骤编号统一从 1 开始，组织成熟度采用 M1–M5。 FSpec 的 L0–L3 属于既有任务路由名称，为保持历史兼容按原编号引用， 不直接改成 L1–L4，以免与已有技能、规则和阶段产物错配。 同理，引用既有 P0 优先级或其他已被工具消费的稳定标识时保留其原义； 后续确需调整，须先建立映射并检查消费者，不通过文档改名代替系统迁移。
本节依据： fs-ai-hub 组织规范、IDP 工作流；FSpec 固定版本见证据索引 L2。