research-bench 是面向模型架构研究的工作流套件,把研究方向判断、架构改动、对照实验、结果审计和远程
触发组织成一套可复现、可维护的流程。仓库现在由三部分组成:rf(Research Flow,研究流程插件)、
ef(Experiment Flow,实验流程插件)和 remote-control(可选的自建远程触发服务)。
rf 与 ef 是可安装的插件,同时支持 Claude Code 与 Codex CLI 两种运行时(双 manifest:
.claude-plugin/ + .codex-plugin/,共享同一套 skill;宿主差异由各 skill 开场引用的
references/host-compatibility.md 兼容协议吸收),分别覆盖研究决策与实验落地;remote-control
不是插件,而是给自有服务器部署的 Web/API 服务,用于从浏览器安全触发和查看 Claude Code 会话。
方向发现由外部插件承担:研究方向的发散、辩论、外部检索验证与 RQ 确认交给同作者的
PaperCompass(hotspot-to-rq 插件,双运行时、
带可审计状态机与 user gate);rf 通过 import-direction 桥接把确认后的会话导入为方向 dossier
与注册表条目,再进入本套件的实验链路。
| 插件 | 命名空间 | 负责什么 |
|---|---|---|
rf |
/rf:<skill> |
Research Flow:架构分析、方向导入与管理、结果审计 |
ef |
/ef:<skill> |
Experiment Flow:环境构建部署、对照实验、工作流测试 |
hotspot-to-rq(外部) |
/hotspot-to-rq:<skill> |
方向发现:热点→辩论→RQ 确认 / 实验去留评估(独立安装,见 §2) |
两个插件共享同一份项目配置文件 .claude/research-bench.config.md(路径、执行环境、数据、指标、
跟踪系统等项目专属信息都写在这里)。建议两个都装以获得完整工作流;只装一个也能独立工作,但会
有 §8 边界说明里列出的保护机制缺口。
research-bench(简称rb)是仓库的品牌名,本身不是一个可安装的插件。
L3 意图层 skills —— 用户入口，负责交互、判断和委托
│ 委托
L2 服务层 agents —— 四类服务承担分析、执行、验证和维护(方向探索与审查在外部 PaperCompass)
│ 调用
L1 驱动层 项目契约脚本 —— 固定子命令作为执行接口
│ 保障
L0 机制层 hooks + config manifest —— 提供保护机制和机器可读配置
| 服务 | 职责 | 工具范围 | 记忆策略 | 所在插件 |
|---|---|---|---|---|
architect |
分析源码结构、数据流、改造位置和权重兼容性 | 只读源码，可写分析文档 | project memory + 记忆规则 | rf |
operator |
按配置中的 ISA 映射执行关键操作并返回脱敏执行回执 | Bash / Read / Grep，无写工具 | 无记忆；执行发现写入回执 | rf + ef(两边都有) |
auditor |
审计实验计划与结果完整性，输出缺口和待办 | 只读，无 WebSearch | 无记忆 | rf |
steward |
维护工作流配置、脚本和文档一致性 | 读写工作流脚手架 | project memory + 记忆规则 | rf + ef(两边都有) |
方向的发散、辩论与价值审查不在本仓库的服务里:它们由外部 PaperCompass 的多代理辩论完成(Mentor /
Evidence Researcher / Devil's Advocate / Panel Judge 等角色,含外部检索验证与用户决策门)。auditor
的审计报告可以作为 PaperCompass 辩论的输入证据(单向:本套件产出、辩论消费);辩论确认的 RQ 经
import-direction 导入,写入注册表和方向档案仍需用户确认。auditor 遵循
references/evidence-protocol.md(协议文档只在 rf 插件里),不提出新方向。
operator(rf、ef 都携带一份，供各自委托的 skill 调用)只执行配置 §7.2 中声明的七个操作：
- 关键操作：
sync-code、install-editable、pull-data、smoke、launch - 轻量操作：
status、collect
关键操作必须通过 operator 执行；轻量操作可由主流程直接执行。每个操作在项目配置中映射到具体脚本或命令，并声明后置条件和敏感环境变量。launch 成功后写入租约文件，sync-code 和 install-editable 前检查租约，避免影响正在执行的训练任务。
仓库包含 .claude-plugin/marketplace.json，列出 rf、ef 两个插件。先添加这个仓库作为
marketplace，再分别安装需要的插件（推荐两个都装）：
/plugin marketplace add Endofthestars/research-bench
/plugin install rf@research-bench
/plugin install ef@research-bench
Codex 侧 marketplace 是 .agents/plugins/marketplace.json(同名 research-bench):
codex plugin marketplace add Endofthestars/research-bench
codex plugin add rf@research-bench
codex plugin add ef@research-bench更新时执行 codex plugin marketplace upgrade research-bench 后重新 codex plugin add;
安装或更新后新建一个 Codex 任务,旧任务不会热加载新技能。Codex 中调用 skill 用
"使用 rf:init 初始化研究工作流"这类点名方式(无前导 /)。
若使用 discovery 模块(方向发现桥接),还需安装外部插件 PaperCompass(独立 marketplace,
名为 personal):
/plugin marketplace add Endofthestars/PaperCompass
/plugin install hotspot-to-rq@personal
更新插件：
/plugin marketplace update research-bench
也可以先克隆仓库，再把本地目录添加为 marketplace 后安装（与 GitHub 安装同一套机制，仅来源不同）：
git clone git@github.com:Endofthestars/research-bench.git/plugin marketplace add /绝对路径/research-bench
/plugin install rf@research-bench
/plugin install ef@research-bench
开发调试时也可以不安装、按次加载：
claude --plugin-dir /绝对路径/research-bench/res-flow --plugin-dir /绝对路径/research-bench/exp-flow注意：不支持在
.claude/settings.json中以"plugins": [路径]的形式引用插件——该字段不存在， 这样写插件不会被加载，skill 也不会获得rf:/ef:命名空间，/init会命中 Claude Code 自带的同名命令而不是本插件的rf:init。请使用上述两种方式之一。
首次在项目中启用插件时，SessionStart hook（rf、ef 各自携带一份）会检查
.claude/research-bench.config.md 是否存在。若尚未初始化，会提示运行：
/rf:init
或
/ef:init
二者行为等价（init 是两个插件都携带的共享 skill），装了哪个插件就用哪个的命名空间调用；两个都装时用哪个都一样。
初始化流程包括：
- 本地只读预扫描：检查
.gitmodules、Docker、GPU、venv/conda、DVC、依赖文件、.env等线索。 - 选择模块：先按研究阶段选场景预设——「找方向包」（core+directions+discovery）、「执行包」（core+exec+data+tracking）、「全家桶」（全模块），选完可微调；
core必选。 - 选择执行档案：启用
exec时，通过“执行位置 × 运行时”确定exec-profile。 - 生成配置：装配
.claude/research-bench.config.md，并按模块裁剪配置段。 - 实例化项目骨架：生成方向模板、路线图、检查清单、测试脚本和本地启动脚本；已有文件不覆盖。
- 填写关键值：如
source-dir、执行句柄、工作目录、tracking 端点等。 - 收尾校验：提示占位残留，并在启用
exec时执行保护机制回归测试。
如需新增/删除模块或切换执行档案，再次运行 /rf:init 或 /ef:init。
/rf:config 或 /ef:config（两者等价）用于查看和修改项目配置：
- 查看：输出 manifest、启用模块、关键配置值和占位残留统计。
set <键> <值>：定点修改配置值，写入前展示旧值和新值。config init modules=core,exec exec-profile=local-venv source-dir=src/ ...：非交互初始化配置和骨架。set env.RW_EXEC_PATTERN <模式>或set env.RW_TRAIN_PATTERNS <模式>：经确认后更新.claude/settings.json的"env"。
职责边界：
- 交互初始化、模块增删、执行档案变更：使用
init。 - 查看配置、定点改值、非交互初始化：使用
config；菜单式逐项浏览修改：使用settings。 - 修改脚本、hook、skill、agent、检查清单等脚手架内容：使用
update-workflow。
core 是必选模块，不依赖执行环境或实验跟踪系统。
| 能力 | 载体 | 所在插件 |
|---|---|---|
| 架构分析 | analyze-architecture skill → architect agent |
rf |
| 安全修改架构或 loss | modify-architecture skill |
rf |
| 源码写保护 | guard-protected-write hook |
rf |
需要填写配置 §1–§4：项目性质、源码布局、指标和提交规范。
exec 启用实验执行链路和训练启动保护机制。执行档案由“位置 × 运行时”组成：
| docker | venv/conda | |
|---|---|---|
| remote | remote-docker：远程 docker daemon，支持 build + deploy 链路 |
remote-venv：通过 ssh 和环境激活执行 |
| local | local-docker：本机 docker 容器执行 |
local-venv：通过 scripts/run.sh 执行 |
四种档案共享同一约束：训练必须通过受控启动通道执行。guard-train-channel（ef 插件携带）会拦截带训练特征但未匹配受控通道的 Bash 命令。
需要填写配置 §5–§7：执行环境、实验脚手架、保护机制模式和 ISA 映射表。§7.1 的模式也可写入项目 .claude/settings.json：
{
"env": {
"RW_TRAIN_PATTERNS": "--train|train_loop|fit\\.py",
"RW_EXEC_PATTERN": "docker[[:space:]]+--context.*(exec|run)"
}
}data 为 run-experiment 提供 pull-data 步骤，并为 deploy-env 提供权重预下载约定。需要填写配置 §8。
tracking 为实验记录和结果审计提供定量证据来源。需要填写配置 §9。
directions 提供方向模板、方向注册表、教训库和方向漂移核查。相关能力包括 import-direction、audit-results（均 rf）和 run-experiment（ef）的方向选择步骤。需要填写配置 §10。
maintenance 提供工作流审计、更新和测试能力：
audit-workflow：只读审计配置、提示词和脚本一致性。（rf、ef都有）update-workflow：通过steward两阶段修改工作流脚手架。（rf、ef都有）test-workflow：调用项目确定性测试脚本。（仅ef）
需要填写配置 §11。
discovery 把方向发现交给外部插件 PaperCompass 的 hotspot-to-rq（论文热点扫描 → 多代理苏格拉底辩论 → 外部检索验证 → 用户确认 RQ,全程 schema 1.3 可审计状态机 + gate receipt），本模块只负责导入侧：import-direction 校验已确认的 PaperCompass 会话（status: COMPLETE + RQ CONFIRM receipt,fail-closed）,交互补齐 flag / baseline_group / access_level 等本套件维度,产出方向落地块经 update-workflow 落 dossier 并登记注册表,同时在 gates.jsonl 追加 papercompass 导入裁决行（evidence_ptr 指向会话目录,作为审计凭证不得删改）。pilot 关卡照旧（当前人工判定）。依赖 core 与 directions。需要填写配置 §12,并按 §2 安装 PaperCompass。
本节为两个插件全部 skill 的规范说明。两个插件共提供 13 个 skill，其中 5 个（init、config、settings、audit-workflow、update-workflow）在 rf、ef 中各存在一份功能等价的副本。
每个 skill 同时附带一份同名的 commands/<skill>.md 薄壳,与 skill 共用 插件名:skill 名 的调用名——功能一致,仅为保证各版本 Claude Code 下斜杠补全均可用。
所有 skill 在执行前均读取 .claude/research-bench.config.md 的 frontmatter manifest 以确认模块启用状态，并遵循统一的门控规则：配置文件不存在时终止执行并提示运行 init；必需模块未启用时终止执行并提示通过 init 启用；可选模块未启用时降级执行，并显式说明被省略的步骤。
| Skill | 所在插件 | 必需模块 | 可选模块 | 执行方式 |
|---|---|---|---|---|
init |
rf、ef | — | — | 主流程（交互式） |
config |
rf、ef | — | — | 主流程 |
settings |
rf、ef | — | — | 主流程（多轮交互） |
analyze-architecture |
rf | core | — | 委托 architect |
modify-architecture |
rf | core | exec | 主流程；smoke 测试委托 operator |
import-direction |
rf | core、directions、discovery | — | 主流程（校验 + 逐维问答） |
audit-results |
rf | tracking | directions | 委托 auditor |
run-experiment |
ef | exec | data、tracking、directions | 主流程；关键操作委托 operator |
build-env |
ef | exec（docker 运行时） | — | 委托 operator；仅限手动触发 |
deploy-env |
ef | exec（remote-docker 档案） | data | 委托 operator；仅限手动触发 |
test-workflow |
ef | maintenance | exec | 主流程（调用测试脚本） |
audit-workflow |
rf、ef | maintenance | 其余模块 | 主流程（只读） |
update-workflow |
rf、ef | maintenance | — | 两阶段委托 steward |
以下 5 个 skill 在 rf、ef 中各携带一份，功能等价，调用时使用所装插件对应的命名空间。
功能：将插件内置的分段配置模板装配为项目配置文件 .claude/research-bench.config.md，并实例化项目工作区骨架文件（方向模板、研究路线图、工作流检查清单、测试脚本、本地启动脚本）。
行为特性：幂等且可重入。对已初始化的项目再次执行时，进入模块增删或执行档案切换模式；已存在的骨架文件不予覆盖，仅执行契约探测。完整初始化流程见 §3。
适用场景：首次在项目中启用插件；新增或删除模块；切换执行档案（exec-profile）。
功能：项目配置的查看与定点修改入口，遵循「配置文件为单一事实来源」原则。提供四种调用形式：
- 无参数调用：输出 manifest、启用模块、关键配置值及占位符残留统计；
set <键> <值>：定点修改单个配置值，写入前展示修改前后的值；config init <键值对>：非交互方式完成配置初始化与骨架实例化；set env.RW_TRAIN_PATTERNS <模式>/set env.RW_EXEC_PATTERN <模式>：经用户确认后写入项目.claude/settings.json的"env"字段。
职责边界：仅处理配置段内单值的修改。模块装配与执行档案变更归属 init；涉及跨文件同步的脚手架修改归属 update-workflow；不记得键名、想菜单式浏览修改时使用 settings。
功能：以菜单形式浏览与修改项目配置，体验对标 Claude Code 内置 /config 面板。主菜单按 manifest 只列已启用模块的配置段；进入段后采用「一轮多问」模式，每轮最多同屏呈现 4 个键（每键首选项为「保持当前值」即跳过），有变更的键仍逐个展示旧值与新值并单独确认写入。支持直达参数（如 settings 5、settings tracking、settings env）跳过主菜单。
与 config 的关系：同一套数据与写入规则（含 env.RW_* 特例、source-dir 双处同步、职责转介），仅交互形态不同——config 面向定点命令式调用，settings 面向逐项浏览式调用。修改 modules / exec-profile 时同样转介 init。
适用场景：不记得配置键名；初始化后想逐段检查并补填占位值；希望在菜单里连续调整多个配置项。
功能：检查工作流配置、提示词与脚本之间的一致性。该 skill 为只读操作，仅输出报告，不实施任何修改。提供两种模式：
- 快照模式：输出当前工作流结构的只读快照，内容按 manifest 裁剪，未启用模块对应的章节予以省略并注明；
- 清单模式：以配置 §11 指定的工作流检查清单为唯一标准逐条核对，报告配置漂移、内容冗余、职责重叠及保护机制缺口。
后续动作：审计发现的问题统一通过 update-workflow 修复。
功能：对工作流脚手架（.claude/ 配置、scripts/、容器构建文件、experiments/、工作区文档）实施修改的统一入口，为 steward 服务的正式调用通道。
流程：采用两阶段确认机制。第一阶段由 steward 产出改动计划、逐文件 diff 及关联同步清单，此阶段不写入任何文件；第二阶段由主流程将计划完整呈现给用户预览；用户确认后，由同一 steward 实例应用改动并按检查清单执行同步自检。
约束：不得自动削弱保护机制、约束条件或检查标准；模块的增删不属于本 skill 职责范围，须经由 init 执行。
功能：将源码调研任务委托给 architect 服务（只读、隔离上下文）执行，产出物包括：相关文件与函数定位、当前数据流描述、改动点及其对预训练权重加载的影响评估，以及「可安全改造」与「高危改动」的分类标注。
产出管理：分析结论沉淀至配置 §2 指定的架构地图文档；主对话仅接收摘要，不引入完整源码内容。
适用场景：架构理解、改动位置定位、改动风险评估；作为 modify-architecture 的前置分析步骤。
功能：对配置 §2 SOURCE_DIR 下的模型源码实施受控修改（decoder 结构、新增模块、loss 函数、目标表示等），全部改动须满足可控、可回滚、可对照、可复现四项要求。
核心规则：改动必须实现为可开关的 flag（默认关闭时行为等价于原版），禁止将改动实现为不可关闭的默认行为；消融实验与回滚均以此为前提。
流程要求：改动前须经 analyze-architecture 确认改动点与权重兼容性影响，并执行一次 smoke 测试作为对照基线。启用 exec 模块时，smoke 测试委托 operator 执行；未启用时提示用户自行验证前向与反向传播。
功能：把一个已确认的 PaperCompass（hotspot-to-rq）方向会话导入为本项目的方向 dossier 与注册表条目。方向的发散、辩论、外部检索验证与 RQ 确认都在 PaperCompass 侧完成；本 skill 只做导入桥接。
校验（fail-closed，判据见配置 §12.1）：session-state.json 须满足 schema_version: 1.3（或 legacy 1.1/1.2）、status: COMPLETE、gate_receipts 含绑定候选与 RQ packet 的 CONFIRM receipt，且 rq-brief.md 存在；任一不满足即拒绝导入。能定位 hotspot-to-rq 安装目录时先跑其 validate_session.py 强校验。
缺维补齐：PaperCompass 产物没有 flag / baseline_group / access_level 维度，在主流程逐维问答补齐（含注册表 slug 冲突与教训库比对），不得代填。
产出：方向落地块（默认 status: surveyed）+ gates.jsonl 的 papercompass 导入裁决行（evidence_ptr 指向会话目录），经 update-workflow 落盘登记。evaluate 类会话不在本 skill 范围。
功能：将结果核查任务委托给 auditor 服务（只读、无状态）执行，依据实验计划从完整性、方向漂移、可信度、论文必要性四个维度核对现有结果，输出结构化的「待办实验清单」，标注缺失实验及不可信实验（如随机种子数量不足、未从 smoke 规模升级至全量、OOD 评估未执行等情形）。
适用场景：一批实验完成后的缺口盘点；论文实验章节撰写前的完备性检查。审计报告同时可作为 PaperCompass 方向辩论（DISCOVER / EVALUATE 模式）的输入证据。
功能：按执行档案（remote-docker / remote-venv / local-docker / local-venv）执行训练实验，涵盖 baseline 对照、实验跟踪记录与复现信息留存。
操作分级：依据配置 §7.2 的 ISA 映射，操作分为两级。关键操作（sync-code、install-editable、pull-data、smoke、launch）以完整序列一次性委托 operator 执行；轻量操作（status、collect）由主流程直接执行，同样受保护机制约束。
并发保护：launch 成功后写入租约文件；sync-code 与 install-editable 执行前检查租约，防止干扰正在进行的训练任务。
功能：按配置 §5.2 定义的镜像分层（底座镜像、项目层镜像）在本地构建环境镜像。职责限定为构建，不包含远程传输。
适用范围：仅适用于 docker 运行时档案（remote-docker、local-docker）。venv 档案下调用时明确提示不适用并指引至配置 §5.3。
触发方式：仅限用户手动触发（disable-model-invocation: true），适用时机为依赖、CUDA 或框架版本发生变化。与 deploy-env 构成两阶段链路；local-docker 档案下构建完成即可在本机使用。
功能：将 build-env 构建完成的镜像传输至远程 docker daemon；启用 data 模块时，同时通过 pull-data 操作预下载预训练权重。
适用范围：仅适用于 remote-docker 档案；其余档案下调用时明确提示不适用。传输命令取自配置 §5.2 的 deploy 脚本，经 operator 执行。
触发方式：仅限用户手动触发，适用时机为依赖变化并重新构建镜像之后。
功能：调用配置 §11 指定的确定性测试脚本（约定为 scripts/test-workflow.sh），验证保护机制拦截行为、本地健康检查、ISA 映射 dry-run 及远程只读连通性，并对脚本输出进行解读。测试结论由脚本断言决定，skill 不自行判定。
定位：与 audit-workflow 构成互补关系——audit 检查配置一致性（读取与推理，不执行），test 验证脚本实际行为（执行断言）。
适用场景：修改 guard hook、.claude/settings.json、脚本或容器构建文件之后的回归确认。
research-bench/ (仓库根 = research-bench / rb 品牌)
├── .claude-plugin/
│ └── marketplace.json # Claude Code marketplace:列出 rf、ef 两个插件
├── .agents/plugins/
│ └── marketplace.json # Codex marketplace(同名 research-bench,同两个插件)
├── res-flow/ # Research Flow 插件,命名空间 /rf:<skill>(Codex 中 rf:<skill>)
│ ├── .claude-plugin/plugin.json
│ ├── .codex-plugin/plugin.json # Codex manifest,版本与 Claude 侧保持一致
│ ├── agents/
│ │ ├── architect.md
│ │ ├── auditor.md
│ │ ├── operator.md # 与 ef 共享,供 modify-architecture 的可选 smoke test 委托
│ │ └── steward.md # 与 ef 共享,供 update-workflow 委托
│ ├── skills/
│ │ ├── analyze-architecture/
│ │ ├── modify-architecture/
│ │ ├── import-direction/ # PaperCompass 方向会话导入桥接(方向发现在外部 PaperCompass)
│ │ ├── audit-results/
│ │ ├── init/ # 与 ef 共享,完整复制,自引用改写为 /rf:
│ │ ├── config/ # 同上
│ │ ├── settings/ # 同上
│ │ ├── update-workflow/ # 同上
│ │ └── audit-workflow/ # 同上
│ ├── commands/ # 每个 skill 一份同名薄壳,保证 /rf: 斜杠补全可靠
│ ├── hooks/
│ │ ├── hooks.json # 只声明本插件实际携带的 hook
│ │ ├── session-init-check.sh # 与 ef 共享(幂等,双装时重复触发可接受)
│ │ └── guard-protected-write.sh # 仅 rf:保护 SOURCE_DIR 写入
│ ├── references/
│ │ ├── evidence-protocol.md
│ │ └── host-compatibility.md # Claude/Codex 宿主兼容协议(与 ef 共享)
│ └── templates/ # 与 ef 内容相同的完整复制(init 需要全部 7 个模块模板)
│ ├── config/{00-core,10-exec,20-data,30-tracking,40-directions,50-maintenance,60-discovery}.md
│ ├── config/ops-presets/
│ └── project/{RESEARCH_ROADMAP.md, workflow-checklist.md, directions/_TEMPLATE/, scripts/}
├── exp-flow/ # Experiment Flow 插件,命名空间 /ef:<skill>(Codex 中 ef:<skill>)
│ ├── .claude-plugin/plugin.json
│ ├── .codex-plugin/plugin.json
│ ├── agents/
│ │ ├── operator.md # 与 rf 共享
│ │ └── steward.md # 与 rf 共享
│ ├── skills/
│ │ ├── build-env/ # 内含 agents/openai.yaml(Codex 显式触发策略)
│ │ ├── deploy-env/ # 同上
│ │ ├── run-experiment/
│ │ ├── test-workflow/
│ │ ├── init/ # 与 rf 共享,完整复制,自引用改写为 /ef:
│ │ ├── config/ # 同上
│ │ ├── settings/ # 同上
│ │ ├── update-workflow/ # 同上
│ │ └── audit-workflow/ # 同上
│ ├── commands/ # 每个 skill 一份同名薄壳,保证 /ef: 斜杠补全可靠
│ ├── hooks/
│ │ ├── hooks.json # 只声明本插件实际携带的 hook
│ │ ├── session-init-check.sh # 与 rf 共享
│ │ └── guard-train-channel.sh # 仅 ef:训练启动通道保护
│ └── templates/ # 与 rf 内容相同的完整复制
├── remote-control/ # 可选服务:自建远程触发/监控 Claude Code 会话
│ ├── server/ # FastAPI 后端
│ ├── web/ # 静态 Web 面板 + PWA
│ ├── deploy/ # systemd / Caddy / env 模板
│ └── docs/SECURITY.md # 公网部署前必须阅读的安全说明
├── .claude/ # 仓库自身的开发工具(不随插件分发)
│ ├── agents/ # plugin-dev / service-dev / consistency-auditor
│ └── skills/ # /add-capability /sync-shared /release
├── shared/ # rf/ef 共有文件的唯一事实来源({{P}} 占位符 = 插件前缀)
├── scripts/
│ └── sync-shared.sh # 把 shared/ 渲染进两个插件;--check 校验漂移
├── docs/DESIGN.md
├── CHANGELOG.md
├── LICENSE
└── README.md
- 模型策略：所有 agent 默认继承主会话模型，不在 frontmatter 中声明
model。如需固定模型，可在对应 agent frontmatter 中添加model字段。 - 写保护边界：
guard-protected-write只覆盖 Claude Code 的Edit、Write、MultiEdit工具写入，且只在rf插件里。只装ef、不装rf时，源码写保护不生效——这是拆分后接受的缺口，正常使用预期两个插件一起装。同理guard-train-channel只在ef里，只装rf时训练启动通道保护不生效。通过 Bash 间接写入仍依赖 Claude Code 权限模式和用户确认。 - Codex 宿主的保护边界：Codex 插件不加载 Claude hooks。
references/host-compatibility.md要求 Codex 主流程在每次写源码 / 改 settings / 执行训练特征命令前做同规则的模型级预检,但这不等价于系统级 hook 强制——任何 skill 不得宣称 Codex 已获得 hook 级保证。build-env/deploy-env的"仅显式触发"在 Claude 侧靠正文约束,在 Codex 侧由agents/openai.yaml的allow_implicit_invocation: false承担。 - 共享 skill 的分叉：
init/config/update-workflow/audit-workflow在rf、ef里各有一份完整复制，功能等价，但文字里的自引用前缀分别是/rf:和/ef:——这是有意为之的分叉，不是不一致；两个插件都装时，同名 skill 会在两个命名空间下各出现一次，属预期行为。 - 重复触发：两个插件都装时，
session-init-check（SessionStart）会各自触发一次，多打印一行提示；该 hook 只读、无副作用，重复触发是可接受的噪音。 - 共享内容的维护方式：共享的 skill/agent/模板/hook 以顶层
shared/为唯一事实来源（{{P}}占位符代表插件前缀），由scripts/sync-shared.sh渲染成res-flow/、exp-flow/内的真实文件副本（公开分发的插件仓库不适合依赖符号链接）。改共享内容只改shared/，改完运行同步脚本；插件目录里的副本是生成物，直接手改会在下次同步时被覆盖。scripts/sync-shared.sh --check可校验两侧是否漂移。 - 平台要求：hook 依赖 bash。Windows 环境建议使用 WSL 或 Git Bash。
- 配置提交策略：项目配置可能包含内网路径、端点和执行句柄。公开仓库不应提交包含敏感信息的项目配置。
- 方向发现的外部依赖：
discovery模块依赖外部插件 PaperCompass（hotspot-to-rq，独立仓库与 marketplace，许可含 CC BY-NC 内容，不并入本仓库）。未安装 PaperCompass 时import-direction无输入可导，方向立项退化为手工编辑 dossier + 注册表（须在 gates.jsonl 留"verdict":"skip"记录）;本仓库不再内置查新与对抗审查能力。
MIT，见 LICENSE。本插件只包含 Claude Code 工作流脚手架，不包含任何模型框架或训练框架源码。
- 通用方法与项目配置分离：skill 和 agent 描述通用流程，项目专属值集中在配置文件。
- 机器可读与人可读分离：hook 需要读取的值放在 frontmatter manifest，其余说明放在正文配置段。
- 意图与执行分离：skill 负责交互和委托，关键操作通过
operator按 ISA 执行。 - 模块化启用：基础能力来自
core，执行、数据、跟踪、方向、维护和方向发现能力按需启用。 - 职责边界清晰：分析、执行、审计和维护分别由不同 agent 承担；方向探索与价值审查交给外部 PaperCompass,本套件只做可审计的导入。
- 保护机制不可自动削弱：修改保护机制、检查标准或权限配置时必须显式说明并获得用户确认。