Back to Details

re0-memo

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Turn a completed cycle into lessons the next cycle can actually use.
将已完成的工作周期转化为下一周期可实际复用的经验教训。

Goal

目标

re0-memo
extracts durable learning from a work cycle without defending the artifact that produced it. A cycle can run, pass tests, and still be the wrong thing. The output is not a changelog or therapy note: it is a local, evidence-backed record of what worked, what misled the build, and what gate the next pass must clear.
Use 
re0-memo
when the artifact is done, failed, disappointing, or ambiguous enough that the next agent needs the cycle's lessons more than its momentum.
re0-memo
从工作周期中提取可长期复用的经验，无需为产出的工件辩护。一个周期可能顺利运行、通过测试，但最终结果仍可能不符合预期。产出不是变更日志或情绪记录：而是一份基于证据的本地记录，包含有效的实践、误导构建的因素，以及下一阶段必须通过的质量门。
当工件已完成、失败、不尽人意或存在歧义，且下一阶段执行者更需要该周期的经验而非现有进展时，可使用 
re0-memo
。

Workflow

工作流程

  1. Read the original objective, final artifact, QA evidence, user complaints, and any local planning notes.
  2. Separate working assets from misleading progress: contracts, schemas, tests, services, vocabulary, and examples that earned reuse vs. UI, panels, scaffolds, or abstractions that only looked productive.
  3. Generalize before recording: when feedback arrives as many specific complaints, cluster them upward into the shared pattern before writing anything down — many specifics against many items usually share one root gap. Record the root and its pattern family as the lesson; keep the specifics under it as evidence, not as lessons themselves.
  4. Name each failure as an anti-pattern, not a mood.
  5. Convert repeated or high-impact failures into quality gates for the next pass.
  6. Convert vague user direction into architecture vocabulary a fresh agent can use.
  7. Write or refresh local docs for the cycle: a re0-memo for lessons and a plan for next-cycle contracts, gates, and vocabulary.
  8. Verify that a from-scratch agent could avoid the same failure from those docs alone.
  1. 阅读原始目标、最终工件、QA测试证据、用户反馈以及所有本地规划文档。
  2. 区分有效资产与误导性进展：保留值得复用的契约、schema、测试、服务、规范术语和示例；摒弃看似有效实则无用的UI、面板、脚手架或抽象层。
  3. 先归纳再记录：当收到大量具体反馈时，先将其归类为共同模式再记录——针对不同事项的诸多具体问题通常源于同一个核心缺陷。将核心问题及其所属模式记录为经验教训，具体问题作为证据附在下方，而非作为经验教训本身。
  4. 将每个失败定义为反模式，而非情绪化描述。
  5. 将重复发生或影响重大的失败转化为下一阶段的质量门。
  6. 将模糊的用户需求转化为新执行者可使用的架构规范术语。
  7. 编写或更新该周期的本地文档：一份记录经验教训的re0-memo，以及一份关于下一阶段契约、质量门和规范术语的计划。
  8. 验证从零开始的执行者仅通过这些文档就能避免相同的失败。

Rules

规则

  • Do not defend the artifact. If it missed the product, say what missed.
  • Do not write a changelog. File lists and effort summaries are not lessons.
  • Do not transcribe a specific complaint as a lesson. A lesson that only fixes the reported case keeps the system human-in-the-loop: the same class of failure returns anywhere a person didn't point. Escalate every specific to the pattern that catches its whole class — the reporter's exact words are evidence, not the gate.
  • Preserve negative corpus. Failed paths are training data.
  • Prefer hard gates over advice.
  • Cite evidence from the cycle: objective, file facts, QA output, screenshots, transcripts, diffs, or user feedback.
  • If the next agent cannot act on it, it is not a lesson yet.
  • Keep provenance local; shipped artifacts should not narrate their scars.
  • 不为工件辩护。若未达到产品要求，明确说明问题所在。
  • 不编写变更日志。文件列表和工作汇总不属于经验教训。
  • 不将具体反馈直接转录为经验教训。仅针对单个案例的教训会让系统依赖人工干预：同一类失败会在未被人工指出的地方再次发生。将每个具体问题升级为能覆盖整个类别问题的模式——反馈者的原话是证据，而非质量门。
  • 保留负面案例集。失败路径是训练数据。
  • 优先采用硬性质量门而非建议。
  • 引用周期中的证据：目标、文件事实、QA输出、截图、对话记录、代码差异或用户反馈。
  • 若下一阶段执行者无法据此采取行动，则不能称之为经验教训。
  • 保留本地来源；已交付的工件无需记录其缺陷。

Verification

验证

Before finishing:
  1. Every lesson traces to observed cycle evidence.
  2. Every anti-pattern names a concrete failure mode and the gate that catches it.
  3. No lesson is a single reported case in disguise: each covers a class, with the specifics that raised it sitting under it as evidence.
  4. A fresh agent can tell what to preserve, what to discard, and what to test first without reading the whole old session.
完成前需确认：
  1. 每条经验教训都能追溯到周期中观察到的证据。
  2. 每个反模式都明确了具体的失败模式以及对应的质量门。
  3. 没有任何一条经验教训是单个案例的伪装：每条教训都覆盖一个类别，引发问题的具体案例作为证据附在下方。
  4. 新执行者无需阅读整个旧周期的内容，就能明确需要保留、丢弃的内容以及优先测试的事项。