From 0db730d948a58c8f4da293317a86c5d703148dba Mon Sep 17 00:00:00 2001
From: Liang Jiaqing <l.j.q.light@gmail.com>
Date: Mon, 18 May 2026 21:10:20 +0800
Subject: [PATCH] add morphling_sop to tracked files; add goal hive execution
 note

---
 .gitignore              |  3 +++
 memory/morphling_sop.md | 43 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+)
 create mode 100644 memory/morphling_sop.md

diff --git a/.gitignore b/.gitignore
index 6aab88e2..8d7f9e8c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -78,6 +78,9 @@ memory/L4_raw_sessions/*
 # Goal Hive Mode SOP
 !memory/goal_hive_sop.md
 
+# Morphling SOP
+!memory/morphling_sop.md
+
 # Skill Search SOP
 !memory/skill_search/
 !memory/skill_search/**
diff --git a/memory/morphling_sop.md b/memory/morphling_sop.md
new file mode 100644
index 00000000..98370017
--- /dev/null
+++ b/memory/morphling_sop.md
@@ -0,0 +1,43 @@
+# morphling_sop
+
+## 定义
+Morphling 是一种项目级能力吸收/替代模式：给定任意目标项目，先抽取其目标与测例，再按组件选择调用、重写或少量复刻禁区规避，最终让自身或新产物在同一测例上达到或超过目标。
+
+## 核心三元组
+1. **目标（Target）**：它解决什么问题、面向谁、核心价值是什么；目标可以是完整项目，也可以是巨型项目中的可交付子系统。
+2. **测例（Tests）**：它声称能通过的 benchmark、demo、CI、榜单、评测站、用户任务清单、性能/质量指标；没有测例先构造最小客观测例。
+3. **行为（Actions）**：对每个组件分别决定：调用、重写、舍弃；避免“复刻/抄袭”作为默认行为。
+
+## 输出形态
+- **调用型 morphling**：把目标能力纳入自身工具链，产物是“更强的我”。
+- **重写型 morphling**：理解核心后从零实现更好版本，产物是可独立替代原项目的新 repo/工具/产品。
+- **混合型 morphling**：同一项目可分组件处理：底层复杂依赖调用，差异化核心重写，冗余模块舍弃。
+
+## 流程
+1. **锁定目标**：记录 URL/repo/产品名；不要先评价值不值得，先看它实际解决的问题。
+2. **目标拆解**：识别类型：skill/教程、库、CLI、桌面/网页产品、基础设施、巨型生态、纯概念项目。
+3. **测例提取**：优先找官方 tests、CI、benchmark、论文/README 指标、demo 脚本、评测网站、issue 中的真实失败案例。
+4. **测例补全**：若目标没有公开测例，构造最小可验证任务集：核心 happy path、边界条件、目标宣称的杀手特性、用户最痛点。
+5. **组件分解**：列出核心模块、可替换依赖、生态/数据/模型/硬件等不可轻易重写部分。
+6. **行为选择**：
+   - 能稳定调用且非差异化核心 → 调用/封装。
+   - 质量差、耦合重、可用更简洁方式实现、或需独立发布 → 重写。
+   - 巨型/长期生态部分 → 缩小到子系统或调用成熟依赖。
+   - 复刻/照抄只作为理解阶段，不作为交付策略。
+7. **实现闭环**：先做能跑通测例的最小版本，再补强超过目标的维度。
+8. **对照验证**：在同一测例上跑目标与 morphling 产物，记录通过率、速度、稳定性、成本、易用性。
+9. **固化成果**：调用型写入工具链/SOP；重写型形成 repo、README、测试与交付说明。
+
+## 边界判断
+- Office 这类巨型生态不做整体替代，拆成具体子系统或能力点。
+- Stable-diffusion-webui 这类“大但核心可抽离”的项目可以重写核心体验，因为历史包袱可能大于真实复杂度。
+- UI-TARS-Desktop 这类路线差异项目：调用可吸收其纯视觉能力；重写则意味着做一个独立多模态桌面 Agent，并跑同类 GUI benchmark。
+
+## 执行方式
+- Morphling 任务应通过 Goal Hive 执行（参见 goal_hive_sop），利用 Master 调度 + Worker 并行实现 + 持续验收的长程模式完成。
+
+## 完成标准
+- 必须有测例或明确构造的测例。
+- 必须说明每个核心组件采用调用/重写/舍弃的理由。
+- 必须能在同一考卷上与目标对比。
+- “更好”不能只靠主观判断，至少落在一个可测维度：通过率、性能、成本、稳定性、易用性、可维护性、覆盖范围。