书籍↔节点对照

书证的公开安全投影：书籍 ↔ 节点强度矩阵、覆盖统计与反向缺口。

168 节点18 组364 边

§1书籍 ↔ 节点对照矩阵

行 = 参考书，列 = 被核验节点（按层分组）；格 = 证据强度徽标（取该节点 × 该书记录的最高优先级）与章级锚，点击节点 ID 进入节点页。

directpartialinferredcontradicted

本质 essence（36 个被核验节点）
书 \ 节点	ESS-G-01 关注点分离	ESS-G-02 依赖倒置与依赖规则	ESS-G-03 边界与接口隔离	ESS-G-04 模块化与分解	ESS-G-06 视图与视角	ESS-G-07 架构描述与对应关系	ESS-H-02 内聚与耦合	ESS-H-06 组合优于继承与脆弱基类	ESS-H-07 可读性与认知负荷	ESS-H-08 SOLID 职责划分与替换性	ESS-I-01 测试作为验证与反馈机制本质	ESS-I-02 可测试性本质	ESS-I-03 错误、缺陷与失效	ESS-I-04 测试的不可穷尽性	ESS-J-01 构建发布运行分离	ESS-J-02 开发生产一致性	ESS-K-01 可靠性即风险管理	ESS-K-02 故障不可避免性与容错	ESS-K-03 可观测性本质	ESS-K-04 度量驱动的反馈闭环	ESS-L-01 软件演化定律	ESS-L-04 演化的不可逆性	ESS-L-05 变更成本随复杂度增长	ESS-M-01 可维护性本质	ESS-M-02 可演化性与可扩展性	ESS-M-03 性能效率本质	ESS-M-04 可靠性与可用性	ESS-M-05 质量属性不可直接测量	ESS-N-01 康威定律	ESS-N-02 组织-架构同态	ESS-N-03 团队边界与架构边界耦合	ESS-N-04 认知负荷约束	ESS-N-05 组织即设计系统	ESS-O-01 本质复杂度与偶然复杂度	ESS-O-02 架构即权衡	ESS-O-03 权衡的不可消除性
BK-001 Software Engineering at Google: Lessons Learned from Programming Over Time	—	—	—	—	—	—	—	—	direct ChComprehension of CodeChDocumentation PhilosophyChKnow Your AudienceChThe Parameters of Good Documentation	—	direct ChBenefits of Testing CodeChWhy Do We Write Tests?ChWrite, Run, React	—	direct ChConfiguration issuesChTesting OverviewChThe Story of Google Web Server	direct ChA Note on Code CoverageChThe Beyoncé RuleChUnanticipated behaviors, inputs, and side effects	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-007 Clean Architecture	direct Ch4Ch15.5Ch17.3Ch19Ch22Ch22.1Ch24	direct Ch11Ch11.2Ch14.4Ch14.5Ch22.1Ch23.4Ch34.3	partial Ch14.1	—	—	partial Ch21.1	partial Ch13.4	—	—	—	—	partial Ch23.1	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch1.1Ch2.2Ch6.3Ch15.4Ch17.1Ch17.2	partial Ch26.1	—
BK-009 Software Architecture in Practice	—	—	—	—	—	—	—	—	—	—	—	direct Ch12.1Ch12.2	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch9Ch9.1Ch9.2	—	direct Ch3.2Ch3.3Ch19.4	—	—	—	—	—	—	direct Ch3.2Ch20.5Ch21.5	direct Ch3.2Ch3.4Ch20.5Ch21.5
BK-011 Building Evolutionary Architectures	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch1.1Ch1.9Ch7.18Ch9.33	direct Ch1.6Ch1.7Ch5.15Ch7.3Ch7.13	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-013 Documenting Software Architectures: Views and Beyond	—	—	—	—	direct Ch6.3.1 Create Context Diagrams Using the Vocabulary of the ViewCh9.2 A Method for Choosing the ViewsChP.3 Architecture ViewsChUsing View Packets to Record ArchitectureChVariation 1: Divide the View into View Packets	direct Ch3.5 Relation to Other Kinds of ViewsCh5.1 OverviewChSection 4. Mapping Between Views	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-020 Clean Code	—	—	—	—	—	—	—	direct Ch3.7Ch6.1Ch6.2Ch10.2Ch16.2Ch17.22Ch17.23	—	direct Ch10.3Ch10.4Ch10.7Ch10.8Ch12.6Ch17.38	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-021 Refactoring	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-022 Working Effectively with Legacy Code	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-023 Designing Data-Intensive Applications	—	—	—	direct Ch2.4	—	—	—	—	—	—	—	—	—	—	—	—	partial Ch2.3	direct Ch2.3	—	—	—	—	direct Ch2.5	direct Ch2.5	direct Ch2.4Ch2.5	direct Ch2.2	direct Ch2.3	—	—	—	—	—	—	direct Ch2.5	direct Ch1.1	direct Ch4.1
BK-024 Release It!	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch3Ch4Ch5Ch6	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-025 Site Reliability Engineering: How Google Runs Production Systems	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct ChKey InsightsChManaging RiskChRisk Tolerance of ServicesChTypes of failures	—	direct ChBlack-Box Versus White-BoxChDefinitionsChPractical Alerting from Time-Series Data	direct ChControl MeasuresChDefining ObjectivesChMonitoring for the Long TermChPractical Alerting from Time-Series DataChTen Years On…ChTying These Principles Together	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-026 The Site Reliability Workbook: Practical Ways to Implement SRE	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct ChAccidents Are NormalChConclusionChFrom Load to OverloadChIt’s Better to Fix It Yourself; Don’t Blame Someone Else	—	direct ChImplementing Purposeful MetricsChMonitoringChSources of Monitoring Data	direct ChDecision Making Using SLOs and Error BudgetsChImproving the Quality of Your SLOChLowering the SLO or Increasing the WindowChWhy SREs Need SLOs	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-030 Team Topologies	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch2	direct Ch2Ch7	direct Ch2Ch3Ch6	direct Ch3Ch8	direct Ch1Ch8	—	—	—
BK-031 The Twelve-Factor App	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct ChVChVI	direct ChIIChX	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-036 Software Architecture in Practice — Chapter 4: Quality Attribute Scenarios	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch4.3ChModifiability ScenarioChQUALITY ATTRIBUTE SCENARIOS	—	—	—	—	—	—	—	direct Ch4.3ChAvailability ScenarioChQUALITY ATTRIBUTE SCENARIO GENERATION

方法论 methodology（45 个被核验节点）
书 \ 节点	MTH-F-05 功能与非功能需求分类	MTH-G-01 架构决策记录	MTH-G-02 质量属性场景与ATAM	MTH-G-03 架构风格选择方法	MTH-G-04 领域驱动战略设计	MTH-G-05 架构文档化方法	MTH-G-06 效用树与敏感点权衡点分析	MTH-H-01 重构手法族	MTH-H-04 代码复审与可读性治理	MTH-I-01 测试层次	MTH-J-01 部署流水线	MTH-J-04 配置外置与显式化	MTH-J-07 可回滚性与爆炸半径控制	MTH-K-01 服务等级目标方法	MTH-K-02 错误预算政策与燃尽率告警	MTH-K-03 四大黄金信号监控方法	MTH-K-04 可观测性信号关联方法	MTH-K-05 事件响应与无指责复盘方法	MTH-K-06 混沌工程方法	MTH-K-07 容量规划与变更管理方法	MTH-L-01 行为保持重构	MTH-L-02 代码坏味道启发式	MTH-L-04 演进式架构	MTH-L-05 架构适应度函数	MTH-L-06 遗留系统渐进治理	MTH-M-01 质量属性战术映射方法	MTH-M-02 可修改性战术应用	MTH-M-03 可用性战术应用	MTH-M-06 质量属性权衡决策方法	MTH-N-02 团队拓扑四类型	MTH-N-03 团队交互模式	MTH-N-04 平台团队与最薄可行平台	MTH-N-05 DORA 交付效能指标	MTH-N-06 团队边界治理	MTH-O-01 覆盖与精度的不对称权衡	MTH-O-02 准入与触发时机选择	MTH-O-03 技术选型的够用原则	MTH-O-04 能力-成本-速度三角	MTH-O-05 质量属性冲突治理	MTH-O-06 粒度与边界设定	MTH-O-07 自动化方式选择	MTH-O-08 复杂度阶梯与演进时机	MTH-O-09 理解成本优先的简单原则	MTH-O-10 增量演化与一致性治理	MTH-O-11 度量与反馈闭环
BK-001 Software Engineering at Google: Lessons Learned from Programming Over Time	—	—	—	—	—	—	—	—	direct ChAutomate Where PossibleChCode ConsistencyChHow Code Review Works at GoogleChWrite Small Changes	direct ChDesigning a Test SuiteChTest SizeChUnfaithful doubles	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct ChContinuous DeliveryChDistributed BuildsChExpressiveness: Token Versus Substring Versus RegexChSearch Query LatencyChTime, Scale, Trade-Offs	—	—	—	—	—	—	—
BK-007 Clean Architecture	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-009 Software Architecture in Practice	—	—	direct Ch3.3Ch19.4Ch20.5Ch21.1Ch21.5	direct Ch3.2Ch3.4Ch20.3	—	—	direct Ch19.4Ch20.5Ch21.5	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch3.4Ch3.5Ch3.6	direct Ch8.2	direct Ch4.2	direct Ch3.2Ch20.3Ch20.5Ch21.4Ch21.5	—	—	—	—	—	—	—	direct Ch3.4Ch20.3	—	direct Ch3.2Ch21.4Ch21.5	—	—	—	—	—	—
BK-011 Building Evolutionary Architectures	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch1.2Ch1.3Ch4.28Ch7.7Ch7.8Ch7.12Ch9.41	direct Ch2.1Ch2.3Ch2.4Ch4.1Ch4.2Ch4.28Ch9.14	—	—	—	—	—	—	—	—	—	—	—	direct Ch2.4Ch2.5Ch2.7Ch3.3Ch4.28	—	—	—	—	direct Ch2.1Ch2.4Ch2.7Ch2.11Ch7.9Ch9.29	—	—	—	direct Ch2.12Ch4.1Ch4.28Ch7.8Ch7.10Ch9.13
BK-013 Documenting Software Architectures: Views and Beyond	—	direct Ch6.5.1 Why Document Architectural Decisions?Ch6.5.2 A Template for Documenting Architectural DecisionsCh6.5.4 Which Decisions to DocumentCh6.5.5 The Payback for Documenting Architectural Decisions	—	—	—	direct Ch6.2 Descriptive CompletenessCh10.1.1 A Standard Organization for Documenting a ViewCh10.2.1 A Standard Organization for Documenting InformationChYou can use the templates in this chapter to create architecture	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch10.1.3 Avoiding Unnecessary Repetition Across Views or ViewChP.2.4 Economics of Architecture DocumentationChRule 1: Write Documentation from the Reader’s Point of ViewChRule 2: Avoid Unnecessary RepetitionChRule 6: Keep Documentation Current but Not Too Current	—	—
BK-020 Clean Code	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-021 Refactoring	—	—	—	—	—	—	—	direct Ch3ChDefining RefactoringChFormat of the RefactoringsChHow Mature Are These Refactorings?	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch4ChDefining RefactoringChFormat of the RefactoringsChThe Two HatsChWhen Shouldn't You Refactor?	direct Ch3ChDuplicated CodeChParallel Inheritance HierarchiesChRefused Bequest	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-022 Working Effectively with Legacy Code	—	—	—	—	—	—	—	direct ChSeam TypesChSeams	—	—	—	—	—	—	—	—	—	—	—	—	direct ChImproving DesignChLegacy Code Change Algorithm	—	—	—	direct ChFour Reasons to Change SoftwareChRisky ChangeChTest CoveringsChThe Legacy Code Change AlgorithmChWe Feel Overwhelmed	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-023 Designing Data-Intensive Applications	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	partial Ch2.3	—	—	—	—	—	—	—	—	partial Ch2.3	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch2.4Ch2.5	partial Ch13.1	partial Ch2.2
BK-024 Release It!	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch17	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
BK-025 Site Reliability Engineering: How Google Runs Production Systems	—	—	—	—	—	—	—	—	—	—	—	—	direct ChChange ManagementChEmergency ResponseChGradual and Staged Rollouts	direct ChAggregationChChoosing TargetsChObjectives in PracticeChSLOs Set ExpectationsChService Level TerminologyChStandardize Indicators	direct ChBenefitsChForming Your Error BudgetChMotivation for Error Budgets	direct ChAs Simple as Possible, No SimplerChErrorsChLatencyChSaturationChThe Four Golden SignalsChWorrying About Your Tail (or, Instrumentation and Performance)	direct ChAlertingChBlack-Box MonitoringChBlack-Box Versus White-BoxChDefinitionsChSymptoms Versus Causes	direct ChCollaborate and Share KnowledgeChGoogle’s Postmortem PhilosophyChLive Incident State DocumentChRecursive Separation of ResponsibilitiesChWhat to Do When Systems BreakChWhen to Declare an Incident	—	direct ChCapacity PlanningChDemand Forecasting and Capacity PlanningChHandling OverloadChPer-Customer LimitsChThe Pitfalls of "Queries per Second"	—	—	—	—	—	—	—	—	—	—	—	—	direct ChHigh VelocityChRelationships Between Testing and Mean Time to Repair	—	—	—	—	—	—	—	—	—	—	—	—
BK-026 The Site Reliability Workbook: Practical Ways to Implement SRE	—	—	—	—	—	—	—	—	—	—	—	—	direct ChDependencies and IsolationChMinimizing Risk to SLOs and the Error BudgetChRelease Engineering PrinciplesChUse a Gradual Canary for Better Metric Selection	direct ChChoosing an Appropriate Time WindowChGetting Stakeholder AgreementChReliability Targets and Error BudgetsChWhat to Measure: Using SLIs	direct Ch2: Increased Alert WindowCh4: Alert on Burn RateCh6: Multiwindow, Multi-Burn-Rate AlertsChAlerting ConsiderationsChEstablishing an Error Budget Policy	direct ChDependenciesChSaturationChStatus of Served TrafficChThe SLO Culture Project	direct ChExamplesChImprove both logs and metricsChMetrics with PurposeChMonitoringChSources of Monitoring DataChTesting Alerting Logic	direct ChCase Study 2: Service Fault—Cache Me If You CanChCounterproductive finger pointingChIncident Command SystemChMain Roles in Incident ResponseChOrganizational IncentivesChTools and Templates	—	direct ChCase Study 2: When Load Shedding AttacksChConfiguring ConservativelyChFuture-proofingChIntroducing Non-Abstract Large System DesignChStrategies for Mitigating OverloadChWhy “Non-Abstract”?	—	—	—	—	—	—	—	—	—	—	—	—	direct ChAutomate This Year’s Job AwayChShare Ownership with DevelopersChThe Wisdom of ProductionChUse the Same Tooling, Regardless of Function or Job Title	—	—	—	—	—	—	—	—	—	—	—	—
BK-030 Team Topologies	—	—	—	—	partial Ch6Ch7	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch5	direct Ch7	direct Ch5	—	direct Ch2Ch7Ch8	—	—	—	—	—	partial Ch6	—	—	—	—	—
BK-031 The Twelve-Factor App	—	—	—	—	—	—	—	—	—	—	direct ChIIChV	direct ChIII	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct ChIIChVIIChXChXII	—	—	—	—	direct ChIChIIIChIXChVIII	—	—	—
BK-036 Software Architecture in Practice — Chapter 4: Quality Attribute Scenarios	direct ChModifiability ScenarioChQUALITY ATTRIBUTE SCENARIO GENERATIONChQUALITY ATTRIBUTE SCENARIOS	—	—	—	—	—	direct ChAvailability ScenarioChQUALITY ATTRIBUTE SCENARIO GENERATION	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	direct Ch4.3	—	—	—	—	—	direct ChModifiability ScenarioChQUALITY ATTRIBUTE SCENARIO GENERATION	—	—	—	—	—	direct ChModifiability ScenarioChQUALITY ATTRIBUTE SCENARIO GENERATION	—	—	—	—

技术实践 technology（12 个被核验节点）
书 \ 节点	TEC-I-01 持续集成服务与流水线	TEC-J-04 金丝雀发布	TEC-K-01 断路器与重试退避	TEC-K-02 可观测性信号采集	TEC-K-03 服务等级目标与错误预算	TEC-K-04 混沌工程实践	TEC-K-05 无指责复盘实践	TEC-K-06 DORA 交付指标	TEC-L-01 架构适应度函数工具化	TEC-L-02 绞杀者渐进式替换	TEC-M-03 可修改性战术实现	TEC-N-02 团队拓扑落地与规模化
BK-001 Software Engineering at Google: Lessons Learned from Programming Over Time	direct ChAccessible and actionable feedbackChContinuous IntegrationChFast Feedback LoopsChHermetic TestingChPresubmit versus post-submitChTAP: Google’s Global Continuous Build	—	—	—	—	—	—	—	—	—	—	—
BK-007 Clean Architecture	—	—	—	—	—	—	—	—	—	—	—	—
BK-009 Software Architecture in Practice	—	—	—	—	—	—	—	—	—	—	direct Ch8.2	—
BK-011 Building Evolutionary Architectures	—	—	—	—	—	—	—	—	direct Ch2.1Ch2.4Ch4.28Ch4.29Ch7.9	—	—	—
BK-013 Documenting Software Architectures: Views and Beyond	—	—	—	—	—	—	—	—	—	—	—	—
BK-020 Clean Code	—	—	—	—	—	—	—	—	—	—	—	—
BK-021 Refactoring	—	—	—	—	—	—	—	—	—	—	—	—
BK-022 Working Effectively with Legacy Code	—	—	—	—	—	—	—	—	—	direct ChFaking CollaboratorsChHow Do I Add a Feature?ChSeam TypesChSprout MethodChWrap Method	—	—
BK-023 Designing Data-Intensive Applications	—	—	partial Ch9.2	—	—	—	direct Ch2.3	—	—	—	—	—
BK-024 Release It!	—	—	direct Ch5	—	—	direct Ch17	—	—	—	—	—	—
BK-025 Site Reliability Engineering: How Google Runs Production Systems	—	direct ChCanary testChFeature Flag Frameworks	—	direct ChBlack-Box Versus White-BoxChLatencyChThe Four Golden SignalsChWhy Monitor?ChWorrying About Your Tail (or, Instrumentation and Performance)	direct ChBenefitsChControl MeasuresChEmbracing RiskChForming Your Error BudgetChService Level Terminology	—	—	direct ChRelationships Between Testing and Mean Time to RepairChThe Role of a Release Engineer	—	—	—	—
BK-026 The Site Reliability Workbook: Practical Ways to Implement SRE	—	direct ChCanarying ReleasesChChoosing a Canary Population and DurationChRequirements of a Canary Process	—	direct ChDependenciesChIntended ChangesChPrefer Loose CouplingChSaturationChSources of Monitoring DataChTesting Alerting Logic	direct Ch3: Incrementing Alert DurationCh6: Multiwindow, Multi-Burn-Rate AlertsChEstablishing an Error Budget PolicyChGetting StartedChReliability Targets and Error BudgetsChWhat to Measure: Using SLIs	—	—	direct ChChange Should Be GradualChCompare and ContrastChConclusionChMeasurement Is CrucialChMove Fast by Reducing the Cost of FailureChNarrow, Rigid Incentives Narrow Your Success	—	—	—	—
BK-030 Team Topologies	—	—	—	—	—	—	—	—	—	—	—	direct Ch3Ch5Ch7Ch8
BK-031 The Twelve-Factor App	—	—	—	—	—	—	—	—	—	—	—	—
BK-036 Software Architecture in Practice — Chapter 4: Quality Attribute Scenarios	—	—	—	—	—	—	—	—	—	—	—	—

其他 / 案例（7 个被核验节点）
书 \ 节点	CAS-X-01 去中心化聊天架构逆向	CAS-X-02 网申填写扩展逆向架构	CAS-X-04 网申 v2 深度重构	CAS-X-05 preset 通道耦合分析	CAS-X-06 插件 DAG RC5→RC7 升级	CAS-X-07 插件 DAG 两次级联升级	CAS-X-09 harness 源码架构解析
BK-001 Software Engineering at Google: Lessons Learned from Programming Over Time	—	—	—	—	—	—	—
BK-007 Clean Architecture	—	partial Ch17Ch17.5Ch18.1Ch22.1Ch24Ch24.1Ch24.2Ch34.5	—	—	—	—	—
BK-009 Software Architecture in Practice	—	—	—	—	—	—	—
BK-011 Building Evolutionary Architectures	—	—	—	partial Ch4.2Ch4.3Ch4.11Ch5.15Ch7.13	partial Ch3.2Ch7.24Ch7.25Ch7.26Ch8.15	partial Ch2.4Ch3.2Ch4.4Ch5.7Ch7.24Ch9.38	—
BK-013 Documenting Software Architectures: Views and Beyond	direct Ch4.3 Call-Return StylesChExamples of the Peer-to-Peer StyleChTable 4.3 Summary of the peer-to-peer styleChWhat the Peer-to-Peer Style Is For	—	—	—	—	—	direct Ch1.3 What Module Views Are ForCh1.4.3 Dependency Structure MatrixChTooling RequirementsChVariation 1: Divide the View into View Packets
BK-020 Clean Code	—	—	—	—	—	—	—
BK-021 Refactoring	—	—	direct ChDesign Changes That Are Difficult to RefactorChFinding ReferencesChLong Parameter ListChRefactoring Improves the Design of SoftwareChShotgun SurgeryChSwitch Statements	—	—	—	—
BK-022 Working Effectively with Legacy Code	—	—	direct ChFirst Steps	—	—	—	—
BK-023 Designing Data-Intensive Applications	—	—	—	—	—	—	—
BK-024 Release It!	—	—	—	—	—	—	—
BK-025 Site Reliability Engineering: How Google Runs Production Systems	—	—	—	—	—	—	—
BK-026 The Site Reliability Workbook: Practical Ways to Implement SRE	—	—	—	—	—	—	—
BK-030 Team Topologies	—	—	—	—	—	—	—
BK-031 The Twelve-Factor App	—	—	—	—	—	—	—
BK-036 Software Architecture in Practice — Chapter 4: Quality Attribute Scenarios	—	—	—	—	—	—	—

§2覆盖统计

书	覆盖节点	direct	partial	inferred	正向	反向
BK-001 Software Engineering at Google: Lessons Learned from Programming Over Time	8	30	4	1	0	35
BK-007 Clean Architecture	9	11	17	7	29	6
BK-009 Software Architecture in Practice	15	60	36	0	96	0
BK-011 Building Evolutionary Architectures	11	31	30	10	71	0
BK-013 Documenting Software Architectures: Views and Beyond	7	34	3	0	37	0
BK-020 Clean Code	2	9	4	1	14	0
BK-021 Refactoring	4	20	4	0	24	0
BK-022 Working Effectively with Legacy Code	5	17	1	0	18	0
BK-023 Designing Data-Intensive Applications	18	46	10	2	40	18
BK-024 Release It!	4	22	2	0	24	0
BK-025 Site Reliability Engineering: How Google Runs Production Systems	15	68	8	0	76	0
BK-026 The Site Reliability Workbook: Practical Ways to Implement SRE	15	61	16	0	77	0
BK-030 Team Topologies	12	51	28	2	81	0
BK-031 The Twelve-Factor App	6	21	3	0	24	0
BK-036 Software Architecture in Practice — Chapter 4: Quality Attribute Scenarios	7	18	2	1	0	21
合计	100	499	168	24	611	80

§3反向发现缺口（阶段3 输入）

缺口为阶段3 结构扩展的输入导航；summary 与 proposed_action 为改写摘要，非书籍原文。仅展示章节级锚。

gap	类型	书	锚	目标	改写摘要	建议动作
GAP-CA-001	覆盖盲区	BK-007	Ch13.4	内聚与耦合	书中以三原则刻画组件级内聚：复用/发布等价、共同闭包、共同复用，并给出三者相互拉扯的张力图与随成熟度动态平衡的规律；图谱现有内聚耦合节点偏模块层级，未单列组件级内聚原则。	新增节点（组件内聚三原则与张力平衡），并在 ESS-H-02 与组件/边界节点间补边
GAP-CA-002	覆盖盲区	BK-007	Ch14.4	边界与接口隔离提案：TEC-H-04	书中给出组件依赖治理的完整方法族：无环依赖原则、稳定依赖原则、稳定抽象原则，以及入/出耦合、抽象度与主序列距离等度量；图谱边界节点未覆盖依赖环治理与稳定性度量这类可操作方法。	新增节点（组件依赖管理与度量方法），并与 ESS-G-02、ESS-G-03 补边
GAP-CA-003	概念缺口	BK-007	Ch21.1	架构描述与对应关系	书中主张架构应把用例与领域意图喊出来，让系统结构本身可读地说明业务，而非被框架或技术分层淹没；图谱有架构描述节点，却无「架构表意/意图可见」这一独立概念。	新增节点（架构表意与意图可见性），从 ESS-G-07 与 MTH-G-05 建立依据推导边
GAP-CA-004	概念缺口	BK-007	Ch6.3	本质复杂度与偶然复杂度	书中把函数式范式的不可变性提升为架构约束，主张把可变状态隔离到少数受控位置并以事件溯源等结构承载状态变化，以此抑制并发与状态带来的复杂度；图谱缺少不可变性与可变隔离概念。	新增节点（不可变性与可变隔离），与 ESS-O-01、ESS-G-01 建立前置/组合边
GAP-CA-005	概念缺口	BK-007	Ch23.1	可测试性本质	书中以谦卑对象模式在边界处把难测行为压缩为极简外壳，并以 Presenter/View、数据库网关、数据映射与服务监听器等实例承载，使可测试性成为边界设计的直接产物；图谱可测试性节点未覆盖该模式族。	新增节点（谦卑对象与测试边界模式），从 ESS-I-02 与边界节点建立实现/依据推导边
GAP-CA-006	覆盖盲区	BK-007	Ch26.1	架构即权衡	书中系统论证数据库、Web 与框架皆为可推迟的细节，主张核心策略不依赖这些选择，并把组合装配点（Main）视为终极细节；图谱缺少「细节可推迟」与组合根这一治理视角。	新增节点（细节可推迟与组合根），与 ESS-G-02、MTH-J-04 补引并建立依赖关联
GAP-CC-001	应引未引	BK-020	Ch10.5	内聚与耦合	本书给出可操作的凝聚度判据：类应保有少量实例变量，每个方法至少操作其中一个，变量被全部方法共用即达最大凝聚；当少数方法想共享某些变量而其余方法不用时，几乎总意味着另一个类正试图从大类里脱出，应当拆分。它还给出反向信号——把大函数拆小时提升为实例变量的做法会稀释凝聚，此时应顺势切出新的类。图谱该节点未引用本书。	为 ESS-H-02 补引 BK-020 第10章 10.5–10.6 节，作为「以实例变量共享度度量凝聚、以凝聚流失作为拆类触发条件」的出处。
GAP-CC-002	应引未引	BK-020	Ch12.4	DRY 单一知识来源	本书把消除重复列为四条简单设计规则中优先级最高的一条，并主张重复的每种形态都代表一次被漏掉的抽象机会：字面相同的代码应抽成方法，算法相似而代码不同的模块应改用模板方法或策略，重复还可以藏在实现层（如 isEmpty 与 size 各自维护状态）。第3章更把重复称为软件中万恶之源，并列举数据库范式、面向对象与结构化编程都在消除重复。图谱该节点未引用本书。	为 ESS-H-03 补引 BK-020 第12章 12.4 节与第3章 3.24 节，作为「消除重复为最高优先规则」及「重复的多种形态与对应消解手法」的出处。
GAP-CC-003	应引未引	BK-020	Ch17.38	设计模式与反模式	本书给出以多态取代分支的启发式：同一类选择只允许存在一个分支语句，其分支必须负责创建多态对象以取代系统其余处的同类分支；并提醒多数人用分支只是因为那是最省事的暴力解法，函数比类型更易变的场合相对罕见，因此每条分支语句都应先被怀疑。第3章进一步给出藏法——把分支埋进抽象工厂，由工厂产出派生实例，其余函数经接口多态分派。图谱该节点未引用本书。	为 ESS-H-09 补引 BK-020 第17章 17.38 节与第3章 3.7 节，作为「以多态封装类型选择、分支语句收敛为唯一工厂」这一模式化解法的出处。
GAP-CC-004	应引未引	BK-020	Ch10.8	依赖倒置与依赖规则	本书以 Portfolio 依赖东京证券交易所 API 为例，说明依赖具体细节会使测试受外部波动牵制，于是抽出只声明一个询价方法的接口、让具体实现去实现它、并由构造函数注入引用，测试即可换成固定报价的替身；作者由此显式陈述依赖倒置原则——类应依赖抽象而非具体细节，并指出解耦到可如此测试的系统同时更灵活、更易复用。第11章把该思路扩展为把构造与使用分离，并用依赖注入作为落地机制。图谱该节点未引用本书。	为 ESS-G-02 补引 BK-020 第10章 10.8 节与第11章 11.2/11.5 节，作为「以抽象接口隔离外部细节、由注入实现依赖方向倒置」的出处。
GAP-CC-005	应引未引	BK-020	Ch8.4	测试替身与测试策略	本书把「用测试去探索第三方 API」写成一种测试替身之外的独立用途：学习测试按自己的预期用法调用外部接口，是受控实验，成本近乎为零且不必事先读懂全部文档；第三方发布新版本时重跑这些测试即可立刻发现行为差异，避免把兼容性风险留到生产环境。它还主张干净的边界应由一组按生产用法行使接口的出站测试守护，并建议用包装层收窄对第三方细节的依赖，以便日后替换实现或做桩。图谱该节点未引用本书。	为 MTH-I-05 补引 BK-020 第8章 8.2–8.4 与 8.6 节，作为「学习测试/边界出站测试」这一测试替身之外用途的出处。
GAP-CC-006	应引未引	BK-020	Ch17.23	边界与接口隔离	本书把接口宽度直接换算为耦合高低：定义良好的模块接口很小，能用很少的动作做成很多事；定义糟糕的模块接口又宽又深，做简单的事也要摆出许多手势。给出的收敛手段包括隐藏数据、工具函数、常量与临时变量，不造大量方法与实例变量，不为子类预留成批受保护成员。第17章另一条启发式（抽象层级错位）则以 Stack 接口里的「剩余容量百分比」为例，指出该操作只对部分实现有意义，应下移到有界栈这类派生接口。图谱该节点未引用本书。	为 ESS-G-03 补引 BK-020 第17章 17.23 与 17.21 节，作为「接口宽度即耦合度」判据与「按使用方需要拆细接口」的出处。
GAP-CC-007	应引未引	BK-020	Ch17.15	代码坏味道启发式	第17章把坏味道整理成一份带编号的巡诊清单，覆盖注释、环境、函数、命名与通用五类，每条给出命名、判据与处置建议，并强调这些是启发式而非可机械套用的规则、每条都要看具体情境。可支撑图谱该节点把坏味道当启发式使用的做法，但本书这一章本身未被引用。	为 MTH-L-02 补引 BK-020 第17章全章（尤其 17.15 通用类与 17.10 函数类各条），作为「坏味道清单化、逐条给判据与处置」的原始出处。
GAP-CC-008	应引未引	BK-020	Ch12.3	理解成本优先的简单原则	本书的简单设计由四条规则按优先级构成：先让全部测试通过，其次消除重复，再次确保表达力，最后才是最小化类与方法数量；作者并明确承认消除重复、表达力与单一职责都可能被做过头，为求小而造出过多微小类反而有害。这与图谱该节点「以理解成本优先」的取向高度同源，却未引用本书。	为 MTH-O-09 补引 BK-020 第12章 12.1–12.6 节，作为「简单设计四规则的优先级排序」及「简洁可被做过头」的出处。
GAP-CC-009	覆盖盲区	BK-020	Ch3.5	— 提案：MTH-H-05	第3章整章给出函数粒度的设计纪律，且多有条目化判据：函数要短、只做一件事、块内缩进不超过一两层、每个函数只下降一个抽象层级、按自顶向下讲述的顺序排列（步降规则）、参数越少越好且避免标志参数与输出参数、避免副作用、命令与查询分离、用异常替代错误码。图谱现有节点覆盖重构手法、命名与评审，但没有「函数粒度与接口形状」这一层方法节点，本书最核心的这一章因此无处挂载。	提案新节点 MTH-H-05「函数设计与抽象层级（Function Design and Abstraction Levels）」，以 BK-020 第3章为主信源，收纳函数长度、单一职责、步降规则、参数形态与副作用等判据。
GAP-CC-010	覆盖盲区	BK-020	Ch2.2	— 提案：MTH-H-06	第2章给出完整的命名方法：名字要透露意图、避免误导与无意义区分、可发音、可搜索、不加编码前缀、类名用名词、方法名用动词、一概念只用一词、不用双关、优先取解空间与问题域的词汇、为名字补充有意义的上下文但不过度加长。图谱有可读性与认知负荷这一本质节点，却没有可执行的命名方法节点，命名这条最基础的工程纪律在图中缺位。	提案新节点 MTH-H-06「命名方法与意图表达（Naming and Intention Revelation）」，以 BK-020 第2章为主信源，并与 ESS-H-07 可读性节点建立细化关系。
GAP-CC-011	覆盖盲区	BK-020	Ch7.5	— 提案：ESS-H-12	第7章把异常处理当作独立的设计主题：优先用异常而非返回码；先写 try-catch-finally 的骨架再填内容；用非受检异常；让异常带上足够的上下文以便定位；按调用方的需要而非异常的来源来划分异常类，必要时把第三方 API 的多种异常包装成一类；为特例定义正常流程；不返回也不传递 null，改用抛异常或特例对象。图谱现有节点覆盖错误/缺陷/失效的概念区分与容错、混沌等运行期议题，但缺少「异常与错误处理的编码策略」这一本质节点。	提案新节点 ESS-H-10「异常处理策略（Exception Handling Strategy）」，以 BK-020 第7章为主信源，并与边界隔离、可测试性节点建立关系。
GAP-CC-012	覆盖盲区	BK-020	Ch8.6	— 提案：MTH-H-07	第8章把「与外部代码的接缝」写成一套做法：以包装层收窄对第三方包的依赖，使日后换库代价小、也便于在自测中做桩；用学习测试探索并固定对第三方行为的理解；在第三方尚未提供时先按理想接口编码、用适配器在边界转换；边界处保持清晰的分离并配一组出站测试界定期望；不让过多代码知道第三方的细节。图谱有边界与接口隔离这一本质节点、也有测试替身方法节点，但缺少「边界接入与防腐」这一方法层节点。	提案新节点 MTH-H-07「边界接入与防腐（Boundary Integration and Anticorruption）」，以 BK-020 第8章为主信源，并与 ESS-G-03、MTH-I-05 建立关系。
GAP-CC-013	覆盖盲区	BK-020	Ch14.5	— 提案：MTH-H-08	第14章以 Args 解析器从粗稿到成品的全过程示范「持续精进」：先让代码跑起来、写测试固定行为，再以极小步骤逐步改动，每一步都保持测试通过；先让重复的临时结构存在，再逐步把行为下沉到合适的派生类，途中始终保持程序可运行。第16章与第10章也复述同一做法——把一次大函数拆成多个类不是重写，而是先写测试固定行为、再做一连串微小改动。图谱有行为保持重构与代码坏味道节点，但缺少「以测试保护的极小步增量精进」这一方法节点。	提案新节点 MTH-H-08「持续精进与极小步改造（Successive Refinement and Tiny Steps）」，以 BK-020 第14章与第16章为主信源，并与 MTH-L-01、MTH-H-01 建立关系。
GAP-CC-014	覆盖盲区	BK-020	Ch13.4	— 提案：ESS-H-14	第13章给出并发设计的职责划分判据：并发本身就是一个足以构成变更原因的关注点，因此应把线程管理代码与线程无关代码分开，只留少数受控位置管理线程；并给出限制共享数据作用域、使用数据副本、让线程尽量独立等推论，以及缩小同步区、警惕同步方法之间的依赖、把线程相关部分做成可插拔可调、把偶发失败当作线程问题的候选信号等做法。图谱现有节点覆盖可靠性、容错与混沌工程，但没有把「并发与线程管理的职责边界」作为本质层议题。	提案新节点 ESS-H-11「并发职责划分（Concurrency Responsibility Partitioning）」，以 BK-020 第13章为主信源，并与 ESS-H-08 单一职责、ESS-I-02 可测试性建立关系。
GAP-DDIA-001	应引未引	BK-023	Ch2.3	可靠性即风险管理	该节点主张可靠性是在风险与稳定之间做显式管理；DDIA 第2章把可靠性界定为出故障时仍持续正确工作，并区分局部故障与整体失效，可作为其定义性上游来源，但节点现未引用本书。	为该节点补引 BK-023 第2章「可靠性与容错」，作为可靠性定义与故障/失效区分的来源。
GAP-DDIA-002	应引未引	BK-023	Ch2.4	可演化性与可扩展性	该节点把可演化性界定为低代价适应变化；DDIA 第2章对可伸缩性给出「先描述负载、再评估资源与性能关系」的界定，并单列可演化性，直接支撑该节点主张，但未被引用。	为该节点补引 BK-023 第2章「可伸缩性」与「可演化性」小节。
GAP-DDIA-003	应引未引	BK-023	Ch2.5	本质复杂度与偶然复杂度	该节点区分问题固有的本质复杂度与工具所致的偶然复杂度；DDIA 第2章在讨论简单性时直接采用这一划分并指出两者边界随工具演进而移动，可佐证此节点但未被引用。	为该节点补引 BK-023 第2章「简单性：管理复杂度」小节。
GAP-DDIA-004	应引未引	BK-023	Ch2.3	混沌工程方法	该节点把混沌工程表述为在生产中做受控实验；DDIA 第2章介绍故障注入并明确定义混沌工程为借实验增强对容错机制信心的学科，直接支持该节点但现未引用。	为该节点补引 BK-023 第2章「容错」小节中的故障注入与混沌工程论述。
GAP-DDIA-005	应引未引	BK-023	Ch2.4	模块化与分解	该节点主张把系统分解为边界清晰、可独立变更的模块；DDIA 第2章把「拆成可相对独立运行的小组件」列为通用伸缩原则，同时强调分解边界的判断困难，直接支撑该节点但未被引用。	为该节点补引 BK-023 第2章「可伸缩性原则」小节。
GAP-DDIA-006	覆盖盲区	BK-023	Ch4.1	— 提案：ESS-H-10	DDIA 第4章系统讲解存储引擎与索引结构（日志结构存储、B 树、列式存储、二级索引与全文检索），并指出索引在读写之间的固有取舍。现有图谱缺少对应的存储引擎/索引本质节点。	新增节点（提案：ESS-H-10 存储引擎与索引结构，待评审）并补边至质量属性权衡相关节点。
GAP-DDIA-007	覆盖盲区	BK-023	Ch6.1	— 提案：MTH-G-07	DDIA 第6章比较单主、多主与无主三类复制算法，讨论同步/异步、故障切换、复制延迟、冲突处理与仲裁一致性等取舍。现有图谱在分布式数据复制域没有对应方法论节点。	新增节点（提案：MTH-G-07 数据复制策略，待评审）。
GAP-DDIA-008	覆盖盲区	BK-023	Ch7.1	— 提案：MTH-G-08	DDIA 第7章讨论分片（分区）的动机与代价、键范围与哈希分片、负载偏斜与热点缓解、再平衡与请求路由、以及二级索引的分片方式。现有图谱缺少数据分区与再平衡的方法论节点。	新增节点（提案：MTH-G-08 数据分区与再平衡，待评审）。
GAP-DDIA-009	覆盖盲区	BK-023	Ch8.2	— 提案：ESS-H-11	DDIA 第8章从事务 ACID 语义出发，系统讨论读已提交、快照隔离、丢失更新、写偏斜与幻读等异常，以及可串行化、两阶段锁、串行执行与分布式事务。现有图谱缺少事务与隔离级别节点。	新增节点（提案：ESS-H-11 事务与隔离级别，待评审）。
GAP-DDIA-010	覆盖盲区	BK-023	Ch10.1	— 提案：ESS-G-09	DDIA 第10章给出线性一致性的新鲜度语义、其与可串行化的区别、实现代价，并以逻辑时钟、全序广播、共识算法与协调服务展开分布式一致性与共识。现有图谱缺少该一致性模型与共识节点。	新增节点（提案：ESS-G-09 分布式一致性模型与共识，待评审）。
GAP-DDIA-011	覆盖盲区	BK-023	Ch11.1	— 提案：MTH-G-09	DDIA 第11、12章分别讨论批处理与流处理数据流：把输入视为不可变、以确定性纯函数派生输出，以及无界事件、事件时间与窗口、流连接与容错。现有图谱缺少批/流数据处理的方法论节点。	新增节点（提案：MTH-G-09 批处理与流处理数据流，待评审）。
GAP-DDIA-012	概念缺口	BK-023	Ch8.3	ESS-H-11	「可串行化快照隔离（SSI）」这一概念在图谱中缺失：它是在快照隔离之上做乐观冲突检测、以较小性能代价换取完整可串行化的并发控制机制，DDIA 第8章有专节论述。	新增节点（提案：ESS-H-12 可串行化快照隔离，待评审），并关联事务与隔离级别节点。
GAP-DDIA-013	概念缺口	BK-023	Ch10.3	增量演化与一致性治理	「全序广播」概念在图谱中缺失：决定事件全序的问题与共识等价，多数共识系统以共享日志形式提供全序广播，用于状态机复制与衍生数据一致性。该概念应在增量演化与一致性治理节点中补充。	新增术语条目并补挂至 MTH-O-10，说明全序广播与共识、状态机复制的关系。
GAP-DDIA-014	概念缺口	BK-023	Ch12.3	断路器与重试退避	「幂等性」与「确定性重放」概念在图谱中缺失：可安全重试、多次执行效果等同的操作是分布式与流处理容错的基础，也使基于日志的衍生数据在故障后可恢复。应在重试退避相关节点补充该概念。	新增术语条目并补挂至 TEC-K-01，说明重试与幂等性的配套关系。
GAP-DDIA-015	概念缺口	BK-023	Ch1.1	— 提案：ESS-H-13	「权威记录系统与衍生数据系统」这一对概念在图谱中缺失：按数据是否为首要权威源区分记录系统与派生系统，是梳理多组件数据架构数据流与集成方式的基本视角，DDIA 第1、13章反复使用。	新增节点（提案：ESS-H-13 记录系统与衍生数据，待评审）。
GAP-DSA-001	覆盖盲区	BK-013	Ch10.4.3	架构文档化方法	该书把架构文档与代码置于同一配置管理之下：文档要标注日期与版本号，翻看多张图时应能一眼判断它们是否出自同一系统版本；文档版本与代码版本还要能互相指认，即从代码出发能查证它对应哪一版架构。这一条把「文档化方法」从写什么推进到如何长期维持版本一致，属于文档化方法的运维侧内容。	在 MTH-G-05 下补一条工程类记录，锚定第 10 章该小节，写明文档纳入配置管理、文档与代码版本互相指认这两项要求。
GAP-DSA-002	覆盖盲区	BK-013	ChYour project’s development plan should specify the process for	架构文档化方法	该书主张架构文档也应有发布节奏：由项目开发计划规定维持文档最新的流程，架构师配合重大里程碑提前发布文档版本，给开发者留出把架构用起来的时间；发布节拍与项目早期迭代快、后期进入维护后转慢的规律相呼应，可把每次迭代或增量发布的收尾与文档改版绑定。	在 MTH-G-05 下补一条工程类记录，锚定第 10 章该小节，写明文档发布节奏与里程碑的绑定方式。
GAP-DSA-003	概念缺口	BK-013	Ch10.4.3	架构文档化方法	现有节点只覆盖「架构文档化方法」的产出结构，没有承载文档自身的版本管理这一维度。该书明确要求把文档当作软件一样纳入配置管理，并与代码版本互相指认，同时按项目节拍发布文档。若缺乏独立承载点，这类要求会被当成写作技巧而非可治理的工程实践，也难以与持续交付场景中的文档新鲜度问题对接。	考虑新建一个关于架构文档版本治理与发布节奏的节点，把配置管理、版本互指、里程碑发布三项要求归入，并与文档化方法节点建立关联。
GAP-DSA-101	覆盖盲区	BK-013	Ch6.5.2 A Template for Documenting Architectural Decisions	架构决策记录	既有节点把决策之间的关系笼统写成「用链接形成可追溯的决策图」，未登记该书给出的三类具体关系轴：因果（哪条决策引出了哪条）、结构（沿架构元素层级构成的父决策与子决策）、时间（决策之间的先后次序）。该书建议用追溯矩阵或决策树承载，也可用对象模型之类的图示表达复杂关系。缺少这三条关系轴，「决策图」只能表达取代关系，无法支撑跨层级的追责与影响回溯。	为 MTH-G-01 的 mechanism 段补引 BK-013 第6章该小节，登记因果、结构、时间三类决策关系及其可用载体（追溯矩阵、决策树、图示），作为取代关系之外的补充。
GAP-DSA-102	覆盖盲区	BK-013	Ch6.5.2 A Template for Documenting Architectural Decisions	架构决策记录	该书把「前提假设」设为决策记录的独立字段，并区分两类假设：关于环境的（环境中可用的东西、不变的前提，例如开发环境所具备的工具与团队技能水平）与关于需求的（为何所提供的设计足以满足需要）。其作用是让假设显式写出后可直接被复核其是否准确、是否仍然成立；相较之下，靠审读设计去反推假设要困难得多。既有节点只提到记录上下文与假设，未把假设拆成这两类，也未说明显式化假设对架构验证的作用。	为 MTH-G-01 补引 BK-013 第6章该小节所附建议框，把环境假设与需求假设的区分、以及「写下来才便于复核准确性」的验证作用登记为直接证据。
GAP-DSA-103	应引未引	BK-013	ChSection 5. Rationale	架构决策记录	该书把决策记录落到文档包的两个不同层次上：视图内部的理由一节只需交代本视图内设计为何如此，并论证其成立；而适用于多个视图的决策、组织或背景约束、以及影响全局的基本模式与风格选择，则归入跨视图的架构背景一节。既有节点覆盖了决策模板本身，却未登记「决策按影响范围分置两层」这一落地口径，读者因而无法判断某条决策应写进哪个位置。	为 MTH-G-01 的 engineering 段补引 BK-013 第10章视图模板的理由一节与跨视图的理由一节，登记「视图内理由 / 跨视图架构背景」两级归属口径。
GAP-DSA-104	应引未引	BK-013	Ch10.3 Documenting a Mapping to Requirements	架构决策记录	该书为决策到需求的对应关系给了一条可检查的完备性判据：每条架构决策至少要挂靠在一个要求之上，或至少能追溯到某位架构师；同时承认反向并不成立——并非每条决策都对得上一条明文要求。它主张建立需求与架构元素或决策之间的双向引用，使评审者能顺着业务目标走到技术决策、再回到该决策对目标的影响，并让架构师在被追问时能自证其取舍。既有节点提到决策要与需求建立映射，但未登记这条判据及其在评审中被用作核查项。	为 MTH-G-01 补引 BK-013 第10章该节，登记「每条决策至少挂靠一个要求或可追溯到架构师」的完备性判据及需求—决策双向引用在评审中的作用。
GAP-DSA-105	应引未引	BK-013	Ch11.2.2 Example Question Set for Supporting Evaluation	架构决策记录	该书把决策与理据是否被记录变成评审时可直接发问的检查项，并按不同评审目的分设问题：为支撑架构评估而审时，追问架构文档是否指出了关键决策及其所在位置、是否捕获了这些决策的理由；为支撑开发而审时，追问是否记录了关键决策与设计理据；为核对与 ISO/IEC 42010 的一致性而审时，追问文档是否包含架构决策的理由，包括视角与模型的选择、对应规则、以及各视图内关键决策的理由。既有节点未登记这条「以提问核验决策记录完备性」的评审路径。	为 MTH-G-01 补引 BK-013 第11章的示例问题集，登记三组以决策与理据为对象的评审提问及其对应评审目的。
GAP-DSA-106	概念缺口	BK-013	Ch6.4 Documenting Variation Points	架构决策记录提案：MTH-G-13	该书把变化点界定为架构中有意留待后续才定的决策：产品族共用一套架构时靠它派生出一族相似而结构不同的系统；有些系统的变化点甚至允许运行期改变基本结构。每个变化点需要写清留待决定的是什么、在哪些情形下采用哪一取值、以及这些取值之间如何相互制约。它与决策记录同属「决策」这一族，但记录对象恰好相反——不是已经作出的决定，而是被刻意推迟、连同允许取值一并存档的决定；既有节点只承载已作出的决策，无法容纳这一类对象。	提案新增节点「有意留待后续的决策项与变化点记录」，以 BK-013 第6章该节为直接信源，并与 MTH-G-01 建立并列或互补关系：MTH-G-01 管已作决策，本节点管被推迟的决策及其允许取值与约束。
GAP-EA-001	应引未引	BK-011	Ch1.4	增量演化与一致性治理	本书把演化式架构定义为「跨多个维度的、有引导的增量变更」，并在第1章逐段拆解这三段含义：变更须小步进行，且必须由客观机制引导，否则只剩被动应付式的改动；第3章再把增量变更区分为开发侧与部署侧两个面向。图谱该节点已主张用增量方式与校验机制治理演化中的一致性，却未引用本书这一原则的原始出处。	为该节点补引 BK-011 第1章定义段与 1.3/1.4 节，作为「有引导的增量变更」原则及其两段含义的来源。
GAP-EA-002	应引未引	BK-011	Ch3.2	部署流水线	本书把部署流水线确立为执行架构校验的载体：多阶段、逐级提升置信度，每次变更都统一触发原子级与整体级校验；并区分持续集成服务器与多阶段流水线在任务分离度与反馈质量上的差异，指出前者常不足以支撑架构级验证。图谱该节点的现有来源未包含本书。	为该节点补引 BK-011 第3章 3.2 节，作为「流水线作为架构校验执行机制」的出处，并补一条指向架构适应度函数节点的边。
GAP-EA-003	应引未引	BK-011	Ch7.16	遗留系统渐进治理	本书第7章把单体向服务化的迁移写成可执行步骤：先按业务功能、事务边界与部署目标确定服务边界，用内聚度度量（CK 度量族中的方法内聚缺失指标）判断共享模块应拆分还是复制，再分离界面层、引入服务发现与防腐层，并主张分若干轮渐进分解而非一次到位；同时提醒事务耦合往往比类级耦合更难拆。图谱该节点未引用本书。	为该节点补引 BK-011 第7章 7.12 与 7.15–7.17 节，作为迁移步骤与共享模块处置判据的来源。
GAP-EA-004	应引未引	BK-011	Ch5.6	领域驱动战略设计	本书把限界上下文与耦合局部性原则接在一起：把实现耦合限制在尽可能小的范围内，是限界上下文与耦合局部性两条线索共同指向的同一结论；第9章进一步给出在既有分层架构与集成架构中切出限界上下文、并用可执行校验阻止跨上下文耦合的具体做法。图谱该节点未引用本书。	为该节点补引 BK-011 第5章 5.6 节与第9章 9.21 节，作为限界上下文与耦合局部性同源的论证及落地做法来源。
GAP-EA-005	应引未引	BK-011	Ch5.15	内聚与耦合	本书把契约定义为架构各部分之间传递信息或依赖的格式，并给出从最严格（远程方法调用、附带模式的 JSON）到最宽松（纯名值对）的连续谱：越严格越使集成架构脆化，越宽松越需要另设校验来补偿确定性；同章还点出把消费方用不到的字段一并写进契约的邮票式耦合反模式。图谱该节点只给出耦合的一般判据，缺少契约松紧这一可操作维度。	为该节点补引 BK-011 第5章 5.15 节，补充契约松紧谱与邮票式耦合的判据。
GAP-EA-006	覆盖盲区	BK-011	Ch5.2	内聚与耦合	本书用五个小节展开「共生耦合」这一概念：把耦合细分为源码层的静态类型（名称、类型、含义、位置、算法）与运行时的动态类型（执行、时序、值、身份），并给出三个度量属性——强度（重构难度）、局部性（元素间距）、度（影响范围），配套「把强形式改成弱形式」「距离越远用越弱形式」两条改造规则，以及把跨封装边界的耦合降到最低、把封装内部的耦合提到最高的三条准则。图谱只有一般性的内聚耦合本质节点，没有这套可直接指导重构的耦合词汇表与判据。	新增节点（提案 MTH-H-05 共生耦合分析，待评审），补边至内聚与耦合本质节点、重构手法族节点与演进式架构节点。
GAP-EA-007	覆盖盲区	BK-011	Ch5.7	— 提案：MTH-G-10	本书定义「架构量子」为可独立部署、功能内聚度高、静态耦合高且运行时以同步耦合为主的单元，并把数据库、界面、编排器等共享耦合点一并计入量子边界：共用数据库或与界面强耦合会把分布式架构压回单一量子，只有互不共享耦合点时才形成多量子。量子大小决定增量变更的下限，量子数量与单位成本之间存在最优点，且不同量子可各自选择适配的技术架构与质量特性。图谱没有任何节点刻画这一结构单位及其计数与判定方式。	新增节点（提案 MTH-G-07 架构量子与量子粒度，待评审），补边至内聚与耦合本质节点、粒度与边界设定节点、演进式架构节点。
GAP-EA-008	覆盖盲区	BK-011	Ch5.11	— 提案：MTH-G-11	本书把量子之间的运行时耦合刻画为三个相互牵制的维度：通信取同步还是异步、一致性取原子事务还是最终一致、协调取编排还是协同；三者不能孤立决定，事务性偏向同步加编排，高规模偏向异步加最终一致加协同，取舍需放在同一决策空间里权衡。图谱缺少这一组运行时耦合的取舍框架，现有节点只覆盖质量属性层面的冲突治理与可靠性实现。	新增节点（提案 MTH-G-08 动态量子耦合三维决策，待评审），补边至架构量子节点、质量属性冲突治理节点与契约松紧相关节点。
GAP-EA-009	覆盖盲区	BK-011	Ch6.1	— 提案：MTH-L-08	本书用整章处理数据这一维度：模式变更应与代码同样受测、纳入版本控制、以小步迁移脚本增量施加，且迁移一经执行即视为不可改写，需以新增迁移而非修改历史迁移来撤销；把数据库当集成点会冻结模式，需借「扩展—收缩」过渡态（必要时加触发器做双向同步）化解；此外还讨论了两阶段提交、引用完整性、数据重复取舍、用代码替换触发器与存储过程、以及数据团队工程实践滞后的成因。图谱没有任何数据层演化节点，这一整类工程做法无处挂载。	新增节点（提案 MTH-L-08 演进式数据库设计与模式迁移，待评审），补边至演进式架构节点、增量演化与一致性治理节点、部署流水线节点。
GAP-EA-010	覆盖盲区	BK-011	Ch8.1	— 提案：MTH-L-09	本书用整章区分「陷阱」（看似可行却立刻显形）与「反模式」（起初像好主意、事后才发现是错的，且存在更好替代），并逐一给出会伤害可演化性的清单：低代码/无代码的最后百分之十陷阱、以厂商产品为架构中心、简历驱动开发、把共享组件养成瓶颈的复用反模式、因共享资源旧账而失当的治理、报表直接耦合到记录系统、为销售做无限定制与永久特性开关、过长规划周期与对手工文档的非理性依恋。图谱只有一般性的模式与反模式概念节点，没有这组针对可演化性的具体清单。	新增节点（提案 MTH-L-09 演化式架构反模式与陷阱，待评审），补边至设计模式与反模式本质节点、演进式架构节点与遗留系统渐进治理节点。
GAP-EA-011	覆盖盲区	BK-011	Ch4.1	— 提案：MTH-L-10	本书主张把架构治理从评审会与人工检查转为可执行校验：企业架构师不再指定技术选型，而是以校验机制约束平台能力与跨项目关切；安全等职能可在各项目流水线中保留自己的检查位，遇到零日漏洞时统一插入排查；同时提出「够用治理」——按简单、中等、复杂三档给出技术栈选项，让团队按问题规模选择，而不是在全组织统一技术栈上过度加码，也避免用统一选型把最复杂场景的负担压给所有项目。图谱缺少这一治理模型节点。	新增节点（提案 MTH-L-10 自动化架构治理与够用治理，待评审），补边至架构适应度函数节点、适应度函数工具化节点与部署流水线节点。
GAP-EA-012	覆盖盲区	BK-011	Ch7.23	— 提案：MTH-L-11	本书主张在某些情境下主动构建「用完即弃」的架构：先用最省资源的方式验证市场或概念，成功后再另建更合适的架构，而不去演化初版；书中以电商与社交产品的多次重写说明该策略对存活的价值，并把它列为不采用演化式架构的正当理由之一，同时提醒成功之后必须真正拨出资源重建，否则会长期停留在临时方案上。图谱的弃用与日落节点处理的是既有能力如何退场，缺少「一开始就计划替换」这一决策。	新增节点（提案 MTH-L-11 牺牲型架构，待评审），补边至弃用与日落策略节点、演进式架构节点与复杂度阶梯与演进时机节点。
GAP-EA-013	覆盖盲区	BK-011	Ch9.13	— 提案：MTH-O-12	本书把需求改写成可检验的假设：写清待验假设、验证实验与验证通过后的意义，再借助并行版本与流量路由做对照实验，让真实用户行为进入反馈闭环，而不是先收集需求再实现功能；并把校验机制当作实验媒介，用可量化指标回答架构假设（例如自定义监控丢失消息的比例、生产环境真实并发水位），据结果决定是否更换实现。图谱的度量与反馈闭环节点只覆盖指标驱动的闭环，没有假设与对照实验这一支。	新增节点（提案 MTH-O-12 假设驱动开发与实验性校验，待评审），补边至度量与反馈闭环节点、渐进暴露部署策略节点与架构适应度函数节点。
GAP-EA-014	覆盖盲区	BK-011	Ch4.4	— 提案：TEC-H-04	本书给出一组可自动校验的代码结构度量：传入与传出耦合、抽象度与不稳定度，以及由后两者合成的归一化「距主序列距离」，并用「无用区」与「痛苦区」解释偏离方向及其修复动作；还给出圈复杂度阈值与「渐进收紧」做法——先告警、后报错，让团队在受控节奏内偿还存量债务，并用 CK 度量族中的内聚缺失指标判断模块是否该拆分。图谱的技术债量化节点未覆盖这组结构度量与渐进收紧机制。	新增节点（提案 TEC-H-04 代码结构度量与渐进收紧治理，待评审），补边至静态分析平台节点、技术债量化度量节点与架构适应度函数工具化节点。
GAP-EA-015	覆盖盲区	BK-011	Ch3.4	— 提案：TEC-L-03	本书把「消费者驱动契约」当作集成架构上的原子校验：由消费方编写自己所需信息的测试并交给提供方，提供方承诺长期保持这些测试通过，于是可以在不破坏集成点的前提下任意演进内部实现；书中给出把设计期的接口描述校验、沙箱功能验证与跨服务契约验证串成多段流水线的完整示例，并把这类做法称为工程安全网。图谱没有契约测试或消费者驱动契约节点。	新增节点（提案 TEC-L-03 消费者驱动契约与契约测试，待评审），补边至部署流水线节点、架构适应度函数工具化节点与边界与接口隔离本质节点。
GAP-EA-016	概念缺口	BK-011	Ch7.22	边界与接口隔离	图谱缺少「防腐层」这一概念：本书主张在项目与外部库、消息中间件、厂商产品之间放一层隔离，把所需语义收敛到自己定义的接口上，使日后替换实现成为机械操作；并给出「即时防腐层」的做法——平时不必预先抽象，确需替换时再由工具抽出接口，以免为抽象而抽象反而损害可读性；第8章还把它列为摆脱厂商绑定反模式的对策。该概念应补挂在边界与接口隔离节点之下。	新增术语条目并补挂至 ESS-G-03，说明防腐层、即时防腐层与外部依赖替换成本之间的关系，并补边至抽象泄漏本质节点。
GAP-QASC-001	覆盖盲区	BK-036	Ch4.3	— 提案：MTH-M-07	语料把「同一失效被多个属性社群同时认领」和「四个社群各用一套词描述同一发生」并列为属性讨论的固有难题，并给出两条处置：以场景刻画属性、逐属性简述其底层关切。图谱现有节点未就「属性归属争议如何裁决、术语如何对齐」给出可操作方法。	新增方法论节点，收纳「关切重叠的消解」与「跨属性术语对齐」两条可执行做法，并与 MTH-M-06 建立关联边。
GAP-QASC-002	概念缺口	BK-036	ChAvailability Scenario	— 提案：MTH-M-08	语料区分系统无关的通用场景与绑定本系统的具体场景，并说明把前者转为后者才是获得需求的手段；还指出并非每条系统专属场景都要填满六个部分，必需项取决于用途与判定测试。图谱缺少「实例化与裁剪」这一步的独立节点。	新增机制类节点记录实例化步骤与「按用途裁剪六部分」的判据，并从 ESS-M-05 引一条关联边。
GAP-QASC-003	覆盖盲区	BK-036	ChQUALITY ATTRIBUTE SCENARIO GENERATION	功能与非功能需求分类	语料指出质量属性需求理论上应在需求获取阶段产出，实践中却很少被有纪律地获取与记录，并以此作为本章改用具体场景的动因。图谱在 MTH-F-05 下未记录这一「获取环节实际失效」的前提，容易把分类方法当作已被执行的现实。	补引至 MTH-F-05：增加一条关于质量诉求获取在现实中常被跳过的前提性记录，并说明补救手段。
GAP-QASC-004	概念缺口	BK-036	Ch4.3	— 提案：ESS-M-06	语料以三条编号问题说明既有属性讨论的缺陷（定义不具可操作性、关切归属争议、术语各行其是），并明确把场景作为前两条的解法。图谱缺少「场景表述法所针对的问题」这一前置说明，使该方法的适用理由无法被追溯。	新增概念节点，记录三条问题及其对应解法，并作为 ESS-M-05 的前置依据建立关联边。
GAP-REF-001	应引未引	BK-021	ChRefactoring Improves the Design of Software	软件演化定律	书中指出不重构则设计必然腐化：为实现短期目标或在不完全理解设计的情况下改动代码会使结构丢失，而且这种丢失有累积效应——越难从代码中读出设计就越难保住它、腐化得越快，定期重构才使代码保住形状。该论述是「软件演化定律」中复杂度持续上升、结构需要主动维护这一命题在代码层的直接表述，而 ESS-L-01 的规范信源未包含 BK-021。	为 ESS-L-01 补引 BK-021 第 2 章「Refactoring Improves the Design of Software」段，登记「结构丢失的累积效应」为该节点在代码层的直接证据。
GAP-REF-002	应引未引	BK-021	ChWhen Shouldn't You Refactor?	技术债本质	书中以 Ward Cunningham 的隐喻给出债务的三要素：未完成的重构即负债，负债带来利息即过于复杂的代码所增加的维护与扩展成本，公司需要一定负债才能高效运转但利息过重会被压垮，因此必须管理债务并分批偿还。这是技术债概念的经典出处之一，ESS-L-02「技术债本质」未收录 BK-021。	为 ESS-L-02 补引 BK-021 第 2 章该节，登记「未完成重构＝负债、复杂度＝利息、须分批偿还」三要素为直接证据。
GAP-REF-003	应引未引	BK-021	ChRefactoring and Design	战略式编程与持续设计投入	书中论述重构改变了前期设计的角色：设计压力来自「日后改设计很贵」，一旦重构使修改不再昂贵，前期设计就从「求出最优解」退为「得到合理解」，并因此转向更简单的设计。同时指出预置的灵活性本身有成本、且无法预测哪些真会被用到。MTH-H-03「战略式编程与持续设计投入」未收录 BK-021。	为 MTH-H-03 补引 BK-021 第 2 章「Refactoring and Design」段，登记「前期设计角色转变」「简单设计优先」「预置灵活性的成本」三条为直接证据。
GAP-REF-004	应引未引	BK-021	ChRefactoring and Design	理解成本优先的简单原则	书中给出一条可执行的简单性判据：面对潜在变化先问「把简单方案重构成灵活方案有多难」，多数时候答案是相当容易，于是直接实现能工作的最简单方案；并指出预置的灵活性会使整体系统更复杂、更难维护，而其中大部分根本用不上。MTH-O-09「理解成本优先的简单原则」未收录 BK-021。	为 MTH-O-09 补引 BK-021 第 2 章该段，把「能否重构过去」登记为选择简单方案的可操作判据。
GAP-REF-005	应引未引	BK-021	ChThe Rule of Three	准入与触发时机选择	书中给出一条具体的触发阈值启发式：第一次做某事就直接做，第二次遇到类似重复时皱眉但仍照做，第三次再遇到类似情形才动手重构（「事不过三」）。它把「何时该消除重复」从感觉转为可操作的次数判据，MTH-O-02「准入与触发时机选择」未收录 BK-021，且该节点现有内容未覆盖以重复次数为阈值的触发规则。	为 MTH-O-02 补引 BK-021 第 2 章「The Rule of Three」节，登记三次法则为重复类变更的触发时机判据；若该节点定位不含代码级触发规则，则考虑另立方法节点承载。
GAP-REF-006	应引未引	BK-021	ChRefactor As You Do a Code Review	代码复审与可读性治理	书中把重构作为代码评审的现场手段：评审者提出的意见若能当场重构实现，就能看到建议落地后的真实代码，从而产生原本想不到的第二层意见，评审也因此有更具体的产出；并建议代码评审保持小规模（一名评审者与原作者共同改码），大规模设计评审才另用图示与场景走查。MTH-H-04「代码复审与可读性治理」未收录 BK-021。	为 MTH-H-04 补引 BK-021 第 2 章该节，登记「评审即重构」「小规模评审组」为直接证据，并补一条指向重构手法族节点的边。
GAP-REF-007	应引未引	BK-021	ChChanging Interfaces	弃用与日落策略	书中给出接口变更的迁移套路：当重构涉及被外部无法改动代码使用的已发布接口时，须在一段时间内同时保留新旧接口，让旧接口转调新接口而不是复制方法体（复制会走向重复代码），并标记为弃用以便调用方知情；同时建议不要过早发布接口、并调整代码所有权规则以便利重构。MTH-L-07「弃用与日落策略」未收录 BK-021。	为 MTH-L-07 补引 BK-021 第 2 章「Changing Interfaces」段，登记「新旧接口并存＋旧接口转调＋弃用标记」为直接证据，并把「不要过早发布接口」补为该策略的前置条件。
GAP-REF-008	概念缺口	BK-021	ChIndirection and Refactoring	— 提案：ESS-H-15	图谱缺少「间接层」这一概念节点。书中以专节论述：多数重构其实是在增加间接层（把大对象拆小、大方法拆小），而间接层能换来四项收益——共享逻辑、把意图与实现分开表述、隔离变化、以多态表达条件逻辑；但每拆一层就多一个要管理的对象，层层委托还会降低可读性，因此还要能识别并移除已经不再回本的「寄生间接」。这一「收益与代价并存、需按回本与否取舍」的判断在图谱中无处承载。	新增 ESS-H-10「间接层与委托的成本收益」，收录四项收益、拆分的可读性与管理成本，以及寄生间接的识别与移除；与 ESS-H-01 信息隐藏、ESS-H-05 深模块与浅模块建立关系边。
GAP-REF-009	应引未引	BK-021	ChRefactoring and Performance	性能效率本质	书中先区分性能优化与重构（都不改变行为、目的不同），再给出可操作的性能工作法：多数程序把大部分时间耗在一小部分代码上，故应先写成结构良好、便于调优的软件，在开发后期用剖析器定位热点、以与重构相同的小步方式优化、每步之后编译测试并在无改善时回退；并批评「全体随时关注性能」的均匀优化浪费九成力气。ESS-M-03「性能效率本质」未收录 BK-021。	为 ESS-M-03 补引 BK-021 第 2 章「Refactoring and Performance」段，登记「先可调优再调优」「剖析驱动的后期小步优化」为直接证据。
GAP-REF-010	应引未引	BK-021	ChSpeculative Generality	复杂度阶梯与演进时机	书中批评为「将来某天可能需要」而预置的钩子与特例：若这些机制并未真正被使用，它们只会妨碍理解与维护，应当删除；并给出可操作的识别法——当某个方法或类的唯一使用者是测试用例时即可删除，另有无用参数、抽象命名等对应处置手法。MTH-O-08「复杂度阶梯与演进时机」未收录 BK-021，缺少这条「过早引入复杂度」的直接反面证据。	为 MTH-O-08 补引 BK-021 第 3 章「Speculative Generality」节，登记投机性泛化及其识别信号为该节点在重构语境的直接证据。
GAP-REF-011	应引未引	BK-021	ChFeature Envy	内聚与耦合	书中把「共同变化的东西应放在一起」写成方法归属的判据：若一个方法更关心别的类的数据，就把它移到数据所在处；并进一步要求发散式变化与霰弹式修改最终收敛为「常见变更与类之间的一对一映射」，即每类变更只改动一个类。ESS-H-02「内聚与耦合」未收录 BK-021，缺少这组可直接操作的内聚判据。	为 ESS-H-02 补引 BK-021 第 3 章「Feature Envy」「Divergent Change」「Shotgun Surgery」三节，登记「变更原因与类一对一映射」为直接证据。
GAP-REF-012	应引未引	BK-021	Ch4	可测试性本质	书中把可测试性直接写成重构的使能条件：「想重构，前提是有坚实的测试」，并补充即使有能自动完成重构的工具也仍然需要测试，因为不可能所有重构都被自动化；对既有的非自测试代码，须先把代码变成可自测的再重构。ESS-I-02「可测试性本质」未收录 BK-021。	为 ESS-I-02 补引 BK-021 第 4 章开篇，登记「测试是重构的前提条件」为直接证据，并补一条指向行为保持重构节点的边。
GAP-REF-013	应引未引	BK-021	ChThe Value of Self-testing Code	测试驱动开发	书中给出自测试代码与先写测试两项实践：测试须全自动并自行判定结果（把期望值写进测试并比较），失败与成功都自动报告；并指出最有用的写测试时机之一是在开始编码之前——先写测试等于先问清要做什么、聚焦接口而非实现，并以测试通过作为完成标志。MTH-I-03「测试驱动开发」未收录 BK-021。	为 MTH-I-03 补引 BK-021 第 4 章「The Value of Self-testing Code」节，登记「自测试代码」「先写测试」为直接证据。
GAP-REF-014	应引未引	BK-021	ChHow Mature Are These Refactorings?	设计模式与反模式	书中明确表述模式与重构的关系：模式是想要到达的形态，重构是从现状走到那里的路径；若干手法本身就是把模式引入系统的动作（以状态或策略取代类型码、形成模板方法），且目录尚未覆盖全部模式，这一缺口被作者点明。ESS-H-09「设计模式与反模式」未收录 BK-021，缺少「模式作为重构目标」这一关系表述的出处。	为 ESS-H-09 补引 BK-021 第 5 章该节，登记「模式＝目标、重构＝路径」为直接证据，并补一条指向重构手法族节点的边。
GAP-REF-015	应引未引	BK-021	ChThe Nature of the Game	遗留系统渐进治理	书中说明大型重构在生产系统上可能持续数月乃至数年：无法说服管理者停工集中清理，只能像啃面包屑一样今天一点、明天一点，按需推进、随时可停，并需全队对方向达成一致、各人的改动都朝同一方向；同时指出纠缠继承、过程式设计等大型重构缺少精确步骤，因为每个烂摊子都不一样。MTH-L-06「遗留系统渐进治理」未收录 BK-021。	为 MTH-L-06 补引 BK-021 第 12 章「The Nature of the Game」与「Four Big Refactorings」两节，登记「按需分次推进＋全队方向共识＋无精确步骤」为直接证据。
GAP-REF-016	覆盖盲区	BK-021	ChTechnical Criteria for a Refactoring Tool	— 提案：TEC-L-04	图谱缺少「自动化重构工具」节点，而书中以整章论述其技术条件与实践条件：技术上需要可全局检索的程序数据库与语法树，且必须承认完全保持行为不可能（如反射调用、实时约束下毫秒级差异）；实践上速度优先于边界完备、可撤销使探索式设计可行、必须集成进 IDE 否则无人使用。工具化的后果被明确推论为「设计错误成本下降，因此前期设计可以减少」。这些内容在图谱中无处承载。	新增 TEC-L-03「自动化重构工具」，收录程序数据库／语法树／行为保持的准确性边界／撤销／IDE 集成五项要件、核心收益「免除每步重测」，以及「工具化降低设计错误成本」的推论；与 MTH-H-01、MTH-L-01 建立关系边。
GAP-RI-001	应引未引	BK-024	Ch3	错误、缺陷与失效	第3章以独立术语条目给出「故障—错误—失效」的三层定义与递进关系：故障使软件内部状态变错，错误是可被看见的不正确行为，失效是系统不再响应；故障被触发打开裂纹，故障变错误、错误再引发失效。这正是 ESS-I-03 所主张的区分，但该节点未把 BK-024 列为信源。	把 BK-024 第3章「Chain of Failure」补入 ESS-I-03 的规范信源与书证核验行，并用该书的三层定义作为术语区分的书证。
GAP-RI-002	应引未引	BK-024	Ch6	可靠性即风险管理	第6章引述面向恢复的计算（ROC）三条立论——硬件与软件的失效都不可避免、建模与分析永不完备因而无法先验预测全部失效模式、人的操作是主要失效来源——并明确其路线与「消除失效根源」的传统可靠性研究相反。ESS-K-01（可靠性即风险管理）正需要这类「失效不可消除、故须持续管理」的书证，但未引用 BK-024。	将 BK-024 第6章「Recovery-Oriented Computing」补入 ESS-K-01 的信源与书证核验行，作为「以风险管理替代消除失效」的直接依据。
GAP-RI-003	应引未引	BK-024	Ch5	可用性战术应用	第5章「Bulkheads」给出把容量按调用方、功能或拓扑切分以在故障中保住部分功能的可用性战术，并指出虚拟机冗余弱于物理机冗余（多数虚拟化工具无法强制物理隔离，多个虚拟机可能同处一台物理机）。MTH-M-03（可用性战术应用）未引用 BK-024，缺了这条关于资源隔离与损害封堵的经典战术来源。	把 BK-024 第5章「Bulkheads」补入 MTH-M-03 信源，并在资源隔离类战术条目下补充该书关于分区依据与伪冗余风险的论证。
GAP-RI-004	应引未引	BK-024	Ch5	可靠性与可用性	第5章「Let It Crash」给出以组件级不稳定换取系统级稳定的做法：崩溃必须被限制在边界内，重启要快，监督树负责决定重启范围、必要时让监督者自身崩溃以免掩盖根因，且组件恢复太慢时（如老式 JavaEE 单体）该策略并不适用。ESS-M-04（可靠性与可用性）未引用 BK-024，缺这条崩溃、监督与重入的可用性机制书证。	考虑把 BK-024 第5章「Let It Crash」补入 ESS-M-04 的书证；或在 MTH-M-03 中作为可用性战术（故障检测/恢复准备/重新引入）的实例引用。
GAP-RI-005	应引未引	BK-024	Ch4	容量规划与变更管理方法	第4章「Unbalanced Capacities」与「Scaling Effects」指出容量失衡是缩放效应的特例：流量模式一变（季节、市场或宣传驱动），平时无害的前端会突然淹没后端；应对需要调用方用断路器卸压、提供方用握手与背压让调用方减速，并用舱壁为关键调用方预留容量。MTH-K-07（容量规划与变更管理方法）未引用 BK-024，缺这条容量失衡与削峰的书证。	把 BK-024 第4章「Unbalanced Capacities」与「Scaling Effects」补入 MTH-K-07 信源，并在容量规划正文中补入「前端突增淹没后端」的失效模式及三层应对。
GAP-RI-006	应引未引	BK-024	Ch10	事件响应与无指责复盘方法	第10章分析 AWS S3 事故复盘时强调全文没有出现「人为错误」一词：这不是人辜负了系统，而是系统辜负了人——管理工具与操作手册放大了一次误输入，因此必须定性为系统失败。书中还主张对成功的变更也做复盘、找出险肇事件并追问当时是什么安全网拦住了它。MTH-K-05（事件响应与无指责复盘方法）未引用 BK-024。	把 BK-024 第10章「System Failure, Not Human Error」补入 MTH-K-05 信源，并在无指责原则下增补「对成功变更复盘、追查险肇事件」这一条目。
GAP-RI-007	应引未引	BK-024	Ch10	无指责复盘实践	第10章指出一次公开复盘应完成三件事：说明发生了什么、致歉、承诺改进，并以 AWS 的公开复盘写作为正面范例。TEC-K-05（无指责复盘实践）作为落地实践节点，未引用 BK-024 这条关于复盘产出与对外沟通的实践书证。	把 BK-024 第10章「Mechanical Advantage」补入 TEC-K-05 信源，并把「说明经过／致歉／承诺改进」三要素纳入复盘文档模板。
GAP-RI-008	应引未引	BK-024	Ch5	测试替身与测试策略	第5章「Test Harnesses」给出测试夹具与 mock 对象的关键差别：mock 只能按已定义接口产生行为，而夹具作为独立服务器不受接口约束，可制造连接被拒、连上后不发数据、只回 RESET、接收窗口打满却不排空等网络与协议级故障，用来验证系统在依赖脱规格时的行为。MTH-I-05（测试替身与测试策略）未引用 BK-024。	把 BK-024 第5章「Test Harnesses」补入 MTH-I-05 信源，并在测试替身谱系中补入「跨进程、可违反协议约定」的夹具这一档及其适用场景。
GAP-RI-009	应引未引	BK-024	Ch4	开发生产一致性	第4章「Scaling Effects」指出开发环境每个应用一台机、QA 至多一两台，而生产里应用尺寸跨度极大，缩放效应因此很难在测试环境看到，这类缺陷测不掉、只能设计掉；第17章进一步说明暂存环境永远不会是生产的全尺寸副本，因而难以从非生产环境获得对整体系统的理解。ESS-J-02（开发生产一致性）未引用 BK-024 这条关于规模不一致的论证。	把 BK-024 第4章「Scaling Effects」与第17章相关段落补入 ESS-J-02 信源，作为「一致性无法靠复制环境达成、需以设计消解」的书证。
GAP-RI-010	应引未引	BK-024	Ch17	可回滚性与爆炸半径控制	第17章把爆炸半径界定为坏体验的量级——既看受影响客户的数量，也看他们被打扰的程度——并指出要按一组准则挑选受害者，从「每一万个请求失败一个」这类简单规则起步再逐步精细化。MTH-J-07（可回滚性与爆炸半径控制）未引用 BK-024，缺了该书对爆炸半径的双维度定义与选靶做法。	把 BK-024 第17章「Prerequisites」补入 MTH-J-07 信源，并采用其爆炸半径双维度（受影响人数 × 受扰程度）作为度量口径与选靶准则。
GAP-RI-011	应引未引	BK-024	Ch13	不可变基础设施实现	第13章论述不可变基础设施：机器部署后不再变更，需要改动的做法是更新自动化脚本并构建新镜像、随后删掉旧机器；其优势在于每次都从已知状态出发，而不必从不明现状收敛，从而避开长期存活机器上配方管不到的隐状态（如内核参数与 TCP 超时）。TEC-J-02（不可变基础设施实现）未引用 BK-024。	把 BK-024 第13章「Automated Deployments」补入 TEC-J-02 信源，并在实现要点中补入「收敛式 vs 不可变式」的对比论证与隐状态风险。
GAP-RI-012	应引未引	BK-024	Ch5	可观测性信号采集	第5章要求断路器状态变化始终被记录、当前状态可查询可监控，并把状态变化频率视为值得趋势化的领先指标；第13章进一步要求健康检查页报告应用版本、运行时版本、主机 IP 以及连接池、缓存与断路器的状态。TEC-K-02（可观测性信号采集）未引用 BK-024，缺了「熔断、资源池与缓存状态作为可采集信号」这条具体埋点清单。	把 BK-024 第5章「Circuit Breaker」与第13章「Rollout」补入 TEC-K-02 信源，并把健康检查页的字段清单纳入信号采集清单。
GAP-RI-013	应引未引	BK-024	Ch5	自动化方式选择	第5章「Governor」与第10章指出自动化没有判断力、出错时极快，等人察觉时往往已进入恢复而非干预阶段；因此应在不安全方向上施加阻力（关停、删除、阻断这类动作要放慢），给人类留出干预时间，并让动作在超出安全区间后遭遇递增阻力。MTH-O-07（自动化方式选择）未引用 BK-024。	把 BK-024 第5章「Governor」与第10章「Mechanical Advantage」补入 MTH-O-07 信源，并把「自动化负责重复任务与快速响应、人负责全局态势感知」的分工纳入选择准则。
GAP-RI-014	应引未引	BK-024	Ch13	渐进暴露部署策略	第13章「Rollout」给出分批滚动更新的完整节奏：先让一批停止接新请求、等负载排空、更新代码与配置、等健康检查全绿、再恢复接流，然后逐批重复；首批应作为金丝雀并暂停评估，在负载均衡器上做流量整形逐步放量，同时盯错误日志、延迟与内存指标的异常，一旦异常就切走流量再排查。MTH-J-05（渐进暴露部署策略）未引用 BK-024。	把 BK-024 第13章「Rollout」补入 MTH-J-05 信源，并把「停流—排空—更新—健康检查—恢复」的批次步骤与金丝雀暂停评估纳入策略描述。
GAP-RI-015	应引未引	BK-024	Ch16	演进式架构	第16章「Evolutionary Architecture」引用 Ford 等人的定义（把跨多个维度的增量、受引导的变更作为首要原则），并指出让演进式架构奏效的关键反而在于失败——必须对同类问题尝试不同做法并淘汰较差者，让技术单元与业务能力的小颗粒各自成功或失败，从而使组织获得适应性。MTH-L-04（演进式架构）未引用 BK-024。	把 BK-024 第16章「Evolutionary Architecture」补入 MTH-L-04 信源，并把「以小颗粒独立成败换取适应性」作为该方法的支撑论据与判据来源。
GAP-RI-016	概念缺口	BK-024	Ch4	— 提案：TEC-K-07	全书第4章系统给出了一整套稳定性反模式（集成点、连锁反应、级联失效、用户与流量冲击、阻塞线程、自我拒绝攻击、缩放效应、容量失衡、惊群、慢响应、无界结果集），第5章再以稳定性模式逐一对治。当前图谱只在技术层有断路器与混沌实践等零散节点，没有承载「反模式—模式」这对成体系结构的节点，导致该书的稳定化主线无处挂载。	新增一个方法层或技术层节点承载稳定性反模式体系，把第5章的稳定性模式（超时、断路器、舱壁、稳态、快速失败、握手、背压、卸载、调速器、解耦中间件、测试夹具、让它崩溃）作为其对策清单，并与 TEC-K-01、TEC-K-04 建立关系边。
GAP-SAIP-001	应引未引	BK-009	Ch3.4	架构风格	该书以专节讨论架构模式与风格如何打包战术并影响多个质量属性，而现有节点「架构风格」未把该书列为其信源，属应补引的漏引。	在 ESS-G-05 的规范信源中补充 BK-009，并补一条指向该书第3章的直接证据。
GAP-SAIP-002	应引未引	BK-009	Ch22.3	架构文档化方法	该书第22章系统论述架构文档化（视图、跨视图信息与理由记录），是架构文档化方法的核心来源，但节点 MTH-G-05 未将该书列为其直接信源。	在 MTH-G-05 中补引 BK-009 第22章，并标注视图组织与理由文档化的直接证据。
GAP-SAIP-003	概念缺口	BK-009	Ch19.1	— 提案：MTH-F-07	该书把「架构上重要的需求」提升为独立主题，论述从需求文档、干系人访谈与业务目标三条途径收集 ASR，并指出其驱动架构决策；现有 167 节点中缺少该概念节点。	新增节点 ASR，挂接现有需求工程节点（MTH-F-01..06）与 MTH-G-02，补入其与该书的边。
GAP-SAIP-004	概念缺口	BK-009	Ch20.1	— 提案：MTH-G-12	该书以整章给出属性驱动设计的七步迭代流程，把驱动转化为结构与接口；现有图中只有战术映射与 ATAM 评估，缺少这一与评估配对的架构设计方法节点。	新增节点 ADD，作为 MTH-G-02（评估）与 MTH-M-01（战术映射）的伴生设计方法，并补入与该书的边。
GAP-SAIP-005	覆盖盲区	BK-009	Ch10.2	质量属性战术映射方法	该书对可用性、可部署性、能效、可集成性、安全性、保密性、可测试性、易用性各设独立章节并给出战术集；现有图仅覆盖可用性、可修改性等少数属性的战术应用节点，安全、能效、可部署性、可集成性、易用性等属性缺乏对应的战术应用节点。	以 MTH-M-01 为母节点，为缺失属性补充战术应用子节点（或扩展现有 MTH-M-01 的细化边），至少覆盖安全、能效、可部署性、可集成性与易用性。
GAP-SAIP-006	应引未引	BK-009	Ch23.1	技术债象限与偿还策略	该书第23章专论架构债的识别、热点发现与自动化治理，与技术债相关节点高度相关，但 MTH-L-03 未把该书列为其信源，且「架构债」作为技术债在架构层的特定形态未被单独刻画。	在 MTH-L-03 补引 BK-009 第23章；如需要，可另立「架构债」节点以区别于一般技术债。
GAP-SAIP-007	概念缺口	BK-009	Ch24.3	团队边界治理	该书第24、25章讨论架构师在项目中的角色（与项目经理分工、增量架构、敏捷与分布式开发）以及个人与组织的架构能力建设，现有图在团队与康威域有组织节点，但缺少「架构师角色/架构能力」这一角色与能力维度节点。	新增节点「架构师角色与架构能力」，挂接 ESS-N-* 团队域与 MTH-N-* 方法论节点，并补入与该书的边。
GAP-SRE-001	应引未引	BK-025	ChBlack-Box Versus White-Box	可观测性信号关联方法	第6章把观测手段按位置分为两类：一类依据系统内部暴露的指标与日志，另一类只按用户可见的外部行为试探；并写明前者能发现迫近隐患与被重试掩盖的失败，后者只反映已经发生且构成真实症状的问题。同章还指出同一现象在不同层级会由症状变为成因，第10章进一步说明只看内部视角会漏掉未抵达目标与随崩溃消失的请求。该节点主张的正是多类信号须组合关联，却未把 BK-025 列入信源。	把 BK-025 第6章「Black-Box Versus White-Box」与第10章「Black-Box Monitoring」补入 MTH-K-04 的信源与书证核验行，作为两类观测视角须组合使用的书证。
GAP-SRE-002	应引未引	BK-025	ChDefinitions	可观测性本质	第6章以相邻条目给出监控、内部暴露型与外部试探型三个术语的界定，并交代监控涵盖实时定量数据的采集、加工、聚合与呈现；第10章则说明在如此体量下为单机故障告警会因噪声过大而无法据以行动，需聚合信号并剪除离群值，同时保留下钻到单个组件的粒度。该节点虽已列出 BK-025，但缺少与这两章对应的书证核验行。	为 ESS-K-03 补上 BK-025 第6章「Definitions」与第10章开篇的书证核验行，用以支撑观测视角的界定与规模化聚合粒度这两条论断。
GAP-SRE-101	应引未引	BK-025	ChThe Role of a Release Engineer	DORA 交付指标	本书只在发布工程一章提到从改动到上线所花的时间以及修复时长、故障间隔等零散指标，通篇没有引用交付效能领域那套被广泛使用的四指标研究框架，也没有把「变更失败率」与「部署频率」作为成对指标提出。因此以该框架为知识来源的节点，无法从本书取得对其指标集合本身的引证。	BK-025 只零散给出发布速度、修复时长与故障间隔，未引用该四指标框架；故 TEC-K-06 的指标集合本身不宜以本书为出处，只可补引其发布工程相关分节。
GAP-SRE-102	覆盖盲区	BK-025	ChChange Management	可回滚性与爆炸半径控制	关于可回滚性与损坏范围控制，本书给足了定性做法（渐进铺开、金丝雀、自动回退、开关撤回），但没有任何把「暴露面」量化的口径：既没有给出受损用户数或受损请求比例的计算式，也没有给出回退决策的阈值标准。相关节点若需要可度量的判据，本书无法提供。	BK-025 对可回滚性只给定性做法、未给暴露面量化口径；MTH-J-07 的可度量判据须另寻出处，本书仅补引其定性做法。
GAP-SRE-103	覆盖盲区	BK-025	ChAuxon	容量规划与变更管理方法	本书对容量规划有一处专门的工程化实现（以意图描述资源需求、求解线性或整数规划并输出分配方案），但该内容集中在一个独立的软件工程案例章里；容量规划主题所覆盖的负载均衡与过载处置各章只讨论供给信号的选择与配额限流，未涉及这套意图驱动的方法。按既定章节取证据时会漏掉该实现。	BK-025 的意图驱动容量规划实现集中在第18章 Auxon 案例，按主题章节取证会漏掉；MTH-K-07 补引时应显式覆盖该案例章。
GAP-SRE-104	概念缺口	BK-025	ChDefinitions	可观测性信号采集	可观测性信号采集在本主题章节内只有面向人与监控系统两类的信号划分，缺少机器可读的追踪数据形态：没有讨论按单次请求串联调用链的追踪、跨服务上下文传播，也没有给出追踪与指标在采样策略上的取舍。若要覆盖这一维度，本书在本主题章节内不构成依据。	BK-025 在本主题章节内只论指标与告警，未涉及调用链追踪与上下文传播；TEC-K-02 的追踪维度不能以本书为依据。
GAP-SRE-105	概念缺口	BK-025	ChForming Your Error Budget	错误预算政策与燃尽率告警	本书把错误预算的讨论限定在季度粒度上，并明确谈到用放慢发布或回退来应对预算接近耗尽，但没有引入预算消耗速率这一动态量，也没有讨论按消耗快慢决定是否冻结发布的判据。以多窗口预算或燃尽速率为内容的节点，在本书中找不到对应论述。	BK-025 只按季度粒度讨论错误预算，未引入消耗速率或多时间窗判据；MTH-K-02 的燃尽率部分不能以本书为依据。
GAP-SREW-001	覆盖盲区	BK-026	ChDependencies	可观测性信号采集	本书没有为四黄金信号设立专节，只在监控与依赖埋点两处顺带提及该概念，饱和度虽有独立小节却未与其余三项合成完整体系；因此本节点内可标为单节直陈的条目偏少，四项信号的完整定义与相互关系需借第4章多处文字乃至第一本 SRE 书才能补齐。	BK-026 未为四大黄金信号设立专节，只在第4章「Dependencies」与监控相关小节顺带提及，饱和度虽有独立小节却未与其余三项合成体系；故 TEC-K-02 的完整信号体系不宜以本书为单一出处，只可补引其监控与饱和度分节。
GAP-SREW-101	覆盖盲区	BK-026	ChSources of Monitoring Data	可观测性信号采集	本书在讨论可观测性信号时只深入展开指标与结构化日志两类来源，明确把分布式追踪与运行时内省排除在章节范围之外，因此关于链路级追踪与运行时状态的采集方法在本书中缺少可引用的展开，节点在该维度的覆盖需要另找来源。	BK-026 明示不覆盖分布式追踪与运行时内省；TEC-K-02 的链路级追踪维度不能以本书为依据，只可补引其监控数据来源分节。
GAP-SREW-102	覆盖盲区	BK-026	ChMove Fast by Reducing the Cost of Failure	DORA 交付指标	与交付效能直接对应的四项行业通行指标（部署频率、变更前置时间、变更失败率、平均恢复时间）在本书中没有被并列定义或成体系地讨论，书中只在与 DevOps 对比时谈到度量流程产出、反馈回路时长与缩短平均修复时间带来的速度收益，并把相关研究书目列入延伸阅读，因此该节点的指标口径无法在本书内部完整闭合。	BK-026 未并列定义四项交付效能指标；TEC-K-06 的指标口径不能以本书闭合，只可补引其反馈回路与修复时长论述。
GAP-SREW-103	覆盖盲区	BK-026	ChRelease Engineering and Canarying	金丝雀发布	金丝雀评估的判定方法在本书中停留在流程与经验层面：作者明确表示不深入统计学，只讨论整体流程与实务考量，因此样本量估算、显著性判定、误判概率控制等量化判据在本书中缺失，节点若需要可复核的判定阈值须依赖外部资料。	BK-026 明确不深入统计学；TEC-J-04 的样本量与显著性判据须另找来源，只可补引其金丝雀流程与实务考量。
GAP-SREW-104	概念缺口	BK-026	ChFrom Load to Overload	容量规划与变更管理方法	本书第17章标题指向过载的识别与恢复，但正文讨论的是团队运维负荷意义上的过载及其心理影响，而非系统层面的过载判定与恢复；系统侧的降载、优雅降级、限流与容量腾挪分散在第11章与第12章，因此「容量规划与变更管理」节点若要从本书取得系统过载恢复的完整链条，必须跨章拼接，单章无法自洽。	BK-026 第17章的「过载」指团队运维负荷而非系统过载；MTH-K-07 的系统侧过载恢复链条须跨章拼接，单章不自洽。
GAP-SREW-105	应引未引	BK-026	ChDependencies	可观测性信号采集	本书在给出依赖监控建议时要求读者参照四大黄金信号来挑选指标，却没有在本书内定义这四类信号，其定义只存在于前作；因此该建议在本书范围内缺少自洽的概念锚点，节点引用时需注明定义出处或改用本书内的等价表述。	BK-026 只要求参照四大黄金信号却未在本书定义；TEC-K-02 引用本书时须注明定义出处或改用本书内等价表述。
GAP-SWEG-001	应引未引	BK-001	ChThe Limits of Automated Testing	测试类型	第11章单列一节交代自动化测不了什么：搜索结果好坏、音视频质量这类判断依赖人的主观评估，复杂安全漏洞的搜寻也是人比自动系统更强。该书把这类做法统称探索性测试，并把它定性为创造性的活动——被测应用被当成一道待破解的谜题，可能走一串意料之外的步骤，也可能塞进意料之外的数据；开跑时并不知道要找什么问题，问题是在反复试探被忽略的路径与异常响应中逐步浮出来的。由此还派生出两条工程约束：人类测试者的力气应集中投在自动化难以覆盖的地方，而探索性测试一旦抓到问题，就应立刻补一个自动化用例防它回归。第14章又把探索性测试列入大型测试类型，补充了它以人工方式验证、适合新系统与已上线系统、以及人工验证不具备次线性扩展能力等特性。图谱的测试类型节点把经验型技术（含探索性测试）列为与黑盒白盒并列的一类，却未收录这组「何时必须交给人」的边界与探索性测试的定义。	为 MTH-I-02 补引 BK-001 第 11 章「The Limits of Automated Testing」与第 14 章「Exploratory Testing」，登记「自动化不适用场景 + 探索性测试定义 + 发现即固化回归用例」为该节点在经验型测试类型上的直接书证。
GAP-SWEG-002	应引未引	BK-001	ChTest sizes in practice	测试层次	第11章给出可强制执行的测试体量约束，并附带一项图谱未记的事实：Google 内部其实分四档——小、中、大、超大；大与超大的内部差别细微且属历史沿革，故书中所述的「大」多数对应其内部的「超大」。强制手段有实例：Java 测试统一跑在自定义安全管理器下，被标为小测试的用例一旦试图做禁止之事（例如建立网络连接）就直接失败；小测试的豁免也有限度，若用内存中的自足实现，仍可访问文件系统。第11章另给出体量的资源与时间边界，第14章则列出大测试的典型特征：默认超时十五分钟或一小时、也有跑数小时乃至数天的，可以是非自足的、也可以是低确定性的。图谱的测试层次节点已有体量与范围两轴的定义及三档约束，但未收录这组「约束被基础设施强制」的落地证据与四档事实。	为 MTH-I-01 补引 BK-001 第 11 章「Test Size」与「Test sizes in practice」，登记可强制执行的体量约束与「小/中/大/超大四档」为该节点在体量轴上的直接书证；大测试的超时与不确定性边界可一并引第 14 章「What Are Larger Tests?」。
GAP-SWEG-003	应引未引	BK-001	ChRecord/replay proxies	测试替身与测试策略	第14章给出一种把大型测试转成小型测试的做法：在大型测试中对子服务发起的流量记录下来，供小测试回放使用。录模式测试持续在提交后运行，主要目的是生成这些流量日志（它本身必须通过，日志才会被生成），回放模式测试则用于开发与提交前阶段。由于不确定性，请求要靠匹配器决定回放哪条响应，其机制与桩和模拟相近。当请求不再匹配已有记录时，工程师必须回到录模式重新生成流量，因此让录模式测试易运行、快且稳很关键。该小节同时交代了另一种做法——消费方驱动契约测试：由客户定义服务模拟，真实服务再用这些输入输出对做测试；并列出 Pact 与 Spring Cloud Contracts 两个公开工具，说明 Google 因大量依赖 protocol buffers 而未在内部采用。图谱的测试替身节点涵盖假件、桩与交互测试三类技术，但未承载「整服务级替身」与录放式代理这组机制。	为 MTH-I-05 补引 BK-001 第 14 章「Record/replay proxies」，登记服务级替身、录模式生成流量与回放模式复用、以及消费方驱动契约测试为该节点在替身技术谱系上的直接书证。
GAP-SWEG-101	应引未引	BK-001	ChPsychological and Cultural Benefits	代码复审与可读性治理	本书把代码评审的心理与文化作用单列成节：把评审作为制度化的例行环节，可以让批评以中性的方式提出，新成员更容易把它读成团队期待而非个人差评；同时评审本身提供了被认可的机会，缓解能力越强越容易自我怀疑的处境。这一层组织心理维度在既有节点中未被登记。	为 MTH-H-04 补引 BK-001 第9章该节，登记「制度化的例行评审缓和批评的人际张力」「评审提供认可与激励」为直接证据。
GAP-SWEG-102	概念缺口	BK-001	ChProduction testing	持续集成服务与流水线提案：TEC-I-04	本书主张把同一套自动化测试一路延伸到最终部署环境：对生产重复执行与候选制品相同的测试集，既核验生产按测试口径是否处于可用状态，也反向核验测试集是否仍与生产相关。这种部署后持续探测的做法与既有节点所覆盖的「构建—提交前—提交后」验证链路并不重合，缺少承载节点。	提案新增节点「生产环境探针式回归验证」，以 BK-001 第23章该节为直接信源，并与 TEC-I-01 建立部署后验证阶段的细化关系。
GAP-SWEG-103	概念缺口	BK-001	ChQuery independent signals	— 提案：TEC-H-05	本书把代码检索的排序信号拆成两类：一类与查询无关、可离线批量计算（文件被查看次数、被引用次数等，其中引用信号借用了网页排名的思路）；另一类随查询变化、必须在线廉价计算。文中还指出「查看次数」会形成自我强化的回路，使新文件因缺少历史数据而难以被排到前列，属于既有节点未覆盖的检索可发现性议题。	提案新增节点「代码检索排序信号与可发现性」，以 BK-001 第17章「Ranking」相关小节为直接信源，登记查询无关与查询相关两类信号的划分及其副作用。
GAP-TFA-001	应引未引	BK-031	ChXI	可观测性信号采集	第 XI 章把日志界定为按时间聚合的事件流，并给出一条职责划分式的工程约束：应用不负责自己输出流的路由与存储，不得去写或管理日志文件，而是由每个进程把事件流不带缓冲地写到标准输出；在预发与线上，这些流由执行环境捕获、与其他流汇聚后投递到一个或多个目的地，归档目的地对应用既不可见也不可配置。图谱的可观测性信号采集节点把日志列为三类信号之一并强调结构化与上下文关联，却未收录这条「日志归执行环境、应用只写标准输出」的边界。	为 TEC-K-02 补引 BK-031 第 XI 章，登记「日志即事件流、应用不承担路由与存储」为该节点在信号采集侧的直接书证。
GAP-TFA-002	应引未引	BK-031	ChIX	可用性战术应用	第 IX 章把进程的可丢弃性写成一组可用性约束：启动要尽量快，以便发布与扩容更敏捷、也便于进程管理器把进程迁到别的机器；收到终止信号后要优雅退出——停止监听端口、让在途请求做完再退出，工作进程则把当前任务退回队列并释放锁；这隐含要求任务可重入或幂等；此外还要接得住硬件失效导致的突然死亡。图谱的可用性战术应用节点覆盖检测、恢复与预防三类战术，却未收录这组面向进程生命周期的具体约束。	为 MTH-M-03 补引 BK-031 第 IX 章，把快速启动、优雅退出、任务可重入与崩溃容忍登记为进程层面的可用性战术书证。
GAP-TFA-003	覆盖盲区	BK-031	ChVIII	— 提案：MTH-J-08	第 VI 章与第 VIII 章合起来给出一套进程模型：进程无状态且彼此不共享，需要留存的数据一律放进有状态的后端服务，内存与文件系统只配当单次事务的临时缓存（会话粘滞因此被禁止）；并发靠按工作类型划分进程种类、再横向增加进程来扩展，进程种类与各类进程数量的组合被称为进程编队；进程不得自行守护化或写 PID 文件，输出流、崩溃重启与启停都应交给操作系统的进程管理器。图谱没有任何节点承载这套「无状态进程 + 进程编队 + 交给进程管理器」的模型。	新增节点（提案 MTH-J-06 无状态进程模型与进程编队，待评审），补边至构建发布运行分离节点与不可变基础设施节点。
GAP-TFA-004	概念缺口	BK-031	ChVII	— 提案：MTH-J-09	第 VII 章主张应用自足地导出服务：不依赖运行环境在运行时注入 Web 服务器，而是以依赖声明引入服务器库、自行绑定端口并监听请求；本地开发直接访问该端口，线上则由路由层把公开域名转接到端口进程。该章还指出端口绑定不限于 HTTP，任何服务器软件都能这样导出，并因此让一个应用可以充当另一个应用的后端服务——只需把对方地址作为资源句柄写进配置。图谱缺少这一「服务导出契约」概念。	新增节点（提案 MTH-J-07 服务自足导出与端口绑定，待评审），补边至配置外置与显式化节点、部署流水线节点。
GAP-TT-001	应引未引	BK-030	Ch2	逆向康威操作	该节点主张主动调整团队与组织结构，使沟通结构先于软件成形而对应目标架构。本书第2章以专节论述这一手法的动机、操作步骤与组织阻力，并引证同行的大样本研究说明高绩效组织普遍采用，可作为该节点最直接的上游出处，但图谱现未引用本书。	为该节点补引 BK-030 第2章，作为逆向康威操作的定义、实施路径与效果证据来源。
GAP-TT-002	应引未引	BK-030	Ch7	团队交互模式	该节点把团队间交互归纳为限时高带宽协作、清晰边界的服务消费与教练式促进三种模式。本书第7章为这三种模式各设专节，给出适用情境、对应的团队行为风格、优势与代价，并指明四类团队各自的主要交互组合，是该节点的原始来源，图谱却未引用。	为该节点补引 BK-030 第7章，作为三种交互模式的定义、行为规范与选择判据来源。
GAP-TT-003	应引未引	BK-030	Ch5	平台团队与最薄可行平台	该节点要求以产品方式经营平台团队，把通用能力封装为可自助使用的内部产品以降低流对齐团队的认知负荷。本书第5章平台团队一节界定了该团队类型的使命、期望行为与「平台刚好够大」的规模判断，并指出平台本身可由多个基本团队类型嵌套构成，图谱该节点未引用本书。	为该节点补引 BK-030 第5章平台团队与「平台刚好够大」小节。
GAP-TT-004	应引未引	BK-030	Ch3	认知负荷约束	该节点指出团队能承载的复杂度有限，每项新增工具、职责或领域都消耗心智带宽。本书第3章把团队认知负荷细分为任务固有的、环境附加的与学习增益的三类，并给出「压缩固有、消除附加、留出增益」的处置方向，还讨论了以人类群体规模上限约束团队与团队集合大小，图谱该节点未引用本书。	为该节点补引 BK-030 第3章「良好边界降低认知负荷」与「以小规模长寿命团队为标准」小节。
GAP-TT-005	应引未引	BK-030	Ch2	组织-架构同态	该节点陈述组织沟通结构与其所设计系统架构之间存在保结构的对应关系。本书第2章综述了支持这一同态效应的多项实证研究，并给出「组织架构与系统架构相冲突时，组织架构胜出」的现代表述，以及沟通路径如何限制组织可探索的设计空间，图谱该节点未引用本书。	为该节点补引 BK-030 第2章，作为同态效应的实证证据与现代表述来源。
GAP-TT-006	应引未引	BK-030	Ch6	团队边界与架构边界耦合	该节点主张团队负责范围须与模块边界对齐，错位会以接口复杂度与协调成本的形式反噬。本书第6章以团队优先的边界选取为主线，论证边界含糊如何导致高耦合与责任真空，并给出多种可用于对齐的切分依据与判定启发式，图谱该节点未引用本书。	为该节点补引 BK-030 第6章「团队优先的软件职责与边界」小节。
GAP-TT-007	覆盖盲区	BK-030	Ch5	团队拓扑四类型	流对齐团队是本书拓扑体系中的主团队类型：围绕单条价值流组建（可以是单一产品、单组特性、单条用户旅程或单一用户画像），具备从需求探索到生产运行的多学科能力，并尽量不把工作移交给其他团队。图谱只有一个概括四类型的节点，没有刻画这一主类型的独立节点，其定义、能力清单、期望行为与衡量方式均无处挂载。	新增节点（提案 MTH-N-07 流对齐团队，待评审），并补边至团队拓扑四类型节点与团队边界治理节点。
GAP-TT-008	覆盖盲区	BK-030	Ch5	团队拓扑四类型	赋能团队以短期介入的方式帮助流对齐团队补齐能力缺口：由某一技术或产品领域的专家组成，先理解对方的具体问题再给建议，不以代劳为目的，并主动避免成为发号施令的知识象牙塔。图谱缺少该团队类型的节点，其与常设的跨团队实践社群之间的分工差异也无处体现。	新增节点（提案 MTH-N-08 赋能团队，待评审），并补边至团队拓扑四类型节点与教练式促进交互模式。
GAP-TT-009	覆盖盲区	BK-030	Ch5	团队拓扑四类型	复杂子系统团队为依赖高度专门知识、多数成员须是该领域专家的子系统而设，其成立依据是团队认知负荷而非组件复用机会，因此数量应远少于传统按共享组件划分的团队。图谱缺少该类型节点，导致「何时应为专门知识单独建队」这一判断依据在图谱中没有承载概念。	新增节点（提案 MTH-N-09 复杂子系统团队，待评审），并补边至团队拓扑四类型节点与服务消费交互模式。
GAP-TT-010	覆盖盲区	BK-030	Ch3	— 提案：MTH-N-10	团队接口把接口设计从代码层扩展到整个团队：除运行时端点与客户端库外，还包括版本承诺、文档与操作指南、团队工作方式与原则、沟通渠道，以及当前与近期工作信息，并要求团队持续定义、公示、检验与演进这一接口。图谱缺少该概念节点，团队对外的可交互面因此没有承载点。	新增节点（提案 MTH-N-10 团队接口，待评审），并补边至团队交互模式与平台团队节点。
GAP-TT-011	覆盖盲区	BK-030	Ch6	— 提案：MTH-N-11	本书第6章提出以「断裂面」寻找系统中的天然接缝，把业务限界上下文列为首选依据，并给出合规监管、变更节奏、团队所在地、风险、性能隔离、技术栈与用户画像等多类可组合的备选依据，附以适用性检验；同章还归纳了多种不易察觉的隐性单体形态。图谱缺少这套按团队认知负荷选取软件边界的方法节点。	新增节点（提案 MTH-N-11 断裂面与团队尺度软件边界，待评审），并补边至领域驱动战略设计与粒度边界设定节点。
GAP-TT-012	覆盖盲区	BK-030	Ch8	— 提案：MTH-N-12	本书第8章把稳定的团队及其交互通道视为组织的感官，用它们持续探测平台、接口与协作关系是否失效，并给出一组触发拓扑调整的可观测征兆，例如系统已超出单团队可承载的规模、交付节奏持续变慢、多项高层业务服务依赖一大片底层服务。图谱缺少这一「以团队交互为传感器驱动结构调整」的方法节点。	新增节点（提案 MTH-N-12 组织感知与拓扑演化触发条件，待评审），并补边至团队边界治理与度量反馈闭环节点。
GAP-TT-013	覆盖盲区	BK-030	Ch4	— 提案：MTH-N-13	本书第4章引入作者维护的团队拓扑目录，把它作为讨论团队职责、接口与协作方式的对话起点，并归纳两类常见的团队形成反模式：临时拼凑式组队与频繁打散重组；同时强调同一拓扑在不同组织规模、工程成熟度与文化下成败迥异，不存在普适最优形态。图谱缺少这一「拓扑目录与团队反模式」的方法节点。	新增节点（提案 MTH-N-13 团队拓扑目录与团队反模式，待评审），并补边至团队拓扑四类型与团队边界治理节点。
GAP-TT-014	概念缺口	BK-030	Ch5	平台团队与最薄可行平台	「最薄可行平台」这一概念在图谱中缺失：它要求在保持平台精简与确实加速交付之间取得平衡，并指出平台形态可从一页组件清单一路演进到由多个内部团队构成的多层平台，只有当底层基座足够复杂时组建常设平台团队才合算。该规模判据应在平台团队节点下补充。	新增术语条目并补挂至 MTH-N-04，说明平台规模的最小充分判据及其形态演进谱系。
GAP-TT-015	概念缺口	BK-030	Ch7	团队交互模式	「承诺理论」在图谱中缺失：它主张团队间关系应以各方自愿作出的承诺来构造，而非以命令或可强制执行的契约来构造，例如按语义化版本号的含义承诺不破坏下游依赖。该概念为服务消费型交互提供了理论依据与可检验的承诺清单，应补挂在团队交互模式节点下。	新增术语条目并补挂至 MTH-N-03，说明承诺式协作与服务消费模式、接口版本承诺之间的关系。
GAP-TT-016	概念缺口	BK-030	Ch8	度量与反馈闭环	「把运行与维护活动当作开发的高保真感官输入、从而形成可自我导向的控制论闭环」在图谱中缺失：本书主张不要另设只做维护与常规运营的团队，让构建者对同一系统的新功能与存量维护并行负责，使运行信号持续回流并校正设计。该机制应在度量与反馈闭环节点下补充。	新增术语条目并补挂至 MTH-O-11，说明以运行信号驱动设计校正的组织级反馈闭环及其反模式。
GAP-WELC-001	覆盖盲区	BK-022	ChWrap Method	绞杀者渐进式替换	在逐方法、逐类的尺度上，发芽与包裹已经把「新旧同时在场、调用方不必知情」这件事讲透了：新方法先执行新增行为、再委派改名后私有化的旧方法，调用点保持原样。但本书停在了进程内的方法与类这一层，没有给出跨部署单元的路由与切换实体——谁来持有那条始终存在的分流通道、判定依据放在哪里、一次功能迁移到哪一步才算切断旧路径、以及切断前如何保留一键回退。TEC-L-02 的定义要求「可切换的接缝与路由」，而本书只交付了前者。	以 BK-022 第 6 章「Wrap Method」的委派改写为最小尺度的路由接缝证据，为该节点补入跨尺度说明：进程内的方法接缝仅覆盖单次调用分流，节点所要求的系统级可切换路由（请求分流、灰度切量、旧路径退场）需另引其他来源。
GAP-WELC-002	概念缺口	BK-022	ChWe Feel Overwhelmed	绞杀者渐进式替换	本书在批评整机重写时描述了一个反复出现的场景：旧系统仍在服役，业务方逐项判断某个新需求是进旧系统还是让客户等新系统，很多时候客户等不了，同一个改动就只能两套系统都做，新团队因此被迫双份作业，替换愈发遥遥无期。本书把「同一改动两套都做」当作失败征兆来叙述，并未把它正面处理为迁移期必须承担的过渡成本，也没有给出并行期的数据同步与归属规则。既有节点中，弃用与日落策略管的是退场，增量演化与一致性治理管的是架构约束的持续一致，都不承载「新旧并行期间两侧数据如何同步、以哪侧为准、何时解除双写」。	提案新节点「渐进迁移中的新旧并行数据同步策略」，承载并行期的双写与同步机制、数据归属与权威侧判定、以及双写解除时机；BK-022 第 24 章「We Feel Overwhelmed」可登记为问题侧的直接证据，机制侧证据需另引。
GAP-WELC-003	应引未引	BK-022	ChThe Legacy Code Change Algorithm	遗留系统渐进治理	本书把遗留代码工作的日常目标定成一条可累积的纪律：每一轮编程结束时交付的不只是带来价值的功能改动，还有它的测试；被覆盖的区域像岛屿一样浮出水面并逐步连成陆地。这为「渐进治理」提供了节奏与进度判据——以每轮编程为单位同时产出功能与测试覆盖，而不是以季度或版本为单位安排一次清理。该节点若只强调接缝与绞杀者，会缺少这条定义推进节奏的依据。	为 MTH-L-06 补引 BK-022 第 2 章「The Legacy Code Change Algorithm」中关于日常目标与测试覆盖岛屿化的段落，登记为「以单轮编程为推进单位、功能与测试同步交付」的直接证据。
GAP-WELC-101	应引未引	BK-022	ChSeams	重构手法族	该书用整章篇幅给出「接缝」这一改造视角：接缝是可换掉行为而不必编辑该处的落点，每个接缝都配一个启用点来决定走哪种行为，并可按语言与构建阶段区分预处理、链接、对象等接缝类型，其中对象接缝在面向对象语言中最实用。这是「在何处下手替换依赖 / 替换实现」的判定框架，与本图谱既有的重构手法族、测试替身与测试策略节点都只能部分对应，目前没有节点把「替换点 + 启用点 + 接缝类型选择」作为独立判定对象承载。	在 MTH-H-01「重构手法族」节点下补入 BK-022 第4章的接缝与启用点证据（含对象接缝优先于预处理/链接接缝的选择结论）；若后续多本书反复出现该视角，再考虑为其单列一个「接缝与启用点」方法节点，并与测试替身与测试策略、可测试性本质建立关系边。
GAP-WELC-102	覆盖盲区	BK-022	ChSensing and Separation	行为保持重构	书中把「为什么要断开依赖」拆成两类互不相同的理由：一是感知，值根本取不到、只能借助替身把计算结果暴露出来；二是分离，连把代码放进测试夹具跑起来都做不到。书中并指出两者孰难并无定论，替身对象与带内置断言的模拟对象分别服务不同场景。图谱现有节点只在「行为保持重构」下谈测试支撑，没有把断依赖的动机分类作为可判定的内容收进来，导致「为感知而断」与「为分离而断」在实践指导上无从区分。	以 BK-022 第3章为该细分的证据来源，在 MTH-L-01「行为保持重构」节点内补入「感知 / 分离」两类断依赖动机及其对应手段（替身、模拟对象）；并与测试替身与测试策略节点建立引用关系，避免两处重复承载。
GAP-WELC-103	概念缺口	BK-022	ChLegacy Code Change Algorithm	行为保持重构	该书把遗留系统中的日常改动固化为一个五步次序：定位改动点、找测试点、断开依赖、写测试、再改动并重构；其配套主张是每次编程回合结束时应同时交出功能与其测试，受测区域因此像岛屿一样逐步扩大。图谱目前缺少这条「在无测试的既有代码里先建立可测性、再实施行为变更」的操作性次序，现有行为保持重构内容讲的是重构本身如何保持行为，不覆盖进入遗留代码的入口流程。	在 MTH-L-01「行为保持重构」或遗留系统渐进治理节点下补入 BK-022 第2章的遗留代码改动次序，并明确其与「测试先行的扩大受测范围」目标的绑定关系；同时在注释中标注该书把为可测性而做的断依赖改造也视为重构这一归类。