跳转至

实验报告索引

更新日期：2026-06-14

本页把 OrgReOrg / Harness 当前 P0 风险实验、Demo 和 benchmark 统一登记为结构化 experiment_report，便于研用测一体地追踪问题、指标、结论和后续任务。

总览

实验 架构主线 状态 阶段 Owner Freshness Cost 风险 核心问题 关键指标 入口
Context Router Demo Runtime Projection completed P0 local simulation context-routing watch
2026-06-14
14d		 zero
local_python
no-paid-api		 low 路由是否能减少无关上下文 expected_library_recall=100%
avg_prompt_token_savings=12.9%		 published page
Ingestion Quality Demo Evidence
Ontology		 completed P0 local risk benchmark ingestion current
2026-06-14
14d		 zero
local_python
no-paid-api		 high 入库清洗会不会丢事实 naive_fact_recall=19%
structured_fact_recall=100%		 published page
Retrieval Platform Benchmark Runtime Projection completed P0 local risk benchmark search current
2026-06-14
14d		 zero
local_python
no-paid-api		 high 检索如何避免权限、删除、旧新冲突和 gap 错误 hybrid_guarded_safe_answer_rate=100%
lexical_unsafe_permission_leaks=2		 published page
SearchConnector Conformance Runtime Projection completed P0 adapter conformance search current
2026-06-14
14d		 zero
local_python
no-paid-api		 medium 真实检索 adapter 是否遵守最低安全和可解释 contract connectors=2
passed_cases=14/14
optional_external_adapter_skeletons=2		 published page
Search Adapter State Benchmark Runtime Projection completed P0 adapter state benchmark search current
2026-06-14
14d		 zero
local_python
no-paid-api		 high 真实检索投影 adapter 接入前，删除传播、权限变更、supersede 和 reindex 延迟会造成哪些 stale-index 风险 passed_cases=4/4
adapter_profiles=3
default_ci_adapters=1
live_adapters_skipped=2
stale_detected=3
unsafe_pre_reindex_hit=3
safe_after_reindex=4
rank_log_contract=4/4		 published page
SearchConnector Tool Gateway Runtime Projection completed P0 tool gateway conformance tool-gateway current
2026-06-14
14d		 zero
local_python
no-paid-api		 high SearchConnector 是否已经作为工具能力进入 Tool Gateway 调用路径 passed_cases=7/7
unsafe_output_leaks=0
stale_index_blocks=1/1
remediation_item_links=1/1		 published page
Context Router Stale Policy Eval Runtime Projection completed P0 stale-index risk policy context-routing current
2026-06-14
14d		 zero
local_python
no-paid-api		 high Context Router 是否能按任务风险处理 stale_index 候选上下文库 passed_cases=4/4
actions_covered=4
blocked_stale_cases=3/3
leak_markers=0		 published page
Projection Remediation Eval Runtime Projection completed P0 stale projection remediation search current
2026-06-14
14d		 zero
local_python
no-paid-api		 critical 关键风险 stale projection 被 block 后，是否能进入统一补证、reindex 和人审路径 passed_cases=3/3
queued_for_reindex=3
worker_reindexed=2
worker_events=7
worker_retry_scheduled=1
worker_timeout=1
worker_callback_rejected=1
worker_idempotency_key_present=3
worker_lease_token_present=1
semantic_review_handoff=3
safe_output_leak_markers=0		 published page
Knowledge Card Tool Gateway Ontology
Runtime Projection		 completed P0 tool gateway conformance knowledge-card current
2026-06-14
14d		 zero
local_python
no-paid-api		 high review 后的 knowledge card reindex/search 是否已经进入 Tool Gateway 调用路径 passed_cases=14/14
permission_leaks=0
reindex_queue_cases=4/4
ontology_registry_lifecycle_cases=3/3		 published page
Ontology Tool Gateway Conformance Ontology
Runtime Projection		 completed P0 ontology action policy conformance ontology current
2026-06-14
14d		 zero
local_python
no-paid-api		 high ontology action 是否已经进入 Tool Gateway 调用前的治理决策 passed_cases=10/10
ontology_action_policy_cases=10
unsafe_lifecycle_blocks=1/1		 published page
Domain Scope Eval Ontology
Runtime Projection		 completed P0 architecture isolation eval domain-topology current
2026-06-14
14d		 zero
local_python
no-paid-api		 high 同一套 Framework 能否同时服务个人、部门、项目三类私域，并阻断跨域泄漏 passed_cases=7/7
risk_probe_cases=4/4
stale_index_blocked=2/2
archived_project_lifecycle_filtered=1
router_score_log_cases=7
router_scorer_version=domain_router_feature_v1
router_feature_score_candidates=24
router_permission_filtered_libraries=10
safe_output_leak_markers=0
gateway_filtered_candidates=9
ontology_case_count=3
ontology_objects=7
ontology_rules=5
ontology_actions=7
ontology_writeback_event_types=3		 published page
Domain Router Feedback Eval Runtime Projection completed P0 router self-improvement eval context-routing current
2026-06-14
14d		 zero
local_python
no-paid-api		 high Context Router 能否从人工纠错事件中改进下一轮上下文库排序，同时不绕过权限 passed_cases=2/2
corrected_top1=2/2
feedback_event_count=1
rejected_library_selected=0
forbidden_library_selected=0		 published page
Real Team Context Benchmark Runtime Projection completed P0 sanitized team regression context-management current
2026-06-14
14d		 zero
local_python
no-paid-api		 high 真实团队讨论里暴露的问题，是否已经进入 Context Router、source closure、Connector 边界和权限过滤回归集 passed_cases=5/5
marker_checks=16
forbidden_selected=0
feedback_applied=10		 published page
Context Management Eval Runtime Projection completed P0 context management observability eval context-management current
2026-06-14
14d		 zero
local_python
no-paid-api		 medium 上下文管理是否能同时观察任务质量、token 成本、权限过滤和知识缺口 passed_cases=4/4
avg_token_savings=24.6%
permission_filtered_count=4
router_permission_filtered_libraries=4
trace_event_count=9
search_rank_log_case_count=4
search_rank_log_gateway_filtered_output_count=4
knowledge_gap_count=1
ask_event_count=1
pending_knowledge_card_count=1
router_scorer_version=domain_router_feature_v1
router_feature_score_candidates=12
safe_output_leak_markers=0		 published page
LoopSpec Demo Runtime Projection completed P0 closed-loop contract demo loop-engineering current
2026-06-14
14d		 zero
local_python
no-paid-api		 medium Framework 是否能用结构化 LoopSpec / LoopRun 表达封闭 loop、验证结果和 handoff 边界 loop_count=4
ready_for_handoff=2
completed_dry_run=2
knowledge_gap_count=1
ask_event_count=1
pending_knowledge_card_count=1
projection_retry_scheduled_count=1
projection_timeout_count=1
projection_callback_rejected_count=1
projection_idempotency_key_count=3
projection_lease_token_count=1
leak_marker_count=0
missing_artifact_count=0
stale_generated_count=0
missing_ci_gate_count=0		 published page
No-WeCom MVP Demo Evidence
Ontology
Runtime Projection		 completed P0 end-to-end MVP smoke mvp-runtime current
2026-06-14
14d		 zero
local_python
no-paid-api		 critical 没有企业微信接口时，本地 MVP 是否能跑通完整主链路 passed=true
ask_ontology_action=allow
ask_registry_event_count=2
context_router_baseline=org_directory
context_router_corrected=project_orgreorg_knowledge
context_router_feedback_applied=2
callback_ledger_recorded_count=1
callback_ledger_duplicate_count=1
callback_ledger_rejected_count=1
callback_ledger_safe_output_leak_count=0
callback_evidence_source_count=1
callback_evidence_registry_error_count=0
callback_evidence_feedback_event_count=1
callback_evidence_card_ref_count=1
feedback_event_count=1
rerouted_owner=crm-owner
review_ontology_action=allow
promote_ontology_action=allow
knowledge_card_registry_event_count=6
reindex_queue_status=ready_for_reindex
reindex_queue_ontology_action=allow
reindex_queue_registry_event_count=8
reindex_queue_indexed_count=1
reindex_queue_search_hit_count=1
reindex_queue_safe_output_leak_count=0
indexed_count=1
search_hit_count=1
governance_probe_count=5
blocked_probe_hit_count=0
restricted_team_hit_count=0
restricted_denied_action=deny
restricted_leak_marker_count=0		 published page
Context Layer Benchmark Runtime Projection completed P0 local risk benchmark context-architecture current
2026-06-14
14d		 zero
local_python
no-paid-api		 medium 渐进披露、RAG、分层混合谁更稳 tiered_hybrid_recall=100%
tiered_hybrid_gap_accuracy=100%		 published page
Agentic Search Option Benchmark Runtime Projection completed P0 option benchmark search current
2026-06-14
14d		 zero
local_python
no-paid-api		 medium P0 到底先用 Postgres、ES 还是向量库 selected_p0_option=tiered_markdown_postgres
scale_candidate=tiered_markdown_opensearch		 published page
Ask Router Simulation Ontology
Runtime Projection		 completed P0 local simulation ask-router current
2026-06-14
14d		 zero
local_python
no-paid-api		 high 证据不足时问谁、怎么问 top1=100%
safe_route=100%
throttle_pass=100%
duplicate_ask_suppressed=1
feedback_event_contract=implemented
local_feedback_event_log=implemented		 published page
Task Skill Package Eval Ontology completed P0 governance benchmark task-skills current
2026-06-14
14d		 zero
local_python
no-paid-api		 medium 任务技能包是否会误触发、膨胀或过期 guarded_precision=100%
token_reduction_vs_all_in=95%		 published page
Tool Gateway Safety Harness Runtime Projection completed P0 local safety harness tool-gateway current
2026-06-14
14d		 zero
local_python
no-paid-api		 critical MCP/Connector 工具边界是否能强制 schema、权限、审批、外连和输出净化 passed_cases=9/9
audit_secret_leaks=0		 published page
External Connector Action Gateway Runtime Projection completed P0 external action conformance tool-gateway current
2026-06-14
14d		 zero
local_python
no-paid-api		 critical 外部 Connector action 接入后，是否能强制 Tool Gateway、safe writeback 和泄漏边界 passed_cases=6/6
writeback_recorded=4
writeback_timeline_events=4
blocked_writeback_count=0
safe_payload_leaks=0		 published page
Connector Callback Ledger Evidence
Ontology
Runtime Projection		 completed P0 external callback conformance tool-gateway current
2026-06-14
14d		 zero
local_python
no-paid-api		 critical 外部 Connector 回调进入系统时，是否能签名校验、幂等去重、安全落 ledger，并避免源系统对象泄漏 passed_cases=6/6
recorded_callbacks=2
evidence_sources=2
ontology_registry_events=1
ontology_state=recorded
duplicate_suppressed=1
rejected_callbacks=3
safe_payload_leaks=0		 published page
GitHub Actions Run Ledger Runtime Projection completed P0 PR/docs health adapter contract loop-engineering current
2026-06-14
14d		 zero
local_python
no-paid-api		 medium GitHub Actions 运行状态能否安全投影到项目看板 Timeline passed_cases=3/3
timeline_events=3
success_runs=2
failure_runs=1
safe_payload_leaks=0		 published page

报告明细

Context Router Demo

  • id: context-router-demo
  • 状态：completed
  • 阶段：P0 local simulation
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：context-routing
  • Freshness：watch；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：low
  • 问题：路由是否能减少无关上下文
  • 运行命令：python scripts/context_router_demo.py --write-report
  • 数据：context router benchmark：vault/90-system/context-router-benchmark.json
  • 分析：analysis：vault/50-outputs/context-router-demo-analysis.md
  • 发布页：published page
  • 看板结论：路由能选中预期上下文库并节省约 12.9% prompt token，但这个结论价值有限；后续重点转向风险验证

本地路由实验能证明上下文库选择可以降低 prompt 输入，但结论价值有限，后续重点已转向权限、删除、旧新冲突和 gap 等风险实验。

关键结论：

  • 路由能降低无关上下文，但这不是当前最关键风险。
  • 更重要的是验证路由和检索是否会泄露权限、误用旧材料或错误硬答。

下一步：

  • 继续把上下文库路由接到真实 SearchConnector adapter。
  • 记录每次路由的候选库、命中原因、证据质量和 gap。

Ingestion Quality Demo

  • id: ingestion-quality-demo
  • 状态：completed
  • 阶段：P0 local risk benchmark
  • 分类：synthetic_internal_demo
  • 架构主线：Evidence
    Ontology
  • Owner：ingestion
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：入库清洗会不会丢事实
  • 运行命令：python scripts/ingestion_quality_demo.py --write-report
  • 数据：evidence registry and structured documents：vault/50-outputs/ingestion-quality-evidence-registry.json
  • 分析：analysis：vault/50-outputs/ingestion-quality-analysis.md
  • 发布页：published page
  • 看板结论：naive summary 事实召回 19%，structured ingestion 事实召回 100%；当前已先生成 8 条 Evidence source 和 raw snapshot，再投影为 ContextDocumentRecord

对比 naive summary 和 structured ingestion，证明过早摘要化会系统性丢失付款期限、负责人、权限提示和表格关系。

关键结论：

  • 摘要只能作为展示字段，不能替代原文、chunk、权限元数据和审计追溯。
  • Evidence source snapshot 和 source_hash 必须先于 ContextDocumentRecord 生成，才能保证下游检索投影可回查。
  • ContextDocumentRecord 已成为后续检索和 SearchConnector adapter 的输入边界。

下一步：

  • 增加 JSON 和表格的结构化字段映射。
  • 增加 PII 检测、客户名/合同号/财务字段识别和 field_mask 建议。

Retrieval Platform Benchmark

  • id: retrieval-platform-benchmark
  • 状态：completed
  • 阶段：P0 local risk benchmark
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：search
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：检索如何避免权限、删除、旧新冲突和 gap 错误
  • 运行命令：python scripts/retrieval_platform_benchmark.py --write-report
  • 数据：results：vault/50-outputs/retrieval-platform-benchmark-results.json
  • 分析：analysis：vault/50-outputs/retrieval-platform-benchmark-analysis.md
  • 发布页：published page
  • 看板结论：只做 ACL 不够，必须同时做 permission、lifecycle、confidence threshold 和 gap 判断

本地反例集覆盖权限泄漏、删除 chunk、superseded 旧材料、别名、精确编号和 gap 判断，验证检索不能只追求 Recall。

关键结论：

  • 权限过滤必须在 evidence 进入 prompt 前执行。
  • 只做 ACL 不够，还必须处理 lifecycle、confidence threshold 和 gap。

下一步：

  • 把同一反例集接到 Postgres FTS/pgvector adapter。
  • 把同一反例集接到 OpenSearch/ES adapter。

SearchConnector Conformance

  • id: search-connector-conformance
  • 状态：completed
  • 阶段：P0 adapter conformance
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：search
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：medium
  • 问题：真实检索 adapter 是否遵守最低安全和可解释 contract
  • 运行命令：python scripts/search_connector_conformance.py
  • 数据：results：vault/50-outputs/search-connector-conformance-results.json
  • 分析：analysis：vault/50-outputs/search-connector-conformance-analysis.md
  • 发布页：published page
  • 看板结论：in_memory 与 sqlite_fts 两个 connector 共 14 个 conformance cases 全部通过；Postgres/OpenSearch adapter skeleton 已接入可选注册，后续必须用真实服务复用同一验收集

把 adapter 共同验收 case 固化下来，当前 in_memory 和 sqlite_fts 两个 CI 可跑 connector 共 14 个 cases 全部通过；Postgres FTS/pgvector 与 OpenSearch/ES adapter skeleton 已接入可选注册，等待真实服务 live conformance。

关键结论：

  • 真实 adapter 必须通过同一 conformance suite，不能各自解释安全语义。
  • SQLite FTS 是 CI 可跑的本地 SQL/FTS adapter，不替代后续 Postgres/OpenSearch 外部服务对照。
  • Postgres/OpenSearch skeleton 只证明 contract 边界已进入代码，不证明外部服务性能、分词、索引传播或删除传播。

下一步：

  • 扩展路径、owner、存在性泄漏和 rank_log 字段完整性 case。
  • 接真实 Postgres 与 OpenSearch 测试服务后复用同一验收集，并补延迟、成本、rank_log 和删除传播指标。

Search Adapter State Benchmark

  • id: search-adapter-state-benchmark
  • 状态：completed
  • 阶段：P0 adapter state benchmark
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：search
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：真实检索投影 adapter 接入前，删除传播、权限变更、supersede 和 reindex 延迟会造成哪些 stale-index 风险
  • 运行命令：python scripts/search_adapter_state_benchmark.py --write-report
  • 数据：results：vault/50-outputs/search-adapter-state-benchmark-results.json
  • 分析：analysis：vault/50-outputs/search-adapter-state-benchmark-analysis.md
  • 发布页：published page
  • 看板结论：4 个 Search Adapter State Benchmark cases 全部通过；adapter matrix 覆盖 sqlite_fts、postgres_fts、opensearch，其中默认 CI 运行 sqlite_fts，Postgres/OpenSearch 在未配置 DSN/URL 时标记为 skipped_unavailable；删除、权限降级、supersede 的 stale-index window 均被检测，reindex 前暴露 3 个 stale hit，reindex 后 4/4 恢复安全；rank_log 已包含 generation、stale_index、过滤计数、adapter id、adapter kind、latency 和 cost units

用本地 SQLite FTS5 source/index split 模拟源数据删除、权限降级和 supersede 后索引尚未刷新的窗口；3 个 stale window 都被检测，3 个 reindex 前 stale hit 被暴露，4 个 case reindex 后恢复安全，rank_log contract 4/4 通过；Postgres/OpenSearch live adapter 可用性已进入结构化 adapter matrix。

关键结论：

  • 删除、权限降级和 supersede 都会产生源数据与索引之间的短暂不一致窗口；旧索引可能把过期或越权上下文装入任务。
  • 检索投影 adapter 必须暴露 source_generation、index_generation 和 stale_index，让上层在 stale 窗口选择降级、等待 reindex、报告 gap 或要求人工确认。
  • reindex 后，deleted 文档必须被 lifecycle filter 阻断，restricted 文档必须被 permission filter 阻断，superseded 文档默认不可见且只能显式 opt-in。
  • Postgres/OpenSearch live conformance 应复用同一 state benchmark，而不是只跑召回率。
  • 当前 adapter matrix 已明确 live adapter 是否可用和为何跳过；没有真实服务时不会把 skeleton 伪装成已验证。

下一步：

  • 在测试环境配置 HARNESS_POSTGRES_DSN / HARNESS_OPENSEARCH_URL 后，用 --include-live-adapters 跑同一 state benchmark，比较真实服务的删除传播、权限变更传播、reindex latency 和 cost units。
  • 把真实 adapter 的 stale state 接入 Context Router 的 projection_states，替换当前合成状态，并接入 Projection Remediation Queue 的真实 reindex worker。
  • 把 reindex queue 从本地 JSON 替换为可恢复 worker / Postgres table，并记录 retry、idempotency 和 adapter failure。

SearchConnector Tool Gateway

  • id: search-tool-gateway
  • 状态：completed
  • 阶段：P0 tool gateway conformance
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：tool-gateway
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：SearchConnector 是否已经作为工具能力进入 Tool Gateway 调用路径
  • 运行命令：python scripts/search_tool_gateway_conformance.py --write-report
  • 数据：results：vault/50-outputs/search-tool-gateway-results.json
  • 分析：analysis：vault/50-outputs/search-tool-gateway-analysis.md
  • 发布页：published page
  • 看板结论：7 个 SearchConnector Tool Gateway cases 全部通过；已验证 scope escalation 拒绝、namespaced scope、不安全 connector 输出过滤、rank_log 清洗、stale_index 运行时阻断、high severity gap receipt 复用 Projection Remediation item id，safe output 不泄露 source_uri

把 context.search、context.get_document、context.report_gap 包到 Tool Gateway 后，并用 7 个 case 验证 scope 子集检查、namespaced scope、输出后置过滤、rank_log 清洗、gap 审计、stale_index 运行时阻断和 remediation item id 复用。

关键结论：

  • SearchConnector 可以作为 Tool Gateway 后面的工具能力，而不是让 Agent 直接自由访问检索对象。
  • 请求中的 allowed_scopes 必须是用户 scope 的子集，不能由 Agent 自己扩大。
  • Tool Gateway adapter 需要在 SearchConnector 自身权限过滤之外再做输出后置过滤。
  • 已认证 person:*、dept:*、project:* 这类 namespaced scopes 可以进入通用检索工具网关。
  • stale_index=true 已从状态传播 benchmark 进入 runtime 策略：gateway 默认阻断本次检索 hits，只向 safe output 暴露 adapter/generation/latency/cost/context library 等安全状态字段，并通过 context.report_gap 记录带 Projection Remediation item id 的 high severity 缺口。

下一步：

  • 把真实 Postgres/OpenSearch adapter 接到同一 gateway conformance。
  • 把真实组织 IAM / 企业微信通讯录权限映射成 permission view 和 namespaced scopes。
  • 将 SearchConnector high severity gap receipt 接入真实 Projection Remediation worker / review adapter。

Context Router Stale Policy Eval

  • id: context-router-stale-policy
  • 状态：completed
  • 阶段：P0 stale-index risk policy
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：context-routing
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：Context Router 是否能按任务风险处理 stale_index 候选上下文库
  • 运行命令：python scripts/context_router_stale_policy_eval.py --write-report
  • 数据：results：vault/50-outputs/context-router-stale-policy-results.json
  • 分析：analysis：vault/50-outputs/context-router-stale-policy-analysis.md
  • 发布页：published page
  • 看板结论：4 个 Context Router Stale Policy cases 全部通过；低风险 stale context 可 allow_with_notice 并进入 selected context，中/高/关键风险 stale context 默认不进入 Agent prompt，分别要求人工确认、等待 reindex 或 block_and_report_gap；safe trace 泄漏标记为 0

把 stale_index=true 从 Tool Gateway 的统一阻断上移到 Context Router，按任务风险输出 allow_with_notice、require_human_confirmation、wait_for_reindex、block_and_report_gap 四类 action，并决定 stale 上下文是否进入 selected context。

关键结论：

  • stale_index=true 不再只有 Tool Gateway 的统一阻断策略；Context Router 已能按任务风险做分级处理。
  • 低风险任务可以 allow_with_notice，继续选入上下文，但 trace 会保留 stale action。
  • 中风险任务会 require_human_confirmation，默认不把 stale 上下文直接选入 Agent prompt。
  • 高风险任务会 wait_for_reindex，关键风险任务会 block_and_report_gap。
  • safe trace 只暴露 adapter id、generation、action 和计数，不暴露 source URI、owner 或内容 marker。

下一步：

  • 把真实 adapter 的 stale state 接入 Context Router 的 projection_states，替换当前合成状态。
  • 把 block_and_report_gap 生成的 Projection Remediation item 接到真实 reindex worker，并让 SearchConnector high severity gap receipt 复用同一个 item id。
  • 用真实团队任务标注 task risk，校准 low / medium / high / critical 的默认策略。

Projection Remediation Eval

  • id: projection-remediation
  • 状态：completed
  • 阶段：P0 stale projection remediation
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：search
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：critical
  • 问题：关键风险 stale projection 被 block 后，是否能进入统一补证、reindex 和人审路径
  • 运行命令：python scripts/projection_remediation_eval.py --write-report
  • 数据：results：vault/50-outputs/projection-remediation-results.json
  • 分析：analysis：vault/50-outputs/projection-remediation-analysis.md
  • 发布页：published page
  • 看板结论：Projection Remediation Eval 3/3 通过；关键风险 stale projection 会生成 queued_for_reindex 补证 item，本地 worker 可将 adapter result 转为 reindexed，也可在 waiting 超时后记录 timeout、进入 retry_scheduled、到期重开 attempt 并轮换 idempotency key；第二个 worker 不能抢占 active lease，错误 lease token callback 被拒绝且不改变状态；worker events=7，同步生成 pending Semantic Review handoff；safe output 泄漏标记为 0

把 Context Router 的 block_and_report_gap 关键风险决策接到本地 Projection Remediation Queue，并由本地 worker 根据 adapter result 更新 reindex 状态、记录事件、处理 timeout retry、attempt idempotency、lease owner 和 callback token 校验，同时生成 Semantic Review handoff，验证补证路径能同时服务 reindex、重试恢复、并发防重和人工安全确认。

关键结论：

  • block_and_report_gap 不再只停留在路由 trace，而是进入可恢复、可审计、可交接的补证队列。
  • Projection Remediation worker 已能处理 adapter success、waiting、timeout、retry_scheduled、dead_letter 和 callback rejection 边界，并通过 event log 记录 reindex 状态变化。
  • Projection Remediation worker retry / timeout / idempotency / lease token guard 已进入 LoopRun dry-run contract，后续要替换为真实持久化 worker。
  • Projection Remediation Item 负责 adapter reindex handoff，Semantic Review Item 负责人工确认和安全披露边界。
  • 当前实现只验证本地 contract；真实 Postgres/OpenSearch worker、企微/GitHub review adapter 仍需接入。

下一步：

  • 将当前本地 projection remediation worker 替换为真实 Postgres/OpenSearch reindex worker。
  • 将 Semantic Review handoff 接入真实企微或 GitHub review adapter。
  • 把 retry policy 的 lease、死信、幂等 key 和 callback token 写入真实持久化队列，并做并发锁、重复 callback 和 adapter error 回放测试。

Knowledge Card Tool Gateway

  • id: knowledge-card-tool-gateway
  • 状态：completed
  • 阶段：P0 tool gateway conformance
  • 分类：synthetic_internal_demo
  • 架构主线：Ontology
    Runtime Projection
  • Owner：knowledge-card
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：review 后的 knowledge card reindex/search 是否已经进入 Tool Gateway 调用路径
  • 运行命令：python scripts/knowledge_card_gateway_conformance.py --write-report
  • 数据：results：vault/50-outputs/knowledge-card-gateway-results.json
  • 分析：analysis：vault/50-outputs/knowledge-card-gateway-analysis.md
  • 发布页：published page
  • 看板结论：14 个 Knowledge Card Tool Gateway cases 全部通过；已验证 team search、scope escalation 拒绝、restricted card 不泄露、reindex 治理权限、review/promote 经过 OntologyToolGateway、本地 reindex queue 增量处理、queue processing 经过 OntologyToolGateway required scopes gate，review/promote 与 queue worker 前后态写入 ontology registry，以及 search/reindex/queue/registry safe output 不泄露对象 ID、owner、source_uri、路径、rank_log 存在性计数、错误路径或内容 marker

把 reviewed/promoted knowledge card 的 review/promote/reindex/search 包到 Tool Gateway，并让 knowledge_card.search 内部复用 context.search 的 SearchConnector Tool Gateway；当前扩展到 14 个 case，覆盖对象 ID、owner、source_uri、路径、rank_log 存在性计数、reindex 错误路径、review/promote lifecycle、本地 reindex queue safe output 泄漏、queue processing 的 OntologyToolGateway required scopes gate，以及 queue worker 前后态写入 ontology registry。

关键结论：

  • knowledge card search 不再直接暴露本地 SearchResponse，而是先过 Tool Gateway。
  • review/promote 路径已接入 OntologyToolGateway，并把 pending/reviewed/promoted lifecycle 写入 ontology object registry。
  • 全局 reindex 被视为治理动作，普通 team 用户不能触发。
  • search safe output 不返回 doc_id、source_uri、connector_id、source path、owner、reviewer 或候选/过滤计数。
  • reindex safe output 不返回 source path、card path、promoted path、owner、reviewer、skipped card 或错误路径；详细错误只保留在内部 index_result。
  • 本地 JSON reindex queue 已能表达 ready / waiting / indexed 状态，并把 ready card 处理成本次增量索引；queue safe output 只暴露状态或计数。
  • queue processing 已接入 OntologyToolGateway，缺少 ontology required_scopes 时不会运行 worker。
  • queue worker 前后态会写入 ontology object registry，safe output 只暴露 registry 计数，不暴露 object id。

下一步：

  • 把真实企微回调的身份、消息 ID、会话 ID 和签名校验纳入同一 gateway conformance。
  • 把 ontology registry 扩展到外部 Connector action，并把企微通讯录、投递和回调 adapter 接到当前 Ask Router topology binding 与 owner registry contract 后面。
  • 把 reindex queue 从本地 JSON 替换为可恢复的持久化 worker / Postgres table，并接真实 adapter。
  • 把 permission leak test 扩展到 registry 事件、worker retry 事件和增量 adapter 状态。

Ontology Tool Gateway Conformance

  • id: ontology-tool-gateway
  • 状态：completed
  • 阶段：P0 ontology action policy conformance
  • 分类：synthetic_internal_demo
  • 架构主线：Ontology
    Runtime Projection
  • Owner：ontology
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：ontology action 是否已经进入 Tool Gateway 调用前的治理决策
  • 运行命令：python scripts/ontology_tool_gateway_conformance.py --write-report
  • 数据：domain topology：domain/orgreorg-demo/domain-topology.json
  • 分析：analysis：vault/50-outputs/ontology-tool-gateway-analysis.md
  • 发布页：published page
  • 看板结论：10 个 Ontology Tool Gateway conformance cases 全部通过；已验证 personal、department、project 三类 ask action、ontology action 到 ToolPolicy 的映射、required_scopes 缺失拒绝、按 action type 判断对象 lifecycle、rule 未覆盖对象拒绝和 audited writeback 要求；Ask Router binding 已进入 domain-topology.json，route_ask_request_guarded 可按 topology task/context-library mapping 选择 action 与对象状态；OntologyToolGateway 已接入三类 Ask Router route 以及 Knowledge Card review、promote、reindex queue 的本地执行路径，pending card 可以 ask/review，reviewed card 可以 promote，queue worker lifecycle 已写入 ontology registry

把 ontology action 映射到 ToolPolicy，并在工具调用前验证 required_scopes、rule 覆盖、按 action type 判断对象 lifecycle 和 writeback 审计，证明 object/rule/action/writeback 已开始参与运行时治理；当前已覆盖 personal/department/project ask、reindex、review、promote 四类本地 action，Ask Router binding 已进入 domain-topology 配置。

关键结论：

  • ontology action 与 ToolPolicy 已形成同一套验收面，后续新增 action 必须有对应 tool_id、action_type 和 required_scopes。
  • 对象 lifecycle 必须按 action type 判断：pending knowledge card 可以 ask 或 review，但不能 promote 或 reindex。
  • writeback event type 必须要求审计，否则动作结果不会沉淀回研用测闭环。
  • OntologyToolGateway 已接入 personal / department / project 三类 Ask Router route，以及 Knowledge Card review、promote、reindex queue 的本地执行路径；worker 和 route 运行前会先验证 action、rule、scope、registry lifecycle 和 writeback。
  • Ask Router binding 已进入 domain-topology 配置，Framework 可以从客户 domain 读取 task/context-library 到 ask action/object state 的映射。

下一步：

  • 把 ontology registry 扩展到外部 Connector action，并把企微通讯录、投递和回调 adapter 接到当前 Ask Router topology binding 与 owner registry contract 后面。
  • 把 ontology action audit event 与统一审计日志、worker retry 和 human review 事件串起来。
  • 把 registry safe output 的泄漏检查扩展到真实 adapter 失败、重试和回放状态。

Domain Scope Eval

  • id: domain-scope-eval
  • 状态：completed
  • 阶段：P0 architecture isolation eval
  • 分类：synthetic_internal_demo
  • 架构主线：Ontology
    Runtime Projection
  • Owner：domain-topology
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：同一套 Framework 能否同时服务个人、部门、项目三类私域，并阻断跨域泄漏
  • 运行命令：python scripts/domain_scope_eval.py --write-report
  • 数据：results：vault/50-outputs/domain-scope-eval-results.json
  • 分析：analysis：vault/50-outputs/domain-scope-eval-analysis.md
  • 发布页：published page
  • 看板结论：personal、department、project 三类基础 demo 和 4 个风险探针全部通过；Domain Scope Eval 已接入 domain_router_feature_v1，7/7 输出 Context Router score log，24 个候选输出 feature breakdown；三个基础 demo 已引用 ontology contract，覆盖 object=7、rule=5、action=7、writeback=3；完整 topology contract 已扩展到 callback ledger object/writeback；故意不安全 connector 的 9 个越权候选输出被 Tool Gateway 过滤，safe output 泄漏标记为 0

用个人入职/报销、财务部门政策、OrgReOrg 项目开发三类合成 demo，加上跨部门项目、员工调岗、项目归档、权限变更 stale index 四个风险探针，验证 domain topology、最小 ontology contract、permission view、lifecycle、SearchConnector 和 Tool Gateway 的跨域隔离能力。

关键结论：

  • domain/ 必须表达组织、部门、人员、项目、任务、上下文库、路由和权限视图，而不是单一资料桶。
  • SearchConnector Tool Gateway 必须支持 person:*、dept:*、project:* 这类 namespaced scopes。
  • rank_log 也是泄漏面，必须清洗候选对象 ID、source URI、owner 和 debug note。
  • stale index 不能只靠检索层删除传播兜底；员工调岗、权限收回、项目归档都要求返回前按当前 permission view 和 lifecycle 二次过滤。
  • Domain Scope Eval 和 Context Management Eval 现在共用 domain_router_feature_v1；它不再只看关键词，而是输出可审计 feature breakdown。
  • 三个基础 demo 已引用 ontology contract；callback ledger object/writeback 由 Connector Callback Ledger 实验单独覆盖，object、rule、action 和 writeback event type 已进入 topology lint 与实验输出。

下一步：

  • 用真实团队问题和人工纠正日志校准 domain_router_feature_v1 的 feature 权重。
  • 把风险探针里的合成 stale index 替换成真实 adapter 的删除传播、重建延迟和权限变更事件。
  • 把 permission view 从 JSON 合约推进为可审计策略和运行时授权检查。
  • 后续如果接 embedding / learning-to-rank scorer，必须保持同一 permission view、feature trace、trace_log 和 Tool Gateway 边界。

Domain Router Feedback Eval

  • id: domain-router-feedback
  • 状态：completed
  • 阶段：P0 router self-improvement eval
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：context-routing
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：Context Router 能否从人工纠错事件中改进下一轮上下文库排序，同时不绕过权限
  • 运行命令：python scripts/domain_router_feedback_eval.py --write-report
  • 数据：feedback events：domain/orgreorg-demo/context-router-feedback-events.json
  • 分析：analysis：vault/50-outputs/domain-router-feedback-analysis.md
  • 发布页：published page
  • 看板结论：2 个 Domain Router feedback cases 全部通过；docs/vault 组织问题可从 org_directory 纠正到 project_orgreorg_knowledge；财务上下文即使被反馈标记相关，也仍被项目维护者 permission view 过滤

把 Context Router 人工纠错变成结构化 feedback event，下一轮路由把 expected/rejected context libraries 作为 feature score 纳入排序，同时继续由 permission view 决定最终能否进入 prompt。

关键结论：

  • 人工纠错事件应该进入 Context Router 的 feature trace，而不是停留在聊天记录。
  • 反馈只能改变排序，不能扩大当前用户的 permission view。
  • 同 task_id 的反馈可以跨问题措辞复用；跨任务才依赖问题相似度。
  • No-WeCom MVP Demo 现在也能展示上下文库路由被人工纠错后自我改进。

下一步：

  • 把真实团队问题继续追加到 context-router-feedback-events.json。
  • 接 Postgres/OpenSearch adapter 后复用同一 feedback fixture，观察真实检索层是否放大或缓解错误路由。
  • 把 feedback event 追加入口接到未来企业微信 review callback。

Real Team Context Benchmark

  • id: real-team-context-benchmark
  • 状态：completed
  • 阶段：P0 sanitized team regression
  • 分类：sanitized_team_discussion
  • 架构主线：Runtime Projection
  • Owner：context-management
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：真实团队讨论里暴露的问题，是否已经进入 Context Router、source closure、Connector 边界和权限过滤回归集
  • 运行命令：python scripts/real_team_context_benchmark.py --write-report
  • 数据：sanitized cases：domain/orgreorg-demo/real-team-context-benchmark.json
  • 分析：analysis：vault/50-outputs/real-team-context-benchmark-analysis.md
  • 发布页：published page
  • 看板结论：5 个真实团队问题回归 case 全部通过；docs/vault、Roadmap、公众号临时链接和 connector 边界问题均路由到 project_orgreorg_knowledge；财务上下文对 project-maintainer 被 permission view 过滤；16 个本地文档 marker 检查通过

从真实讨论中抽取 docs/vault、Roadmap 对齐、临时公众号链接封口、外部 connector 边界和财务权限隔离五类问题，固化成清洗后的回归集；当前 5/5 通过，16 个本地文档 marker 检查通过。

关键结论：

  • 真实讨论中的 docs/vault、Roadmap、外部来源封口、Connector 边界问题都应路由到项目知识库，而不是组织目录。
  • 人工纠错事件在真实问题措辞变化后仍能作为 Context Router feature 生效。
  • 财务上下文在项目维护者视角下会被 permission view 过滤；正确行为是显式过滤或产生 gap，而不是扩大上下文加载范围。
  • 临时公众号链接问题已经转成可检查的 source closure marker，避免再次用长时间搜索追逐不可稳定复现的链接。
  • 新增外部 Connector action contract 后，真实企微接入应复用现有 action / writeback / safe output 边界。

下一步：

  • 每次团队讨论暴露一个新误路由、误搜索或权限边界问题，都应追加到这个 benchmark。
  • 接入 Postgres/OpenSearch adapter 后，用同一批 case 检查真实检索投影是否放大噪声或泄漏对象存在性。
  • 企微接入后，把真实消息 ID、会话 ID、签名、回调状态只作为 adapter 内部字段，不进入 safe output。

Context Management Eval

  • id: context-management-eval
  • 状态：completed
  • 阶段：P0 context management observability eval
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：context-management
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：medium
  • 问题：上下文管理是否能同时观察任务质量、token 成本、权限过滤和知识缺口
  • 运行命令：python scripts/context_management_eval.py --write-report
  • 数据：results：vault/50-outputs/context-management-eval-results.json
  • 分析：analysis：vault/50-outputs/context-management-eval-analysis.md
  • 发布页：published page
  • 看板结论：4 个 Context Management cases 全部通过；已用 domain_router_feature_v1 生成 route trace 和 12 个候选 feature breakdown；已用 route_ask_request 生成 ask message、ask trace 和 pending knowledge card；平均 token 节省 24.6%，权限过滤候选数 4，router 权限过滤库数 4，trace event 数 9，SearchConnector rank_log case 数 4，gateway filtered output 数 4，knowledge gap 数 1，ask event 数 1，safe output 泄漏标记为 0

用合成 Domain Topology 和故意不安全 connector，把 Agentic Context Management 的最小充分上下文、路由评分、SearchConnector rank_log、权限过滤、knowledge gap、ask event 和 owner 建议变成可测量指标。

关键结论：

  • 知识构建和搜索是上下文管理的服务层，不是目标本身。
  • 最小充分上下文必须同时看 evidence coverage、token、权限过滤和 gap。
  • 权限不足时正确行为是显式 knowledge gap 和主动询问 owner，而不是扩大检索范围或硬答。
  • route trace、SearchConnector rank_log、ask event 和 pending knowledge card 是 Loop 状态的一部分，必须进入可观测指标。
  • route trace 现在由 domain_router_feature_v1 统一生成，Domain Scope Eval 与 Context Management Eval 共用同一 router contract 和 feature breakdown。
  • ask event 现在由 route_ask_request 统一生成，Context Management Eval 输出 pending knowledge card，企微接入只替换 delivery / callback adapter。

下一步：

  • 用真实团队问题和人工纠正日志校准 domain_router_feature_v1 的 feature 权重。
  • 把 route_ask_request 的本地消息投递替身接到真实 Ask Router / 企业微信消息事件，同时保持同一 ask message、knowledge card 和 trace contract。
  • 接入 Postgres/OpenSearch adapter 后继续输出同一 search_connector_rank_log，并补充延迟、索引成本、上下文 token 和人工纠正。

LoopSpec Demo

  • id: loop-spec-demo
  • 状态：completed
  • 阶段：P0 closed-loop contract demo
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：loop-engineering
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：medium
  • 问题：Framework 是否能用结构化 LoopSpec / LoopRun 表达封闭 loop、验证结果和 handoff 边界
  • 运行命令：python scripts/loop_spec_demo.py --write-report
  • 数据：spec：vault/90-system/loop-spec-demo.json
  • 分析：analysis：vault/50-outputs/loop-spec-demo-analysis.md
  • 发布页：published page
  • 看板结论：Context Gap Collection 与 PR/Docs Health 均为 ready_for_handoff；Knowledge Maintenance 和 Projection Remediation Retry 为 completed_dry_run；knowledge gap=1、ask event=1、pending knowledge card=1、projection retry scheduled=1、projection timeout=1、projection callback rejected=1、projection idempotency key=3、projection lease token=1、missing CI gate=0、stale generated=0

新增 LoopSpec / LoopRun 最小 contract，并用 Context Gap Collection、Knowledge Maintenance、PR/Docs Health、Projection Remediation Retry 四条 loop 分别验证主动补充 handoff、知识维护发布同步、PR/docs 合并前门禁和 worker retry/idempotency/lease callback contract。

关键结论：

  • Loop Engineering 必须落成结构化 LoopSpec 和 LoopRun，不能只停留在原则文档。
  • 没有企微接口或 live PR 状态时，正确状态是 ready_for_handoff，不是假装外部系统动作已完成。
  • LoopRun 可以把 context eval、ask event、pending knowledge card、验证结果、报告和项目看板连接起来。
  • Projection Remediation Retry Loop 可以把 worker timeout、retry schedule、attempt idempotency、lease token callback guard 和 safe output 边界作为本地 dry-run contract。
  • 知识维护也应该是 loop：生成物同步可以自动检查，语义过时必须进入人工 review handoff。
  • PR/Docs Health 也应该是 loop：CI 必须覆盖生成物 freshness、测试和 MkDocs strict build，真实 PR checks 与 review comments 后续交给 GitHub adapter。

下一步：

  • 把 requires_human_review_for_semantic_staleness 设计成可追踪 review queue。
  • 把 requires_real_github_pr_ci_status 接到 GitHub PR adapter。
  • 把 requires_live_reindex_worker_adapter 接到真实 Postgres/OpenSearch worker、持久化队列锁和 adapter callback。
  • 企微 adapter 就绪后，把 requires_real_wecom_delivery 替换为真实消息投递、签名校验和回调事件，并复用现有回复解析与 knowledge card review。

No-WeCom MVP Demo

  • id: no-wecom-mvp-demo
  • 状态：completed
  • 阶段：P0 end-to-end MVP smoke
  • 分类：synthetic_internal_demo
  • 架构主线：Evidence
    Ontology
    Runtime Projection
  • Owner：mvp-runtime
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：critical
  • 问题：没有企业微信接口时，本地 MVP 是否能跑通完整主链路
  • 运行命令：python scripts/no_wecom_mvp_demo.py --write-report
  • 数据：results：vault/50-outputs/no-wecom-mvp-demo-results.json
  • 分析：analysis：vault/50-outputs/no-wecom-mvp-demo-analysis.md
  • 发布页：published page
  • 看板结论：无企微端到端 MVP smoke 通过：初始 owner=finance-owner，ask_ontology_action=allow，ask_registry_event_count=2，Context Router 可从 baseline org_directory 纠正到 project_orgreorg_knowledge 且 feedback_applied=2，callback ledger recorded=1、duplicate=1、rejected=1、leak=0，callback Evidence source=1、registry_error=0、feedback_event_ref=1、knowledge_card_ref=1，问错人 feedback event=1，纠错后 owner=crm-owner，reviewed，review_ontology_action=allow，promote_ontology_action=allow，knowledge_card_registry_event_count=6，reindex_queue_status=ready_for_reindex，reindex_queue_ontology_action=allow，reindex_queue_registry_event_count=8，reindex_queue_indexed=1，reindex_queue_search_hit=1，reindex_queue_safe_output_leak=0，indexed=1，search_hit=1；5 个治理探针通过，blocked_probe_hit=0，restricted_team_hit=0，restricted_user_hit=1，team restricted-scope 请求被 deny，restricted leak marker=0

用临时 workspace 和合成组织目录跑通问题、搜索、gap、Ask Router、knowledge card、Connector Callback Ledger、callback Evidence Registry、问错人反馈、二次路由、reply、review、promote、reindex queue、OntologyToolGateway、Knowledge Card Tool Gateway reindex/search，并加入 pending、rejected、needs_changes、expired、restricted 五类治理反例。

关键结论：

  • 无企微条件下，当前本地 runtime 已能跑通一条完整的主动收集和知识外挂链路。
  • 本地 reply-text 现在先经过 Connector Callback Ledger：有效回调被记录，重复回调被幂等抑制，无效签名被拒绝，safe output 不泄露源系统对象。
  • 被采信的本地 reply callback 已先生成受限 Evidence source 和 raw snapshot，再投影成 AskFeedbackEvent，并把 Evidence source id 写回 pending knowledge card 审计字段。
  • ask-feedback-events.json 可以作为真实企微消息回调前的本地事件流替身。
  • 端到端 smoke 暴露并修复了同一任务 gap wording 变化导致 feedback event 不生效的问题。
  • Context Router 人工纠错事件已经并入主链路，可把 docs/vault 问题从 org_directory 纠正到 project_orgreorg_knowledge。
  • Ask Router route、review/promote 和 reindex queue 已先经过 OntologyToolGateway；registry 累计记录 ask、pending/reviewed/promoted 和 ready/indexed lifecycle；safe output 只暴露状态和计数，为真实 worker / adapter 留出可恢复边界。
  • review/promote/reindex/search 已经进入 Knowledge Card Tool Gateway 和 OntologyToolGateway，避免本地 demo 绕过未来工具边界。
  • pending、rejected、needs_changes 和 expired knowledge card 不会进入索引；restricted card 不会向 team 用户泄漏。

下一步：

  • 继续把真实团队问题样例加入端到端 demo，但保持合成数据和真实私域数据分离。
  • 扩展 permission probe 到对象存在性、owner、路径和 source_uri 的泄漏检查。
  • 把本地 JSON reindex queue 替换为可恢复 worker / Postgres table，验证 retry、幂等、延迟和 adapter 失败恢复。
  • 企微 adapter 接入时只替换 owner registry 来源、delivery/callback 来源，保留同一 Evidence Registry、Connector Callback Ledger、knowledge card、feedback event、reindex queue 和 gateway contract。

Context Layer Benchmark

  • id: context-layer-benchmark
  • 状态：completed
  • 阶段：P0 local risk benchmark
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：context-architecture
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：medium
  • 问题：渐进披露、RAG、分层混合谁更稳
  • 运行命令：python scripts/context_layer_benchmark.py --write-report
  • 数据：results：vault/50-outputs/context-layer-benchmark-results.json
  • 分析：analysis：vault/50-outputs/context-layer-benchmark-analysis.md
  • 发布页：published page
  • 看板结论：当前样例里 tiered_hybrid 最稳；单用 D2、单用 D3 都有明显边界

对比 D2 Markdown、D3 检索投影和分层混合路径，当前样例中 tiered_hybrid 最稳。

关键结论：

  • 单用 D2 和单用 D3 都有明显边界。
  • 运行时投影需要让 Agent 能从入口索引、稳定制品、检索投影和 Evidence Connector 逐级下探。

下一步：

  • 接入真实检索投影 adapter。
  • 接入 Evidence Connector 作为源系统下探路径。

Agentic Search Option Benchmark

  • id: agentic-search-option-benchmark
  • 状态：completed
  • 阶段：P0 option benchmark
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：search
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：medium
  • 问题：P0 到底先用 Postgres、ES 还是向量库
  • 运行命令：python scripts/agentic_search_option_benchmark.py --write-report
  • 数据：results：vault/50-outputs/agentic-search-option-benchmark-results.json
  • 分析：analysis：vault/50-outputs/agentic-search-option-benchmark-analysis.md
  • 发布页：published page
  • 看板结论：P0 默认 Markdown + Postgres FTS/pgvector；OpenSearch/ES 后置为规模化 adapter；纯向量库不作为核心默认

比较 Markdown、Postgres FTS/pgvector、OpenSearch/ES、纯向量库和分层方案后，P0 默认 Markdown + Postgres，OpenSearch/ES 作为规模化 adapter。

关键结论：

  • P0 不需要先上完整 ES/OpenSearch 运维栈。
  • 纯向量库不作为核心默认，因为权限、生命周期、精确编号和可解释性不足。

下一步：

  • 用真实 Postgres FTS/pgvector 测试服务跑 live conformance 和延迟/成本对照。
  • 用真实 OpenSearch/ES 测试服务跑 live conformance、索引传播和规模化查询对照。

Ask Router Simulation

  • id: ask-router-simulation
  • 状态：completed
  • 阶段：P0 local simulation
  • 分类：synthetic_internal_demo
  • 架构主线：Ontology
    Runtime Projection
  • Owner：ask-router
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：high
  • 问题：证据不足时问谁、怎么问
  • 运行命令：python scripts/ask_router_simulation.py --write-report
  • 数据：results：vault/50-outputs/ask-router-simulation-results.json
  • 分析：analysis：vault/50-outputs/ask-router-simulation-analysis.md
  • 发布页：published page
  • 看板结论：9 个合成场景中 Top1、Recall@3、安全路由、负反馈、节流和消息契约均为 100%，重复询问抑制数 1；AskFeedbackEvent 已支持 better_owner / not_owner 回复写入本地事件流并影响下一轮路由；owner registry 已统一为显式目录优先、Domain Topology fallback

用组织目录、系统领域、证据路径、职责关键词、负反馈、冷却窗口和问错人反馈事件做本地路由，验证主动询问的消息契约、候选选择、重复询问抑制和下一轮路由纠错。

关键结论：

  • 主动询问必须结合组织职责和上下文证据，而不是机械问当前用户。
  • 负反馈和节流规则是避免打扰的关键。
  • 冷却窗口内已问过 owner 时，本轮不应重复发送，也不应改问 requester 绕过节流。
  • 问错人反馈必须成为持久化事件，并在下一轮路由中前置更合适 owner、过滤原错误 owner。
  • 本地 orgreorg_demo --feedback-log / --ask-feedback-log 已能模拟企微回调事件流。

下一步：

  • 加入真实团队问题。
  • 把真实企业微信通讯录接入 owner registry contract，并把消息 ID、会话 ID、送达状态和问错人反馈接入 recent_ask_events / feedback event。

Task Skill Package Eval

  • id: task-skill-package-eval
  • 状态：completed
  • 阶段：P0 governance benchmark
  • 分类：synthetic_internal_demo
  • 架构主线：Ontology
  • Owner：task-skills
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：medium
  • 问题：任务技能包是否会误触发、膨胀或过期
  • 运行命令：python scripts/task_skill_package_eval.py --write-report
  • 数据：results：vault/50-outputs/task-skill-package-eval-results.json
  • 分析：analysis：vault/50-outputs/task-skill-package-eval-analysis.md
  • 发布页：published page
  • 看板结论：progressive_manifest_guarded 当前样例 100% 通过，平均 token 比 all-in 降约 95%；正式包必须有 manifest、negative_terms、status、verify 和安全字段

比较 all-in、keyword-only 和 progressive_manifest_guarded，验证任务技能包需要 manifest、negative_terms、status、verify 和安全字段。

关键结论：

  • 任务技能包适合作为本体层可执行知识对象，但必须有 manifest 和负例约束。
  • 过期包和误触发需要进入 dashboard。

下一步：

  • 接入任务包使用日志。
  • ask_router_review 高风险包已实体化；后续把问错人、节流、回复解析和 Tool Gateway safety case 纳入 usage dashboard。

Tool Gateway Safety Harness

  • id: tool-gateway-safety
  • 状态：completed
  • 阶段：P0 local safety harness
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：tool-gateway
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：critical
  • 问题：MCP/Connector 工具边界是否能强制 schema、权限、审批、外连和输出净化
  • 运行命令：python scripts/tool_gateway_safety.py --write-report
  • 数据：fixture：vault/90-system/tool-gateway-safety.json
  • 分析：analysis：vault/50-outputs/tool-gateway-safety-analysis.md
  • 发布页：published page
  • 看板结论：9 个 Tool Gateway safety cases 全部通过；已验证 schema hash、scope、R4 approval、R3 draft-only、SSRF/egress、输出脱敏和审计不泄密

本地 safety harness 用 9 个合成工具调用验证 allowlist、schema hash、scope、R4 审批、R3 draft-only、URL egress、输出脱敏和审计不泄密。

关键结论：

  • Tool Gateway 必须位于 MCP/Connector 之前，不能依赖提示词或模型自觉遵守权限。
  • 高风险写操作需要拆成 draft-only 与 require_approval 两条路径。
  • 输出净化和审计净化同样重要，审计日志不能保存原始 token、cookie、password 或 private key。

下一步：

  • 把 knowledge card reindex 和后续企微 connector 都包到 Tool Gateway 调用路径后面。
  • 扩展 permission leak test：无权限用户不能看到内容、路径、owner 或对象存在性。
  • 增加真实 MCP server adapter 的 schema、timeout、错误码和输出 schema contract test。

External Connector Action Gateway

  • id: external-connector-action-gateway
  • 状态：completed
  • 阶段：P0 external action conformance
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：tool-gateway
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：critical
  • 问题：外部 Connector action 接入后，是否能强制 Tool Gateway、safe writeback 和泄漏边界
  • 运行命令：python scripts/external_connector_action_conformance.py --write-report
  • 数据：fixture：vault/90-system/external-connector-actions.json
  • 分析：analysis：vault/50-outputs/external-connector-action-analysis.md
  • 发布页：published page
  • 看板结论：6 个 External Connector Action Gateway cases 全部通过；允许或 draft-only 的 4 个 case 写入安全 writeback 并投影到 project status event timeline；缺 scope 和缺 approval 的外部动作不写成功事件；safe output / writeback / audit payload 未泄露原始消息 ID、会话 ID、URL、owner、PR/commit 或业务对象 ID

用合成企微、GitHub 和 CRM action 验证外部响应不能直接进入模型；允许执行或 draft-only 后只写安全 writeback event，且 safe output / writeback 不暴露消息 ID、会话 ID、URL、owner、业务对象 ID 或正文。

关键结论：

  • 外部 Connector action 不能把源系统响应直接暴露给 Agent；只能暴露状态、计数、warning 数和安全指标。
  • writeback event 可以保留 connector_id、action_id、状态和外部引用 hash，但不能保存原始消息 ID、会话 ID、URL、owner 或业务对象 ID。
  • draft-only 写操作可以进入内部草稿 / review 队列，但不应被视为已经写入源系统。
  • R4 外部动作没有 approval_id 时不会生成 writeback；获批后也只返回安全状态和计数。
  • 已记录的 writeback event 可以作为 project status event timeline 的安全事件源。
  • 企微 adapter 后续只需要替换 delivery / callback 实现，仍然复用这个 action contract、Tool Gateway 和 writeback 边界。

下一步：

  • 把企微通讯录、消息投递和回调 adapter 按这个 contract 接入，而不是绕过 Tool Gateway。
  • 把 writeback event 继续落到 ontology registry 的真实持久化表，并接入 worker retry / callback 的同一事件链。
  • 增加 timeout、retry、idempotency key、callback signature 和 source-system permission 的真实 adapter conformance。

Connector Callback Ledger

  • id: connector-callback-ledger
  • 状态：completed
  • 阶段：P0 external callback conformance
  • 分类：synthetic_internal_demo
  • 架构主线：Evidence
    Ontology
    Runtime Projection
  • Owner：tool-gateway
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：critical
  • 问题：外部 Connector 回调进入系统时，是否能签名校验、幂等去重、安全落 ledger，并避免源系统对象泄漏
  • 运行命令：python scripts/connector_callback_ledger_conformance.py --write-report
  • 数据：callback evidence registry：vault/50-outputs/connector-callback-evidence-registry.json
  • 分析：analysis：vault/50-outputs/connector-callback-ledger-analysis.md
  • 发布页：published page
  • 看板结论：6 个 Connector Callback Ledger cases 全部通过；2 条有效回调安全落 ledger 并生成受限 Evidence source/raw snapshot，1 条重复回调被幂等抑制，3 条无效签名、过期时间戳或缺字段回调被拒绝；ontology registry 记录 ledger-connector-callback state=recorded、event_count=1；safe output / ledger event 未泄露原始消息 ID、会话 ID、URL、owner、run_id 或 commit sha

用合成企微和 GitHub callback 验证外部回调不能直接更新知识库或暴露给 Agent；回调必须通过 HMAC 签名、时间窗、必填字段和 idempotency key，重复回调只返回 duplicate，safe output / ledger event 不暴露消息 ID、会话 ID、URL、owner、run_id、commit sha 或正文。

关键结论：

  • 外部回调不应直接更新知识库或暴露给 Agent；必须先过签名、时间窗、必填字段和幂等校验。
  • 重复回调只能返回 duplicate，不追加 ledger event，避免源系统重试造成重复沉淀或重复通知。
  • Ledger 只保存 connector、callback type、状态、外部引用 hash、安全指标和 warning 数，不保存消息 ID、会话 ID、URL、owner、PR/commit、业务对象 ID 或正文。
  • 被采信且 recorded 的回调已生成受限 Evidence source、raw snapshot 和 source hash；重复、无效签名、过期或缺字段回调不会进入 Evidence。
  • Callback ledger conformance 已把 ledger-connector-callback 写入 ontology registry，形成可审计 writeback event。
  • 企微真实 adapter 后续只替换签名来源、消息字段和投递 API，仍然复用 callback ledger 与安全输出约束。

下一步：

  • 把 worker retry、semantic review 和真实企微 callback 接入同一 project status event timeline。
  • 用真实 adapter 补 timeout、retry、签名 header、消息 ID、会话 ID、source-system permission 和删除传播状态的泄漏检查。
  • 继续把 callback Evidence source 作为真实企微回复、GitHub checks 和业务系统回写事件进入知识沉淀链路的统一入口。

GitHub Actions Run Ledger

  • id: github-actions-run-ledger
  • 状态：completed
  • 阶段：P0 PR/docs health adapter contract
  • 分类：synthetic_internal_demo
  • 架构主线：Runtime Projection
  • Owner：loop-engineering
  • Freshness：current；checked_at=2026-06-14；review_after_days=14
  • Cost：zero；runtime=local_python；paid_api=false；deterministic local script; no paid API
  • Risk：medium
  • 问题：GitHub Actions 运行状态能否安全投影到项目看板 Timeline
  • 运行命令：python scripts/github_actions_run_ledger.py --write-report
  • 数据：fixture：vault/90-system/github-actions-runs.json
  • 分析：analysis：vault/50-outputs/github-actions-run-ledger-analysis.md
  • 发布页：published page
  • 看板结论：3 个 GitHub Actions Run Ledger cases 全部通过；输出 3 条 timeline event，其中 success=2、failure=1、unsafe_payload_leaks=0；ALPC91 mirror 失败和修复成功可以被同一 PR/Docs Health 事件流表达

用本次 ALPC91 mirror GitHub Actions 失败与修复流程的脱敏样例，验证 workflow run 可被投影为安全项目事件：失败 run、修复成功 run 和团队 PR 成功 run 均进入同一 Timeline，且不泄露 run id、完整 URL 或完整 commit sha。

关键结论：

  • GitHub Actions run 不能把原始 run id、完整 URL、完整 commit sha 或 job 日志直接投到公开看板；看板只需要 workflow、branch、短 SHA、状态、结论、耗时和 hash 引用。
  • 同一 PR/Docs Health Loop 可以表达失败和修复：失败 run 进入 github-actions-run-failure，修复 run 进入 github-actions-run-success。
  • ALPC91 发布镜像、团队仓库 PR 检查和未来 Cloudflare 构建都应先投影为安全 runtime event，再由看板决定是否触发 review、重试或 handoff。
  • 当前仍是本地 fixture contract，不是 live GitHub API adapter；下一步应由 gh 或 GitHub App 拉取真实 run，再复用同一脱敏和 timeline contract。

下一步：

  • 把 gh run list / GitHub App webhook 接到同一 ledger contract，替换合成 fixture。
  • 增加 job annotation 摘要 adapter，但仍只输出安全错误类别和文件位置，不输出完整日志或原始 URL。
  • 把失败 run 事件接入 Semantic Review Queue 或 LoopRun retry policy，让 PR/Docs Health Loop 能自动提出下一步动作。