Cell-design（design.cell）用于在项目中以“单元（cell）”方式描述架构。specs/design/design.cell 是首要设计来源：一个项目级文本文件，描述架构单元、设计版本所处阶段，以及各组件引用的用户故事，控制台会随写随渲染。保存后，平台会为尚无 design.json 的可部署组件生成骨架，并继承该单元的故事引用。组件 id 必须与 components/<name>/design.json 中的名称一致。
单元即项目边界，画成八边形：项目自身组件在内部；项目外部通信对象画在四条边界上——north 为公网/互联网网关，west 为组织内网网关，east 为项目外的组织或平台依赖（如 Thunder 认证、org-service），south 为第三方/外部依赖（SaaS 等）。设计文件中，项目内资源（数据库、缓存、对象存储）也是单元内组件；暴露到互联网或组织内网分别通过 north、west 暴露边表示。
语法按行书写，每行一条语句，忽略空行，仅支持整行注释（# 或 // 开头）。多词值用双引号包裹。保留字 title、version、component、as、north、east、south、west 不可用作组件或外部 id。title 声明标题；phase 声明该设计版本详述的单个 PRD 阶段，必须在文件靠前位置且只有一个；component 声明单元内组件，可带 as 标签和可选类型，并以 [stories: 1, 2] 后缀引用所服务的 PRD 故事；外部依赖用 <direction> <id> [as <label>] [type] 声明，行内不能含 ->。边写作 A -> B [: label]，依据两端自动推断内部调用、暴露、入站或出站。推荐先声明带边界的外部项，再写普通 a -> b，编译器会自动归类。north/west 仅允许入站，east/south 仅允许出站，反向写法会报错。单项目通常只需一个隐式单元，多单元块仅在联合建模多个项目时使用。
用法上应在一个 addFile 中整体写入 design.cell，平台会逐行流式渲染实时架构图，无需增量 editFiles。发生架构性变更（增删改组件、改调用关系、改暴露、增删组织或外部依赖）时，design.cell 应最先修改，再用 editFile 做定点增删行，最后同步 design.md 与受影响的 design.json；若属于整体重构，则 removeFile 后用一次 addFile 重新流式写入。不涉及组件、边、暴露或外部依赖的改动不触碰 design.cell。需避免的常见错误包括不存在 resource 或 external 关键字、用裸引号当标签、类型前加冒号，以及把 Thunder、支付或邮件等外部依赖放入单元内部。资料未提供收费、价格、平台支持范围或效果等更多信息。