Sync: add project management and xr notes

2026-04-25 06:25:02 +08:00
parent a26d62bb6d
commit 20f686ea5f
52 changed files with 3251 additions and 9 deletions
--- a/wiki/concepts/Atomic-Commit.md
+++ b/wiki/concepts/Atomic-Commit.md
@@ -0,0 +1,35 @@
+---
+title: "Atomic Commit"
+type: concept
+tags: ["git", "code-quality", "delivery-traceability"]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Atomic Commit（原子提交）是一种 Git 提交粒度原则——每次提交仅包含一个逻辑变更单元（一个清晰的改动），易于审查、回滚和溯源，不捆绑多个不相关的变更。
+
+## Characteristics
+
+- **单一职责**：一个 commit = 一个清晰的改动
+- **可独立回滚**：回滚一个 commit 不会影响其他功能的正常运行
+- **可独立审查**：reviewer 能在短时间内理解单个 commit 的意图
+- **易于溯源**：通过 commit message 快速定位引入特定行为的 ticket
+
+## Anti-patterns
+
+| 反模式 | 描述 | 风险 |
+|--------|------|------|
+| Mega commit | 一次性提交大量不相关变更 | review 成本高；回滚连带损伤 |
+| WIP commit | 包含 work-in-progress 代码的提交 | 污染历史，难以理解 |
+| Fixup commit | 在 review 过程中不断追加修改 | 历史难以重建 |
+| Bundled commit | 将多个功能捆在一个 commit 里 | 拆分困难，回滚粒度过粗 |
+
+## Relationship to Branch Strategy
+
+Atomic Commit 与 [[Branch-Strategy]] 共同构成 [[Jira-Git-Traceability]] 的基础：
+- Branch 隔离不同任务的工作
+- 每个 branch 内的 commit 进一步原子化
+
+## Sources
+- [[project-management-jira-workflow-steward]]
--- a/wiki/concepts/Branch-Strategy.md
+++ b/wiki/concepts/Branch-Strategy.md
@@ -0,0 +1,39 @@
+---
+title: "Branch Strategy"
+type: concept
+tags: ["git", "workflow", "delivery-traceability"]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Branch Strategy（分支策略）是一套基于变更类型的分支分层管理模型，通过规范化分支命名和来源规则，确保各类型的代码变更在正确的上下文中开发、审查和合并。
+
+## Branch Types
+
+| 类型 | 模式 | 来源分支 | 目标分支 | 典型场景 |
+|------|------|----------|----------|----------|
+| Feature | `feature/JIRA-ID-description` | develop | develop | 新产品或平台功能 |
+| Bugfix | `bugfix/JIRA-ID-description` | develop | develop | 非关键缺陷修复 |
+| Hotfix | `hotfix/JIRA-ID-description` | main | main | 关键生产环境修复 |
+| Refactor | `feature/JIRA-ID-description` | develop | develop | 结构清理（需关联 Jira 任务） |
+| Docs | `feature/JIRA-ID-description` | develop | develop | 文档更新（需关联 Jira 任务） |
+| Tests | `bugfix/JIRA-ID-description` | develop | develop | 回归测试（需关联 Jira 任务） |
+| Config | `feature/JIRA-ID-description` | develop | develop | 配置或工作流策略变更 |
+| Dependencies | `bugfix/JIRA-ID-description` | develop | develop | 依赖或平台升级 |
+| Release | `release/version` | develop | main | 发布准备 |
+
+## Protected Branches
+
+- `main`：始终生产就绪；所有合并必须经过 PR review
+- `develop`：持续集成的集成分支；feature/bugfix 从其拉取
+- `release/*`：发布准备分支；仍需关联 release ticket 或变更控制项
+
+## Relationship to Other Concepts
+
+- [[Atomic-Commit]]：在 branch 内部进一步原子化 commit
+- [[Jira-Git-Traceability]]：每个 branch 必须包含 Jira ID 作为唯一标识
+- [[Jira-Gate]]：branch 创建前必须验证 Jira Task 存在
+
+## Sources
+- [[project-management-jira-workflow-steward]]
--- a/wiki/concepts/ChinaLaborLawCompliance.md
+++ b/wiki/concepts/ChinaLaborLawCompliance.md
@@ -0,0 +1,50 @@
+---
+title: "China Labor Law Compliance（中国劳动法合规）"
+type: concept
+tags: [compliance, labor-law, hr, china]
+sources: [recruitment-specialist]
+last_updated: 2026-04-25
+---
+
+## 定义
+中国劳动法合规是指在招聘、入职、管理、离职全流程中，遵守《中华人民共和国劳动合同法》、《就业促进法》、《个人信息保护法》（PIPL）等法律法规的一系列要求。
+
+## 在 [[Recruitment Specialist Agent]] 中的核心模块
+
+### 劳动合同法要点
+- **合同签订**：入职30天内必须签订书面劳动合同，违者需支付双倍工资
+- **合同类型**：固定期限、无固定期限、项目型
+- **连续两次固定期限合同后**：员工有权要求签订无固定期限合同
+
+### 试用期规定
+- 合同期3个月~1年：试用期 ≤ 1个月
+- 合同期1年~3年：试用期 ≤ 2个月
+- 合同期3年及以上：试用期 ≤ 6个月
+- 试用期工资 ≥ 约定工资的80% 且 ≥ 当地最低工资
+- 同一员工只能设定一次试用期
+
+### 五险一金
+- **五险**：养老保险、医疗保险、失业保险、工伤保险、生育保险
+- **一金**：住房公积金
+- 入职30天内必须完成社保登记和缴纳
+
+### 竞业限制
+- 期限 ≤ 2年
+- 补偿金通常 ≥ 离职前12个月平均月薪的30%
+- 拖欠超过3个月，员工有权解除竞业义务
+
+### 经济补偿（N+1）
+- **N**：每满一年支付一个月工资
+- **N+1**：未提前30天通知，额外支付一个月工资
+- **违法解除**：2N 赔偿
+- 月工资上限：当地社会平均工资的3倍，最长计算12年
+
+## 合规红线
+- 禁止就业歧视（性别、年龄、婚姻状况、民族、宗教）
+- 背景调查需候选人书面授权
+- 候选人个人信息收集须符合 PIPL
+- 提前排查竞业限制，避免招用有竞业义务的人员
+
+## 连接
+- [[Recruitment Specialist Agent]] — 内置劳动法合规知识库
+- [[Recruitment Specialist Agent]] — 入职 SOP 中的合同签署和社保登记流程
--- a/wiki/concepts/Delivery-Traceability.md
+++ b/wiki/concepts/Delivery-Traceability.md
@@ -0,0 +1,47 @@
+---
+title: "Delivery Traceability"
+type: concept
+tags: ["delivery", "traceability", "project-management", "audit"]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Delivery Traceability（交付可追溯性）是指从业务需求到代码发布全链路的可重建、可审计交付记录体系，使团队能在几分钟内重建"从需求到已发布代码"的完整路径，而非花费数小时。
+
+## The Five Links
+
+| 环节 | 关键问题 | 可追溯性价值 |
+|------|----------|------------|
+| **Jira Task** | 这个需求从哪里来？ | 需求来源记录 |
+| **Branch** | 这段代码在哪个隔离环境开发？ | 隔离性保证 |
+| **Commit** | 这个改动具体做了什么？ | 原子粒度的变更记录 |
+| **Pull Request** | 谁审查了这次变更？ | Review 责任链 |
+| **Release** | 这个功能何时上线？ | 发布时间线记录 |
+
+## Two Modes of Traceability
+
+### Prospective Traceability（前向追溯）
+从 Jira 任务 → 代码 → 发布，确保需求被完整实现。用于：进度跟踪、变更影响分析。
+
+### Retrospective Traceability（回溯追溯）
+从已发布代码 → Jira 任务 → 需求来源，用于：事故溯源、审计合规、回滚决策。
+
+## Traceability vs. Bureaucracy
+
+[[Jira Workflow Steward]] 的核心观点：**Jira-linked commits 是质量工具，而非合规打勾**。
+
+当开发者理解可追溯性的实际价值（review 加速、发布说明自动生成、事故 10 分钟内定位）时，遵循规范的阻力会显著降低。
+
+## Success Metrics
+
+- 从 Jira + Git 历史重建发布说明：< 10 分钟
+- 定位引入特定行为的 ticket 和 commit：< 5 分钟
+- 回滚操作：原子 commit 使回滚低风险
+
+## Relationship to GitOps
+
+Delivery Traceability 关注业务需求到代码交付的全链路，[[GitOps]] 关注基础设施声明到部署的自动化调和。两者共同构成完整的软件交付可追溯性体系。
+
+## Sources
+- [[project-management-jira-workflow-steward]]
--- a/wiki/concepts/Gitmoji-Commit.md
+++ b/wiki/concepts/Gitmoji-Commit.md
@@ -0,0 +1,65 @@
+---
+title: "Gitmoji Commit"
+type: concept
+tags: ["git", "gitmoji", "code-quality"]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Gitmoji Commit 是一种提交规范，使用标准化 Emoji（Gitmoji）作为提交类型的视觉前缀，使开发者能在 git log 中通过 Emoji 快速识别变更意图。
+
+## Format
+
+```
+<Gitmoji> JIRA-ID: short description
+```
+
+示例：
+- `✨ JIRA-214: add SSO login flow`
+- `🐛 JIRA-315: fix token refresh race`
+- `♻️ JIRA-522: refactor audit service boundaries`
+- `📚 JIRA-623: document API error catalog`
+- `🧪 JIRA-724: add session timeout regression tests`
+- `🔧 JIRA-811: add branch policy validation`
+- `📦 JIRA-902: upgrade GitHub Actions versions`
+
+## Official Gitmoji Catalog
+
+| Emoji | 含义 | 使用场景 |
+|-------|------|----------|
+| ✨ | 新功能 | 新增 agent、catalog 功能 |
+| 🐛 | 缺陷修复 | bug fix |
+| ♻️ | 重构 | 代码结构优化 |
+| 📚 | 文档 | 仅限现有功能/贡献指南的文档更新 |
+| 🧪 | 测试 | 测试编写或更新 |
+| 💄 | 样式 | UI/样式调整（不改变行为） |
+| 🔧 | 配置 | 工作流、CI/CD、配置变更 |
+| 📦 | 依赖 | 依赖或平台升级 |
+| 🚀 | 部署 | 部署相关变更 |
+
+## Gitmoji Selection Principle
+
+> 优先选择反映**实际变更类型**的 Gitmoji，而非个人偏好。
+
+特殊情况：
+- 为新 agent（全新 catalog 功能）→ 优先使用 `✨` 而非 `📚`（因为 Gitmoji 将 `✨` 定义为新功能）
+- 仅更新现有 agent 文档或贡献指南 → 使用 `📚`
+
+## Automated Validation
+
+通过 commit-msg hook 自动验证格式：
+
+```bash
+commit_regex='^(🚀|✨|🐛|♻️|📚|🧪|💄|🔧|📦) [A-Z]+-[0-9]+: .+$'
+```
+
+不符合格式的提交将被拒绝。
+
+## Official References
+
+- Primary: [gitmoji.dev](https://gitmoji.dev/)
+- Source of truth: [github.com/carloscuesta/gitmoji](https://github.com/carloscuesta/gitmoji)
+
+## Sources
+- [[project-management-jira-workflow-steward]]
--- a/wiki/concepts/Innovation-Pipeline.md
+++ b/wiki/concepts/Innovation-Pipeline.md
@@ -0,0 +1,50 @@
+---
+title: "Innovation Pipeline"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Innovation Pipeline（创新管道）是 [[Strategic-Portfolio-Management]] 中的一个特殊项目层级，专门用于管理实验性、创新性项目。与 Tier 1/2 追求确定性回报不同，Innovation Pipeline 项目的核心价值是学习而非短期财务回报。
+
+## Position in Portfolio Architecture
+
+```
+Strategic Portfolio
+├── Tier 1 Projects (Strategic Priority)
+│   └── 高投资，高确定性战略回报
+├── Tier 2 Projects (Growth Initiatives)
+│   └── 中等投资，中等增长回报
+└── Innovation Pipeline
+    └── 低投资，高学习价值，失败是预期结果
+```
+
+## Key Characteristics
+
+- **Learning Objectives**：项目目标设定为学习而非回报
+- **Lower Resource Commitment**：资源投入相对有限
+- **Higher Risk Tolerance**：失败被视为有价值的数据点
+- **Capability Development**：驱动组织能力和技术探索
+- **Technology Adoption**：新技术和方法的试验田
+
+## Relationship to Other Concepts
+
+- 属于 [[Strategic-Portfolio-Management]] 的组成部分
+- 支持 [[Resource-Allocation]] 中的能力建设优先级
+- 与 [[Risk-Balancing]] 密切相关——Innovation Pipeline 是风险敞口的主要来源
+
+## In Studio Producer Framework
+
+在 [[Project-Management-Studio-Producer]] 的 Strategic Portfolio Plan 模板中，Innovation Pipeline 是独立章节，包含：
+- 实验性举措和学习目标
+- 技术采纳和能力发展
+- 失败容错机制设计
+
+## Aliases
+- Experimental Portfolio
+- R&D Pipeline
+- Innovation Portfolio
+- Learning Portfolio
--- a/wiki/concepts/Jira-Gate.md
+++ b/wiki/concepts/Jira-Gate.md
@@ -0,0 +1,44 @@
+---
+title: "Jira Gate"
+type: concept
+tags: ["project-management", "jira", "workflow", "quality-gate"]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Jira Gate（Jira 门控）是 [[Jira Workflow Steward]] Agent 实施的一项强制性工作流规则：**在没有有效 Jira Task ID 的前提下，不生成任何分支名、提交信息或 Git 工作流建议**。Jira Task ID 是所有交付输出的前提条件。
+
+## Rules
+
+1. **Never generate without Jira ID**：分支名、commit message、PR 标题均必须包含有效 Jira Task ID
+2. **Exact preservation**：严格使用 Jira ID 原样，不得发明、规范或猜测缺失的 ticket 引用
+3. **Prompt for ID, don't guess**：若 Jira 任务缺失，则请求补充，而非自动创建 ID
+
+> 若 Jira 任务缺失，询问：`Please provide the Jira task ID associated with this work (e.g. JIRA-123).`
+
+## External Prefix Handling
+
+若外部系统（如 AI 编码 agent）添加了外层前缀，分支名内部仍需保持仓库原生格式：
+
+- ✅ `codex/feature/JIRA-214-add-sso-login`（仓库格式在外部包装内保持不变）
+- ❌ `feature/JIRA-214-add-sso-login` → `codex/JIRA-214-add-sso-login`（丢失仓库类型信息）
+
+## Gate Position in Workflow
+
+```
+[Request] → [Jira Gate: 要求 Jira ID] → [Branch Strategy] → [Atomic Commits] → [PR Template] → [Release]
+     ↓
+[无 Jira ID → 停止并请求]
+```
+
+Jira Gate 位于整个交付链路的最前端，是第一道质量门。
+
+## Relationship to Other Concepts
+
+- [[Jira-Git-Traceability]]：Jira Gate 是 Jira-Git Traceability 的第一步门控
+- [[Branch-Strategy]]：Gate 通过后才进入分支策略流程
+- [[Pull-Request-Governance]]：PR 合并同样需要 Jira ID 验证
+
+## Sources
+- [[project-management-jira-workflow-steward]]
--- a/wiki/concepts/Jira-Git-Traceability.md
+++ b/wiki/concepts/Jira-Git-Traceability.md
@@ -0,0 +1,39 @@
+---
+title: "Jira-Git Traceability"
+type: concept
+tags: ["project-management", "jira", "git-workflow", "delivery-traceability"]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Jira-Git Traceability（ Jira-Git 可追溯性）是指通过 Jira Task ID 将软件交付链路中的 Jira 任务、分支、提交、Pull Request 和 Release 五个环节串联为完整可追溯记录的工作流实践。其核心原则为：**若某项变更无法从 Jira 追踪到分支、提交、PR 直至发布，则该工作流视为不完整**。
+
+## Core Components
+
+| 环节 | 要求 | 工具/模式 |
+|------|------|----------|
+| Jira Task | 所有 Git 工作流的唯一锚点 | Jira Gate 强制前置 |
+| Branch | 必须包含 Jira ID：`feature/JIRA-214-xxx` | 分支策略 |
+| Commit | 必须包含 Jira ID：`<Gitmoji> JIRA-214: description` | Gitmoji Commit 规范 |
+| Pull Request | PR 标题必须包含 Jira ID | PR 模板 |
+| Release | 发布记录必须关联 Jira 任务或变更控制项 | Release Branch |
+
+## Why It Matters
+
+1. **Review Speed**：reviewer 可在 5 秒内通过 commit subject 识别变更类型和 ticket 上下文
+2. **Release Notes**：从 Jira 和 Git 历史可在 10 分钟内重建发布说明
+3. **Incident Forensics**：事故溯源时可在分钟内定位引入行为的 ticket 和 commit
+4. **Audit Readiness**：合规环境中，需求到代码的完整链路是审计强制要求
+5. **Atomic Reverts**：commit 原子化且 purpose-labeled，回滚操作低风险
+
+## Relationship to GitOps
+
+Jira-Git Traceability 是 GitOps 在项目管理层面的扩展：
+- **GitOps** 关注：基础设施声明 → Git → 自动调和（环境始终与 Git 同步）
+- **Jira-Git Traceability** 关注：需求（Jira）→ 代码（Git）→ 交付（Release）全链路可追溯
+
+两者互补：GitOps 确保基础设施状态，Jira-Git Traceability 确保业务需求到代码的双向可追溯。
+
+## Sources
+- [[project-management-jira-workflow-steward]]（主要来源）
--- a/wiki/concepts/Liquid-Glass-Design-System.md
+++ b/wiki/concepts/Liquid-Glass-Design-System.md
@@ -0,0 +1,29 @@
+---
+title: "Liquid Glass Design System"
+type: concept
+tags: []
+sources: [visionos-spatial-engineer]
+last_updated: 2026-04-25
+---
+
+## Definition
+Apple visionOS 26 引入的核心视觉设计语言，通过透明材质实现深度感知和空间沉浸感。Liquid Glass 设计系统让 UI 元素呈现出类似玻璃的透明、折射和光影效果，同时自适应 light/dark 环境变化和周围内容。
+
+## Core Characteristics
+- **Translucent Materials（透明材质）**：UI 元素呈现玻璃般的透明效果，可透视背后的 3D 空间内容
+- **Adaptive Lighting（自适应光效）**：根据环境光照条件动态调整透明度和反射效果
+- **Depth Perception（深度感知）**：通过透明层级传达 UI 元素在 Z 轴上的相对位置
+- **Contextual Adaptation（内容自适应）**：透明效果根据周围 3D 内容动态调整，确保可读性和美观性
+
+## Implementation Technologies
+- **SwiftUI glassBackgroundEffect**：实现毛玻璃透明背景的 SwiftUI modifier
+- **RealityKit Materials**：RealityKit 中的物理材质系统支持 Liquid Glass 效果
+- **Metal Shader Framework**：底层 GPU 渲染支持高性能透明效果计算
+
+## Related Concepts
+- [[Spatial Layouts]]：Liquid Glass UI 在 3D 空间中的布局管理
+- [[Multi-Window Architecture]]：多窗口场景下 Liquid Glass 效果的一致性
+- [[Glass Background Effects]]：具体实现透明效果的技术手段
+
+## Sources
+- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
--- a/wiki/concepts/Multi-Window-Architecture.md
+++ b/wiki/concepts/Multi-Window-Architecture.md
@@ -0,0 +1,29 @@
+---
+title: "Multi-Window Architecture"
+type: concept
+tags: []
+sources: [visionos-spatial-engineer]
+last_updated: 2026-04-25
+---
+
+## Definition
+visionOS 应用的多窗口管理模式，基于 WindowGroup 场景类型，支持 single-instance 窗口、volumetric 展示和空间场景管理。
+
+## Window Types
+- **Unique Windows（单实例窗口）**：应用主窗口，每次只存在一个实例
+- **Volumetric Presentations（空间展示）**：在 3D volume 内呈现的辅助内容窗口
+- **Spatial Scenes（空间场景）**：完整的 3D 空间应用场景定义
+
+## Core Patterns
+- **WindowGroup Management**：通过 WindowGroup 管理同类型窗口的生命周期
+- **Glass Background Effects**：每个窗口默认带有 Liquid Glass 风格的毛玻璃背景
+- **Spatial Presentation Hierarchy**：窗口之间的空间层级关系管理
+- **Presentation State**：SwiftUI 状态驱动的窗口展示模式切换
+
+## Related Concepts
+- [[Spatial Widgets]]：与主窗口协同工作的空间小组件
+- [[Liquid Glass Design System]]：多窗口场景下的统一视觉语言
+- [[Multi-Window Architecture]] — 见本文
+
+## Sources
+- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
--- a/wiki/concepts/National-Annex.md
+++ b/wiki/concepts/National-Annex.md
@@ -0,0 +1,91 @@
+---
+title: "National Annex"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+## Aliases
+- National Annex to Eurocode（Eurocode 国家附录）
+- NDPs（Nationally Determined Parameters，国家确定参数）
+- 欧洲规范国家附录
+- 欧盟规范本地化修订
+
+## Definition
+
+National Annex（国家附录）是各 Eurocode 成员国对 EN 1990–1999 系列规范的本地化修订文件，通过国家确定参数（NDPs）改变 Eurocode 默认值，从而在 Eurocode 框架内实现各国不同的安全等级和设计偏好。National Annex 是 Eurocode 体系内**规范冲突的主要来源**。
+
+## What National Annexes Modify
+
+### 1. Nationally Determined Parameters (NDPs)
+Eurocode 规范中的部分参数由各成员国自行确定，包括：
+
+| 参数类型 | 示例 | 影响 |
+|---------|------|------|
+| 荷载分项系数 γ | Eurocode 默认 γG=1.35, γQ=1.5 | 英国 NA 可能调高 γG |
+| 组合系数 ψ | Eurocode 默认 ψ0=0.7（办公室活荷载） | 各国可能不同 |
+| 可靠度系数 γM | Eurocode 默认 γM0=1.0, γM1=1.0 | 影响构件抗力 |
+| 安全等级 | 从 RC1/RC2/RC3 选择 | 影响 γF 和 γM |
+| 地震重要性系数 γI | EN 1998 Default = 1.0 | 各国可调高 |
+| 地震谱形状 | 与 EN 1998-1 附录相同 | 部分国家有修订 |
+
+### 2. Informative Annexes
+- Eurocode 各部分包含"资料性附录"，各国可选择采纳或废弃
+
+### 3. National Deviations
+- 超出 Eurocode 框架的额外要求（如特定材料标准、构造细节）
+
+## Major National Annexes
+
+| 国家 | 缩写 | 关键差异 |
+|------|------|---------|
+| United Kingdom | UK NA to BS EN | 风荷载高度系数（UK 地形更粗糙）、地震分区 |
+| Germany | NA DE | DIN 标准兼容性处理、高延性 DCH 要求严格 |
+| France | NF EN | 混凝土抗压强度等级（法标与欧标衔接） |
+| Netherlands | NTA | 地基与岩土设计有特殊附录 |
+| Sweden | EKS | 风荷载暴露系数（瑞典多森林地形） |
+| Norway | NA NO | 地震要求（挪威北部有地震风险） |
+
+## Why National Annexes Create Conflicts
+
+**同一结构在两个国家可能需要不同设计：**
+
+```
+场景：钢框架建筑，巴黎 vs 伦敦
+
+设计输入：
+  - 结构系统：钢框架
+  - 跨度：8m
+  - 活荷载：5 kN/m²
+
+英国 (UK NA to BS EN 1993-1-1)：
+  - γG = 1.35, γQ = 1.50
+  - 截面分类界限按 UK NA 修正
+  - 风荷载：UK NA 按暴露度 C（郊区地形）
+
+法国 (NF EN)：
+  - γG = 1.35, γQ = 1.50（与 EN 默认相同）
+  - 截面分类按 EN 默认值
+  - 风荷载：NF EN 规定暴露类别和系数
+
+结果：相同结构在 UK 和 FR 可能需要不同构件尺寸
+```
+
+## Multi-Standard Projects and National Annexes
+
+在涉及 Eurocode + 另一标准（如 ACI 318）的多标准项目中，National Annexes 的处理流程：
+
+1. **识别所有适用的 National Annex**（项目所在国 + 业主所在国）
+2. **列出 NDPs 与 EN 默认值的偏差**
+3. **评估偏差对设计结果的影响**
+4. **在 Basis of Design 中记录最终采用的 NDPs**
+5. **向 AHJ（主管当局）确认接受哪些 National Annex 版本**
+
+## Usage in Civil Engineer Agent
+
+Civil Engineer Agent 处理 Eurocode 项目时，**必须**在每个计算包开头注明：
+1. 所采用的 Eurocode EN 标准编号和版本年份
+2. 所适用的 National Annex（如 NA to BS EN 1993-1-1）
+3. 所有与 EN 默认值不同的 NDPs（列表形式）
+4. **铁律**：绝不在 Eurocode 公式中混入 ACI/AISC 的分项系数
--- a/wiki/concepts/Portfolio-ROI.md
+++ b/wiki/concepts/Portfolio-ROI.md
@@ -0,0 +1,43 @@
+---
+title: "Portfolio ROI"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Portfolio ROI（组合投资回报率）是衡量组合层面投资效益的核心财务指标，定义为组合整体收益与总投资成本的比率。在 [[Project-Management-Studio-Producer]] 的框架中，Portfolio ROI 是组合管理的北极星指标，设定基准为 **≥ 25%**。
+
+## Calculation Framework
+
+```
+Portfolio ROI = (组合总收益 - 组合总投资成本) / 组合总投资成本 × 100%
+```
+
+## Portfolio ROI vs. Project ROI
+
+| Dimension | Project ROI | Portfolio ROI |
+|-----------|-------------|--------------|
+| Scope | 单个项目 | 组合整体 |
+| Time | 项目周期 | 跨项目周期 |
+| Metrics | 范围/时间/成本 | 战略价值实现率 |
+| Focus | 执行效率 | 资源配置效率 |
+| Target | 交付成功 | 商业目标实现 |
+
+## Key Influencing Factors
+
+- **Tier 1 项目**：战略优先级项目，高投资高预期回报
+- **Tier 2 项目**：增长型项目，中等投资中等回报
+- **Innovation Pipeline**：实验性项目，低投资学习导向
+- **Risk-Adjusted Returns**：风险调整后的预期回报
+
+## Tracking in Strategic Portfolio Management
+
+在 [[Project-Management-Studio-Producer]] 的四阶段工作流中，Portfolio ROI 追踪属于"Step 4: Performance Management and Strategic Optimization"阶段，通过 Strategic Portfolio Review 模板进行季度复盘。
+
+## Aliases
+- Return on Portfolio Investment
+- Portfolio Performance
+- Investment Efficiency
--- a/wiki/concepts/Pull-Request-Governance.md
+++ b/wiki/concepts/Pull-Request-Governance.md
@@ -0,0 +1,60 @@
+---
+title: "Pull Request Governance"
+type: concept
+tags: ["git", "code-review", "workflow", "delivery-traceability"]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Pull Request Governance（PR 治理）是通过标准化 PR 模板、安全审查要求、风险记录和强制审查流程，保护分支合并质量的工作流规范。
+
+## Mandatory PR Scenarios
+
+以下场景的合并**必须**经过 PR review：
+- 合并到 `main`
+- 合并到 `release/*`
+- 大型重构
+- 关键基础设施变更
+- 认证、授权、基础设施、敏感数据处理相关变更
+
+## PR Template Structure
+
+标准 PR 模板包含：
+
+```markdown
+## What does this PR do?
+Implements **JIRA-214** by adding the SSO login flow...
+
+## Jira Link
+- Ticket: JIRA-214
+- Branch: feature/JIRA-214-add-sso-login
+
+## Change Summary
+- Add SSO callback controller and provider wiring
+- Add regression coverage for expired refresh tokens
+- Document the new login setup path
+
+## Risk and Security Review
+- Auth flow touched: yes
+- Secret handling changed: no
+- Rollback plan: revert the branch and disable the provider flag
+
+## Testing
+- Unit tests: passed
+- Integration tests: passed in staging
+- Manual verification: login and logout flow verified in staging
+```
+
+## Security Discipline
+
+- **No secrets in PR**：凭证、token、客户数据严禁出现在 PR 标题、描述或 diff 中
+- **Explicit validation scope**：明确说明哪些环节经过测试、哪些未经测试
+- **Security review mandatory**：认证、授权、基础设施、敏感数据处理变更必须经过安全审查
+
+## Rollback Readiness
+
+每个 PR 必须包含回滚计划，确保回滚操作低风险、低影响。
+
+## Sources
+- [[project-management-jira-workflow-steward]]
--- a/wiki/concepts/RealityKit-SwiftUI-Integration.md
+++ b/wiki/concepts/RealityKit-SwiftUI-Integration.md
@@ -0,0 +1,29 @@
+---
+title: "RealityKit-SwiftUI Integration"
+type: concept
+tags: []
+sources: [visionos-spatial-engineer]
+last_updated: 2026-04-25
+---
+
+## Definition
+Apple 提供的 RealityKit 3D 渲染引擎与 SwiftUI 声明式 UI 框架之间的深度集成模式，允许开发者用 SwiftUI 语法声明式地构建 3D 空间界面。
+
+## Core Integration Patterns
+- **@Observable Entities**：RealityKit 实体实现 @Observable 协议，与 SwiftUI 视图自动双向绑定
+- **Direct Gesture Handling**：SwiftUI 手势（Gesture）直接作用于 RealityKit 实体，无需中间层
+- **ViewAttachmentComponent**：将 SwiftUI 视图作为 component 附加到 RealityKit 实体
+- **EntityManager Integration**：通过 SwiftUI Environment 访问 EntityManager 实例
+
+## Implementation Benefits
+- **Declarative 3D（声明式 3D）**：用 SwiftUI 视图语法替代传统 Entity-Component 模式
+- **State Synchronization（状态同步）**：SwiftUI @State/@Binding 与 RealityKit 实体属性自动同步
+- **Reduced Boilerplate（减少样板代码）**：相比纯 RealityKit 开发，集成模式显著减少代码量
+
+## Related Concepts
+- [[SwiftUI Volumetric APIs]]：基于 RealityKit-SwiftUI 集成的上层 API 集
+- [[Spatial Layouts]]：集成后的 3D 内容在空间中的布局管理
+- [[Multi-Window Architecture]]：集成模式在多窗口场景下的应用
+
+## Sources
+- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
--- a/wiki/concepts/RecruitmentFunnelAnalyzer.md
+++ b/wiki/concepts/RecruitmentFunnelAnalyzer.md
@@ -0,0 +1,43 @@
+---
+title: "Recruitment Funnel Analyzer（招聘漏斗分析）"
+type: concept
+tags: [recruitment, analytics, data-driven]
+sources: [recruitment-specialist]
+last_updated: 2026-04-25
+---
+
+## 定义
+招聘漏斗分析是一种数据驱动方法，通过追踪从职位发布到试用期通过的全链路各环节转化率，识别招聘瓶颈并持续优化招聘效率和 ROI。
+
+## 在 [[Recruitment Specialist Agent]] 中的实现
+
+### 漏斗模型
+```
+职位曝光 → 投递量 → 简历通过 → 初试 → 复试 → 终面 → 发 offer → offer 接受 → 入职 → 试用期通过
+```
+
+### 关键指标
+| 指标 | 计算方式 |
+|------|---------|
+| 简历投递率 | 投递数 / 曝光量 × 100% |
+| 简历通过率 | 通过数 / 投递数 × 100% |
+| 面试到场率 | 实到人数 / 邀约人数 × 100% |
+| offer 接受率 | 接受数 / 发出数 × 100% |
+| 入职率 | 入职数 / offer接受数 × 100% |
+| 试用期留存率 | 试用期通过数 / 入职数 × 100% |
+| 总体转化率 | 试用期通过数 / 投递数 × 100% |
+
+### 渠道 ROI 分析
+- 每渠道计算：成本 / 简历数、成本 / 入职数、成本 / 试用期通过数
+- 综合效率分 = 候选人质量分 × 0.4 + (1/单次入职成本) × 10000 × 0.3 + 试用期通过率 × 100 × 0.3
+
+### 招聘周期分析
+- 平均招聘周期（天数）
+- 各环节耗时：简历筛选、面试流程、offer 审批、候选人决策
+
+## Python 实现
+内置于 [[Recruitment Specialist Agent]] 的 `RecruitmentFunnelAnalyzer` 类，支持按职位、部门、周期筛选数据。
+
+## 连接
+- [[Recruitment Specialist Agent]] — 内置分析工具
+- [[Structured Interview]] — 数据驱动决策支撑结构化面试标准
--- a/wiki/concepts/Resource-Allocation.md
+++ b/wiki/concepts/Resource-Allocation.md
@@ -0,0 +1,40 @@
+---
+title: "Resource Allocation"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Resource Allocation（资源分配）是在有限资源约束下，将人力、预算、技术和时间的组合进行最优配置的过程。区别于单一项目的资源管理，Portfolio 层面的资源分配需要在多个项目和不同项目阶段之间进行优先级权衡。
+
+## Key Dimensions
+
+- **Creative Resources**：设计师、创意人员、内容创作者
+- **Technical Resources**：工程师、开发人员、架构师
+- **Financial Resources**：预算分配、投资优先级
+- **Time Resources**：团队容量、时间盒规划
+- **Vendor Resources**：外部合作伙伴、自由职业者
+
+## Portfolio-Level Principles
+
+- **Prioritization Framework**：基于战略价值的项目分级（Tier 1/2/Innovation Pipeline）
+- **Capacity Planning**：团队容量与需求匹配，避免过载
+- **Trade-off Management**：短期交付与长期能力建设之间的权衡
+- **Dynamic Rebalancing**：根据 Portfolio Review 动态调整资源分配
+
+## Relationship to Strategic Portfolio Management
+
+Resource Allocation 是 [[Strategic-Portfolio-Management]] 的核心子功能之一。在 [[Project-Management-Studio-Producer]] 的框架中，Resource Allocation Strategy 是 Strategic Portfolio Plan 的核心组成部分，包含：
+- Team Capacity（当前和计划的团队组成）
+- Skill Development（培训和能力建设优先级）
+- External Partners（供应商和自由职业者战略关系）
+- Budget Distribution（跨组合层级的投资分配）
+
+## Aliases
+- Resource Planning
+- Capacity Management
+- Budget Allocation
+- Talent Allocation
--- a/wiki/concepts/SLS.md
+++ b/wiki/concepts/SLS.md
@@ -0,0 +1,73 @@
+---
+title: "SLS"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+## Aliases
+- Serviceability Limit State（正常使用极限状态）
+- 正常使用极限状态
+- 使用性极限状态
+- 挠度控制
+- Deflection Control
+
+## Definition
+
+正常使用极限状态（SLS, Serviceability Limit State）是结构设计中验证结构在正常使用时满足适用性要求的验算标准，关注的是结构的**使用功能、舒适度和耐久性**，而非安全性。SLS 验算确保建筑在使用荷载下不产生过大的变形、振动或裂缝，从而不影响正常使用。
+
+## Core SLS Criteria
+
+| 验算项目 | 典型限值 | 规范来源 |
+|---------|---------|---------|
+| 楼板挠度（活荷载） | L/360（住宅）/ L/480（办公） | ACI 318 Appendix B |
+| 梁挠度（活荷载） | L/360（吊顶）/ L/240（无吊顶） | AISC Steel Manual |
+| 悬臂挠度 | L/180 | ACI 318 |
+| 裂缝宽度（钢筋混凝土） | 0.3mm（室内）/ 0.4mm（室外） | EN 1992-1-1 |
+| 振动（人致振动） | 频率 ≥ 5Hz（办公）/ 加速度 < 0.5% g | AISC Design Guide 11 |
+| 裂缝宽度（梁） | 0.3mm（受拉钢筋保护层方向） | ACI 318-19 |
+
+## SLS vs ULS
+
+> **ULS 和 SLS 必须同时满足，方为合格设计。**
+> ULS 是安全底线（结构会不会塌），SLS 是使用品质（结构会不会晃/裂/变形过大影响功能）。
+
+**控制关系的两种典型场景：**
+
+1. **ULS 控制（Strength-Governed）**：高应力截面，承载力决定截面尺寸，挠度通常满足
+   - 例子：高荷载短跨度钢梁
+
+2. **SLS 控制（Deflection-Governed）**：低应力长跨度截面，挠度决定截面尺寸
+   - 例子：活荷载下挠度超限的长跨度钢梁 → 需增大截面至 W24x55
+   - 例子：预应力混凝土梁的反拱与长期挠度平衡
+
+## SLS in Major Codes
+
+### Eurocode EN 1990
+- **SLS 组合**（特征组合/频遇组合/准永久组合）：
+  - 特征组合：Gk + Qk（不乘系数）
+  - 频遇组合：Gk + ψ1Qk（ψ1 为频遇系数）
+  - 准永久组合：Gk + ψ2Qk（ψ2 为准永久系数，ψ2 通常 < ψ1）
+- **挠度限值**：Annex NA.A（UK NA）或各国附录规定，通常 L/250
+
+### ACI 318 (Appendix B)
+- **直接验算法**：计算总挠度 ΔT = ΔLP + ΔLT - Δi
+  - ΔLP：恒荷载产生的即时挠度
+  - ΔLT：长期荷载（持续荷载）产生的挠度
+  - Δi：反拱（预应力或柱顶升引起的向上位移）
+- **容许挠度**：Table 24.2.2（ACI 318-19）按构件类型和吊顶条件规定限值
+
+### AISC Steel Manual / AISC Design Guide 11
+- **挠度限值**：由使用者功能需求决定，无强制规范限值，但通常遵循 L/360 或 L/240
+- **振动验算**：高层楼板、人行天桥等人致振动，须验算固有频率和加速度响应
+
+## Usage in Civil Engineer Agent
+
+Civil Engineer Agent 在每个计算包中**必须同时检查 ULS 和 SLS**：
+1. 先验算 ULS（截面抗力是否足够）
+2. 再验算 SLS（挠度/裂缝/振动是否满足限值）
+3. 若 SLS 不满足 → **增大截面**（增加 Ix）或调整配筋
+4. **注明控制条件**：本次设计中由 SLS（挠度）控制，ULS 验算仅供参考
+
+> **典型案例**：AISC 360 LRFD 钢梁 W21x44 — φMn ≥ Mu **通过 ULS**，但 δLL = 18.1mm > L/360 = 16.9mm **SLS 失败**，须增大至 W24x55。
--- a/wiki/concepts/STARFramework.md
+++ b/wiki/concepts/STARFramework.md
@@ -0,0 +1,33 @@
+---
+title: "STAR Framework（行为面试法）"
+type: concept
+tags: [interview, behavioral-assessment, hiring]
+sources: [recruitment-specialist]
+last_updated: 2026-04-25
+---
+
+## 定义
+STAR Framework 是一种结构化行为面试方法，通过四个维度引导候选人描述其过去的工作经历：
+- **Situation（情境）**：描述事情发生的背景
+- **Task（任务）**：明确候选人需要完成的目标
+- **Action（行动）**：候选人具体采取了哪些行动
+- **Result（结果）**：最终取得了什么成果
+
+## 在 [[Recruitment Specialist Agent]] 中的应用
+- 设计行为面试问题，基于 STAR 框架引导候选人提供具体案例
+- 针对不同能力维度准备追问提示
+- 关注候选人的具体行为，而非假设性回答
+- 使用结构化评分卡评估 STAR 回答的完整性和质量
+
+## 使用场景
+适用于评估候选人的：
+- 团队协作能力
+- 问题解决能力
+- 领导力
+- 冲突管理能力
+- 客户导向意识
+
+## 连接
+- [[Recruitment Specialist Agent]] — 该 Agent 的核心面试评估工具
+- [[Structured Interview]] — STAR 是结构化面试的重要组成部分
+- [[Structured Interview]] — 结构化面试结合 STAR 和评分卡确保评估一致性
--- a/wiki/concepts/Spatial-Widgets.md
+++ b/wiki/concepts/Spatial-Widgets.md
@@ -0,0 +1,29 @@
+---
+title: "Spatial Widgets"
+type: concept
+tags: []
+sources: [visionos-spatial-engineer]
+last_updated: 2026-04-25
+---
+
+## Definition
+visionOS 26 引入的小组件系统，可吸附于 3D 空间中的墙面、桌面等表面，并持久化放置在物理位置，无需应用处于前台运行即可展示。
+
+## Core Characteristics
+- **Spatial Placement（空间放置）**：通过 SwiftUI API 定义 widget 在 3D 空间中的精确位置
+- **Surface Snapping（表面吸附）**：自动识别并吸附到墙面、桌面等物理表面
+- **Persistent Presence（持久化存在）**：Widget 保留在设定位置，用户返回时仍然可见
+- **Cross-App Usage（跨应用使用）**：作为系统级功能，所有应用可共享 widget 展示
+
+## Implementation Technologies
+- **WidgetKit for visionOS**：Apple Widget 框架的 visionOS 扩展
+- **SwiftUI Volumetric Widgets**：支持 volumetric 展示模式的 widget 类型
+- **3D Positioning API**：定义 widget 在空间中的精确位置和朝向
+
+## Related Concepts
+- [[Liquid Glass Design System]]：Widget 的视觉呈现采用 Liquid Glass 风格
+- [[Multi-Window Architecture]]：Widget 与主应用窗口的协同模式
+- [[Spatial Layouts]]：Widget 在 3D 空间中的布局管理
+
+## Sources
+- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
--- a/wiki/concepts/Stakeholder-Alignment.md
+++ b/wiki/concepts/Stakeholder-Alignment.md
@@ -0,0 +1,45 @@
+---
+title: "Stakeholder Alignment"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Stakeholder Alignment（利益相关者对齐）是确保所有关键利益相关者（高管、团队、客户、供应商）对项目目标和方向达成共识的管理实践。在 [[Project-Management-Studio-Producer]] 的框架中，这是高管级战略沟通的核心能力。
+
+## Stakeholder Categories
+
+- **Executive Stakeholders**：C-suite、高管层——关注战略价值和商业影响
+- **Internal Stakeholders**：团队成员、部门——关注执行可行性和资源支持
+- **External Stakeholders**：客户、合作伙伴——关注交付价值和关系健康
+- **Regulatory Stakeholders**：合规、审计——关注法规遵从和治理
+
+## Core Practices
+
+- **Executive Communication**：面向高管层的战略叙事——"Our Q3 portfolio delivered 35% ROI while establishing market leadership"
+- **Expectation Setting**：明确界定范围、交付物和成功标准
+- **Strategic Investment Framing**：将项目投资包装为战略价值主张
+- **Board Presentation**：3年战略定位和竞争优势分析
+- **Feedback Loop**：建立双向沟通机制
+
+## Communication Styles
+
+| Context | Style | Example |
+|---------|-------|---------|
+| 战略规划 | 愿景驱动 | "This initiative positions us perfectly for the anticipated market shift" |
+| 高管汇报 | 价值量化 | "Creative excellence drove $5M revenue increase" |
+| 团队沟通 | 执行可行 | 技术细节和资源需求 |
+| 客户沟通 | 交付导向 | 交付物和价值实现 |
+
+## Relationship to Strategic Portfolio Management
+
+[[Project-Management-Studio-Producer]] 将 Stakeholder Alignment 作为核心职责，要求"Manage senior stakeholder relationships and executive-level communications"，是 Portfolio ROI 和按时交付之外的第三大成功要素。
+
+## Aliases
+- Stakeholder Management
+- Executive Communication
+- Strategic Communication
+- Expectation Management
--- a/wiki/concepts/Strategic-Portfolio-Management.md
+++ b/wiki/concepts/Strategic-Portfolio-Management.md
@@ -0,0 +1,35 @@
+---
+title: "Strategic Portfolio Management"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Strategic Portfolio Management（战略组合管理）是通过系统化方法管理多个相互关联的项目组合，以实现组织级商业目标的最大化。核心在于在组合层面进行资源优化配置、风险平衡和优先级排序，而非单个项目管理。
+
+## Core Components
+
+- **Portfolio Definition**：识别和定义组合的范围、边界和成员项目
+- **Strategic Alignment**：确保组合中所有项目与组织战略目标一致
+- **Resource Optimization**：跨项目分配有限资源，最大化整体 ROI
+- **Risk Balancing**：在创新项目与已验证项目之间平衡风险敞口
+- **Performance Monitoring**：组合层面的 KPI 追踪（Portfolio ROI、按时交付率）
+- **Governance**：定期 Portfolio Review 和战略调整机制
+
+## Relationship to Single Project Management
+
+| Dimension | Single Project Management | Strategic Portfolio Management |
+|-----------|-------------------------|-------------------------------|
+| Scope | 单个项目 | 多个相关项目的集合 |
+| Objective | 项目交付成功 | 组织战略目标实现 |
+| Time Horizon | 项目生命周期 | 持续、跨项目周期 |
+| Decision Maker | Project Manager | Executive/Portfolio Manager |
+| Success Metric | 铁三角（范围/时间/成本） | Portfolio ROI ≥ 25%，95% 按时交付 |
+
+## Aliases
+- Portfolio Management
+- Project Portfolio Management
+- Strategic Portfolio Governance
--- a/wiki/concepts/StructuredInterview.md
+++ b/wiki/concepts/StructuredInterview.md
@@ -0,0 +1,32 @@
+---
+title: "Structured Interview（结构化面试）"
+type: concept
+tags: [interview, hiring, evaluation]
+sources: [recruitment-specialist]
+last_updated: 2026-04-25
+---
+
+## 定义
+结构化面试是一种标准化的面试方法，通过统一的评分标准、面试问题和评估维度，确保所有候选人接受同等条件的评估，提升面试的一致性和准确性。
+
+## 在 [[Recruitment Specialist Agent]] 中的应用
+- 设计标准化面试评分卡，每个维度有明确的评分标准和行为锚定
+- 构建按岗位类型和职级分类的面试题库
+- 确保面试官一致性：培训面试官并校准评分标准
+- 与 [[STAR Framework]] 结合使用，提升评估深度
+
+## 核心要素
+1. **标准化评分卡**：统一评估维度 + 行为锚定描述
+2. **题库**：按岗位类型、职级分类的预设问题
+3. **面试官培训**：确保评分标准一致性
+4. **校准机制**：定期回顾和校准面试评分
+
+## 关键指标
+- 面试评估一致性（Inter-rater Reliability）
+- 预测效度（与入职后绩效的相关性）
+- 候选人体验评分
+
+## 连接
+- [[Recruitment Specialist Agent]] — 结构化面试是该 Agent 招聘流程设计的核心
+- [[STAR Framework]] — STAR 是结构化面试的组成部分
+- [[Recruitment Specialist Agent]] — 内置面试题库和能力评估模型
--- a/wiki/concepts/SwiftUI-Volumetric-APIs.md
+++ b/wiki/concepts/SwiftUI-Volumetric-APIs.md
@@ -0,0 +1,29 @@
+---
+title: "SwiftUI Volumetric APIs"
+type: concept
+tags: []
+sources: [visionos-spatial-engineer]
+last_updated: 2026-04-25
+---
+
+## Definition
+visionOS 26 新增的 SwiftUI API 集，专门用于在 volumetric 空间场景中渲染和管理 3D 内容，实现声明式的空间界面开发。
+
+## Core Capabilities
+- **3D Content Integration（3D 内容集成）**：将 RealityKit 实体无缝嵌入 SwiftUI 视图层级
+- **Volume Content（Volume 内容）**：支持在受限的 3D 空间（volume）内展示和管理内容
+- **Breakthrough UI（突破性 UI）**：允许 UI 元素突破传统窗口边界，融入 3D 场景
+- **Transient Content（临时内容）**：支持在 volume 内快速展示和消失的临时 UI 元素
+
+## Key API Components
+- **@Observable Entities**：声明式状态管理，与 SwiftUI 视图自动同步
+- **Direct Gesture Handling**：在 3D 内容上直接处理手势输入
+- **ViewAttachmentComponent**：将 SwiftUI 视图附加到 RealityKit 实体上
+
+## Related Concepts
+- [[RealityKit-SwiftUI Integration]]：SwiftUI Volumetric APIs 的底层集成机制
+- [[Spatial Layouts]]：3D 内容在空间中的定位和布局模式
+- [[Multi-Window Architecture]]：Volumetric 内容在多窗口场景下的管理
+
+## Sources
+- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
--- a/wiki/concepts/ULS.md
+++ b/wiki/concepts/ULS.md
@@ -0,0 +1,63 @@
+---
+title: "ULS"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+## Aliases
+- Ultimate Limit State（极限状态设计）
+- 强度极限状态
+- 承载能力极限状态
+- Strength Limit State
+
+## Definition
+
+极限状态设计（ULS, Ultimate Limit State）是结构设计中验证结构承载能力的核心原则，要求结构在最大设计荷载组合下不发生承载能力失效。ULS 关注的是结构**是否会倒塌或发生不可接受的变形**，对应的是结构安全性的底线要求。
+
+## Core Principle
+
+> **ULS 核心公式**：`作用效应 ≤ 抗力`（Effect ≤ Resistance）
+
+在 LRFD/SD 设计体系中：
+- **作用效应**（Demand）：通过荷载分项系数放大后的内力（弯矩 M、剪力 V、轴力 P）
+- **抗力**（Resistance）：通过抗力系数折减后的构件承载力（φMn、φVn、φPn）
+
+## ULS vs SLS 对比
+
+| 维度 | ULS（极限状态） | SLS（正常使用极限状态） |
+|------|----------------|----------------------|
+| 目标 | 防止倒塌和承载能力失效 | 防止使用功能受损 |
+| 设计方法 | LRFD/SD（分项系数法） | 容许挠度/裂缝宽度/振动频率 |
+| 关注点 | 安全性 | 适用性、耐久性 |
+| 验算条件 | φRn ≥ γi ΣQi | Δ ≤ Δ_limit |
+| 典型限值 | 截面承载力 | 挠度 L/360、裂缝 0.3mm |
+
+**ULS 和 SLS 必须同时满足，方为合格设计。**
+
+## ULS in Major Codes
+
+### Eurocode (EN 1990)
+- **ULS 组合**（永久+可变+偶然）：γG Gk + γQ Qk + γQ ψ0 Qk,acc
+- **延性要求**：EN 1998 抗震设计 DCL/DCM/DCH 等级对 ULS 验算有不同的细部构造要求
+
+### ACI 318 (Strength Design)
+- **ULS 组合**：U = 1.4D / U = 1.2D + 1.6L + 0.5(Lr 或 R)
+- **φ 系数**：φ = 0.90（抗弯）、φ = 0.75（抗剪）、φ = 0.65（轴压螺旋箍筋柱）
+
+### AISC 360 (LRFD)
+- **ULS 组合**：U = 1.2D + 1.6L（主力组合）
+- **φ 系数**：φ = 0.90（抗弯构件）、φ = 0.75（抗剪）、φ = 0.90（轴拉）
+
+## Usage in Civil Engineer Agent
+
+Civil Engineer Agent 在每个计算包中**必须同时**检查 ULS 和 SLS：
+1. 首先进行 ULS 验算（截面是否满足 φRn ≥ Σγi Qi）
+2. 若 ULS 通过，进行 SLS 验算（挠度、裂缝、振动是否满足限值）
+3. 若 SLS 不满足，**增大截面或调整配筋**，直至两者同时满足
+4. 在计算包开头明确注明：所采用的分项系数和抗力系数（及其来源规范）
+
+## Common Pitfall
+
+> **ULS 通过 ≠ 设计完成**：结构可能在 ULS 验算中通过，但在 SLS（挠度）验算中失败。例如，AISC 360 LRFD 钢梁设计中，W21x44 可能满足抗弯 ULS，但 W24x55（更大截面）才是由挠度控制的选型。