showcase-catalog.json

{
  "schema_version": "loopx_showcase_catalog_v1",
  "updated_at": "2026-10-14",
  "redaction_policy": {
    "public_repo_may_include": [
      "sanitized domain labels",
      "reusable control-plane patterns",
      "synthetic demos",
      "explicit evidence boundaries",
      "owner-approved user feedback excerpts with hard-sensitive details removed"
    ],
    "public_repo_must_not_include": [
      "private document links",
      "unapproved internal screenshots",
      "unredacted raw chats",
      "raw benchmark task text",
      "private repositories",
      "local filesystem paths",
      "credentials",
      "unpublished domain artifacts"
    ]
  },
  "source_coverage": [
    {
      "source_key": "cpp-algorithm-accuracy",
      "disposition": "promoted_case",
      "case_id": "2026-07-cpp-accuracy-long-run",
      "reason": "The report includes a concrete >13h runtime, stated intervention level, outcome, and mechanism evidence."
    },
    {
      "source_key": "four-day-unattended-agent",
      "disposition": "promoted_case",
      "case_id": "2026-07-four-day-unattended-agent",
      "reason": "The report states four days without human intervention and identifies useful work plus a reporting capability."
    },
    {
      "source_key": "public-engine-refactor",
      "disposition": "promoted_case",
      "case_id": "2026-07-public-engine-refactor",
      "reason": "The user report is backed by a public issue and seven merged pull requests."
    },
    {
      "source_key": "small-request-relief",
      "disposition": "feedback_signal_only",
      "case_id": null,
      "reason": "Useful satisfaction signal, but it has no duration, intervention, or independently inspectable outcome."
    },
    {
      "source_key": "ecommerce-24x7-interest",
      "disposition": "not_promoted",
      "case_id": null,
      "reason": "This is prospective demand for seller analytics and competitor monitoring, not a realized LoopX outcome."
    },
    {
      "source_key": "peer-harness-assessment",
      "disposition": "not_promoted",
      "case_id": null,
      "reason": "The material is a positive assessment and a comparable harness report, not evidence that the referenced workloads used LoopX."
    },
    {
      "source_key": "vllm-pr-54951-public-workflow",
      "disposition": "promoted_case",
      "case_id": "2026-10-vllm-long-context-optimization",
      "reason": "The author explicitly names LoopX as workflow engine in public October 13, 2026 posts; upstream PR #54951 independently establishes a merge. Reported measurements retain their conditions and limits."
    }
  ],
  "cases": [
    {
      "id": "2026-07-cpp-accuracy-long-run",
      "date": "2026-07",
      "title": "13+ hour C++ algorithm accuracy run",
      "status": "owner_approved_user_evidence_case",
      "case_type": "independent_user",
      "evidence_strength": "user_report_with_public_method_reference",
      "case_page": "docs/showcases/cases/independent-cpp-accuracy-long-run.md",
      "demo_command": null,
      "domain": "complex-cpp-algorithm",
      "audience": [
        "engineering-lead",
        "long-running-agent-operator",
        "C++ developer"
      ],
      "pattern_tags": [
        "independent_user",
        "13h_plus_run",
        "vision_replan",
        "public_research",
        "evidence_retention"
      ],
      "headline": "An independent user reported a >13h multi-stage C++ accuracy task that stayed on goal, found a public code-memory tool, and improved the final precision.",
      "problem": "A complex C++ algorithm had a precision problem, while direct long-running agent attempts risked parameter thrashing, local-detail drift, and repeated context compression.",
      "loopx_behavior": [
        "kept the multi-stage work aligned to the declared vision for more than 13 hours",
        "triggered public research when the current route no longer appeared able to satisfy the vision",
        "selected a public codebase-memory MCP for C++ call-graph and coupling analysis",
        "retained experiment evidence and an explanation of the final approach"
      ],
      "runtime_signal": {
        "duration": ">13h",
        "agent_scale": "one long-running agent reported",
        "human_intervention": "no parameter micromanagement or repeated local redirection reported during the multi-stage run"
      },
      "user_value": "The user reported a clear precision improvement, less context compression, and an explanation that made the result and experiment path understandable after the run.",
      "evidence_links": [
        {
          "label": "codebase-memory-mcp",
          "url": "https://github.com/DeusData/codebase-memory-mcp",
          "kind": "public_method_reference"
        }
      ],
      "evidence_assets": [
        {
          "path": "docs/assets/showcases/user-feedback/cpp-accuracy-13h-user-report.jpg",
          "alt": "Authorized user feedback reporting a LoopX C++ algorithm run lasting more than 13 hours with improved precision and retained evidence",
          "caption": "Source: an owner-approved message excerpt from the LoopX public Lark developer group. Runtime and outcome are user-reported; the public MCP reference is independently inspectable."
        },
        {
          "path": "docs/assets/showcases/user-feedback/cpp-accuracy-public-research-user-report.jpg",
          "alt": "Authorized follow-up explaining that LoopX replan triggered public research and found a code-memory MCP",
          "caption": "Source: an owner-approved follow-up message excerpt from the same LoopX public Lark developer group, describing the public-research transition."
        }
      ],
      "evidence_boundary": "Owner-approved message excerpts from the LoopX public Lark developer group and a public tool reference; the project repository, raw run state, prompts, experiment data, and performance measurements remain private.",
      "showcase_table": {
        "proof_point": "A >13h engineering run can remain aligned, change method through public research, and retain an understandable evidence trail.",
        "loopx_intervention": "vision alignment, replan, public research, evidence retention"
      },
      "frontend_card": {
        "visual_metaphor": "a long C++ investigation changes tools without losing its target",
        "primary_metric_hint": ">13h user-reported run with improved final precision",
        "badges": [
          "Independent user",
          ">13h",
          "C++ accuracy"
        ],
        "story_beats": [
          "a complex algorithm accuracy problem resisted the initial route",
          "LoopX preserved the vision while replanning",
          "public research found a code-memory tool",
          "the user reported improved precision and retained evidence"
        ]
      },
      "evidence_metrics": [
        {
          "value": ">13h",
          "labels": {
            "zh": "用户报告运行时长",
            "en": "user-reported runtime"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "公开工具引用",
            "en": "public tool reference"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "参数微操报告",
            "en": "parameter-micromanagement reports"
          }
        }
      ],
      "localizations": {
        "zh": {
          "title": "13+ 小时 C++ 算法精度修复",
          "headline": "外部用户报告：超过 13 小时的多阶段任务保持目标一致，并通过公开研究找到新工具、提升最终精度。",
          "problem": "一个复杂 C++ 算法存在精度问题；直接长程执行容易出现参数反复调整、局部细节漂移和上下文反复压缩。",
          "proof_point": "长程工程任务可以在更换方法时不丢失目标，并保留可解释的证据链。",
          "loopx_intervention": "vision 对齐、replan、public research、证据保留",
          "loopx_behavior": [
            "超过 13 小时的多阶段工作持续对齐已声明的 vision",
            "当前路径无法继续满足 vision 时触发 public research",
            "选择公开 codebase-memory MCP 分析 C++ 调用关系和耦合",
            "保留实验证据与最终方案解释"
          ],
          "user_value": "用户报告最终精度明显提升、上下文压缩减少，并能在运行结束后理解过程与方案选择。",
          "evidence_boundary": "来自 LoopX 公开飞书开发群、经 owner 授权的消息摘录与公开工具引用；项目仓库、原始运行状态、prompt、实验数据和性能测量仍保持私有。"
        }
      },
      "interactive_page": "docs/showcases/cases/independent-cpp-accuracy-long-run.html",
      "interactive_page_zh": "docs/showcases/cases/independent-cpp-accuracy-long-run.html",
      "interactive_page_en": "docs/showcases/cases/independent-cpp-accuracy-long-run.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/independent-cpp-accuracy-long-run.html",
        "en": "docs/showcases/cases/independent-cpp-accuracy-long-run.en.html"
      },
      "showcase_rank": 1
    },
    {
      "id": "2026-07-four-day-unattended-agent",
      "date": "2026-07",
      "title": "Four-day unattended agent run",
      "status": "owner_approved_user_evidence_case",
      "case_type": "independent_user",
      "evidence_strength": "user_report_only",
      "case_page": "docs/showcases/cases/independent-four-day-unattended-agent.md",
      "demo_command": null,
      "domain": "long-running-agent-operations",
      "audience": [
        "operator",
        "agent-platform-developer",
        "engineering-lead"
      ],
      "pattern_tags": [
        "independent_user",
        "four_day_run",
        "unattended_execution",
        "weekly_reporting"
      ],
      "headline": "An independent user reported that an agent ran for four days without human intervention, continued useful work, and exposed a weekly-report capability.",
      "problem": "Long-running agents often need repeated prompting, and operators cannot easily tell whether unattended work is still useful.",
      "loopx_behavior": [
        "kept the task active across a four-day window",
        "allowed the agent to continue without reported human intervention",
        "made the accumulated work discussable through a periodic report surface"
      ],
      "runtime_signal": {
        "duration": "4d",
        "agent_scale": "one long-running agent reported",
        "human_intervention": "none reported during the four-day run"
      },
      "user_value": "The user described the agent as doing valuable work rather than merely staying alive, while a weekly report gave the operator a way to inspect progress later.",
      "evidence_links": [],
      "evidence_assets": [
        {
          "path": "docs/assets/showcases/user-feedback/four-day-unattended-user-report.jpg",
          "alt": "Redacted authorized chat excerpt reporting a four-day LoopX agent run without human intervention",
          "caption": "Source: an owner-approved message excerpt from the LoopX public Lark developer group, cropped to remove chat identity and unrelated reporting context. All claims remain user-reported."
        }
      ],
      "evidence_boundary": "Owner-approved message excerpt from the LoopX public Lark developer group only; the workload, repository, run history, report contents, and unselected chat context remain private.",
      "showcase_table": {
        "proof_point": "A user observed four days of unattended work and judged the work useful, with a later reporting surface available for inspection.",
        "loopx_intervention": "durable task state, unattended continuation, periodic reporting"
      },
      "frontend_card": {
        "visual_metaphor": "an unattended work loop advances across four days and returns a report",
        "primary_metric_hint": "4d without reported human intervention",
        "badges": [
          "Independent user",
          "4 days",
          "Unattended"
        ],
        "story_beats": [
          "the operator left the task running",
          "the agent continued for four days",
          "the user judged the work valuable",
          "a weekly report offered a later inspection point"
        ]
      },
      "evidence_metrics": [
        {
          "value": "4d",
          "labels": {
            "zh": "用户报告运行时长",
            "en": "user-reported runtime"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "报告的人工干预",
            "en": "reported human interventions"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "周期报告能力",
            "en": "periodic report surface"
          }
        }
      ],
      "localizations": {
        "zh": {
          "title": "4 天无人干预运行",
          "headline": "外部用户报告：Agent 在没有人工干预的情况下连续运行 4 天，并持续处理有价值的工作。",
          "problem": "长程 Agent 往往需要反复催促，operator 也难以判断无人值守期间是否仍在做有价值的工作。",
          "proof_point": "长程 Agent 不只是保持存活，还需要让用户看见它是否在做有价值的工作。",
          "loopx_intervention": "持久任务状态、无人值守续跑、周期报告",
          "loopx_behavior": [
            "任务在 4 天窗口内持续保持 active",
            "Agent 在用户报告的零人工干预下继续推进",
            "通过周期报告为后续检查提供入口"
          ],
          "user_value": "用户认为 Agent 在持续做有价值的工作，而周期报告让 operator 可以稍后检查进度。",
          "evidence_boundary": "仅包含来自 LoopX 公开飞书开发群、经 owner 授权并脱敏的消息摘录；工作负载、仓库、运行历史、报告内容和未选取的聊天上下文仍保持私有。"
        }
      },
      "interactive_page": "docs/showcases/cases/independent-four-day-unattended-agent.html",
      "interactive_page_zh": "docs/showcases/cases/independent-four-day-unattended-agent.html",
      "interactive_page_en": "docs/showcases/cases/independent-four-day-unattended-agent.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/independent-four-day-unattended-agent.html",
        "en": "docs/showcases/cases/independent-four-day-unattended-agent.en.html"
      },
      "showcase_rank": 2
    },
    {
      "id": "2026-07-public-engine-refactor",
      "date": "2026-07",
      "title": "Public engine refactor across seven merged PRs",
      "status": "public_repository_plus_user_report_case",
      "case_type": "independent_user",
      "evidence_strength": "public_repository_plus_user_report",
      "case_page": "docs/showcases/cases/independent-public-engine-refactor.md",
      "demo_command": null,
      "domain": "repository-refactor",
      "audience": [
        "maintainer",
        "engineering-lead",
        "long-running-agent-operator"
      ],
      "pattern_tags": [
        "independent_user",
        "public_repository",
        "seven_prs",
        "incremental_refactor",
        "user_reported_scale"
      ],
      "headline": "A user attributed a public Engine decomposition to LoopX; the repository shows the work landing incrementally through seven merged PRs.",
      "problem": "A monolithic Engine mixed roughly nine responsibility areas and about sixty methods, making behavioral refactoring difficult to review and test.",
      "loopx_behavior": [
        "kept the decomposition anchored to one explicit public refactor goal",
        "split the work across independently reviewable component extractions",
        "allowed later stages to reuse the public issue as a durable coordination point",
        "preserved incremental mergeability instead of producing one giant refactor diff"
      ],
      "runtime_signal": {
        "duration": "multi-week public PR sequence",
        "agent_scale": "not reported",
        "human_intervention": "maintainer review and merge remained present; the user did not claim a fully unattended run",
        "token_scale": "1B+ tokens, user-reported and not independently verified"
      },
      "user_value": "The public repository shows seven related PRs merged into a staged facade-and-components refactor; the user described the LoopX-driven sequence as successful and high quality.",
      "evidence_links": [
        {
          "label": "Refactor issue #166",
          "url": "https://github.com/zilliztech/mfs/issues/166",
          "kind": "public_goal_and_design"
        },
        {
          "label": "PR #131",
          "url": "https://github.com/zilliztech/mfs/pull/131",
          "kind": "merged_pull_request"
        },
        {
          "label": "PR #137",
          "url": "https://github.com/zilliztech/mfs/pull/137",
          "kind": "merged_pull_request"
        },
        {
          "label": "PR #160",
          "url": "https://github.com/zilliztech/mfs/pull/160",
          "kind": "merged_pull_request"
        },
        {
          "label": "PR #164",
          "url": "https://github.com/zilliztech/mfs/pull/164",
          "kind": "merged_pull_request"
        },
        {
          "label": "PR #171",
          "url": "https://github.com/zilliztech/mfs/pull/171",
          "kind": "merged_pull_request"
        },
        {
          "label": "PR #175",
          "url": "https://github.com/zilliztech/mfs/pull/175",
          "kind": "merged_pull_request"
        },
        {
          "label": "PR #176",
          "url": "https://github.com/zilliztech/mfs/pull/176",
          "kind": "merged_pull_request"
        }
      ],
      "evidence_assets": [],
      "evidence_boundary": "The issue and seven merged PRs are public repository evidence. LoopX attribution, perceived quality, and the 1B+ token scale are owner-approved user reports rather than independently verified repository facts.",
      "showcase_table": {
        "proof_point": "One public refactor goal landed as seven merged PRs instead of a monolithic change.",
        "loopx_intervention": "durable goal, staged todo sequence, PR-sized delivery, evidence-backed continuation"
      },
      "frontend_card": {
        "visual_metaphor": "one monolithic engine separates into reviewable components across seven merge points",
        "primary_metric_hint": "7 merged PRs in a public repository",
        "badges": [
          "Independent user",
          "7 merged PRs",
          "Public repo"
        ],
        "story_beats": [
          "a public issue defined the target architecture",
          "component extractions landed incrementally",
          "seven related PRs merged",
          "user-reported scale is kept separate from public repository facts"
        ]
      },
      "evidence_metrics": [
        {
          "value": "7",
          "labels": {
            "zh": "公开合并 PR",
            "en": "public merged PRs"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "公开架构目标",
            "en": "public architecture goal"
          }
        },
        {
          "value": "1B+",
          "labels": {
            "zh": "用户报告 token 规模",
            "en": "user-reported token scale"
          }
        }
      ],
      "localizations": {
        "zh": {
          "title": "公开 Engine 重构：7 个合并 PR",
          "headline": "外部用户将一次公开 Engine 拆分归因于 LoopX；仓库证据显示相关工作通过 7 个 PR 渐进合并。",
          "problem": "一个 Engine 混合约 9 类职责和约 60 个方法，行为保持型重构难以测试、审阅和一次性合并。",
          "proof_point": "一个公开重构目标可以拆成 7 个可独立 review、可合并的 PR。",
          "loopx_intervention": "持久目标、分阶段 todo、PR-sized delivery、证据续跑",
          "loopx_behavior": [
            "用一个公开 issue 固定目标架构",
            "把组件抽取拆成可独立 review 的阶段",
            "后续阶段继续复用公开 issue 作为协调点",
            "通过 PR-sized delivery 避免单个巨型重构 diff"
          ],
          "user_value": "公开仓库显示 7 个相关 PR 已合并；用户将这组渐进式重构归因于 LoopX，并评价成功率和质量较好。",
          "evidence_boundary": "Issue 和 7 个合并 PR 属于公开仓库证据；LoopX 归因、主观质量和 10 亿+ token 规模来自经 owner 授权的用户报告，并非独立验证事实。"
        }
      },
      "interactive_page": "docs/showcases/cases/independent-public-engine-refactor.html",
      "interactive_page_zh": "docs/showcases/cases/independent-public-engine-refactor.html",
      "interactive_page_en": "docs/showcases/cases/independent-public-engine-refactor.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/independent-public-engine-refactor.html",
        "en": "docs/showcases/cases/independent-public-engine-refactor.en.html"
      },
      "showcase_rank": 3
    },
    {
      "id": "2026-10-vllm-long-context-optimization",
      "date": "2026-10-13",
      "title": "vLLM long-context optimization merged upstream",
      "status": "public_repository_plus_user_report_case",
      "case_type": "independent_user",
      "evidence_strength": "public_repository_plus_user_report",
      "case_page": "docs/showcases/cases/independent-vllm-long-context-optimization.md",
      "demo_command": null,
      "domain": "inference-performance-optimization",
      "audience": [
        "maintainer",
        "inference-engineer",
        "long-running-agent-operator"
      ],
      "pattern_tags": [
        "independent_user",
        "public_repository",
        "continuous_exploration",
        "validation",
        "upstream_delivery"
      ],
      "headline": "Zheng Cai reports LoopX as the workflow engine behind continuous vLLM optimization; the resulting sparse-indexer PR merged upstream. Reported +32.59% total-token throughput: GLM-5.3-Flash, 1M input, 4×H200, TP4, C1.",
      "problem": "Inference optimization requires repeated profiling, paper/code research, experiments, correctness checks, and review. The author reports LoopX as the workflow engine for this process; validation across models and workloads remains substantial engineering work.",
      "loopx_behavior": [
        "Author reports using LoopX as the workflow engine for an agent-driven vLLM inference-optimization framework.",
        "Author describes profiling, paper/code research, hypotheses, experiments, and correctness/speed measurement.",
        "Author attributes cost-balanced sparse-indexer query-row sharding to continuous iteration.",
        "Upstream PR #54951 merged on October 11, 2026; the author retains validation, review follow-up, and maintenance ownership."
      ],
      "runtime_signal": {
        "duration": "not reported",
        "agent_scale": "not reported",
        "human_intervention": "not quantified; author owns validation, review follow-up, and maintenance"
      },
      "user_value": "Continuing exploration and validation produced an inspectable upstream optimization. The LoopX maintainer highlights developer attention as a motivation; no quantitative attention or cost savings are established.",
      "evidence_links": [
        {
          "label": "Author: LoopX as workflow engine (October 13, 2026)",
          "url": "https://x.com/zigzagcai/status/2109952174822408443",
          "kind": "public_user_report"
        },
        {
          "label": "Author: profiling, research, experiments, correctness",
          "url": "https://x.com/zigzagcai/status/2109952350299316499",
          "kind": "public_user_report"
        },
        {
          "label": "Author: continuous iteration",
          "url": "https://x.com/zigzagcai/status/2109952500262645847",
          "kind": "public_user_report"
        },
        {
          "label": "vLLM PR #54951: merge and reported measurements",
          "url": "https://github.com/vllm-project/vllm/pull/54951",
          "kind": "merged_pull_request"
        },
        {
          "label": "LoopX maintainer: exploration, human feedback, verifiable outcomes",
          "url": "https://x.com/huangruiteng/status/2109984101092737107",
          "kind": "public_maintainer_commentary"
        },
        {
          "label": "LoopX maintainer: validation and developer attention",
          "url": "https://x.com/huangruiteng/status/2109988844162703786",
          "kind": "public_maintainer_commentary"
        }
      ],
      "evidence_assets": [],
      "evidence_boundary": "The upstream merge is public repository evidence. LoopX use and the workflow are author reports; measurements are upstream-reported, not independently rerun or an isolated LoopX uplift. +32.59% is total input + output throughput at 1,000,000 input tokens: GLM-5.3-Flash, 4×H200, TP4, C1, 256 output tokens, 65,536-token batch budget, legacy runner + explicit FA3, four fresh-process ABBA/BAAB pairs, warmups excluded. It is not saturated serving throughput. Measured base 5893426b88f7 / optimized 16934c6e76e5 differ from final PR head a9fd692db809; merge commit 3e8e1364ff41. Runtime, costs, configuration, and intervention counts remain unknown. Targeted correctness is not broad quality or bitwise equivalence; short-input and cross-platform non-regression are not established.",
      "showcase_table": {
        "proof_point": "An author-reported LoopX optimization workflow led to an inspectable sparse-indexer change merged into vLLM.",
        "loopx_intervention": "author-reported workflow engine: profiling, research, hypotheses, experiments, correctness and speed checks"
      },
      "frontend_card": {
        "visual_metaphor": "profiling and hypotheses become measured experiments and an upstream reviewable optimization",
        "primary_metric_hint": "Upstream-reported +32.59% C1 total-token throughput at 1M input on 4×H200, TP4",
        "badges": [
          "independent_user",
          "Upstream merged",
          "Reported measurements"
        ],
        "story_beats": [
          "author names LoopX as workflow engine",
          "agents research and test optimization hypotheses",
          "correctness and performance measurements retain their conditions",
          "the resulting sparse-indexer optimization merges into vLLM"
        ],
        "show_control_diagram": false
      },
      "evidence_metrics": [
        {
          "value": "+32.59%",
          "labels": {
            "en": "reported C1 total tok/s · 1M, 4×H200, TP4",
            "zh": "报告 C1 总吞吐 · 1M、4×H200、TP4"
          }
        },
        {
          "value": "54.154 → 40.388s",
          "labels": {
            "en": "reported server TTFT · same configuration",
            "zh": "报告 server TTFT · 相同配置"
          }
        },
        {
          "value": "2026-10-11",
          "labels": {
            "en": "public upstream merge date (UTC)",
            "zh": "公开上游合并日期（UTC）"
          }
        }
      ],
      "localizations": {
        "zh": {
          "title": "vLLM 长上下文优化：已合入上游",
          "headline": "Zheng Cai 公开报告以 LoopX 为 workflow engine 持续探索并验证 vLLM 优化，成果已合入上游。报告总 token 吞吐 +32.59%：GLM-5.3-Flash、1M 输入、4×H200、TP4、C1。",
          "problem": "推理优化需要反复 profiling、论文和代码研究、实验、正确性检查及评审。作者将 LoopX 作为这一过程的 workflow engine；跨模型和 workload 的验证仍是重要工程工作。",
          "proof_point": "作者报告的 LoopX 优化工作流，推进成可检查的 sparse indexer 优化，并合入 vLLM。",
          "loopx_intervention": "作者报告的 workflow engine：profiling、研究、假设、实验、正确性与速度检查",
          "loopx_behavior": [
            "作者公开说明以 LoopX 为 agent-driven vLLM 推理优化框架的 workflow engine。",
            "作者介绍 profiling、论文/代码研究、假设、实验、正确性和速度测量。",
            "作者说明通过持续迭代找到 sparse indexer query 行的计算量均衡切分方案。",
            "上游 PR #54951 于 2026-10-11 合并；验证、评审跟进和维护责任仍属于作者。"
          ],
          "user_value": "持续探索和验证推进成可核验的上游优化。LoopX 维护者强调释放开发者精力，但这里没有精力或成本节省的定量结论。",
          "evidence_boundary": "上游合并是公开仓库事实；LoopX 使用及工作流来自作者报告。性能是上游报告结果，未独立复跑或隔离 LoopX 因果增益。+32.59% 指总输入加输出吞吐，条件为 GLM-5.3-Flash、1,000,000 输入 token、4×H200、TP4、C1、256 输出 token、65,536-token batch budget、legacy runner + 显式 FA3；四组 fresh-process ABBA/BAAB 配对排除 warmup，不代表饱和服务吞吐。测量基线 5893426b88f7 / 优化版本 16934c6e76e5 与最终 PR head a9fd692db809 分开，merge commit 为 3e8e1364ff41。运行时长、成本、具体配置和干预次数未知；针对性正确性不代表全面质量或逐位等价，也不宣称短输入和其他平台全面无回归。"
        }
      },
      "interactive_page": "docs/showcases/cases/independent-vllm-long-context-optimization.html",
      "interactive_page_zh": "docs/showcases/cases/independent-vllm-long-context-optimization.html",
      "interactive_page_en": "docs/showcases/cases/independent-vllm-long-context-optimization.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/independent-vllm-long-context-optimization.html",
        "en": "docs/showcases/cases/independent-vllm-long-context-optimization.en.html"
      },
      "showcase_rank": 4,
      "page_assets": "shared"
    },
    {
      "id": "2026-06-27-overnight-pr-batch",
      "date": "2026-06-27",
      "title": "Overnight PR batch with reviewable control",
      "status": "public_evidence_case",
      "case_type": "creator_dogfooding",
      "evidence_strength": "public_git_evidence",
      "case_page": "docs/showcases/cases/0627-overnight-pr-batch.md",
      "demo_command": null,
      "domain": "agent-platform-self-improvement",
      "audience": [
        "operator",
        "agent-platform-developer",
        "technical-lead"
      ],
      "pattern_tags": [
        "high_throughput_reviewable_work",
        "pr_sized_slices",
        "self_merge_policy",
        "validation_writeback",
        "public_boundary"
      ],
      "headline": "An overnight LoopX run can produce many PR-sized slices while keeping review, validation, and public evidence boundaries visible.",
      "problem": "High-throughput autonomous work is only useful if the resulting changes remain reviewable, validated, and safe to publish.",
      "loopx_behavior": [
        "keep work broken into PR-sized slices instead of a giant unreviewable diff",
        "tie runtime, docs, and focused smoke updates together when a control-plane contract changes",
        "limit self-merge to narrow validated changes while preserving broader review gates",
        "record public evidence from Git history instead of raw agent logs or private screenshots",
        "keep public/private boundary checks in the showcase path"
      ],
      "user_value": "The operator can wake up to a compact batch of merged public slices, see what changed, and still trust that gates, validation, and evidence boundaries were not bypassed.",
      "workload_signal": {
        "scope": "public_repository_window",
        "window": {
          "from": "2026-06-27T01:29:00+08:00",
          "to": "2026-06-27T11:29:00+08:00",
          "hours": 10
        },
        "public_git": {
          "merged_commits": 22,
          "files_touched": 60,
          "insertions": 6695,
          "deletions": 223,
          "commit_messages_with_pr_numbers": 10
        },
        "claim_boundary": "public Git history only; contemporaneous private queue notes are not used as public evidence"
      },
      "evidence_boundary": "Public Git evidence only; no private documents, internal screenshots, raw chats, local active-state bodies, raw logs, credentials, or machine-specific paths.",
      "interactive_page": "docs/showcases/cases/0627-overnight-pr-batch.html",
      "interactive_page_zh": "docs/showcases/cases/0627-overnight-pr-batch.html",
      "interactive_page_en": "docs/showcases/cases/0627-overnight-pr-batch.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/0627-overnight-pr-batch.html",
        "en": "docs/showcases/cases/0627-overnight-pr-batch.en.html"
      },
      "showcase_rank": 5,
      "showcase_table": {
        "proof_point": "High-throughput multi-lane work can remain PR-sized, reviewable, and merge-safe.",
        "loopx_intervention": "todo claim, review packet, self-merge boundary, focused smoke, public-boundary scan"
      },
      "frontend_card": {
        "visual_metaphor": "parallel PR lanes converge into a reviewable merge rail",
        "primary_metric_hint": "22 reviewable merged commits, including 10 PR-numbered commits, landed inside a 10h public evidence window.",
        "badges": [
          "PR batch",
          "review packet",
          "public boundary"
        ],
        "story_beats": [
          "keep work broken into PR-sized slices instead of a giant unreviewable diff",
          "tie runtime, docs, and focused smoke updates together when a control-plane contract changes",
          "limit self-merge to narrow validated changes while preserving broader review gates",
          "record public evidence from Git history instead of raw agent logs or private screenshots"
        ]
      },
      "evidence_metrics": [
        {
          "value": "22",
          "labels": {
            "zh": "可审阅 merged commits",
            "en": "reviewable merged commits"
          }
        },
        {
          "value": "10",
          "labels": {
            "zh": "带 PR 编号的 commits",
            "en": "PR-numbered commits"
          }
        },
        {
          "value": "10h",
          "labels": {
            "zh": "公开证据窗口",
            "en": "public evidence window"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "raw agent logs 依赖",
            "en": "raw-agent-log dependency"
          }
        }
      ]
    },
    {
      "id": "2026-06-24-pr-issue-auto-fix",
      "date": "2026-06-24",
      "title": "PR issue automatic fix loop",
      "status": "public_safe_pattern_case",
      "case_type": "reproducible_demo",
      "evidence_strength": "public_safe_pattern",
      "case_page": "docs/showcases/cases/0624-pr-issue-auto-fix.md",
      "demo_command": null,
      "domain": "issue-fix-workflow",
      "audience": [
        "operator",
        "agent-platform-developer",
        "open-source-maintainer"
      ],
      "pattern_tags": [
        "issue_fix_workflow",
        "review_feedback",
        "repro_smoke",
        "command_pack",
        "successor_todo"
      ],
      "headline": "Review feedback should become an ordered repair workflow with repro, fix, validation, and reviewer handoff.",
      "problem": "PR comments and issues are often concrete enough to fix, but unsafe to feed into an agent as unstructured prompt text without routing, repro, and validation.",
      "loopx_behavior": [
        "classify the issue or review feedback",
        "create ordered repair todos",
        "keep gated source reads explicit",
        "separate repro, implementation, validation, and reviewer handoff"
      ],
      "user_value": "The operator can turn a PR issue into a controlled fix loop without manually rewriting the review comment as an agent plan.",
      "evidence_boundary": "Public-safe pattern case only; no private screenshots, raw gated issue bodies, internal review notes, local paths, raw logs, credentials, or unpublished repository artifacts.",
      "interactive_page": "docs/showcases/cases/0624-pr-issue-auto-fix.html",
      "interactive_page_zh": "docs/showcases/cases/0624-pr-issue-auto-fix.html",
      "interactive_page_en": "docs/showcases/cases/0624-pr-issue-auto-fix.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/0624-pr-issue-auto-fix.html",
        "en": "docs/showcases/cases/0624-pr-issue-auto-fix.en.html"
      },
      "showcase_rank": 6,
      "showcase_table": {
        "proof_point": "Issue and review feedback can enter an executable repair loop.",
        "loopx_intervention": "issue-fix workflow, command pack, repro smoke, PR review feedback"
      },
      "frontend_card": {
        "visual_metaphor": "issue feedback closes through repro, fix, validation, and review handoff",
        "primary_metric_hint": "Feedback becomes a five-stage repair loop with branch-ready fix evidence and reviewer handoff.",
        "badges": [
          "issue fix",
          "repro smoke",
          "PR review"
        ],
        "story_beats": [
          "classify the issue or review feedback",
          "create ordered repair todos",
          "keep gated source reads explicit",
          "separate repro, implementation, validation, and reviewer handoff"
        ]
      },
      "evidence_metrics": [
        {
          "value": "5",
          "labels": {
            "zh": "修复闭环阶段",
            "en": "repair-loop stages"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "branch-ready 修复包",
            "en": "branch-ready fix packet"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "review handoff 保留",
            "en": "review handoff preserved"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "公开 artifact 中 raw issue body",
            "en": "raw issue bodies in public artifact"
          }
        }
      ]
    },
    {
      "id": "2026-06-23-agent-to-agent-pr-comments",
      "date": "2026-06-23",
      "title": "Agent-to-agent PR comment and fix loop",
      "status": "public_safe_pattern_case",
      "case_type": "reproducible_demo",
      "evidence_strength": "public_safe_pattern",
      "case_page": "docs/showcases/cases/0623-agent-to-agent-pr-comments.md",
      "demo_command": null,
      "domain": "pull-request-review",
      "audience": [
        "operator",
        "agent-platform-developer",
        "open-source-maintainer"
      ],
      "pattern_tags": [
        "agent_to_agent_handoff",
        "pr_comment_loop",
        "review_packet",
        "claimed_todo",
        "successor_todo"
      ],
      "headline": "PR review feedback can become an owned agent todo with fix evidence instead of a loose chat reminder.",
      "problem": "Multiple agent lanes can see or act on the same PR feedback, but without ownership and handoff state the comment-to-fix loop becomes hard to audit.",
      "loopx_behavior": [
        "turn review feedback into a claimed todo",
        "route implementation through the owning agent lane",
        "record fix and validation evidence in the review packet",
        "keep successor work explicit after the comment is handled"
      ],
      "user_value": "The operator can let agents coordinate around PR comments without losing final review visibility or fix evidence.",
      "evidence_boundary": "Public-safe pattern case only; no private screenshots, raw chats, internal review notes, local state, credentials, or unpublished artifacts.",
      "interactive_page": "docs/showcases/cases/0623-agent-to-agent-pr-comments.html",
      "interactive_page_zh": "docs/showcases/cases/0623-agent-to-agent-pr-comments.html",
      "interactive_page_en": "docs/showcases/cases/0623-agent-to-agent-pr-comments.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/0623-agent-to-agent-pr-comments.html",
        "en": "docs/showcases/cases/0623-agent-to-agent-pr-comments.en.html"
      },
      "showcase_rank": 7,
      "showcase_table": {
        "proof_point": "Multiple agents can coordinate around PR review comments without losing owner review.",
        "loopx_intervention": "claimed_by, handoff gate, review packet, comment/fix loop"
      },
      "frontend_card": {
        "visual_metaphor": "agent comments pass through explicit ownership instead of loose threads",
        "primary_metric_hint": "Every PR feedback item gets an owner, fix evidence, and a visible reviewer handoff instead of becoming a loose reminder.",
        "badges": [
          "handoff",
          "PR comment",
          "claimed_by"
        ],
        "story_beats": [
          "turn review feedback into a claimed todo",
          "route implementation through the owning agent lane",
          "record fix and validation evidence in the review packet",
          "keep successor work explicit after the comment is handled"
        ]
      },
      "evidence_metrics": [
        {
          "value": "1",
          "labels": {
            "zh": "每条反馈一个 owner",
            "en": "owner per feedback item"
          }
        },
        {
          "value": "3",
          "labels": {
            "zh": "owner/fix/review 可回答问题",
            "en": "owner/fix/review questions answered"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "review packet handoff",
            "en": "review-packet handoff"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "无主 PR comment reminder",
            "en": "unowned PR comment reminders"
          }
        }
      ]
    },
    {
      "id": "2026-06-23-overnight-project-refactor",
      "date": "2026-06-23",
      "title": "Overnight project refactor as PR-sized slices",
      "status": "public_safe_pattern_case",
      "case_type": "creator_dogfooding",
      "evidence_strength": "public_safe_pattern",
      "case_page": "docs/showcases/cases/0623-overnight-project-refactor.md",
      "demo_command": null,
      "domain": "repository-refactor",
      "audience": [
        "operator",
        "agent-platform-developer",
        "technical-lead"
      ],
      "pattern_tags": [
        "long_unattended_goal",
        "pr_sized_slices",
        "todo_follow_up",
        "supersede",
        "validation_writeback"
      ],
      "headline": "A broad refactor can run overnight while staying split into human-sized review units.",
      "problem": "Autonomous refactors become risky when discoveries, stale tasks, cleanup, and behavior changes collapse into one broad diff.",
      "loopx_behavior": [
        "keep the current refactor slice explicit",
        "convert discoveries into follow-up todos",
        "supersede stale tasks when the route changes",
        "validate each slice before merge or handoff"
      ],
      "user_value": "The operator can wake up to reviewable PR-sized refactor slices instead of a single giant autonomous diff.",
      "evidence_boundary": "Public-safe pattern case only; no private screenshots, raw chats, internal planning notes, local paths, credentials, raw logs, or unpublished project artifacts.",
      "interactive_page": "docs/showcases/cases/0623-overnight-project-refactor.html",
      "interactive_page_zh": "docs/showcases/cases/0623-overnight-project-refactor.html",
      "interactive_page_en": "docs/showcases/cases/0623-overnight-project-refactor.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/0623-overnight-project-refactor.html",
        "en": "docs/showcases/cases/0623-overnight-project-refactor.en.html"
      },
      "showcase_rank": 8,
      "showcase_table": {
        "proof_point": "Long unattended refactors can split into moderate PR slices instead of one unreviewable diff.",
        "loopx_intervention": "loop, todo follow-up, supersede, PR-sized slices"
      },
      "frontend_card": {
        "visual_metaphor": "a large refactor moves as small reviewable packets",
        "primary_metric_hint": "Unattended refactors stay reviewable by landing one PR-sized slice at a time with follow-up and review gates.",
        "badges": [
          "refactor",
          "PR slices",
          "todo evidence"
        ],
        "story_beats": [
          "keep the current refactor slice explicit",
          "convert discoveries into follow-up todos",
          "supersede stale tasks when the route changes",
          "validate each slice before merge or handoff"
        ]
      },
      "evidence_metrics": [
        {
          "value": "1",
          "labels": {
            "zh": "一次一个 PR-sized slice",
            "en": "PR-sized slice at a time"
          }
        },
        {
          "value": "3",
          "labels": {
            "zh": "successor/supersede/handoff 路线",
            "en": "successor/supersede/handoff routes"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "宽风险 review gate",
            "en": "review gate for broad risk"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "巨型 diff 目标",
            "en": "giant-diff target"
          }
        }
      ]
    },
    {
      "id": "2026-06-19-dynamic-workflow-hardware-agent",
      "date": "2026-06-19",
      "title": "Dynamic workflow for hardware-agent development",
      "status": "public_safe_interactive_case",
      "case_type": "contributor_case",
      "evidence_strength": "public_interactive_case",
      "case_page": "docs/showcases/cases/0619-dynamic-workflow-hardware-agent.md",
      "interactive_page": "docs/showcases/cases/0619-dynamic-workflow-hardware-agent.html",
      "demo_command": null,
      "domain": "hardware-agent-development",
      "audience": [
        "agent-platform-developer",
        "technical-lead",
        "open-source-user"
      ],
      "pattern_tags": [
        "dynamic_workflow",
        "multi_agent_coordination",
        "shared_control_plane",
        "long_unattended_goal",
        "convergence"
      ],
      "headline": "A fuzzy long-running engineering goal needs a shared control plane when multiple worker agents participate.",
      "problem": "Specialized engineering work can require multiple agents to split work and converge without losing ownership or state.",
      "loopx_behavior": [
        "keep durable goal state outside any one chat thread",
        "make ownership, quota, and evidence writeback explicit",
        "let script-generated worker loops continue only after bounded validation",
        "project convergence state and human gates for the operator"
      ],
      "user_value": "A contributor-approved public artifact shows how one control plane can coordinate Claude Code, generated scripts, and hardware-agent workers across five long-running engineering cases.",
      "evidence_boundary": "Public-safe interactive artifact; no raw chats, screenshots, proprietary design details, private repositories, local paths, task ids, credentials, or unpublished hardware artifacts.",
      "frontend_card": {
        "visual_metaphor": "multiple worker lanes converging through one shared control plane",
        "primary_metric_hint": "5 public-safe hardware workflows demonstrate multi-worker convergence while proprietary details stay out of the artifact.",
        "badges": [
          "interactive-html",
          "multi-agent",
          "hardware"
        ],
        "story_beats": [
          "LoopX owns goal state, quota, todos, claims, evidence, and history",
          "Claude Code writes task-specific orchestration scripts under that contract",
          "hardware-agent workers perform bounded RTL, simulation, and validation work",
          "five public cases show closed tasks, DSE, flagship Fmax optimization, and convergence floors"
        ]
      },
      "interactive_page_zh": "docs/showcases/cases/0619-dynamic-workflow-hardware-agent.html",
      "interactive_page_en": "docs/showcases/cases/0619-dynamic-workflow-hardware-agent.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/0619-dynamic-workflow-hardware-agent.html",
        "en": "docs/showcases/cases/0619-dynamic-workflow-hardware-agent.en.html"
      },
      "showcase_rank": 9,
      "showcase_table": {
        "proof_point": "Fuzzy goals, multiple workers, and long unattended runs can still converge.",
        "loopx_intervention": "goal state, worker handoff, dynamic workflow"
      },
      "evidence_metrics": [
        {
          "value": "5",
          "labels": {
            "zh": "公开安全硬件 workflow",
            "en": "public-safe hardware workflows"
          }
        },
        {
          "value": "3",
          "labels": {
            "zh": "LoopX/编排/worker 角色分离",
            "en": "LoopX/orchestrator/worker role split"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "canonical artifact 保留",
            "en": "canonical artifact preserved"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "专有设计细节暴露",
            "en": "proprietary design details exposed"
          }
        }
      ]
    },
    {
      "id": "2026-06-19-loopx-self-iteration",
      "date": "2026-06-19",
      "title": "LoopX self-iteration loop",
      "status": "public_evidence_case",
      "case_type": "creator_dogfooding",
      "evidence_strength": "public_git_evidence",
      "case_page": "docs/showcases/cases/0619-loopx-self-iteration.md",
      "demo_command": null,
      "domain": "agent-platform-self-improvement",
      "audience": [
        "open-source-user",
        "agent-platform-developer",
        "technical-lead"
      ],
      "pattern_tags": [
        "self_iteration",
        "peer_claim_scope",
        "todo_claim_ownership",
        "identity_aware_prompt",
        "self_merge_policy",
        "evidence_writeback",
        "efficiency_evidence_model"
      ],
      "headline": "A high-churn LoopX repo stayed legible while benchmark, product, docs, planning, and peer lanes moved in parallel.",
      "problem": "A long-running agent engineering repo needed to keep many public commits, benchmark routes, planning lanes, user gates, docs, smokes, and peer changes reviewable without relying on private chat memory.",
      "loopx_behavior": [
        "preserve durable goal, todo, gate, quota, evidence, and run-history state across high repository churn",
        "separate benchmark, productization, documentation, planning, and peer lanes into reviewable obligations",
        "register peer identities and project advisory scope through automation prompts",
        "claim and complete scoped todos with public-safe evidence",
        "allow small validated peer self-merges while requiring explicit review handoff for risky work",
        "keep public showcases and smokes free of private chat, internal docs, raw trajectories, and raw benchmark evidence"
      ],
      "user_value": "The operator can let a fast-moving multi-lane agent project continue across benchmark, product, docs, and peer work while keeping ownership, gates, validation, follow-up, and conservative efficiency evidence visible in one shared control plane.",
      "workload_signal": {
        "anchor_commit": "86d6d9d",
        "scope": "whole_public_repository",
        "whole_repository": {
          "commit_count": 801,
          "files_touched": 570,
          "insertions": 265703,
          "deletions": 49895
        },
        "recent_window": {
          "since": "2026-06-18T00:00:00+08:00",
          "commit_count": 244,
          "files_touched": 216,
          "insertions": 52898,
          "deletions": 20935
        },
        "public_window": {
          "from": "2026-05-31T22:57:55+08:00",
          "to": "2026-06-20T12:18:42+08:00",
          "calendar_days": 19.6,
          "active_commit_days": 16
        },
        "efficiency_model": {
          "baseline": "AI-coding-assisted product process",
          "estimated_developer_days": {
            "low": 59,
            "high": 92
          },
          "single_engineer_calendar_compression": {
            "low": 3.0,
            "high": 4.7
          },
          "two_person_team_calendar_compression": {
            "low": 1.8,
            "high": 3.2
          },
          "claim_boundary": "directional, maturity-adjusted, public Git evidence only"
        },
        "main_surfaces": [
          "CLI",
          "todo lifecycle",
          "status and quota projection",
          "heartbeat prompt",
          "dashboard/status server",
          "benchmark adapters",
          "frontstage projection",
          "docs",
          "smokes",
          "showcases",
          "product positioning"
        ]
      },
      "feature_points": [
        "benchmark and adapter maturation",
        "control-plane correctness for quota, gates, todo projection, and outcome-floor blockers",
        "planning and dreaming lane separation",
        "user/operator surfaces including diagnostics, dashboard framing, onboarding, quickstart, README, and showcases",
        "registered todo claim ownership and identity-aware scoped heartbeat prompts",
        "peer self-merge completion flag with evidence",
        "public-boundary smokes and showcase catalog checks",
        "conservative efficiency evidence model that converts commits into maturity-adjusted product requirement clusters"
      ],
      "evidence_boundary": "Public Git evidence only; no private thread text, local active-state bodies, internal document links, screenshots, raw benchmark material, credentials, or machine-specific paths.",
      "frontend_card": {
        "visual_metaphor": "many repo lanes flowing through one control plane, with independently claimed peer lanes branching safely",
        "primary_metric_hint": "801 public commits, 244 recent commits, and a conservative 59-92 AI-assisted developer-day baseline show self-iteration throughput.",
        "badges": [
          "self-iteration",
          "commit-backed",
          "peer-agent",
          "efficiency-model"
        ],
        "story_beats": [
          "whole repo moves quickly across benchmark, runtime, docs, dashboard, planning, and smoke surfaces",
          "LoopX keeps durable goals, todos, gates, quota, evidence, and run history visible",
          "one peer lane progresses beside a separately claimed benchmark lane",
          "validated peer changes can self-merge while risky work uses explicit review handoff",
          "public Git history is converted into conservative product requirement clusters",
          "public docs and smokes turn the experience into a reusable case"
        ]
      },
      "interactive_page": "docs/showcases/cases/0619-loopx-self-iteration.html",
      "interactive_page_zh": "docs/showcases/cases/0619-loopx-self-iteration.html",
      "interactive_page_en": "docs/showcases/cases/0619-loopx-self-iteration.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/0619-loopx-self-iteration.html",
        "en": "docs/showcases/cases/0619-loopx-self-iteration.en.html"
      },
      "showcase_rank": 10,
      "showcase_table": {
        "proof_point": "A high-churn multi-lane project can keep state, boundaries, and evidence coherent.",
        "loopx_intervention": "todo, quota, gate, evidence, review packet, frontstage"
      },
      "evidence_metrics": [
        {
          "value": "801",
          "labels": {
            "zh": "public commits",
            "en": "public commits"
          }
        },
        {
          "value": "244",
          "labels": {
            "zh": "06-18 后 commits",
            "en": "commits since Jun 18"
          }
        },
        {
          "value": "59-92d",
          "labels": {
            "zh": "AI-assisted baseline",
            "en": "AI-assisted baseline"
          }
        },
        {
          "value": "3.0-4.7x",
          "labels": {
            "zh": "calendar compression",
            "en": "calendar compression"
          }
        }
      ]
    },
    {
      "id": "2026-06-17-blocked-p0-safe-rotation",
      "date": "2026-06-17",
      "title": "Blocked P0 with safe P1/P2 rotation",
      "status": "reproducible_synthetic_demo",
      "case_type": "reproducible_demo",
      "evidence_strength": "reproducible_synthetic_demo",
      "case_page": "docs/showcases/cases/0617-blocked-p0-safe-rotation.md",
      "demo_command": "python3 examples/showcase-0617-blocked-p0-safe-rotation-smoke.py",
      "domain": "benchmark-rotation",
      "audience": [
        "operator",
        "agent-platform-developer",
        "benchmark-developer"
      ],
      "pattern_tags": [
        "blocked_priority_fallback",
        "concrete_user_gate",
        "safe_fallback_work",
        "quota_discipline",
        "attention_reduction"
      ],
      "headline": "A gated P0 lane should not stall a whole long-running goal when safe fallback work exists.",
      "problem": "A benchmark lane needed a large local dependency before it could continue, while other no-upload benchmark work remained safe.",
      "loopx_behavior": [
        "surface the P0 dependency as a concrete user gate",
        "avoid spending on the gated lane",
        "select a non-dependent fallback lane",
        "record both the blocker and the fallback reason"
      ],
      "user_value": "The operator sees exactly what decision is needed while the agent can keep making bounded progress elsewhere.",
      "evidence_boundary": "Synthetic public fixture only; no private screenshots, raw tasks, internal links, local image names, or raw run logs.",
      "frontend_card": {
        "visual_metaphor": "priority lanes with one gated lane and one active fallback lane",
        "primary_metric_hint": "One concrete P0 user decision is isolated while one safe fallback lane can continue with zero gated-lane spend.",
        "badges": [
          "reproducible",
          "user-gate",
          "fallback"
        ],
        "story_beats": [
          "P0 lane is blocked by a user decision",
          "LoopX projects the decision as a user todo",
          "agent continues safe fallback work",
          "state records blocker, fallback, validation, and spend policy"
        ]
      },
      "interactive_page": "docs/showcases/cases/0617-blocked-p0-safe-rotation.html",
      "interactive_page_zh": "docs/showcases/cases/0617-blocked-p0-safe-rotation.html",
      "interactive_page_en": "docs/showcases/cases/0617-blocked-p0-safe-rotation.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/0617-blocked-p0-safe-rotation.html",
        "en": "docs/showcases/cases/0617-blocked-p0-safe-rotation.en.html"
      },
      "showcase_rank": 11,
      "showcase_table": {
        "proof_point": "A user decision should not block all safe work.",
        "loopx_intervention": "concrete user todo, safe fallback, quota control"
      },
      "evidence_metrics": [
        {
          "value": "1",
          "labels": {
            "zh": "具体 P0 用户决策",
            "en": "concrete P0 user decision"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "safe fallback lane",
            "en": "safe fallback lane"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "gated lane 自动推进",
            "en": "gated-lane auto-progress"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "private upload 依赖",
            "en": "private upload dependency"
          }
        }
      ]
    },
    {
      "id": "2026-09-dsh-loopx-replan",
      "date": "2026-09",
      "title": "DSH × LoopX Replan",
      "status": "reproducible_synthetic_demo",
      "case_type": "reproducible_demo",
      "evidence_strength": "real_recording_with_reproducible_fixture",
      "case_page": "docs/showcases/cases/dsh-loopx-replan-demo.md",
      "demo_command": "python3 examples/dsh-loopx-demo-smoke.py",
      "recording_path": "docs/assets/showcases/dsh-loopx/dsh-loopx-quickstart-replan.mp4",
      "page_assets": "shared",
      "domain": "agent-host-integration",
      "audience": [
        "DSH user",
        "agent-platform-developer",
        "long-running-agent-operator"
      ],
      "pattern_tags": [
        "deepseek_harness",
        "native_skill_activation",
        "vision_replan",
        "decision_evidence",
        "goalbar_closeout"
      ],
      "headline": "A real DSH session changes a logging-library decision after a serverless constraint while preserving the original evidence and successor work.",
      "problem": "A new material constraint can invalidate an agent's earlier decision, but ordinary chat correction can erase why the plan changed and what still needs validation.",
      "loopx_behavior": [
        "activate explicitly through the native DSH skill picker",
        "retain the initial decision and evidence",
        "record a Replan when the serverless constraint changes the ranking",
        "bind successor implementation and tests to the same durable Goal",
        "close the visible GoalBar only after the revised work settles"
      ],
      "user_value": "The user can change a material constraint without losing the decision trail, while DSH remains the execution host and LoopX keeps the work frontier visible.",
      "evidence_assets": [
        {
          "path": "docs/assets/showcases/dsh-loopx/dsh-loopx-cover.png",
          "alt": "DSH × LoopX demo cover showing explicit skill activation, durable work, and a real Replan from Pino to Roarr",
          "caption": "Public cover derived from the edited DSH recording; the linked case provides the video, fixture, and evidence boundary."
        }
      ],
      "evidence_boundary": "Edited real DSH recording plus a synthetic public fixture and tests; credentials, provider configuration, raw reasoning, setup retries, local LoopX state, and the unedited recording are excluded.",
      "frontend_card": {
        "visual_metaphor": "one visible DSH Goal changes route while its earlier decision remains connected to the evidence",
        "primary_metric_hint": "One recorded Replan changes 12 packages to 4 and closes 3/3 tests with GoalBar 2/2.",
        "badges": [
          "DSH",
          "real recording",
          "reproducible"
        ],
        "story_beats": [
          "the user selects the LoopX skill inside DSH",
          "the agent initially chooses Pino",
          "a serverless constraint triggers an explicit Replan to Roarr",
          "the revised CLI passes three behavior tests and closes two Todos"
        ]
      },
      "localized_pages": {
        "zh": "docs/showcases/cases/dsh-loopx-replan-demo.html",
        "en": "docs/showcases/cases/dsh-loopx-replan-demo.en.html"
      },
      "localizations": {
        "zh": {
          "title": "DSH × LoopX：约束变化后的显式 Replan",
          "headline": "真实 DSH 会话在新增 serverless 约束后修正日志库决策，同时保留原始证据和后继工作。",
          "proof_point": "宿主原生 Agent 可以改变计划，同时保留旧计划为何被替代的证据。",
          "loopx_intervention": "原生 Skill 激活、Replan、后继 Todo、证据与 GoalBar",
          "problem": "新的关键约束可能推翻 Agent 的旧决策；普通聊天修正容易抹掉计划为什么变化、后续还需验证什么。",
          "loopx_behavior": [
            "在 DSH 技能选择器中显式激活 loopx",
            "保留初始决策和证据",
            "serverless 约束改变排序时记录 Replan",
            "把后继实现与测试绑定到同一个持久 Goal",
            "修订后的工作完成后才关闭可见 GoalBar"
          ],
          "user_value": "用户可以改变关键约束而不丢失决策链；DSH 继续负责执行，LoopX 让工作前沿持续可见。",
          "evidence_boundary": "经编辑的真实 DSH 录屏，加上合成的公开 fixture 与测试；不包含凭证、provider 配置、原始推理、安装重试、本地 LoopX 状态或未剪辑录屏。"
        }
      },
      "showcase_rank": 11,
      "showcase_table": {
        "proof_point": "A host-native agent can change plans without erasing why the old plan was superseded.",
        "loopx_intervention": "native skill activation, Replan, successor Todo, evidence, GoalBar"
      },
      "evidence_metrics": [
        {
          "value": "60s",
          "labels": {
            "zh": "真实录屏",
            "en": "real recording"
          }
        },
        {
          "value": "12→4",
          "labels": {
            "zh": "依赖包数量",
            "en": "dependency packages"
          }
        },
        {
          "value": "3/3",
          "labels": {
            "zh": "行为测试",
            "en": "behavior tests"
          }
        },
        {
          "value": "2/2",
          "labels": {
            "zh": "GoalBar Todo",
            "en": "GoalBar Todos"
          }
        }
      ],
      "interactive_page": "docs/showcases/cases/dsh-loopx-replan-demo.html",
      "interactive_page_zh": "docs/showcases/cases/dsh-loopx-replan-demo.html",
      "interactive_page_en": "docs/showcases/cases/dsh-loopx-replan-demo.en.html"
    },
    {
      "id": "2026-06-20-creator-operator-case-spec",
      "date": "2026-06-20",
      "title": "Creator-operator long-running agent case",
      "status": "public_safe_case_spec",
      "case_type": "reproducible_demo",
      "evidence_strength": "public_safe_case_spec",
      "case_page": "docs/showcases/cases/0620-creator-operator-case-spec.md",
      "demo_command": null,
      "storyboard_path": "docs/showcases/creator-ops-fake-data-storyboard.md",
      "feedback_contract_path": "docs/showcases/creator-ops-feedback-boundary-contract.md",
      "domain": "creator-operations",
      "audience": [
        "non-technical-operator",
        "creator-operator",
        "product-builder",
        "open-source-user"
      ],
      "pattern_tags": [
        "creator_operator_workflow",
        "gate_aware_continuation",
        "feedback_capture",
        "safe_side_path",
        "material_library",
        "synthetic_case"
      ],
      "headline": "A creator-operator needs a long-running agent loop that keeps research moving while publishing decisions stay gated.",
      "problem": "Content research, preference mapping, insight extraction, draft queues, and material libraries can all blur together when the user only sees chat logs or raw agent traces.",
      "loopx_behavior": [
        "represent the creative objective as durable goal state",
        "separate publishing decisions from safe research and organization work",
        "turn feedback into preference hints, gate decisions, todo updates, or boundary corrections",
        "keep synthetic/public material separate from private notes and unpublished drafts",
        "show the next agent move before another automatic run spends compute"
      ],
      "user_value": "A non-technical operator can see what changed, what is blocked, what can safely continue, and how feedback changes the plan without reading prompts, logs, or raw traces.",
      "evidence_boundary": "Synthetic case spec only; no real platform data, creator notes, screenshots, private drafts, raw browsing traces, local paths, credentials, or performance claims.",
      "appendix_surface": {
        "reason": "Synthetic product-direction spec; keep as appendix until real public evidence or an approved public-safe user story exists.",
        "public_surface": "appendix_only",
        "links": [
          "docs/showcases/creator-ops-fake-data-storyboard.md",
          "docs/showcases/creator-ops-feedback-boundary-contract.md"
        ]
      },
      "interactive_page": "docs/showcases/cases/0620-creator-operator-case-spec.html",
      "interactive_page_zh": "docs/showcases/cases/0620-creator-operator-case-spec.html",
      "interactive_page_en": "docs/showcases/cases/0620-creator-operator-case-spec.en.html",
      "localized_pages": {
        "zh": "docs/showcases/cases/0620-creator-operator-case-spec.html",
        "en": "docs/showcases/cases/0620-creator-operator-case-spec.en.html"
      },
      "evidence_metrics": [
        {
          "value": "1",
          "labels": {
            "zh": "publish hard gate",
            "en": "publish hard gate"
          }
        },
        {
          "value": "1",
          "labels": {
            "zh": "safe research side path",
            "en": "safe research side path"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "autopublish 动作",
            "en": "autopublish actions"
          }
        },
        {
          "value": "0",
          "labels": {
            "zh": "真实运营数据暴露",
            "en": "real operations data exposed"
          }
        }
      ]
    }
  ]
}