diff --git a/emrg/server/open_source_prompt.md b/emrg/server/open_source_prompt.md index 1cbc99d..58334fd 100644 --- a/emrg/server/open_source_prompt.md +++ b/emrg/server/open_source_prompt.md @@ -38,11 +38,11 @@ gh auth status 2>&1 || { TOKEN=$(printf "protocol=https\nhost=github.com\n\n" | git credential fill 2>/dev/null | grep '^password=' | cut -d= -f2-) if [ -n "$TOKEN" ]; then export GH_TOKEN="$TOKEN" - echo "gh 未认证 — 已从 git 凭据提取 token (GH_TOKEN)" + echo "gh not authenticated — token extracted from git credentials (GH_TOKEN)" gh auth status 2>&1 fi else - echo "gh 未认证 — 请在 EMRG GUI 设置页连接 GitHub（无需终端）" + echo "gh not authenticated — connect GitHub from the EMRG GUI settings page (no terminal needed)" fi } ``` @@ -115,20 +115,20 @@ cd {{ source_dir }} && git status --short --branch 2>&1 #### 0.4 Read the state file ```bash -cat {{ evolution_cwd }}/open_source_{{ owner }}_{{ repo }}_state.md 2>/dev/null || echo "[新状态文件]" > {{ evolution_cwd }}/open_source_{{ owner }}_{{ repo }}_state.md +cat {{ evolution_cwd }}/open_source_{{ owner }}_{{ repo }}_state.md 2>/dev/null || echo "[new state file]" > {{ evolution_cwd }}/open_source_{{ owner }}_{{ repo }}_state.md ``` State file format: ```markdown # Open-Source State: {{ owner }}/{{ repo }} -- 角色: Committer | Contributor -- 当前阶段: 准备 | 侦察 | 贡献 | 追踪 | 审查 -- 上次完成: <上一轮做了什么> -- 活跃PR: <自己的 open PR 列表，每行一个> -- 进行中: <正在实现的内容 | 无> -- 下一步: <本轮计划做什么> -- 阻塞: <什么在阻止进展？空=无阻塞> +- role: Committer | Contributor +- current stage: Prep | Recon | Contribute | Track | Review +- last completed: +- active PRs: +- in progress: +- next step: +- blocked: ``` #### 0.5 Rant scan (host development instructions) @@ -178,10 +178,10 @@ cd {{ source_dir }} && git log --oneline -20 Unhandled rant found in 0.5 (project matches, pending/in_progress, dedup check passed)? → Phase Contribution (handle the rant — host instruction, highest priority) -Is "进行中" (in progress) in the state file non-empty? +Is "in progress" non-empty in the state file? → Phase Contribution (continue the unfinished implementation) -Are there open items in "活跃PR" (active PRs)? +Are there open items in "active PRs"? → Phase Tracking (check PR status, respond to reviews) No active work? @@ -262,11 +262,11 @@ When Phase Contribution is entered because an **unhandled rant** (project-matchi ```bash cd {{ source_dir }} # Read the contributing guide (if present) -cat CONTRIBUTING.md 2>/dev/null || echo "[无 CONTRIBUTING.md]" +cat CONTRIBUTING.md 2>/dev/null || echo "[no CONTRIBUTING.md]" # Read the PR template (if present) -cat .github/pull_request_template.md 2>/dev/null || echo "[无 PR 模板]" +cat .github/pull_request_template.md 2>/dev/null || echo "[no PR template]" # Check for other convention files -ls .github/ 2>/dev/null || echo "[无 .github 目录]" +ls .github/ 2>/dev/null || echo "[no .github directory]" ``` Extract from these files and strictly follow: @@ -282,18 +282,18 @@ Extract from these files and strictly follow: #### B.2b Read the full codebase (MUST before contributing) -> ⚠️ 前提：**每次贡献前都重新读取最新代码**（0.3 Source sync 已保证 `git pull` 到最新；任何贡献思路都建立在你刚拉取的最新代码上，不得用记忆/旧版本代码做判断）。 +> ⚠️ Prerequisite: **re-read the latest code before every contribution** (0.3 Source sync guarantees `git pull` to latest; any contribution idea must be built on the code you just pulled — never on memory or stale code). -**读完整代码**（不止是目标文件）： -- 先看仓库根：README / docs / 目录结构 → 理解项目定位、模块划分 -- 通读核心模块源码（按目录树从上到下，理解每个模块职责） -- 定位到与本次 Issue/目标相关的代码时，**精读相关文件全文**（不只看改动点附近） +**Read the full codebase** (not just the target files): +- Start at the repo root: README / docs / directory structure → understand the project's positioning and module layout +- Read through the core module sources (top-down through the directory tree, understanding each module's responsibility) +- When you locate the code relevant to this Issue/goal, **read the full relevant files closely** (not just around the change point) -**以 repository 作者的视角理解设计意图**： -- 问自己：作者为什么这样设计？这个函数/模块解决什么问题？为什么用这个模式（而非别的方式）？ -- 读提交历史 / git blame：理解代码演化脉络，不臆测作者意图 -- 设计意图不明 → 读测试（测试即文档），读 Issue/讨论记录 -- **只有当你理解了作者的设计意图，才考虑怎么贡献** —— 贡献必须顺应既有设计，而不是另起炉灶 +**Understand the design intent from the repository author's perspective**: +- Ask yourself: why did the author design it this way? What problem does this function/module solve? Why this pattern (vs. another way)? +- Read commit history / git blame: understand the code's evolution, don't guess the author's intent +- Unclear intent → read the tests (tests are docs), read Issues/discussion records +- **Only when you understand the author's design intent should you consider how to contribute** — contributions must follow the existing design, not start from scratch #### B.3 Fork and branch @@ -323,7 +323,7 @@ cd {{ source_dir }} # - Go: go test ./... 2>&1 || echo "⚠️ test failures" # # 2. If the project has no tests → at least manually verify the change: -python -c "<验证代码片段>" 2>&1 || echo "⚠️ verification failed" +python -c "" 2>&1 || echo "⚠️ verification failed" ``` - Tests failing → fix the code → re-test → until passing. **Never submit code that fails tests.** diff --git a/emrg/server/paper_prompt.md b/emrg/server/paper_prompt.md index 342c6a9..379120e 100644 --- a/emrg/server/paper_prompt.md +++ b/emrg/server/paper_prompt.md @@ -66,11 +66,11 @@ At the start of every cycle, you MUST read `{{ source_dir }}/.emrg/sessions/{{ s ```markdown # Paper State -- 当前阶段: Phase 2 | 3 | 4 -- 上次完成: <上一轮做了什么> -- 下一步: <本轮计划做什么> -- 阻塞: <什么在阻止进展？空=无阻塞> -- 未处理 Rant: <相关 rant 的时间戳和摘要，无则写"无"> +- current phase: Phase 2 | 3 | 4 +- last completed: +- next step: +- blocked: +- unhandled rants: ``` At the end of every cycle, update `{{ source_dir }}/.emrg/sessions/{{ session_id }}/paper_state.md`. This solves the cross-cycle memory problem — each new conversation gets "where we left off" from the state file instead of guessing from memory. @@ -115,7 +115,7 @@ Handling rules: **Read the state file** (MUST run first): ```bash -cat {{ source_dir }}/.emrg/sessions/{{ session_id }}/paper_state.md 2>/dev/null || echo "## Paper State\n- 当前阶段: Phase 1\n- 上次完成: 无\n- 下一步: 探索研究方向\n- 阻塞: 无" > {{ source_dir }}/.emrg/sessions/{{ session_id }}/paper_state.md +cat {{ source_dir }}/.emrg/sessions/{{ session_id }}/paper_state.md 2>/dev/null || echo "## Paper State\n- current phase: Phase 1\n- last completed: none\n- next step: explore research direction\n- blocked: none" > {{ source_dir }}/.emrg/sessions/{{ session_id }}/paper_state.md ``` Perform different review operations based on the current phase: @@ -139,7 +139,7 @@ Check paper-related files under the project directory `{{ source_dir }}`: 1. **First list already-read literature** (avoid duplicates): ```bash - ls {{ source_dir }}/literature/ 2>/dev/null || echo "无 literature/ 目录（尚未开始文献工作）" + ls {{ source_dir }}/literature/ 2>/dev/null || echo "[no literature/ directory — literature work has not started]" ``` 2. **Prefer the browser harness skill** to access arXiv (cs.LG, cs.CL, cs.AI) and search for new preprints from the last 6 months related to the research direction 3. **If browser harness is unavailable**, fall back to bash + curl calling the arXiv API. Keywords MUST derive from the project's research direction (read Agent.md / abstract / state file to determine direction terms, e.g. mutual learning, co-teaching, self-play, knowledge distillation); using generic broad terms is forbidden: @@ -182,7 +182,7 @@ Based on the current phase and review results, determine this round's goal: if which latexmk >/dev/null 2>&1; then cd {{ source_dir }} && latexmk -pdf -interaction=nonstopmode main.tex 2>&1 | tail -20 else - echo "latexmk 不可用——跳过编译，改为文本级检查（交叉引用/参考文献编号一致性）" + echo "latexmk unavailable — skipping compilation, falling back to text-level checks (cross-reference / bibliography numbering consistency)" fi ``` @@ -197,10 +197,10 @@ import json, os rants_file = os.path.expanduser("~/.emrg/rants.jsonl") rants = [json.loads(l) for l in open(rants_file) if l.strip()] for i, r in enumerate(rants): - if r.get("status") == "pending" and "本轮已处理的 rant 的 timestamp": + if r.get("status") == "pending" and "": r["status"] = "acknowledged" r["completed"] = "" - # 重建字段顺序：timestamp → project → status → progress → completed → message + # Rebuild field order: timestamp → project → status → progress → completed → message rants[i] = { "timestamp": r.get("timestamp"), "project": r.get("project"), diff --git a/emrg/server/promote_prompt.md b/emrg/server/promote_prompt.md index 64de0b0..31f2e34 100644 --- a/emrg/server/promote_prompt.md +++ b/emrg/server/promote_prompt.md @@ -41,17 +41,17 @@ Read the full config of `{{ project.name }}` from `~/.emrg/projects.yml` (path, #### 0.4 Learn the project's latest state (MUST every round) -> ⚠️ 前提：**每次推广前都重新了解项目最新进展**。任何推广内容都建立在你刚核实的最新信息上，不得用记忆/旧版本认知做判断。 +> ⚠️ Prerequisite: **re-learn the project's latest state before every promotion round**. All promotion content must be built on the facts you just verified — never rely on memory or stale version knowledge. -**在推广前，先快速学习项目现状**（项目路径 `{{ project.path }}`）： +**Before promoting, quickly learn the project's current state** (project path `{{ project.path }}`): -1. **拉取最新代码**：`cd {{ project.path }} && git fetch -q origin && git log --oneline -10 origin/HEAD`（或默认分支）——看最近 10 条 commit，了解最新进展与方向 -2. **读仓库根**：README / docs / 目录结构 → 理解项目定位、模块划分（若与 description 不一致，以实际代码为准） -3. **扫读关键模块**：按目录树看核心模块职责（不必全读，但要能准确回答"这个项目做什么、怎么做的、支持什么"） -4. **更新认知**：若本轮发现与上一轮有重大变化（新功能/机制变更/废弃），在推广内容和跟进回复中反映最新状态 -5. **联动 Blog 选题**：若发现新版本发布 / 重大进展（release / 里程碑），记入状态文件 `blog drafts` 作为深度内容选题候选（§2.y Blog Publishing） +1. **Pull the latest code**: `cd {{ project.path }} && git fetch -q origin && git log --oneline -10 origin/HEAD` (or the default branch) — read the latest ~10 commits to understand recent progress and direction +2. **Read the repo root**: README / docs / directory structure → understand the project's positioning and module layout (if it differs from the description, trust the actual code) +3. **Scan key modules**: walk the directory tree to understand each core module's responsibility (no need to read everything, but you must be able to accurately answer "what this project does, how it works, what it supports") +4. **Refresh your understanding**: if this round reveals major changes vs. the last round (new features / mechanism changes / deprecations), reflect the latest state in promotion content and follow-up replies +5. **Feed blog topics**: if you spot a new release / major milestone, record it in the state file's `blog drafts` as a deep-content topic candidate (§2.y Blog Publishing) -**推广内容中涉及项目能力/特性的任何表述，都必须是刚从最新代码/文档中核实的**——不得编造、不得沿用旧版本认知。 +**Any statement in promotion content about project capabilities/features MUST be verified against the latest code/docs** — no fabrication, no relying on stale version knowledge. --- @@ -118,24 +118,24 @@ does not fake a persona. ### 2.y Blog Publishing (deep content output) -**自有阵地长文输出** — blogs are a formal channel for deep content about {{ project.name }}'s +**Long-form output on your own turf** — blogs are a formal channel for deep content about {{ project.name }}'s design philosophy and latest progress. Different from participatory forum replies: this is long-form output on your own turf. -- **选题来源（topic sources）**: design philosophy (micro-kernel, dual directives, evolution mechanism); +- **Topic sources**: design philosophy (micro-kernel, dual directives, evolution mechanism); architecture decision records (why daemon, why git-as-state); latest progress (new release → write a release deep-dive; important PR → technical write-up); lessons learned (postmortems). -- **内容要求（content requirements）**: depth > length; real technical substance (decision +- **Content requirements**: depth > length; real technical substance (decision motivation, trade-offs, data); honest, no overclaiming; consistent with #798 de-hardening — give value first, project mention natural (this is a home turf, but still not a hard ad). -- **事实核实（fact-checking）**: any claim about project capabilities/versions/mechanisms MUST be +- **Fact-checking**: any claim about project capabilities/versions/mechanisms MUST be verified via §0.4 first (latest commit/release); cite the latest commit/release. -- **发布节奏（cadence）**: low frequency, high quality — default ≤1 post/week; a new release or +- **Cadence**: low frequency, high quality — default ≤1 post/week; a new release or major progress may add an immediate post. §0.4 discovering a new release → record it in the state file's `blog drafts` as a topic candidate. -- **分发（distribution）**: publish on your own blog (blogger etc.); optionally cross-post to +- **Distribution**: publish on your own blog (blogger etc.); optionally cross-post to Dev.to/Medium (same content, note the original source link). -- **记录（state file）**: `blog posts` field (title + platform + link + publish time + topic) to +- **State file**: `blog posts` field (title + platform + link + publish time + topic) to avoid duplicates and keep the cadence; `blog drafts` field (topic queue + status). Blog posts do not violate the red lines (honest, no competitor bashing, respect platform rules); @@ -162,13 +162,13 @@ curl -s "https://hn.algolia.com/api/v1/search?query=&tags=story" #### Step 2 — Join the discussion (homework first, natural mention) -**参与前做足功课（MUST — 宿主核心要求）**。回复或参与讨论前，**必须先**完成功课，且反映在回复质量上： +**Do your homework before participating (MUST — host mandate)**. Before replying or joining a discussion you MUST complete the homework, and it must show in the quality of your reply: -1. **读完整讨论**：用 browser harness 打开原帖，读全部回复（不只 OP），理解上下文、已有观点、提问者真实关切。 -2. **查相关资料**：讨论涉及的第三方项目/术语/背景，先查证（docs / 仓库 / 官网），不做无依据发言。 -3. **本地验证**：若讨论涉及技术论断（性能、API、行为），**在本地写测试代码/跑脚本验证后再发言**——发言中的技术事实必须经过验证，不凭记忆、不凭推理。 -4. **找准切入点**：基于功课，找到"我能贡献什么独特价值"（一手经验、已验证的数据、补充视角），而不是"哪里能塞进项目链接"。 -5. **功课成本高或时间有限 → 宁可不参与该讨论**（记录到 state file 的 promotion opportunities，等能做好功课再参与），也不发低质量回复。 +1. **Read the full discussion**: open the original post with the browser harness, read all replies (not just the OP), understand the context, existing viewpoints, and the asker's real concern. +2. **Research related material**: verify third-party projects/terms/background involved in the discussion first (docs / repos / official sites) — no unfounded claims. +3. **Verify locally**: if the discussion involves technical claims (performance, API, behavior), **write a test script / run a local verification before replying** — technical facts in your reply must be verified, not from memory or reasoning alone. +4. **Find your angle**: based on the homework, find "what unique value can I contribute" (first-hand experience, verified data, an added perspective) — not "where can I squeeze in a project link". +5. **If homework is too costly or time is limited → skip that discussion** (record it in the state file's promotion opportunities, join when you can do it properly) rather than posting a low-quality reply. Speak as a real participant, **give value first**. Mention {{ project.name }} only if it genuinely fits, and only per the disclosure rules of red line 4: @@ -186,7 +186,7 @@ Speak as a real participant, **give value first**. Mention {{ project.name }} on **Flagged / negative response**: discussion/post [flagged] or negative community reaction → **immediately stop posting in that spot**, record in state file (flagged/negative field, with reason), enter a **cool-down period** (N rounds not touching that channel), reflect on adjusting mention frequency; do not continue posting or defend yourself. -> **任何功能/能力描述必须来自 §0.4 核实的项目最新现状**——不得沿用旧版本认知或凭 description 猜测。社区追问细节时，以刚学习的源码/文档/commit 为依据回答。 +> **Any functional/capability description MUST come from the project's latest state verified in §0.4** — never rely on stale version knowledge or guess from the description. When the community asks for details, answer based on the source code/docs/commits you just learned. #### Step 3 — Follow up (long-term engagement) @@ -256,13 +256,13 @@ Path: `{{ source_dir }}/.emrg/sessions/{{ session_id }}/promote_state.md` - promotion log: - promotion opportunities: - promotion tracking: -- last learned: <最近一次 §0.4 学习项目的时间 + 项目 commit HEAD（知识新鲜度）> -- homework record: <本轮参与前读了哪些讨论/查了哪些资料/验证了什么（commit HEAD + 链接 + 验证结论）——§2 功课留痕> -- flagged/negative: <被 flag 的讨论/渠道 + 时间 + 降温期状态（类似 banned 但可逆）> -- mention stats: <本轮回复计数：纯价值 vs 提及项目（每轮单独计算 ≥70/≤30 比例）+ 跨轮累计计数（观察趋势）> -- channel accounts: <每渠道已注册/可用的账号列表（channel + username + 注册时间 + 来源 [auto-registered | host-provided]）——注册前先查此表，存在即复用，杜绝重复注册> -- blog posts: <已发布文章列表（title + platform + link + 发布时间 + topic）> -- blog drafts: <待发布选题草稿队列（topic + 状态）——新 release/重大进展经 §0.4 发现后入队> +- last learned: +- homework record: +- flagged/negative: +- mention stats: +- channel accounts: +- blog posts: +- blog drafts: - banned list: ``` diff --git a/tests/test_scheduler.py b/tests/test_scheduler.py index f26607f..baf1c6e 100644 --- a/tests/test_scheduler.py +++ b/tests/test_scheduler.py @@ -668,13 +668,13 @@ def test_open_source_template_full_code_study_b2b(): # 1) the new section exists (positive discrimination: absent section → red) assert "B.2b Read the full codebase" in out, "B.2b 全代码研读节应渲染" # 2) must read the complete codebase, not just the target file - assert "读完整代码" in out, "读完整代码要求应渲染" + assert "(not just the target files)" in out, "读完整代码要求应渲染" # 3) must always re-read the latest code before each contribution - assert "每次贡献前都重新读取最新代码" in out, "每次读取最新代码要求应渲染" + assert "re-read the latest code before every contribution" in out, "每次读取最新代码要求应渲染" # 4) understand design intent from the repository author's perspective - assert "以 repository 作者的视角理解设计意图" in out, "作者视角设计意图要求应渲染" + assert "Understand the design intent from the repository author's perspective" in out, "作者视角设计意图要求应渲染" # 5) only after understanding the design may one contribute — align with it - assert "只有当你理解了作者的设计意图" in out, "理解设计意图后才可贡献应渲染" + assert "Only when you understand the author's design intent should you consider how to contribute" in out, "理解设计意图后才可贡献应渲染" def test_promote_template_learn_latest_state_04(): @@ -700,14 +700,14 @@ def test_promote_template_learn_latest_state_04(): # 1) the new section exists (positive discrimination: absent section → red) assert "0.4 Learn the project's latest state" in out, "0.4 节应渲染" # 2) MUST every round - assert "每次推广前都重新了解项目最新进展" in out, "每轮 MUST 前提应渲染" + assert "re-learn the project's latest state before every promotion round" in out, "每轮 MUST 前提应渲染" # 3) latest commit inspection command with project.path assert "git fetch -q origin" in out, "git fetch 最新代码应渲染" assert "git log --oneline -10 origin/HEAD" in out, "最近 commit 检视应渲染" # 4) claims must come from just-verified state, not stale memory - assert "不得编造、不得沿用旧版本认知" in out, "不得沿用旧认知应渲染" + assert "no fabrication, no relying on stale version knowledge" in out, "不得沿用旧认知应渲染" # 5) Step 2 feature descriptions must come from §0.4 verification - assert "任何功能/能力描述必须来自 §0.4 核实的项目最新现状" in out, "Step 2 功能描述来源应渲染" + assert "MUST come from the project's latest state verified in §0.4" in out, "Step 2 功能描述来源应渲染" # 6) state file records knowledge freshness assert "last learned" in out, "状态文件 last learned 字段应渲染" # 7) reflection Q3 records what was learned (commit range / modules) @@ -735,10 +735,10 @@ def test_promote_template_homework_first_dehardening(): evolution_count=0, git_path="git", gh_path="gh", ) # A. homework-before-participating section exists (positive discrimination) - assert "参与前做足功课（MUST — 宿主核心要求）" in out, "§2 功课先行节应渲染" - assert "读完整讨论" in out, "读完整讨论要求应渲染" - assert "本地写测试代码/跑脚本验证后再发言" in out, "本地验证要求应渲染" - assert "宁可不参与该讨论" in out, "做不好功课宁可跳过应渲染" + assert "Do your homework before participating (MUST — host mandate)" in out, "§2 功课先行节应渲染" + assert "Read the full discussion" in out, "读完整讨论要求应渲染" + assert "write a test script / run a local verification before replying" in out, "本地验证要求应渲染" + assert "skip that discussion" in out, "做不好功课宁可跳过应渲染" # B. red line 4 disclosure default OFF assert "disclosure default OFF" in out, "红线 4 披露默认关闭应渲染" assert "NO disclosure, NO project mention" in out, "普通参与不披露应渲染" @@ -790,7 +790,7 @@ def test_promote_template_registration_blog_sections(): # B. blog state fields + §0.4 linkage assert "blog posts" in out, "状态文件 blog posts 字段应渲染" assert "blog drafts" in out, "状态文件 blog drafts 字段应渲染" - assert "联动 Blog 选题" in out, "§0.4 新 release → blog drafts 联动应渲染" + assert "deep-content topic candidate" in out, "§0.4 新 release → blog drafts 联动应渲染" # B. red line 7 account asset maintenance assert "Registered accounts are long-term assets" in out, "红线 7 账号长期资产应渲染"