chore: baseline V8.10.0-dev.1 with v8_workflows type-mapping fix and trade-pro spec
- SiteForge Enterprise V8.10.0-dev.1 upstream source (210 tests) - Fix: v8_workflows._mapped_input now reads both 类型/分类 columns so WXR imports keep post/product types instead of collapsing to page - Docs: trade-pro theme port spec (R3) and implementation plan Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
浅念
@@ -0,0 +1,11 @@
|
||||
# 6.0.0 / SiteForge Factory
|
||||
|
||||
- 统一 Web API、用户会话响应、健康检查、后台界面和部署名称的软件版本为 `6.0.0`；主题独立版本继续为 `1.1.0`。
|
||||
- 移除 Web 请求线程中的直接静态构建；所有 UI 构建操作都提交 202 任务。
|
||||
- 队列增加客户端 Idempotency-Key、活跃任务去重、取消、子进程超时和有限重试；同一网站运行任务互斥。
|
||||
- Worker 加入租约续期、过期任务恢复、可取消的执行进程、可配置超时和重试次数。
|
||||
- 锁定直接和传递依赖版本；添加 GitHub Actions Python 测试、JS 语法和 Docker 构建配置。
|
||||
- 继承 V5 全套主题、内容导入/装配、视觉编辑、迁移审计、审批和静态导出。
|
||||
- 通过 58 项测试；另用真实 Uvicorn+独立 Worker 进行 HTTP 登录、创建站点、排队构建、预览和 ZIP 下载。
|
||||
|
||||
**非本轮完成**：Art Design Pro 官方工程替换、PostgreSQL/Redis 分布式基础设施、深度 CMS 全格式支持、任意服务器发布与生产安全压力测试。
|
||||
@@ -0,0 +1,17 @@
|
||||
# SiteForge v0.3 变更
|
||||
|
||||
## 从 v0.2 到 v0.3
|
||||
|
||||
- 新增 `app/blueprints.py`：受限的页面区块协议、区块输入校验、字段占位符、动态内容数据源和网页 HTML 渲染。
|
||||
- 四套主题新增 `manifest.json` 与 9 种 `page-presets.json`，支持独立行业主题的页面预设。
|
||||
- 增加 11 类实际渲染的页面区块及共享响应式 `blocks.css`。
|
||||
- 新增完整屏可视化编辑器 `/editor/{site_id}/{entry_id}`：区块拖拽排序、属性面板、预览、保存、构建。
|
||||
- 新增站点内容类型字段模型管理及数据结构存储、导航编辑和静态绑定参数表。
|
||||
- 新增 `/apply-theme` 批量一键套版，以及 `/scaffold` 默认栏目初始化。
|
||||
- 旧的 WordPress / CSV / XLSX / JSON / 静态导出和登录机制保留，已有旧站内容不自动覆盖。
|
||||
- 新增 Art Design Pro Vue3 / Element Plus 独立对接示例（非官方完整前端代码）。
|
||||
- 编写新增端到端 API 单测，旧用例继续回归。
|
||||
|
||||
## 风险与后续重点
|
||||
|
||||
开发版暂未实现基于官方 Art Design Pro 工程的实际构建、复杂页面组件多级布局、全站实时预览、复杂插件迁移、分布式任务队列、企业角色权限、公共云多目标部署。Docker 尚须在用户的运行环境验证镜像构建及持久卷。
|
||||
@@ -0,0 +1,57 @@
|
||||
# SiteForge V5 商业主题交付说明
|
||||
|
||||
> V5 是在 V4 原有后台、内容模型、编辑器与构建流程上迭代的**行业网站主题交付候选版**。完成页面功能及技术回归，不代表现已取得各类网站的商用法律、运营或视觉验收。
|
||||
|
||||
## 本轮实际开发
|
||||
|
||||
- 四个独立主题 Automotive、Industrial、Corporate、Minimal，继续保留各自 14 类页面模板。
|
||||
- 页面视觉重新整理：商业版字体排版、节奏、卡片、详情与参数布局、按钮交互、移动端适配；四套不同视觉方向。
|
||||
- 主题自带本地 SVG 视觉示意素材，可离线浏览；上传企业正式图片或 Logo 后，会优先展示真实素材。内置插画不是实际产品图片，请正式交付前替换。
|
||||
- 全站 Logo 优先使用网站实际配置。导航多级菜单、品牌与分类目录、产品画廊、筛选、对比页面结构等保持数据驱动。
|
||||
- 移动端导航与筛选空状态、键盘焦点、减少动态效果偏好等交互改进。
|
||||
- 站点 OG 标题/摘要与主题色，继承站点已有 Title/SEO/Canonical/Robots，不自行修改迁移来源 URL。
|
||||
- 建立商业交付报告 `commercial-readiness.json`，提示演示内容、占位图、Logo、询盘渠道及隐私说明等待人工验证事项。报告也在 `siteforge-report.json` 包含摘要。这与静态质量检测分开，**不会虚构已合规或已上线**。
|
||||
- 新增主题 `1.1.0`。保留 V4 主题 `1.0.0` 的完整模板快照供已锁定旧主题的站点使用；更旧的 `0.3.0` 仍保留。
|
||||
- 修正后台主题预览的商业 CSS 与本地 SVG 资源加载，使其与构建所用主题文件一致。
|
||||
|
||||
## 四套主题的业务定位
|
||||
|
||||
| 主题 | 风格与重点 | 常见栏目 |
|
||||
| --- | --- | --- |
|
||||
| Automotive | 深蓝与暖金、大幅车辆展示、车型与品牌分区 | 首页/车型/品牌/参数/新闻/案例/联系 |
|
||||
| Industrial | 浅蓝与工程网格、产品分级、规格表 | 首页/分类/产品/规格/案例/技术文章/联系 |
|
||||
| Corporate | 现代紫白体系、业务能力与项目展示 | 首页/服务/关于/案例/新闻/联系 |
|
||||
| Minimal | 中性色编辑式布局、作品陈列 | 首页/作品/服务/简介/联系 |
|
||||
|
||||
## 快速使用
|
||||
|
||||
1. Docker Desktop 启动后，在项目目录初始化 `.env`，然后运行 `docker compose up -d --build`。
|
||||
2. `http://localhost:8787/` 登录。`/theme-gallery` 查看主题，`/factory-studio` 创建网站。
|
||||
3. 在网站项目中初始化完整栏目，添加企业资料、Logo、正式邮箱、产品与文章。
|
||||
4. 选择主题版本 `1.1.0`、预览、生成静态站并在 ZIP 中查看 `commercial-readiness.json` 与 `siteforge-report.json`。
|
||||
5. 完成真实设备、内容、图片版权、SEO、表单、法律页面与性能检查后再上线。
|
||||
|
||||
## 商业交付前人工验收清单
|
||||
|
||||
- [ ] 企业 Logo、品牌颜色、产品主图、图库和版权授权材料均已填入；不再使用演示素材。
|
||||
- [ ] 首页、关于、产品、品牌、新闻、案例、联系与 404 页面逐页核对；不允许空栏或虚构数据。
|
||||
- [ ] PC 1440px/1024px、手机 390px/360px 等设备检查，尤其是中文/英文长标题和多级菜单。
|
||||
- [ ] 真实询盘接收渠道已配置并实际发送验证；如连接第三方表单，需要其隐私和防垃圾邮件机制。
|
||||
- [ ] Title、Description、Canonical、Robots、Sitemap 和历史 URL 与旧站基线一致（仅迁移项目）。
|
||||
- [ ] 图片与 PDF、内部链接、搜索、筛选、参数/画廊和键盘操作实际验证。
|
||||
- [ ] 业务文案和业绩指标经过企业审核，隐私政策/法律页按目标市场要求配置。
|
||||
- [ ] 部署环境的 HTTPS、缓存、日志、备份、回滚、安全与压力测试已通过。
|
||||
|
||||
## 当前不在本轮保证范围
|
||||
|
||||
不保证任意 WordPress/Elementor/ACF/WooCommerce 无损迁移；不提供任意代码主题安全安装、内置邮件服务器、完整 Art Design Pro 官方仓库整合、PostgreSQL/Redis、多云一键发布，也未完成正式生产环境合规或多浏览器全面测试。构建通过只是技术成功，`commercially_certified` 固定为 `false`。
|
||||
|
||||
## 测试方法
|
||||
|
||||
```bash
|
||||
python -m pytest -q
|
||||
PYTHONPATH=. SITEFORGE_DEMO_OUT=/tmp/siteforge-demo python scripts/make_theme_demo.py
|
||||
python scripts/make_offline_preview.py /tmp/siteforge-demo /tmp/siteforge-preview.html
|
||||
```
|
||||
|
||||
静态演示使用虚构内容，包含各主题的本地 `visual/hero.svg`；不依赖第三方图片服务。
|
||||
@@ -0,0 +1,54 @@
|
||||
# SiteForge 7.1.0 — 对照《COMPLETION_PLAN(1).md》优化结果
|
||||
|
||||
> 对照文件：用户提供《SiteForge 网站工厂 — 完整实现与生产落地计划》v2.0（2026-10-22）。
|
||||
> 状态：**P0 代码修复及本地测试完成；真实 Docker / 云 CI / 浏览器网络访问 / 线上回滚尚待指定部署环境验收。**
|
||||
> 注意：该计划评审的是 v5 源码及 v4 运行实例；本项目的实际起点是 **V7.0.0**。不应把计划中的 v5 数字直接改写成实际运行结论。
|
||||
|
||||
## 评审中的关键结论
|
||||
|
||||
1. **“代码更新 ≠ 生产部署已生效”**：保留生产实例的健康版本和提交标识对账，杜绝仅凭 ZIP 文件判断升级成功。
|
||||
2. **P0 必须先修**：预览导航根路径 404、Compose 重复构建标签、Worker 错误继承 Web HTTP 探针、favicon、Linux CI 和离线恢复。
|
||||
3. **安全底座不足仍是最高风险**：任意 URL 的 DNS 解析与重定向、数据导入包的 XXE/压缩炸弹、数据库只读权限、密钥引用策略，必须先在 P1 统一设计而非每个连接器各自实现。
|
||||
4. **发布闭环尚未生产验收**：不可变构建、审批、原子发布、线上探测、回滚、CDN 控制需正式环境测试。
|
||||
5. **多语言需要内容级映射**：仅克隆站点不能形成正确的翻译组/hreflang。
|
||||
|
||||
## 本次 P0 工作与验证证据
|
||||
|
||||
| 文档任务 | 实际修改 | 验证状态 |
|
||||
|---|---|---|
|
||||
| P0-1 平台/部署版本一致 | 平台改为 7.1.0；health 返回 `version` 与 `commit`；后台文字、Docker 标签、init 配置对应升级；Dockerfile 加 OCI revision 标签 | 本地 API / UI 代码测试通过；目标服务器镜像摘要仍需部署后对账 |
|
||||
| P0-2 预览根链接 404 | `app/preview_rewrite.py`：仅在预览 HTTP 响应中改写 href/src/action/poster；绝对外站 URL 不动；静态 ZIP 原封不动 | 新增真实构建/TestClient 回归，检查 `/products/` 预览状态 200 |
|
||||
| P0-3 Worker 健康检查 | 去除 Dockerfile 的 Web 专属内置探针；Web 仍检查 HTTP；Worker 使用 `/data/worker-heartbeat` 独立探针 | 单元及 Compose 结构测试通过；Docker Engine 未运行 |
|
||||
| P0-4 favicon | 新增 `/favicon.ico` 真正文件与路由 | HTTP 测试 200 |
|
||||
| P0-5 同镜像标签重复构建 | Web 唯一进行 build，Worker 引用同一镜像并依赖 Web 容器启动；本地 / 企业 Compose 同步调整 | Compose 结构测试通过；GitHub CI 新增单命令 `up -d --build` 冒烟，尚待 CI 云端运行 |
|
||||
| P0-6 跨平台 CI | `scripts/check.sh` 与 `scripts/check.ps1`；CI 使用 Bash 检查 Python、所有 JS、pytest；增加 Docker Compose 双服务 healthy 冒烟 | Linux 本地 79 项通过；GitHub Actions 尚待在仓库运行 |
|
||||
| P0-7 密钥卫生 | 保持 `.env`、`secrets/` 在 Git ignore / Docker ignore；初始化脚本不覆盖已有密钥 | 静态检查完成；真实环境密钥轮换须由管理员执行，不能从交付包代替生产凭据 |
|
||||
| P0-8 备份恢复 | 新增 SQLite WAL 在线备份 → 独立目录恢复 → 核对站点与媒体的测试 | 本地隔离测试通过；真实 Docker 数据卷离线恢复演练待完成 |
|
||||
|
||||
## P0 的真实退出条件（仍需在你自己的 Docker 环境完成）
|
||||
|
||||
- 运行 `docker compose up -d --build`，**Web 和 Worker 均显示 healthy**。
|
||||
- `/api/health` 返回 `7.1.0` 和你提供的 `SITEFORGE_GIT_SHA`（生产环境不应是 `unknown`）。
|
||||
- 对目标镜像记录 `docker image inspect` 摘要，截图或保存启动日志。
|
||||
- PC 1440、手机 390/360 登录、导航、构建、预览无失败。
|
||||
- 在独立测试卷完成备份、恢复和回滚验证，不直接覆盖旧站正式数据。
|
||||
- 轮换暴露过的管理员密码、会话密钥及发布 Agent 密钥。
|
||||
|
||||
## 后续开发顺序（依照原计划）
|
||||
|
||||
| 阶段 | 首先要完成的工程 | 完成门槛 |
|
||||
|---|---|---|
|
||||
| P1 | 显式 DB schema 迁移表、通用任务/审计、SSR F/DNS/重定向安全客户端、secret ID 引用、配额 | 故障注入与越权、私网请求拒绝测试通过 |
|
||||
| P2 | WP REST/WXR/Sitemap 断点续跑、幂等、URL/SEO 基线、迁移会话 | 本地 WP 固定夹具 + 授权真实站匿名验收报告 |
|
||||
| P3 | XML/API/只读 MySQL 连接器、导入暂存与批次回滚 | 5,000 条可恢复导入、失败不重复写入 |
|
||||
| P4 | Schema 区块、整站主题包、兼容性预检、草稿与设备样式 | 多页面模板安装/回退和视觉回归通过 |
|
||||
| P5 | SFTP/S3 不可变版本、审批、原子切换、线上探测 | 容器化部署/故障/回滚测试通过 |
|
||||
| P6 | locale / translation_groups / hreflang | 多语言页面双向 hreflang 与 sitemap 一致 |
|
||||
| P7 | PostgreSQL + 分布式队列高可用、SSO、监控、备份、SLO | 真实并发与灾备压测和安全审计 |
|
||||
|
||||
## 技术边界
|
||||
|
||||
- 本次未将当前 PostgreSQL 兼容层表述为正式数据迁移/高可用认证。
|
||||
- 未声称官方 Art Design Pro 项目已构建：它仍以独立接入代码形式存在。
|
||||
- 浏览器自动化在当前隔离环境访问本地 HTTP 返回 `ERR_BLOCKED_BY_ADMINISTRATOR`；这属于测试环境访问限制，**不作为页面已通过浏览器测试的证据**。
|
||||
- Docker Engine 当前未安装，不能宣称 Compose 真正已启动。
|
||||
@@ -0,0 +1,78 @@
|
||||
# SiteForge V7 — Web + Docker 部署与正式发布
|
||||
|
||||
## 1. 配置
|
||||
|
||||
首先下载源码到可信环境，进入项目目录。Windows PowerShell 首次生成 `.env`（不会覆盖已存在密码）：
|
||||
|
||||
```powershell
|
||||
docker run --rm -v "${PWD}:/project" -w /project python:3.12-slim python scripts/init_config.py
|
||||
```
|
||||
|
||||
切勿把 `.env`、管理员密码、发布签名密钥或源站数据库导出提交到代码库。数据库密码必须为 URL 安全字符或在连接字符串中正确编码。
|
||||
|
||||
## 2. 单机验证
|
||||
|
||||
```bash
|
||||
docker compose up -d --build
|
||||
docker compose ps
|
||||
docker compose logs -f siteforge worker
|
||||
```
|
||||
|
||||
浏览器打开 `http://localhost:8787/`，登录后进入 `/factory-studio`（建站）、`/operations`（CMS 导入、人工复核、构建、审批、发布）、`/theme-gallery`（主题预览）。
|
||||
|
||||
## 3. PostgreSQL + Redis 的企业测试组合
|
||||
|
||||
```bash
|
||||
docker compose -f compose.enterprise.yaml up -d --build
|
||||
docker compose -f compose.enterprise.yaml ps
|
||||
docker compose -f compose.enterprise.yaml logs -f siteforge worker postgres redis
|
||||
```
|
||||
|
||||
这是**新数据库部署**，不要把 V6 的 SQLite 数据卷直接绑定给 V7 的 PostgreSQL 版本。先备份，再制定一次性数据导入和对账计划。`postgres-smoke` CI Job 具有独立临时 PostgreSQL 数据库的基础烟雾测试；当前交付环境无法运行该 Job 或本地 Docker/PostgreSQL。
|
||||
|
||||
Redis 当前只作为通知通道，数据库是任务事实来源，Redis 不提供 Exactly-Once 保障。
|
||||
|
||||
## 4. 接入 Art Design Pro 官方工程
|
||||
|
||||
联网取得官方项目（开源地址：`https://github.com/Daymychen/art-design-pro`），按照官方文档所需 Node.js / pnpm 版本安装：
|
||||
|
||||
```bash
|
||||
python scripts/install_into_art_design_pro.py /path/to/art-design-pro
|
||||
python scripts/install_into_art_design_pro.py /path/to/art-design-pro --apply
|
||||
cd /path/to/art-design-pro
|
||||
pnpm install --frozen-lockfile
|
||||
pnpm build
|
||||
```
|
||||
|
||||
注册菜单：网站项目、主题库、可视化编辑、CMS 迁移、企业运行中心、审批与发布。需要同域代理 `/api`、`/ui`、`/editor`、`/preview`、`/login` 等到 SiteForge，且保留服务端 Session + CSRF。正式交付前要验证前端角色菜单与服务端 RBAC 一致。
|
||||
|
||||
本压缩包**不包含官方 Art Design Pro 整体源代码**；当前 Docker 默认仍运行 SiteForge 内置 Web 后台。
|
||||
|
||||
## 5. 单独部署 Release Agent
|
||||
|
||||
推荐在目标服务器中部署独立 Agent，只授予一个发布目录的写入权限，并在 HTTPS 反向代理和网络白名单后面运行。
|
||||
|
||||
```bash
|
||||
docker compose -f compose.release-agent.yaml up -d --build
|
||||
```
|
||||
|
||||
目标机器 `.env` 配置 `SITEFORGE_DEPLOY_SECRET`（至少 32 字符），控制端配置 `SITEFORGE_DEPLOY_STAGING_URL` 和 `SITEFORGE_DEPLOY_STAGING_SECRET`，或 PRODUCTION 对应值。
|
||||
|
||||
Agent 在容器里使用 `/srv/releases/<site-id>/releases/<hash>/` 保存不可变版本，并通过 `current` 指针切换。外部网站域名应由 Nginx/Caddy 指向该只读版本目录或代理 Agent 的 `/public/<site-id>/...`；需要由运维为每个站点配置域名，当前**不是自动配置 DNS/CDN 的产品**。
|
||||
|
||||
发布接口不是公网通用文件上传：必须经过构建完成、迁移与 HTML 质量检查、独立审批，并使用 HTTPS HMAC 请求签名，签名绑定 HTTP 方法和精确路径，存在 5 分钟的时间戳有效窗口。务必开启 TLS、源 IP 限制和审计日志。
|
||||
|
||||
## 6. CI 与运行验收
|
||||
|
||||
```bash
|
||||
python -m pip install -r requirements-dev.lock
|
||||
python -m pytest -q
|
||||
python scripts/verify_release.py
|
||||
for file in app/static/*.js; do node --check "$file"; done
|
||||
```
|
||||
|
||||
完整 GitHub Actions：`.github/workflows/ci.yml`。包含 Python 3.12/3.13 测试、静态 JavaScript、Docker 镜像及 PostgreSQL 冒烟配置；但必须在你的仓库中真正跑通流水线，确认依赖、容器构建、数据库行为才可标为通过。
|
||||
|
||||
## 7. 升级时的数据保护
|
||||
|
||||
不要 `docker compose down -v`。先备份 SQLite/PostgreSQL、主题、媒体、构建产物及发布历史，再在隔离测试环境进行恢复和预演；确认旧网站 URL/SEO 清单无差异后再切换正式流量。不同 Compose project 的同名卷默认并不共享，升级流程不得靠“覆盖 ZIP”代替数据迁移。
|
||||
@@ -0,0 +1,17 @@
|
||||
# SiteForge Factory 6.0.0 — 功能交付矩阵
|
||||
|
||||
| 模块 | 已经落地的真实功能 | 不能等同于 |
|
||||
|---|---|---|
|
||||
| 新建/多站点 | 站点 CRUD、克隆、独立数据、团队角色 | 大规模租户隔离认证审计认证通过 |
|
||||
| 四套主题 | 14 类页面模板、各主题独立资源、品牌/产品/新闻/案例、菜单、搜索、筛选、图库和主题版本 | 不需人工检查即可直接交付任何行业客户 |
|
||||
| 可视化编辑 | 组件库、布局列、嵌套区块、直接文字编辑、图片上传、响应式预览与全局样式 | Figma 级自由布局、多用户实时协同 |
|
||||
| 内容模型 | 产品/文章/品牌、字段规则、Excel/CSV/JSON 预览与映射、导入冲突报告 | 任意复杂数据零人工识别与完全语义映射 |
|
||||
| WordPress 迁移 | XML/WXR，基本 REST/网页采集，部分 Elementor、WooCommerce 字段，媒体压缩包，源站 URL/SEO 清单 | WooCommerce 变体/订单全量、ACF/Elementor 任意组件像素保真 |
|
||||
| SEO/验收 | URL 基线、meta/Canonical 规则、sitemap、broken link、质量报告、迁移差异 CSV | 搜索引擎排名不变保证，完整 SEO 审计认证 |
|
||||
| 后台 Web | FastAPI + 自带 Web 工作台、可视化设计器、团队权限 | 官方 Art Design Pro 已完整替换 |
|
||||
| Worker | 202 任务、SQLite 持久化队列、超时重试/取消/幂等/租约 | 分布式 HA/Exactly Once 原子发布，完整冻结构建快照 |
|
||||
| 发布 | 构建版本、ZIP、预览、本地目录发布、审核/回滚记录 | 一键全云部署、DNS/CDN 自动控制、灾备 SLA |
|
||||
| Docker | Compose Web/Worker、卷、健康检查、可选 Caddy HTTPS | 实际 Docker 容器在本环境启动/云上压测通过 |
|
||||
| CI | 精确依赖版本锁、GitHub Actions 测试/构建配置 | GitHub Actions 真实运行通过或安全漏洞审计通过 |
|
||||
|
||||
**可验证完成标准（后续正式商业验收）**：汽车和工业两个真实站点分别完成零代码套版、内容录入、旧站路径/SEO 核对、PC/平板/手机真实浏览器测试、询盘服务验证、审批与部署/回滚演练，并提供逐项通过记录。
|
||||
@@ -0,0 +1,22 @@
|
||||
# V4 功能验收矩阵
|
||||
|
||||
| 用户期望 | 本次已实现 | 继续开发/验收 |
|
||||
|---|---|---|
|
||||
| 四套完整行业主题 | 原 V3 的四套主题共 56 组独立模板；V4 追加多级导航、产品图库 Lightbox、可配置 HTTPS 表单和主题兼容性检查 | 专业素材、真实表单接收服务、复杂车型筛选逻辑与视觉优化 |
|
||||
| 可视化组件设计 | 支持编辑器响应式多列布局、列内区块、全页自由布局/追加模式、完整主题预览、可复用组件库 | 自由网格画布、高级排版控制、多人实时协作 |
|
||||
| 内容智能装配 | Excel/CSV/JSON 解析预览、字段别名、车型/能源/续航/图库/参数绑定、关系报告与品牌空页面装配 | 多值关系、多语言和复杂字段映射、AI 语义匹配需人工确认 |
|
||||
| WordPress 迁移 | WXR/REST 等原有路径 + V4 特殊字段转换、SEO 清单、静态构建差异和人工复核机制 | SQL 全库深度适配、复杂插件无损解析及真实站验收 |
|
||||
| 发布前审计 | WXR/sitemap/CSV/JSON 基线；实际 HTML 路由、title、description、canonical、robots、H1 和质量检查；差异 CSV；单条人工接受理由 | 真实 HTTP 状态 / CDN 规则与线上 Google Search Console 指标监控 |
|
||||
|
||||
## 源数据验证标准
|
||||
|
||||
- 未抓取/导出的路径不能自动假设不存在。
|
||||
- HTTP 200 的源路径必须有对应 HTML，缺少会阻断发布。
|
||||
- SEO 源数据缺失时只报告已知差异，不虚构旧站 metadata。
|
||||
- 所有警告必须审核接受或修复后重新构建；结构阻断项不允许直接接受例外。
|
||||
- 复杂 Elementor、ACF、WooCommerce 数据保留原始字段，部分安全转换并列出人工核查项。
|
||||
- 构建产物中不得出现未识别的本地资源/内链错误；外部资源应按实际站点审核是否本地化。
|
||||
|
||||
## 运行安全界限
|
||||
|
||||
本项目不提供 Docker 容器启动成功的保证。不要将默认测试端口直接暴露公网；请配置 HTTPS、限流、备份、生产安全审计。管理中心与客户静态网站独立部署。
|
||||
@@ -0,0 +1,43 @@
|
||||
# SiteForge 6.0.0 — 运维与安全说明
|
||||
|
||||
## 运行架构
|
||||
|
||||
- 单机 Compose：Web（认证及 API）、Worker（后台构建）、独立持久化数据卷、独立已发布文件卷；可选 Caddy HTTPS。
|
||||
- 数据：SQLite WAL；一个站点同时间最多一个运行中的构建任务。长期多节点部署要替换存储和任务中心。
|
||||
- 运行时只需公网暴露经正确配置的 HTTPS 反向代理。请不要把 8787 开放到公网。
|
||||
|
||||
## 日常排障
|
||||
|
||||
```bash
|
||||
docker compose ps
|
||||
docker compose logs --tail=100 siteforge
|
||||
docker compose logs --tail=100 worker
|
||||
docker compose exec siteforge python -c 'from app.version import VERSION;print(VERSION)'
|
||||
```
|
||||
|
||||
正常时 `GET /api/health` 返回 `{"status":"ok","name":"SiteForge","version":"6.0.0"}`。Worker 未运行时 API 可以仍然健康，但构建会停留在 queued；因此应同时监测 Worker 容器。
|
||||
|
||||
## 数据安全
|
||||
|
||||
- 密钥只保存在 `.env` 或平台密钥管理器；生产 HTTPS 将 `SITEFORGE_COOKIE_SECURE=true`。
|
||||
- 管理员密码至少 12 位，团队账号使用 scrypt 密码哈希；启用站点角色。
|
||||
- 发布权限、迁移 SEO 阻断和审核不能仅由客户端判断，必须遵从后端校验。
|
||||
- 不要任意加载第三方 Jinja/JS 主题代码；当前主题导入限制为声明式主题包。
|
||||
- 旧站采集应只针对已获得授权的站点，防止内部网络 SSRF。
|
||||
|
||||
## 备份/恢复
|
||||
|
||||
SQLite 正在运行时不要直接只复制一个 `.sqlite3` 文件；应使用 SQLite 在线备份 API，并同步备份 media、theme_packages、archives、builds、legacy 及部署文件。可先停止维护性写入，再执行卷快照。恢复必须在空白测试部署上演练后才能用于正式生产。
|
||||
|
||||
## V5 升级
|
||||
|
||||
不要运行 `docker compose down -v`，不要覆盖 V5 的数据卷。使用全新 V6 Compose 名称和独立卷，检查账户、旧 URL/SEO、主题固定版本、素材、历史构建、发布根目录，再安排切换。
|
||||
|
||||
## Worker 任务处理
|
||||
|
||||
- 前端构建请求统一 HTTP 202 排队。
|
||||
- `SITEFORGE_BUILD_TIMEOUT_SECONDS` 默认 300，可调整 10–3600 秒。
|
||||
- `SITEFORGE_BUILD_MAX_ATTEMPTS` 默认 3，可调整 1–6。
|
||||
- 用户取消排队任务立即 `cancelled`；运行中进入 `cancel_requested`，Worker 会终止构建子进程并确认状态。
|
||||
- 临时任务错误才会指数退避重试；确定性数据错误标记 failed，避免无用重复尝试。
|
||||
- Worker 领取任务后更新租约；租约过期可能重试任务。对于进程崩溃时未清理的孤儿进程，当前实现尚未保证多机严格一次执行，正式集群版需进程组隔离及分布式租约协议。
|
||||
@@ -0,0 +1,58 @@
|
||||
> 本文件含 V8.8 原始评估内容；V8.9 最新实测数据与剩余门禁以 [V8.9 验收报告](P0_P4_V8_9_VERIFICATION.md) 为准。
|
||||
|
||||
# SiteForge Enterprise V8.9 — P0–P4 实现与验收矩阵
|
||||
|
||||
> 状态：**集成开发版，不是生产验收完成版**。本文件依据《COMPLETION_PLAN(1).md》v2.0 的 P0–P4 验收要求，结合 V8.8 源码与 V8.9 新增的导入、性能、恢复及媒体回归编写。文档历史记录（原源码 v5、运行 v4）不等于本工程当前运行事实。
|
||||
|
||||
## 本轮实质交付
|
||||
|
||||
1. **按设备调整真正的多列布局**：`layout` 区块现在分别支持平板 1–3 列、手机 1–2 列；每列单独设置顺序、跨列、显隐；子组件支持已有响应式样式。规则校验后构建成静态 CSS。为防整站模板复制后 ID 冲突，按网站页面路径哈希作用域隔离 CSS。
|
||||
2. **整站套版增加审核态**：后台原“确认应用”改成“暂存 → Owner 发布”；发布时必须验证草稿版本与整站布局指纹；若网站被其他人修改，返回 409，不静默覆盖。
|
||||
3. **多页套版原子化**：使用同一个数据库事务修改全部页面和网站主题/导航；执行中失败后整体回滚；拒绝覆盖仍存在的页面/全站草稿。新页面默认草稿状态、`noindex,follow`，不伪造 SEO 与客户数据。
|
||||
4. **路径与媒体修复**：区块 CTA、图片等使用根路径；编辑器预览使用 `/local-media/{site}/{file}`；新增站点媒体库选择与画廊/轮播添加入口。
|
||||
5. **样式白名单收口**：背景色严格为六位十六进制；间距为 0–120 的整数，显隐为布尔值；防止无效 CSS 或任意表达式进入构建器。
|
||||
6. **版本、Compose、CI 断言统一**：`8.9.0-dev.1`；修复旧 `siteforge-v8-6` Compose 项目名遗留问题；保留独立 Worker 健康检查与测试脚本。
|
||||
|
||||
## 对《COMPLETION_PLAN(1).md》逐项判断
|
||||
|
||||
符号：✅ 已有代码及本地测试；◐ 部分实现/缺实机验收；❌ 未完成。
|
||||
|
||||
| 阶段 | 需求 | 现状 | 阻断生产交付的剩余工作 |
|
||||
|---|---|---|---|
|
||||
| P0 | 版本标识、预览根路径、favicon、Worker 健康 | ✅/◐ | 目标机上镜像摘要、实际浏览器、回滚演练尚未验证 |
|
||||
| P0 | 一键 Compose 构建/启动、备份恢复、跨平台 CI | ◐ | Docker Engine 实机及 GitHub Actions 真正运行、旧数据库升级演练 |
|
||||
| P0 | 真实凭据轮换 | ❌ | 运维方需要在自己环境轮换管理员口令、Session、第三方 Secret，不能通过打包源码代替 |
|
||||
| P1 | 数据库迁移登记、Worker 幂等/超时/取消/重试/容量 | ◐ | SQLite 迁移登记已有；旧表的完整版本迁移、多个 Worker 并发/死信恢复仍不完整 |
|
||||
| P1 | 安全出网、密钥引用、日志、资源上限 | ◐ | 核心 HTTP SSRF 规则和密钥引用已有；生产密钥轮换、告警、各协议审计仍待实机 |
|
||||
| P2 | WordPress REST/WXR、Sitemap、检查点、媒体 | ◐ | 公开文章、页、分类、标签、有限媒体已支持；私有内容与任意 Elementor/ACF/WooCommerce 结构不能保证无损 |
|
||||
| P2 | 全 URL/SEO/媒体基线及统一迁移向导 | ◐ | 有 URL/SEO 比较和复核；需要本地综合夹具、真实授权 WP 站点全流程验收，复杂媒体 CSS/srcset 适配继续开发 |
|
||||
| P3 | Excel/CSV/JSON/XML/API/只读 MySQL | ◐ | 有暂存、映射、工作任务、关系预览与回滚；真实 MySQL TLS、5000 条数据容量、API 密钥轮换仍待验收 |
|
||||
| P3 | 安全 XML/ZIP 与批次完整回滚 | ◐ | XXE/压缩限制与受保护回滚已有；更复杂文件与异常恢复需故障注入测试 |
|
||||
| P4 | 受控声明式区块/主题预设 | ✅ | 有组件白名单、四套主题、模板预检及安全渲染；实际视觉质量需正式素材验收 |
|
||||
| P4 | 页面/全站草稿与正式构建隔离 | ✅/◐ | 页面草稿/全站草稿已隔离，整站模板现在具备暂存及 Owner 发布；旧批量生成入口仍需全面权限梳理 |
|
||||
| P4 | PC/平板/手机不同布局 | ◐ | 现在支持区块间距/显隐与布局列数/跨列/排序；不等于三套完全独立可拖拽画布 |
|
||||
| P4 | 整站模板可复制、回退、兼容检查 | ◐ | 已预检、模板暂存与原子应用；模板版本升级兼容和视觉回归、全站变更历史回退仍不完整 |
|
||||
| P4 | Chrome 桌面/平板/390px/360px 回归与无障碍 | ❌ | 需真实浏览器交互、键盘流程及系统性视觉回归；当前环境未完成 |
|
||||
|
||||
## 不应误报为完成的需求
|
||||
|
||||
- 正式 **Art Design Pro 官方工程**整合与编译：未完成。当前仍以现有 Web 后台为主。
|
||||
- PostgreSQL/Redis 的高可用和多实例：非 P0–P4 生产验收范围，也尚未完成；企业 Compose/兼容层不能代替实测。
|
||||
- SFTP/S3 正式发布、生产回滚、多语言：P5–P7 尚待后续独立交付。
|
||||
- 任意 WordPress 插件的像素级还原：不承诺。必须按特定站点/组件制定转换规则和复核结果。
|
||||
|
||||
## 已执行的验证
|
||||
|
||||
- Python 自动化回归，包含 V8.8 新增的响应式布局、复制模板、草稿不泄漏、两步应用、旧站改动拒绝、事务失败回滚、内页链接及媒体路径等专项测试。
|
||||
- `scripts/verify_release.py`、JavaScript `node --check`、Python 编译、源码 ZIP 完整性；以上以实际最后一次运行结果为准。
|
||||
- **未执行**：真实 Docker Engine 启动、GitHub Actions 云端运行、正式浏览器和移动设备视觉测试、授权 WordPress 实站迁移、远程发布故障恢复、真实 MySQL TLS。
|
||||
|
||||
## 达到 P0–P4 完全验收的明确条件
|
||||
|
||||
需在安装好的测试服务器上完成：`docker compose up -d --build` 一条命令通过；`/api/health` 和镜像版本相符；360/390/1024/1440 像素交互验收；5000 行内容导入与批次中断恢复；WordPress REST/WXR/Sitemap/媒体综合本地夹具及一个授权实站；四主题整站草稿、模板套用、构建前后隔离；密钥轮换、安全审计、数据库备份与恢复。每项有可重复报告，未过项不能标记为生产完成。
|
||||
|
||||
## V8.9 补充（以新报告为准）
|
||||
|
||||
- 已加入 P0 备份先验证后恢复、P2 WordPress 响应式媒体路径、P3 站点级品牌/分类缓存和 100 条分页、P3 性能夹具、P4 静态质量与模板回归测试。
|
||||
- 5,000 条同分类测试，技术构建生成 50 个分类分页和 50 个产品中心分页；独立静态 QA 扫描 5,191 HTML，`errors=0`。详细警告与环境限制参见 `P0_P4_V8_9_VERIFICATION.md`。
|
||||
- **仍不满足 P0–P4 全面上线门禁**：真实 Docker、GitHub CI、各设备浏览器、授权 WordPress 站点、真实 MySQL TLS、密钥轮换/高可用尚未实机验收。
|
||||
@@ -0,0 +1,52 @@
|
||||
# SiteForge Enterprise V8.9 — P0–P4 优化及真实验收证据
|
||||
|
||||
**版本**：8.9.0-dev.1（2026-10-22）
|
||||
**状态**：开发与离线集成测试已完成一轮；**不是 P0–P4 全部生产验收通过**。
|
||||
|
||||
## 已在当前环境验证的实际成果
|
||||
|
||||
| 阶段 | 具体修改 | 已执行验证 | 仍待完成 |
|
||||
|---|---|---|---|
|
||||
| P0 | 离线备份恢复先检查所有 ZIP 路径、范围、符号链接、SQLite 完整性；旁路暂存并目录切换；保存恢复前原目录 | 正常恢复、存在旧目录、损坏 DB、非法 ZIP 路径和保留原目录专项测试 | Docker Engine 一键启动、旧版本真实数据升级/回滚、管理员及 Session 密钥轮换、GitHub CI 真正运行 |
|
||||
| P1 | 延续 V8.8 安全出网、密钥引用、限额、Worker 超时/幂等/取消/租约；本轮未声称做完 P1 所有基础设施 | 所有旧测试继续通过；回归建站、授权和任务接口 | 正式密钥轮换/吊销、完整可观测性及告警、数据库迁移注册表完备性与多 Worker 故障演练 |
|
||||
| P2 | WordPress 额外识别 `img srcset/data-src/data-srcset`、`picture source srcset`、懒加载与视频 poster；仅安全同源图片自动下载；保留响应式尺寸描述、远端 CDI/跨域资源待复核 | 响应式媒体 URL 发现、重写保真、剩余 CDN 识别、既有迁移用例 | CSS `background-image`、私有附件、Elementor/ACF/WooCommerce 任意复杂结构、经授权真实 WP 站点全量迁移 |
|
||||
| P3 | 构建器对产品品牌/分类预构建索引；商业就绪与静态 QA 流式扫描；真正用 5,000 条车型分 10 批提交及构建 | 5,000 条记录 10×500 完整提交（14.34s）；静态构建产生 5,043 个 HTML（26.01s）；优化后的独立质量扫描（6.5s，错误 0） | 多种数据形状压测（如 5000 个同分类页面）、真实 MySQL TLS/外部 API、并发导入及断点故障注入、商业 SEO 数据清洗 |
|
||||
| P4 | 维持现有手机/平板独立列、草稿和整站模板发布；新增构建器索引缓存防止模板渲染多次遍历全库，静态 QA 防路径穿越 | 原有页面设计、事务、草稿/正式隔离测试持续通过 | 实际 360/390/1024/1440 浏览器截图/键盘操作/视觉回归，任意设备自由画布与全站历史撤销 |
|
||||
|
||||
## 5,000 条测试的注意事项
|
||||
|
||||
- 测试数据是**本地虚构车型数据**，并未连接真实 MySQL，也没有在 Docker 容器中执行。
|
||||
- 用 10 批各 500 条执行真正的 `stage → commit`，不是只把测试数据插进数据库。合计 5,000 条记录。
|
||||
- 静态构建成功生成 5,043 个 HTML 文件。质量扫描 `errors=0`，但原始测试数据有 **5,039 条 SEO/描述等 warning**；这意味着技术上可生成，不代表可以直接商业上线。
|
||||
- **本轮后续修复**：新增每页 100 条的静态分页，包括同一分类和默认 `/products/` 产品中心。5,000 条同一分类的隔离数据库构建生成了 50 个分类分页、50 个产品中心分页，构建约 29.59 秒；该构建的独立 QA 约 6.67 秒，扫描 5,191 个 HTML，错误为 0，但保留 5,039 条内容/SEO 警告。未经正式内容清洗不得对外上线。
|
||||
- 可复现的程序：`python scripts/pilot_5000.py --report pilot.json`。默认只执行 5,000 条导入，使用临时数据库，不覆盖现有数据；在独立大内存测试机加 `--build` 执行全部构建/QA，需单独验收耗时、资源峰值与 Worker 超时。
|
||||
|
||||
## 新代码位置
|
||||
|
||||
- `app/wp_migration_v82.py` — 图片候选、响应式 URL 改写与待复核。
|
||||
- `app/theme_pro.py`、`app/builder.py` — 站点级商品/品牌/分类预计算。
|
||||
- `app/commercial_readiness.py`、`app/quality.py` — 线性读取与静态 QA 路径索引。
|
||||
- `scripts/restore_backup.py` — 离线预检、目录恢复及保留原目录。
|
||||
- `scripts/pilot_5000.py` — 5,000 条独立验收脚本。
|
||||
- `tests/test_p0_p4_completion_v89.py` — 回归测试。
|
||||
|
||||
## 发布门禁与运维限制
|
||||
|
||||
- **尚不能标记 P0–P4 生产验收全部完成**。开发代码没有目标服务器镜像摘要、跨浏览器体验、授权客户 CMS 全量迁移及故障恢复证据，不能代替这些检查。
|
||||
- 生产恢复必须事先停止 Web/Worker。新恢复脚本仅适用于 SQLite 的单机卷；如果使用 PostgreSQL，需要独立 pg_dump / 迁移/恢复方案。
|
||||
- 不应提前启用 P5 远程自动发布生产域名；必须先完成 P0–P4 的上线门禁并验证旧网址和 SEO。
|
||||
|
||||
## 实际验证步骤
|
||||
|
||||
```bash
|
||||
python -m pytest -q
|
||||
python scripts/verify_release.py
|
||||
python -m compileall -q app scripts
|
||||
bash scripts/check.sh
|
||||
python scripts/pilot_5000.py --report pilot.json
|
||||
# 仅在有 Docker Engine 的服务器执行：
|
||||
docker compose up -d --build
|
||||
curl -fsS http://127.0.0.1:8787/api/health
|
||||
```
|
||||
|
||||
以上 Docker、真机浏览器及真实外部 WordPress/MySQL 步骤在本次执行环境**未完成**。
|
||||
@@ -0,0 +1,17 @@
|
||||
# SiteForge 企业正式生产化清单
|
||||
|
||||
本项目实现了单机 Docker Web 形式的网站生产核心功能。要达到大型企业多团队多环境长期运行标准，还应完成如下工程工作（不属于本次已验证能力）：
|
||||
|
||||
1. **数据库和队列**：从当前 SQLite WAL 单实例升级到 PostgreSQL（Alembic 迁移、多租户行级访问控制、连接池）和 Redis/RabbitMQ + Worker；构建任务幂等、重试退避、死信队列、任务超时和容量控制。
|
||||
2. **账号与认证**：接入 OIDC / SSO、MFA、账号生命周期、细粒度角色审批、管理员紧急停用和会话撤销。当前 Cookie 签名在有效期内仍需账户禁用验证。
|
||||
3. **审计不可抵赖**：当前审计日志与主库共存，应写入追加型独立日志、配置审计保留策略和异地日志汇聚。
|
||||
4. **主题市场与沙箱**：严格的主题 Manifest 版本约束、组件兼容性、预览沙箱、第三方主题供应链签名、模板回滚和主题资产扫描。
|
||||
5. **高级可视化编辑**：页面级断点独立控制、样式变量冲突检测、组件属性 Schema、草稿分支、多人冲突锁、预览审批，避免用户自定义不受控的 HTML/JS。
|
||||
6. **大型 CMS 迁移**：WordPress 数据库/ACF/Elementor/WooCommerce 扩展适配器、Drupal、Joomla、Shopify/Headless CMS 权限 API、分页重试和导入幂等；开放页面爬虫不可替代私有源数据。
|
||||
7. **静态 QA**：旧站抓取 URL 完整性（包含状态码/Canonical/Hreflang/HTTP 缓存/结构化数据）、手机/桌面视觉差异、在线域名上线后的真实 301/404 响应检查，Search Console 监测。
|
||||
8. **安全**：运行时镜像与 Python 包漏洞扫描、供应链锁文件、SSRF DNS pinning / 网络 egress ACL、文件解析沙箱、病毒扫描、限流共享 Redis、CSP/安全响应头、DNS/CDN 变更审批。
|
||||
9. **发布管道**：Nginx/Caddy/对象存储/CDN 多提供商部署器、同步版本清单、预部署审核、流量切换、回滚、不同环境变量密钥管理。
|
||||
10. **运维 SLO**：Prometheus/OpenTelemetry、集中日志、异常报警、备份异地与还原演练、容量规划、真实 Docker/Kubernetes 压测及 RPO/RTO 目标。
|
||||
11. **Art Design Pro 官方集成**：取得有权使用的 Art Design Pro 版本源码，按对应版本路由/权限系统接入并在 Node 构建环境完整测试、验证其许可证要求。
|
||||
|
||||
建议实施顺序：正式试点环境 → 真实 WP 站迁移基线验收 → PostgreSQL/队列 → Art 前端正式整合 → 安全审计 → 大型网站灰度发布。
|
||||
@@ -0,0 +1,29 @@
|
||||
# SiteForge V2 六大优先级 · 开发交付与验收状态
|
||||
|
||||
最后核对：2026-10-21。本文件用“已实现/基础实现/未实现/未验证”分别记录，不把开发代码视为已通过生产验收。
|
||||
|
||||
| 用户要求 | 当前交付的可用能力 | 尚需继续的功能 | 状态 |
|
||||
|---|---|---|---|
|
||||
| ① 完整主题 | 四套独立设计、9 类页面预设、导航/响应式页脚、静态搜索和筛选、上传声明式主题 ZIP、版本管理、预览、站点固定版本 | 更完善的商业设计资产、更多独立布局组件、高级导航交互、行业专题详情定制 | 基础实现，视觉未商业验收 |
|
||||
| ② 可视化编辑 | 区块拖拽排序/增删/复制、图片上传、预览双击文字编辑、PC/平板/手机布局差异、设计 Token、构建实时生效 | 任意布局嵌套/多层栅格、任意元素拖放、实时协同、完整撤销/重做、复杂动画 | 结构化区块编辑已实现 |
|
||||
| ③ 内容智能装配 | 产品/车型/品牌映射、字段别名识别、规则保存、CSV/JSON 映射预演、冲突报告、实际导入、内容关联列表和详情 | 多层关联复杂自动识别、AI 语义识别、全量 Excel/数据库字段映射后台工作流和数据质量分析 | 规则式自动装配已实现 |
|
||||
| ④ 完整旧站迁移 | WP WXR/REST、公开爬取、CSV/XLSX/JSON、ACF/Woo 部分字段、原 URL 基线、SEO 差异/404/资源质量检查、发布门禁 | Elementor 深度重构、完整 Woo 业务数据、非 WP 专有 CMS/数据库深度迁移、真实网站逐页验收 | 基础迁移，**不保证无损** |
|
||||
| ⑤ 正式 Art Design Pro | Vue3 业务页面与官方工程离线接入脚本；完整可用原生 Web 控制台 | 官方完整工程及依赖集成、前端生产构建、路由与登录权限同构、官方 UI E2E | **尚未正式完成** |
|
||||
| ⑥ 企业级发布运维 | 登录 RBAC、操作审计、异步 Worker、双人审批、本地发布、版本回滚、Docker Compose 数据卷 | PostgreSQL/Redis、多实例高可用、远程发布/HTTPS/CDN、监控告警、压测/渗透/容灾演练 | 基础交付，**未完成生产化** |
|
||||
|
||||
## 本次可以跑通的闭环
|
||||
|
||||
- 从空白新建站点 → 初始化标准栏目 → 添加/导入内容 → 选择主题 → 设计区块 → 构建 → 预览 → 导出静态站。
|
||||
- 旧站内容按字段导入 → URL 和 SEO 基线 → 更换主题 → 检查是否丢页 → 审批 → 本地发布。
|
||||
- 一个账号仅能管理授权网站；不同账号申请与审批。新增版本后原内容保持可追溯。
|
||||
|
||||
## 生产发布前的强制验收
|
||||
|
||||
- [ ] 真实 Docker 环境完成 Compose 构建与 Web/Worker 启停验证。
|
||||
- [ ] Art Design Pro 官方代码整合并通过 `pnpm build`、浏览器验收（若坚持用它作为唯一后台）。
|
||||
- [ ] 数据卷、数据库升级方案、异地备份和恢复演练。
|
||||
- [ ] 真实旧站全量 URL/SEO/资源清单与新站差异报告无未处理阻断项。
|
||||
- [ ] 登录/权限/CSRF/SSRF/上传文件安全检查和渗透测试。
|
||||
- [ ] CDN/HTTPS/多域名发布、回滚、容量和性能验收。
|
||||
|
||||
**结论：这是可继续扩展的 V2 开发集成版本，不等于六项要求全部生产级完成。**
|
||||
@@ -0,0 +1,28 @@
|
||||
# SiteForge Factory 7.0.0 — 开发验收结果
|
||||
|
||||
**基础**：继承 V6 的网站创建、主题、编辑器、字段映射、旧站 SEO、静态构建及 Worker 任务稳定性能力。
|
||||
|
||||
## 本版新增
|
||||
|
||||
- 四类 CMS 的 JSON 适配预演/导入；复杂插件与关系字段提示由一次性响应改为持久化复核流程。
|
||||
- Web `/operations` 与 Art Design Pro `MigrationCenter.vue` 新增复核和问题处理入口。
|
||||
- 发布 API 修复未完成构建误放行；完整构建、迁移差异、未处理事项、静态资源检查和独立审批按部署路径执行。
|
||||
- 远程 Release Agent 的签名绑定 HTTP method + URL path，避免读请求签名跨端点执行状态变更。
|
||||
- 四套商业主题的空白标准栏目自动生成 noindex 占位，不让新网站菜单出现空 404。
|
||||
- 版本信息统一 7.0.0（主题各自版本为 1.1.0），基本 CI、Python 依赖锁及 V7 Docker Compose 保留。
|
||||
|
||||
## 本环境实际验证
|
||||
|
||||
- **74 项 Python 自动化测试通过**（包括旧站测试回归、发布闸门、CMS 复核、请求签名防跨路径复用、Art 菜单安装器的模拟工程、生成页面零阻断断链测试）。
|
||||
- `scripts/verify_release.py` 通过；Node.js JS 语法检查通过。
|
||||
- 真实启动 Uvicorn 与独立 Worker，通过 HTTP 验证登录、创建网站、异步构建、预览和 ZIP 导出。
|
||||
|
||||
## 尚未验证 / 尚未完成
|
||||
|
||||
- Docker Engine 容器实机启停及 PostgreSQL/Redis 同步数据库压力与故障转移；PostgreSQL 适配属于兼容实现，不是成熟 HA。
|
||||
- 官方 Art Design Pro 源码构建：当前环境无法直接下载官方仓库或 npm 依赖；交付六个业务模块与安装器，但无法宣称官方完整集成。
|
||||
- WooCommerce 复杂变体与订单、Elementor 任意布局、ACF 全关系、多 CMS 私有接口等无损迁移。
|
||||
- 公网 TLS 域名、正式发布 Agent、生产 CDN/DNS 和灰度/备份容灾实际演练。
|
||||
- 全自由画布、在线多人协作编辑、真实客户网站的设计、性能与 SEO 验收。
|
||||
|
||||
**结论**：可用于受控测试环境与试点项目开发，尚不属于可对任意复杂站点承诺无损迁移和高可用 SLA 的生产认证产品。
|
||||
@@ -0,0 +1,38 @@
|
||||
# SiteForge Factory V7 — 用户需求逐项对照
|
||||
|
||||
> 本文件结合《SiteForge 智能网站工厂完整产品与技术方案 V2.0》、此前 V5/V6 开发说明，以及本轮四个重点：Art Design Pro、可视化编辑、复杂 CMS、PostgreSQL/Redis 与正式发布。状态以当前源码和可执行测试为准，不以页面按钮数量或方案描述代替验收。
|
||||
|
||||
| 用户目标 | 当前可执行实现 | 仍需完成/验收 | 状态 |
|
||||
|---|---|---|---|
|
||||
| 新站生产 / 旧站换新主题 | 多站点、内容 CRUD、4 套主题、标准栏目、构建、版本/ZIP | 实际客户素材、真实站点 UI/SEO 验收 | 基础可用 |
|
||||
| 完整主题与版本 | 汽车、工业、企业、极简主题；独立页面模板、搜索/分类/品牌、版本锁定 | 多行业精修、交互与表单服务验收 | 核心可用 |
|
||||
| 可视化页面编辑 | 区块、嵌套列、拖动、文字及图片属性、全局样式、设备宽度、撤销重做 | 任意层级自由画布、团队协作、真实设备测试 | 部分实现 |
|
||||
| 自动装配内容 | Excel/CSV/JSON 字段映射、品牌分类关联、主题内容重用 | 未知字段语义识别、复杂关系无人工装配 | 部分实现 |
|
||||
| WordPress及其他CMS迁移 | WXR/XML、部分 Elementor、公开 REST/WooCommerce、Drupal JSON:API、Shopify JSON | ACF/Elementor/WooCommerce 全类型、订单/变体、私有数据/媒体专用适配；实际站点逐项验收 | 部分实现 |
|
||||
| URL/SEO保真 | 旧站 URL 清单、SEO 差异、缺失页面/资源/内链报告；发布前基线检查 | 真实大型旧站全量核对、重定向语义与搜索引擎监控 | 验收流程可用，无法承诺100%无损 |
|
||||
| 导入异常人工复核 | **V7** 持久化 CMS 字段/关系警告、后台复核记录、迁移站阻止带未处理项发布 | 深度字段自动修复 | 已实现 |
|
||||
| Art Design Pro | 六个 Vue3 + Element Plus 业务页面、官方工程安装/路由脚本 | **仍未包含官方源码**；需外部联网获取仓库、执行 pnpm 构建、统一认证及权限菜单联调 | 尚未正式整合 |
|
||||
| PostgreSQL | **V7** PG 访问兼容层、独立 Compose、CI PostgreSQL 冒烟脚本 | 旧 SQLite 数据迁移、真实容器运行、并发事务/压力、高可用 | 可选测试路径，未生产验收 |
|
||||
| Redis | **V7** Redis 通知/唤醒 Worker，任务持久状态仍在数据库 | Redis 主队列/outbox、可靠分布式扩容、监控指标 | 部分实现 |
|
||||
| Worker与任务稳定性 | 统一构建任务、幂等、重试、取消、超时、租约、独立子进程 | 构建输入冻结快照、多节点 Exactly-Once 效果、孤儿进程收敛 | 单机已验证 |
|
||||
| 正式发布与回滚 | **V7** HTTPS HMAC 签名 Agent、发布审批、质量/迁移闸门、文件版本与回滚 | 公网域名/TLS、远程服务器及 CDN/DNS、灰度、备份容灾、安全审计 | 代码可用，待实机验收 |
|
||||
| 商业交付把关 | 主题交付清单；构建时生成 `noindex` 的空栏目防断链 | 正式 Logo、图片版权、联系方式、法务、性能真实站验收 | 验收框架可用 |
|
||||
|
||||
## V7 新增的安全与闭环修复
|
||||
|
||||
1. 发布只接受 `status=complete` 的构建版本；未完成、失败或未知状态一律拒绝。
|
||||
2. CMS 特殊字段警告存入 `cms_import_reviews`，需要具备复核权限的人员填写至少 12 字的真实核查结论。
|
||||
3. 迁移站发布时重新检查 URL/SEO 基线，以及所有未处理 CMS 复核事项。
|
||||
4. 发布签名绑定请求时间戳、站点、HTTP 方法、精确路径、正文哈希；防止只读签名跨操作复用。
|
||||
5. 当主题导航含标准栏目但网站尚未录入相关内容时，生成明确 `noindex` 的占位页，避免导航产生 404；它们不能当成商业已完成页面。
|
||||
6. 本地发布和远程发布都检查完成状态与静态 HTML 质量；远程还要求独立审批。
|
||||
|
||||
## 发布准入建议（严格）
|
||||
|
||||
- 所有原 URL/SEO 例外已得到检查、修复或有记录的人工裁决。
|
||||
- 空栏目已填充正式内容，并移除不必要的 `noindex`；真实图片/Logo/表单接收器/联系渠道已验证。
|
||||
- 真实浏览器在 PC/平板/移动端完成交互与视觉验收。
|
||||
- 经另一名审核人批准，且构建和发布文件的记录与校验信息一致。
|
||||
- 备份与回滚演练成功后再接入正式域名。
|
||||
|
||||
**重要**：74 项本地自动化测试通过不等于已通过上述真实生产验收。当前环境缺少 Docker Engine、实际 Art Design Pro 官方仓库及生产 PostgreSQL/Redis 服务。
|
||||
@@ -0,0 +1,905 @@
|
||||
# SiteForge 智能网站生产工厂
|
||||
|
||||
> **完整产品需求与技术架构方案（PRD + Architecture + Implementation Plan）**
|
||||
> 版本：V2.0（对 V1.0“通用多站点迁移与静态建站平台”的定位升级）
|
||||
> 日期：2026-10-21
|
||||
> 状态：产品与研发规划版
|
||||
> 适用：产品经理、设计师、前后端研发、测试、运维、Claude 等编程助手
|
||||
|
||||
---
|
||||
|
||||
## 0. 核心定义与产品定位
|
||||
|
||||
**SiteForge 不只是旧网站迁移工具，而是“网站工厂（Website Factory）”：以模板、数据、页面结构和站点配置为原材料，经过装配、构建、验证和发布，持续生产完全独立的网站。**
|
||||
|
||||
网站可以：
|
||||
|
||||
1. **旧站改造**：从 WordPress、其他 CMS、自研 PHP 或普通网站导入既有内容，选用全新主题，保留旧站 SEO 和 URL，重建设计不同的静态网站。
|
||||
2. **模板建站**：没有旧站，选择行业模板，填入企业资料、Logo、产品、文章和媒体文件，直接形成新站。
|
||||
3. **数据建站**：从 Excel/CSV/JSON/XML、API、数据库或图片资料批量导入新内容，自动建立内容类型和页面，匹配模板生成网站。
|
||||
4. **自由建站**：从空白项目开始创建导航、页面、区块、数据集合、主题和页面规则；最终保存为可复用的新模板。
|
||||
5. **混合建站**：上述方式可自由组合，例如“旧站文章 + 新 Excel 产品 + 新模板 + 自定义页面”。
|
||||
|
||||
统一原则：**内容和视觉彻底分离，迁移和新建使用同一个内容模型、页面装配器、静态构建器、质量检测及发布系统。**
|
||||
|
||||
### 0.1 产品成功标准
|
||||
|
||||
- 非迁移用户也能完整创建、编辑、构建并发布一个新网站。
|
||||
- 旧站迁移不是复制旧视觉，而是按“内容映射 → 新主题 → 全新网站”装配。
|
||||
- 同一份数据可以切换不同主题、重复构建；主题切换不得无故删除内容。
|
||||
- 一份设计可以保存为模板；模板升级不能未经确认覆盖站点定制内容。
|
||||
- 多网站独立运行、互不影响；输出静态文件后生产站不依赖中心平台在线。
|
||||
- 迁移站保留需要保留的 URL、SEO、链接和媒体访问行为；全新站可自由制定 URL/SEO 策略。
|
||||
- 导出物有真实 HTML/CSS/JS/媒体、必要的路由/重定向/服务器配置，而非只提供开发框架项目。
|
||||
|
||||
### 0.2 非目标与边界
|
||||
|
||||
- 不是承诺对任何公开 URL 一键获得不可见的后台、私有数据或完整业务代码。
|
||||
- 不是将所有交互功能硬转为静态 HTML；账号、支付、订单、实时库存、复杂搜索等需要独立 API/服务。
|
||||
- 不是初期一次性建成可对任意复杂页面精准拖拽设计的通用 Webflow 类编辑器。
|
||||
- 不保证迁移后搜索排名零波动；系统负责风险降低、可追溯验证和监测。
|
||||
|
||||
---
|
||||
|
||||
## 1. 四大建站入口与混合生产工作流
|
||||
|
||||
| 模式 | 起始条件 | 用户主要步骤 | 输出 |
|
||||
|---|---|---|---|
|
||||
| A 旧站重建 | 有旧网站 | 识别旧站 → 导入内容/SEO/URL → 选主题 → 映射 → 预览 → 构建 → 发布 | 新设计的独立网站 |
|
||||
| B 模板新建 | 无旧站 | 选行业模板 → 填公司信息 → 导入或新增内容 → 配置栏目 → 预览 → 发布 | 全新网站 |
|
||||
| C 数据驱动 | 有 Excel/API/数据库 | 导入数据 → 字段映射 → 生成内容集合 → 选模板 → 自动建立列表/详情页 → 发布 | 数据驱动批量页面网站 |
|
||||
| D 空白搭建 | 需要自主设计 | 创建站点 → 可视化组装页面 → 配置设计变量/数据 → 预览 → 发布 → 沉淀为模板 | 定制网站与可复用模板 |
|
||||
|
||||
### 1.1 “继续生产”能力
|
||||
|
||||
网站创建完后可继续：新增文章和产品、批量导入新数据、替换 Banner、维护多语言、增删栏目、修改 SEO、调整主题样式、升级组件、局部/全站重建、回滚到旧版本。**迁移任务完成不等于站点项目结束。**
|
||||
|
||||
### 1.2 三个关键产品动作
|
||||
|
||||
- **Create Site**：从空白、模板或克隆既有站点结构新建。
|
||||
- **Import Content**：随时将旧站、文件、API 等数据导入现有站点，映射、去重、合并和校验。
|
||||
- **Build & Publish**：将某一明确的数据版本 + 主题版本 + 站点配置打包成可追溯静态发布版本。
|
||||
|
||||
不能把“导入网站”与“创建网站”绑定成一对一：一个站点允许多个数据源，一个数据源也可按授权复用到多个站点。
|
||||
|
||||
---
|
||||
|
||||
## 2. 总体架构：三条输入管线、一个生产流水线
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
subgraph Inputs[网站生产输入]
|
||||
I1[旧站导入：WP/CMS/PHP/HTML]
|
||||
I2[新内容导入：Excel/CSV/JSON/API/媒体]
|
||||
I3[从零创建：内容编辑器/页面编辑器]
|
||||
end
|
||||
subgraph Core[SiteForge 网站工厂控制中心]
|
||||
C1[通用内容中心 / 媒体中心]
|
||||
C2[模板市场 / 主题设计系统]
|
||||
C3[页面编辑器 / 页面装配规则]
|
||||
C4[网站蓝图 Site Blueprint]
|
||||
C5[URL / SEO / 多语言规则]
|
||||
C6[任务引擎 / 版本 / 权限]
|
||||
end
|
||||
subgraph Pipeline[网站生产流水线]
|
||||
P1[数据校验与字段映射]
|
||||
P2[站点装配与路由解析]
|
||||
P3[静态构建 HTML/CSS/JS]
|
||||
P4[预览 / SEO / 功能 / 链接检查]
|
||||
P5[发布 / ZIP 导出 / 回滚]
|
||||
end
|
||||
I1 --> P1
|
||||
I2 --> P1
|
||||
I3 --> C1
|
||||
P1 --> C1
|
||||
C1 --> C4
|
||||
C2 --> C4
|
||||
C3 --> C4
|
||||
C5 --> C4
|
||||
C6 --> C4
|
||||
C4 --> P2 --> P3 --> P4 --> P5
|
||||
P5 --> S[独立运行的网站 A / B / C ...]
|
||||
```
|
||||
|
||||
### 2.1 控制面与生产面分离
|
||||
|
||||
控制面：SiteForge 后台、API、数据/媒体资产、模板、采集、构建任务、发布/审核。生产面：各网站独立的静态文件/CDN/Nginx 与可选独立业务 API。**线上网站运行不要求 SiteForge API 或数据库常驻可用。**
|
||||
|
||||
### 2.2 “网站”并不是“主题”
|
||||
|
||||
一个网站由以下因素组合：
|
||||
|
||||
```
|
||||
Website Release =
|
||||
Site Configuration
|
||||
+ Site Blueprint (页面/栏目/菜单/区块/路由规则)
|
||||
+ Theme & Component Version
|
||||
+ Content Snapshot
|
||||
+ Asset Snapshot
|
||||
+ SEO & Redirect Rules
|
||||
+ Environment & Build Settings
|
||||
```
|
||||
|
||||
这是保证可重复构建、主题更换和版本回滚的核心公式。
|
||||
|
||||
---
|
||||
|
||||
## 3. 关键领域模型（必须从第一天设计好）
|
||||
|
||||
### 3.1 Site（站点）
|
||||
|
||||
唯一站点 ID、站点类型、语言/地区、域名、环境、数据源、主题引用、权限、发布策略。
|
||||
|
||||
### 3.2 Site Blueprint（网站蓝图）
|
||||
|
||||
蓝图描述**网站结构而不是内容本身**：
|
||||
|
||||
- 页面树：主页、关于我们、联系方式、服务、产品、新闻、品牌、活动等。
|
||||
- 导航树：顶部主导航、Mega Menu、页脚、移动导航。
|
||||
- 页面类型：普通静态页、内容集合列表、集合详情、分类聚合、专题页。
|
||||
- 路由规则：固定页 slug、列表分页、产品 URL 格式、语言前缀。
|
||||
- SEO 规则：title 模板、canonical、sitemap/noindex、结构化数据类型。
|
||||
- 区块编排：Banner、产品网格、优势、表单、统计、FAQ、CTA 等。
|
||||
- 设计变量：品牌色、字体、布局宽度、间距、圆角、响应式断点。
|
||||
- 模板绑定：哪个页面类型使用哪套布局及组件。
|
||||
- 功能扩展：搜索、询盘、表单、在线聊天、外部 API 等。
|
||||
|
||||
站点蓝图可以从模板初始化，也可以由编辑器独立创建；保存之后属于站点自身，主题升级不得悄悄覆盖人工更改。
|
||||
|
||||
### 3.3 Content Type（内容类型）与 Entry（内容条目）
|
||||
|
||||
内容中心不能硬编码只支持“文章”和“产品”，应支持动态类型：
|
||||
|
||||
- 默认类型：Page、Post、Product、Category、Brand、Service、Case、FAQ、Team、Download。
|
||||
- 自定义内容类型：如汽车的 Vehicle、工业管材的 Pipe、房地产的 Property。
|
||||
- 字段定义：短文本、富文本、数字、布尔、日期、枚举、关系、数组、媒体、SEO 字段、多语言字段、引用。
|
||||
- 校验规则：是否必填、唯一性、格式、单位、可搜索/筛选、跨字段规则。
|
||||
- 数据状态：draft / review / published / archived；版本和来源可追踪。
|
||||
|
||||
### 3.4 Theme（主题）/ Template（页面模板）/ Component（组件）
|
||||
|
||||
- **主题 Theme**：完整设计风格及组件集合、页面模板、响应式规则、设计 Token。
|
||||
- **页面模板 Page Template**：例如首页、产品列表、产品详情、文章详情、专题落地页。
|
||||
- **组件 Component**：Hero、图片网格、产品卡、参数表、图文交错、导航栏、页脚等。
|
||||
- **主题实例 Theme Instance**：某站点在主题基础上的参数覆盖与自定义区块配置。
|
||||
|
||||
### 3.5 Route Registry（路由注册表）
|
||||
|
||||
一切最终发布 URL 的唯一事实源：`site_id + method + normalized_path + locale + route_behavior`；必须记录来源及冲突处理，不能仅由标题推断路径。
|
||||
|
||||
---
|
||||
|
||||
## 4. 模板工厂：不仅选模板，还要生产模板
|
||||
|
||||
### 4.1 模板分类
|
||||
|
||||
- 行业模板：汽车出口、工业品、制造业、外贸 B2B、企业介绍、服务类、资讯类。
|
||||
- 页面模板：首页、列表、详情、关于、联系、新闻、案例、FAQ、落地专题等。
|
||||
- 区块库：Hero、统计、产品参数、网格、时间线、客户评价、团队、展会等。
|
||||
- 布局方案：顶部导航、侧边导航、全宽、多列、自适应等。
|
||||
|
||||
### 4.2 模板选择体验
|
||||
|
||||
每个主题展示 PC/移动端预览、适合行业、支持的内容类型、内置页面数量、菜单形态和可编辑范围。选择主题后运行 `compatibilityCheck`，提示当前内容是否满足主题必需字段，并提供字段映射或替代组件选项。
|
||||
|
||||
### 4.3 模板来源
|
||||
|
||||
1. 平台预置主题。
|
||||
2. 开发人员以标准主题 SDK 编写并注册主题。
|
||||
3. 在设计器中制作页面，保存为模板或区块。
|
||||
4. 从现有网站**复制结构/设计配置**作为新项目起点，不自动复制私有数据。
|
||||
|
||||
### 4.4 防止主题与数据耦合
|
||||
|
||||
主题只能根据语义接口取数据，例如 `products.featured`、`company.name`、`posts.latest`。不能把某个具体产品、域名或 WordPress ID 硬编码进主题组件。
|
||||
|
||||
### 4.5 模板升级
|
||||
|
||||
主题使用不可变版本号。站点自行选择是否升级；升级前进行数据兼容性检测和区块差异预览；不支持自动合并的站点私有修改应手动解决。
|
||||
|
||||
---
|
||||
|
||||
## 5. 可视化建站编辑器（分级实现）
|
||||
|
||||
### 5.1 编辑器 V1：区块式编辑
|
||||
|
||||
支持：增删页面、排列标准区块、替换组件样式、设定图片/文案/数据引用、编辑导航与页脚、调整设计 Token、切换 PC/平板/手机预览、草稿/审核/发布。
|
||||
|
||||
### 5.2 编辑器 V2：结构化可视化编排
|
||||
|
||||
支持：嵌套容器、列布局、响应式属性、条件显示、组件插槽、集合绑定、重复列表、页面模板编辑和全站设计系统管理。
|
||||
|
||||
### 5.3 编辑器 V3（可选）：高级自由设计
|
||||
|
||||
高级拖拽、交互动效、定制脚本、组件市场等；需严格控制任意 HTML/JS 注入与主题兼容问题。
|
||||
|
||||
**不建议 V1 开发任意像素拖拽引擎。** 先用区块式编辑器建立高复用度和稳定构建体验；高级主题仍允许开发者编写独立代码。
|
||||
|
||||
### 5.4 主题自由度分级
|
||||
|
||||
- L1 配置型：换色、Logo、素材和文案即可上线。
|
||||
- L2 区块型：调整首页和内页的组件排列及内容映射。
|
||||
- L3 高级定制型：独立开发主题，完全自定义 HTML、样式、交互和布局。
|
||||
|
||||
这避免为了统一拖拽而让不同网站“长得一样”。
|
||||
|
||||
---
|
||||
|
||||
## 6. 内容工厂：手动、批量、API 与旧站多源输入
|
||||
|
||||
### 6.1 数据输入管道
|
||||
|
||||
| 输入渠道 | 典型数据 | 数据处理 |
|
||||
|---|---|---|
|
||||
| 后台手动新增 | 文章、产品、服务、页面 | 表单编辑和字段校验 |
|
||||
| Excel / CSV | 车型、价格、参数、批量产品 | 预览字段、列映射、类型推断、增量更新 |
|
||||
| JSON / XML | 第三方结构化数据 | schema 映射、字段转换、关系解析 |
|
||||
| API / Webhook | ERP、CRM、内部商品系统 | 授权连接、定时/手动同步、冲突策略 |
|
||||
| SQL / 备份 | 原数据库内容 | 隔离解析、适配映射、数据脱敏 |
|
||||
| WordPress XML/API | 文章、产品、分类、meta | WordPress 插件与字段适配器 |
|
||||
| 通用网站抓取 | 公开页面、SEO、图片、菜单 | 页面发现、JS 渲染、去噪和人工确认 |
|
||||
| 媒体 ZIP / 对象存储 | 图片、PDF、视频 | 去重、批量命名和资源引用映射 |
|
||||
|
||||
### 6.2 通用导入工作台
|
||||
|
||||
选择数据源 → 预览 → 识别内容类型 → 字段映射 → 数据清洗 → 去重/冲突策略 → 导入模拟运行（dry-run） → 确认入库 → 验证关联与资源 → 保留导入快照。
|
||||
|
||||
支持“仅新增”“按唯一键更新”“新增+更新”“人工审核冲突”；**默认不得直接覆盖人工编辑过的字段**。保留来源字段值、最新导入值、人工覆盖值及优先级。
|
||||
|
||||
### 6.3 内容与页面的区别
|
||||
|
||||
- 录入 1000 个车型，不意味着手工建 1000 个页面。
|
||||
- 车型都是 `Vehicle` 内容条目；系统采用一个 `vehicle-detail` 页面模板批量生成 1000 个对应 URL。
|
||||
- 新增车型后自动生成新详情页并更新分类列表、筛选数据、站点地图与内部链接。
|
||||
|
||||
### 6.4 媒体中心
|
||||
|
||||
- 原图存储，派生多尺寸格式；保留 alt、文件名、来源 URL 和使用关系。
|
||||
- 旧站媒体需维护原路径映射，必要时保留原 URL 的资源响应。
|
||||
- 批量上传、图库、资源去重、视频外链、PDF 和下载附件。
|
||||
- 资源删除时检查使用关系；不能造成已上线页面引用失效。
|
||||
|
||||
---
|
||||
|
||||
## 7. 网站装配引擎（全产品最核心的技术）
|
||||
|
||||
### 7.1 输入
|
||||
|
||||
`site_blueprint.json + theme@version + content_snapshot + asset_manifest + route_registry + SEO_policy`
|
||||
|
||||
### 7.2 核心过程
|
||||
|
||||
1. 验证主题与内容类型是否兼容。
|
||||
2. 解析页面树与导航，构造页面上下文。
|
||||
3. 读取数据绑定配置，生成列表和详情集合。
|
||||
4. 根据 URL/语言规则生成页面路径，检测重复与冲突。
|
||||
5. 按页面模板渲染静态 HTML，并生成 CSS/JS。
|
||||
6. 生成 sitemap、robots、结构化数据和必要的重定向配置。
|
||||
7. 执行页面链接、SEO、媒体、性能及功能验证。
|
||||
8. 形成不可变构建产物、版本元数据和差异报告。
|
||||
|
||||
### 7.3 装配示例：汽车站
|
||||
|
||||
- 公司信息绑定 `company.*`。
|
||||
- 首页精选车型绑定 `vehicles where featured=true`。
|
||||
- 品牌列表绑定 `brands`，每个品牌生成 `/brands/{slug}/`。
|
||||
- 车型详情绑定 `vehicles`，生成 `/models/{slug}/` 或从旧站注册表获取原有 URL。
|
||||
- 新闻内容绑定 `posts`，自动生成新闻列表和详情。
|
||||
- PC 和移动端页面由同一语义内容驱动，但主题可采用不同响应式布局。
|
||||
|
||||
### 7.4 蓝图 JSON 示例
|
||||
|
||||
```json
|
||||
{
|
||||
"siteKey": "export-auto-demo",
|
||||
"mode": "migration-redesign",
|
||||
"theme": {"id": "automotive-premium", "version": "1.4.0"},
|
||||
"locale": "en",
|
||||
"designTokens": {"primaryColor": "#1765B2", "contentWidth": "1280px"},
|
||||
"pages": [
|
||||
{"kind": "static", "path": "/", "template": "home"},
|
||||
{"kind": "collection", "path": "/products/", "template": "product-list", "contentType": "vehicle"},
|
||||
{"kind": "entry", "template": "product-detail", "contentType": "vehicle", "routeSource": "registry"}
|
||||
],
|
||||
"navigation": {"header": ["/", "/products/", "/about-us/", "/contact/"]},
|
||||
"seoPolicy": "preserve-imported"
|
||||
}
|
||||
```
|
||||
|
||||
### 7.5 主题数据绑定示例
|
||||
|
||||
```json
|
||||
{
|
||||
"template": "home",
|
||||
"slots": {
|
||||
"hero": {"type": "Hero", "bindings": {"title": "site.homeHero.title", "image": "site.homeHero.image"}},
|
||||
"featured": {"type": "VehicleGrid", "source": {"contentType": "vehicle", "filter": {"featured": true}, "limit": 8}},
|
||||
"news": {"type": "LatestPosts", "source": {"contentType": "post", "limit": 3}}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
规则应由受控 schema/查询 DSL 解释，**禁止把任意用户输入作为数据库查询或 JS/SQL 执行**。
|
||||
|
||||
---
|
||||
|
||||
## 8. 旧站迁移子系统（Website Factory 的一个入口）
|
||||
|
||||
### 8.1 兼容范围与优先顺序
|
||||
|
||||
P0：WordPress（REST API + WXR XML + SQL + `wp-content`）、HTML 静态站、普通 PHP 公开站。P1：Drupal、Joomla、自定义 CMS、Vue/React 渲染站。P2：电商、会员、复杂业务站专用适配器。
|
||||
|
||||
### 8.2 自动扫描
|
||||
|
||||
抓取 robots、sitemap、内部链接、菜单、页面、分页、媒体和 head SEO；识别 CMS、页面类型、动态表单、语言、状态码和 canonical；得到带来源、置信度和异常标记的扫描清单。
|
||||
|
||||
### 8.3 迁移独有工作流
|
||||
|
||||
`Old Site → Snapshot → Extract → Normalize → Map To Theme → Route/SEO Preserve → Preview/QA → Cutover`
|
||||
|
||||
1. 建立旧站不可变快照，记录内容、URL、响应状态、SEO、媒体。
|
||||
2. 能取得权限时优先组合 API/备份/网页数据，不能取得权限时抓取公开内容并标记未知项。
|
||||
3. 将旧站类型映射到统一类型，例如 WooCommerce product → Product / ACF car → Vehicle。
|
||||
4. 让用户选择新的视觉主题，映射旧数据字段到新页面组件。
|
||||
5. 保留旧 URL 注册表、历史 301、canonical 和 SEO 元数据；异常需明示审核。
|
||||
6. 禁止新主题自动重写旧路由。新增加的内容可按新建路由规则生成。
|
||||
7. 预览视觉不同的新站并以旧站数据基线自动验收。
|
||||
8. 发布时注意 DNS、CDN、缓存、预览 noindex、必要 API 以及回滚。
|
||||
9. 上线后追踪 404、搜索抓取和流量变化；上线前后还可进行增量同步直至冻结旧站写入。
|
||||
|
||||
### 8.4 关键事实
|
||||
|
||||
公开页面采集无法保证后台未展示字段完整；网站登录、支付、购物车及实时功能不能纯静态复制；要在扫描报告中明确“可自动”“需授权”“需开发扩展”“不迁移”四种处置结果。
|
||||
|
||||
---
|
||||
|
||||
## 9. 新站创建子系统（与迁移同等优先级）
|
||||
|
||||
### 9.1 模板新建流程
|
||||
|
||||
1. 输入网站名称、主语言、品牌信息、目标行业、域名（可延后绑定）。
|
||||
2. 选择模板并预览 PC/移动端。
|
||||
3. 从模板生成站点蓝图、页面树、导航和内容类型定义。
|
||||
4. 进入引导式公司资料表：名称、Logo、联系方式、社媒、地址、企业简介。
|
||||
5. 手工或批量添加产品、文章、品牌、图片；主题根据字段绑定渲染页面。
|
||||
6. 修改页面区块、主色、字体和导航，设置联系表单目标。
|
||||
7. 自动生成页面、站点地图与 SEO 默认值；检查内容完整性。
|
||||
8. 预览、发布、绑定域名；未来继续从后台更新。
|
||||
|
||||
### 9.2 空白新建流程
|
||||
|
||||
1. 创建站点与内容类型。
|
||||
2. 配置导航/页脚和布局框架。
|
||||
3. 通过区块编辑器建立页面和模板。
|
||||
4. 建立动态集合页及详情路由规则。
|
||||
5. 绑定内容和媒体，预览并发布。
|
||||
6. 经审核将该站的可复用结构导出为主题/站点模板。
|
||||
|
||||
### 9.3 导入内容建站流程
|
||||
|
||||
1. 上传 `vehicles.xlsx`，识别标题、品牌、图片、价格、参数等。
|
||||
2. 创建或选择 `Vehicle` 内容类型，建立字段映射、唯一键和数据校验。
|
||||
3. 选择适合的产品站主题；若字段不足，提示补齐，而不是凭空生成。
|
||||
4. 由车型集合创建列表、详情、品牌聚合页，生成对应 URL。
|
||||
5. 配置通用企业资料、SEO、导航，发布成完整新站。
|
||||
|
||||
### 9.4 主题替换机制
|
||||
|
||||
切换主题时预检查必需字段、页面类型、交互能力、导航结构及 URL 兼容性。允许在临时预览环境试装，保留旧主题和站点蓝图版本；确认后切换，不删除原内容和媒体。
|
||||
|
||||
---
|
||||
|
||||
## 10. URL 与 SEO：区分“迁移”和“新建”两种政策
|
||||
|
||||
### 10.1 迁移站（Preserve Mode）
|
||||
|
||||
- 以实际旧站最终有效访问行为为基线，保留用户可见有效 URL、状态码和所需重定向链。
|
||||
- Title、Description、Canonical、Robots、Hreflang、JSON-LD、Open Graph、图片 alt、内链和 sitemap 做差异比对。
|
||||
- 旧 URL 到新构建产物一对一登记，包含中文路径、大小写、尾部斜杠、`.html`、分页、文件、查询参数规则。
|
||||
- 404 处理必须区分原本无效和新迁移导致；如果页面已批准下线，应设置合适的 301/410 行为。
|
||||
- 允许设计变化，但不能因使用新模板悄悄改变原 SEO/URL。
|
||||
|
||||
### 10.2 新站（Generate Mode）
|
||||
|
||||
- 按站点定义 slug 策略和 URL 规则；允许人工指定覆盖。
|
||||
- 使用 SEO 默认模板，例如 `{product.name} | {site.name}`，并提示检查重复标题/空描述。
|
||||
- 自动生成 robots、sitemap、Open Graph、必要的 JSON-LD 和 canonical。
|
||||
- 多语言模式需完整管理 locale URL、翻译关联和 hreflang。
|
||||
- 预览域名必须鉴权并禁止搜索索引。
|
||||
|
||||
### 10.3 混合模式
|
||||
|
||||
来源于旧站的内容使用 Preserve URL，新增内容使用 Generate URL；注册表统一检查冲突。**不能简单设置一个整站 `preserve=true` 就忽略新内容路径生成。**
|
||||
|
||||
### 10.4 质量门禁
|
||||
|
||||
迁移站关键 URL 和 SEO 的未批准差异必须阻止发布；新站的门禁主要是 URL 冲突、重复规范地址、无效内链、关键必填字段缺失和资源失效。
|
||||
|
||||
---
|
||||
|
||||
## 11. 管理后台信息架构（建议菜单）
|
||||
|
||||
```
|
||||
SiteForge
|
||||
├── 工作台 Dashboard
|
||||
│ ├── 网站数量 / 最近发布 / 失败任务 / 风险
|
||||
│ └── 快速操作：新建网站 / 导入内容 / 创建模板
|
||||
├── 网站工厂
|
||||
│ ├── 所有网站
|
||||
│ ├── 创建网站向导（空白 / 模板 / 旧站 / 数据）
|
||||
│ ├── 网站蓝图 / 页面树 / 菜单 / 域名
|
||||
│ └── 预览 / 历史版本 / 克隆结构
|
||||
├── 内容中心
|
||||
│ ├── 内容类型设计器
|
||||
│ ├── 文章 / 产品 / 自定义集合
|
||||
│ ├── 公司资料 / 全局数据
|
||||
│ ├── 数据导入与同步
|
||||
│ └── 媒体资源库
|
||||
├── 设计中心
|
||||
│ ├── 模板库 / 主题库
|
||||
│ ├── 页面模板 / 区块库
|
||||
│ ├── 页面编辑器
|
||||
│ ├── 全站设计 Token
|
||||
│ └── 自定义主题注册与版本
|
||||
├── 迁移中心
|
||||
│ ├── 网站技术扫描
|
||||
│ ├── WordPress / CMS 导入
|
||||
│ ├── 字段映射 / 旧站快照
|
||||
│ ├── URL / SEO 基线
|
||||
│ └── 迁移差异报告
|
||||
├── 构建与发布
|
||||
│ ├── 构建任务 / 预览
|
||||
│ ├── 自动验收与报告
|
||||
│ ├── 发布审批 / 目标服务器
|
||||
│ ├── ZIP 导出 / 历史版本
|
||||
│ └── 回滚 / CDN 缓存刷新
|
||||
└── 系统设置
|
||||
├── 用户 / 团队 / 角色
|
||||
├── API 密钥 / 数据源凭证
|
||||
├── 适配器 / 扩展服务
|
||||
├── 审计日志 / 告警
|
||||
└── 存储 / 域名 / 环境
|
||||
```
|
||||
|
||||
### 11.1 新建网站首页建议
|
||||
|
||||
四个同级入口卡片：**旧站改造、使用模板新建、导入数据建站、空白建站**。不要把“迁移”置于唯一入口，也不要把“选择模板”藏在迁移流程中。
|
||||
|
||||
### 11.2 网站内部工作台
|
||||
|
||||
概览 → 内容 → 页面 → 设计 → SEO/路由 → 预览 → 发布 → 设置。便于独立运营每个网站，不要求管理员理解数据仓库和构建细节。
|
||||
|
||||
---
|
||||
|
||||
## 12. 推荐技术选型与研发边界
|
||||
|
||||
| 部分 | 推荐 | 备注 |
|
||||
|---|---|---|
|
||||
| 后台界面 | Vue 3 + TypeScript + Element Plus / Art Design Pro | 多站点、内容编辑、区块页面编辑器 |
|
||||
| 核心 API | Python FastAPI + Pydantic + SQLAlchemy | 复用 Python 采集、数据处理和内部工程经验 |
|
||||
| 异步任务 | Celery + Redis（或 Dramatiq） | 采集、媒体、导入、同步、质量任务 |
|
||||
| 数据库 | PostgreSQL | JSONB 扩展字段、关系表和审计日志 |
|
||||
| 采集服务 | Python httpx/Scrapy + Playwright | SSR/动态页面扫描与插件适配 |
|
||||
| 模板及静态生成 | Astro + TypeScript/Node Worker | 主题组件、静态页面编译、增量/全量构建 |
|
||||
| 资产存储 | S3 兼容对象存储/OSS + 本地缓存 | 原图、附件、站点版本和静态包 |
|
||||
| 部署 | Nginx / 对象存储 + CDN / SSH 或 Git 工作流 | 独立站交付和可回滚 |
|
||||
| 任务与日志 | PostgreSQL + Redis + 集中日志 | 可追踪的导入和发布作业 |
|
||||
| 运行 | Docker Compose 首选 | 后期再按规模拆分服务 |
|
||||
|
||||
**为什么不强制全部使用一种语言**：数据采集/规范化适合 Python；静态主题的现代前端生态适合 TypeScript/Astro。通过版本化 JSON 契约连接两个 Worker，避免牺牲网站的设计自由度。若团队对 NestJS 更熟，也可替换 API 层，不影响领域模型和构建协议。
|
||||
|
||||
### 12.1 部署架构
|
||||
|
||||
- API、PostgreSQL、Redis、导入 Worker、构建 Worker、管理前端、对象存储等分别通过容器管理。
|
||||
- 每个网站生成独立不可变 `release_id` 的产物并可单独导出、上传和回滚。
|
||||
- 为不同域名、地区和站点提供独立构建与部署配置。
|
||||
- 预览站点与生产站点隔离，预览授权、禁止索引。
|
||||
|
||||
---
|
||||
|
||||
## 13. 数据库详细方案
|
||||
|
||||
### 13.1 数据库分域
|
||||
|
||||
**组织与权限**：`organizations`、`users`、`memberships`、`roles`、`permissions`。
|
||||
|
||||
**网站与蓝图**：`sites`、`site_environments`、`site_blueprints`、`site_settings`、`page_nodes`、`navigation_menus`、`navigation_items`、`site_domains`。
|
||||
|
||||
**内容模型**：`content_types`、`field_definitions`、`content_entries`、`entry_versions`、`entry_relations`、`content_localizations`、`global_entries`。
|
||||
|
||||
**媒体**：`media_assets`、`media_variants`、`media_references`、`media_source_urls`。
|
||||
|
||||
**模板与组件**：`themes`、`theme_versions`、`page_templates`、`component_definitions`、`component_instances`、`design_tokens`、`site_theme_bindings`。
|
||||
|
||||
**数据输入与适配器**：`data_sources`、`adapter_definitions`、`import_jobs`、`import_items`、`field_mappings`、`sync_policies`、`source_snapshots`、`source_identity_map`。
|
||||
|
||||
**URL 与 SEO**：`routes`、`redirect_rules`、`seo_records`、`seo_snapshots`、`link_checks`、`route_diffs`。
|
||||
|
||||
**构建发布**：`build_jobs`、`build_artifacts`、`releases`、`deployments`、`quality_reports`、`audit_events`。
|
||||
|
||||
### 13.2 SQL 示意
|
||||
|
||||
```sql
|
||||
CREATE TABLE sites (
|
||||
id UUID PRIMARY KEY,
|
||||
organization_id UUID NOT NULL,
|
||||
name TEXT NOT NULL,
|
||||
site_key TEXT NOT NULL,
|
||||
creation_mode TEXT NOT NULL CHECK (creation_mode IN
|
||||
('blank','template','migration','data_import','clone_structure')),
|
||||
default_locale TEXT NOT NULL DEFAULT 'en',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
UNIQUE (organization_id, site_key)
|
||||
);
|
||||
|
||||
CREATE TABLE content_types (
|
||||
id UUID PRIMARY KEY,
|
||||
site_id UUID NOT NULL REFERENCES sites(id),
|
||||
type_key TEXT NOT NULL,
|
||||
schema_json JSONB NOT NULL,
|
||||
UNIQUE (site_id, type_key)
|
||||
);
|
||||
|
||||
CREATE TABLE content_entries (
|
||||
id UUID PRIMARY KEY,
|
||||
site_id UUID NOT NULL REFERENCES sites(id),
|
||||
content_type_id UUID NOT NULL REFERENCES content_types(id),
|
||||
source_identity TEXT,
|
||||
slug TEXT,
|
||||
locale TEXT NOT NULL DEFAULT 'en',
|
||||
status TEXT NOT NULL DEFAULT 'draft',
|
||||
data_json JSONB NOT NULL,
|
||||
version INTEGER NOT NULL DEFAULT 1,
|
||||
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
|
||||
);
|
||||
|
||||
CREATE TABLE site_blueprints (
|
||||
id UUID PRIMARY KEY,
|
||||
site_id UUID NOT NULL REFERENCES sites(id),
|
||||
revision INTEGER NOT NULL,
|
||||
blueprint_json JSONB NOT NULL,
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
UNIQUE (site_id, revision)
|
||||
);
|
||||
|
||||
CREATE TABLE routes (
|
||||
id UUID PRIMARY KEY,
|
||||
site_id UUID NOT NULL REFERENCES sites(id),
|
||||
locale TEXT NOT NULL,
|
||||
path TEXT NOT NULL,
|
||||
behavior TEXT NOT NULL, -- render | redirect | gone | proxy
|
||||
target_entry_id UUID NULL REFERENCES content_entries(id),
|
||||
target_url TEXT NULL,
|
||||
source_kind TEXT NOT NULL, -- imported | generated | manual
|
||||
UNIQUE (site_id, locale, path)
|
||||
);
|
||||
|
||||
CREATE TABLE build_jobs (
|
||||
id UUID PRIMARY KEY,
|
||||
site_id UUID NOT NULL REFERENCES sites(id),
|
||||
blueprint_revision INTEGER NOT NULL,
|
||||
theme_version TEXT NOT NULL,
|
||||
input_manifest JSONB NOT NULL,
|
||||
status TEXT NOT NULL,
|
||||
started_at TIMESTAMPTZ,
|
||||
finished_at TIMESTAMPTZ
|
||||
);
|
||||
```
|
||||
|
||||
数据库 DDL 只是结构示意；正式实现应补全租户隔离策略、外键/索引、关系类型、软删、版本表、迁移脚本和审计字段。`source_identity_map` 不应在跨数据源之间简单依赖 slug 去重。
|
||||
|
||||
### 13.3 数据治理约束
|
||||
|
||||
- 以 `organization_id + site_id` 强制作用域隔离，查询接口必须实现授权校验。
|
||||
- 导入前保存 raw source；标准化后保留原来源与变更来源。
|
||||
- 使用内容版本快照支持回滚和差异查看。
|
||||
- 记录手动字段覆盖，不允许重导入无声覆盖。
|
||||
- 涉及多语言、复杂关系、复用媒体时，不用一张任意 JSONB 表取代所有关系模型。
|
||||
|
||||
---
|
||||
|
||||
## 14. 核心 API 契约（示意）
|
||||
|
||||
```text
|
||||
POST /api/sites # 建立网站；body.creationMode
|
||||
GET /api/sites # 站点清单
|
||||
GET /api/sites/{siteId}
|
||||
POST /api/sites/{siteId}/clone-structure
|
||||
GET /api/themes # 主题库
|
||||
GET /api/themes/{themeId}/versions
|
||||
POST /api/sites/{siteId}/theme/preview # 试装主题/兼容性检查
|
||||
POST /api/sites/{siteId}/theme/activate
|
||||
GET /api/sites/{siteId}/blueprint
|
||||
PUT /api/sites/{siteId}/blueprint # 乐观锁 revision
|
||||
GET /api/sites/{siteId}/content-types
|
||||
POST /api/sites/{siteId}/content-types
|
||||
GET /api/sites/{siteId}/entries
|
||||
POST /api/sites/{siteId}/entries
|
||||
PATCH /api/sites/{siteId}/entries/{entryId}
|
||||
POST /api/sites/{siteId}/imports # 文件/API/CMS/旧站导入
|
||||
POST /api/imports/{jobId}/dry-run
|
||||
POST /api/imports/{jobId}/commit
|
||||
GET /api/imports/{jobId}/conflicts
|
||||
GET /api/sites/{siteId}/routes
|
||||
GET /api/sites/{siteId}/seo-audit
|
||||
POST /api/sites/{siteId}/builds
|
||||
GET /api/builds/{buildId}
|
||||
POST /api/sites/{siteId}/releases/{releaseId}/publish
|
||||
POST /api/sites/{siteId}/deployments/{deployId}/rollback
|
||||
GET /api/sites/{siteId}/quality-reports
|
||||
```
|
||||
|
||||
### 14.1 任务状态机
|
||||
|
||||
`created → queued → running → needs_review | failed | completed`；构建验收后再从 `completed` 经 `approved → published`，允许取消、重试、失败恢复，但每个状态转换须有审计记录。
|
||||
|
||||
### 14.2 构建契约
|
||||
|
||||
Node/Astro 构建 Worker 只接受经过签名/授权访问的不可变输入 manifest，输出静态包路径、构建报告、内容 hash、资源清单和验收结果；不要将数据库直接暴露给静态构建主题代码。
|
||||
|
||||
---
|
||||
|
||||
## 15. 质量验收体系（按建站模式执行）
|
||||
|
||||
### 15.1 通用验收
|
||||
|
||||
- 所有必需页面可访问、无冲突路由、没有意外 404/5xx。
|
||||
- 内容、分类、关联、图片和附件链接完整；过滤 XSS 等不可信脚本。
|
||||
- PC / 移动端核心页面无溢出、错位和严重布局问题。
|
||||
- sitemap、robots、canonical 与发布目标域名一致。
|
||||
- 站点预览不被搜索引擎收录，正式站按配置开放索引。
|
||||
- 表单、询盘、导航、搜索等启用功能经过实际测试。
|
||||
- 发布包可在隔离环境部署并独立访问；能回滚。
|
||||
|
||||
### 15.2 迁移专用验收
|
||||
|
||||
- 旧站已发现的有效 URL 都有一致访问或批准例外；关键路径的未批准变化阻断发布。
|
||||
- SEO 标题、描述、canonical、robots、hreflang 等做旧/新对照。
|
||||
- 产品/文章/页面数与旧站基线差异有解释；不可获取内容明确列出。
|
||||
- 资源与重定向规则逐项校验；上线后持续关注抓取和错误。
|
||||
|
||||
### 15.3 新站专用验收
|
||||
|
||||
- 必填企业信息、Logo、联系路径和站点语言完整。
|
||||
- 集合列表与详情页数量正确，新增内容可以重新生成网页。
|
||||
- SEO 自动生成规则没有导致大量重复标题或无意义内容。
|
||||
- 所选模板适用内容字段，缺失信息不能通过臆造补全。
|
||||
|
||||
### 15.4 验收报告分级
|
||||
|
||||
`BLOCKER`（必须解决）/ `WARNING`（可人工批准）/ `INFO`。不要把“页面加载成功”视作“内容迁移完整”。
|
||||
|
||||
---
|
||||
|
||||
## 16. 构建、部署、静态导出与持续更新
|
||||
|
||||
### 16.1 全量与局部构建
|
||||
|
||||
V1 可先全量构建保证正确性；V2 根据内容变化计算影响依赖：更新车型 → 对应详情、分类、品牌列表、首页精选和 sitemap 等重建。依赖图要可追踪，以免漏刷引用页。
|
||||
|
||||
### 16.2 交付格式
|
||||
|
||||
```
|
||||
release-2026-10-21-a1b2/
|
||||
├── public/
|
||||
│ ├── index.html
|
||||
│ ├── about-us/index.html
|
||||
│ ├── products/index.html
|
||||
│ ├── products/example/index.html
|
||||
│ ├── assets/...
|
||||
│ ├── sitemap.xml
|
||||
│ └── robots.txt
|
||||
├── server/
|
||||
│ ├── nginx.conf.example
|
||||
│ └── redirects.json
|
||||
├── manifest.json
|
||||
├── quality-report.json
|
||||
└── deployment-notes.md
|
||||
```
|
||||
|
||||
旧站存在 `.html`、尾斜杠与目录结构差异时，按照路由注册表选择适当静态目录或 Web 服务器规则；**输出文件路径本身不代表 HTTP 访问语义自动等同**，必须经过实际服务器验收。
|
||||
|
||||
### 16.3 部署策略
|
||||
|
||||
- 预览 / staging / production 三级环境，可选择简化为 preview + production。
|
||||
- 产物不可变、版本化；原子切换部署；媒体缓存和 HTML 缓存采用不同策略。
|
||||
- 支持 ZIP 下载、SSH/SFTP、Git CI、对象存储 + CDN；不同站点独立域名和缓存。
|
||||
- 发布操作与回滚操作留存操作人、时间、版本和差异。
|
||||
|
||||
### 16.4 外部服务扩展
|
||||
|
||||
表单、询盘、搜索、评论、登录等由独立功能适配器负责；主题仅通过公开的组件/客户端 SDK 调用，避免各站重复实现且不把平台后台变成生产站依赖。
|
||||
|
||||
---
|
||||
|
||||
## 17. 安全、权限、成本与可维护性
|
||||
|
||||
- **采集 SSRF**：阻断内部 IP、云元数据地址、敏感主机及重定向跳转；抓取速率限制、URL 白名单、robots 与站点使用权限审查。
|
||||
- **文件安全**：ZIP 解压路径穿越、恶意 HTML/JS/PHP、上传扩展名、MIME、体积限制与资源扫描。
|
||||
- **数据隔离**：租户、站点、内容、媒体、API 凭证严格隔离，导出权限与发布权限分离。
|
||||
- **主题安全**：主题依赖锁定、审核第三方组件、禁止把未审核用户表达式转换为运行代码。
|
||||
- **SEO 安全**：导入外站数据时不能盲目继承失效域名 canonical/跳转目标；必须判别并显示冲突。
|
||||
- **构建安全**：构建 Worker 沙箱、资源/CPU/时间限制、审计命令、脱离机密生产凭证。
|
||||
- **版本安全**：导入快照、内容版本、主题版本、发布版本皆可追溯与恢复。
|
||||
- **数据备份**：数据库备份、媒体/源快照、构建物及密钥轮换政策。
|
||||
|
||||
---
|
||||
|
||||
## 18. 开发路线图：从最小“网站工厂”开始
|
||||
|
||||
### 阶段 0 — 架构与样本验证（建议 2–3 周）
|
||||
|
||||
成果：Site Blueprint schema、内容类型/字段协议、主题 manifest、路由引擎规则、导入/构建 JSON 契约、站点项目 UI 原型；准备 3 个试点样本（WordPress 迁移、新站模板、新数据批量导入）。
|
||||
|
||||
### 阶段 1 — MVP 网站工厂（建议 6–10 周）
|
||||
|
||||
**必须同时具备“新建”和“迁移”两条路径。**
|
||||
|
||||
- 站点项目管理、主题目录（至少两套不同设计）、站点蓝图。
|
||||
- 内容模型（页面/文章/产品/分类、可扩展字段）、媒体上传与基础编辑。
|
||||
- 模板新建、CSV/Excel 导入、WordPress 核心内容导入。
|
||||
- 页面装配/静态构建、基本 URL/SEO 模式、预览与 ZIP 导出。
|
||||
- 自动验收、单站版本管理。
|
||||
|
||||
验收：同一系统能生产一个无旧站的新网站和一个 WP 迁移重建网站；两站视觉结构不同且可独立访问。
|
||||
|
||||
### 阶段 2 — 可规模化多站点运营（建议 6–10 周）
|
||||
|
||||
- 通用网站爬虫与插件适配器、字段映射工作台。
|
||||
- 主题兼容性检测、区块式编辑器、页面/菜单可视化设置。
|
||||
- 增量导入、媒体处理、版本化部署与一键回滚。
|
||||
- URL/SEO 完整旧新站差异报告、批量质量门禁。
|
||||
- 多站点、多权限、多环境和站点克隆结构。
|
||||
|
||||
验收：至少一个非 WordPress 站可迁移，模板与数据独立升级可运行。
|
||||
|
||||
### 阶段 3 — 完整模板工厂与自动化（按实际业务决定）
|
||||
|
||||
- 可视化页面模板编辑、组合式区块库。
|
||||
- 自定义主题 SDK 和内部主题市场、模板版本升级迁移。
|
||||
- API 数据同步、任务计划、依赖图增量构建。
|
||||
- AI 内容分类、字段匹配和页面布局建议（人工审核）。
|
||||
- 更多 CMS / ERP 适配器和复杂组件。
|
||||
|
||||
> 时间均为粗略研发规划区间，不是工期承诺；应基于团队人数、模板复杂度、实际旧站数据和试点验收调整。
|
||||
|
||||
---
|
||||
|
||||
## 19. 研发团队协作与目录建议
|
||||
|
||||
```text
|
||||
siteforge/
|
||||
├── apps/
|
||||
│ ├── admin-web/ # Vue 管理后台
|
||||
│ └── api/ # FastAPI 主服务
|
||||
├── workers/
|
||||
│ ├── imports/ # 导入与数据清洗
|
||||
│ ├── crawler/ # 旧站抓取和 CMS 适配
|
||||
│ ├── media/ # 媒体处理
|
||||
│ ├── builder/ # Astro 构建服务
|
||||
│ └── qa/ # URL/SEO/功能验收
|
||||
├── packages/
|
||||
│ ├── blueprint-schema/ # 站点蓝图协议
|
||||
│ ├── content-schema/ # 内容与字段协议
|
||||
│ ├── adapter-sdk/ # 数据源接入接口
|
||||
│ ├── theme-sdk/ # 主题数据绑定/组件接口
|
||||
│ ├── route-engine/ # 路由规则与映射
|
||||
│ └── build-contract/ # 输入/输出 manifest
|
||||
├── themes/
|
||||
│ ├── corporate-clean/
|
||||
│ ├── automotive-premium/
|
||||
│ └── industrial-b2b/
|
||||
├── migrations/ # 数据库演进
|
||||
├── docs/ # PRD、ADR、API、模板规范
|
||||
├── tests/ # 完整端到端样本
|
||||
└── infra/ # Docker、Nginx、CDN、CI
|
||||
```
|
||||
|
||||
### 19.1 设计/数据/研发协作界面
|
||||
|
||||
- 设计师交付主题原型与组件规范。
|
||||
- 研发把组件封装成可配置主题，声明需要哪些数据字段。
|
||||
- 内容人员录入内容和映射字段，不需修改代码。
|
||||
- 项目负责人检查预览并发布。
|
||||
- 可选开发人员继续以 SDK 开发特殊功能，保持独立品牌差异。
|
||||
|
||||
### 19.2 文档最小集合
|
||||
|
||||
PRD、站点蓝图 JSON Schema、Theme Manifest、组件数据绑定规范、适配器 SDK、数据模型 ERD、API OpenAPI、任务状态机、部署/回滚手册、验收测试用例。
|
||||
|
||||
---
|
||||
|
||||
## 20. 首批试点与详细验收用例
|
||||
|
||||
### 试点 A：旧 WordPress 汽车网站 → 新汽车主题
|
||||
|
||||
提供 WordPress XML + SQL/媒体（若可用）+ 网站 URL；输出文章/车型/品牌/分类和 SEO；选择全新汽车主题；旧站现存核心 URL 不改变；首页/品牌/车型详情样式与旧站不同；确认可离线发布。
|
||||
|
||||
### 试点 B：新建工业品网站（无任何旧站）
|
||||
|
||||
选择工业主题 → 添加公司 Logo/简介/联系方式 → 批量上传管材 Excel 和图片 → 自动生成产品分类与详情 → 配置联系页面 → 预览 → 以纯静态文件发布。
|
||||
|
||||
### 试点 C：已有网站 + 新数据混合
|
||||
|
||||
在 A 项目后续导入新一批产品 CSV：仅新增/更新相应产品，不覆盖旧文章与人工编辑；新增页面按新规则生成路由；原迁移 URL 不改变；系统更新受影响页面与 sitemap。
|
||||
|
||||
### 试点 D：空白页面 → 保存为模板 → 复用到第二个网站
|
||||
|
||||
从空白建立官网页面树和首页组件结构，绑定内容字段，保存为可复用模板；新项目使用该模板和另一套公司资料生成不同网站，不复制试点的私有内容。
|
||||
|
||||
**上述四个试点是网站工厂成功与否的核心验收，不允许用“只完成 WP 迁移”代替。**
|
||||
|
||||
---
|
||||
|
||||
## 21. 风险与关键决策
|
||||
|
||||
| 风险/问题 | 对策 |
|
||||
|---|---|
|
||||
| 模板不适配导入数据 | 主题声明字段和页面能力，预检查并引导补齐字段 |
|
||||
| “一键搬家”遗漏旧数据 | 多源交叉提取、数据覆盖率报告、人工审核和异常列表 |
|
||||
| 新主题导致旧 URL 改变 | URL 注册表独立于主题、迁移模式发布门禁 |
|
||||
| 模板升级覆盖独立设计 | 主题版本锁定、兼容检测、差异预览、独立站点覆盖层 |
|
||||
| 内容修改无法及时更新静态站 | 事件触发构建、预览与人工或自动发布策略 |
|
||||
| 大站生成耗时过长 | 静态构建分批、缓存、增量依赖、构建 Worker 并发 |
|
||||
| 复杂业务功能无法静态化 | 独立服务/API 适配器、功能清单和迁移边界确认 |
|
||||
| AI 生成错误产品参数或公司事实 | 不凭空补全、标记来源和置信度、人工审阅 |
|
||||
| 运营长期绑定平台无法退出 | 保证完整静态包、资源与服务器规则可导出 |
|
||||
|
||||
### 21.1 推荐冻结的架构决策
|
||||
|
||||
1. Website Factory 为总产品；Migration Center 仅是子模块。
|
||||
2. 模板和内容分离；Site Blueprint 负责装配。
|
||||
3. 四种同级建站入口；导入在网站创建后随时可用。
|
||||
4. “旧站 SEO 保真”与“新站 SEO 生成”是两种独立策略。
|
||||
5. 线上输出优先真正静态文件；额外动态能力作为可选扩展。
|
||||
6. 站点、内容、媒体、主题、蓝图、构建物独立版本化。
|
||||
7. 第一阶段不追求任意像素自由拖拽，保留独立主题开发能力。
|
||||
|
||||
---
|
||||
|
||||
## 22. 可立即拆解的第一轮开发任务
|
||||
|
||||
### Sprint A：基础项目与协议
|
||||
|
||||
- 建立仓库、开发环境、CI、PostgreSQL、Redis、身份与网站项目模型。
|
||||
- 完成 Site Blueprint / Theme Manifest / Content Type Schema 草案及验证器。
|
||||
- 创建模板库 UI、四入口建站首页和站点工作台初版。
|
||||
|
||||
### Sprint B：内容 + 模板 + 构建闭环
|
||||
|
||||
- 手动创建产品、文章、基本页面和媒体。
|
||||
- 实现两种设计风格不同的主题，完成数据绑定和列表/详情页生成。
|
||||
- 输入规范 manifest，Astro 全量构建、预览站点和 ZIP 导出。
|
||||
|
||||
### Sprint C：数据导入 + WordPress 迁移
|
||||
|
||||
- CSV/Excel 字段映射、dry-run、幂等更新、异常行报告。
|
||||
- WordPress WXR/API 导入和图片资源迁移。
|
||||
- 旧站 URL/SEO 基线及 Preserve Mode。
|
||||
|
||||
### Sprint D：上线级质量闭环
|
||||
|
||||
- URL/SEO/媒体/内链验收、构建版本、发布审批和回滚。
|
||||
- 四项端到端试点验收；填写已知限制和改进清单。
|
||||
|
||||
---
|
||||
|
||||
## 23. 最终交付物清单
|
||||
|
||||
- SiteForge 管理后台（含四种建站入口）。
|
||||
- 通用内容中心、动态内容类型、媒体库、导入工作台。
|
||||
- 模板/主题/组件中心、站点蓝图、区块式页面配置。
|
||||
- WordPress 适配器、通用爬虫、Excel/CSV/JSON 导入能力。
|
||||
- 静态装配与构建引擎，包含 ZIP 导出与独立服务器部署。
|
||||
- 旧站路由与 SEO 比对、新站 SEO 自动生成、自动验收和质量报告。
|
||||
- 多网站环境/发布/回滚/权限/审计能力。
|
||||
- 至少三套不同业务风格的参考主题与必要主题 SDK 文档。
|
||||
- 四个试点通过报告、自动化测试、开发部署手册和数据恢复演练。
|
||||
|
||||
---
|
||||
|
||||
## 24. 一句话总结
|
||||
|
||||
**SiteForge 是“有内容就能造网站、没有内容也能从零造网站、有旧网站就能搬内容换设计、造完还能持续管理和再次生成”的通用网站工厂。**
|
||||
|
||||
旧站迁移、内容管理、主题市场、页面设计、SEO、静态构建与发布，都是围绕“生产网站”这一核心能力服务的工序，而不是独立产品的拼接。
|
||||
@@ -0,0 +1,35 @@
|
||||
# SiteForge 7.2.0 — P1 增量实施与验收报告
|
||||
|
||||
依据 `COMPLETION_PLAN(1).md` v2.0 P1（平台底座），在 V7.1 源码上迭代。不是 P1 完工证明。
|
||||
|
||||
## 已实现（代码及自动化测试）
|
||||
|
||||
| P1 条目 | 实际完成范围 | 证据 |
|
||||
|---|---|---|
|
||||
| P1-1 Schema 迁移 | SQLite 新增迁移登记表、校验和校验和一项增量迁移；旧模块建表尚未整体纳管，PG 迁移另行验收 | `app/schema_registry.py`, `tests/test_p1_platform.py` |
|
||||
| P1-2/3 队列控制 | 继承幂等、租约、超时和取消，新增全局/单站排队容量上限与 429；尚无队列总负载压力测试 | `app/jobs.py`, `tests/test_p1_platform.py` |
|
||||
| P1-4 安全出网 | HTTP(S)、公网 IP、DNS 结果检查；选定地址直接连接并保持 TLS 主机名校验；受限端口、无代理、每跳重校验、响应限流；接入 REST、爬虫、媒体镜像、远程部署 | `app/safe_http.py`, `app/adapters.py`, `app/importers.py`, `app/builder.py`, `app/release_api.py` |
|
||||
| P1-5 密钥引用 | 可使用 `env:SITEFORGE_...` 或 `file:secret-name` 读取 `/run/secrets`；远程部署向后兼容旧明文环境变量；未完成统一密钥轮换与撤销 | `app/secret_refs.py`, `app/release_api.py` |
|
||||
| P1-6 诊断能力 | `X-Request-ID`，只记录方法/状态/耗时/请求编号，不记录请求内容和完整 URL | `app/request_trace.py` |
|
||||
| P1-7 配额 | 构建任务全局及站点限制、图片和旧 ZIP 原有限制加压缩比限制；站点数和长期构建保留限制尚未完成 | `app/jobs.py`, `app/main.py` |
|
||||
|
||||
## 已知限制（不得作为生产验收通过）
|
||||
|
||||
- Docker Engine、GitHub Actions、真实浏览器、备份恢复和生产回滚仍需在目标环境验证。
|
||||
- PostgreSQL 多实例事务与旧模块 DDL 全量版本迁移尚未验收；目前推荐继续采用单机 SQLite 测试部署。
|
||||
- WordPress 深度插件映射、Art Design Pro 官方工程构建及完整视觉编辑器仍存在前期版本已披露的限制。
|
||||
- HTTP 出网遵循系统信任存储中的 CA，不包含专属证书固定（certificate pinning）；公网 IP **地址固定**属于 DNS 重绑定防护，两者不是一回事。
|
||||
- 外部发布 Agent 需具备独立网络策略、审计和服务器级防火墙。`file:` 密钥当前只用于存在的密钥文件，不包含自动轮换。
|
||||
|
||||
## 验收步骤
|
||||
|
||||
1. 从新空目录解压，初始化 `.env`（不要覆盖旧生产数据）。
|
||||
2. `python -m pytest -q`，`python -m compileall -q app`，`bash scripts/check.sh`。
|
||||
3. `docker compose up -d --build`，检查 Web 与 Worker 均健康；`/api/health` 版本为 `7.2.0`。
|
||||
4. 通过后台创建网站，重复提交幂等构建，确认正常生成；将 `SITEFORGE_MAX_PENDING_JOBS_PER_SITE=1`，确认超限 429。
|
||||
5. 用受控夹具验证 DNS 解析到私网、混合地址、重定向到私网均被拒绝。
|
||||
6. 验证备份—恢复、异步任务恢复及正式发布前审计，保存测试记录及镜像摘要。
|
||||
|
||||
## 后续实施次序
|
||||
|
||||
完成 P1 剩余的数据库迁移、密钥生命周期、可观测性和故障注入后，再按计划 P2 WordPress 迁移闭环、P3 数据装配、P4 模板编辑、P5 发布闭环开发。P7 生产多实例升级须基于试点和压测数据启动。
|
||||
@@ -0,0 +1,42 @@
|
||||
# SiteForge Enterprise V8.10.0-dev.1 — 管理后台易用性升级验收
|
||||
|
||||
## 本轮实际交付
|
||||
|
||||
- 默认路由 `/` 改用全新的简洁工作台（`app/templates/workspace.html`、`app/static/workspace.{css,js}`）。
|
||||
- 原后台迁移到 `/classic`，以保证原有功能与接口可回退；原数据库和 Worker 不变。
|
||||
- 合并日常导航：工作台、我的网站、网站概览、内容与页面、外观与设计、导入与迁移、构建与交付、网站设置。
|
||||
- 默认隐藏复杂技术入口；展开“高级工具”可访问 WordPress/连接器/模板/任务/审批等全部既有模块。
|
||||
- 新建网站、内容 CRUD（新建与编辑）、主题切换、站点设置、文件直接导入、后台构建及其质量报告和预览均使用原有真实 API。
|
||||
- 新工作台加入四步流程引导，识别内容数量、构建版本、域名是否已配置。
|
||||
- 专业数据工作台 `/production-v8` 按任务切换（批次数据、整站模板、WordPress、XML/API、MySQL），保留原控件 ID 和事件处理。
|
||||
- 桌面和移动端响应式样式，手机侧滑菜单，可见键盘焦点与 reduced-motion 支持。
|
||||
- CI / 后端 / 镜像版本更新为 `8.10.0-dev.1`，Compose 试点项目名 `siteforge-v8-10`。
|
||||
|
||||
## 本地已验证
|
||||
|
||||
- `python -m pytest -q --disable-warnings`：**210 passed**。
|
||||
- `python -m compileall -q app`：完成。
|
||||
- `node --check app/static/*.js`（逐文件执行）：完成。
|
||||
- 新增四项 HTTP 路由/静态资源/真实 API 操作专项测试。
|
||||
- 独立 HTML 离线交互预览已生成：可以切换菜单和体验模拟数据，不会操作真实项目。
|
||||
|
||||
## 严格边界
|
||||
|
||||
- 这是**管理后台体验升级**，不是对 Art Design Pro 官方工程的完整重构。
|
||||
- 高级主题页、Editor 三栏设计器、运行中心仍是既有单独页面，下一轮可以逐步统一视觉组件。
|
||||
- 离线预览使用虚构数据，仅供查看界面；创建、导入等操作在实际项目上通过 API 生效。
|
||||
- 未执行真实 Docker Engine、生产浏览器多设备交互、正式云端 CI、可用性用户访谈。
|
||||
- 简易文件导入使用直接导入 API，不提供迁移审计；关键 WordPress 项目应进入高级迁移工作台。
|
||||
|
||||
## 运行
|
||||
|
||||
首次部署（Windows PowerShell）：
|
||||
|
||||
```powershell
|
||||
docker run --rm -v "${PWD}:/project" -w /project python:3.12-slim python scripts/init_config.py
|
||||
docker compose up -d --build
|
||||
```
|
||||
|
||||
浏览器访问 `http://localhost:8787/`。旧版管理页位于 `/classic`，便于对比和临时回退。
|
||||
|
||||
使用独立 Compose 测试卷，正式升级前做好数据库和媒体备份。
|
||||
@@ -0,0 +1,35 @@
|
||||
# V8.10 网站工作台 — 导航与使用指南
|
||||
|
||||
## 为什么重做
|
||||
|
||||
原后台同时开放网站列表、生产中心、迁移中心、模板库、编辑器和企业任务中心，导致用户需要记住多个入口、多个版本名称以及操作先后顺序。V8.10 将日常操作按用户目标分组。
|
||||
|
||||
## 菜单结构
|
||||
|
||||
| 新菜单 | 用户能完成的事 | 后台能力来源 |
|
||||
|---|---|---|
|
||||
| 工作台 | 查看项目、下一步建议 | `/api/sites` |
|
||||
| 我的网站 | 创建/选择站点 | `/api/sites` |
|
||||
| 网站概览 | 四步建站引导 | 站点、内容、构建 API |
|
||||
| 内容与页面 | 新建/修改内容，打开设计器 | `/api/sites/{id}/entries`, `/editor/...` |
|
||||
| 外观与设计 | 切换主题，进入页面设计 | `/api/sites/{id}`, `/editor/...` |
|
||||
| 导入与迁移 | 文件导入，进入复杂迁移工作台 | `/api/sites/{id}/import`, `/production-v8` |
|
||||
| 构建与交付 | 任务提交、预览、报告、ZIP | `/api/sites/{id}/builds`, `/api/enterprise/.../jobs/...` |
|
||||
| 网站设置 | 企业名、域名、Logo 等 | `PATCH /api/sites/{id}` |
|
||||
| 高级工具 | WordPress 分页采集/字段映射/审批/高级主题 | 现有独立页面 |
|
||||
|
||||
## 设计原则
|
||||
|
||||
1. 默认只展示当前步骤需要的信息；SEO 专业选项折叠。
|
||||
2. 仅一个网站选择器；日常导航稳定不变化。
|
||||
3. 明确区分保存内容、发布设计、构建静态文件、正式上线；不宣称一键构建就是上线。
|
||||
4. 面向普通用户使用业务词汇，技术字段保留在高级功能。
|
||||
5. 所有关键操作使用真实已有 API，CSRF 与后台权限未绕过。
|
||||
6. 电脑/手机响应式，移动侧边栏可关闭，按钮有可见焦点。
|
||||
|
||||
## 已知边界
|
||||
|
||||
- `/production-v8`、`/operations`、`/factory-studio` 的深度功能仍保持原布局；本次统一的是默认后台和一级业务入口。
|
||||
- 简易文件导入是直接导入，并非迁移审计工作流。旧站迁移应从高级工作台进行。
|
||||
- 可视化编辑继续使用已有三栏设计器，尚非完整 Art Design Pro 官方前端。
|
||||
- 真实服务器和用户访谈的可用性验收尚需执行。
|
||||
@@ -0,0 +1,31 @@
|
||||
# SiteForge Enterprise V8.1.0-dev.1 — 开发验收与下一阶段
|
||||
|
||||
本报告依据 V8.0.0-dev.1 代码增量及《COMPLETION_PLAN(1).md》，不是完整企业生产验收。
|
||||
|
||||
## 交付增量
|
||||
|
||||
- 新增 WordPress REST 迁移会话持久化（状态、页码、采集数、异常、取消）。
|
||||
- 原 URL、SEO Title、Description、Canonical、Robots、H1 可从公开 WP REST 返回信息形成基线；未暴露信息需单独补采。
|
||||
- 单页（最多 50 条）安全访问和暂存；人工确认后应用全部批次，避免中途自动覆盖内容。
|
||||
- 网络失败与服务器重启后保留页码；并发采集采用租约防止重复执行；重复阶段复用已暂存批次。
|
||||
- 采集上限被触及时停止完成流程，防止缺页的站点被误标为已迁移。
|
||||
- 外部链接、缺 SEO 元数据、未本地化媒体及复杂字段写入人工复核，与现有审核门禁集成。
|
||||
- 浏览器控制台增加会话建立、采集、连续扫描、停止、确认、取消和最新构建差异报告入口。
|
||||
- 新增不依赖外部 WordPress 的确定性接口模拟测试与现有项目回归。
|
||||
|
||||
## 尚未完成（不得标注已实现）
|
||||
|
||||
1. 全部 WordPress 内容类型与分页边界的异步 Worker 抓取（当前为受限同步请求逐页推进）。
|
||||
2. Sitemap index/gzip、图片资源镜像与文件校验、媒体路径保留。
|
||||
3. WooCommerce/ACF/Elementor 完整适配及复杂字段映射。
|
||||
4. Art Design Pro 官方完整工程编译，PostgreSQL / Redis 实机部署。
|
||||
5. SFTP / S3 原子发布、灰度监控与生产回滚演练。
|
||||
6. Docker 实机、真实 Chromium 浏览器和授权真实网站的全量验收。
|
||||
|
||||
## 验收依据
|
||||
|
||||
- 本地 pytest 完整回归（以交付时实际运行结果为准）。
|
||||
- UI inline JavaScript 语法检查、Python 编译、版本与 Compose 静态检查。
|
||||
- 交付 ZIP 与目录一致性核验。
|
||||
|
||||
**重要：** 对 `completed_with_warnings` 的迁移，会继续产生待复核的 CMS 事项；发布必须经过现有质量和审核流程，不能把“采集已完成”视为“网站可正式上线”。
|
||||
@@ -0,0 +1,33 @@
|
||||
# SiteForge Enterprise V8.2 开发验收与边界
|
||||
|
||||
**基线：** V8.1.0-dev.1 的 110 项测试与原有四套主题、企业访问控制、数据暂存、版本化构建和审核功能；本版基于相同源码目录增强。
|
||||
|
||||
## 本次已实现
|
||||
|
||||
- `wp_migration_v82.py`：Sitemap Index/urlset 同源读取、XML 安全解析、gzip 有界解压、条数/文件数限制、缺漏计算与审计复核。
|
||||
- 媒体文件先验证 URL 与 MIME/文件签名；禁用任意 CDN 自动取回、SVG、跳转；保存至站点隔离媒体目录；仅重写尚未提交的导入批次。
|
||||
- `jobs.submit_migration`：与构建任务共享持久队列、幂等键、全局和单站容量限制。
|
||||
- `app.job_runner`：Worker 子进程依据 `kind` 执行 WordPress REST 采集，重试 HTTP 502/503/504 类中断，并保留原有完成/失败/取消状态。
|
||||
- `run_scan`：逐页调用已有持久迁移检查点；重启检测到旧采集租约时先等待租约到期，避免短时间内重复领取。
|
||||
- `wp_migration_v81.finalize`：增加 Sitemap 缺页和未本地化图片发现，沿用既有 CMS 复核与发布阻断。
|
||||
- 更新 V8 控制台按钮、文档、Compose 镜像版本、发布代理镜像引用、版本验收脚本。
|
||||
|
||||
## 实测
|
||||
|
||||
- Python pytest **120 项全部通过**（本地依赖环境，非全新 Docker）；Python 编译和 JS 语法检查通过。
|
||||
- `scripts/verify_release.py` 验证版本、四主题、异步构建路径、锁定依赖、CI 文件与 JavaScript。
|
||||
- 专项测试使用本地确定性 WordPress/Sitemap/媒体响应模拟，未向生产网站发起采集。
|
||||
|
||||
## 未实现或未验收
|
||||
|
||||
1. **WordPress 完整迁移**：分类、标签、作者、评论、WooCommerce 变体、ACF 复杂关系、Elementor 布局复刻、附件库、原有转址、所有未开放 REST 字段仍不完整。
|
||||
2. **全站素材本地化**：当前只对暂存批次的特色图与主要 `<img src>` 分批处理；`srcset` 多分辨率、CSS、视频/附件和跨站 CDN 未完整覆盖。
|
||||
3. **任意目标站点 SEO 100% 保真**：Sitemap 使用者需先运行发现和审计，并对缺失路径/Canonical/媒体进行人工复核。
|
||||
4. **Art Design Pro 官方完整后台**：仍仅有业务接入组件与安装程序，未包含官方工程或通过生产编译。
|
||||
5. **生产数据库和队列**：PostgreSQL/Redis 仍需数据迁移、跨实例、容灾和安全压测。
|
||||
6. **SFTP/S3 正式发布**：原有审批/Agent 基础仍未经过真实远程服务器原子切换与回滚验收。
|
||||
7. **运行环境**：尚未完成 Docker 引擎实机、浏览器、GitHub 云端 CI、真实 WordPress 站点的端到端验证。
|
||||
|
||||
## 推荐下一验收
|
||||
|
||||
在授权的测试 WordPress 站点及独立 Docker 环境执行：创建迁移会话 → Worker 完整读取 → Sitemap 缺漏对照 → 分批图片本地化 → 复核异常 → 确认导入 → 生成站点 → 逐 URL SEO 验收 → 审核发布测试服务器 → 故障回滚。保留完整构建号、审计报告、网页截图和任务日志，作为正式交付证据。
|
||||
@@ -0,0 +1,45 @@
|
||||
# SiteForge Enterprise V8.3.0-dev.1 — WordPress 分类、标签与媒体目录
|
||||
|
||||
## 已实现（可在本地固定夹具测试）
|
||||
|
||||
- 保留 V8.2 WordPress REST 分页文章和页面扫描、Worker 任务、Sitemap 审计和媒体本地化。
|
||||
- 新增 `wp_migration_v83.py`：公开 WP REST `categories`、`tags`、`media` 目录的逐页采集。每类资源独立保存页码、累计数量和是否完成；每页最多 50 条、每类最多 5,000 条；所有远程访问走项目安全 HTTP 客户端。
|
||||
- 保存源 WP taxonomy/media ID、名称、slug、parent、源归档 URL、媒体 MIME/尺寸/替代文本的有限元数据；逐项关系使用 `wp_catalog_refs` 表保存。数据仍保持在原迁移会话作用域。
|
||||
- WP 文章的源 ID、分类/标签 ID、特色媒体 ID 和部分公开 ACF 快照进入分批暂存数据的 `meta.wp_source`；ACF 过大不存储原值，只记录字段名与需复核提示。不自动执行或重建 Elementor、插件脚本。
|
||||
- 已同步名称自动补齐暂存内容 `meta.fields.category/tags`，确认导入后随内容保存；新同步不会修改已经正式提交或人工编辑的正文。
|
||||
- 分类/标签归档原 URL 在 `finalize` 时进入 SEO 基线，不会凭空生成不存在的归档页面；不匹配仍须由 URL/SEO 审计处理。
|
||||
- 未找到的关系、缺失上级分类、空名称、跨域归档 URL、ACF 等进入人工复核。只有全部审核完才允许按既有发布门禁继续。
|
||||
- Web 工作台新加“分类 / 标签 / 媒体库”分页同步与目录进度查询。
|
||||
|
||||
## API（需已登录 + CSRF + 站点权限）
|
||||
|
||||
- `GET /api/migrations/sites/{site}/wordpress/sessions/{session}/catalog`：查询资源采集检查点及数量
|
||||
- `POST /api/migrations/sites/{site}/wordpress/sessions/{session}/catalog/categories/next`：同步下一页公开分类
|
||||
- `POST /api/migrations/sites/{site}/wordpress/sessions/{session}/catalog/tags/next`：同步下一页公开标签
|
||||
- `POST /api/migrations/sites/{site}/wordpress/sessions/{session}/catalog/media/next`：同步下一页公开媒体库元数据
|
||||
- `POST /api/migrations/sites/{site}/wordpress/sessions/{session}/catalog/refresh`：手动刷新待导入文章里的分类和标签名称
|
||||
|
||||
**操作顺序**：建立迁移会话 → 采集 WordPress 页面与文章（Worker）→ 同步分类、标签、媒体库元数据直到各目录 `done=true` → 执行 V8.2 媒体本地化 → 核对 Sitemap 缺失 URL 与分类归档 URL → 确认正式导入 → SEO/发布审核。
|
||||
|
||||
## 已验证
|
||||
|
||||
- 旧有 120 项及新增 10 项，合计 **130 项 pytest 通过**。
|
||||
- 覆盖源 ID 保存、分类和标签关联、独立媒体清单、幂等分页、网络故障游标保护、越权、目录同步 API、人工复核、归档 URL 基线等。
|
||||
- Python 编译、JavaScript 语法、版本核查见 `scripts/check.sh` 和 `scripts/verify_release.py`。
|
||||
|
||||
## 未完成 / 严禁误标为生产完成
|
||||
|
||||
- WordPress 分类/标签 **元数据同步** 不等于完整重建分类归档页内容和样式。保存原 URL 以便后续修复或人工批准的重定向。
|
||||
- WordPress 媒体库 **目录同步** 不等于下载了全量媒体二进制；只下载 V8.2 明确扫描并授权的正文、封面图片，其他附件、PDF、CDN、`srcset`、CSS 背景仍需继续处理。
|
||||
- 公开 WP REST 对 ACF、Elementor、WooCommerce 变体/库存/属性的暴露程度因站而异；本版只保留有限元数据和复核提示，不做复杂插件的布局无损转换。
|
||||
- 目录同步目前是“一次一页”的同步 API，不是长时独立 Worker 任务；大规模任务应继续入队列。
|
||||
- 未做真实 Docker Engine、授权生产 WordPress 全站、GitHub 云 CI、正式 Art Design Pro 构建和远程 SFTP/S3 发布验收。
|
||||
- 旧数据库上的原地升级、数据库备份与正式回滚仍需要在隔离环境演练。
|
||||
|
||||
## 下一批具体开发建议
|
||||
|
||||
1. 完成分类/标签归档模板生成或经过人工批准的 301 重定向映射，并纳入 URL/SEO 验收。
|
||||
2. 实现媒体附件全量清单 + 授权可下载资产、失败可续传、二进制校验与附件引用关系。
|
||||
3. 针对真实 ACF / Elementor / WooCommerce 导出文件，建立固定测试夹具和受限字段适配器。
|
||||
4. 把分类、标签、媒体目录同步放入独立 Worker 任务，具备取消、进度和故障恢复。
|
||||
5. 在稳定的 P2 迁移流程后启动 P3 API/XML/只读数据库连接器和 P4 编辑器增强。
|
||||
@@ -0,0 +1,46 @@
|
||||
# SiteForge Enterprise V8.4.0-dev.1 — P3 XML / 公开 HTTP API 连接器
|
||||
|
||||
## 本次实际完成
|
||||
|
||||
本版本基于 V8.3 完整项目继续开发，保留四套主题、WordPress P2 迁移工作台、V8 暂存批次、Worker、网站构建与 SEO 审核。
|
||||
|
||||
| 项目 | 代码交付 | 适用边界 |
|
||||
|---|---|---|
|
||||
| XML 文件导入 | `app/connectors_v84.py` `parse_xml_records`，认证上传 API 和控制台 | 1–8 MB，最多 1000 个 `record_tag`，扁平/两层记录，禁止 DTD/XXE，节点深度/数量/字段值限制 |
|
||||
| 公开 HTTP API | 创建受限 HTTPS JSON 数据源，定义 `data.items` 等 JSON 路径、分页、字段映射 | **仅公开、不需要令牌的 JSON API**；不接受登录凭据、表单登录或用户自定义脚本 |
|
||||
| Worker 采集 | `kind=api_scan` 使用既有租约 Worker 子进程，超时、取消、有限次数重试 | 单次最多 50 页、每页最多 100 项，总计 5000 项；当前不使用任意下一页 URL |
|
||||
| 断点续跑/幂等 | `v84_api_pages` 逐页持久化检查点，重试查找之前已暂存的页面批次 | 分页按页码稳定顺序；若上游 API 对同一页改变数据，需重新建立数据源做差异验证 |
|
||||
| 批次安全 | 所有采集只产生 `staged`，沿用 V8 的冲突预览、人工提交、手工修改保护和回滚 | **采集完成不自动入库**，更不自动构建或发布 |
|
||||
| 网站后台 | `/production-v8` 加入 XML 上传、API 配置、提交/取消、查看数据源进度 | `limit_reached` 表示达到页数上限，不应被理解为全量采集完成 |
|
||||
| 认证 | 全部新接口复用现有 Session、CSRF、站点权限检查 | 管理员需保障来源合法授权、数据质量和个人信息合规 |
|
||||
|
||||
## API
|
||||
|
||||
- `POST /api/connectors/sites/{site_id}/xml/staging`：multipart `file`、`record_tag`、`content_type`、`mapping_json`。
|
||||
- `POST /api/connectors/sites/{site_id}/api-sources`：JSON 配置公开 HTTPS JSON API，支持 `url`、`items_path`、`page_param`、`per_page_param`、`page_size`、`max_pages`、`mapping`、`content_type`。
|
||||
- `GET /api/connectors/sites/{site_id}/api-sources`：数据源列表。
|
||||
- `GET /api/connectors/sites/{site_id}/api-sources/{source_id}`：检查点和暂存批次。
|
||||
- `POST /api/connectors/sites/{site_id}/api-sources/{source_id}/scan`：提交 Worker 采集，可传 `idempotency_key`。
|
||||
- `POST /api/connectors/sites/{site_id}/api-sources/{source_id}/cancel`：标记源取消并请求取消相关 Worker 任务。
|
||||
|
||||
## 安全限制
|
||||
|
||||
外部请求沿用 `app/safe_http.py`：固定安全 DNS 解析的公网 IP、校验证书、阻止内部/保留地址及重定向（`redirects=0`）、限制默认 HTTPS 端口、20 秒单请求超时、2 MB JSON 响应大小。XML 通过 `defusedxml` 禁止 DTD/实体并进行整体结构上限检查。来源 URL 拒绝常见令牌参数，且**不接受认证请求头**。
|
||||
|
||||
不允许任意 SQL/代码执行。数据库侧 **MySQL 只读连接器没有在本轮交付**，需下一阶段使用受限数据库账号、TLS、白名单视图、参数化列选择并在容器化夹具中验收。
|
||||
|
||||
## 本地已执行验收
|
||||
|
||||
- 144 项自动化测试通过，含新增 14 项 XML/API/Worker/安全/权限/断点续跑测试。
|
||||
- `python scripts/verify_release.py` 通过，Python 源码编译与 Node JavaScript 语法检查通过。
|
||||
- V8.4 管理控制台的接口使用 TestClient 验证了登录、CSRF、XML 上传和 API 数据源创建。
|
||||
|
||||
**尚未验收：** Docker 实机启动、官方 Art Design Pro 编译、云端 GitHub CI 执行、真实公开 API 连续采集（当前以固定虚构服务响应做确定性测试）、大批量吞吐、外部网络故障场景、多服务器发布和实际 MySQL 数据库安全测试。因此该版本仍为开发/试点候选版，而不是已交付企业生产的终版。
|
||||
|
||||
## 后续 P3/P4/P5 优先项
|
||||
|
||||
1. 具备 Secret ID 轮换的认证 HTTP API（不接受明文凭据填在 URL 或日志中）。
|
||||
2. 数据库侧只读账号的 MySQL 白名单表/视图连接器，按 500 条分批及批次回滚。
|
||||
3. 通用映射 Schema、内容关系规范、批量导入进度、冲突审核 UI。
|
||||
4. 整站模板编辑器、可回滚草稿与页面响应式联动；最终 SFTP/S3 安全发布验收。
|
||||
5. GitHub 云端 CI、Docker PostgreSQL/Redis 迁移与运行验收；认证、容量、安全、重试及取消的完整故障注入。
|
||||
@@ -0,0 +1,73 @@
|
||||
# SiteForge Enterprise V8.5.0-dev.1 — P3 认证 API 与安全 MySQL 数据连接器
|
||||
|
||||
## 开发范围与实际代码
|
||||
|
||||
- **认证 HTTPS JSON API**：原 `v84_api_sources` 数据源升级为 `auth_type` / `auth_header` / `secret_ref`。支持公开、Bearer Token、X-API-Key 和经限制的自定义 `X-*` 请求头。Web 创建数据源时仅校验 `env:SITEFORGE_*` / `file:*` 引用格式；由独立 Worker 执行时才读取凭据。前端、列表和详情响应不返回密钥引用或值。
|
||||
- **安全 HTTP**：原有 DNS 解析与套接字固定连接、TLS 域名验证继续使用；携带凭据必须走 HTTPS 且禁止重定向，拒绝 Cookie/Host 等非允许的凭据请求头。API JSON 只读 GET，分批暂存，继续支持断点续跑、任务取消、重试及容量限制。
|
||||
- **MySQL 只读连接器**：新增 `app/connectors_v85.py`；管理员需要在 Worker 环境设置 `SITEFORGE_MYSQL_ALLOWED_HOSTS` 与 `SITEFORGE_MYSQL_ALLOWED_TABLES`，以及数据库侧真实 `SELECT`-only 账号。系统仅接受安全的库名/表名/列名，按唯一游标列执行固定参数化 `SELECT … WHERE key > %s ORDER BY key LIMIT %s`，强制 TLS 证书和主机名校验，开启数据库 READ ONLY 事务。不存在让用户提交原始 SQL 的入口。
|
||||
- **数据暂存与可审计回滚**：MySQL 单批最多 250 行、最多 50 页且最多 5000 行；API 延续单页 100、总量 5000 的限制。每页用源 ID 和页码建立稳定来源标识；Worker 崩溃后按页/批次检查点恢复；仍需明确点击“提交”后才真正入站。用户可以在允许的条件下用 V8 批次回滚功能撤销导入，防止覆盖人工修改。
|
||||
- **关系检查**：新增独立只读 API 预览批次的品牌、分类和未知品牌页面引用；只提示问题、不猜测品牌、不修改内容。网站隔离与会话/CSRF 权限继续保留。
|
||||
- **后台入口**：`/production-v8` 增加认证方式、密钥引用字段、MySQL 数据源、Worker 执行/取消，以及批次“关系检查”按钮。
|
||||
|
||||
## 使用与密钥配置
|
||||
|
||||
开发环境示例（不要将凭据提交到 Git）：
|
||||
|
||||
```dotenv
|
||||
SITEFORGE_MYSQL_ALLOWED_HOSTS=mysql.example.com
|
||||
SITEFORGE_MYSQL_ALLOWED_TABLES=catalog.products_public,catalog.brands_public
|
||||
SITEFORGE_MYSQL_READ_USER=<read_only_username>
|
||||
SITEFORGE_MYSQL_READ_PASSWORD=<read_only_password>
|
||||
```
|
||||
|
||||
然后数据源配置：
|
||||
|
||||
```json
|
||||
{
|
||||
"host":"mysql.example.com",
|
||||
"database":"catalog",
|
||||
"table":"products_public",
|
||||
"key_column":"id",
|
||||
"columns":["id","name","brand","category"],
|
||||
"user_ref":"env:SITEFORGE_MYSQL_READ_USER",
|
||||
"password_ref":"env:SITEFORGE_MYSQL_READ_PASSWORD",
|
||||
"mapping":{"title":"name","brand":"brand","category":"category"},
|
||||
"page_size":100,
|
||||
"max_pages":20
|
||||
}
|
||||
```
|
||||
|
||||
生产环境推荐将账号/密码分别保存到宿主机 `private_secrets/mysql_reader_user` 和 `private_secrets/mysql_reader_password`，并启用 `compose.mysql-secrets.yaml` 只挂载到 Worker 的 `/run/secrets`。前端对应填写 `file:mysql_reader_user` / `file:mysql_reader_password`。如服务器使用自签名 CA，将受信任 CA 放在 `private_ca/mysql-ca.pem`，并设置 `SITEFORGE_MYSQL_CA_FILE=/etc/siteforge/certs/mysql-ca.pem`。**这两类目录已排除在 Git/Docker 构建上下文之外**。
|
||||
|
||||
执行：
|
||||
|
||||
```bash
|
||||
# 确保 private_secrets/ 与 private_ca/ 已创建、权限正确
|
||||
mkdir -p private_secrets private_ca
|
||||
docker compose -f compose.yaml -f compose.mysql-secrets.yaml up -d --build
|
||||
```
|
||||
|
||||
外部 API 示例（Bearer）：选择 HTTPS URL、`auth_type=bearer`、`secret_ref=file:partner_api_token`，并将密钥文件放在 Worker 挂载的 `/run/secrets`。密钥不放在 URL 参数、JSON 正文、API 结果或 Git 仓库中。缺少该密钥文件时，Worker 会报告采集失败；并不会降级为公开采集。
|
||||
|
||||
## 主要 API
|
||||
|
||||
| API | 说明 |
|
||||
|---|---|
|
||||
| `POST /api/connectors/sites/{site}/api-sources` | 公开或认证 HTTPS JSON API 数据源 |
|
||||
| `GET /api/connectors/sites/{site}/api-sources/{id}` | API 进度；不显示密钥引用 |
|
||||
| `POST /api/connectors/sites/{site}/mysql-sources` | 创建经白名单校验的 MySQL 数据源（owner 权限） |
|
||||
| `GET /api/connectors/sites/{site}/mysql-sources` | MySQL 数据源列表 |
|
||||
| `POST /api/connectors/sites/{site}/mysql-sources/{id}/scan` | 进入 Worker 队列 |
|
||||
| `POST /api/connectors/sites/{site}/mysql-sources/{id}/cancel` | 申请取消 |
|
||||
| `GET /api/connectors/sites/{site}/import-batches/{id}/relationships` | 预览品牌、分类及潜在缺失关联 |
|
||||
|
||||
## 验证和限制
|
||||
|
||||
- 本轮新增加 **13 项**专项测试，合计 **159 项本地自动化测试通过**（完整回归、版本、Python 编译和 JS 语法在打包时再次执行）。
|
||||
- 真实数据库 `PyMySQL` 连接、TLS 证书、数据库侧最小权限、Docker Compose 启动、GitHub Actions 云端 CI，以及 5000 行产品真实压测**尚未实机验证**。新增测试使用确定性本地模拟连接器；因此不能宣称 MySQL 已完成生产部署验收。
|
||||
- 无任意 SQL，也不自动跨站抽取未经授权的数据库；真正的数据库用户必须由管理员在 MySQL Server 上授予只读权限。数据库只读事务不是数据库权限的替代品。
|
||||
- 数据批次按原 V8 规则暂存、提交、受保护回滚；本轮没有实现多库 JOIN、增量 CDC、数据库写回、API OAuth 授权流程或通用数据关系图。
|
||||
|
||||
## 仍待完成的完整网站工厂需求
|
||||
|
||||
P4 完整可视化组件、整站模板兼容性和草稿隔离；P5 生产 SFTP/S3 原子发布和回滚；P6 多语言内容关系与 hreflang；Art Design Pro 官方工程完整编译；PostgreSQL/Redis 高可用、企业身份和正式安全/浏览器/容器验收。
|
||||
@@ -0,0 +1,33 @@
|
||||
# SiteForge Enterprise V8.6.0-dev.1 — P4 开发与验收
|
||||
|
||||
## 与 V8.5 相比已完成
|
||||
|
||||
| 项目 | 代码实现 | 本地验证 | 外部/生产验证 |
|
||||
|---|---|---|---|
|
||||
| 轮播、视频、分组、方案、地图外链、询盘组件 | 已完成 | 安全渲染测试 | 未做真实浏览器视觉验收 |
|
||||
| 属性契约 | 已提供只读接口 | Schema 测试 | 仍待按字段类型细化 |
|
||||
| 独立草稿保存、版本检测、原子发布与放弃 | 已完成 | HTTP 测试与真实静态构建前后对比 | 未执行多人/多实例压测 |
|
||||
| 整站模板主题版本及兼容性预检 | 已完成 | API、冲突、无副作用测试 | 未覆盖所有外部主题版本 |
|
||||
| 现有数据导入、WordPress、Worker 与主题 | 保留 | 168 项回归 | 真实系统待验收 |
|
||||
|
||||
## 注意的兼容性边界
|
||||
|
||||
- 历史 `/api/sites/{site}/pages/{entry}/blueprint` 接口仍允许直写正式页面；新编辑器已改用独立的 `studio-draft` 接口。若全面推行审批，应进一步迁移/限制旧直写接口。
|
||||
- 设计草稿独立于正式内容及静态构建，但正式编辑发布并不等于网站已经上线，还必须发起 Worker 构建、SEO/质量审计与既有发布审批。
|
||||
- 轮播为键盘可滚动的 CSS scroll-snap 列表，不是定时自动轮播；标签采用 native details，保证基础无障碍与无需自定义 JS。
|
||||
- 表单组件是跳转到内部联系页或可信外部页面，不提供内置服务端提交、验证码、邮件通知。
|
||||
- 视频只接受 YouTube/Vimeo 白名单 HTTPS URL；地图只提供 Google Maps/OpenStreetMap 外链，不注入第三方 SDK。
|
||||
- 整站模板快照不复制源站业务正文、SEO、域名、认证信息。模板兼容不代表真实视觉质量合格。
|
||||
- 原项目使用 SQLite 开发库，企业 PostgreSQL/Redis 兼容与多实例部署仍未做真正生产级验收。
|
||||
|
||||
## 验收结果
|
||||
|
||||
- Python pytest：168 项全部通过。
|
||||
- `python scripts/verify_release.py`：版本、主题模板数量、Worker 构建路由、固定依赖、CI 文件、JS 语法检查通过。
|
||||
- Python 编译及编辑器运行脚本 `node --check` 通过。
|
||||
- 静态构建隔离专项回归：保存草稿后构建的 HTML 不包含私有草稿；发布设计后重建才包含相应区块。
|
||||
- 暂缺：真实 Docker Desktop 构建启动、云端 CI、Chrome 桌面/手机端真实 E2E、旧站升级恢复演练。
|
||||
|
||||
## 下一阶段建议
|
||||
|
||||
P4 继续完成每个组件更严格的 JSON Schema、完整全站页眉页脚可视化修改、360/390/1024/1440px 浏览器视觉回归、跨语言内容。随后集中完成 P5 SFTP/S3 原子发布与回滚，P6 hreflang 内容关系，以及 Art Design Pro 官方工程与企业服务的正式验收。
|
||||
@@ -0,0 +1,25 @@
|
||||
# SiteForge Enterprise V8.7.0-dev.1 — 开发验收与剩余工作
|
||||
|
||||
## 本轮范围：P4 全站设计与原有编辑 API 保护
|
||||
|
||||
| 需求 | 实现证据 | 结论 |
|
||||
|---|---|---|
|
||||
| 四主题站点导航/页眉/页脚设置 | `app/site_design_v87.py` + 四套 `themes/*/pro.html` | 后端与构建器完成 |
|
||||
| 草稿保存/发布隔离 | `site_design_drafts`、`site_design_publications` | 测试通过 |
|
||||
| 响应式调整 | `responsive_css()` 注入 `assets/custom.css` | 手机/平板间距与显隐完成；非独立自由画布 |
|
||||
| 全站设计令牌 | 设计令牌写入草稿，发布才更新 settings | 测试通过 |
|
||||
| 旧接口绕过保护 | `require_legacy_enabled()`，默认 HTTP 409 | 测试通过；某些其他历史入口待进一步统一 |
|
||||
| 后台操作 | `app/templates/editor.html`、`app/static/editor.js`、admin/enterprise 脚本 | JavaScript 语法通过，浏览器实机待验收 |
|
||||
| 生产发布与 Art Design Pro | 无正式环境 | **未完成** |
|
||||
|
||||
本地自动化测试：**181 项全部通过**，在 V8.6 的 168 项基础上新增 13 项测试。四套静态演示站实际各生成 36 页（共 144 页），质量报告均为 0 个 error / 0 个 warning，演示内容为虚构样本。
|
||||
|
||||
代码侧进行了 Python 编译、JavaScript 语法、主题构建和 ZIP 校验；未执行真实 Docker 或浏览器视觉端到端验收。Docker 启动、跨浏览器 E2E、实际用户权限对抗测试和生产发布仍需外部环境验证。
|
||||
|
||||
## 升级注意事项
|
||||
|
||||
- 在测试环境备份数据库、媒体文件与构建归档后升级，不要覆盖现有正式数据卷。
|
||||
- 新增两张表采用 `CREATE TABLE IF NOT EXISTS` 幂等创建。
|
||||
- 旧 API 对设计的直接写入默认禁用；如外部脚本依赖它们，必须改为新的草稿 API + 发布 API。
|
||||
- 只有进入 `site_design_drafts` 的全站设计设置需要发布；保存草稿不会更改历史已构建 ZIP。
|
||||
- 当前单机 SQLite 实现没有得到 PostgreSQL 并发生产压力测试结果。
|
||||
@@ -0,0 +1,55 @@
|
||||
# 历史记录：V8.0 开发状态（已被 V8.1 替代）
|
||||
|
||||
此文档仅保留 V8.0 的历史验收数据。当前版本请看 `V8_1_RELEASE_STATUS.md`。
|
||||
|
||||
# SiteForge V8 开发状态与验收证据
|
||||
|
||||
> 平台版本 `8.0.0-dev.1`。本文件仅记录本轮可核实的功能；未验证即不标记完成。
|
||||
|
||||
## 目标
|
||||
|
||||
统一项目架构，最终满足旧站迁移、模板新建、数据自动装配、可视化设计、安全构建、迁移 SEO 检查、审批发布与回滚。技术路线以 `COMPLETION_PLAN(1).md` 的 P0–P7 为依据。规划中的人日/时间不是本次完成度证据。
|
||||
|
||||
## 本次已经开发并验证的增量
|
||||
|
||||
| 领域 | 实现 | 验证 |
|
||||
|---|---|---|
|
||||
| V8 版本基线 | 主版本常量、Compose 标签、CI 版本断言、Release 检查脚本统一为 `8.0.0-dev.1` | 版本测试、release 脚本 |
|
||||
| Web 控制台 | `/production-v8` 管理页面，支持多网站切换、内容文件暂存、批次列表、模板套版、Worker 提交 | 受保护页面 HTTP 与 API 测试 |
|
||||
| 内容批次 | 映射、URL 冲突预检、来源主键、批次历史、提交 skip/replace、旧数据快照与回滚 | 11+ V8 测试，完整回归 |
|
||||
| 安全回滚 | 回滚时在同一数据库写事务内检查人工修改指纹，禁止强制覆盖已修改内容 | 竞态预检相关测试 |
|
||||
| WordPress WXR | 受限解析、页面/文章类型保留、复杂 Elementor/WooCommerce 人工复核持久化 | WXR 安全和复核测试 |
|
||||
| 整站模板 | 安全声明式页面结构快照、兼容性检查、应用新站、保留原站数据/SEO | 跨站模板测试 |
|
||||
| Art 对接源码 | 新增 `V8Production.vue`，安装脚本按路由标记避免重复注册并备份原文件 | 模拟 Art 工程自动测试 |
|
||||
| 统一构建 | 继承 V7.2 原有 Worker 子进程构建，V8 新 UI 调用原队列 | HTTP → Worker 子进程 → ZIP 冒烟 |
|
||||
|
||||
## 当前测试证据
|
||||
|
||||
- 本地：**100 项 pytest 通过**；Linux `scripts/check.sh`、`scripts/verify_release.py` 通过。
|
||||
- 实际 TestClient HTTP：登录、创建 automotive 网站、暂存并提交两条车型、整站模板快照、提交 Worker、由独立 Python 子进程生成 14 个 HTML 页面并下载 ZIP 成功。
|
||||
- 构建 `/api/health` 返回版本 `8.0.0-dev.1`，测试未设置 Git SHA，故返回 `commit=unknown`。正式部署需注入实际提交哈希。
|
||||
- 尚未在此执行 Docker 引擎构建、真正的官方 Art Design Pro 编译、Chrome E2E、PostgreSQL 多实例、正式外网 SFTP/S3 发布。
|
||||
|
||||
## 仍然缺失（不能视为已完成）
|
||||
|
||||
| 项目 | 缺口 |
|
||||
|---|---|
|
||||
| 官方 Art 管理后台 | 完整官方仓库、路由/权限 API 适配、打包与实际浏览器验收 |
|
||||
| P2 迁移 | REST/Sitemap 全量分页、迁移状态机、断点续跑、媒体与 SEO 全量清单、本地模拟服务 |
|
||||
| P3 连接器 | 安全 XML/GET API/MySQL 适配；读库账号/TLS/限流；5,000 条异步导入、批次恢复 |
|
||||
| P4 编辑器 | 组件 Schema 统一、carousel/video/tabs/pricing/map、完整设备断点与模板兼容矩阵 |
|
||||
| P5 发布 | SFTP/S3 不可变目录及原子指针切换、上线后探测、故障注入和自动回滚 |
|
||||
| P6 多语言 | site_groups、locales、translation_groups、页面级 hreflang 与本地化 URL |
|
||||
| P7 企业生产 | PostgreSQL 完整迁移、Redis 正式队列、SSO/MFA、监控/审计/密钥生命周期、容灾及压测 |
|
||||
| 生产认证 | Docker 首次启动、CI 远端运行、跨浏览器视觉/移动端、真实授权旧站迁移、正式域名演练 |
|
||||
|
||||
## 下一阶段具体开发顺序
|
||||
|
||||
1. 建立可重复的 WordPress REST/WXR/Sitemap 本地测试夹具和迁移任务状态机。
|
||||
2. 将大文件导入进入统一 Worker 队列，加入批次检查点与异常恢复机制。
|
||||
3. 正式编译 Art Design Pro 前端并与 Web/API 同域集成，逐步替换原后台。
|
||||
4. 补齐 XML/API/只读 MySQL 连接器与字段映射对比。
|
||||
5. 建立 SFTP/S3 原子发布测试环境和故障注入，接入审批与质量门禁。
|
||||
6. 完成多语言关系模型、企业级数据库升级、运维与生产验收。
|
||||
|
||||
**验收原则**：单个模块有 API 或页面不等于完成；必须有可重复的成功和失败路径测试，并经正式构建发布闭环验证。
|
||||
@@ -0,0 +1,368 @@
|
||||
# trade-pro 第 5 主题移植实施计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 把 cms Astro 主题移植为 SiteForge V8_10 第 5 套内置主题 trade-pro（英文外贸 B2B），平台适配 + 骨架跑通 + 完整模板 + 验收。
|
||||
|
||||
**Architecture:** 三步走——先做平台适配（主题发现单一源、宏覆盖机制、主题资产优先、6 处前端入口），再以骨架主题包在真实 hesupipe 站点（`483295c29ea0`，193 条内容）跑通构建，最后按 cms 设计源（`D:\project\cms\runtimes\astro-site-runtime`）逐模板移植视觉。设计依据：[spec R3](../specs/2026-10-22-trade-pro-theme-design.md)。
|
||||
|
||||
**Tech Stack:** Python 3.12 / FastAPI / Jinja2（FileSystemLoader 多目录）/ pytest / 原生 JS。
|
||||
|
||||
**环境事实（执行者必读）:**
|
||||
- 工作目录：`C:\Users\30997\Downloads\SiteForge_Factory_V5_Web_Docker\SiteForge_Enterprise_V8_10`（下称 `$ROOT`，bash 里用正斜杠）
|
||||
- Docker 实例已运行：`http://127.0.0.1:8787`（容器 siteforge-v8-10-siteforge-1/-worker-1），admin 密码在 `.env`
|
||||
- 测试命令：`python -m pytest -q`（当前 210 项全绿，任何改动后必须保持）；JS 检查 `node --check app/static/<file>.js`
|
||||
- cms 设计源：`D:/project/cms/runtimes/astro-site-runtime/src`（tokens.css 250 行、base.css 445 行、components/*.astro、pages/[locale]/*.astro）；像素基准 `dist/hesupipe/en/`
|
||||
- 改动 Python 后需 `docker compose up -d --build` 重建容器再验证 HTTP 层（构建约 1 分钟，有缓存）
|
||||
- 契约清单已固化于 spec §2（F1-F13），本计划直接引用
|
||||
|
||||
---
|
||||
|
||||
## Phase 1+2：平台适配与骨架跑通（Task 1-8）
|
||||
|
||||
### Task 1: Git 基线
|
||||
|
||||
**Files:** 无新文件（初始化仓库）
|
||||
|
||||
- [ ] **Step 1:** `cd $ROOT && git init && git add -A && git status --short | head -20`
|
||||
- [ ] **Step 2:** 确认 `.env`、`storage/`、`hesupipe_clean2.xml` 未被跟踪（.gitignore 已含 `.env`、`storage/`；`git check-ignore .env` 应有输出；`hesupipe_clean2.xml` 加入 .gitignore 一行）
|
||||
- [ ] **Step 3:** `git commit -m "chore: baseline V8.10.0-dev.1 with v8_workflows type-mapping fix and trade-pro spec"`（含 Co-Authored-By 行，下同）
|
||||
|
||||
### Task 2: 主题发现单一源（F1）
|
||||
|
||||
**Files:**
|
||||
- Modify: `app/core.py:12`
|
||||
- Modify: `app/theme_pro.py:16-18`
|
||||
- Modify: `app/theme_store.py:14`
|
||||
- Test: `tests/test_theme_registry.py`（新建）
|
||||
|
||||
- [ ] **Step 1: 写失败测试**
|
||||
|
||||
```python
|
||||
"""Theme discovery must be a single source of truth."""
|
||||
from app import core, theme_pro, theme_store
|
||||
|
||||
def test_discover_returns_builtin_themes_with_manifests():
|
||||
ids = core.discover_themes()
|
||||
for tid in ('automotive', 'industrial', 'corporate', 'minimal'):
|
||||
assert tid in ids
|
||||
import json
|
||||
for tid in ids:
|
||||
manifest = json.loads((core.ROOT / 'themes' / tid / 'manifest.json').read_text(encoding='utf-8'))
|
||||
assert manifest.get('id') == tid
|
||||
|
||||
def test_three_whitelists_agree():
|
||||
assert set(core.THEMES) == set(theme_pro.THEMES) == set(theme_store.BUILTIN)
|
||||
assert isinstance(core.THEMES, tuple)
|
||||
```
|
||||
|
||||
注：`core.ROOT` 若不存在，测试里用 `pathlib.Path(app.__file__).parent.parent`。
|
||||
|
||||
- [ ] **Step 2:** `python -m pytest tests/test_theme_registry.py -q` → 预期 FAIL（`discover_themes` 不存在）
|
||||
- [ ] **Step 3: 实现**——`app/core.py:12` 替换为：
|
||||
|
||||
```python
|
||||
ROOT_PATH = __import__('pathlib').Path(__file__).resolve().parent.parent
|
||||
|
||||
def discover_themes():
|
||||
"""Single source of truth: scan themes/*/manifest.json (id must match folder)."""
|
||||
import json
|
||||
themes_dir = ROOT_PATH / 'themes'
|
||||
found = []
|
||||
for folder in sorted(themes_dir.iterdir()):
|
||||
if not folder.is_dir() or folder.name.startswith('_'):
|
||||
continue
|
||||
manifest = folder / 'manifest.json'
|
||||
if not manifest.is_file():
|
||||
continue
|
||||
try:
|
||||
if json.loads(manifest.read_text(encoding='utf-8')).get('id') == folder.name:
|
||||
found.append(folder.name)
|
||||
except (ValueError, UnicodeError):
|
||||
continue
|
||||
return tuple(found)
|
||||
|
||||
THEMES = discover_themes()
|
||||
```
|
||||
|
||||
（core.py 顶部已有 `import json`，可复用；实现时去掉重复 import，风格与文件一致。）
|
||||
|
||||
`app/theme_pro.py:16-18` 改为：
|
||||
|
||||
```python
|
||||
from .core import sanitize, route_path, THEMES
|
||||
```
|
||||
|
||||
（删除原第 18 行的元组定义。）
|
||||
|
||||
`app/theme_store.py:14` 改为：
|
||||
|
||||
```python
|
||||
from .core import THEMES as BUILTIN
|
||||
```
|
||||
|
||||
- [ ] **Step 4:** `python -m pytest tests/test_theme_registry.py -q` → PASS；`python -m pytest -q` 全绿
|
||||
- [ ] **Step 5:** `git add -A && git commit -m "feat: single-source theme discovery replaces three hardcoded whitelists"`
|
||||
|
||||
### Task 3: theme_pro 每主题环境（宏覆盖机制，F4）
|
||||
|
||||
**Files:**
|
||||
- Modify: `app/theme_pro.py:18-20`（LOADER 旁新增 env_for）
|
||||
- Modify: `app/theme_pro.py:190`（render 用 env_for）
|
||||
- Test: `tests/test_theme_registry.py`（追加）
|
||||
|
||||
- [ ] **Step 1: 追加失败测试**
|
||||
|
||||
```python
|
||||
def test_env_for_theme_prefers_theme_dir_then_shared_root():
|
||||
from app import theme_pro
|
||||
env = theme_pro.env_for('industrial')
|
||||
paths = [str(p) for p in env.loader.searchpaths]
|
||||
assert paths[0].replace('\\', '/').endswith('themes/industrial')
|
||||
assert paths[1].replace('\\', '/').endswith('themes')
|
||||
# 共享宏库必须仍可解析（回落路径）
|
||||
assert env.get_template('_professional_components.html') is not None
|
||||
|
||||
def test_env_for_is_cached_per_theme():
|
||||
from app import theme_pro
|
||||
assert theme_pro.env_for('industrial') is theme_pro.env_for('industrial')
|
||||
```
|
||||
|
||||
- [ ] **Step 2:** 跑测试 → FAIL（env_for 不存在）
|
||||
- [ ] **Step 3: 实现**——`app/theme_pro.py` 在 LOADER 定义后追加：
|
||||
|
||||
```python
|
||||
_ENVS = {}
|
||||
|
||||
def env_for(theme):
|
||||
"""Per-theme Jinja env: theme dir first, shared themes/ root as fallback.
|
||||
|
||||
Lets a theme override shared macros (_professional_components.html) while
|
||||
inheriting everything else. Cached: one env per theme across 5000-page builds.
|
||||
"""
|
||||
env = _ENVS.get(theme)
|
||||
if env is None:
|
||||
theme_dir = ROOT / 'themes' / theme
|
||||
search = [str(theme_dir), str(ROOT / 'themes')] if theme_dir.is_dir() else [str(ROOT / 'themes')]
|
||||
env = Environment(loader=FileSystemLoader(search), autoescape=select_autoescape(['html', 'xml']))
|
||||
_ENVS[theme] = env
|
||||
return env
|
||||
```
|
||||
|
||||
`render()` 末行（:190）改为：
|
||||
|
||||
```python
|
||||
return env_for(theme).get_template('pro.html').render(**ctx)
|
||||
```
|
||||
|
||||
- [ ] **Step 4:** `python -m pytest -q` 全绿（现有 test_theme_pro_v3.py 即回归）
|
||||
- [ ] **Step 5:** commit `feat: per-theme Jinja env enables theme-level macro override`
|
||||
|
||||
### Task 4: builder 主题资产优先（F5）
|
||||
|
||||
**Files:**
|
||||
- Modify: `app/builder.py:191`
|
||||
- Test: `tests/test_theme_registry.py`（追加）
|
||||
|
||||
- [ ] **Step 1: 追加失败测试**
|
||||
|
||||
```python
|
||||
def test_theme_blocks_css_overrides_platform(tmp_path):
|
||||
from app import builder
|
||||
from pathlib import Path
|
||||
dist = tmp_path / 'assets'; dist.mkdir()
|
||||
theme_dir = tmp_path / 'theme'; theme_dir.mkdir()
|
||||
(theme_dir / 'blocks.css').write_text('/* theme version */', encoding='utf-8')
|
||||
builder.copy_blocks_css(theme_dir, dist)
|
||||
assert (dist / 'blocks.css').read_text(encoding='utf-8') == '/* theme version */'
|
||||
# 无主题版时回落平台版
|
||||
dist2 = tmp_path / 'assets2'; dist2.mkdir()
|
||||
builder.copy_blocks_css(tmp_path / 'nonexistent', dist2)
|
||||
assert (dist2 / 'blocks.css').is_file()
|
||||
```
|
||||
|
||||
- [ ] **Step 2:** 跑 → FAIL
|
||||
- [ ] **Step 3: 实现**——`app/builder.py:191` 的 `shutil.copy2(ROOT/'app'/'static'/'blocks.css',dist/'assets'/'blocks.css')` 替换为调用新函数，并在文件合适位置（output_path 附近）定义：
|
||||
|
||||
```python
|
||||
def copy_blocks_css(theme_dir, dist_assets):
|
||||
"""Theme-provided blocks.css wins; platform default is the fallback."""
|
||||
src = theme_dir / 'blocks.css' if (theme_dir / 'blocks.css').is_file() else ROOT / 'app' / 'static' / 'blocks.css'
|
||||
shutil.copy2(src, dist_assets / 'blocks.css')
|
||||
```
|
||||
|
||||
- [ ] **Step 4:** `python -m pytest -q` 全绿；commit `feat: theme-level blocks.css takes priority over platform asset`
|
||||
|
||||
### Task 5: trade-pro 骨架主题包（Phase 2 核心）
|
||||
|
||||
**Files:**
|
||||
- Create: `themes/trade-pro/manifest.json`、`site.html`、`pro.html`、`_professional_components.html`、`theme.css`、`blocks.css`、`pro.css`、`page-presets.json`、`pages/`（14 个 html）、`visual/.gitkeep`、`versions/.gitkeep`
|
||||
- Test: `tests/test_theme_registry.py`（追加）
|
||||
|
||||
- [ ] **Step 1: 追加失败测试**
|
||||
|
||||
```python
|
||||
def test_trade_pro_registered_and_compatible():
|
||||
assert 'trade-pro' in core.THEMES
|
||||
result = theme_store.compatibility('trade-pro')
|
||||
assert result['valid'], result['errors']
|
||||
assert not result['errors']
|
||||
|
||||
def test_trade_pro_builds_real_site():
|
||||
# 集成冒烟：真实构建函数对演示站点渲染 home 不抛异常（复用现有测试夹具方式，
|
||||
# 参考 tests/test_theme_pro_v3.py 中的最小站点夹具）
|
||||
...
|
||||
```
|
||||
|
||||
（第二个测试复用 test_theme_pro_v3.py 已有的最小站点构建夹具写法，theme 传 'trade-pro'。）
|
||||
|
||||
- [ ] **Step 2:** 跑 → FAIL
|
||||
- [ ] **Step 3: 创建文件**
|
||||
|
||||
`manifest.json`：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "trade-pro",
|
||||
"name": "Trade Pro — International B2B",
|
||||
"description": "English-first international B2B theme ported from the hesupipe Astro design: SVG icon set, responsive trade catalogue, product specs and inquiry CTA.",
|
||||
"version": "1.0.0",
|
||||
"style": "international-b2b",
|
||||
"entry": "pro.html",
|
||||
"styles": ["theme.css", "blocks.css"],
|
||||
"page_templates": ["home","about","contact","listing","product","article","case","standard","category"],
|
||||
"blocks": ["hero","richtext","features","stats","collection","image_text","gallery","faq","cta","attributes","spacer","layout","carousel","video","tabs","pricing","map","form_link"],
|
||||
"responsive": true,
|
||||
"auto_binding": true,
|
||||
"professional_layout": true,
|
||||
"commercial_ui": true,
|
||||
"accent": "#0b3d91"
|
||||
}
|
||||
```
|
||||
|
||||
`site.html`：以 `themes/industrial/site.html` 为底，改 `lang="zh-CN"` → `lang="en"`，其余变量占位不动（它只包 {{content}}）。
|
||||
|
||||
`_professional_components.html`：先做**透传骨架**（从共享库复制 card/cover 等宏，Task 10 起逐个换成 cms 设计 + SVG 图标）。
|
||||
|
||||
`pro.html`：以 industrial 的 pro.html 为底最小化：`lang="en"`；页眉/页脚消费 site_design chrome 但按 spec 4.2.5 值比对输出英文兜底（中文默认值视为未配置）；正文区渲染 page content 与 custom_blocks；按钮类名一律 `sf-tp-*`。
|
||||
|
||||
`theme.css`：先放 tokens 骨架（Task 9 全量移植）：
|
||||
|
||||
```css
|
||||
:root{--sf-tp-primary:#0b3d91;--sf-tp-accent:#f5a623;--sf-tp-bg:#ffffff;--sf-tp-text:#1a2332;--sf-tp-muted:#5a6a7e;--sf-tp-radius:8px;--sf-tp-font:'Inter',system-ui,-apple-system,sans-serif}
|
||||
```
|
||||
|
||||
`blocks.css`：空文件 + 注释 `/* trade-pro component styles: filled in Phase 3 */`。
|
||||
`pro.css`：空文件（兼容性硬性要求，spec F8）。
|
||||
`page-presets.json`：**复制 industrial 的同名文件原样**（Phase 4 精修；13 种 key 齐全即可）。
|
||||
`pages/`：`home.html` 写最小可用骨架（hero + showcase 列表 + cta 引用共享宏）；其余 13 个（about/contact/listing/product/brand/article/case/service/faq/category/search/standard/notfound）先各写薄变体（复用 home 的结构、引用同样宏），文件必须存在（spec F7 硬性）。
|
||||
|
||||
- [ ] **Step 4:** `python -m pytest -q` 全绿（含新测试）
|
||||
- [ ] **Step 5:** `docker compose up -d --build` 后：`curl -s http://127.0.0.1:8787/api/health` 版本不变、`curl -s "http://127.0.0.1:8787/api/factory/themes/trade-pro/compatibility"`（带登录 cookie）返回 valid=true
|
||||
- [ ] **Step 6:** commit `feat: trade-pro skeleton theme package (Phase 2)`
|
||||
|
||||
### Task 6: theme_color 映射 + 6 处前端入口（F3/F11）
|
||||
|
||||
**Files:**
|
||||
- Modify: `app/theme_pro.py`（theme_color 字典，make_context 内，约 :171）
|
||||
- Modify: `app/templates/admin.html:13`（siteTheme select）
|
||||
- Modify: `app/templates/workspace.html:41`（建站模态框 theme select）
|
||||
- Modify: `app/templates/theme-gallery.html:4`（theme select）
|
||||
- Modify: `app/static/workspace.js:5`（themeName）
|
||||
- Modify: `app/static/admin.js:5`（cfg）
|
||||
- Modify: `app/static/factory-v2.js:30`（schemes）
|
||||
- Test: `tests/test_theme_registry.py`（追加）
|
||||
|
||||
- [ ] **Step 1: 追加失败测试**
|
||||
|
||||
```python
|
||||
def test_frontend_entries_include_trade_pro():
|
||||
import pathlib
|
||||
base = pathlib.Path(__file__).resolve().parent.parent
|
||||
for rel, needle in [
|
||||
('app/templates/admin.html', 'value="trade-pro"'),
|
||||
('app/templates/workspace.html', 'value="trade-pro"'),
|
||||
('app/templates/theme-gallery.html', 'value="trade-pro"'),
|
||||
('app/static/workspace.js', "'trade-pro'"),
|
||||
('app/static/admin.js', "'trade-pro'"),
|
||||
('app/static/factory-v2.js', "'trade-pro'"),
|
||||
]:
|
||||
assert needle in (base / rel).read_text(encoding='utf-8'), rel
|
||||
|
||||
def test_theme_color_map_covers_trade_pro():
|
||||
# theme_pro.make_context 的 theme_color 字典含 trade-pro（渲染 smoke 断言 meta theme-color）
|
||||
...
|
||||
```
|
||||
|
||||
- [ ] **Step 2:** 跑 → FAIL
|
||||
- [ ] **Step 3: 实现**——逐处追加（保持原文风格）：
|
||||
- theme_color 字典追加 `'trade-pro':'#0b3d91'`
|
||||
- 三个 HTML select 各追加：`<option value="trade-pro">Trade Pro · 外贸 B2B（英文）</option>`（theme-gallery 用 `Trade Pro · International B2B`）
|
||||
- `workspace.js` themeName 追加 `'trade-pro':'Trade Pro'`
|
||||
- `admin.js` cfg 追加 `trade-pro:{label:'Trade Pro',desc:'英文外贸 · B2B 目录与询盘',prev:'corp',title:'Go global.'}`
|
||||
- `factory-v2.js` schemes 追加 `'trade-pro':['#0b3d91','#e8f1fb','GO GLOBAL']`
|
||||
- [ ] **Step 4:** `python -m pytest -q` 全绿 + `for f in app/static/*.js; do node --check "$f"; done` 通过
|
||||
- [ ] **Step 5:** commit `feat: register trade-pro in theme color map and all six frontend entry points`
|
||||
|
||||
### Task 7: E2E 验收——真实站点切主题构建（Phase 2 门槛）
|
||||
|
||||
**Files:** 无代码（验证 + 记录）
|
||||
|
||||
- [ ] **Step 1:** 登录拿 cookie/CSRF（参照已验证流程：POST /api/auth/login → GET /api/auth/me）
|
||||
- [ ] **Step 2:** `PUT /api/factory/sites/483295c29ea0/theme` body `{"theme":"trade-pro"}`（确认返回成功）
|
||||
- [ ] **Step 3:** `POST /api/sites/483295c29ea0/builds`（Idempotency-Key + CSRF）→ 轮询 job 至 done
|
||||
- [ ] **Step 4:** 断言：pages ≥203、errors 空；预览首页 HTTP 200、含 `lang="en"`、不含"首页/联系我们"（平台中文默认，spec F9 验收）；`/products/`、`/product/alloy-resin-system-window/` 200
|
||||
- [ ] **Step 5:** 断言 6 入口：新工作台/`/classic` 建站表单、theme-gallery、factory-studio 主题卡里均出现 trade-pro（浏览器人工点验，截图存 `docs/superpowers/` 或记录于验收文件）
|
||||
- [ ] **Step 6:** 把结果写入 `docs/superpowers/specs/2026-10-22-trade-pro-theme-design.md` 附录"Phase 2 验收记录"；commit
|
||||
|
||||
---
|
||||
|
||||
## Phase 3：完整视觉移植（Task 8-12）
|
||||
|
||||
> 以下任务的代码无法在计划里全文预写（从 cms 源逐段移植），但每步给出**精确源文件、提取规则与验收断言**。共用纪律：每完成一个 Task 跑全量 pytest + commit。
|
||||
|
||||
### Task 8: 设计令牌与基础样式全量移植
|
||||
|
||||
- 源：`D:/project/cms/runtimes/astro-site-runtime/src/styles/tokens.css`（250 行）+ `base.css`（445 行）
|
||||
- [ ] 变量重命名加 `--sf-tp-` 前缀（spec 4.2.6）；按钮/交互元素全部 `sf-tp-` 类名（避开平台 `.btn/.primary/.request/.button/.nav-btn`）
|
||||
- [ ] 验收断言：`themes/trade-pro/theme.css` 覆盖 tokens 全集（颜色/字体/圆角/间距）；构建产物 `assets/theme.css` 含 `--sf-tp-` 变量；平台 custom.css 的 `.btn{...}` 与主题按钮类无交集（grep 断言）
|
||||
- [ ] pytest（现有快照不受影响）+ commit
|
||||
|
||||
### Task 9: 图标宏库（替代箭头）
|
||||
|
||||
- 源：cms 组件与 dist HTML 中的内联 SVG（`grep -o '<svg[^>]*>' dist/hesupipe/en/index.html` 起逐个提取；参考 `src/components/*.astro` 里的图标用法）
|
||||
- [ ] `themes/trade-pro/_professional_components.html` 定义 `icon(name)` 宏：内联 SVG 集合（≥8 个：arrow-right/check/phone/mail/location/whatsapp/download/quote 等，从 cms 实际用到的集合提取）
|
||||
- [ ] 验收：home/product 页渲染输出含 `<svg` 且无裸文本箭头 `→` 作为唯一图标（对照 dist）
|
||||
- [ ] commit
|
||||
|
||||
### Task 10: 九种独立布局逐个移植（每布局一个 commit）
|
||||
|
||||
顺序与源对照（cms `src/pages/[locale]/` ↔ dist `en/` ↔ trade-pro `pages/`）：
|
||||
|
||||
1. `home`：index.astro ↔ dist 首页（Hero/FeatureGrid/CardGrid/CTA 结构）
|
||||
2. `product`：products/[slug].astro ↔ dist/products/alloy-resin-system-window/（参数表 specs、多图 gallery、询盘 CTA）
|
||||
3. `listing`：news/[...page].astro + products 列表 ↔ 按 kind 分支（Phase 0 已确认模板可拿到 page/kind 上下文；若不可分支由 category 承担产品列表，spec §7 兜底）
|
||||
4. `category`：product-category ↔ 分类页
|
||||
5. `article`：news/[slug] ↔ 文章详情
|
||||
6. `about` / 7. `contact`（LeadForm 样式 + form_endpoint）/ 8. `case`（projects）/ 9. `standard`（applications、support）
|
||||
|
||||
每个布局的统一验收：构建对应真实页面 200；关键结构选择器与 dist 对照（header/hero/卡片/参数表/页脚）；英文文案断言（无中文默认）；手机宽度可读（人工抽查一次，全量视觉验收在 Task 12）。
|
||||
|
||||
### Task 11: 五个变体布局 + search
|
||||
|
||||
- brand/service/faq/notfound/search 以 standard/listing 变体补齐为"结构合理"版本（后续迭代精修，spec 4.3）
|
||||
|
||||
### Task 12: 预设、编辑器与全量验收（Phase 4）
|
||||
|
||||
- [ ] `page-presets.json` 13 种按 cms 首页/产品页实际区块结构重写（编辑器初始布局与真实设计一致）
|
||||
- [ ] 编辑器验证：hero/cta/features/collection/attributes 在 trade-pro 下可编辑、预览、保存草稿、发布（spec §6）
|
||||
- [ ] 全站设计草稿验证：页眉/页脚/导航配置生效（显式值渲染、中文默认被值比对替换为英文兜底）
|
||||
- [ ] 全量回归：`python -m pytest -q`（≥210+新增全绿）、`node --check` 全部 JS
|
||||
- [ ] 实战验收：站点 483295c29ea0 最终构建 ≥203 页零错误；视觉对照两层标准（spec §6）逐页记录
|
||||
- [ ] 更新 spec 附录验收记录；commit
|
||||
|
||||
## 风险与回退
|
||||
|
||||
- 每个 Task 独立 commit，出问题 `git revert` 单点回退
|
||||
- 平台适配层（Task 2-4）有 4 主题回归保护：任何现有测试变红立即停止
|
||||
- trade-pro 目录独立，删目录 + revert 白名单改动即完全移除
|
||||
@@ -0,0 +1,128 @@
|
||||
# trade-pro 第 5 主题移植设计（V8_10 主线）— 修订版 R3
|
||||
|
||||
日期：2026-10-22 ｜ 状态：评审通过（R2 复审后小幅修订）｜ 目标版本：SiteForge Enterprise V8.10.0-dev.1
|
||||
修订记录：R1 评审"需修订后通过"（13 项发现已吸收）→ R2 复审"小幅修订后通过"（补第 6 处前端入口、行号 187、显式/默认值判定机制）→ R3 为终版。
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
把 cms 项目（D:\project\cms）Astro 主题的视觉设计移植为 SiteForge 第 5 套内置主题 `trade-pro`，首要服务 hesupipe.com 重建（英文外贸 B2B），长期服务后续外贸类客户站。附带解决：默认语言英文（现四套主题模板硬编码 `lang="zh-CN"` + 中文文案）、图标体系（现主题大量箭头符号，cms 主题有内联 SVG 图标集）。
|
||||
|
||||
### 范围外
|
||||
|
||||
平台多语言切换（P6）、其他三套旧主题的改造、cms 主题 en/es 双语路由、主题市场上架流程、Figma 级自由编辑、前端主题入口全面 API 驱动化（本轮逐处追加，API 化列后续迭代）。
|
||||
|
||||
## 2. 已验证的平台事实（设计依据，R2 修正）
|
||||
|
||||
| # | 事实 | 证据 | 对设计的影响 |
|
||||
|---|---|---|---|
|
||||
| F1 | **主题白名单共三处硬编码** | `app/theme_pro.py:18` THEMES；`app/core.py:12` THEMES（`builder.py:18,224` 与 `main.py:19,267 /api/themes` 使用）；`app/theme_store.py:14` BUILTIN（`resolve()` 59-60 对非 BUILTIN 无 theme_versions 记录抛 ThemeError，`builder.py:189` 构建即调） | 平台适配必须三处同步，且统一为单一发现源 |
|
||||
| F2 | **主题 ZIP 安装通道不可用于 trade-pro** | `theme_store.py:106-117,143-146`：安装包仅声明式文件，pro/site.html 只能从 4 个 BUILTIN layout_family 拷贝 | trade-pro 必须以内置目录形式随代码交付，不走 install() |
|
||||
| F3 | **前端 6 处主题选择入口硬编码** | `app/templates/admin.html:13` 建站 select；**`app/templates/workspace.html:41` 工作台建站模态框下拉**（V8.10 主 UI）；`app/static/workspace.js:5,63` themeName 映射；`app/static/admin.js:5` cfg；`app/static/factory-v2.js:30` schemes；`app/templates/theme-gallery.html:4` 下拉 | 后端动态化不会自动传导，前端必须逐处追加 trade-pro |
|
||||
| F4 | 组件宏库全主题共享 | `themes/_professional_components.html`（根目录）；由各主题 `pro.html:2` `{% from ... import card,cover ... with context %` 引用，经 `theme_pro.LOADER`/`builder.ENV`（均为 themes/ 根单目录单例）解析 | 需"每主题优先、回落共享"的宏覆盖机制（见 4.2.4）；部分调用点已是双目录（builder.py:291/376/393、main.py:517、factory_api.py:313），做法可对齐 |
|
||||
| F5 | **主题包 blocks.css 无生效路径** | `builder.py:191` 恒定复制 `app/static/blocks.css` 到 dist | 平台适配需增加"主题目录优先"复制逻辑（见 4.2.3） |
|
||||
| F6 | 页眉/页脚/导航由平台生成 | `site_design_v87.py:69 _nav()`；`builder.py:219` 注入 custom.css | 新主题适配平台 DOM；全站设计草稿功能须在新主题生效 |
|
||||
| F7 | 兼容性检查：**13 种预设（缺失仅 warning）+ 14 个布局文件（缺失 valid=False，含 search.html）** | `blueprints.py:49-63` PAGE_TEMPLATES 13 种（无 search）；`theme_store.py:90-96` | 交付 14 个 pages/*.html（硬性）+ 13 种预设（尽力全） |
|
||||
| F8 | 主题目录五文件硬性要求 | `theme_store.py:82`：manifest.json/theme.css/page-presets.json/pro.html/**pro.css** | 结构含 pro.css（承接组件样式） |
|
||||
| F9 | **平台中文默认值与英文目标冲突** | `theme_pro.py:151-155` 默认导航全中文、`:22` TITLES、`:182` pretty_type 兜底'内容'；`site_design_v87.py:20` DEFAULTS `cta_text:'联系我们'` | 模板侧规避：主题内置英文 chrome 兜底，不消费平台中文默认（见 4.5） |
|
||||
| F10 | **平台 custom.css 无条件覆盖按钮样式** | `builder.py:213-218` 生成 `.btn,.primary,.request,.button,.nav-btn{...}` 写入最后加载的 custom.css | 主题按钮用自有类名前缀 `sf-tp-`，避开平台选择器（见 4.5） |
|
||||
| F11 | theme_color 映射仅 4 主题 | `theme_pro.py:170`，缺省回落 '#ffffff' | 映射表补 trade-pro（或从 manifest accent 读） |
|
||||
| F12 | 设计素材源 | cms `src/styles/{tokens.css 250行, base.css 445行}` + 组件 scoped CSS + `dist/hesupipe` 成品像素基准 | 手工移植素材基础 |
|
||||
| F13 | hesupipe 数据已在本机 V8_10 实例内 | 站点 `483295c29ea0`（193 条：16 page/129 post/48 product），经 `/staging/wxr` 导入清洗版 WXR（剔除 930 非内容条目、修复 19 个 `?p=` 链接），构建版本 `5552c7a9a9c1` | Phase 2/4 验收直接切该站主题；导入通道与清洗脚本已验证可复现 |
|
||||
|
||||
## 3. 方案选择
|
||||
|
||||
**A. 手工移植（选定）**：以 `dist/hesupipe` 成品为像素基准、`src/` 源码为素材，手写 Jinja 模板。9 种真实模板量可控，质量最高。
|
||||
否决 B（脚本转换 dist 产物：哈希类名无法映射回内容变量）与 C（只换 CSS：结构受限，达不到设计还原）。
|
||||
|
||||
## 4. 架构设计
|
||||
|
||||
### 4.1 主题包结构（R2：补 pro.css，blocks.css 依赖 F5 适配）
|
||||
|
||||
```
|
||||
themes/trade-pro/
|
||||
├── manifest.json # id: trade-pro, version 1.0.0, style: international-b2b, 英文元数据, accent/theme_color
|
||||
├── site.html / pro.html # lang="en"，全英文 UI 文案
|
||||
├── _professional_components.html # 每主题覆盖宏库（4.2.4）
|
||||
├── theme.css # base.css + tokens.css 移植，CSS 变量桥接设计令牌
|
||||
├── blocks.css # 组件样式（依赖 4.2.3 平台适配后方可生效）
|
||||
├── pro.css # 专业页组件样式（F8 硬性要求，可为承接层）
|
||||
├── pages/*.html # 14 个布局文件（F7 硬性，含 search.html；9 独立 + 5 变体，见 4.3）
|
||||
├── page-presets.json # 13 种模板预设（F7；warning 级但全部提供）
|
||||
├── visual/ # 中性演示素材预览图（禁止 hesupipe 真实素材）
|
||||
└── versions/ # 版本快照
|
||||
```
|
||||
|
||||
### 4.2 平台适配层（R2：按 F1-F5、F9-F11 扩充为 7 项）
|
||||
|
||||
1. **主题发现统一（F1/F2）**：在 theme_store 新增单一发现函数（扫描 `themes/*/manifest.json` 得到 id+元数据）；`core.THEMES`、`theme_pro.THEMES`、`theme_store.BUILTIN` 三处改为引用该函数结果（保留原名称导出以兼容既有 import：builder.py:18/224、main.py:19/267、theme_pro.py:187、theme_store.py:59-60）。现有 4 主题目录不动，行为等价。
|
||||
2. **前端入口逐处追加（F3，共 6 处）**：admin.html:13 select、workspace.html:41 建站模态框下拉、theme-gallery.html:4 下拉、workspace.js:5 themeName、admin.js:5 cfg、factory-v2.js:30 schemes 各追加 trade-pro 条目（英文名 + accent + 预览图引用）；`/api/themes`（main.py:267）确认返回发现函数结果。API 驱动化重构列后续迭代。
|
||||
3. **主题资产复制（F5）**：builder.py:191 改为"主题目录存在 blocks.css 则复制主题版，否则复制平台版"（向后兼容）。
|
||||
4. **宏覆盖机制（F4，R2 具体化）**：`theme_pro.py:20 LOADER` 与 `builder.py:22 ENV` 由单目录改为按主题构造 `ChoiceLoader([theme_dir, themes_root])`（与 builder.py:291 等现有双目录做法对齐）；列出全部构造点与使用点（theme_pro.py:190 render 等）逐一核对；Jinja 缓存按 env 实例管理，per-theme env 复用避免 5000 页级构建的重复编译开销；pro.html 顶部 `{% from '_professional_components.html' import ... %}` 即先命中主题目录版本。现有 4 主题目录无同名文件，回落共享库，行为不变（回归测试覆盖）。
|
||||
5. **英文 chrome 兜底（F9）**：trade-pro 模板不消费平台中文默认——nav 未配置时模板内置 Home/Products/News/About/Contact 英文导航；不使用 TITLES/pretty_type 中文标签，模板自带英文 kind 标签；site_design 的 `cta_text` 仅在用户显式配置（非平台默认值）时渲染。**显式/默认值判定机制**：`ctx['nav']` 恒非空（theme_pro.py:151-155 已填中文默认）、`cta_text` 经 `site_design_v87.py:91` 与 DEFAULTS 合并后无法从源头区分，因此采用**值比对**——模板侧将"等于中文默认值（首页/联系我们等）"视为未配置并输出英文兜底（英文站场景下用户显式配置不会恰好等于中文默认值，判定可靠）。
|
||||
6. **样式优先级（F10）**：主题按钮/交互元素全部使用 `sf-tp-` 前缀类名，避开平台 custom.css 的 `.btn/.primary/.request/.button/.nav-btn` 选择器；tokens.css 变量以 `--sf-tp-*` 命名并提供默认值，平台 accent 注入仅在站点显式设置时通过桥接变量生效。
|
||||
7. **theme_color（F11）**：`theme_pro.py:170` 映射表补 trade-pro（取 manifest accent）。
|
||||
|
||||
所有平台改动配回归测试：现有 4 主题渲染关键断言不变。
|
||||
|
||||
### 4.3 页面模板映射（14 个布局文件）
|
||||
|
||||
| cms 页面 | SiteForge 模板 | 实现 |
|
||||
|---|---|---|
|
||||
| index | home | 独立（Hero+FeatureGrid+CardGrid+CTA） |
|
||||
| about | about | 独立 |
|
||||
| news/products 列表 | listing | 独立，按内容类型分支（Phase 0 确认可行性） |
|
||||
| news 详情 | article | 独立 |
|
||||
| product-category | category | 独立 |
|
||||
| product 详情 | product | 独立（参数表/多图） |
|
||||
| projects | case | 独立 |
|
||||
| applications/support | standard | 独立 |
|
||||
| contact | contact | 独立（LeadForm 样式） |
|
||||
| 搜索 | search | 复用 listing 变体 |
|
||||
| — | brand/service/faq/notfound | 复用 listing/standard 变体（后续精修） |
|
||||
|
||||
### 4.4 区块契约
|
||||
|
||||
沿用现有 block id 与属性 Schema（blueprints.BLOCKS：hero/richtext/features/stats/collection/image_text/gallery/faq/cta/attributes/**layout**/spacer + carousel/video/tabs/pricing/map/form_link 六组件），只重写渲染与样式 → 编辑器/预设/自动装配/整站模板开箱即用。映射：PageHero→hero、FeatureGrid→features、CardGrid→collection、CTA→cta、产品参数表→attributes。cms 组件属性超出契约时模板内智能适配，不扩平台契约。
|
||||
|
||||
### 4.5 语言、令牌、图标、素材
|
||||
|
||||
- `lang="en"`，主题内全部 UI 文案/面包屑/分页/日期英文；英文 chrome 兜底见 4.2.5
|
||||
- tokens.css 变量 `--sf-tp-*` 桥接 SiteForge 设计令牌（V8.7 全站设计草稿可调），优先级规则见 4.2.6
|
||||
- 图标：cms 内联 SVG 集合进主题宏库（替代箭头）
|
||||
- 素材规范：主题包仅含中性演示素材；hesupipe 真实图片留在站点数据侧
|
||||
|
||||
### 4.6 数据映射与导入通道
|
||||
|
||||
产品 specs/gallery → entry meta.fields（与现有 product 模板同构）；正文直接渲染；图片 URL 保持原站引用（镜像后续统一处理）。**导入通道（F13）**：本机 V8_10 实例站点 `483295c29ea0` 已含 hesupipe 全量 193 条（清洗版 WXR 经 `/api/factory/sites/{id}/staging/wxr` 暂存导入，清洗规则：仅保留 post/page/product、删除 19 个 `?p=` 形式 link）；Phase 2/4 直接切换该站主题验收，另以脚本化步骤记录保证可复现。
|
||||
|
||||
## 5. 实施阶段（R2：Phase 1 扩充，Phase 2 落到已有站点）
|
||||
|
||||
- **Phase 0 契约研究**：通读 industrial 主题全部文件 + theme_pro/builder/theme_store 渲染分工，产出契约清单；确认 listing 按内容类型分支的可行方案；给主线目录建 Git 仓库并提交基线（补丁管理，含 v8_workflows.py:67 修复）
|
||||
- **Phase 1 平台适配**：4.2 全部 7 项 + 现有 4 主题回归测试（含双目录加载、资产复制、/api/themes）
|
||||
- **Phase 2 骨架跑通**：trade-pro 空壳（manifest/site.html/pro.html/theme.css/pro.css 骨架 + home 布局）注册成功；**站点 483295c29ea0 切主题构建出首页**；前端 6 入口可见可选
|
||||
- **Phase 3 完整模板**：其余 8 种独立布局 + 5 种变体（含 search）+ blocks.css 全量样式 + 图标宏库
|
||||
- **Phase 4 预设与验收**：13 种 page-presets、编辑器区块验证、theme-gallery 预览、全量测试、实战与视觉验收
|
||||
|
||||
## 6. 测试与验收
|
||||
|
||||
- pytest：主题发现（三处白名单一致）、兼容性检查 valid=True（14 布局 + 13 预设）、9 种独立布局渲染快照、英文文案与 `lang="en"` 断言（含未配置 nav 时英文兜底）、4 主题回归（双目录回落、资产复制、按钮类名不冲突）
|
||||
- 实战：站点 483295c29ea0 切 trade-pro 构建 ≥203 页零错误；**6 个前端入口均可见可选 trade-pro**；编辑器 hero/cta/features 可编辑可预览；全站设计草稿页眉/页脚配置生效（显式配置值渲染、平台中文默认不出现）
|
||||
- 视觉验收两层：**必须一致**（设计令牌/字体/配色/组件视觉骨架/英文文案/图标体系）；**允许差异**（内容排列顺序、分页器样式细节）
|
||||
|
||||
## 7. 风险与缓解（R2 更新）
|
||||
|
||||
| 风险 | 缓解 |
|
||||
|---|---|
|
||||
| listing 模板无法按内容类型分支 | Phase 0 契约研究确认；兜底：kind 变量分支或 category 模板承担产品列表 |
|
||||
| 宏覆盖机制的 per-theme env 影响构建性能 | env 按 themes 缓存复用；5000 页级构建跑性能回归（V8.9 有基线） |
|
||||
| 平台生成页眉 DOM 与 cms 设计差异大 | 本轮样式层适配平台 DOM，结构模板化列后续迭代 |
|
||||
| 前端逐处追加遗漏入口 | Phase 2 验收清单含 6 入口逐项检查；全仓 grep `automotive`（templates 命中 admin.html/theme-gallery.html/workspace.html 三文件 + static 下 workspace.js/admin.js/factory-v2.js）确认无第 7 处 |
|
||||
| cms scoped CSS 分散难提取 | dist 编译 CSS 反查 + src 源码双重对照 |
|
||||
|
||||
## 8. 交付物
|
||||
|
||||
themes/trade-pro/ 完整主题包（14 布局 + 13 预设 + 五文件硬性项）、平台适配 diff（4.2 全部 7 项，含测试）、本文档、站点 483295c29ea0 切主题验收记录、Git 仓库与补丁清单。
|
||||
|
||||
## 9. 已知关联补丁（升级版本时需重放）
|
||||
|
||||
`app/v8_workflows.py:67` 类型列修复（`类型`/`分类` 兼容读取）——已在 V8_7、V8_10 各打一次。
|
||||
Reference in New Issue
Block a user