企业官网建设流程全解析

领域规则与策略（Domain Rules & Strategies）

层级：L2-L3 |职责：领域公理实例化 + 策略/规范/流程/反模式
源公理：axioms.md §一-§八 |派生追溯：derivation.md §一、§三-§五

§0. 领域规则与公理体系的关系

L0 逻辑基底（axioms.md） └─ L0.5 元推理规则（MetaEvolution / 分层反射） └─ L2 领域公理（本文件 §一）：L0 公理的工程领域特化 ├─ 规则实例：通过 derivation.md 追溯至 L0 公理 └─ 状态变量实例：通过 derivation.md 追溯至 L0 公理

1. 领域规则不引入新的 L0 逻辑基底——所有领域规则必须能追溯到 axioms.md 中的 L0/L0.5 公理
2. 领域规则可版本化——遵循 AxiomHierarchyStructure L2 invariants（可版本化，旧版存档）
3. 领域规则的修改需 ≥2 验证者签名——遵循 AxiomHierarchyStructure L1 invariants（修改需≥2验证者签名共识）

§一、公式类型体系

1.1 规则分类层级

1.2 公式类型定义

注：[DR] 和 [CR] 不产生可执行输出，仅作为文档结构化标记。

1.3 规则冲突解决（ConflictResolution）

同层规则冲突时，按以下优先级裁决：

1. 参数来源优先级（由 ConfigInjection 定义）
2. 规则特异性（更具体的规则优先于通用规则）
3. 时间顺序（后定义的规则覆盖先定义的规则）

跨层优先级由公式类型层级隐含保证：基底公理(L0) > 领域公理(L2) > 规范(L2) > 策略(L2-L3) > 流程(L3) > 反模式(L2-L3)

派生路径：derivation.md §ConflictResolution

• 参数来源优先级 → ConfigInjection（本文件 §二）
• 规则特异性 → IDI-Difference [AX]
• 时间顺序 → LogicalClock [AX]

§二、配置注入（ConfigInjection）

2.1 参数来源优先级

运行时参数 > 项目配置(→ project.md) > 环境变量(→ env:VAR) > 默认值(→ default:val)

2.2 参数缺失处理

• 必需参数缺失→ 规则降级（跳过依赖该参数的决策分支，记入 operationLog）
• 可选参数缺失或类型不匹配→ 使用默认值

2.3 L3 参数修改权限

遵循 AxiomHierarchyStructure L3 invariants（运行时可变，权限分级）：

• config：部署注入（配置文件/环境变量/ConfigMap），无需额外验证
• admin：运行时修改，需 Admin JWT + 熔断校验
• 部署环境覆盖 ≠ 用户输入修改——前者是配置注入，后者需 admin 验证 + 熔断校验

§三、认知状态评估（StateValidity）

StateValidity(cognitiveState, worldState) [QA]

Provides: 状态有效性评估结果（valid/invalid/degraded）

公式：

InternalConsistency ∧ ExternalConsistency ∧ HistoricalIntegrity → valid ¬InternalConsistency → invalid InternalConsistency ∧ (ExternalConsistency ⊕ HistoricalIntegrity) → degraded otherwise → invalid

三定律的 L0 公理派生：

详细派生路径见 derivation.md §StateValidity

评估前置条件：调用 StateValidity 前应先通过 SyncGuard.sync_check 刷新 fileCache（fileCache 非空时）。若 sync_check 不可用，评估结果应标注 ExternalConsistency 维度的可信度。

空状态处理：当fileCache = ∅（系统首次启动或空状态）时，跳过 ExternalConsistency 和 HistoricalIntegrity 两个维度的评估，仅评估 InternalConsistency。

InternalConsistency=false 处理：直接判定为 invalid（对应 StateRecovery 的 full_reset），不进入 degraded 路径。

§四、状态空间定义（State Space Definitions）

状态变量的运行时实例存储于 engine.md §四 StateManager。

InitialStateNullity [AX]（引用）

[CR: axioms.md:InitialStateNullity [AX]]

• 完整公式见 axioms.md：∀x∈SystemState:LegalInitialState→x.intent∈{NO_DATA,NO_RESPONSE}
• 本文件不重复定义，以 axioms.md 为权威源

ResultStructure [AX]（引用）

[CR: axioms.md:ResultStructure [AX]]

• 完整公式见 axioms.md：∀R∈Iteration:R.result∈⟨status,terminal,quality,metadata,output⟩
• 本文件不重复定义，以 axioms.md 为权威源

循环要素类型签名 [SS]

迭代类型签名 [SS]

Iteration : InputSpace × SharedState → OutputSpace × SideEffectSpace Round : LoopStateSpace → LoopStateSpace

§五、策略（Strategies）

策略只做决策判断，不含步骤序列。所有策略输出服从 TruthValueDomainLogic [AX] 的真值域三值语义。

5.1 工具策略

DeprecateStrategy(D, hasReference) [CD] Provides: 废弃决策（cannot_delete/can_delete/no_action）

D ∧ hasReference → cannot_delete·D ∧ ¬hasReference → can_delete·¬D → no_action

AmbiguityStrategy(semantics, phase) [CD] Provides: 歧义处理决策（extract_to_shared_config/use_alias/remove_alias）

same → extract_to_shared_config·different ∧ transition → use_alias·different ∧ migration_done → remove_alias

ReferenceStrategy(depA→B, depB→A) [CD] Provides: 循环引用检测结果（true/false）

depA→B ∧ depB→A → true·otherwise → false

RefactorStrategy(error) [CD] Provides: 重构优先级决策（refactor_first/normal_priority）

error ∈ RefactorScope → refactor_first·otherwise → normal_priority
RefactorScope = {模块迁移, 接口变更, 架构级改动}

ConflictStrategy(hasReference, isFirstTime, deprecationConfig) [CD] 处理决策（delete/firstTimeAction/retryAction）

¬hasReference → delete·hasReference ∧ isFirstTime → deprecationConfig.firstTimeAction·hasReference ∧ ¬isFirstTime → deprecationConfig.retryAction

ToolStrategy [CM] Provides: 工具选择决策（{tools, timeout, mode} 三元组）

• ToolPriority(toolType)：available(external) → external·¬available(external) ∧ available(builtin) → builtin·otherwise → cli
• ToolSelect(taskType)：∈{file_io} → direct_file_ops·∈{analysis,processing} → sandbox_processing·∈{reasoning,decomposition} → structured_reasoning·∈{batch,multi_query} → batch_processing·otherwise → builtin
• Toolchain(scene)：scene → ToolchainMap[scene]（查表模式）。@parallel标注表示该步骤可并发执行。新增场景只需在 ToolchainMap 中添加条目。
• Toolchain fallback：若ToolchainMap[scene]未定义，回退到 ToolSelect 分类路径。

OnError(error) [CD] [layer: L2-L3, scope: single_call|global]

Provides: 通用错误处理决策（continue/report/halt）

通用错误分类策略。仅做错误分类，不含循环计数器或熔断逻辑。循环场景下的错误处理由 engine.md §十 OnError 扩展。

├─ error∈{partial_output, warning} → continue ├─ error∈{irrecoverable} → halt ├─ error∈{compilation_error} → halt（非循环场景）/ 见ExecutionFailureGate（循环场景下由engine.md §六先处理，支持重试） ├─ error∈{execution_failure, timeout} → report + retry_optional ├─ error∈{resource_exhausted} → report + halt └─ otherwise → report + continue

• 本策略不维护 retryCounter / emptyCount / switchCounter / forceHalt 等状态变量（由 engine.md §四 StateManager 统一维护）。
• 循环场景（L1 焦点层级且scope: loop_body）下，由engine.md §十 OnError扩展本策略，叠加计数器规则和熔断逻辑。
• compilation_error 特殊处理：循环场景下由 engine.md §六 ExecutionFailureGate 先处理（支持重试直至 ONERROR_RETRY_LIMIT 后 TM），不进入通用 OnError 的 halt 分支。

作用域提示：L2/L3 焦点层级按本通用策略处理错误。L1 循环体内的错误才激活 engine.md §十 的扩展决策树。

KnowledgeDedup(entity, kb) [CD] Provides: 去重检查结果（skip/record）

hash(entity.name + entity.content) ∈ kb.hashes → skip·otherwise → record + kb.hashes.add(hash)

备策略：当 kb.hashes 未初始化时，先search(entity.name)检查同名实体。存在则add_observations，不存在则record。

PathStrategy(execEnv, projectConfig) [CM] Provides: 路径格式映射

execEnv → projectConfig.path.format[execEnv]· execEnv∈{direct_api, cli, sandbox}

• 通用路径原则：① 绝对路径原则 ② 禁止 cd ③ 兜底策略：路径解析失败时尝试projectConfig.path.root④ 沙箱转义：sandbox 路径使用\\或/

Background(taskType) [CM] Provides: 后台运行判断

taskType∈{dev_server,watcher,daemon}→true·otherwise→false

MergeServerRequest(hasServer, hasRequest) [CD] Provides: 合并决策（merge_in_one_call/separate）

hasServer∧hasRequest→merge_in_one_call·otherwise→separate

CohesionLowStrategy(methods, context) [CD]

methods > GOD_CLASS_THRESHOLD(40) → suggest_refactor + request_confirmation AGGREGATE_THRESHOLD(30) < methods ≤ GOD_CLASS_THRESHOLD(40) → record_as_intent + keep_structure methods ≤ AGGREGATE_THRESHOLD(30) → no_action

隐式聚合与无法区分场景：context 显示功能分散但无统一入口时，即使 methods ≤ GOD_CLASS_THRESHOLD，也输出suggest_convergence；当类型无法区分时，默认按聚合类处理（record_as_intent + keep_structure）。

5.2 上下文策略

CB(actionType) [CM] Provides: 上下文预算模式

file_read→partial_read·code_execution→summary_only·batch_operation→batch_with_queries·doc_web→index_no_content

BudgetAlloc(phase) [CC]

P_plan→较多预算用于信息收集·P_exec_prep→中等预算用于结构分析·P_exec_core→最大预算用于编码实现·P_exec_verify→少量预算用于验证·P_complete→不分配预算

PD(phase) [CM] Provides: 阶段定义

P_plan→(规划,{需求分析,方案设计,信息收集})·P_exec_prep→(执行-准备,{文件读取,代码理解,结构分析})·P_exec_core→(执行-核心,{编码,修改,重构,配置变更})·P_exec_verify→(执行-验证,{构建,测试,审查,验证})·P_complete→(完成,{attempt_completion})

StateRecovery(stateValidity) [SM]

invalid → full_reset·degraded → targeted_recovery·valid → no_action

• 死锁消除：统一为 full_reset，消除 persistenceFileStatus 状态依赖。推理链持久化文件在 full_reset 中被清空并写入恢复标记。
• full_reset：① 清空运行时缓存（operationLog、fileCache）→ ② 清空推理链持久化文件并写入恢复标记（# FULL_RESET at {timestamp}）→ ③ 重新扫描文件系统建立 fileCache → ④ 向用户报告状态已重置，请求确认 → ⑤ 用户确认后继续
• 进度标记不受影响：full_reset 不清除 task_progress（由外部系统维护）。
• 恢复后首次 StateValidity：full_reset 完成后首次 StateValidity 由初始化钩子自动跳过 ExternalConsistency 和 HistoricalIntegrity 两个维度。
• 二次恢复防护：推理链文件中的恢复标记在 full_reset 步骤②写入后，CompactProcedure 的 persist_reasoning 将其作为当前阶段的推理记录写入推理链。后续 StateValidity 检查 HistoricalIntegrity 时，该记录满足phase.reasoningLog ≠ ∅条件。
• targeted_recovery：① 识别 degraded 的具体维度 → ② 仅恢复对应维度 → ③ 向用户报告部分状态已刷新
• 任何压缩操作前必须先执行 StateValidity 检查，invalid 状态不压缩先恢复。

CompactDecision(phaseChanged, moduleDone, ctx_critical, stateValidity) [CD] Provides: 压缩类型决策（none/phase_compact/module_compact/emergency_dump）

ctx_critical → emergency_dump·phaseChanged → phase_compact·moduleDone ∧ ¬phaseChanged → module_compact·otherwise → no_action

• 优先级：ctx_critical > phaseChanged（上下文截断风险 > 阶段压缩收益）。
• ctx_critical 由系统信号触发：上下文水位警告（>85%）、文件重读需求、输出截断检测。不依赖 AI 内省。

5.3 读取策略

ReadStrategy(S, filePath, projectConfig) [CD] Provides: 读取档位决策（direct/process/process_segmented）

S < SMALL → direct·SMALL ≤ S ≤ LARGE → process·S > LARGE → process_segmented

SMALL/LARGE 阈值来自 project.md §1.1 文件处理阈值。

• 读取完成后更新 fileCache：按 StateManager 规范更新。
• degraded 状态处理：StateValidity 输出 degraded 时（InternalConsistency=true 且 ExternalConsistency=false），优先选择direct或process模式并强制重新读取（跳过 fileCache）。invalid 时先执行 StateRecovery。

IdempotencyCheck(current, last, currentFileHash, lastFileHash) [QA] Provides: 幂等性检查结果（skip/proceed/null_input）

current = null → null_input·current ≠ null ∧ last = null → proceed·current ≠ null ∧ last ≠ null ∧ current = last ∧ currentFileHash = lastFileHash → skip·otherwise → proceed

• 两维检查：操作标识 + 文件哈希都相同才 Skip。
• null 保护：current=null→ 返回null_input；current≠null ∧ last=null→ 进入proceed。
• 状态变量更新：执行完毕后通过 StateManager 更新last = current和lastFileHash = currentFileHash。

InfoDomain(task, readStrategy, projectConfig) [CM] Provides: 信息域评估结果

single_file → (scope=single, type=code, complexity=readStrategy)·single_module → (scope=module, type=mixed, complexity=moderate)·cross_module → (scope=multiple, type=mixed, complexity=complex)·full_project → (scope=all, type=mixed, complexity=complex)

• complexity 由 ReadStrategy 输出档位决定：direct→simple,process→moderate,process_segmented→complex。

CalculateCost(N, T_i, R_perOp, R_batch) [CC] Provides: 操作成本估算

Cost_sequential(N)=ΣT_i + N×R_perOp·Cost_batch(N)≈max(T_1,...,T_N)+R_batch· 推论：N>1∧T_i分布均匀→Cost_batch<Cost_sequential

§六、规范（Standards）

规范定义约束条件，可引用领域公理、策略。

6.1 错误处理规范

FailMode(errorType) [CM] Provides: 失败模式（FailFast/FailSafe/FailGraceful）

errorType∈{unrecoverable,precondition_violation}→FailFast·∈{user_input,optional_feature}→FailSafe·∈{non_core,third_party_timeout}→FailGraceful

ThrowRule(violationType, language, projectConfig) [CM] Provides: 异常类型映射

violationType → projectConfig.exceptions[violationType]

FixPriority(errorType, projectConfig) [CM] Provides: 修复优先级映射

errorType → projectConfig.fixPriority[errorType]

CodeStandard(code) [QA] Provides: 代码质量评估（pass/block）

¬emptyCatch ∧ ¬consoleLog ∧ ¬magicNumber ∧ ¬unusedImport ∧ ¬hardcodedPath ∧ ¬todoFIXME → pass·otherwise → block

• 项目可在 project.md 中声明AllowedCodeViolations覆盖。
• Warn 级（不阻断，仅注释建议）：预留抽象、注释替代命名、冗余注释/配置。

6.2 架构规范

SCA(condition) [CD] Provides: 服务聚合锚点判断

condition∈{external_dependency,dataflow_boundary,capability_exit,change_hotspot}→true·otherwise→false

VB(boundary) [CD] Provides: 边界验证结果（valid/invalid:multiple_responsibilities/invalid:incomplete_coverage）

single_responsibility∧complete_coverage→valid·¬single_responsibility→invalid:multiple_responsibilities·single_responsibility∧¬complete_coverage→invalid:incomplete_coverage

CommunicationMode(syncMode, processBoundary, crossSystem) [CM] Provides: 通信方式（method_call/remote_call/event_delegate/message_queue/data_object）

sync ∧ same_process ∧ ¬crossSystem → method_call·sync ∧ ¬same_process ∧ ¬crossSystem → remote_call·async ∧ same_process ∧ ¬crossSystem → event_delegate·async ∧ ¬same_process ∧ ¬crossSystem → message_queue·crossSystem → data_object

CohesionCheck(scope) [CM] Provides: 内聚性评估结果（{rating, method_count, lines}）

methods≤COHESION_METHOD_THRESHOLD(30) ∧ lines≤COHESION_LINE_THRESHOLD(1000) → {rating: "High", method_count: methods, lines}
methods>COHESION_METHOD_THRESHOLD(30) ∨ lines>COHESION_LINE_THRESHOLD(1000) → {rating: "Low", method_count: methods, lines}

• CohesionCheck 输出 Low 时由 CohesionLowStrategy 进一步评估。

6.3 输出规范

ShouldWrite(isRedundant, simpler, costExceedsValue) [CD] Provides: 写入决策（true/false）

isRedundant→false·simpler_exists→false·costExceedsValue→false·otherwise→true

OA(state, scope, recoverable) [CD] Provides: 输出动作（replace/rewrite/deprecate/delete）

modify∧local→replace·modify∧global→rewrite·deprecate∧recoverable→deprecate·deprecate∧¬recoverable→delete

§七、反模式索引

§八、操作流程（Procedures）

流程定义步骤序列。所有流程服从 Discrete-AtomicStep [AX] 的原子跃迁约束。

SyncGuard [SM]

步骤序列：

1. [TOOL: sync_check(paths)]：对 fileCache 中所有条目执行物理校验
   • {status: "synced"}→ 继续步骤 2
   • {status: "stale", stalePaths: [...]}→ 刷新 fileCache 中对应条目的时间戳和哈希，设置StateManager.externalConsistency = false，继续步骤 2
   • {status: "error", message}→ 委托 ErrorHandler 处理
2. 状态变量更新：sync_check 返回 stale → 设置externalConsistency = false，触发 StateValidity 重新评估

• 默认在工具链执行前触发，可通过@skip_sync_guard标注跳过。

IdempotencyGuard [SM]

步骤序列：

1. IdempotencyCheck：调用 IdempotencyCheck 策略进行幂等性检查
   • skip→ 跳过本次执行
   • proceed→ 进入执行体
   • null_input→ 跳过本次执行（由调用方决定是否初始化新操作）
2. 状态变量更新：执行体完成后，通过 StateManager 更新last和lastFileHash

• 可选守卫，通过@skip_idempotency_guard标注跳过。与 SyncGuard 独立。

ErrorHandler [SM]

根据 OnError 输出的决策值执行对应动作：

forcehalt → 停止工具链 → 设置 forceHalt=true → 报告用户 → 强制挂起 halt → 停止工具链 halt+persist → 停止工具链 → persist_reasoning(error_summary) continue → 记录错误摘要到 operationLog → 继续执行后续步骤 skip_remaining → 跳过剩余步骤 → persist_reasoning(error_summary) retry → 验证参数和系统状态是否已变化 → 重试当前步骤 switch_strategy → [回滚脏代码 → 换参数/换工具/报告用户] - **编译错误回滚**：`error = compilation_error` 时先回滚到上次编译成功的代码版本。回滚范围仅限当前工具链中修改的文件。 - **文件快照机制**：执行体在修改文件前通过 StateManager 记录文件原始内容快照，回滚时从快照恢复。git stash 优先。 - **回滚失败处理**：回滚失败 → 输出 halt。

• ErrorHandler 是 SyncGuard 和工具链执行失败时的统一处理入口，不包含决策逻辑。
• ErrorHandler 的 persist_reasoning 仅用于异常终止时保存错误摘要，与 CompactProcedure 的阶段边界持久化职责不同。

ReasoningPersistence [SM]

职责区分：persist_reasoning有三种调用场景：

PostProcess [SM]

步骤序列：

1. 推理(reasoning)：调用sequentialthinking_tools分析执行结果，形成结论
2. 记录知识(record_knowledge)：调用create_entities/create_relations/note持久化关键发现（执行前引用 KnowledgeDedup 去重）

• PostProcess 的record_knowledge存事实/结论，CompactProcedure 的persist_reasoning存推理链。两者职责不同。

FileDeprecationFlow [SM]

参数：deprecatedDir（默认_deprecated/）、excludeMethod（compile_exclude/runtime_ignore/module_exclude）、excludeConfig、cleanTrigger
步骤：check_references → move_to_deprecated → apply_exclusion → verify_isolation → register_cleanup

CompactProcedure(compactType) [SM]

阶段动作映射：

phase_compact → [执行阶段动作 → mark_phase_done → clear_context → 新会话从进度标记恢复，加载推理链末 RECENT_CHAIN_COUNT(3) 条到元提示]
module_compact → [record_module_summary + persist_reasoning → record_notes → update_progress_marker → clear_context]
emergency_dump → [输出极简纯文本状态摘要（≤EMERGENCY_DUMP_MAX_CHARS(500)字符） → clear_context → 强制 Halt，等待用户输入]

• emergency_dump 跳过阶段动作映射和 persist_reasoning（截断风险 > 持久化收益）。
• ctx_critical 信号应在当前步骤执行前检测，检测到后立即触发 emergency_dump。
• none → no_action