尧图网页设计 
last30days-skillGitHub 搜索限定符冲突的剥离机制与 Residual Review Findings 深度解析【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill本文基于仓库中 Residual Review Findings 记录解读 last30days-skill 的 GitHub 源适配器中Planner 注入的搜索限定符与适配器自身日期窗口冲突这一缺陷的完整脉络strip_search_qualifiers剥离逻辑的设计与行为边界、限定符独占qualifier-only主题的错误信封语义、端到端测试如何固化这些行为以及一次自动化代码评审ce-code-review所沉淀的 4 项待修复发现与 3 项残余风险。读完后你可以复现该模块的判定逻辑并理解report-only 冲突记录这类工程流程文档在多人协作仓库中的作用。1. 背景一次代码评审记录是什么该记录文件的开头声明了其运行上下文这是对分支fix/github-qualifier-strip提交42c5ab5bebcb3d4bd4d8bfc11f89b4df4bc1da9b执行 ce-code-reviewmode:agent后产生的评审发现存档。这些发现在 LFG 流程的第 5 步未被直接应用而是filed for durability登记以保证持久可追溯。记录中分三类组织发现Filed已立案4 项发现P1×1、P2×2、P3×1登记到 GitHub Issuesissue #951 至 #954全部指向 github.py 中限定符剥离相关的代码行Settled-conflict findings已裁决冲突report-only2 项发现与 KTD-1会话内已裁决的计划决策qualifier-only 主题应返回错误信封相冲突因此只记录、不申请应用Residual risks残余风险3 项从评审中带出、暂不立案的潜在问题。要读懂这些发现需要先理解它们所针对的底层缺陷——也就是 issue #949 所描述的限定符冲突问题。2. 缺陷根因两个created:限定符谁说了算问题出在 last30days-skill 的查询规划层plannerLLM 规划的子查询主题串里有时会直接写入 GitHub 搜索限定符例如open source AI stars:1000 created:2025-03-20。而 search_github 在构造查询时会追加自己维护的日期窗口created:{from_date}。源码中的注释github.py#L169-L183完整记录了冲突链两个created:限定符同时出现时GitHub 只认第一个静默忽略适配器追加的那个API 于是返回了窗口之外的条目这些条目又会在parse_github_response的本地日期过滤中被整体丢弃最终表现为一个抓到了结果、却汇报零条结果的源issue #949。3. 剥离机制实现QUALIFIER_KEYS 与正则修复的核心是strip_search_qualifiers在进入查询构造前把主题串里的 GitHub 搜索限定符全部剥掉只保留自然语言主体。实现分三层github.py#L176-L198第一层限定符词表。QUALIFIER_KEYS是一个 36 项的 frozenset覆盖 GitHub 搜索语法中的限定符关键字archived、author、created、is、label、language、repo、stars、state、type、updated等。第二层剥离正则。_QUALIFIER_RE的构造值得逐段拆解_QUALIFIER_RE re.compile( r(?:(?[\s,;])|^)(?: |.join(sorted(QUALIFIER_KEYS)) r):(?:[]?)?(?:\[^\]*\|[^\s,;()\[\]])[,;]?, re.IGNORECASE, )(?:(?[\s,;])|^)限定符必须出现在串首或紧跟空白、逗号、分号之后——这避免了误伤state of the art中不带冒号的普通单词词后必须有:才触发:(?:[]?)?可选的比较符前缀覆盖stars:1000、created:2025-01-01等形态(?:\[^\]*\|[^\s,;()\[\]])值部分。引号值bug fix整体消费跨越空格普通值则停止在空白、逗号、分号、括号、方括号处不会贪吃后一个主题词如created:2025-03-20,robotics中的robotics必须存活末尾可选的[,;]?把粘连的分隔符一并吃掉让ai,created:2025-03-20这类 planner 输出不残留尾逗号。第三层归一化。strip_search_qualifiers用 .join(...split())折叠连续空白并在 docstring 中明确约定当主题只剩限定符时返回空串调用方必须处理绝不能用空词搜索空词会匹配整个站点随后被日期过滤丢弃成一次假无结果。4. 判定边界qualifier-only 路径的错误信封search_github在剥离后github.py#L226-L245core extract_core_subject(topic) plain_core strip_search_qualifiers(core) if plain_core ! core: _log(fStripped search qualifiers: {core} - {plain_core}) if not plain_core: _log(Topic contained only search qualifiers or was empty; nothing to search) return { items: [], context: {core: core, from_date: from_date, to_date: to_date, count: count}, error: ( fGitHub topic contained only search qualifiers or was empty: {topic!r} ), }要点有三其一剥离发生在extract_core_subject之后即取核心主语与剥限定符是两道独立的防线其二qualifier-only 与空主题走同一条报错短路路径不发起任何网络请求其三返回的仍是一个与其他适配器一致的 envelope 形状但携带error字段——从源码结构看这个error字段会决定下游管道对该源的分类成功 / 尝试但失败 / 错误这正是后文 P1 发现的关注点。5. 端到端测试如何固化行为test_github.py 中的两个测试类覆盖了该机制的全部边界可作为验证清单TestStripSearchQualifiers纯函数层用例输入期望输出固化的行为混合主题open source ai stars:1000 created:2025-03-20open source ai基本剥离无冒号普通词ai in healthcare原样in不带:不是限定符大小写Stars:1000空串忽略大小写的纯限定符主题斜杠值repo:facebook/react bugbug值类消费/逗号粘连ai,created:2025-03-20ai,分隔符后紧跟的限定符分号粘连ai;created:2025-03-20ai;同上分号引号值label:bug fix open sourceopen source引号值整体消费不残留fix碎片粘连主题词created:2025-03-20,robotics含robotics值类在分隔符处停止不吞后续词TestSearchGithubQualifierssearch_github端到端层验证了查询串只含一个created:q.count(created:) 1且为适配器自己的窗口、qualifier-only 主题mock_fetch.assert_not_called()零网络调用、state of the art ai中state存活进入查询以及认证场景下is:issue/is:pull-request双分区合并去重并按 reactions 重排。6. 本次评审登记的 4 项发现Filed以下 4 项即记录文件 Filed (tracker: GitHub Issues) 一节的全部内容逐条给出源码级解读P1 — 限定符独占主题被判 ERROR污染重试资格issue #951github.py:237第 237 行是 qualifier-only 路径的return语句该路径返回的 envelope 带error字段。评审发现这个下游的 ERROR/attempted 分类会阻断管道层的瘦结果重试机制。对照 pipeline.py 中的_retry_thin_sources它对结果少于 3 条的源发起简化核心主语的重试但筛选条件显式排除了source not in bundle.errors_by_source——即已被记为错误的源不会进入重试队列。从源码结构看一次 qualifier-only 子查询把 GitHub 源标成 ERROR 后该源在整个 run 内都失去了走瘦结果补救通道的资格。该发现被标注为settled-conflict: report-only per KTD-1KTD-1 是会话内已裁决的计划决策——qualifier-only 主题返回错误信封本就是计划行为因此登记 issue 只为持久化不申请修改代码。P2 — 引号包裹或括号包裹的限定符绕过剥离issue #952github.py:186第 186 行即_QUALIFIER_RE定义。(?:(?[\s,;])|^)这个位置断言要求限定符前是空白/逗号/分号/串首当 planner 输出整段被引号或括号包裹的形态如stars:1000或(created:2025-03-20)冒号前是或(而非空白时正则不会匹配限定符可能残留进最终查询重新制造 issue #949 的双created:冲突。P2 — 空主题或噪音限定符主题翻转为硬 ERRORissue #953github.py:231第 231 行if not plain_core:分支把空主题与 qualifier-only 主题一视同仁地翻转为携带error的硬失败。评审认为这与 KTD-1 / R3 的裁决此类主题应返回错误信封存在边界争议——例如主题中还有无法构成有效查询的噪音词残留时硬 ERROR 与正常搜索但零结果的语义边界不清。同样标注settled-conflict: report-only per KTD-1登记 issue #953 仅为持久化。P3 — 重复的 qualifier-only 子查询刷屏日志与错误详情issue #954github.py:229当 plan 里多个子查询都退化到 qualifier-only例如 planner 对多个实体各生成一条限定符串每条都会执行第 229 行附近的Stripped search qualifiers日志与第 236 行的Topic contained only search qualifiers or was empty日志并在各自的 envelope 中写入完整的topic!r错误详情——子查询数量放大时日志和错误详情会出现重复刷屏。7. Settled-conflict 小节为何已裁决冲突只报不修记录文件的 Settled-conflict findings (report-only, not filed as apply requests) 一节对上述 P1/P2 两项做了补充说明这是理解 ce-code-review 流程的关键两项发现都与 **KTD-1session-settled plan decision**冲突——即在制定计划阶段对应计划文档fix-github-qualifier-collision的会话已经裁决qualifier-only 主题返回错误信封这一语义。发现本身技术上成立如 P1 指出的_retry_thin_sources阻断效应但修改它会推翻既有裁决因此这些发现filed as #951/#953 for durability, not for application——issue 是证据存档不是待修工单。No sink / failed 一节为 None说明所有发现都成功落盘Proceeded-and-flagged settled-decision conflicts (from ce-work step 2) 一节亦为 None说明 ce-work 步骤 2 没有额外返回需继续放行但打标记的冲突决策。8. 评审带出的 3 项残余风险记录文件 Residual risks carried from the review 一节列出了三条暂不立案、但需要被后续读者知晓的风险逐条对照源码验证错误信封中context[core]未剥离而成功路径已剥离当前无消费者受影响。对照源码确实如此qualifier-only 分支返回时context里的core用的是extract_core_subject(topic)的原始结果github.py#L237-L244而成功路径在 github.py#L245 执行core plain_core后parse_github_response消费的是剥离后的context[core]用于计算相关性_compute_relevance。两条路径的context[core]语义不一致属于潜在的地雷而非现网缺陷——记录也明确写了 no current consumer is affected。GitHub 对未闭合引号返回 422 是外部 API 行为未被测试覆盖。_QUALIFIER_RE的值类\[^\]*\只消费闭合引号planner 若输出未闭合引号如label:bug残留在查询串中会触发 GitHub/search/issues的 422而仓库测试只覆盖了闭合引号形态。这是外部依赖行为单测只能靠 mock 固化己方逻辑无法替 GitHub 背书。planner 吐出逗号粘连、带引号、包裹形态的限定符是 LLM 行为暴露面无法从代码量化。这一条点明了整个缺陷类别的根本性质输入形态的空间由 LLM 生成而正则剥离只能覆盖已观察到的形态。测试类中ai,created:...、label:bug fix等用例都是对历史观察形态的回归保护新形态出现时需要补正则与补测试。9. 从这份 Findings 文档学到的工程实践该记录虽然只有几十行却完整展示了一种可复用的评审存档范式发现必须落到精确行号与 issue 编号4 项 Filed 发现全部带文件:行号与 issue 号使评审意见可被后续任何一次评审直接交叉引用区分可应用与已裁决冲突settled-conflict 发现单独成节并标注 report-only避免自动化流程误把推翻会话裁决的修改当作普通 bugfix 应用残余风险独立成节不满足立案条件无法复现、外部行为、不可量化的风险不丢弃而是显式 carry 到文档里防止下轮评审重复发现或遗忘。如果你要复核本文的全部论断入口是三个文件记录本体 42c5ab5bebcb3d4bd4d8bfc11f89b4df4bc1da9b.md、被评审的实现 github.py限定符剥离与查询构造集中在 L169–L343以及验证这些行为的测试 test_github.pyTestStripSearchQualifiers与TestSearchGithubQualifiers两个类。管道侧重试资格的判定在 pipeline.py 的_retry_thin_sources。需要说明的适用前提本文所有行号与行为描述均以当前仓库快照为准记录文件提及的计划文档2026-08-07-001-fix-github-qualifier-collision-plan.md在当前仓库中不存在文中对 KTD-1 的转述以该记录文件自身文字为限。【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 last30days-skill：GitHub 搜索限定符冲突的剥离机制与 Residual Review Findings 深度解析
last30days-skillGitHub 搜索限定符冲突的剥离机制与 Residual Review Findings 深度解析【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill本文基于仓库中 Residual Review Findings 记录解读 last30days-skill 的 GitHub 源适配器中Planner 注入的搜索限定符与适配器自身日期窗口冲突这一缺陷的完整脉络strip_search_qualifiers剥离逻辑的设计与行为边界、限定符独占qualifier-only主题的错误信封语义、端到端测试如何固化这些行为以及一次自动化代码评审ce-code-review所沉淀的 4 项待修复发现与 3 项残余风险。读完后你可以复现该模块的判定逻辑并理解report-only 冲突记录这类工程流程文档在多人协作仓库中的作用。1. 背景一次代码评审记录是什么该记录文件的开头声明了其运行上下文这是对分支fix/github-qualifier-strip提交42c5ab5bebcb3d4bd4d8bfc11f89b4df4bc1da9b执行 ce-code-reviewmode:agent后产生的评审发现存档。这些发现在 LFG 流程的第 5 步未被直接应用而是filed for durability登记以保证持久可追溯。记录中分三类组织发现Filed已立案4 项发现P1×1、P2×2、P3×1登记到 GitHub Issuesissue #951 至 #954全部指向 github.py 中限定符剥离相关的代码行Settled-conflict findings已裁决冲突report-only2 项发现与 KTD-1会话内已裁决的计划决策qualifier-only 主题应返回错误信封相冲突因此只记录、不申请应用Residual risks残余风险3 项从评审中带出、暂不立案的潜在问题。要读懂这些发现需要先理解它们所针对的底层缺陷——也就是 issue #949 所描述的限定符冲突问题。2. 缺陷根因两个created:限定符谁说了算问题出在 last30days-skill 的查询规划层plannerLLM 规划的子查询主题串里有时会直接写入 GitHub 搜索限定符例如open source AI stars:1000 created:2025-03-20。而 search_github 在构造查询时会追加自己维护的日期窗口created:{from_date}。源码中的注释github.py#L169-L183完整记录了冲突链两个created:限定符同时出现时GitHub 只认第一个静默忽略适配器追加的那个API 于是返回了窗口之外的条目这些条目又会在parse_github_response的本地日期过滤中被整体丢弃最终表现为一个抓到了结果、却汇报零条结果的源issue #949。3. 剥离机制实现QUALIFIER_KEYS 与正则修复的核心是strip_search_qualifiers在进入查询构造前把主题串里的 GitHub 搜索限定符全部剥掉只保留自然语言主体。实现分三层github.py#L176-L198第一层限定符词表。QUALIFIER_KEYS是一个 36 项的 frozenset覆盖 GitHub 搜索语法中的限定符关键字archived、author、created、is、label、language、repo、stars、state、type、updated等。第二层剥离正则。_QUALIFIER_RE的构造值得逐段拆解_QUALIFIER_RE re.compile( r(?:(?[\s,;])|^)(?: |.join(sorted(QUALIFIER_KEYS)) r):(?:[]?)?(?:\[^\]*\|[^\s,;()\[\]])[,;]?, re.IGNORECASE, )(?:(?[\s,;])|^)限定符必须出现在串首或紧跟空白、逗号、分号之后——这避免了误伤state of the art中不带冒号的普通单词词后必须有:才触发:(?:[]?)?可选的比较符前缀覆盖stars:1000、created:2025-01-01等形态(?:\[^\]*\|[^\s,;()\[\]])值部分。引号值bug fix整体消费跨越空格普通值则停止在空白、逗号、分号、括号、方括号处不会贪吃后一个主题词如created:2025-03-20,robotics中的robotics必须存活末尾可选的[,;]?把粘连的分隔符一并吃掉让ai,created:2025-03-20这类 planner 输出不残留尾逗号。第三层归一化。strip_search_qualifiers用 .join(...split())折叠连续空白并在 docstring 中明确约定当主题只剩限定符时返回空串调用方必须处理绝不能用空词搜索空词会匹配整个站点随后被日期过滤丢弃成一次假无结果。4. 判定边界qualifier-only 路径的错误信封search_github在剥离后github.py#L226-L245core extract_core_subject(topic) plain_core strip_search_qualifiers(core) if plain_core ! core: _log(fStripped search qualifiers: {core} - {plain_core}) if not plain_core: _log(Topic contained only search qualifiers or was empty; nothing to search) return { items: [], context: {core: core, from_date: from_date, to_date: to_date, count: count}, error: ( fGitHub topic contained only search qualifiers or was empty: {topic!r} ), }要点有三其一剥离发生在extract_core_subject之后即取核心主语与剥限定符是两道独立的防线其二qualifier-only 与空主题走同一条报错短路路径不发起任何网络请求其三返回的仍是一个与其他适配器一致的 envelope 形状但携带error字段——从源码结构看这个error字段会决定下游管道对该源的分类成功 / 尝试但失败 / 错误这正是后文 P1 发现的关注点。5. 端到端测试如何固化行为test_github.py 中的两个测试类覆盖了该机制的全部边界可作为验证清单TestStripSearchQualifiers纯函数层用例输入期望输出固化的行为混合主题open source ai stars:1000 created:2025-03-20open source ai基本剥离无冒号普通词ai in healthcare原样in不带:不是限定符大小写Stars:1000空串忽略大小写的纯限定符主题斜杠值repo:facebook/react bugbug值类消费/逗号粘连ai,created:2025-03-20ai,分隔符后紧跟的限定符分号粘连ai;created:2025-03-20ai;同上分号引号值label:bug fix open sourceopen source引号值整体消费不残留fix碎片粘连主题词created:2025-03-20,robotics含robotics值类在分隔符处停止不吞后续词TestSearchGithubQualifierssearch_github端到端层验证了查询串只含一个created:q.count(created:) 1且为适配器自己的窗口、qualifier-only 主题mock_fetch.assert_not_called()零网络调用、state of the art ai中state存活进入查询以及认证场景下is:issue/is:pull-request双分区合并去重并按 reactions 重排。6. 本次评审登记的 4 项发现Filed以下 4 项即记录文件 Filed (tracker: GitHub Issues) 一节的全部内容逐条给出源码级解读P1 — 限定符独占主题被判 ERROR污染重试资格issue #951github.py:237第 237 行是 qualifier-only 路径的return语句该路径返回的 envelope 带error字段。评审发现这个下游的 ERROR/attempted 分类会阻断管道层的瘦结果重试机制。对照 pipeline.py 中的_retry_thin_sources它对结果少于 3 条的源发起简化核心主语的重试但筛选条件显式排除了source not in bundle.errors_by_source——即已被记为错误的源不会进入重试队列。从源码结构看一次 qualifier-only 子查询把 GitHub 源标成 ERROR 后该源在整个 run 内都失去了走瘦结果补救通道的资格。该发现被标注为settled-conflict: report-only per KTD-1KTD-1 是会话内已裁决的计划决策——qualifier-only 主题返回错误信封本就是计划行为因此登记 issue 只为持久化不申请修改代码。P2 — 引号包裹或括号包裹的限定符绕过剥离issue #952github.py:186第 186 行即_QUALIFIER_RE定义。(?:(?[\s,;])|^)这个位置断言要求限定符前是空白/逗号/分号/串首当 planner 输出整段被引号或括号包裹的形态如stars:1000或(created:2025-03-20)冒号前是或(而非空白时正则不会匹配限定符可能残留进最终查询重新制造 issue #949 的双created:冲突。P2 — 空主题或噪音限定符主题翻转为硬 ERRORissue #953github.py:231第 231 行if not plain_core:分支把空主题与 qualifier-only 主题一视同仁地翻转为携带error的硬失败。评审认为这与 KTD-1 / R3 的裁决此类主题应返回错误信封存在边界争议——例如主题中还有无法构成有效查询的噪音词残留时硬 ERROR 与正常搜索但零结果的语义边界不清。同样标注settled-conflict: report-only per KTD-1登记 issue #953 仅为持久化。P3 — 重复的 qualifier-only 子查询刷屏日志与错误详情issue #954github.py:229当 plan 里多个子查询都退化到 qualifier-only例如 planner 对多个实体各生成一条限定符串每条都会执行第 229 行附近的Stripped search qualifiers日志与第 236 行的Topic contained only search qualifiers or was empty日志并在各自的 envelope 中写入完整的topic!r错误详情——子查询数量放大时日志和错误详情会出现重复刷屏。7. Settled-conflict 小节为何已裁决冲突只报不修记录文件的 Settled-conflict findings (report-only, not filed as apply requests) 一节对上述 P1/P2 两项做了补充说明这是理解 ce-code-review 流程的关键两项发现都与 **KTD-1session-settled plan decision**冲突——即在制定计划阶段对应计划文档fix-github-qualifier-collision的会话已经裁决qualifier-only 主题返回错误信封这一语义。发现本身技术上成立如 P1 指出的_retry_thin_sources阻断效应但修改它会推翻既有裁决因此这些发现filed as #951/#953 for durability, not for application——issue 是证据存档不是待修工单。No sink / failed 一节为 None说明所有发现都成功落盘Proceeded-and-flagged settled-decision conflicts (from ce-work step 2) 一节亦为 None说明 ce-work 步骤 2 没有额外返回需继续放行但打标记的冲突决策。8. 评审带出的 3 项残余风险记录文件 Residual risks carried from the review 一节列出了三条暂不立案、但需要被后续读者知晓的风险逐条对照源码验证错误信封中context[core]未剥离而成功路径已剥离当前无消费者受影响。对照源码确实如此qualifier-only 分支返回时context里的core用的是extract_core_subject(topic)的原始结果github.py#L237-L244而成功路径在 github.py#L245 执行core plain_core后parse_github_response消费的是剥离后的context[core]用于计算相关性_compute_relevance。两条路径的context[core]语义不一致属于潜在的地雷而非现网缺陷——记录也明确写了 no current consumer is affected。GitHub 对未闭合引号返回 422 是外部 API 行为未被测试覆盖。_QUALIFIER_RE的值类\[^\]*\只消费闭合引号planner 若输出未闭合引号如label:bug残留在查询串中会触发 GitHub/search/issues的 422而仓库测试只覆盖了闭合引号形态。这是外部依赖行为单测只能靠 mock 固化己方逻辑无法替 GitHub 背书。planner 吐出逗号粘连、带引号、包裹形态的限定符是 LLM 行为暴露面无法从代码量化。这一条点明了整个缺陷类别的根本性质输入形态的空间由 LLM 生成而正则剥离只能覆盖已观察到的形态。测试类中ai,created:...、label:bug fix等用例都是对历史观察形态的回归保护新形态出现时需要补正则与补测试。9. 从这份 Findings 文档学到的工程实践该记录虽然只有几十行却完整展示了一种可复用的评审存档范式发现必须落到精确行号与 issue 编号4 项 Filed 发现全部带文件:行号与 issue 号使评审意见可被后续任何一次评审直接交叉引用区分可应用与已裁决冲突settled-conflict 发现单独成节并标注 report-only避免自动化流程误把推翻会话裁决的修改当作普通 bugfix 应用残余风险独立成节不满足立案条件无法复现、外部行为、不可量化的风险不丢弃而是显式 carry 到文档里防止下轮评审重复发现或遗忘。如果你要复核本文的全部论断入口是三个文件记录本体 42c5ab5bebcb3d4bd4d8bfc11f89b4df4bc1da9b.md、被评审的实现 github.py限定符剥离与查询构造集中在 L169–L343以及验证这些行为的测试 test_github.pyTestStripSearchQualifiers与TestSearchGithubQualifiers两个类。管道侧重试资格的判定在 pipeline.py 的_retry_thin_sources。需要说明的适用前提本文所有行号与行为描述均以当前仓库快照为准记录文件提及的计划文档2026-08-07-001-fix-github-qualifier-collision-plan.md在当前仓库中不存在文中对 KTD-1 的转述以该记录文件自身文字为限。【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考