Requirement compiler V2 Segment 1

[lisihao]

1. 新的总架构：Solar Compile + Governance + Optimization

之前我们定的是：

Boss Intent
-> Requirement Compiler
-> GEMS Grounding Compiler
-> Plan Compiler
-> Contract Binder / Static Verifier
-> Context Compiler
-> Execution Broker
-> Event / Evidence / Artifact Ledger

现在要加一层闭环：

Execution Traces / Failures / Evaluations / Human Feedback
-> Optimization Fabric
-> Candidate Compiler / Policy / Prompt / Contract / Context Strategy
-> Verification Gate
-> Canary / Shadow Eval
-> Promotion Registry
-> Next Compile Stack Version

最终图：

┌────────────────────────────────────────────────────────────────────┐
│ Boss Intent │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Solar Compile Stack │
│ Requirement Compiler → GEMS Grounder → Plan Compiler │
│ → Contract Binder → Context Compiler │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Execution Broker │
│ Proposed → Grounded → Contract-Bound → Verified → Executed │
│ → Observed → Postflight-Verified → Committed → Recorded │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Event Ledger / Evidence Ledger / Artifact Store │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Solar Optimization Fabric │
│ Failure Taxonomy / Eval Cases / GEPA / optimize_anything │
│ Candidate Generation / Pareto Frontier / Safety Gate / Promotion │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Optimized Compile Stack Components │
│ Requirement taxonomy, prompts, context policies, retrieval plans, │
│ action contracts, tool routing, repair strategies, evaluator rubrics│
└────────────────────────────────────────────────────────────────────┘

重点：Optimizer 优化的是 Solar 的编译和治理组件，不是直接修改世界事实。

2. 和 GEMS 的关系：Optimization Fabric 是 GEMS-Harness 的学习层

GEMS proposal 的四个 RO 是：

RO1 GEMS Graph：semantic grounding / text-to-discovery
RO2 Action Contracts：contract formalism / composition / verification / inference
RO3 Governed Memory：event-sourced state / typed objects / replay
RO4 Runtime Integration：MCP integration / validation loop / evaluation

GEMS 文档明确提出 GEMS Graph 由 DatasetGraph、ToolingGraph、ConceptGraph 组成，支持从自然语言到 grounded queries 和 tool specifications；Action Contracts 捕获 pre/post、side effects、compensation、policy、interface binding，并能做多步组合验证；Governed Memory 则把 action、decision、approval 记录成 immutable event，并支持 replay、materialized views 和 tamper-evident log。

我们之前已经把 GEMS 从 advisory MCP tool 升级成 Solar 的 mandatory control plane：不能相信 agent 自己一定调用 validate_plan_step，所有有副作用动作必须经过 Execution Broker。这个判断仍然保留。Super Harness 评审里也明确：GEMS 当前 proposal 更像 enterprise grounding platform，还缺 PlanIR 和强制执行控制面；PlanIR 是让系统从“验证单步动作”升级到“验证整个 workflow”的中心结构。

现在再加一层：

GEMS-Harness = Semantic Compiler + Contract Verifier + Execution Ledger + Evaluation Oracle
Solar Optimization Fabric = GEMS-Harness 的自我改进器

它优化这些东西：

1. ConceptGraph bootstrapping prompts
2. ToolingGraph extraction rules
3. ActionContract inference templates
4. Requirement classification taxonomy
5. RequirementIR compiler prompts/rules
6. PlanIR generator templates
7. Context Compiler retrieval/budget/compression policies
8. Execution Broker routing policies
9. Postflight verifier rubrics
10. Repair planner strategies
11. Evaluator scoring functions
12. Human review prioritization rules

GEMS 原案也强调 RO4 要做 ablation：coworker alone vs +GEMS Graph vs +Contracts vs +Memory，并用端到端执行、audit trail、anomaly detection 来验证每个组件价值。 Solar Optimization Fabric 应该直接把这些 ablation 和 failure records 变成优化器的训练/评估数据。

3. 和“需求分类与优化分析系统”的融合

我只能恢复到那个会话的轻量记忆：你在做一个“需求分类与优化分析系统”，涉及 GEPA 和 optimize_anything。结合当前 Solar 设计，我建议把它升级为 Solar 的 Requirement Optimization Layer，不要做成孤立产品。

它应该分成两件事：

Requirement Classifier
判断需求是什么类型、风险多高、需要哪些编译路径、哪些上下文、哪些工具、哪些审批。

Requirement Optimizer
把模糊老板意图优化成更好的 RequirementIR：
更清晰的目标、更可验收的成功标准、更少歧义、更好的拆解、更明确的非目标。
3.1 需求分类不只是标签，而是编译路由

普通需求分类可能输出：

bug / feature / research / refactor

Solar 不能这么浅。Solar 的需求分类要输出编译策略：

requirement_classification:
intent_type:
primary: architecture_redesign
secondary:
- data_substrate
- optimizer_design
- agent_runtime_governance

work_mode:
- research
- design
- implementation_planning

risk_profile:
data_sensitivity: internal
side_effect_risk: low_for_design_high_for_execution
governance_need: high
ambiguity_level: medium

compilation_route:
requirement_compiler: required
gems_grounding: required
plan_ir: required
action_contracts: required_for_implementation
context_compiler: required
execution_broker: required_for_write_actions
optimizer: required_for_iterative_improvement

evidence_policy:
source_bound_claims: required
citations: required
freshness_check: required_for_external_components

expected_artifacts:
- RequirementIR
- GroundedRequirementIR
- PlanIR
- ContextPack
- Architecture ADR
- Epic/Story backlog
- Eval suite

optimizer_targets:
- requirement_taxonomy
- requirement_compiler_prompt
- context_compiler_budget_policy
- evaluator_rubric

这才是 Solar 风格的需求分类：分类结果直接决定后续编译器怎么跑。

3.2 需求优化不是“润色需求”，而是“降低执行不确定性”

Requirement Optimizer 的目标函数不是文案好看，而是：

1. ambiguity_down
2. acceptance_test_coverage_up
3. evidence_requirements_clear
4. planability_up
5. contractability_up
6. context_compilability_up
7. risk_visibility_up
8. user_intent_preservation_up

示例：

原始需求：
“升级 Solar 数据底座，结合 GEMS、GEPA、optimize anything 优化器看看。”

优化后的 RequirementIR：

• objective: 设计 Solar Data Substrate 2.0 + Optimization Fabric
• success_criteria:
  • 明确 optimizer 可优化和不可优化的 artifact 边界
  • 给出 Requirement Compiler / Context Compiler 的优化方案
  • 给出 GEPA / optimize_anything 集成方式
  • 给出 EvalCase / ScoreCard / Promotion Gate
• constraints:
  • 不得优化 canonical facts / evidence / event ledger
  • 优化候选必须经过 schema + policy + regression gate
  • production 自动修改必须被禁止，默认走 proposal / canary
• non_goals:
  • 不做无约束 self-modifying agent
  • 不让 optimizer 直接改生产知识库

这就是“需求优化分析系统”应该成为 Solar 第一层 optimizer 的原因。

4. GEPA / optimize_anything 在 Solar 里的正确位置
   4.1 GEPA 适合优化什么

GEPA 适合优化 LLM textual components：

Requirement Compiler prompt
Requirement classification instruction
Ambiguity detector prompt
GEMS concept resolver prompt
ToolingGraph extractor prompt
ActionContract inference prompt
PlanIR generation prompt
Context Compiler section assembler prompt
Context compression instruction
Evaluator rubric
Repair planner instruction
Human handoff template

GEPA 不应该直接优化：

Source Registry truth
Event Ledger
Evidence Ledger
accepted facts
human-curated decisions
production policy
production contracts without gate

GEPA paper 的核心是：采样 trajectories，例如 reasoning、tool calls、tool outputs，然后用自然语言反思失败原因，提出并测试 prompt updates，再从 Pareto frontier 合并互补经验；论文摘要报告 GEPA 在六个任务上平均超过 GRPO 约 6%，最多约 20%，并使用最多 35x 更少 rollouts。 DSPy 文档也强调，GEPA 可以利用 textual feedback，而不只是 scalar score，因此能在更少 rollouts 下找到高性能 prompt。

4.2 optimize_anything 适合优化什么

optimize_anything 适合优化 任何可文本化、可评估的 artifact。官方介绍说它可以优化 code、prompts、agent architectures、vector graphics、configurations；核心 insight 是“如果一个东西能序列化成字符串，并且质量能被测量，LLM 就能推理并提出改进”。

Solar 里可优化 artifact 很多：

schemas:

• RequirementIR schema descriptions
• ContextPack section schema descriptions
• ActionContract template

policies:

• context budget policy
• retrieval scoring formula
• tool routing policy
• repair policy
• risk classification rules

prompts:

• requirement compiler prompt
• context compiler prompt
• evaluator prompt
• reflection prompt

configs:

• qmd hybrid retrieval weights
• rerank thresholds
• evidence freshness TTL
• context section token budgets
• GEPA reflection minibatch size

code:

• parsers
• validators
• renderers
• lightweight deterministic checkers

agent architecture:

• plan compiler stage ordering
• repair loop architecture
• evaluator stack composition

但必须加一道 Solar 约束：

optimize_anything can propose anything;
Solar can promote only verified, versioned, reversible, regression-tested artifacts.
5. 关键设计：Optimizer 不能是自由进化器，必须是受治理的编译器优化器

不要做这种危险架构：

failed task -> optimizer mutates prompts/contracts/policies -> auto deploy

这会炸。正确架构：

failed task
-> Failure Record
-> Optimization Job
-> Candidate Generation
-> Static Verification
-> Offline Eval
-> Regression Eval
-> Pareto Selection
-> Human / Policy Gate
-> Canary
-> Promotion
-> Versioned Rollout

架构图：

┌────────────────────────────────────────────────────────────────────┐
│ Event / Evidence / Context / Evaluation Traces │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Failure Taxonomy + Eval Case Builder │
│ SemanticError / ToolMisuse / PolicyViolation / ContextMiss / Drift │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Optimization Job Planner │
│ choose target artifact + optimizer + budget + metrics │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Candidate Generator │
│ GEPA / optimize_anything / MIPROv2 / rule search / human patch │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Candidate Verifier │
│ schema / policy / contract / security / regression / cost │
└─────────────────────────────┬──────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ Pareto Frontier + Promotion Registry │
│ quality vs cost vs latency vs risk vs evidence coverage │
└────────────────────────────────────────────────────────────────────┘

GEPA / DSPy 的 optimizer 模型通常接受 program、metric、train inputs 三类输入；DSPy 文档明确说 optimizer 会调 prompt、few-shot examples 或权重以最大化指定 metric，并且可以从很小的数据开始。 Solar 要把这个思想扩展成：每个 compiler artifact 都有 train/eval cases、metric、promotion gate 和 lineage。

6. OptimizableArtifact：Solar 优化器的核心 ABI

先定义统一 artifact，不然 optimize_anything 会变成野路子。

schema_version: solar.optimizable_artifact.v1
artifact_id: optart:context_budget_policy.v1
kind: context_budget_policy

owner:
package: solar_compile.context
component: BudgetAllocator

content:
format: yaml
path: packages/solar_compile/context/policies/default_budget.yaml

mutable_fields:

• section_weights
• hard_reserves
• diversity_constraints
• truncation_order
• compression_strategy

immutable_fields:

• schema_version
• policy_safety_constraints
• forbidden_source_rules

constraints:
schema: schemas/context_budget_policy.schema.json
must_pass:
- no_forbidden_source_leak
- known_facts_require_evidence
- allowed_actions_require_contract
- token_budget_not_exceeded
forbidden_changes:
- allow_untrusted_as_known_fact
- disable_evidence_requirement

evaluation:
eval_suite_id: evalsuite:context_compiler.v1
primary_metric: context_task_success
secondary_metrics:
- evidence_coverage
- unsupported_claim_rate
- token_cost
- latency
- policy_violation_rate
- context_precision
- context_recall

deployment:
rollout_mode: canary
requires_human_approval: true
revert_strategy: version_pin_previous

这个 ABI 的关键原则：

optimizer 可以改 mutable_fields；
optimizer 不能改 immutable_fields；
optimizer 产物必须过 schema / policy / regression；
optimizer 结果先进入 proposal，不直接进 production。
7. OptimizationJob：一次优化任务的结构
schema_version: solar.optimization_job.v1
job_id: optjob:ctx-budget-2026-06-08
target_artifact_id: optart:context_budget_policy.v1
trigger:
type: regression | scheduled | human_request | failure_cluster
source:
failure_cluster_id: failcluster:context_miss.qmd_sources

optimizer:
engine: gepa.optimize_anything
mode: multi_task_generalization
budget:
max_metric_calls: 200
max_wall_clock_minutes: 60
max_cost_usd: 25

train_cases:

• evalcase:context:001
• evalcase:context:002

validation_cases:

• evalcase:context:holdout:001

metrics:
objective:
maximize:
- context_task_success
- evidence_coverage
- context_recall
minimize:
- unsupported_claim_rate
- token_cost
- latency
- policy_violation_rate
hard_constraints:
- policy_violation_rate == 0
- schema_failure_rate == 0
- evidence_resolvability >= 0.98

promotion:
min_delta:
context_task_success: +0.05
unsupported_claim_rate: -0.02
canary_tasks: 20
rollback_on:
- any_policy_violation
- evidence_resolvability_drop

这就把“优化”从玄学变成工程闭环。

8. 需求编译器怎么优化

Requirement Compiler 是第一优先级，因为需求编译错了，后面全错。

8.1 可优化组件

1. requirement taxonomy
2. intent classifier prompt
3. ambiguity detector prompt
4. success criteria extractor
5. non-goal extractor
6. risk classifier
7. acceptance test generator
8. requirement splitting policy
9. stakeholder / artifact inference rules
10. RequirementIR schema descriptions
    8.2 训练/评估样本
    evalcase:
    input:
    raw_intent: "升级 Solar 数据底座，结合 GEMS 和 optimize anything 看看"
    conversation_context: [...]
    expected:
    intent_type: architecture_redesign
    constraints:
    • no_mempalace
    • evidence_native
    • optimizer_governed
      required_sections:
    • objective
    • success_criteria
    • non_goals
    • acceptance_tests
    • optimizer_targets
      metrics:
      classification_accuracy
      constraint_recall
      ambiguity_detection_f1
      acceptance_test_quality
      planability_score
      user_intent_preservation
      8.3 Requirement Optimizer 的 scoring
      score =
      0.20 * intent_classification_accuracy

• 0.20 * success_criteria_completeness
• 0.15 * ambiguity_detection_f1
• 0.15 * acceptance_test_quality
• 0.10 * constraint_recall
• 0.10 * planability_score
• 0.05 * non_goal_precision
• 0.05 * token_efficiency

硬约束：

1. 不能添加用户没有授权的目标。
2. 不能删掉用户明确约束。
3. 不能把模糊需求伪装成确定需求。
4. 必须保留 unresolved_ambiguities。
5. 必须输出 acceptance_tests。
   8.4 GEPA 用法

GEPA 适合优化：

• requirement compiler instruction
• ambiguity extraction instruction
• success criteria extraction rubric
• acceptance test generator prompt

因为这些都是文本 instruction，并且能通过 RequirementIR quality metric 评估。GEPA 支持用 textual feedback 指导优化，而不仅是数字分数；这对需求编译很关键，因为失败原因通常是“漏了非目标”“把建议当硬约束”“没拆出验收条件”这种语言级诊断。

9. Context Compiler 怎么优化

Context Compiler 是第二优先级。它直接影响 agent 看到什么、漏掉什么、能做什么。

9.1 可优化组件

1. retrieval intent planner
2. evidence candidate scorer
3. section budget policy
4. context compression prompt
5. current_plan_node rendering template
6. allowed_actions rendering template
7. risk/staleness section policy
8. contradiction surfacing policy
9. model_view / broker_view / evaluator_view split policy
10. context expansion trigger policy
    9.2 ContextPack 的多目标优化

Context Compiler 不应该追求单一“回答准确率”。它是多目标：

maximize:
task_success
context_recall
evidence_coverage
correct_tool_usage
policy_compliance
repair_success_rate

minimize:
unsupported_claim_rate
wrong_tool_rate
token_cost
latency
context_noise
stale_source_usage
policy_violation_rate

建议 scorecard：

context_scorecard:
hard_constraints:
schema_valid: true
evidence_resolvability >= 0.98
policy_violation_rate == 0
known_facts_evidence_coverage >= 0.95
allowed_actions_contract_coverage == 1.0

weighted_objectives:
task_success: 0.25
context_recall: 0.18
context_precision: 0.12
evidence_coverage: 0.15
correct_tool_usage: 0.10
token_efficiency: 0.08
latency: 0.05
repair_success: 0.07
9.3 optimize_anything 用法

Context Compiler 的策略很适合 optimize_anything，因为很多策略都是可文本化的配置：

section_budget:
mission: 0.05
requirement_context: 0.10
gems_grounding: 0.14
project_state: 0.10
current_plan_node: 0.12
known_facts: 0.20
relevant_sources: 0.16
allowed_actions: 0.08
risks: 0.04
staleness: 0.01

优化器可以提出候选：

• 增加 current_plan_node 和 allowed_actions 权重，减少泛化背景。
• 对 execute mode 提高 exact evidence 权重。
• 对 evaluate mode 提高 success_predicates 和 artifact diff 权重。
• 对 repair mode 提高 failure records 和 checkpoint refs 权重。

然后用 evaluation cases 验证是否真的提升 task success / evidence coverage / token efficiency。optimize_anything 官方把 single-task search、multi-task search、generalization 合并到一个 declarative API，这很适合 Solar：单个失败任务可以做 targeted repair，多任务 eval suite 可以做策略泛化，跨任务策略则用于长期发布。

10. GEMS Grounding 怎么优化

GEMS Grounding 的核心风险是：ConceptGraph 错了，整个系统会高置信地错。Super Harness 评审已经指出，ontology bootstrapping 是质量瓶颈，必须有 confidence score、human validation queue、conflict detection、concept versioning、definition lineage、department-specific override。

10.1 可优化组件

1. concept resolution prompt
2. alias detection rule
3. source authority scoring
4. ToolingGraph extractor prompt
5. policy extraction prompt
6. low-confidence human review threshold
7. conflict detection threshold
8. concept merge/split policy
   10.2 Grounding metrics
   concept_resolution_accuracy
   source_authority_accuracy
   tool_mapping_accuracy
   policy_binding_accuracy
   false_merge_rate
   false_split_rate
   low_confidence_recall
   human_review_efficiency
   downstream_plan_verification_pass_rate
   10.3 优化策略

• GEPA 优化 concept resolver 和 policy extractor 的提示词。
• optimize_anything 优化 confidence threshold / review queue policy / merge-split policy。
• 失败样本来自 SemanticError、WrongSource、WrongTool、PolicyMiss。
• 高风险 concept 不能自动 promote，必须 human accept。

这和 GEMS 原案的 progressive formalization 一致：先从 dbt models、glossaries、SKILL.md 等 informal seeds 开始，再 enrichment、alignment、LLM-assisted disambiguation，最后只把低置信项送人审。

11. Action Contract 和 Execution Broker 怎么优化

Action Contract 不能靠优化器随便改，因为它涉及权限和副作用。优化器只能提出 contract candidate，不能直接上线。

11.1 可优化组件

1. contract inference prompt
2. policy document extraction prompt
3. precondition/postcondition templates
4. side-effect classification rules
5. compensation classification
6. risk level classifier
7. interface binding policy
8. verifier selection policy
   11.2 不可自动优化的组件
9. production approval policy
10. irreversible action policy
11. canonical security rules
12. source-of-record designation
13. human-curated contract overrides
    11.3 Contract optimization metrics
    field_coverage
    precision_of_preconditions
    precision_of_side_effects
    policy_violation_catch_rate
    false_block_rate
    verification_latency
    composition_success
    human_review_load
    postflight_failure_rate

GEMS proposal 明确把 Action Contract 的难点列为 expressiveness-compactness trade-off、跨 MCP/API/CLI/code 的 interface-agnostic abstraction、composable contracts、实时 plan verification、从 API specs/MCP schemas/usage logs 推断 contract、从自然语言 policy documents 抽取 formal constraints 等。 所以 Solar 的优化器必须是 proposal-first，不能自动重写生产 contract。

11.4 Broker routing policy 的 optimize_anything

可以优化这个：

routing_policy:
read_only_low_risk:
prefer: [native_api, qmd_mcp]
high_throughput_data_processing:
prefer: [sandboxed_code]
side_effecting_write:
prefer: [api_with_contract_enforcement]
external_untrusted_tool:
prefer: [sandboxed_mcp]
high_sensitivity:
deny: [code_execution]

目标函数：

task_success + latency + cost + policy_compliance + audit_completeness

但硬约束：

policy_violation_rate == 0
irreversible_action_without_approval == 0
forbidden_scope_access == 0

Super Harness 评审里也强调，MCP、API、CLI、code execution 各有 trade-off，不能默认所有工具都 MCP 化；正确做法是 ActionIntent + RiskProfile + Contract + CostModel -> choose interface binding。