docs(docs): 新增 0020 Portal Shell 架构文档(C4+4+1+ADR) + 设计 spec v2.1 + 更新 0010/004 指向新架构

docs/architecture/0010_architecture.md

@@ -63,6 +63,7 @@ graph TB
     Kafka -- "消费事件" --> ServiceLayer
     Kafka -- "同步读视图" --> ClickHouse
     Kafka -- "索引同步" --> ES
+
 二、 彻底解耦的四大核心设计模式
 在最优架构中，系统通过以下企业级模式解决耦合问题：
 
@@ -104,6 +105,24 @@ Query (读) 链路：系统背后通过 CDC（如 Debezium）监听 MySQL 的 bi
 
 收益：“排课组”的前端和后端可以独立发版，“题库组”的前端和后端可以独立发版。页面的组装在运行时由宿主框架完成。
 
+> **⚠️ 架构演进说明（2026-07-14）**
+>
+> 本节描述的 MF 微前端方案已在实施评估中被**取代**。经过对 Module Federation + 独立 widget 容器方案的深入分析，发现存在部署运维复杂（8+ 容器）、与 Next.js SSR 兼容性差、首屏瀑布流等问题。
+>
+> **新方案**：采用 **Modular Monolith + Micro-kernel** 架构（单 Next.js + dynamic import + 配置驱动），在保留"前端解耦 + 独立发版"核心目标的同时，大幅降低部署复杂度（1 容器）并提升首屏性能（RSC 服务端预取）。
+>
+> 详见：[0020 Portal Shell 架构文档](./0020_portal_shell_architecture.md)
+>
+> **演进对比**：
+>
+> | 维度       | 本节（MF 微前端）    | 新方案（Modular Monolith） |
+> | ---------- | -------------------- | -------------------------- |
+> | 部署       | 8+ 独立容器          | 1 容器                     |
+> | 首屏       | MF 远程加载慢        | RSC 服务端预取秒开         |
+> | 跨前端通信 | EventBus（状态黑盒） | URL + Zustand（可追踪）    |
+> | 独立发版   | widget 可独立发版    | 插件随 Shell 发版          |
+> | 第三方扩展 | 天然支持             | 二期 iframe 沙箱           |
+
 三、 基础设施与扩展性设计
 统一 API 网关 (API Gateway)
 
@@ -133,8 +152,8 @@ SSE 或 WebSocket 不再由业务容器承载。设立专门的 Push Gateway 服
 
 业务模块不再需要操心“谁要我的数据”、“如何拼装别人的数据”、“事务失败怎么回滚”。它们只做一件事：接收指令 -> 改变自身领域模型 -> 将改变广播给全宇宙（Event Bus）.
 
-
 蓝图设计的合理性（几乎全对，但有几个地方需要微调）
+
 1. 各层选型精准，但有一处“过度理想”
    API Gateway + BFF + GraphQL：
    Gateway 做统一鉴权限流，BFF 做面向前端的聚合，GraphQL 允许不同端按需取数——这在多端下非常正确。