COLLABORATION / 05

协作与 CI

允许并行,不允许隐式耦合。每个工作包都必须有唯一 owner、有限范围、稳定契约、验收证据和回滚方法。

OWNERSHIP

六条可并行开发线

跨线依赖通过版本化契约和 consumer test,而不是临时口头约定。

ID工作流 / Owner范围发布门
W1
门户与信息架构Developer Experience
本网站、清单 schema、搜索、模块详情catalog schema + build
W2
UI FoundationsDesign Systems
tokens、组件状态、Figma/Swift/Web 映射token drift + visual
W3
内容与社区Content Platform
data-sources → BBS → Portal 契约contract + provenance
W4
IM 与移动端Realtime / iOS
im-core、iOS、媒体 SDK、Push/WScross-repo smoke
W5
开放平台与资源Developer Platform
miniapp-open-platform、reits-media、opensdkpackage integrity + sandbox
W6
预约与商业化Booking Platform
发现、预约、商户、支付、增长order contract + E2E
W7
量化与行情Quant Platform
行情、策略、运行、模拟、Quant iOSdata contract + determinism
W8
身份与平台发布Platform Engineering
reits-auth、CI、安全、观测、部署、回滚auth + release evidence

TASK PACKET

人和 AI 使用同一种任务包

任务包是一次改动的最小协作边界;信息不全时先补任务包,不直接扩展范围。

task_id: W3-CONTENT-014
owner: content-platform
repositories: [data-sources, reits-bbs]
goal: "BBS feed contract adds source provenance"
in_scope: [schema, producer, consumer-test, docs]
out_of_scope: [UI redesign, database migration]
contracts: [bbs-feed.v2]
acceptance: [unit, contract, redacted-fixture]
rollback: "keep v1 alias for one release"
evidence: [test-log, contract-diff, sample-payload]
01

一个结果

goal 只描述一个可验证结果。

02

一个 owner

多仓任务仍只有一位集成负责人。

03

显式边界

in_scope / out_of_scope 阻止 AI 自行扩大任务。

04

契约先行

producer 与 consumer 使用同一版本和 fixture。

05

证据交付

完成不是“代码写完”,而是证据包可复核。

06

回滚可用

发布前就写清回退开关、旧版本兼容期和数据恢复。

CI ARCHITECTURE

从提交到运行证据的六级流水线

01

Intake

manifest schema、任务范围、owner、依赖锁定

scope-check
02

Fast

format、lint、typecheck、unit、secret scan

≤ 10 min
03

Contract

API、路由、事件、token 与数据库迁移 diff

consumer gate
04

Experience

a11y、visual、关键旅程、iOS snapshot

surface gate
05

Release

制品 hash、SBOM、迁移、回滚、部署清单

evidence pack
06

Observe

健康、错误预算、告警、值班、回滚验证

post-deploy
BLOCKING

合并必过

构建、单测、契约、安全、迁移、关键 UI 可访问性。失败不得以重跑掩盖。

REVIEW

需要 owner 判断

视觉基线、性能预算、依赖更新、公开文案与合规语义。

SCHEDULED

周期运行

完整 E2E、真实设备、长时 chaos、依赖与安全扫描、容量和备份恢复演练。

CHANGE PROTOCOL

跨仓变更四步协议

  1. 01

    Propose

    在生产方提交 contract diff、兼容策略、消费者清单和弃用日期。

  2. 02

    Prove

    新增 consumer fixture;旧消费者继续通过,新消费者在 feature flag 后验证。

  3. 03

    Promote

    先发布生产方兼容版本,再逐个升级消费者,观测错误预算和数据一致性。

  4. 04

    Prune

    兼容期结束且所有消费者迁移后,删除旧契约并归档决策与证据。