run-memory 是营销 playbook 的共享步骤。它的作用是为同一品牌反复运行的营销流程（如每周、每月自动化）提供记忆：上一次运行发现了什么、推荐了什么、这些推荐是否奏效。它本身不写报告（报告由 write-report 技能负责），而是维护一份简短、结构化的“运行记录”，供下一次运行读取。
用途与加载范围 凡是可能对同一品牌多次运行的 playbook 都会加载它，包括调研、分析、广告、社交、邮件、搜索、创作者等；一次性产出（单条帖子、单组照片）不加载。每次运行会调用两次：playbook 自身工作开始前一次，报告完成后一次。
它能替代什么、不能替代什么 如果 playbook 已有工作日志，该日志仍是事实来源，例如 run-paid-campaigns 的 ads/campaigns/<slug>/state.md 与 decisions.md（服务的 campaign-harness 语法、R<n> 编号、## Checks due）、outcomes-ledger 技能的账本、analyze-performance 的 definitions.md。运行记录只复制它们的编号，并补上它们缺少的内容（基线配方和结果数字），不会另存一份不同的状态。
输入（由调用方提供）
- playbook：playbook 标识，写入标签。
- job：用人话描述的任务（如 weekly ads check、monthly read、competitor watch），不用标识、工具或 id；同一 playbook 有多个节奏时每个节奏一个 job，且每次运行保持一致，因为下一次运行靠它检索。job-slug 为 job 小写并用连字符连接。
- subject：可选，仅当某个 job 按活动、竞品或列表分别运行时使用，小写标识。
- cadence：daily、weekly、monthly、quarterly 或 ad hoc，用于判断上次记录是否过旧。
- outcome_sources：该 playbook 能看到建议是否执行及效果来源的地方，例如 meta_read 的变更或推送状态、自身日志、social_post_list、campaign_read、账本。 品牌输入（brand_id、brand_slug、coworker_agent_id、scope）来自 marketing-guide 技能第 1–2 节。
记录文件与标题 文件路径为 runs/<playbook>/<job-slug>/[<subject>/]<YYYY-MM-DD>.md，同一天第二次运行为 <YYYY-MM-DD>-2.md。标题为 Run record — <job>[ — <subject>] — <Brand> — <YYYY-MM-DD>，同一天第二次运行加 (2)。subject 放在标题中，因为 brain 搜索无法按标签过滤。
本地模式 本地模式（marketing-guide 技能第 5 节）不调用 gooseworks 工具，也不做 brain 或知识搜索：用宿主文件工具列出并读取最新记录；数据来源为本地文件、营销人员只读连接器、导出数据和其本人口述；记录通过 save-to-brain 的本地分支保存，学到的规则通过 save-learning 保存；提示语为“已把本次运行的笔记保存到这个文件夹”，不说“保存到你的品牌”。无文件的托管聊天中，询问一次上次的笔记，没有就视为无更早运行，最后把记录发到聊天中供下次粘贴。
运行开始时 步骤1：找上一次记录。先查工作区（规范副本），用 gooseworks:file_list 列出对应目录；如 coworker 范围内没有，再列默认工作区中 brands/<brand_slug>/runs/… 。若有 Brand Brain 工具（brand_knowledge_*），用 gooseworks:brand_knowledge_search 检索标题匹配、近 180 天内的文档；否则用 gooseworks:knowledge_search。空搜索结果不能证明没有记录（可能仍在索引或导入未完成）。以最新日期的记录为准，完整读取，不依据搜索片段。没有记录则说明没有更早运行，不臆造“自上次以来”，仍以 90 天前为 since 执行步骤2；旧记录指超过节奏 3 倍或 ad hoc 超过 90 天，需说明可能变化较大。
步骤2：读取自上次以来的情况，只读该 playbook 需要的、且免费的内容：各未结建议的 outcome_sources、playbook 自身日志、brain 中相关报告、创意、广告、学习内容。
步骤3：检查此前每条建议。状态分为 done（有来源显示已执行）、not done（有来源显示未执行或本人表示未执行）、unknown（无任何证据，需说明如何确认，计划运行中列入报告“Decisions for you”并记录询问日期）、dropped（本人放弃或被更新建议取代）、open（未到复核日期，原样顺延）。对已执行且过复核期的建议，按原“如何判断”测试和基线配方重跑两个窗口，结论为 worked/didn't work（给出前后数字、窗口和 truth/claimed 标签）、too early（给出可读日期）或 can't tell（说明原因）。付费动作有专门配方：后窗口从变更应用次日起，预算变动≥30% 跳过前 3 天，结束于今天前 72 小时；前窗口等长，结束于变更应用前一天；两个窗口使用相同归因设置；预算增加看每天增量结果及其相对允许成本，不看平均 CPA；每窗口结果低于约 30 个，或窗口内存在其他已记录变更，判 can't tell 或 too early 并给日期。数字除接入品牌自有店铺或 CRM 数据（truth）外均标为 claimed。
步骤4：写“自上次以来”3–5 行，用平实语言供营销人员阅读，作为聊天回答开头，报告中置于“The story”顶部。
步骤5：把结果用于本次运行：不重复无效动作（除非有实质变化并说明），未结建议沿用原 id 顺延，被拒绝的建议仅在出现新证据时重提并说明曾被拒绝，连续两次运行过复核期仍无证据则询问一次保留或放弃。
运行结束时 步骤6：写运行记录，正文少于 400 词，含表格全文少于 1,500 词，固定章节依次为 Checked、Numbers、Decisions、Recommendations、Outcomes of the previous run's recommendations，空章节写 none。编号规则：已有稳定来源 id（R<n>、change_id、push_id）就用它，否则铸造 <YYYYMMDD>-<n>；顺延建议保留首个 id，不给同一事项两个 id。Owner 为营销人员、agent、审批页或其他执行 playbook。“How we'll know”需写明指标、阈值和基线配方（对象、指标、窗口长度、归因或数据设置，广告还需广告 id 及 GooseWorks 制作占比）。广告 playbook 另加按广告记分卡（花费前 10 广告加 all others 行，列含 ad、spend、results、cost per result 或 ROAS、CTR、days live、verdict、变化）和资金动作表（id+R<n>+change_id/push_id、from→to、应用日期、基线配方、结论）。记录中禁止出现个人数据，只用计数和非个人群组 id。
步骤7：保存记录。通过 save-to-brain 保存，路径为上述文件，artifact 为 Run record — <job>[ — <subject>]，tags 为 [<playbook>, run-record]（可加 subject:<slug>），versioned: keep-history，import: yes；旧记录永不删除。学到的规则仅以本人原话通过 save-learning 保存；自行发现的规律留在记录和报告中作为发现。在有 brand_knowledge_* 工具时，实测结论可按 save-learning 的事实路径保存为仅数字事实（kind 23，field experiment_readout.<id>），仅限带有 worked/didn't work 及 truth/claimed 标签的结论，且不得来自计划运行，并告知营销人员这是“按发现保存，非确认”。最后用一句话告知已保存；计划运行中除非保存失败不输出此行。
计划运行（无人在场） 仍需读取上次记录并写新记录；只做免费读取，除非自动化许可中已命名每次运行的常设上限（spend-gate 技能）。