/run-memory

name: run-memory
description: >-
  Shared step of the marketing playbooks (analyze-performance, run-paid-campaigns,
  research-competitors, email-lifecycle): reads the last run's record, checks whether its
  recommendations were done and whether they worked, and saves a short record of this run for the next
  one. Loaded by those playbooks; not for direct use.
version: 0.1.1

run-memory

A playbook that runs again (often as a weekly or monthly automation) must know what its last run found, what it recommended and whether that worked. This atom is that memory. The **report** is separate (the `write-report` skill, `../write-report/SKILL.md`); a run record is the short, structured note the next run reads.

**Who loads it:** every playbook that can run more than once for the same brand: research, analysis, ads, social, email, search, creators. Not one-off makers (a single post, one photo set). It runs twice per run: **Start** before the playbook's own work, **End** after its report.

**What it does not replace.** Where a playbook already keeps a working log, that log stays the source of truth: run-paid-campaigns' `ads/campaigns/<slug>/state.md` + `decisions.md` (the server's campaign-harness grammar, `R<n>` ids, `## Checks due`), the `outcomes-ledger` skill's ledgers, analyze-performance's `definitions.md`. The run record copies their ids and adds only what they lack (the baseline recipe and the result numbers). It never keeps a second, different copy of their state, and when the playbook has its own scoring rule (run-paid-campaigns' "Score last week"), step 3 below *is* that step. Use its rule and add only what is missing.

Inputs (the calling playbook supplies them)

| Input | Rule | |---|---| | `playbook` | The playbook slug (`analyze-performance`). Goes in the tags. | | `job` | The job in plain words (`weekly ads check`, `monthly read`, `competitor watch`). Never a slug, tool or id. One playbook with several cadences has one `job` per cadence. Keep it the same on every run, because the next run searches by it. `job-slug` is `job` lower-cased and hyphenated. | | `subject` | Optional. Only when a job keeps separate runs per campaign, rival or list (`spring-launch`). Lower-case slug. | | `cadence` | `daily`, `weekly`, `monthly`, `quarterly`, or `ad hoc`. Used to judge whether the last record is old. | | `outcome_sources` | Where this playbook can see whether a recommendation happened and what it did. Examples: `meta_read` change or push status, its own log file, `social_post_list`, `campaign_read`, a ledger. |

Brand inputs (`brand_id`, `brand_slug`, `coworker_agent_id`, scope) come from the `marketing-guide` skill (`../marketing-guide/SKILL.md`) §1–2.

**File:** `runs/<playbook>/<job-slug>/[<subject>/]<YYYY-MM-DD>.md`. A second run on the same day is `<YYYY-MM-DD>-2.md`. **Title:** `Run record — <job>[ — <subject>] — <Brand> — <YYYY-MM-DD>`, with ` (2)` added for a second run that day (save-to-brain's never-overwrite rule, its step 1). The subject sits in the title because brain search cannot filter by tag. **Local mode** (the `marketing-guide` skill (`../marketing-guide/SKILL.md`) §5) calls no `gooseworks:` tool and no brain or knowledge search:

• **Step 1:** with the host's file tools, list `gooseworks-local/<brand-slug>/runs/<playbook>/<job-slug>/[<subject>/]` and read the newest record whole. Empty → no earlier run (step 1's rule).
• **Step 2:** the sources are the local files (the playbook's own log and reports in that folder), the marketer's connectors (read-only), their exports and their words.
• **Step 7:** the record through save-to-brain's local branch; rules learned through save-learning (it writes `brand-notes.md`); no readout fact (it stays in the record). The line says "Saved this run's notes in this folder", never "to your brand".
• **Hosted chat without files:** ask once for last time's notes ("paste last time's notes if you kept them"); none → no earlier run. At the end, give the record in chat to paste back next time.

Start of run

1. Find the last record

Look in the workspace first, because it is the canonical copy and the exact check. Use the brain search to catch a record saved somewhere else.

• **Workspace.** Call `gooseworks:file_list` on `runs/<playbook>/<job-slug>/` (or the subject folder) in the brand's scope. If the coworker scope has no record, also list `brands/<brand_slug>/runs/…` in the default workspace. Records saved before the brand had a coworker live there.
• **Brain.** If `brain_*` tools are listed, call `gooseworks:brain_search` with query `Run record <job> <Brand>`, `source_types: ["document"]`, `since` = today minus 180 days, and `limit: 5`. Otherwise call `gooseworks:knowledge_search` with the same query and `source_types`. Keep only hits whose title matches this job's title up to the date, subject included. An empty search proves nothing: the brain may still be indexing ("Still indexing: 65 of 204…"), or the import may not have finished.

The newest dated record wins. **Read the whole record:** use `gooseworks:file_read` on the workspace file, or, if the brain is the only place it exists, `gooseworks:brain_open` on the document hit, following its continuations. **Without `brain_*` tools** (production today) a hit that exists only in the brain can't be opened in full: say "I found an earlier record I can't open here", treat this as a run with no readable record, and continue. Never work from a search snippet.

**The baseline is the newest record that has Numbers.** A `Not run` record (see Scheduled runs) only adds gaps and carried items. Keep reading back until you find one with Numbers.

**No record → no earlier run of this job.** Say so. Do not invent a "since last time". Still do step 2 with `since` = today minus 90 days. Server reports and the playbook's own log may hold history from before this job existed; if they do, say what they show and that it was not this job's own check. Every number this run records becomes the ba