​
Server Web 概览

Server Web 是远程管理端，只连接服务器，不读取本地 workspace 或 Electron 本地项目。它展示的是已经上传并带 latest 版本的项目；没有 latest 的 draft 项目会被过滤掉。 Server runner 中执行的 workflow 会把 workflow.getRuntimePlatform() 标记为 "web"，包括 server web、external API 和 Webhook 触发的运行；这表示实际执行宿主是远程 server，而不是触发请求的客户端。（issue #84） 当前默认管理端入口是 server/web：根目录 server:web、deploy:web 以及 server 包内 build:web / typecheck:web 都指向该目录，构建产物输出到 server/public 并由 server 静态托管。 开发模式通过 pnpm run server 或 pnpm -C server dev 启动后会加载 server/.env 和仓库根目录 .env。server 包的 dev 脚本使用 cross-env 注入 NODE_ENV=development、WORKFLOW_SERVER_DEV=1 和 NODE_OPTIONS=--conditions=development，避免只在 Unix shell 可用的环境变量写法在 Windows 上直接启动失败。默认本地 .env 使用 WORKFLOW_SERVER_PORT=7125，如果该端口已经被占用，且当前是 WORKFLOW_SERVER_DEV=1 的 dev watch 模式，server 会自动尝试下一个端口（例如 7126、7127），并在日志里打印实际监听地址。非 dev 启动仍会保留端口占用错误，避免部署时静默漂移到未知端口。 issue #97 的阶段 0 起，发布/部署态和开发态的默认端口带被明确拆开：本地开发继续沿用 712x，而 deploy / launchd / 生产示例改为 7130+，其中 workflow server 默认使用 7130。部署脚本与 launchd 会优先读取 server/.env.production 和仓库根目录 .env.production，只有缺失时才回退到开发常驻的 .env。这允许同一台机器并存一套 712x 开发环境和一套 713x 发布环境。 issue #97 的阶段 A 继续把生产路径固定到外置硬盘根目录：当设置 WORKFLOW_RELEASE_STORAGE_ROOT 时，server 运行数据会默认派生到 ${WORKFLOW_RELEASE_STORAGE_ROOT}/server-data，下载服务会默认派生到 ${WORKFLOW_RELEASE_STORAGE_ROOT}/downloads/workflow-code，docs 静态站点会默认派生到 ${WORKFLOW_RELEASE_STORAGE_ROOT}/published/docs/stable，发布态 Supabase 会通过 docker/supabase/docker-compose.release.yml 绑定到 ${WORKFLOW_RELEASE_STORAGE_ROOT}/supabase/*。如果这个根目录未挂载或不可写，deploy、download 与 docs 启动都会直接失败，避免发布态静默回退到仓库里的 server/.data 或 Docker named volumes。 本地自托管 Supabase 的 server 连接地址默认使用 127.0.0.1：WORKFLOW_SUPABASE_URL=http://127.0.0.1:7121，WORKFLOW_DATABASE_URL=postgresql://...@127.0.0.1:7123/postgres。issue #86 起避免在 server 进程里使用 localhost，因为 macOS 上 localhost 可能优先解析到 IPv6，被其它本地 dev server 命中并返回 HTML，导致 Supabase Storage SDK 初始化 bucket 时解析失败。 如果在 Windows 上通过 docker compose up -d 启动 docker/supabase，workflow-code-supabase-kong 一启动就报 exec /home/kong/kong-entrypoint.sh: no such file or directory，优先检查 docker/supabase/volumes/api/kong-entrypoint.sh 是否被签出成了 CRLF。这个脚本在 Linux 容器里作为 shebang 入口运行，CRLF 会让 #!/bin/bash 变成 #!/bin/bash\r，导致 Kong 在进入健康检查前就反复重启。仓库通过根目录 .gitattributes 把这类 .sh 固定为 LF，修改脚本后如果本地仍异常，可执行 git add --renormalize docker/supabase/volumes/api/kong-entrypoint.sh 后重新 docker compose up -d。 docker/supabase/.env 是这套本地自托管环境的唯一默认源。issue #81 起，supavisor 的 bootstrap 会在启动时按 POOLER_TENANT_ID 对 _supavisor.tenants 做创建或更新，而不是只在首次启动时插入一次；这样当仓库里提交的 .env 把数据库端口、主机或池大小改成新值后，重启 docker compose up -d 就会覆盖旧 tenant 配置，避免 _supavisor.tenants 里残留旧的 db_port（例如历史上的 8433）导致认证查询一直超时。 界面风格从 issue #79 开始改为高对比极简管理端：浅色主题使用更亮的中性灰作为页面骨架（#F8FAFC 背景、#FFFFFF 卡片、#EAEFF3 muted、#E2E8F0 border）；深色主题使用 ui-ux-pro-max 的 OLED / Pure black + white contrast 方向，并约束为 neutral charcoal 灰阶（#09090B 页面背景、#111111 卡片、#18181B 辅助面、#27272A hover/active、#323236 border），避免大面积偏蓝 slate 底色。青色只用于当前焦点和信息点缀，绿色、琥珀色和红色只用于成功、等待/风险和错误状态。页面保留浅色/深色主题，但避免把所有内容都做成纯黑白，状态、入口和警告都必须有清晰语义色。 管理端默认入口切到 server/web 后，当前页面基座使用 shadcn/ui source components、Radix primitives 和 Tailwind CSS v4 tokens，并继续沿用 issue #79 沉淀的高对比、紧凑管理端方向。默认管理端的 Button、Input、Select、Switch、Table、Sheet、分页页脚和搜索框都从 server/web/src/components/ui/ 统一导出。 项目详情页按运行监控工作台组织：主内容顶部直接显示项目名、latest/发布状态、在线版本、Webhook、执行中和等待中计数；桌面端左侧菜单直接切到项目级工作区导航，只保留 概览 / 设置 / 成员 / 知识库 / 执行日志 / 版本 / KV 数据 / 环境变量 / Embed / Webhook 这 10 个入口，不再在详情页里继续显示“项目工作台 / 设置 / 管理中心 / 全局 KV 数据”这类跨页面主导航项。概览页专注展示摘要卡片、图表和运行用户统计；运行调度、可见性与禁止运行名单移动到左栏“设置”，项目成员维护移动到左栏“成员”。运行调度区会定时静默刷新当前执行中和等待中任务，任务卡片主体优先展示 runId、目标版本和时间，状态标签保持内容宽度的紧凑标签并与日志/停止 icon 按钮同行，不再出现整条黄色横幅或挤高任务卡片；“执行情况统计”只保留已完成记录的成功率、延迟和趋势图，不重复展示执行中横幅。最近执行记录使用统一 shadcn Table、短执行 ID 和单个最右侧操作列，日志入口使用带 aria-label 的图标按钮，避免长 ID 或文本按钮撑开表格。 版本详情页从 issue #79 起改为紧凑版本工作区：左侧项目菜单只负责导航，不再重复展示 latest 或在线版本摘要；主内容先展示 latest、在线、预准备和已下线版本摘要，再在版本表格上方展示筛选和分页。版本表格使用统一 shadcn Table，保持稳定行高和操作列，当前 latest 的下线按钮会禁用并说明原因，空发布日志以 未填写 标签表达；版本较多时可按版本号或发布日志筛选，并按 20 条一页分页。 其它 server web 管理页同样按 issue #79 的操作台密度整理：项目列表、最近执行、KV、环境变量、Embed、Webhook 和执行日志都把筛选、计数、分页和保存/重置等操作收进当前工作区，不再让控件漂在页面外；只有存在多页或更多数据时展示分页按钮。默认 server/web 的项目、运行记录、版本、KV、Webhook delivery 和执行日志表格统一通过 shadcn Table primitives 渲染，所有表格分页统一为每页 20 条；有服务端 cursor 的日志与 KV 使用上一页/下一页切换，不再把下一页追加到当前列表。表格行高和操作列保持稳定，页脚统计、筛选 placeholder、状态说明默认使用中文，保留 Webhook、Embed、KV 等必要技术名词。

​
登录

打开 server 地址后，如果当前浏览器还没有服务端会话，会进入 workflow-code 管理台 登录页。登录页主视觉使用与 App、docs 和默认项目卡片相同的一套品牌图标，并只保留账号密码这一条登录入口。普通用户和管理员都通过邮箱密码建立 httpOnly cookie 会话；若服务端配置了 WORKFLOW_BOOTSTRAP_ADMIN_EMAIL 与 WORKFLOW_BOOTSTRAP_ADMIN_PASSWORD，首次使用这组账号密码登录时会自动创建并提升内置管理员账号，便于临时初始化环境。浏览器会话 cookie 会使用 WORKFLOW_AUTH_COOKIE_SECRET 签名，未配置时回退到 WORKFLOW_SERVER_ADMIN_KEY，生产环境建议单独设置以便独立轮换恢复密钥。CLI / App 的 device flow 也会复用这个浏览器会话完成批准页授权。 Server 登录页 失败时会显示错误状态；提交过程中有独立 loading 状态。 Server 登录错误

​
项目列表

登录成功后会进入项目列表。拥有 projects.read_all、projects.read_public 或 runs.create 的普通账号也会看到项目工作台入口，后端会按公开项目、成员关系和运行权限过滤可见项目；没有项目相关权限的账号仍会停留在账号中心。列表只展示 server 上已上传并带 latest 的项目，支持刷新和按项目 id、名称、latest 版本、上传用户显示名称以及 Workflow / Conversation 类型过滤；表格内直接显示上传用户头像、显示名称和用户 ID，方便区分是谁上传了当前项目。顶部筛选还可在“全部 / 可运行 / 准备中 / Webhook / Embed”之间切换，并显示当前匹配数量。列表顶部会先展示服务器指标：已发布项目、可运行项目、公开入口数量和 Webhook 数量，方便进入表格前先判断服务器整体状态。 上传包中的 package.json 可以通过 workflowCode.projectCard 配置项目卡片展示元数据：kind 区分 workflow / conversation，icon 使用内置 token，iconUrl 可提供 http(s) 图片，iconBackgroundColor 使用 #RRGGBB。其中 workflow 默认显示内置 Workflow 图标，旧的 sparkles 也会兼容映射到同一枚图标；其它 token 继续使用内置 Lucide 图标。server 会在保存草稿时持久化该字段，并通过 /api/workflows 的 projectCard 返回给管理端；旧 workflowCode.appCard 只作为兼容读取。没有显式配置时，server 会根据 index.ts 的 conversation 配置或项目 id/name 生成默认卡片。 Server 项目列表 每一行会展示项目图标、Workflow / Conversation 标签、项目名称、ID、latest 版本、更新时间和集成状态，并提供三个入口：
  • 详情：进入项目详情、版本、环境变量、Embed 和 Webhook。
  • Embed：在新的浏览器页面打开公开 Embed；未启用公开入口时打开该项目的 Embed 配置页。
  • 日志：进入该项目详情菜单下的“执行日志”表格。
首页桌面端不再保留左侧全局主导航，项目工作台只显示顶部品牌区、右上角统一账号菜单和“全局 KV 数据”入口；品牌区点击后始终回到首页。设置页、管理员后台和项目详情页仍保留左侧导航，但账号菜单内容与首页完全复用同一份组件。日志不占用一级导航栏，也不再单独占用一个页面；它放在项目详情菜单的“项目详情”下面，只从项目列表行、项目详情运行记录或 KV 关联入口进入，避免把项目上下文排查入口和全局入口混在同一层级。 项目详情不再在概览页内部嵌套 概览 / 设置 / 成员 页内 tabs。运行调度、可见性与禁止运行名单已经提升到左侧独立“设置”工作区，项目成员维护提升到左侧独立“成员”工作区，避免在项目详情里形成两层局部导航。

​
审计日志

issue #96 起，server web 新增一级“审计日志”页面，对账号与权限、API key、device flow、项目管理、发布、运行、Embed、Webhook、环境变量等敏感操作做统一检索。页面依赖 GET /api/audit-events，只对拥有 audit.read 的主体开放；system.admin 仍会短路覆盖该权限，但普通管理员能力不再强绑为唯一入口，便于后续扩展只读审计员角色。 审计列表默认按时间倒序展示，并支持按时间范围、用户 ID、principal 类型、事件类型、资源类型、资源 ID、结果筛选，以及基于 cursor 的分页。页面会展示本次匹配总数、本页拒绝数、本页失败数；查询、翻页、刷新和详情抽屉都具备明确的 loading / empty / error 状态。详情抽屉只显示脱敏后的结构化 context，不会回显明文 token、API key、admin key、secret、cookie、环境变量值或其它凭据。 当前审计覆盖重点包括：
  • 账号与权限：登录、登出、device approve / deny / token、API key create / revoke、角色与权限变更、用户管理。
  • 业务敏感操作：项目创建、更新、删除、上传、发布、版本上下线、运行、取消运行、用户输入恢复、Embed 配置、Webhook secret reset、环境变量保存、external / embed 运行入口。
  • 权限拒绝：统一记录为 permission.denied，避免把所有 403 混入特定业务事件名。
审计上下文在写入前和读取前都会经过统一脱敏逻辑：命中 token、secret、password、authorization、apiKey、adminKey、cookie、session、refresh、access、credential、env、value 等语义字段时，只保留前后缀或通用 [redacted]；非敏感长文本会按长度截断，避免在页面或日志里写出超长原始输入。当前默认保留策略为“跟随主 PostgreSQL 数据库持续保存”，尚未引入定时清理任务；如需定期归档或删除，应基于 workflow_audit_events 单独扩展后台策略。

​
移动端

server web 有移动端 frame。移动端保留同样的信息密度：项目名、latest 版本、更新时间、运行状态和详情/Embed/日志入口。 Server 移动端项目列表

​
深色模式

Server Web 通过 data-theme 和本地存储保存主题，支持浅色、深色和跟随系统三种模式。设置页左侧只保留 个人信息 / 系统设置 / API Key 三项，其中个人信息支持头像上传并实时同步到右上角账号菜单，系统设置当前只承载主题切换。 Server 深色项目列表

​
追踪

本文档首版由 issue #32 记录。执行记录分页与进行中任务入口由 issue #45 记录。首页 Embed 新页面打开与 Global KV 间距调整由 issue #77 记录。项目运行队列和调度控制由 issue #78 记录。server web 极简界面重构由 issue #79 记录。默认 server web 入口为 server/web，只展示已发布项目的行为对齐 server/web/src/App.tsx 中的 isUploadedVersionProject。