本地与云端双工作台
MAWflow 把“面对真实源码和开发环境”与“面向 Workspace、团队和跨设备协作”拆成两个正式产品工作台。两端使用同一项目身份和业务语言，但不共享浏览器会话，也不会因为关联同一项目就自动传输完整源码。
本地产品工作台
- 直接面对当前电脑的真实源码和开发环境；
- 本地项目不限数量，可独立、离线推进；
- 支持创建、导入、Clone、从 Seed 建立或连接 Workspace 项目；
- 通过“资源凭证”统一管理服务器、服务、访问配置、凭证关系和项目环境运行矩阵；
- 通过“本机能力”管理 AI 服务、当前电脑、运行环境、宿主机和节点；
- 按需把经授权的项目状态接入云端协作。
云端产品工作台
- 以 Workspace 聚合团队、成员、项目和节点；
- 管理需求、计划、任务、审批、验收、交付和团队协作；
- 支持跨电脑、远程和移动协作；
- 默认连接用户自己的 Host/Node；
- 一级入口统一为“工作首页、项目空间、我的工作、资源凭证、组织协作、个人设置”；
- “资源凭证”集中查看云端服务器、服务、凭证反向引用、Host、项目使用、审批与审计；
- 可以按项目条件申请其它运行资源或 Self-hosted Workspace。
同步什么，不同步什么
| 类型 | 默认处理 |
|---|---|
| 项目身份、成员、任务、审批和证据引用 | 在授权范围内参与云端协作 |
| 项目手册的确认内容或安全摘要 | 按项目策略和用户选择同步 |
| 完整源码、未提交工作副本、原始提示词 | 不因开启云端协作自动上传 |
| 密钥、密码、SSH 私钥、数据库连接串 | 不进入普通页面或项目正文 |
| 高风险发布、外部同步和不可逆动作 | 先展示影响，再由责任人确认 |
一个人怎样使用双工作台
同一个人同时操作本地与云端工作台时，不需要把自己拆成“开发、测试、验收、交付”四个虚拟成员。两端共享同一个任务事实，但各自只做最擅长的事：
| 步骤 | 主要入口 | 一人团队的最短动作 |
|---|---|---|
| 1. 定义结果 | 云端或本地 | 写清要得到什么、怎样判断完成。 |
| 2. 确认计划 | 当前任务所在工作台 | 一次确认范围、风险和检查方式。 |
| 3. AI 执行 | 本地工作台 | 在真实工作副本中执行并留下检查结果。 |
| 4. 人工验收 | 本地或云端 | 本人检查结果，选择通过或回修。 |
| 5. 交付决策 | 验收表单 | 同一次提交选择“形成发布候选”或“无需发布”。 |
| 6. 发布门 | 对应发布入口 | 只有发布候选才单独确认生产发布；验收通过不会自动上线。 |
| 7. 归档历史 | 两端自动回读 | 无需发布的任务直接关闭；已发布任务在发布证据就绪后归档。 |
普通低风险任务不再要求同一个人重复提交“验收批准”和“交付批准”。系统仍保存一次具名决定、理由和证据引用；生产发布、凭证变更、数据迁移及不可逆动作继续使用独立确认门。
从本地工作台创建云端协作项目时，项目身份、成员与本机来源映射会先保存，首轮项目认知和推进准备度体检作为可见后台任务继续执行；创建页面不需要等待完整普查。返回本地后完成账号连接并刷新云端事实；如果云端项目记录的本机来源和设备正是当前安装，本地工作台会自动把云端唯一 project_key 回填到原项目，使两端任务进入同一协作身份，不需要一人团队再手工做一次内容相同的绑定。这一步只同步协作身份，不会下载、上传或修改源码；跨设备或来源不精确匹配时仍要求人工选择。
一台电脑没有远端仓库时怎样执行
如果项目来自当前安装、两端使用同一账号，而且本地项目与云端项目已经精确映射，本地工作台可以为当前任务签发一次“同机本地源码”证明。任务仍会建立云端工作项、执行授权和节点任务，但源码只在这台电脑登记的项目目录及其隔离工作树中使用，不要求为了单人单机开发额外创建远端仓库。
这类任务完成后会先形成任务分支的本地已验证提交，不会尝试推送不存在的远端。你选择“验收通过”时，工作台会再次确认目标分支、冻结版本、工作副本和改动范围；全部一致才以 fast-forward 合入原项目。项目已变化、分支分叉或出现越界文件时会停止并要求处理，不会自动覆盖。
本地工作台自己的 Project Space 草稿、批注和编辑请求保存在项目的 .local/project-space-runtime.json，该目录按 Seed 约定不进入 Git。旧版本生成的 .maw/project-space-runtime.json 只有在能证明是工作台 schema 且未被 Git 跟踪时才会迁移；已经提交或无法确认归属的文件不会被自动删除。工作台自有运行态不应让项目变成“有未提交变化”。
执行节点领取任务后还会回到本机 Host Manager 核对同一任务、节点、安装、项目映射、当前分支和冻结提交，再从真实项目创建独立任务工作树。若这一步失败，任务必须停止并显示源码装载问题；不能退回空的 Runner 目录继续执行，也不能把“节点执行成功”误当作“项目已经产生变更”。
从失败或返工状态重试时，本地工作台先落盘“已排队”事实，再请求云端重排原任务；执行节点即使立即领取，也能读取到同一轮次。该流程复用原 WorkItem、Task 和 Dispatch，不要求一人团队为了恢复任务再建一套重复记录。
如果云端已经完成重排、但本机没有及时收到响应，本机不会把任务恢复成上一轮的“已完成”。它会用原 WorkItem、任务版本和云端 Task 回读当前状态；重复点击也只返回同一队列事实，不会再次增加重试次数或复制任务。回读无法确认精确同一对象时才提示保留现场并重新检查。
重试后，当前任务卡会清除上一轮的结果可用标记、结果引用和审计快照，并按本轮事实显示“等待节点”“节点已领取”“正在执行”或“等待人工验收”；上一轮失败不会继续占用当前摘要。历史失败、人工结论和修复原因仍可在审计中心按轮次查看，不会因清理当前卡片而丢失。
项目手册和审计中心是闭环的两个长期入口：项目手册把当前项目文档编译为可阅读、可版本化的认知面；审计中心保留任务执行、人工结论、返工轮次和 Evidence 引用。多次返工不会覆盖成一次失败，同一条证据因断网重放也不会重复；只有最终人工通过才形成唯一验收结论。
一人团队首次初始化六卷手册时，引导模式先展示每卷来源数和待创建文件数，完整文件差异按需展开；确认后只以六卷索引的真实回读判断初始化是否成功，不再要求与“今日最重要动作”同时消失。生成的 docs/handbooks/** 会明确进入下一步 Git 提交，不会只显示笼统的“完成验证未通过”。分卷来源索引中的项目内相对链接可直接打开对应手册正文，不需要再到源码目录查找。来源索引不等于核心结论：六卷都只有索引时，工作台明确禁止批准基线，并引导到 Git 工作区新增如 current-baseline.md 的正式正文；失败原因会直接显示，不会出现点击后无反馈。审计中心把多个 Finding/修复请求归并到已经确认的任务主线：摘要中的任务数只计算真实任务，修复请求数单独说明，避免把同一轮问题重复看成多条任务。
| 场景 | 源码方式 |
|---|---|
| 同一账号、同一安装、同一项目精确映射 | 可直接使用本机隔离工作树，不上传源码。 |
| 换电脑、团队交接或云端节点执行 | 配置受管 Git 远端和访问方案。 |
| 项目映射、安装身份或工作副本发生变化 | 当前任务暂停并要求重新核对，不猜测目录或自动迁移源码。 |
这种简化只省去不必要的 remote 配置，不会省略范围确认、节点隔离、标准结果、真人验收和归档；生产发布仍是独立动作。
为什么两端阶段可能不同
云端阶段是团队对当前项目周期的声明，本机阶段是根据当前工作副本、任务和证据做出的迭代观测。两者不同不表示系统已经发现一个必须“校准”的错误，也不表示任何一端会自动改写另一端。
- 如果当前任务仍能正常推进，阶段差异只作为说明信息展示，并列出各自依据。
- 如果差异会影响任务、验收或发布，页面应把阻塞对象和下一步直接放到当前任务上，而不是给出笼统的“校准阶段”。
- 一人团队可以在核对证据后更新云端声明，或继续以本机事实完成当前任务；不需要为了让两个标签相同而创建额外审批。
- 本地和云端状态一致后，提示会自然消失；系统不会自动跳级、回退或替用户作出阶段决定。
从哪里开始
- 已有本地代码：走本地项目路径。
- 先做产品规划：走网页项目路径。
- 多人或跨设备协作：走团队协作路径。
- 需要自己的服务器承载 Workspace 正文和运行环境：先完成普通项目路径，再按需选择 Self-hosted Workspace。
按运行条件选择
| 你的条件 | 建议路径 | 说明 |
|---|---|---|
| 暂时没有服务器 | 先在云端产品工作台建立项目 | 创建项目和确认范围不以 Host/Node 为开通条件；需要执行时再准备资源 |
| 一台开发电脑 | 本地产品工作台 | 源码和开发环境留在当前电脑，可独立推进 |
| 已有自己的服务器 | 云端项目 + 自有运行资源，或 Self-hosted Workspace | 是否承载 Workspace 正文取决于项目数据边界 |
| 团队和跨设备 | 云端产品工作台 | 团队共享项目身份、任务和证据引用，源码仍按授权处理 |