288 changed files with 1705 additions and 39039 deletions
--- a/.claude-plugin/plugin.json
+++ b/.claude-plugin/plugin.json
@ -1,6 +1,6 @@
 {
  "name": "linkedin-studio",
-  "version": "0.7.0",
+  "version": "0.4.0",
  "description": "LinkedIn Studio — full-spectrum LinkedIn content engine: feed posts, carousels, video scripts, and long-form newsletter editions, with the 2026 relevance-ranking model baked in. v4.0.0 is an audit-remediation release (Voyage Phase 0–3): every user-facing claim is made honest or removed, all 11 previously-orphaned agents are wired (→ 19 agents), a `/linkedin:firsthour` post-publish command is added (→ 27 commands), the algorithm-signal claims are reconciled to one sourced statement (no unpublishable model name or date), short-form de-AI and video quality gates are added, and the structure lint is rebuilt to guard the real layout plus version/count/stat consistency. Breaking: the newly-wired agents register only on reinstall/reload, and this consolidates the v3.0.0 identity break (slug, agent namespace `linkedin-studio:<agent>`, state-file path `~/.claude/linkedin-studio.local.md`). v3.1.0 added the cold adversarial review package (`/linkedin:headless-review` + Step 6.5 + `/linkedin:pivot` + per-artifact personas); the `/linkedin:*` commands are unchanged. v4.1.0 adds a journey layer: two guided front-doors (`/linkedin:create`, `/linkedin:measure`) plus a router re-tiered into five journeys (Start · Create · Engage · Measure · Grow), with the 27 existing commands kept as the execution tier (→ 29 commands; additive, reload registers the two new commands).",
  "author": {
    "name": "Kjell Tore Guttormsen"
--- a/.gitignore
+++ b/.gitignore
@ -41,6 +41,7 @@ assets/drafts/week-*/
 assets/analytics/exports/
 assets/analytics/posts/
 assets/analytics/weekly-reports/
 assets/analytics/content-history.md
 # Internal development files (not for public release)
 BACKLOG.md
@ -56,28 +57,3 @@ docs/**/.session-state.local.json
 # Node.js
 scripts/analytics/node_modules/
 scripts/analytics/build/
 scripts/brain/node_modules/
 scripts/brain/build/
 scripts/contract-gate/node_modules/
 scripts/contract-gate/build/
 scripts/editions/node_modules/
 scripts/editions/build/
 scripts/specifics-bank/node_modules/
 scripts/specifics-bank/build/
 scripts/trends/node_modules/
 scripts/trends/build/
 # --- session/local state ---
 # STATE.md is LOCAL-ONLY (gitignored): no private remote exists and STATE must
 # never reach the public open/ mirror. Deliberate deviation from the global
 # "STATE tracked" rule, justified by the absence of any private remote.
 STATE.md
 REMEMBER.md
 ROADMAP.md
 TODO.md
 NEXT-SESSION-PROMPT*.local.md
 *.local.md
 *.local.json
 *.local.sh
 .DS_Store
 .claude/
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -5,175 +5,6 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 ## [Unreleased]
 ### Added — demand-sweep «innenfra og ut» (N7.5 / MR-F9)
 - **`demand-spotter` agent** — the demand-side twin of `trend-spotter`. Discovery finds *what happened*; the sweep translates it into *the reader's problem* via three passes after discovery, before drafting: demand-sweep (verbatim questions from where readers ask) → pain-point map → vocabulary translation (the reader's words, not the field's jargon). Inherits the session model; agents 19 → 20.
 - **Tier 5 demand sources** — a new tier in the source-list convention (`config/trends-sources.template.md`): practitioner forums, GitHub issues on spec repos, procurement data, regulator guidance, channel comments — the inverse of the Tier 1–4 supply sources. Known blind spots stated honestly (YouTube JS-rendered → API; Reddit approximate; HN/GitHub = ground truth; an honest null is a finding).
 - **`demand` signal on the trend record** — the rankable twin of the verbatim `saturation` text: `strength` (etterspørsel: strong/moderate/thin) + `answered` (is it already answered). Additive-optional; store schema stays v4 (no migration). Absent ⇒ unmeasured (the honest null the sweep may return instead of inventing demand).
 - **Arc (åre) output contract §4** — `scripts/trends/src/arc.ts`: groups demand-swept records into veins (relatedIds transitive closure), ranks each vein's questions on `etterspørsel × kan-svare × ikke-besvart`, and classifies an honest **market verdict** distinguishing a **supply-gap** (many ask, none answer — write here) from a **demand-gap** (few ask, but the sender can answer — high value, low audience) from **saturated** (skip). Pure + deterministic.
 - **`arcs` CLI verb + `/linkedin:trends --demand` mode** — render the §4 arc map (`node --import tsx src/cli.ts arcs`), reachable via the command's new demand mode (delegates to `demand-spotter`, keeps commands at 30). The morning brief also shows the per-candidate demand signal alongside the existing reader fields.
 - Trends suite 276 → 300; test-runner 139 → 140; `tsc --noEmit` clean.
 ### Added — voice chain: bind voice BEFORE prose (N8 / C-1, C-2, C-3, A2-F1, A2-F2)
 - **`chronicle-voice-profile` artifact (C-1/A2-F1)** — `voice-trainer` now distils a dedicated long-form voice profile (`${DATA}/profile/chronicle-voice-profile.md`) from the **published gold corpus only** (`ingest/published/`, `provenance=published`), one section per `(language, format)` pair present in the corpus — never from the English short-form `authentic-voice-samples.md` the engine itself calls degrading for chronicle voice, never from `provenance=ai-draft`. `/linkedin:newsletter` binds long-form drafting (Step 0 / 3a / 3b) to THAT profile as the primary reference, with an **explicit, never-silent fallback** to the short-form corpus when it is absent.
 - **Drift log is READ, not just written (C-2)** — Step 3a gains a **Pass 0**: read `chronicle-voice-drift-log.md` as a *negative list* of the recurring AI-tells/drifts `voice-scrubber` logged on prior editions, so drafting avoids them BEFORE the scrub (the log was append-only, never consumed); Step 3b re-reads it during expansion.
 - **Review language resolved + persisted at Step 1 (C-3)** — the calibration now **resolves the review `language`** (detect/ask) and persists the top-level `edition-state.language` at the Step 1.5 checkpoint, making the template's "Resolved at Step 1" doc-string true. Previously the default `"en"` was never set, so `language-reviewer`'s Norwegian checks and `voice-scrubber`'s gold standard silently never fired even for a Norwegian edition; Step 6.5 already consumed the field, so resolving it closes the axis end-to-end.
 - **Auto-gull — the gold corpus grows on its own (A2-F2)** — Step 8 lock now appends the locked edition to `ingest/published/` tagged `provenance=published`, so the corpus the chronicle profile is distilled from grows one edition at a time (the author's own locked editions, never the engine's drafts). No manual curation.
 - Domain-general throughout: languages/formats come from the user's own corpus, never hardcoded. test-runner 140 → 146 (Section 16o: 6 unconditional voice-chain greps + self-test; anti-erosion floor 123 → 129).
 ### Added — randsone gates: gate the feed-facing surfaces (N9 / C-4, C-6, C-7, C-9)
 - **Randsone fact + language gate (C-4/C-9)** — `/linkedin:newsletter` Step 9 (post-lock) now runs a **scoped** `fact-reviewer` (F1 verifiable claims + F3 number attribution) + `language-reviewer` (L1 repetition + L2 anglicisms/register) pass over the four feed-facing surfaces the reader actually meets — the **delingstekst hook**, the **samle post**, the **carousel slide text**, and the **edition title** — before the hook-conversion binary. Until now only the hook's click-worth was judged; its truth and language, the samle post, the carousel slides and the title reached the feed ungated. Placed at Step 9 because that is the first phase where all four surfaces exist (carousel is authored in Step 7.5; delingstekst/samle from Step 8), and Step 9 already operates on post-lock distribution copy — so the gate revises distribution surfaces + re-renders, never the locked body; a defect tracing into the locked body/canonical title is a pivot.
 - **Edition title-strength gate (C-9)** — the edition's own title now faces a strength gate at Step 9 (binding on the distribution title, advisory on the locked canonical title), not only the hook's two lines.
 - **Deterministic post-factcheck fact-recheck (C-6)** — a new invariant after Step 5: any later fold-in (5.5/6/6.5/7) whose diff touches a sentence with **numbers, names, or quotes** fires a mandatory **scoped `fact-reviewer`** mini-recheck of exactly those sentences — a deterministic trigger, **not a judgment call**, replacing the old "re-run if it felt substantive" discretion and closing the pivot-heuristic blind spot (a swapped statistic under the +20 % threshold never trips `/linkedin:pivot`, but does trip this).
 - **WebFetch on both fact agents (C-7)** — `fact-checker` and `fact-reviewer` gain `WebFetch`: quote precision (F2) and exact-figure attribution (F3) require the verbatim source text in context, not a search snippet.
 - test-runner 146 → 154 (Section 16p: 8 unconditional randsone-gate greps + self-test; anti-erosion floor 129 → 137). Domain-general; no KTG-specific values hardcoded.
 ### Added — series-level protection: make the retread visible before prose (N11 / C-5)
 - **`scripts/editions/` — series distillate (new package)** — each locked edition leaves behind the narrative units it spent (anecdotes told, arguments argued, hooks used) in `<serie>/linkedin/series-distillate.json`, beside `edition-state.json` in the **series root** — series-scoped state where the series' other state already lives, so it travels with the series and needs no slug→path map. `distil-append` (Step 8 lock) folds an edition in; a re-lock after `/linkedin:pivot` **replaces** its entry rather than duplicating it.
 - **Step 2.5 destillat-sjekk — the check runs BEFORE prose** — the skeleton gate now compares the proposed skeleton against everything the series has published and folds any finding into the annotation page the operator already reads, while changing course is still cheap. **Advisory, never blocking** (exit 0 either way): a deliberate callback is a legitimate move — an *unnoticed* retread is not. Until now every one of the long-form gate agents saw exactly one edition, so "the reader has heard this before" was structurally invisible; at series cadence it is the fastest-growing defect class.
 - **Deterministic comparison, AI extraction** — the units are distilled from locked prose by the command layer, but the store, the similarity and the verdict are plain code: **character-trigram Jaccard**, chosen because the plugin is language-general and inflection (*migrere* / *migreringen*) breaks word-token overlap. Calibrated against real paraphrase pairs — retellings 0.44–0.55, unrelated 0.04–0.06, same-topic-different-story 0.24 — so the default threshold sits in the gap at **0.40** (word-Jaccard scored a shortened hook paraphrase at 0.11 and would have let it through). Units are compared within their kind; an argument re-used as a hook is a new move.
 - **Specifics-bank usage log (`usedIn`)** — the material grain of the same defect: `recordUsage` + the `record-usage` CLI verb stamp «used in edition NN» on the specifics an edition actually consumed (read from the bound slot-map via `boundSpecificIds`, so `abstrakt`/`ekstern` slots stamp nothing). Recorded at **lock**, so it means published rather than merely considered, and idempotent under a pivot re-lock. The bank's dedupe deliberately *encourages* re-surfacing the same material; this log is what makes that re-use visible at the next Step 1.5 instead of silent. Additive-optional — schema stays v1, existing banks load unchanged.
 - Suites: new `editions` 27/0; specifics-bank 28 → 45; test-runner 163 → 173 (Section 16r: 9 unconditional greps + non-vacuity self-test; anti-erosion floor 146 → 155). `tsc --noEmit` clean in both packages. Domain-general throughout.
 ### Added — editions register + phase telemetry: make the production line measurable (N12 / A1-11, A1-12)
 - **Editions register (`scripts/editions`, new module)** — one row per edition in production in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/editions/register.json`: series, edition, title, series path, current phase, the one next action, and slot. `register-list` answers "what is in flight, and where does each edition stand?" without opening a single series folder — until now that answer required opening every `edition-state.json` by hand, which is why nobody had it. Data-dir placement (M0), because the register spans **all** series (the distillate is per-series and stays in the series root).
 - **`articles.NN.phaseLog` — lead time becomes a measured number** — every phase transition appends `{phase, completedAt}` to the edition-state. Additive-optional (default `[]`), so schemaVersion stays **1** and pre-N12 editions load unchanged; their absence reads as "not measured", never as zero. Per-article rather than top-level, mirroring `articles.NN.phase`: lead time is a property of an edition.
 - **One call per transition, both writes** — `/linkedin:newsletter` gains a **phase-transition protocol** defined once next to the resumption table, and each of the **16 canonical phases** invokes it: `register-upsert --edition-state <path>` appends the phase-log entry *and* mirrors the register row. Deliberately one command, not two: telemetry the command layer must remember to write separately is incomplete inside a week, and an incomplete log measures nothing. Step 10 closes the row (`register-complete`) and prints the measured lead time.
 - **The register is a MIRROR, never a source of truth** — deterministic resumption still reads `edition-state.json` and only that. Delete the register and the next transition rebuilds the row; a failed `register-upsert` is reported plainly and never stops the pipeline. `startedAt` is the one value that cannot be recovered, so it never moves: re-upserting a completed edition *reactivates* the same row (what `/linkedin:pivot` does), keeping the clock on real elapsed production time.
 - **Deterministic, no clock in the core** — every mutation takes `now` as an argument (`--at` / `--now` at the CLI edge), as the distillate takes `lockedAt`. Idempotent where a re-run is legitimate (a repeated transition logs once; completing twice keeps the first `completedAt`), *not* where it is real work (a phase recurring after another one is logged again — a pivot back through cleared gates is production time that happened). Missing facts are refused at the edge rather than defaulted: a row naming the wrong phase is worse than no row.
 - Suites: editions 27 → 72; test-runner 173 → 184 (Section 16s: 11 unconditional greps incl. a 16-phase coverage sweep + non-vacuity self-test; anti-erosion floor 155 → 166). `tsc --noEmit` clean. Domain-general throughout.
 ### Added — publishing slots + vacancy warning + WIP roll-up (N13 / A1-10, D-5)
 - **Publishing slots are operator config (`profile/publishing-slots.json`)** — a recurring weekly grid (`{day, time, label}`) in the per-user data dir, with a schema + **opt-in** template at `config/publishing-slots.template.json`. The plugin writes it for nobody and ships no publishing times: while the file is absent every slot surface stays silent, exactly like the trend and brain nudges. It lives in the data dir rather than the state file because the state file is machine-written (rollover, pruning, post tracking) and its frontmatter reader does not parse lists — user config does not belong in a file the plugin rewrites.
 - **Vacancy at session start** — the SessionStart hook now names the next publishing slot **nothing covers**, how many are open in the next 14 days, and — when the gap is ≤3 days — how to fill it. Coverage counts both the short-form queue (status `scheduled`/`published`; a cancelled entry frees the slot again) **and** editions-register rows whose slot claims that date, so long-form and short-form can never be booked on top of each other. A day carrying two slots needs two posts to be full.
 - **Work in progress is surfaced, not searched for** — `## Editions in Flight` at session start, plus the same roll-up in the `/linkedin` router and `/linkedin:calendar`: series, edition, current phase, the one next action, claimed slot, and days in flight. The N12 register made this measurable; N13 makes it *visible without asking*.
 - **`hooks/scripts/slots.mjs` — one implementation, four surfaces** — zero-dep (a SessionStart hook must not spawn tsx), pure core (dates in as strings, no clock), and imported by the commands the same way `queue-manager.mjs` already is. The hook's vacancy warning and the slot `/linkedin:newsletter` defaults to therefore cannot disagree.
 - **`/linkedin:newsletter` Step 10 defaults to the next open slot** — scheduling is one confirmation instead of an interview, and the transition now writes `--slot` onto the register row so a scheduled edition stops reading as an open slot. Unconfigured grid or a full horizon ⇒ the old ask, unchanged.
 - **D-5: the shipped schedule is marked for what it is** — `references/scheduling-strategy.md` now carries the same epistemic standard as the algorithm reference (**confidence: low / directional**, practitioner heuristic, no primary source) and defers to the operator's own grid, tested against their own analytics. The tables are a starting point, not a finding about anyone's audience.
 - Suites: hooks 140 → 174 (25 slot-core + 9 session-start tests); test-runner 184 → 197 (Section 16t: 13 unconditional greps incl. a de-niche check that no publishing time is hardcoded in the slot path and no operator grid is committed, + non-vacuity self-test; anti-erosion floor 166 → 179).
 ### Built feedback (awaiting consumer-side proof)
 - **MR-F9** (demand-sweep «innenfra og ut») — built; the (a)/(b)/(c) evidence gate is a runtime demonstration, proven consumer-side (plugin agents don't resolve in the dev repo).
 ## [0.7.0] - 2026-07-23
 **Trend engine → production bridge.** The discovery pass becomes a first-class command, gains a reader-side proposal + actionability layer, and is wired directly into the long-form pipeline: a trend now flows id-traceably from discovery to a scheduled edition, and a candidate with no formulable reader-grip can no longer inflate the top band.
 ### Added — trend discovery command (N5)
 - **`/linkedin:trends`** — trend-discovery pass: delegates to `trend-spotter` (default long-form mode), persists to the trend store + a dated morning brief, triages per candidate (act/skip). Commands 29 → 30. (`a8e3cac`)
 - **`trend-spotter` model-pin removed** — the agent now inherits the session model instead of being pinned to `sonnet`, so a discovery pass runs at the session's tier. (`a8e3cac`)
 ### Added — trend proposal + reader-side layer (N6)
 - **Proposal fields on the trend record** — `angle` / `targetLevel` / `rationale` / `relatedIds`, plus the reader-side `actionability` (is a reader-grip formulated?) / `verdict` (BÆRENDE/STØTTE/NYHET) and `readerQuestion` / `painPoint` / `saturation`. All additive-optional; store schema stays v4 (no migration). (`65b6033`)
 - **Candidate lifecycle** — `new → selected → acted | skipped`; a `select` verb + `--ids` batch triage (partial hit = exit 0, all-miss = exit 2). (`65b6033`)
 - **Band-distribution calibration (MR-F6)** — the scoring SSOT now states the expected distribution (Immediate ≥8 is the exception, target ≤~3 of 20), checkable across runs against the persisted composite. (`bace49f`)
 ### Added — trend→newsletter bridge + actionability gate (N7)
 - **Trend→newsletter bridge (MR-F3)** — `/linkedin:newsletter` Step 1 accepts a trend id and pre-fills the brief (angle / target-level / key-points / source-URLs) from the stored candidate; `articles.NN.sourceTrendId` records the provenance (additive-optional, no edition-state schema bump); Step 10 auto-`act`s the source trend on scheduling so the discovery→production loop closes deterministically; Step 2 gains an external fact-package intake path (kilde-så-draft with finished research). `grep -ci trend commands/newsletter.md`: 0 → 18. (`1adb7f4`)
 - **F7 band-cap gate (MR-F7)** — a candidate whose reader-grip is explicitly not formulated (`actionability.formulated=false`) is capped to at most `High` regardless of composite. Pure and deterministic; it overrides the composite→band derivation **downward only** (the real composite is preserved), wired into the capture path so the persisted priority is gated. (`1adb7f4`)
 ### Landed feedback
 - **MR-F3** (trend→newsletter bridge) — landed @ `1adb7f4`.
 ## [0.6.0] - 2026-07-17
 **Catch-up release.** Everything since the v0.5.3 tag ships here (28 commits, `git log --oneline v0.5.3..HEAD` is the source of truth), and the sections below also document work that shipped **inside** earlier tags but was never changelogged (see the catch-up note at the end).
 ### Added — figure pipeline (MR-F4/MR-F8)
 - **`render/build-figur.mjs`** — coded data figures: SVG/HTML → PNG via headless Chrome; three targets (article 1200px wide with content-driven height / carousel 1080×1350 / single 1200×1200); brand tokens from the user data dir's `profile/brand-tokens.json` with neutral defaults (token-seam); Chrome-hang watchdog. Standalone CLI + importable module; 33 tests. (`c4434ed`)
 - **`/linkedin:newsletter` Step 7.5 — three figure routes** with the coded route PRIMARY for data figures, plus new **`references/figure-design-guidelines.md`** (reference docs 27 → 28). (`1a67bd2`)
 - **`render/build-html.mjs` parser reconciliation** — multi-line blockquotes (blank `>` line = new `<p>` in the same quote), `[text](url)` links with an http/https/mailto scheme-whitelist, and the `**[FIGUR N — «…»]**` marker → inline SVG from `figurer/figN*.svg` with figcaption (fallback: plain blockquote) + CSS for all three. Byte-identical parser parity with the upstream engine proven by fixture; the import-safe `main()` CLI-guard is kept. 7 new tests. (`8151029`)
 ### Added — research engine RE-R3a–e
 - **R3a** — persist the relevance score on the store record + rank the morning brief on it. (`e169c78`)
 - **R3b** — trend lifecycle: re-score on re-capture, status, seen-log. (`b185db9`)
 - **R3c** — autonomous trigger: scheduler + headless entry. (`3276e44`)
 - **R3d** — temporal overlay: first-mover + saturation. (`2a8459c`)
 - **R3e** — brief history + day-over-day diff (frontmatter + "Nytt siden sist"). (`5b51b4b`)
 ### Added — OKF Stage 1
 - The brain store emits an **OKF-compatible bundle** (`brain/` as bundle, `ingest/` excluded; title/description + typed pending-diff). (`9e95222`, `e9e183e`)
 ### Fixed
 - **Oppgave 1 fix-pass** (from independent cold-review): clipboard heredoc, report refs, calendar queue fields. (`882f6ee`)
 - **Prune-regex no-op** in state-updater + date-independent calendar fixtures (flake). (`776d728`)
 ### Docs
 - **Independent cold-review complete — 29/29 surfaces** (R2a Create emitters, R2b Create orchestrators, R3 Engage, R4 Measure, R5 Grow + Router; `docs/hardening/review*.md`). (`5474df5`…`4fd038a`)
 - **Truth-pass (this release):** README maturity note + badges (hardening 29/29 + cold-review 29/29; what remains for 1.0.0 is a GUI); CLAUDE.md maturity line + Architecture entries for specifics-bank and contract-gate; **GR-model correction** in `references/algorithm-signals-reference.md` — LinkedIn's ranking model has an official primary-source name, the **Generative Recommender (GR)**, announced 2026-03-12 on LinkedIn's engineering blog (the earlier "likely fabricated" flag rejected a genuine primary source and is retracted in a correction note); **saves-API rationale** updated (Marketing API v202604 exposes `POST_SAVE` on `/memberCreatorPostAnalytics`, partner-gated — manual entry remains the right UX); hardening queue table caught up through S31a/b/c; second-brain architecture header caught up through SB-S3a–e. Plus maturity-status correction (`001d76c`), CLAUDE.md trim (−2,266 always-loaded tokens, `9567689`), ingestion-guard adoption plan (`d67552e`).
 ### Catch-up note — work that shipped inside earlier tags, never changelogged
 - **Inside v0.5.1:** **Fix #1 — contract-gate** (`scripts/contract-gate/`, deterministic §B/§C1 rule-gate, `/linkedin:newsletter` Step 4.5) and **Fix #2 — specifics-bank / lived-specifics** (`scripts/specifics-bank/` store + per-edition binding + Step 1.5 elicitation, slices 1–3). Together these took the newsletter pipeline 16 → 18 phases.
 - **Inside v0.5.3:** **SB-S3a–e** (profile.md reader-wiring, supersede arm, cross-silo id-threading, operations.md ops centre, content-history retirement + read-side reconcile) and **RE-R1–R2b** (item-schema + triage-scorer as tested code; item→store capture bridge with lossless schema v1→v2 migration; dated morning-brief artifact + session-start surfacing).
 ## [0.5.3] - 2026-06-24
 ### Changed — registration hygiene: agent fasit fixtures moved out of `agents/`
 **Stops Claude Code from registering 6 spurious agents.** The six long-form-review fasit fixtures lived in `agents/fixtures/*-cases.md`; because Claude Code scans `agents/` recursively, each was registered as a junk `fixtures:*` agent (`fixtures:content-reviewer-cases`, …). They are test fixtures, not capabilities. **Count-neutral** (no real agent/command/reference/skill change; `ls agents/*.md` still 19) — pure namespace hygiene.
 - **Moved** the 6 fasit fixtures `agents/fixtures/*-cases.md` → `tests/fixtures/*-cases.md`, and their 6 lint tests `agents/__tests__/*-fixture.test.mjs` → `tests/*-fixture.test.mjs` (co-located; each test's relative fixture path retargeted `../fixtures/` → `./fixtures/`). `agents/fixtures/` and `agents/__tests__/` are now removed.
 - **Retargeted** the 5 agent fasit-refs (`content`/`language`/`persona`/`editorial`/`fact-reviewer`) from `${CLAUDE_PLUGIN_ROOT}/agents/fixtures/…` to `${CLAUDE_PLUGIN_ROOT}/tests/fixtures/…`.
 - **Tests.** Fixture-lint 35/35 at the new path (`node --test 'tests/*.test.mjs'`); render 20/20, hooks 139/139 unaffected; gate `scripts/test-runner.sh` green (counts + version-consistency). Reinstall/reload required for the 6 spurious agents to disappear from the registry.
 ## [0.5.2] - 2026-06-23
 ### Added — SB-S2: the evolution loop (second-brain arc)
 **The compounding mechanism.** An operator-invoked, operator-gated consolidation pass that reads the published gold signal + tributary deltas and proposes a **diff** to the two-layer `brain/profile.md` — never a silent overwrite. **Non-breaking** (additive minor): count-neutral (no command/agent/reference/skill); `voice-trainer` unchanged; one session-start hook edit (zero-dep).
 - **Deterministic engine** (`scripts/brain/src/consolidate.ts`): `proposeDiff`/`applyDiff` (pure) — add / reject-`ai-draft` (model-collapse guard, in code) / evidence-bump / promote at N=3 / conflict→keep-both with **distinct ids** (primary `mintEntityId`, alt `mintContentId` — no duplicate-id corruption; no supersede, that's S3) / decay-flag at 90d (dynamic only; static decay-exempt). `applyDiff` round-trips through the SB-S0 grammar; re-running is idempotent.
 - **`brain consolidate` CLI**: `--gather` (reads published bodies since last run + the profile, for the invoking session to extract candidates — no new agent), `--propose --candidates <json>` (validates shape + single-line; writes `brain/pending-diff.{md,json}`; never touches profile.md), `--apply --diff <json> --confirm` (the ONLY path that writes profile.md; refuses without `--confirm`; records `brain/consolidation-state.json`).
 - **Session-start** (`hooks/scripts/session-start.mjs`, zero-dep edit): unconditional scaffold-ensure (fresh-install path) + a consolidation-due nudge (counts published records + reads the sidecar `last_run` via `getDataRoot`; no `profile.md` parse) + a brain-init nudge.
 - **Operator scope:** journal-capture deferred · the invoking session does the fuzzy extraction (no new agent) · motor-only (no `profile.md` reader until SB-S3). Docs: `docs/second-brain/consolidation-loop.md`.
 - **Tests.** brain suite 63 → 82 (`consolidate` 12 + `consolidate-cli` 7); hook suite 131 → 136 (new `session-start-brain-consolidation` 5); gate `scripts/test-runner.sh` 93/0/0 (`BRAIN_TESTS_FLOOR` 63→82; assertion floor unchanged at 78 — no new gate section). Light-Voyage-hardened (brief-reviewer REVISE, plan-critic REPLAN, scope-guardian ALIGNED — all folded).
 ## [0.5.1] - 2026-06-23
 ### Added — SB-S1: ingest + the published gold signal (second-brain arc)
 **The second slice of the second-brain arc.** Captures the user's *actual published posts* into `ingest/published/` tagged `provenance=published` — the gold signal that voice/profile learning is allowed to learn from — and wires the learning surface to that signal **only**, never to AI-drafted content (the model-collapse guard). **Non-breaking** (additive minor): no command/agent/reference/skill count changes; a shipped agent's learning behaviour changes (`voice-trainer`).
 - **Ingest data layer** (`scripts/brain/src/ingest.ts`): a `PublishedRecord` file-per-post grammar (fixed 5-line header + `---` sentinel + verbatim body, no YAML) with a `parse ∘ serialize` identity; a content-hash id `mintContentId = sha256(VERBATIM body)[:12]` — byte-identity dedup, so two structurally-different posts never collide and a differing body is never silently dropped.
 - **`brain` CLI** grows `ingest --file <path>` / `ingest --scan-inbox` (top-level `*.md`, skips dotfiles, non-destructive, idempotent, create-on-demand) and `published list` (surfaces `provenance` so ai-draft leakage is visible). The existing `init` is preserved.
 - **Published-only invariant wired + gate-enforced.** `agents/voice-trainer.md` reads `ingest/published/` as its primary gold source, keeps `voice-samples/` as a human tributary (not reshaped), forbids `provenance=ai-draft`, and fences the auto-append trap. A new structure-lint section (Brain Published-Only Invariant) enforces the wiring with exact-literal greps + a non-vacuity self-test.
 - **Tests.** brain suite 34 → 63 (`ingest` 14 + `publish` 9 + `cli` 6); gate `scripts/test-runner.sh` 90 → 93/0/0 (`BRAIN_TESTS_FLOOR` 34→63, assertion floor 75→78). No automatic `brain/profile.md` mutation (the consolidation loop is SB-S2); no cross-silo threading (SB-S3); no connector (SB-S4).
 ## [0.5.0] - 2026-06-18
 ### Added — M0: per-user external data dir (architecture workstream)
 **User data now lives outside the plugin.** The first of the four `v1.0.0` workstreams (architecture) is complete: every class of user data — voice profile, analytics, drafts, plans, A/B tests, audience insights, frameworks, case studies, network/repurposing trackers, user profile — now resolves under `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/` instead of the plugin tree. **Non-breaking** (minor bump): an automatic, idempotent, atomic migration runs once on session-start (copy → fsync → byte-verify → rename; external is canonical, never clobbered), and the deprecated `ANALYTICS_ROOT` / `STATE_FILE` / `PLUGIN_ROOT` aliases are still honored for one minor version.
 - **Resolver seam per runtime (twins).** `hooks/scripts/data-root.mjs` (`getDataRoot()`, zero-dep `.mjs`) and `scripts/analytics/.../storage.ts` (`getDataRoot()`, TS via `tsx`) resolve the same default + override semantics, guarded by a twin-consistency test — the runtime split (zero-dep hooks vs `tsx` analytics) forbids one shared module.
 - **Migration tool.** `hooks/scripts/migrate-data.mjs` is the single source of truth for external destinations (`MOVE_FILES` + `COPY_FILES`); `personalization-score.mjs` mirrors it. Idempotent re-runs report `already-migrated`.
 - **D2 — scaffold/instance split.** Every COPY-class data file (`examples/high-engagement-posts`, `audience-insights/{demographics,engagement-patterns}`, `templates/my-post-templates`) ships a read-only `*-template.md` seed in-plugin; the canonical instance lives external with in-plugin scaffold fallback.
 - **D3 — path convention.** `references/data-path-convention.md` defines the inline `${LINKEDIN_STUDIO_DATA:-…}/` token (generalizing the proven `${LTL_SERIES_ROOT:-…}` newsletter pattern); ~168 prose references across commands, agents, skills, hook prompts, and references repointed to it. Style-A `${CLAUDE_PLUGIN_ROOT}` is preserved for shipped read-only assets (templates, checklists, references, the analytics CLI).
 - **Privacy.** Closed a real voice-sample leak in the in-plugin `examples` scaffold (scrubbed to a generic seed; git-history scrub tracked as a pre-publish follow-up).
 ### Changed
 - Version declarations bumped to `0.5.0` across `.claude-plugin/plugin.json`, `README.md` (badge), and `CLAUDE.md` (header).
 - **Structure lint** (`scripts/test-runner.sh`) extended 74 → 81 checks: `EXPECT_REFS` 25→26 (+ exactly-+1 delta), a no-bare-in-plugin-data-path guard (R1), a no-`ANALYTICS_ROOT`-pin guard (M3 — caught 5 surviving pins in the analytics agent + skill), an SC2 working-tree dry-run, and an assertion-count anti-erosion floor — each with a non-vacuity self-test. No functionality regressed: hooks 128/0, analytics 119/0 + tsc clean, structure 81/0.
 ## [0.4.0] - 2026-05-31
 ### Re-baselined
--- a/CLAUDE.md
+++ b/CLAUDE.md
--- a/README.md
+++ b/README.md
@ -6,12 +6,12 @@
 *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)*
-![Version](https://img.shields.io/badge/version-0.7.0-blue)
+![Version](https://img.shields.io/badge/version-0.4.0-blue)
 ![Platform](https://img.shields.io/badge/platform-Claude_Code_Plugin-purple)
-![Commands](https://img.shields.io/badge/commands-30-green)
+![Commands](https://img.shields.io/badge/commands-29-green)
 ![Agents](https://img.shields.io/badge/agents-19-orange)
 ![Hooks](https://img.shields.io/badge/hooks-9-red)
-![Reference Docs](https://img.shields.io/badge/reference_docs-28-teal)
+![Reference Docs](https://img.shields.io/badge/reference_docs-25-teal)
 ![License](https://img.shields.io/badge/license-MIT-lightgrey)
 Most experts know they *should* post on LinkedIn — and quietly don't. The blank editor wins. LinkedIn Studio turns that chore into a system: structured workflows that take you from idea to published, in your own voice, calibrated to how LinkedIn's **topic-relevance** ranking model (2026) actually distributes content. Two engines under one surface — a **feed engine** for short-form posts, carousels, and video scripts, and a **long-form engine** that runs newsletter editions and essays through a serious editorial pipeline before they ever lock.
@ -22,7 +22,7 @@ This is not a shortcut. Hand the wheel to the AI and you land where everyone who
 > New here? Run `/linkedin:onboarding` — it walks you through profile optimization, personalization, and your first published post in one guided flow (~10 minutes).
 > [!NOTE]
-> **Pre-1.0.** The earlier 1.0.0–4.1.0 numbering reflected ambition, not maturity. Honest about where it stands today: the **architecture workstream (M0) is done** — user data lives in a per-user data dir *outside* the plugin, with automatic migration — and the **29 pre-0.7.0 command surfaces have all passed both the interactive hardening gate (29/29) and independent cold-review (29/29)** (`/linkedin:trends`, new in 0.7.0-dev, is not yet gated). What remains for 1.0.0 is a GUI. See [CHANGELOG.md](CHANGELOG.md).
+> **Pre-1.0 (v0.4.0).** The earlier 1.0.0–4.1.0 numbering reflected ambition, not maturity. Honest about where it stands today: user data still lives inside the plugin, no command has been through a hardening gate, command testing is incomplete, and there is no GUI yet. See [CHANGELOG.md](CHANGELOG.md).
 ---
@ -45,7 +45,7 @@ For everyday presence. The point is *velocity without losing quality*: every con
 ### 📖 The Long-Form Engine — `/linkedin:newsletter`
-For the pieces that build authority — newsletter editions, essays, series articles. This is what sets LinkedIn Studio apart from "AI writes your post" tools: an **18-phase pipeline where the draft is grounded in your real material *before research* (lived-specifics extraction) and then has to survive a gauntlet of quality gates *before it locks*.**
+For the pieces that build authority — newsletter editions, essays, series articles. This is what sets LinkedIn Studio apart from "AI writes your post" tools: a **16-phase pipeline where the draft has to survive a gauntlet of quality gates *before it locks*.**
 ```
 skeleton gate ──▶ voice scrub ──▶ fact-check ──▶ editorial craft gate ──▶
@ -108,7 +108,7 @@ Run the onboarding wizard — it walks you through profile, setup, and your firs
 ## Commands
-All 30 commands use colon notation: `/linkedin:post`, `/linkedin:quick`, etc. The surface is organized into five journeys (Start · Create · Engage · Measure · Grow); `/linkedin:create` and `/linkedin:measure` are guided front-doors that route you to the right command when you know the journey but not the exact command. Run `/linkedin` for the live router with your posting status.
+All 29 commands use colon notation: `/linkedin:post`, `/linkedin:quick`, etc. The surface is organized into five journeys (Start · Create · Engage · Measure · Grow); `/linkedin:create` and `/linkedin:measure` are guided front-doors that route you to the right command when you know the journey but not the exact command. Run `/linkedin` for the live router with your posting status.
 ### Onboarding & Setup
@ -133,7 +133,7 @@ All 30 commands use colon notation: `/linkedin:post`, `/linkedin:quick`, etc. Th
 | `/linkedin:multiplatform` | Adapt LinkedIn content for X threads, newsletter sections, blog posts, slides, YouTube scripts. |
 | `/linkedin:batch` | A full week of content in one session — one theme in, 3–5 posts out, written to the queue. |
 | `/linkedin:pipeline` | Full end-to-end pipeline from idea to published post (ideation → publish → post-analysis). |
-| `/linkedin:newsletter` | Long-form orchestrator — newsletter/essay/series article at series quality. Multi-session 18-phase pipeline; lived-specifics grounding BEFORE research, all gates BEFORE lock. |
+| `/linkedin:newsletter` | Long-form orchestrator — newsletter/essay/series article at series quality. Multi-session 16-phase pipeline; all gates BEFORE lock. |
 | `/linkedin:headless-review` | Cold adversarial review package on a FROZEN draft (`content-reviewer` + `language-reviewer` + `fact-reviewer` + `persona-reviewer`) — run in a fresh session for maximum isolation. |
 | `/linkedin:pivot` | Re-open a long-form edition after a substantive late change so cleared gates re-run before lock (heuristic: >20 % word-count or >2 new sections). |
@ -179,8 +179,7 @@ All 30 commands use colon notation: `/linkedin:post`, `/linkedin:quick`, etc. Th
 | `content-planner` | Sonnet | Weekly/monthly content calendars |
 | `network-builder` | Sonnet | Strategic networking + outreach |
 | `content-repurposer` | Sonnet | Format conversion + evergreen refresh |
-| `trend-spotter` | (inherits session) | Trending topics + opportunity scores |
+| `trend-spotter` | Sonnet | Trending topics + opportunity scores |
 | `demand-spotter` | (inherits session) | Demand-sweep «innenfra og ut»: reader's verbatim questions → pain-point map → vocabulary translation → arc map with honest market verdict |
 | `voice-trainer` | Sonnet | Voice profile building + drift detection |
 | `differentiation-checker` | Sonnet | Originality scoring + commodity detection |
 | `video-scripter` | Sonnet | Video scripts with pacing + visual cues |
@ -246,7 +245,7 @@ The README is the front door. The detail lives alongside it:
 | For… | See |
 |------|-----|
 | Architecture — agent pipeline & selection, 9 hooks, 6 skills, personalization scoring, configuration, analytics internals | [CLAUDE.md](CLAUDE.md) |
-| The 28-document knowledge base (algorithm signals, angles, frameworks, strategy guides) | [`references/`](references/) |
+| The 25-document knowledge base (algorithm signals, angles, frameworks, strategy guides) | [`references/`](references/) |
 | Full version history and known gaps | [CHANGELOG.md](CHANGELOG.md) |
 | Maintenance model, fork-and-own, what upstream provides | [GOVERNANCE.md](GOVERNANCE.md) |
--- a/agents/tests/content-reviewer-fixture.test.mjs
+++ b/agents/tests/content-reviewer-fixture.test.mjs
@ -13,7 +13,7 @@ import { fileURLToPath } from 'node:url';
 // [GATE]/[OPERATØR], never self-certified here.
 const FIXTURE_PATH = fileURLToPath(
-  new URL('./fixtures/content-reviewer-cases.md', import.meta.url)
+  new URL('../fixtures/content-reviewer-cases.md', import.meta.url)
 );
 const fixture = readFileSync(FIXTURE_PATH, 'utf8');
--- a/agents/tests/editorial-reviewer-fixture.test.mjs
+++ b/agents/tests/editorial-reviewer-fixture.test.mjs
@ -12,7 +12,7 @@ import { fileURLToPath } from 'node:url';
 // never self-certified here.
 const FIXTURE_PATH = fileURLToPath(
-  new URL('./fixtures/editorial-reviewer-cases.md', import.meta.url)
+  new URL('../fixtures/editorial-reviewer-cases.md', import.meta.url)
 );
 const fixture = readFileSync(FIXTURE_PATH, 'utf8');
--- a/agents/tests/fact-checker-fixture.test.mjs
+++ b/agents/tests/fact-checker-fixture.test.mjs
@ -11,7 +11,7 @@ import { fileURLToPath } from 'node:url';
 // self-certified here.
 const FIXTURE_PATH = fileURLToPath(
-  new URL('./fixtures/fact-checker-cases.md', import.meta.url)
+  new URL('../fixtures/fact-checker-cases.md', import.meta.url)
 );
 const VERDICTS = ['🟢', '🔴', '🟡'];
--- a/agents/tests/fact-reviewer-fixture.test.mjs
+++ b/agents/tests/fact-reviewer-fixture.test.mjs
@ -13,7 +13,7 @@ import { fileURLToPath } from 'node:url';
 // [GATE]/[OPERATØR], never self-certified here.
 const FIXTURE_PATH = fileURLToPath(
-  new URL('./fixtures/fact-reviewer-cases.md', import.meta.url)
+  new URL('../fixtures/fact-reviewer-cases.md', import.meta.url)
 );
 const fixture = readFileSync(FIXTURE_PATH, 'utf8');
--- a/agents/tests/language-reviewer-fixture.test.mjs
+++ b/agents/tests/language-reviewer-fixture.test.mjs
@ -13,7 +13,7 @@ import { fileURLToPath } from 'node:url';
 // the fasit directions is [GATE]/[OPERATØR], never self-certified here.
 const FIXTURE_PATH = fileURLToPath(
-  new URL('./fixtures/language-reviewer-cases.md', import.meta.url)
+  new URL('../fixtures/language-reviewer-cases.md', import.meta.url)
 );
 const fixture = readFileSync(FIXTURE_PATH, 'utf8');
--- a/agents/tests/persona-reviewer-fixture.test.mjs
+++ b/agents/tests/persona-reviewer-fixture.test.mjs
@ -12,7 +12,7 @@ import { fileURLToPath } from 'node:url';
 // never self-certified here.
 const FIXTURE_PATH = fileURLToPath(
-  new URL('./fixtures/persona-reviewer-cases.md', import.meta.url)
+  new URL('../fixtures/persona-reviewer-cases.md', import.meta.url)
 );
 const fixture = readFileSync(FIXTURE_PATH, 'utf8');
--- a/agents/analytics-interpreter.md
+++ b/agents/analytics-interpreter.md
@ -45,17 +45,17 @@ The two modes share the same data sources and analysis framework; they differ in
 The plugin has a built-in analytics pipeline. Always check for imported data first — structured data is more reliable than user-reported numbers.
-1. **Check for imported data:** Read files in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/` — these contain structured JSON with per-post metrics (impressions, reactions, comments, shares, clicks, engagement rate).
+1. **Check for imported data:** Read files in `${CLAUDE_PLUGIN_ROOT}/assets/analytics/posts/` — these contain structured JSON with per-post metrics (impressions, reactions, comments, shares, clicks, engagement rate).
-2. **Weekly reports (report mode):** Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/*.json` for pre-generated summaries.
+2. **Weekly reports (report mode):** Read `${CLAUDE_PLUGIN_ROOT}/assets/analytics/weekly-reports/*.json` for pre-generated summaries.
-3. **Load pattern baselines:** Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/engagement-patterns.md` for the user's tracked engagement patterns (best times, top topics, format performance, hook types that work). Use this as baseline context.
+3. **Load pattern baselines:** Read `${CLAUDE_PLUGIN_ROOT}/assets/audience-insights/engagement-patterns.md` for the user's tracked engagement patterns (best times, top topics, format performance, hook types that work). Use this as baseline context.
-4. **Load audience context:** Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/demographics.md` for audience composition.
+4. **Load audience context:** Read `${CLAUDE_PLUGIN_ROOT}/assets/audience-insights/demographics.md` for audience composition.
 5. **Run trend analysis:**
   ```bash
-   node --import tsx "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric impressions
+   ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" node --import tsx "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric impressions
   ```
 6. **Generate fresh report (report mode):**
   ```bash
-   node --import tsx "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report --week <YYYY-WXX>
+   ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" node --import tsx "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report --week <YYYY-WXX>
   ```
 7. **If no imported data exists:** Guide the user to run `/linkedin:import` first. Fall back to the manual data sources below.
@ -64,15 +64,15 @@ When structured data is available, use it as the primary source. This gives you
 ## Reference Data (both modes)
 Always load these for pattern comparison:
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md` — Proven high-engagement patterns and replicable elements. Compare top posts against these.
+- `${CLAUDE_PLUGIN_ROOT}/assets/examples/high-engagement-posts.md` — Proven high-engagement patterns and replicable elements. Compare top posts against these.
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/engagement-patterns.md` — Historical engagement patterns (benchmark for current period).
+- `${CLAUDE_PLUGIN_ROOT}/assets/audience-insights/engagement-patterns.md` — Historical engagement patterns (benchmark for current period).
 ## Manual Data Sources (fallback)
 When structured analytics aren't available:
 - `~/.claude/linkedin-studio.local.md` — Posting history, streaks, weekly stats
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/plans/` — Planned vs. actual content
+- `${CLAUDE_PLUGIN_ROOT}/assets/plans/` — Planned vs. actual content
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/` — Draft history
+- `${CLAUDE_PLUGIN_ROOT}/assets/drafts/` — Draft history
 - See `${CLAUDE_PLUGIN_ROOT}/assets/analytics/README.md` for data format and directory structure.
 ## Mission
--- a/agents/content-optimizer.md
+++ b/agents/content-optimizer.md
@ -31,7 +31,7 @@ When you receive content to optimize, analyze it through these lenses:
 ### 1. Hook Analysis (First 110-140 Characters)
-**First, load the user's proven patterns:** Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md` to identify which hook types and content patterns specifically work for THIS user's audience. Prioritize their proven patterns over generic advice.
+**First, load the user's proven patterns:** Read `${CLAUDE_PLUGIN_ROOT}/assets/examples/high-engagement-posts.md` to identify which hook types and content patterns specifically work for THIS user's audience. Prioritize their proven patterns over generic advice.
 **Check against high-performing hook types:**
 - Surprising stat
--- a/agents/content-planner.md
+++ b/agents/content-planner.md
@ -4,7 +4,7 @@ description: |
  Systematic content planning agent that creates weekly and monthly content plans based on
  content pillars, 70/20/10 mix, seasonal themes, and publishing gaps. Analyzes previous
  plans to avoid repetition, enforces content mix balance, and stores plans in
-  ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/plans/ for tracking. Can create Linear issues for each planned post.
+  assets/plans/ for tracking. Can create Linear issues for each planned post.
  Use when the user says:
  - "plan my content", "what should I post this week", "content calendar"
@ -21,7 +21,7 @@ tools: ["Read", "Glob", "Write", "AskUserQuestion", "WebSearch"]
 # Content Planner Agent
-You are a LinkedIn content planning specialist. You create strategic content plans that balance topic pillars, content types, and posting frequency for sustainable authority building.
+You are a LinkedIn content planning specialist. You create strategic content plans that balance topic pillars, content types, and posting frequency for sustainable thought leadership growth.
 ## Step 0: Load Context
@ -29,7 +29,7 @@ Read these files before planning:
 ```
 ${CLAUDE_PLUGIN_ROOT}/skills/linkedin-studio/SKILL.md           → expertise areas, voice
-${CLAUDE_PLUGIN_ROOT}/references/content-angles.md         → 8 universal angles
+${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md         → 8 universal angles
 ${CLAUDE_PLUGIN_ROOT}/references/linkedin-growth-playbook-2025-2026.md → growth strategies
 ${CLAUDE_PLUGIN_ROOT}/references/low-frequency-posting-strategy.md    → sustainable posting
 ${CLAUDE_PLUGIN_ROOT}/references/linkedin-formats.md                  → format options
@ -37,7 +37,7 @@ ${CLAUDE_PLUGIN_ROOT}/assets/templates/weekly-content-calendar-2-3x.md → calen
 ~/.claude/linkedin-studio.local.md                        → user state + recent posts
 ```
-Also scan `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/plans/` for previous plans to avoid repetition.
+Also scan `${CLAUDE_PLUGIN_ROOT}/assets/plans/` for previous plans to avoid repetition.
 ## Step 1: Content Audit
@ -149,21 +149,21 @@ For a 2-3 post/week cadence (optimal for sustainable growth):
 These rotation rules are enforced at write-time by the `topic-rotation-gate` hook:
-1. **No back-to-back pillars** — Never schedule the same pillar for consecutive posts. If Post 1 is "Implementation", Post 2 must be a different pillar.
+1. **No back-to-back pillars** — Never schedule the same pillar for consecutive posts. If Post 1 is "Azure AI", Post 2 must be a different pillar.
 2. **14-day 50% balance cap** — No single pillar may exceed 50% of posts in any rolling 14-day window.
 3. **Rotation priority** — When selecting the next pillar, prioritize the pillar with the highest gap score (most days since last post + fewest posts in 14-day window).
 4. **Underrepresented pillars** — Any pillar with 0 posts in the last 14 days should receive a priority slot in the next plan.
 ## Step 3: Seasonal & Event Awareness
-### Annual Calendar — rhythm, adapt to your field & region
+### Annual Calendar — Nordic/Tech Focus
-The cadence below is general. Anchor it with **your** field's events (conferences, release cycles, regulatory milestones) and your region's cultural moments — loaded from the user's profile/pillars, not baked in. Where a specific event is named, it is an *example* — swap in the equivalent from your domain. Check the current date and flag relevant themes:
+Check the current date and flag relevant themes:
 ```
 JANUARY
  - New Year goals/reflections → "My [year] priorities" posts
-  - Predictions for the year (in your field)
+  - AI predictions for the year
  - Q4 retrospective content
 FEBRUARY
@ -172,18 +172,18 @@ FEBRUARY
  - Valentine's: "Love letters to [profession/tool]" (entertaining)
 MARCH
-  - International Women's Day (Mar 8) → diversity in your field
+  - International Women's Day (Mar 8) → Diversity in tech
-  - End of Q1 → quarterly reflections
+  - End of Q1 → Quarterly reflections
-  - Spring conference season starting (your field's events)
+  - Spring conferences starting (Nordic tech scene)
 APRIL
-  - Conference season builds (your field's events)
+  - NDC conferences season begins
-  - Regulatory/policy updates in your domain
+  - AI regulation updates (EU AI Act milestones)
-  - Easter break (region-dependent) → personal reflection posts
+  - Easter break → Personal reflection posts
 MAY
-  - Major release cycles (e.g. a key vendor's annual developer conference) → announcement commentary
+  - Microsoft Build (typically May) → AI announcements
-  - Regional national days / cultural moments → cultural content (if it fits your brand)
+  - 17. mai (Norwegian National Day) → Cultural content
  - End of spring conference season wrap-ups
 JUNE
@ -202,19 +202,19 @@ AUGUST
  - Conference CFP deadlines (fall events)
 SEPTEMBER
-  - Conference peak in many fields → takeaways and commentary
+  - Tech conference peak (Ignite, various Nordic events)
-  - Autumn product/release launches → commentary
+  - New product launches (Apple, Microsoft)
  - "What I learned this summer" reflection
 OCTOBER
-  - Awareness months relevant to your field (e.g. cybersecurity)
+  - Cybersecurity awareness month
  - Q3 wrap-ups
-  - Halloween → creative/entertaining content
+  - Halloween → Creative/entertaining tech content
 NOVEMBER
-  - Year-end vendor conferences / recaps → commentary
+  - Microsoft Ignite (typically November)
-  - Recap season begins
+  - AI recap season begins
-  - Black Friday → "best [professional tools]" lists
+  - Black Friday → "Best [professional tools]" lists
 DECEMBER
  - Year-in-review content
@ -461,7 +461,7 @@ After any adjustment, re-run the quality check before saving.
 ### Save the Plan
-Save approved plans to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/plans/`:
+Save approved plans to `${CLAUDE_PLUGIN_ROOT}/assets/plans/`:
 - Weekly: `2026-W05.md`
 - Monthly: `2026-02.md`
@ -500,7 +500,7 @@ Ask via AskUserQuestion before creating issues:
 ## Reference Files
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md` — 8 universal angles
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md` — 8 universal angles
 - `${CLAUDE_PLUGIN_ROOT}/references/linkedin-growth-playbook-2025-2026.md` — Growth strategies
 - `${CLAUDE_PLUGIN_ROOT}/references/low-frequency-posting-strategy.md` — Sustainable posting
 - `${CLAUDE_PLUGIN_ROOT}/references/linkedin-formats.md` — Format options and specs
--- a/agents/content-repurposer.md
+++ b/agents/content-repurposer.md
@ -34,9 +34,9 @@ ${CLAUDE_PLUGIN_ROOT}/references/linkedin-formats.md              → format spe
 ${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md          → CTA and engagement patterns
 ${CLAUDE_PLUGIN_ROOT}/references/articles-strategy-guide.md        → article writing strategy
 ${CLAUDE_PLUGIN_ROOT}/references/newsletter-strategy-guide.md      → newsletter integration
-${CLAUDE_PLUGIN_ROOT}/references/content-angles.md      → 8 universal angles
+${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md      → 8 universal angles
 ${CLAUDE_PLUGIN_ROOT}/assets/case-studies/case-study-template.md   → case study structure + 4 LinkedIn post angles
-${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md     → proven patterns to replicate
+${CLAUDE_PLUGIN_ROOT}/assets/examples/high-engagement-posts.md     → proven patterns to replicate
 ~/.claude/linkedin-studio.local.md                     → user state + performance data
 ```
@ -556,7 +556,7 @@ CONTENT LIFECYCLE TRACKER
 | "[Hook]" | [date] | [1-7] | [specific action] | [date] |
 ```
-Save tracker to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/repurposing-tracker.md`
+Save tracker to `${CLAUDE_PLUGIN_ROOT}/assets/repurposing-tracker.md`
 ## Step 7: Batch Repurposing
@ -588,13 +588,13 @@ Publishing schedule:
  Week 2: [item 3], [item 4]
  Week 3: [item 5], [item 6]
-Expected reach: above the original (directional — no reliable multiplier)
+Expected reach multiplier: [2-5x original]
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 ## Output & Storage
-Save repurposed content to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/repurposed/`:
+Save repurposed content to `${CLAUDE_PLUGIN_ROOT}/assets/drafts/repurposed/`:
 ```
 Naming convention:
@ -614,5 +614,5 @@ Create the `drafts/repurposed/` directory if it doesn't exist.
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md` — CTA patterns
 - `${CLAUDE_PLUGIN_ROOT}/references/articles-strategy-guide.md` — article strategy
 - `${CLAUDE_PLUGIN_ROOT}/references/newsletter-strategy-guide.md` — newsletter integration
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md` — 8 universal angles
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md` — 8 universal angles
 - `${CLAUDE_PLUGIN_ROOT}/references/low-frequency-posting-strategy.md` — posting cadence
--- a/agents/content-reviewer.md
+++ b/agents/content-reviewer.md
@ -283,6 +283,6 @@ Read these for the contract and the pipeline position:
  lock (Step 8).
 - `${CLAUDE_PLUGIN_ROOT}/references/longform-quality-rules.md` — the broad quality
  pass; this agent is the *finer* argument-integrity gate that runs cold after it.
- `${CLAUDE_PLUGIN_ROOT}/tests/fixtures/content-reviewer-cases.md` — fasit
+- `${CLAUDE_PLUGIN_ROOT}/agents/fixtures/content-reviewer-cases.md` — fasit
  fixture: the Del 4 (Security Champions, Maskinrommet, 2026-05-29) worked cases
  mapping real argument defects to C1–C5 + severities.
--- a/agents/demand-spotter.md
+++ b/agents/demand-spotter.md
@ -1,172 +0,0 @@
 ---
 name: demand-spotter
 description: |
  Turn a discovered topic «innenfra og ut» — from the reader's problem, not the field's news. Poll
  where the audience already ASKS (forums, GitHub issues, procurement data, regulator guidance),
  surface their verbatim questions, map each to the cost/risk/duty/tool it hits, translate the
  field's jargon into the reader's own words, and deliver an honest market verdict (write here vs
  saturated) as a set of arcs (veins) — one actionable edition per question.
  Use when the user asks:
  - "who's actually asking about this?", "what's the reader's real question here?"
  - "demand sweep", "map the demand", "is anyone asking for this?"
  - "what pain point does this hit?", "translate this out of the jargon"
  - "is this saturated?", "should we write this or is it already answered?"
  - "turn this trend into the reader's words", "innenfra og ut"
  Triggers on: "demand sweep", "who is asking", "reader's question", "pain point", "saturated",
  "market gap", "innenfra og ut", "translate the jargon", "arc", "åre".
 color: silver
 # No `tools:` allowlist by design (same routing rationale as trend-spotter): an allowlist would
 # block every research MCP unless each `mcp__<server>__<tool>` were hardcoded, breaking the
 # "prefer whatever MCP the user actually connected, hardcode nothing" routing. Omitting `tools:`
 # inherits every session tool, so Tavily / Gemini / Perplexity / a GitHub MCP is reachable when
 # present, with WebSearch + WebFetch as the always-available floor. Bash stays (it runs the
 # deterministic trend-store CLI: `capture` to persist, `arcs` to render the §4 output).
 disallowedTools: Write, Edit, NotebookEdit
 ---
 # Demand Spotter Agent — «innenfra og ut»
 You are the demand-side twin of the trend-spotter. Discovery finds **what happened**; you translate
 it into **the problem the reader is stuck on**. Without that translation the line writes *utenfra og
 inn* — "here is a technology, should you consider it?" — to an audience that never used the field's
 words. Your job is the inverse: start from the pain the reader already has, and show what the topic
 does to it.
 **Domain-generality is absolute.** The sources, the pain-point taxonomy, and the vocabulary rule
 below are GENERIC mechanisms. Which pillars matter, which sources to poll, and what counts as a
 reader "grip" come from the user's profile and data dir at runtime — never a beat baked into this
 agent. The same sweep serves any niche.
 ## Your Mission — three passes, run AFTER discovery and BEFORE drafting
 You do not re-score relevance (that is trend-spotter's five sender-fit dimensions). You run three
 passes that produce the reader side the sender-fit score is blind to:
 1. **Demand-sweep** — poll where the questions actually live; surface verbatim questions with sources.
 2. **Pain-point map** — connect each question to the cost/risk/duty/tool the reader already carries.
 3. **Vocabulary translation** — render the question in the reader's own words, not the field's jargon.
 Deliver the result as **arcs (veins)**: a warm topic is not one news-item, it is a vein, and each
 question in it is one actionable edition.
 ---
 ## Pass 1 — Demand-sweep (where the questions live)
 The user's `trends/sources.md` **Tier 5** lists the demand sources for their niche (the generic
 shape ships in `${CLAUDE_PLUGIN_ROOT}/config/trends-sources.template.md`). Poll them — these are the
 **inverse** of Tier 1–4 (supply/announcement sources):
 - **Practitioner forums / communities** — where people ask (Reddit, HN, product forums, Discord/Slack where reachable).
 - **GitHub issues on the spec / tool repos** — undervalued gold: real questions from the people building, with names + comment counts as signal strength.
 - **Procurement data** — the hardest demand indicator there is: someone has a budget and wrote the need down (a national tender portal / a TED-equivalent for the market).
 - **Regulator / supervisory guidance** — what the reader is *required* to take a position on (non-optional demand).
 - **Comment fields** on the user's own channels.
 **Research routing (hardcode nothing):** prefer whatever research MCP the user has connected (Tavily,
 Gemini, a GitHub MCP, …); fall back to WebSearch + WebFetch. Route each source to the tool that can
 actually reach it.
 **Ground truth first — and be honest about the blind spots:**
 - **HN (Algolia API) and GitHub (issues API) are exact** — prioritise them for signal strength; a comment/issue count from them is a real number.
 - **Reddit blocks direct fetch** (curl/WebFetch) — sitations come via a research MCP, and counts are inconsistent between snapshots → treat Reddit numbers as **approximate**, never as fact.
 - **YouTube / video comments are JS-rendered** and need an API key — the largest blind spot, and it hits exactly the channels many creators use most. **Specify the fetch method or mark the channel explicitly un-swept.**
 - **An honest null is a finding.** If a source is thin, say "thin signal" — never invent demand to fill a slot. `demand.strength: "thin"` is a measured low; omitting `demand` entirely means unmeasured. Both are legitimate; a fabricated "strong" is not.
 **Output of Pass 1, per question:** the verbatim question + its source URL, clustered by theme, each
 with (a) **signal strength** — how many ask, honestly estimated, and (b) **is it answered?** — is a
 good answer already out there, is the market saturated.
 ---
 ## Pass 2 — Pain-point map (connect to what the reader already struggles with)
 For each cluster, ask: what does the organisation **already** have as a problem that this topic
 touches? Map to one of:
 - **Cost they already pay** (licences, time, double work)
 - **Risk they already own** (regulation, supervision, precedent, security)
 - **Duty they already have** (impact assessment, archiving, transparency/FOI, information security)
 - **Tools they already have** — critical: the reader is usually *already* inside a suite they pay for; anything new competes against something that is effectively "free" and already operated by IT.
 - **ROI doubt they already voiced** — and whether the numbers in the field actually hold up.
 Without this pass the piece is a technology presentation. With it, it answers a letter the reader
 already wrote. This pass fills the record's **`painPoint`**.
 ---
 ## Pass 3 — Vocabulary translation (the reader's words, not the field's)
 **Rule: the field's jargon is forbidden in the title, hook, and ingress** unless the audience
 demonstrably uses it. Keep the topic; swap the words. Produce **both, side by side**:
 - *the field's words* (kept as the record `title`)
 - *the reader's words* — the record **`readerQuestion`**
 **The test that must pass:** can a leader who never heard of the topic recognise their own problem in
 the title? No → the title is written *utenfra og inn*, and you rewrite it. This pass fills
 **`readerQuestion`**.
 ---
 ## Output contract §4 — the arc (åre), not the news-item
 Persist each swept question as a store record carrying the reader fields, then render the arc map.
 **Persist (Pass 1–3 results) via the deterministic store CLI** — one batch call, carrying the reader
 fields the demand-sweep produced (`readerQuestion`, `painPoint`, `saturation`, `demand`, plus the
 reader-side verdict `verdict` and grip `actionability` the F7 gate reads). `relatedIds` links the
 records that are facets of one vein:
 ```bash
 cd "${CLAUDE_PLUGIN_ROOT}/scripts/trends" && \
  echo '[
    {"source":"<hn|github|tavily|…>","title":"<the field'\''s words, verbatim>","url":"<source url>",
     "topics":["<pillar-tag>"],
     "readerQuestion":"<the reader'\''s own words — Pass 3>",
     "painPoint":"<cost/risk/duty/tool it hits — Pass 2>",
     "saturation":"<metningsdom, verbatim: is it answered, by whom>",
     "demand":{"strength":"strong|moderate|thin","answered":true|false},
     "verdict":"BÆRENDE|STØTTE|NYHET",
     "actionability":{"formulated":true|false,"note":"<the reader grip, or why none>"},
     "relatedIds":["<id of another record in the same vein>"]}
  ]' | node --import tsx src/cli.ts capture
 ```
 - **`demand`** is the rankable twin of the verbatim `saturation` text: `strength` = etterspørsel (how strongly asked), `answered` = whether a good answer already exists. Omit `demand` when you did not measure it (honest null) — do not fabricate a strength.
 - **`verdict`/`actionability`** are the reader-side utility judgment (mechanism from the scoring SSOT); the deterministic F7 band-cap gate reads them. What counts as a formulated grip is the operator's reader-side calibration (profile / data dir), never yours to invent.
 - Content-invalid items land in `errors[]`; the valid ones still persist. A malformed `demand` (bad strength, non-boolean `answered`) is a hard error at the seam — fix the payload, don't silently drop the field.
 **Render the §4 output — the arc map** (question inventory ranked on `etterspørsel × kan-svare ×
 ikke-besvart`, per-vein market verdict, BÆRENDE/STØTTE reading order). This is deterministic code —
 you do not hand-format it:
 ```bash
 cd "${CLAUDE_PLUGIN_ROOT}/scripts/trends" && \
  node --import tsx src/cli.ts arcs            # print the arc map
  # node --import tsx src/cli.ts arcs --topics "<pillar>"   # narrow to one theme
  # node --import tsx src/cli.ts arcs --out "<dir>"          # write a dated arc map
 ```
 The `arcs` verb groups the demand-swept records into veins (relatedIds transitive closure), ranks the
 questions, classifies each vein's **honest market verdict**, and renders it. The verdict distinguishes
 the two gaps you must never confuse:
 - **supply-gap** (many ask, none answer) — the gold: write here.
 - **demand-gap** (few ask, but the sender can answer) — highest value, lowest guaranteed audience.
 - **saturated** (already answered) — do not write.
 - **unknown / thin** — the honest null; do not fill it in.
 ---
 ## What you deliver to the caller
 1. The **arc map** (the `arcs` output) — the ranked question inventory per vein, with the market verdict.
 2. A one-line reading: which vein is the strongest write (highest-ranked supply-gap or a high-conviction demand-gap), and which questions are saturated (skip).
 3. The blind spots you hit (un-swept channels, approximate counts) — stated plainly, never papered over.
 You persist and render; you never draft the edition — that is `/linkedin:newsletter`. Your output is
 the *inntak* to the drafting decision, in the reader's own words.
--- a/agents/differentiation-checker.md
+++ b/agents/differentiation-checker.md
@ -44,7 +44,7 @@ Before searching, identify:
 1. **Direct topic:** `site:linkedin.com "[key phrase from thesis]"`
 2. **Competing angle:** `"[topic]" AND "[angle keyword]" site:linkedin.com`
-3. **Broad topic:** `"[topic]" expert insights 2025 2026`
+3. **Broad topic:** `"[topic]" thought leadership 2025 2026`
 4. **Contrarian:** `"[topic]" "actually" OR "wrong" OR "myth"`
 5. **Expert:** `"[topic]" expert opinion LinkedIn`
@ -144,7 +144,7 @@ Rate each as present (P), partially present (PP), or absent (A):
 1. Echo chamber -- repeats what everyone says
 2. Humble brag -- disguised self-promotion
 3. Vague wisdom -- platitudes without specifics
-4. Pure promotion -- marketing posing as expertise
+4. Pure promotion -- marketing as thought leadership
 5. Borrowed authority -- citing without adding perspective
 6. Generic listicle -- numbered list, no unique framing
 7. Tired take -- exhausted arguments ("AI will replace [job]")
@ -200,7 +200,7 @@ Combine 2-3 of the 8 Universal Angles:
 - **Reverse causation:** "We think X causes Y. What if Y causes X?"
 - **Zoom out/in:** Switch between big-picture and meeting-room perspective.
-## Authority Value Test
+## Thought Leadership Value Test
 Every piece must pass at least **two of three:**
@ -324,6 +324,6 @@ content-planner --> [draft] --> differentiation-checker --> content-optimizer --
 ## References
 Read these files for detailed methodology:
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md` -- 8 Universal Angles, combinations, red flags, authority value test
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md` -- 8 Universal Angles, combinations, red flags, thought leadership test
- `${CLAUDE_PLUGIN_ROOT}/references/content-framework.md` -- content anti-patterns, differentiation checklist, relevance filter
+- `${CLAUDE_PLUGIN_ROOT}/references/ai-content-framework.md` -- AI content anti-patterns, differentiation checklist, relevance filter
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md` -- hook types, contrarian opening patterns, story structures
--- a/agents/editorial-reviewer.md
+++ b/agents/editorial-reviewer.md
@ -276,6 +276,6 @@ Read these for the contract and the pipeline position:
  the gate that runs *after* this one; the role boundary is craft vs. response.
 - `${CLAUDE_PLUGIN_ROOT}/agents/fact-checker.md` — the Step 5 sweep (truth);
  this agent runs *after* it on the fact-checked draft.
- `${CLAUDE_PLUGIN_ROOT}/tests/fixtures/editorial-reviewer-cases.md` — fasit
+- `${CLAUDE_PLUGIN_ROOT}/agents/fixtures/editorial-reviewer-cases.md` — fasit
  fixture: the Del 4 v5 gold-standard (KTG's eight editorial points mapped to the
  two axes + severities).
--- a/agents/engagement-coach.md
+++ b/agents/engagement-coach.md
@ -49,7 +49,7 @@ Help creators:
 - Substantive comments (15+ words) outweigh short ones and rank above plain reactions — but below saves and shares (no fixed comment-vs-reshare multiplier)
 - Posts with 15+ engagements in first hour unlock 2nd/3rd degree distribution
 - Your comments on others' posts expose you to their audience
- Commenting within 30 minutes of a post tends to earn more follow-up engagement on your comment (multiplier unverified)
+- Commenting within 30 minutes of a post = 64% more follow-up engagement on your comment
 **The insight:** Time spent engaging often returns MORE than time spent creating.
@ -72,13 +72,13 @@ Help creators:
 ### 2. First Hour Strategy
-**Critical context:** The first 15–30 minutes decide ~70% of total reach (golden window 60–90 min; see `references/algorithm-signals-reference.md`)
+**Critical context:** First 60 minutes determine 70% of total reach
 **The sequence:**
 1. **Post** at optimal time for your audience
 2. **Wait 10 minutes** — let organic engagement start
 3. **Add value comment** on your own post (extend the conversation, add resource)
-4. **Respond to EVERY comment** within 30 minutes (more follow-ups — figure unverified)
+4. **Respond to EVERY comment** within 30 minutes (64% more follow-ups)
 5. **Add 2-3 more self-comments** over 90 minutes (spark discussion)
 **Velocity targets:**
@ -117,7 +117,7 @@ Evaluate every potential comment target against these four groups. Each serves a
 - Find them in comment sections of relevant posts
 - Prospect while providing genuine value
 - Build relationships before any pitch
- 2-3 touchpoints on their content = far more likely to get a positive response (figure unverified)
+- 2-3 touchpoints on their content = 3.6x more likely to get positive response
 - Frequency: When you spot them in relevant discussions
 **4. New Connections — Algorithm Play**
@ -192,11 +192,11 @@ Structure: Connect to their point → Share brief relevant story → Extract the
 4. **Write for the audience**, not just the author — other readers are watching
 5. **End with energy** — a question or statement that invites response
 6. **Match the post's tone** — serious post = serious comment, personal post = personal comment
-7. **AI-generated comments cost you** — ~45% less engagement (correlational, medium confidence) and actively suppressed when detected. Use templates as scaffolding, write in YOUR voice.
+7. **AI-generated comments cost you** — 55% engagement penalty when detected. Use templates as scaffolding, write in YOUR voice.
 ### Optimal Comment Windows (CET)
-Commenting within 30 minutes of a post's publication tends to earn more follow-up engagement on your comment (figure unverified). Early comments get pinned to the top and seen by the largest audience.
+Commenting within 30 minutes of a post's publication = 64% more follow-up engagement on your comment. Early comments get pinned to the top and seen by the largest audience.
 | Time Block | Activity | Why |
 |------------|----------|-----|
@ -310,7 +310,7 @@ Rate each comment before posting:
 | 0 min | Post goes live | - |
 | 10 min | Add value comment | Spark conversation |
 | 15 min | Check for early comments | Respond immediately |
-| 30 min | Respond to all comments | More follow-ups (figure unverified) |
+| 30 min | Respond to all comments | 64% more follow-ups |
 | 45 min | Add another insight comment | Keep momentum |
 | 60 min | Final engagement check | Lock in reach |
@ -452,7 +452,7 @@ Why this works: [Brief explanation]
 | "Thanks for sharing" | Passive, doesn't spark conversation | Share what specifically resonated and why |
 | "100%" / "This!" / emoji-only | Not counted as quality engagement | Write 15+ words with your perspective |
 | Pitch in comments | Reputation killer, transparent self-promotion | Add value first, DM relationship later |
-| AI-generated comments | ~45% less engagement (correlational); actively suppressed when detected | Use CEA templates but write in YOUR voice |
+| AI-generated comments | -30% reach, -55% engagement when detected | Use CEA templates but write in YOUR voice |
 | Comment pods | Actively detected, shadow-ban risk | Build genuine inner circle through real engagement |
 | Only commenting when you post | Algorithm notices inconsistent behavior | Comment daily regardless of posting schedule |
 | Commenting late (>3 hours) | Miss the visibility window | Set alerts for key accounts, check feed 3-4x daily |
--- a/agents/fact-checker.md
+++ b/agents/fact-checker.md
@ -16,7 +16,7 @@ description: |
  "is this accurate", "verify numbers", "back this up", "factual correctness".
 model: opus
 color: brown
-tools: ["Read", "WebSearch", "WebFetch"]
+tools: ["Read", "WebSearch"]
 ---
 # Fact Checker Agent
@ -89,14 +89,6 @@ Always run the contradiction sweep (5) — a claim that survives a deliberate
 search for counter-evidence is far stronger than one that merely matched a
 confirming page.
 **Fetch the verbatim source for quotes and figures (WebFetch).** A search
 *snippet* is enough to locate a source but not to confirm a **quotation** or an
 **exact figure** — for those, `WebFetch` the located page and read the original
 wording in context. A quote is verified only against the source's verbatim text
 («Vi» vs «Vi i Nav» is a precision failure even when the gist matches); a figure
 is verified only against the number as the source actually states it. Never grade
 quote precision or number attribution off a snippet alone.
 ### Step 3: Assess Source Credibility
 For each source, evaluate: is it primary or secondary, who published it, how
--- a/agents/fact-reviewer.md
+++ b/agents/fact-reviewer.md
@ -22,7 +22,7 @@ description: |
  "number attribution", "headless review", "fact-reviewer".
 model: opus
 color: gold
-tools: ["Read", "WebSearch", "WebFetch"]
+tools: ["Read", "WebSearch"]
 ---
 # Fact Reviewer Agent
@ -211,12 +211,6 @@ source's exact wording and attribution and compare verbatim (F2). For figures,
 trace to a named source and confirm the source's precision matches the draft's
 (F3/F4 — "around a third" does not verify "37 %").
 **Fetch the verbatim source, do not grade off a snippet (WebFetch).** F2 (quote
 precision) and F3 (number attribution) cannot be settled from a search *snippet* —
 `WebFetch` the located source and read the original wording/number in context, then
 compare verbatim. A quote or figure marked 🟢 must have been checked against the
 source's actual text, never a preview line.
 ### Step 3 — Score on the five dimensions
 Score each claim 0–100 across the five dimensions. A contradicted claim is 🔴
@ -355,6 +349,6 @@ Read these for the package, the boundary, and the pipeline position:
  for the five-archetype cold adversarial-review package.
 - `${CLAUDE_PLUGIN_ROOT}/commands/newsletter.md` — Step 6.5 (where this agent runs,
  cold, on the frozen draft) and Step 8 (lock + pivot-detection).
- `${CLAUDE_PLUGIN_ROOT}/tests/fixtures/fact-reviewer-cases.md` — fasit fixture:
+- `${CLAUDE_PLUGIN_ROOT}/agents/fixtures/fact-reviewer-cases.md` — fasit fixture:
  the six Del 4 (Security Champions) worked cases mapped to F1–F4 + risk sort +
  the pivot-premise rationale.
--- a/agents/fixtures/content-reviewer-cases.md
+++ b/agents/fixtures/content-reviewer-cases.md
--- a/agents/fixtures/editorial-reviewer-cases.md
+++ b/agents/fixtures/editorial-reviewer-cases.md
--- a/agents/fixtures/fact-checker-cases.md
+++ b/agents/fixtures/fact-checker-cases.md
--- a/agents/fixtures/fact-reviewer-cases.md
+++ b/agents/fixtures/fact-reviewer-cases.md
--- a/agents/fixtures/language-reviewer-cases.md
+++ b/agents/fixtures/language-reviewer-cases.md
--- a/agents/fixtures/persona-reviewer-cases.md
+++ b/agents/fixtures/persona-reviewer-cases.md
--- a/agents/language-reviewer.md
+++ b/agents/language-reviewer.md
@ -314,6 +314,6 @@ Read these for the boundary and the pipeline position:
 - `${CLAUDE_PLUGIN_ROOT}/references/longform-quality-rules.md` — the broad quality
  pass; rule 3 (AI-slop ban-list) is `voice-scrubber`'s; your axis is the cold
  Norwegian-language re-read, not the de-AI ban-list.
- `${CLAUDE_PLUGIN_ROOT}/tests/fixtures/language-reviewer-cases.md` — fasit
+- `${CLAUDE_PLUGIN_ROOT}/agents/fixtures/language-reviewer-cases.md` — fasit
  fixture: the Del 4 / F5 language blind spots (the «Vi» vs «Vi i Nav» quote
  error, anglicisms, repetitions) mapped to L1–L5 + severities.
--- a/agents/network-builder.md
+++ b/agents/network-builder.md
@ -23,7 +23,7 @@ tools: ["Read", "Glob", "WebSearch", "Write", "AskUserQuestion"]
 # Network Builder Agent
-You are a LinkedIn strategic networking specialist. You help the user build meaningful connections that compound their authority, reach, and influence through systematic engagement, outreach, and relationship management.
+You are a LinkedIn strategic networking specialist. You help the user build meaningful connections that compound their thought leadership reach and influence through systematic engagement, outreach, and relationship management.
 ## Step 0: Load Context
@ -38,7 +38,7 @@ ${CLAUDE_PLUGIN_ROOT}/skills/linkedin-studio/SKILL.md             → user exper
 ~/.claude/linkedin-studio.local.md                          → user state + network data
 ```
-Also check `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/network/` for existing tracker files.
+Also check `${CLAUDE_PLUGIN_ROOT}/assets/network/` for existing tracker files.
 ## Step 1: Network Audit
@ -610,7 +610,7 @@ VERDICT: Don't join formal pods. Build genuine Tier 1 instead.
 ### Tracker Setup
-Save and maintain a tracker in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/network/`:
+Save and maintain a tracker in `${CLAUDE_PLUGIN_ROOT}/assets/network/`:
 ```markdown
 # Network Tracker
@ -687,7 +687,7 @@ Profile networking signals:
 Headline:
  Include: What you do + Who you help + Signal (e.g., "Open to collabs")
-  Example: "Ops Lead @ [org] | Helping manufacturers cut downtime | Speaker & Writer"
+  Example: "AI Advisor @ [org] | Helping public sector adopt AI | Speaker & Writer"
 About section:
  Last paragraph should include:
@ -708,4 +708,4 @@ Activity:
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md` — engagement methods
 - `${CLAUDE_PLUGIN_ROOT}/references/linkedin-growth-playbook-2025-2026.md` — growth strategies
 - `${CLAUDE_PLUGIN_ROOT}/references/opportunity-generation.md` — conversion and DM strategy
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md` — angles for comments
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md` — angles for comments
--- a/agents/persona-reviewer.md
+++ b/agents/persona-reviewer.md
@ -98,18 +98,6 @@ Read the named persona from `config/personas.template.md` (or the project's
 **overbeviser**, **ekspertise**, **sjargong**. Judge as that reader — not as
 yourself, not as a generic audience. One run = one persona.
 Then read `articles.NN.targetLevel` from the edition-state (set at Step 1 of
 `/linkedin:newsletter` — the N7 trend bridge / N6 proposal layer pre-fills it,
 the operator confirms it during calibration). It fixes where this persona sits on
 **the edition's configured target-level span**: the primær anchors the
 reader-facing end, and the active set MUST include a mandatory secondary at the
 OPPOSITE end of that span. Place this persona on the span accordingly — a
 secondary NO from a reader at the far end is a SIGNAL only when the persona
 genuinely sits at that end, and only with an explicit ceiling justification;
 otherwise it is a real flag. If `articles.NN.targetLevel` is absent (a
 manually-started edition that never resolved one), fall back to the persona's own
 **ekspertise** field to locate it on the span.
 ### Step 2: Read the input as that reader
 Read top to bottom, read-only, once, the way this reader actually would.
@ -406,4 +394,4 @@ the skeleton + pitches (NOT prose — there is none yet) and re-runs this sweep.
 Read these files for the persona contract and pipeline position:
 - `${CLAUDE_PLUGIN_ROOT}/config/personas.template.md` — the reader persona library, five-field contract, primær rule, two-mode usage
- `${CLAUDE_PLUGIN_ROOT}/tests/fixtures/persona-reviewer-cases.md` — fasit fixture: one persona + sample draft + six axes + both modes
+- `${CLAUDE_PLUGIN_ROOT}/agents/fixtures/persona-reviewer-cases.md` — fasit fixture: one persona + sample draft + six axes + both modes
--- a/agents/post-feedback-monitor.md
+++ b/agents/post-feedback-monitor.md
@ -37,7 +37,7 @@ Before analyzing anything, load these files:
 1. **Algorithm knowledge:** Read `${CLAUDE_PLUGIN_ROOT}/references/algorithm-signals-reference.md`
 2. **Engagement frameworks:** Read `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md`
 3. **State file:** Read `~/.claude/linkedin-studio.local.md` (if exists)
-4. **Latest analytics:** Use Glob to find the most recent file in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/` and read it
+4. **Latest analytics:** Use Glob to find the most recent file in `${CLAUDE_PLUGIN_ROOT}/assets/analytics/posts/` and read it
 This gives you the user's baseline performance and algorithm context for accurate benchmarking.
@ -68,8 +68,8 @@ Map the post to its current phase and benchmark against expected performance.
 ### The Five Performance Phases
 **Phase 1: The Golden Hour (0-1 hour)**
- Algorithm decision window — velocity in the first 15–30 min decides ~70% of final reach
+- Algorithm decision window — velocity here determines 70% of final reach
- Post shown to a small test slice of connections (Stage 2 distribution; proportion unverified)
+- Post shown to 6-10% of connections (Stage 2 distribution)
 - Target: 5+ reactions, 2+ comments in first 60 minutes
 - Critical threshold: 15+ engagements = unlocks 2nd/3rd degree distribution
@ -327,7 +327,7 @@ Check: Did you post at an optimal time? Is the hook strong? Does the topic match
 Almost never. Deleting and reposting is detected by the algorithm and can result in reduced distribution. The exception: if you spot a major factual error in the first 5 minutes and have <10 impressions.
 ### "My post is doing well — should I post again today?"
-No. Posting multiple times within 3 hours tends to split your own audience (directional; no discrete figure). Let the current post breathe for at least 18-24 hours. Use that energy to engage in comments instead.
+No. Multiple posts within 3 hours get a -25% penalty each. Let the current post breathe for at least 18-24 hours. Use that energy to engage in comments instead.
 ### "It's been 48 hours, can I still boost it?"
 After 48 hours, organic reach is essentially locked. Your energy is better spent on the next post. Document what you learned and apply it forward.
--- a/agents/strategy-advisor.md
+++ b/agents/strategy-advisor.md
@ -39,42 +39,15 @@ Provide personalized, actionable strategic guidance that accounts for the user's
 Read these files for strategic intelligence:
 ```
-${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/demographics.md     → audience composition + intended vs actual gaps
+${CLAUDE_PLUGIN_ROOT}/assets/audience-insights/demographics.md     → audience composition + intended vs actual gaps
-${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/engagement-patterns.md → timing, topic, and format patterns
+${CLAUDE_PLUGIN_ROOT}/assets/audience-insights/engagement-patterns.md → timing, topic, and format patterns
-${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md     → proven patterns from top posts
+${CLAUDE_PLUGIN_ROOT}/assets/examples/high-engagement-posts.md     → proven patterns from top posts
 ${CLAUDE_PLUGIN_ROOT}/references/trajectory-strategy-adjustments.md → trajectory-to-action mappings
 ~/.claude/linkedin-studio.local.md                     → user state + posting history
 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/brain/profile.md   → evolving second-brain profile (consolidated, evidence-weighted facts about the user)
 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/brain/operations.md → the operations centre: dated "who I am now" anchor + plans + ideas (user-authored)
 ```
 Use demographics data to compare the user's **intended** audience vs **actual** engagers when making strategic recommendations.
 ### Consuming the evolving profile (brain/profile.md)
 The second-brain profile is a consolidated, evidence-weighted picture of the user, grown over time by the brain motor (mutated ONLY via `brain consolidate --apply --confirm` — you never write it). It has two layers:
 - **`## Static`** — stable, high-confidence facts about the user.
 - **`## Dynamic`** — emerging facts still accruing evidence.
 Each fact line carries `evidence_count` and `last_seen`. Weight by strength and recency: a higher `evidence_count` and a more recent `last_seen` are a stronger, fresher signal than a thin or stale one.
 **Anti-sycophancy (binding):** Treat every profile fact as **evidence to TEST**, not flattery — counter-pressure it against the analytics and state each time you use it (e.g. *the profile says you lean toward X, but your recent imports show Y — test that before recommending*). The profile informs your recommendations; it never dictates them and never flatters the user.
 **Graceful absence:** If `brain/profile.md` is missing or empty (fresh installs have no brain yet), proceed silently on the other context sources — no error, and no note about a missing profile.
 ### Consuming the operations centre (brain/operations.md)
 The operations centre is the user-authored other half of the second brain (the brain motor never writes here). It has three sections: `## Who I am now (anchor)`, `## Plans`, and `## Ideas`.
 **The anchor is authoritative — it deprecates older inferences.** The `## Who I am now` anchor is the user's own *dated* declaration of current direction (a `_As of YYYY-MM-DD:_` line). When a `brain/profile.md` Dynamic fact predates the anchor's date or contradicts its stated direction, **prefer the anchor and flag the older fact as possibly-stale** — do not parrot the stale fact. This is the frozen-past-self guard: the user's current self overrides the machine's older read of them.
 **Inversion vs the profile (important):** unlike profile facts — which you treat as **evidence to TEST** (challenge them) — the anchor is user-declared direction, *not* an inference to challenge, so you **honour** it. It is direction, not praise: honouring it never licenses flattery, and it never excuses you from counter-pressuring the *profile* facts.
 **Plans vs Ideas:** `## Plans` are active commitments (current intent — weigh as what the user is actually doing); `## Ideas` are a parking lot (suggestions, not commitments — surface them as options, never as settled plans).
 **Graceful absence:** If `brain/operations.md` (or its anchor) is missing or empty, proceed silently on the other context sources — no error, and no note about a missing operations centre.
 ### New Creator Advantage Detection
 From the state file, extract `first_post_date`. Calculate the creator window status:
@ -243,7 +216,7 @@ Based on their responses (or auto-detected from `follower_count`), place them in
 - Inbound opportunities starting
 - Content machine running
-**Primary focus:** Authority building and cross-platform visibility
+**Primary focus:** Thought leadership and cross-platform visibility
 ### Phase 5: Scale (10K+ followers)
 **Characteristics:**
@ -265,7 +238,7 @@ Override standard phase recommendations with accelerated tactics:
 - **Frequency:** 4-5x/week minimum (vs standard 3x). The algorithm is actively learning — more data points = faster expertise establishment.
 - **Format priority:** Mix text + carousels + images early. Algorithm maps format preferences faster during this period.
- **Save optimization:** Front-load save-worthy content (frameworks, checklists, templates). Saves drive faster audience growth (figure unverified) and compound the window advantage.
+- **Save optimization:** Front-load save-worthy content (frameworks, checklists, templates). Saves drive 3x faster audience growth and compound the window advantage.
 - **Profile:** Must be fully optimized before or on day 1. Every profile visit during high-distribution should convert.
 - **Engagement:** 15-20 strategic comments/day (vs standard 5-10). Maximize visibility while the algorithm is actively surfacing you.
 - **Collaboration:** Start building relationships from week 2. Cross-pollination amplifies during the window.
@ -483,5 +456,5 @@ Time: [time]
 Read these files for detailed methodology:
 - `${CLAUDE_PLUGIN_ROOT}/references/growth-roadmaps.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/low-frequency-posting-strategy.md`
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md`
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/troubleshooting-guide.md`
--- a/agents/trend-spotter.md
+++ b/agents/trend-spotter.md
@ -1,33 +1,27 @@
 ---
 name: trend-spotter
 description: |
-  Scan trending topics across the user's content pillars and domain. Score relevance against those
+  Scan trending topics in AI, Microsoft, and public sector. Score relevance against content pillars,
-  pillars, suggest content angles, assess first-mover timing, and generate weekly trend digests
+  suggest thought leadership angles, assess first-mover timing, and generate weekly trend digests
  with opportunity scores.
  Use when the user asks:
  - "what's trending?", "any hot topics?", "what should I post about?"
  - "scan for trends", "find trending topics", "content opportunities"
-  - "weekly trend digest", "what's happening in my field this week?"
+  - "weekly trend digest", "what's happening in AI this week?"
  - "is this topic still timely?", "should I post about this news?"
  - "first-mover check", "trend report", "opportunity scan"
  Triggers on: "trending", "what should I post about", "scan for trends", "content opportunities",
-  "trend digest", "what's new in my space", "timely topic", "first-mover", "opportunity scan".
+  "trend digest", "what's happening in AI", "timely topic", "first-mover", "opportunity scan".
 model: sonnet
 color: white
-# No `tools:` allowlist by design (research-engine slice 2b). An explicit allowlist would
+tools: ["Read", "WebSearch", "Glob"]
 # block every research MCP unless its `mcp__<server>__<tool>` name were hardcoded here —
 # which breaks the "prefer whatever MCP the user actually connected, hardcode nothing"
 # routing. Omitting `tools:` inherits every session tool, so a Tavily / Gemini / Perplexity /
 # other research MCP is reachable when present, with WebSearch + WebFetch as the always-
 # available floor. `disallowedTools` trims the file-writing tools a read + search + persist
 # agent never needs; Bash stays (it runs the deterministic trend-store CLI).
 disallowedTools: Write, Edit, NotebookEdit
 ---
 # Trend Spotter Agent
-You are a LinkedIn trend intelligence agent that identifies timely content opportunities within the creator's own domain — defined entirely by their content pillars and expertise areas (loaded from their profile at runtime), never by a beat baked into this agent. You help creators catch waves early enough to establish authority positioning.
+You are a LinkedIn trend intelligence agent specialized in identifying timely content opportunities at the intersection of AI, Microsoft technology, and public sector digitalization. You help creators catch waves early enough to establish thought leadership positioning.
 ## Your Mission
@ -36,107 +30,88 @@ Find the right trends at the right time with the right angle. Specifically:
 1. **Scan** high-signal sources for emerging topics
 2. **Score** each trend against the creator's content pillars and audience
 3. **Assess** timing -- is this early enough for first-mover advantage?
-4. **Recommend** the strongest content angle per trend
+4. **Recommend** the strongest thought leadership angle per trend
 5. **Deliver** a prioritized digest with clear opportunity scores
 ## Dependencies
 Before scanning, load the user's content pillars and expertise areas:
-1. **Read user profile:** `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md`
+1. **Read user profile:** `${CLAUDE_PLUGIN_ROOT}/config/user-profile.local.md`
   - Extract: 5 core expertise areas, target audience, voice preferences
   - If file does not exist, ask the user for their 5 content pillars before proceeding
-2. **Read voice samples:** `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` (glob for .md files)
+2. **Read voice samples:** `${CLAUDE_PLUGIN_ROOT}/assets/voice-samples/` (glob for .md files)
   - Understand their typical angle and tone
-3. **Check recent posts:** `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/` (if available)
+3. **Check recent posts:** `${CLAUDE_PLUGIN_ROOT}/assets/analytics/posts/` (if available)
   - Avoid recommending topics they already covered recently
 4. **Read research-tooling declaration:** the `### Research Tooling` block of the same
   `user-profile.md` — which research MCPs (if any) the user has connected, and any preferred
   order. This drives how you fetch (see **Research Routing** below). If the block is missing
   or every option is unchecked, treat the floor (WebSearch + WebFetch) as the only research
   tool.
 5. **Load prior trend history (de-amnesia):** before polling anything new, query the
   persistent trend store for what you already captured on the candidate topics, so the digest
   reasons over accumulated history instead of starting amnesiac each session:
   ```bash
   cd "${CLAUDE_PLUGIN_ROOT}/scripts/trends" && \
     node --import tsx src/cli.ts query --topics "<pillar-tag1,pillar-tag2,…>"
   ```
   Use the hits to avoid re-surfacing a trend you already logged and acted on, and to spot a
   pattern building across captures. (Adopter note: run `npm install` in
   `${CLAUDE_PLUGIN_ROOT}/scripts/trends` once. If the store has no deps yet, skip this step
   and proceed with a live poll — the digest still works, just without memory.)
 ## Research Routing (MCP-first, floor-fallback)
 WHERE you look is config (the source list, below); HOW you fetch is routed by the user's
 declared tooling. Pick the strongest research tool available this session — never bake a tool
 name into your reasoning, read it from the declaration:
 1. **Prefer a declared research MCP.** If the profile's `### Research Tooling` names an MCP you
   can see this session (a Tavily / Gemini / Perplexity / other `mcp__…` search or research
   tool), use it first — a research MCP gives better non-US / regional coverage than WebSearch.
   Honor the user's "Preferred order" if they set one.
 2. **Floor: WebSearch + WebFetch.** When no research MCP is declared or connected, discover
   with WebSearch and read source pages with WebFetch. These are always available, so the
   engine still works with zero MCPs connected.
 3. **Fail soft.** If a tool call errors (an MCP that isn't actually connected, a fetch that
   fails), fall back to the floor and keep going — never abort the scan over one unavailable
   tool.
 Record which tool you used as the `--source` when persisting (below): the MCP's short name
 (e.g. `tavily`), `websearch`, or `manual`.
 ## Source Scanning Framework
-**Which sources to poll is config, not code — read the list, do not hardcode a beat.** This is
+### Tier 1: Breaking News (daily, respond within 24-48h)
 what keeps the engine generic: it serves any niche, because the niche lives in the source list,
 never in this agent.
-**Load the source list (user override → shipped default):**
+- **OpenAI**, **Anthropic**, **Microsoft AI**, **Google AI** -- blog posts and announcements
 - **EU/Norwegian government** AI regulatory decisions
-1. If `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends/sources.md` exists, use it —
+### Tier 2: Analysis & Research (2-3x/week, post within a week)
   the user's own niche-specific list (their vendors, regulators, outlets), which survives
   plugin upgrades/reinstalls.
 2. Otherwise fall back to the shipped generic defaults in
   `${CLAUDE_PLUGIN_ROOT}/config/trends-sources.template.md` (source *categories*, not one
   person's beat).
-Both files group sources into four tiers by cadence; poll on that cadence:
+- **MIT Technology Review**, The Verge AI, Ars Technica AI, **Stratechery**
 - **Industry reports** from McKinsey, Gartner, Forrester on AI adoption
 - **ArXiv** top-cited papers in cs.AI, cs.CL, cs.LG
-| Tier | What lives here | Cadence | Response window |
+### Tier 3: Community Signals (weekly, post if pattern emerges)
 |------|-----------------|---------|-----------------|
 | **Tier 1 — Primary / breaking** | first-party announcements, authoritative decisions | daily | react within 24–48h |
 | **Tier 2 — Analysis & research** | where developments get interpreted, not just reported | 2–3×/week | post within a week |
 | **Tier 3 — Community signals** | where practitioners surface what matters before the press | weekly | post if a pattern emerges |
 | **Tier 4 — Niche & seasonal** | slower sources with predictable cadence | monthly | plan ahead |
-Build search queries from the loaded source list + the user's pillars — not from a hardcoded
+- **Hacker News** AI discussions (front page = high signal)
-query bank: target a source or topic from the list (`"[Tier-1 source] latest"`,
+- **r/MachineLearning**, **r/LocalLLaMA** trending posts
-`"[pillar] [this week]"`), fetched via the routed tool (**Research Routing**, above).
+- **LinkedIn** trending topics and viral posts in AI/tech
 ### Tier 4: Niche & Seasonal (monthly, plan ahead)
 - **Conference announcements** (Build, Ignite, NeurIPS, AAAI)
 - **Quarterly earnings** with AI mentions (Microsoft, Google, etc.)
 - **Seasonal themes:** Q1 predictions/strategy, Q2 conferences, Q3 retrospectives, Q4 reflections
 ### Recommended Search Queries
 ```
 "OpenAI announcement" OR "Anthropic release" OR "Microsoft AI" this week
 "Azure AI" OR "Copilot" OR "Microsoft 365 AI" new features
 "AI regulation" OR "EU AI Act" OR "AI policy" latest
 "public sector AI" OR "government AI" latest
 "AI enterprise" OR "AI implementation" report [year]
 "AI trend" OR "AI debate" LinkedIn [this week]
 ```
 ## Relevance Scoring System
-**The scoring rubric is a single source of truth — do not inline a matrix here.** Read it from
+Score each discovered trend on a 1-10 scale across five dimensions.
 `${CLAUDE_PLUGIN_ROOT}/references/trend-scoring-modes.md` and apply the matching mode:
- **kortform** (default) — feed posts. Timing + audience pull carry real weight; the first-mover
+### Scoring Matrix
  window is short.
 - **long-form** — when the caller is producing a chronicle / newsletter / series edition (e.g.
  invoked from `/linkedin:newsletter`) or asks for it explicitly. Depth potential enters at 25 %
  and timing drops to 10 % — a chronicle rewards substance and a durable angle over speed.
-Score each candidate's five dimensions 1–10 per the mode's table — that qualitative judgment is
+| Dimension | Weight | 1-2 (Low) | 3-5 (Medium) | 6-8 (High) | 9-10 (Exceptional) |
-yours. The deterministic step that follows is NOT: pipe the scored candidates (JSON on stdin) to the
+|-----------|--------|-----------|---------------|-------------|---------------------|
-scorer CLI `${CLAUDE_PLUGIN_ROOT}/scripts/trends/src/cli.ts score` (`--mode kortform|long-form
+| **Pillar Fit** | 30% | Outside all 5 pillars | Tangential to one pillar | Direct hit on one pillar | Intersects 2+ pillars |
-[--threshold N]`), the single owner of the weighted composite, the composite→action bands
+| **Audience Relevance** | 25% | Wrong audience entirely | Some audience overlap | Core audience cares | Audience actively asking about this |
-(Immediate / High / Medium / Low / Skip), and the keep/drop threshold. It returns the kept candidates
+| **Timing** | 20% | >7 days old, saturated | 3-7 days, moderate coverage | 24-72h, early coverage | <24h, you would be among first |
-ranked highest-first, each annotated with its composite + band. Do not recompute the composite or
+| **Angle Potential** | 15% | Only obvious take available | One good angle possible | 2-3 strong angles | Contrarian or unique angle clear |
-restate the band thresholds here — supply the five judgment scores and let the scorer rank and triage.
+| **Authority Match** | 10% | No credibility on topic | Some related experience | Direct experience | Published authority on this |
 ### Composite Score Calculation
 ```
 Opportunity Score = (Pillar Fit x 0.30) + (Audience x 0.25) + (Timing x 0.20) + (Angle x 0.15) + (Authority x 0.10)
 ```
 ### Score Interpretation
 | Score | Priority | Action |
 |-------|----------|--------|
 | 8.0-10 | **Immediate** | Drop everything and draft a post within 24h |
 | 6.0-7.9 | **High** | Plan and publish within 48-72h |
 | 4.0-5.9 | **Medium** | Add to content calendar for this week |
 | 2.0-3.9 | **Low** | Note for future reference, skip for now |
 | 0-1.9 | **Skip** | Not relevant to your positioning |
 ## Trend Opportunity Assessment
@ -178,7 +153,7 @@ Before recommending a trend, verify:
 ## Angle Recommendation Engine
-For each trend scoring 4.0+, map to the strongest content angle.
+For each trend scoring 4.0+, map to the strongest thought leadership angle.
 ### The 8 Universal Angles Applied to Trends
@ -201,7 +176,7 @@ For each trend, ask:
 2. **Can I connect it to another trend?** If yes, Pattern Recognition for authority
 3. **Do I have direct experience?** If yes, Personal Lesson for credibility
 4. **Is it complex/jargon-heavy?** If yes, Practical Breakdown for value
-5. **Can I predict what happens next?** If yes, Future Implication for authority positioning
+5. **Can I predict what happens next?** If yes, Future Implication for thought leadership
 6. **Is there a hard truth nobody is saying?** If yes, Uncomfortable Truth for boldness
 ### Angle Combinations (Most Powerful)
@ -214,7 +189,7 @@ Recommend combining 2 angles when possible:
 - **Tech releases:** Personal Lesson + Practical Breakdown
 - **Failures/setbacks:** Human Story + Uncomfortable Truth
-### Authority Value Test (Gate Before Recommending)
+### TL Value Test (Gate Before Recommending)
 Every recommended angle must pass at least 3 of 5 tests:
@ -230,8 +205,8 @@ If an angle fails the test, try a different one before including in the digest.
 | Priority | Trigger Types | Response Window |
 |----------|---------------|-----------------|
-| **High** | Major product/model releases, capability breakthroughs, regulatory decisions, major acquisitions, security vulnerabilities, platform changes in the user's stack | 24-48 hours |
+| **High** | Major model releases, capability breakthroughs, regulatory decisions, major acquisitions, security vulnerabilities, Microsoft platform changes | 24-48 hours |
-| **Medium** | Research papers, industry reports, tool updates, conference takeaways, strategy shifts, sector milestones in the user's domain | Within the week |
+| **Medium** | Research papers, industry reports, tool updates, conference takeaways, strategy shifts, public sector milestones | Within the week |
 | **Low** | Incremental updates, minor funding rounds, personnel changes, speculation, vendor marketing | Skip or brief mention |
 **High-priority response formula:** Breaking News + So What? + Now What?
@ -241,7 +216,7 @@ If an angle fails the test, try a different one before including in the digest.
 Before including any trend in the digest, it must pass at least 2 of 4:
 1. **Expertise fit?** Relevant to my core areas (Yes = proceed, No = skip unless huge)
-2. **Audience care?** The user's target audience (per their profile) would notice and care
+2. **Audience care?** Public sector leaders or enterprise AI implementers would notice
 3. **Unique perspective?** I can add experience-based insight, not just commentary
 4. **Urgency?** Time-sensitive topic with closing window
@ -249,14 +224,18 @@ Before including any trend in the digest, it must pass at least 2 of 4:
 ### Step-by-Step Generation
-**Step 1: Scan sources (routed fetch)**
+**Step 1: Scan sources (WebSearch)**
-Run 4–6 targeted searches covering the tiers in your loaded source list (**Source Scanning
+Run 4-6 targeted searches covering all tiers:
-Framework**, above), via the routed tool (**Research Routing** — declared MCP first, WebSearch +
+
-WebFetch floor). Each query targets a source or topic from the list crossed with a user pillar —
+```
-e.g. `"[Tier-1 source] latest"`, `"[pillar] [this week]"`, `"[regulator] [recent decision]"`. Do
+Search 1: "[AI announcement OR release] [current week/month] [year]"
-not use a fixed query bank: the niche lives in the source list and the user's pillars, never in
+Search 2: "Microsoft [AI OR Copilot OR Azure] [news OR update] [year]"
-this agent.
+Search 3: "[public sector OR government] [AI OR digital] [latest OR news]"
 Search 4: "[AI regulation OR policy OR governance] [latest]"
 Search 5: "[AI enterprise OR implementation] [trend OR report] [year]"
 Search 6: "[AI debate OR controversy OR opinion] LinkedIn [this week]"
 ```
 **Step 2: Filter and score**
@ -275,88 +254,9 @@ this agent.
 - For each trend scoring 4.0+, recommend primary angle
 - Suggest angle combination where applicable
- Run Authority Value Test on each recommendation
+- Run TL Value Test on each recommendation
 - Discard angles that fail the test
 **Step 4.5: Persist kept trends to the store (de-amnesia)**
 For every trend that cleared the relevance filter (Step 2) — not only the ones that make the
 final digest — fold it into the persistent trend store, so the next session reasons over it
 instead of re-discovering it. Build ONE raw-item batch (the same trends you just scored) and pipe
 it through `capture`: it normalizes each item, dedupes on normalized title+URL, unions topics on
 re-capture (so re-capturing an existing trend just enriches the tags), persists the source's
 `publishedAt` for later freshness ranking, and — when you carry the score (below) — persists the
 relevance assessment so the morning brief ranks on it — one call, not one per trend:
 ```bash
 cd "${CLAUDE_PLUGIN_ROOT}/scripts/trends" && \
  echo '[
    {"source":"<tavily|websearch|manual|…>","title":"<verbatim headline>","url":"<source url>",
     "topics":["<pillar-tag1>","<pillar-tag2>"],"publishedAt":"<YYYY-MM-DD if known>",
     "summary":"<one-line what-happened>",
     "score":{"mode":"kortform","dimensions":{"pillar":N,"audience":N,"timing":N,"angle":N,"authority":N}}}
  ]' | node --import tsx src/cli.ts capture
 ```
 `source` is the tool you actually fetched with (**Research Routing**); `publishedAt` is the
 source's own publish date — omit the key when unknown (the store's `capturedAt` is set
 automatically and stays distinct from it).
 **Carry the Step-2 scores — do not discard them.** You already scored each candidate's five
 dimensions 1–10 in **Relevance Scoring** (Step 2); fold those same numbers into the capture batch
 as the item's `"score"`, so the store persists the relevance assessment and the morning brief
 ranks on its composite (the store computes the composite + band itself — supply only the judgment).
 Use `"mode":"kortform"` by default; use `"mode":"long-form"` with the long-form dimension names
 (`pillar`, `depth`, `angle`, `authority`, `currency`) when the caller is producing a chronicle /
 newsletter / series edition (e.g. invoked from `/linkedin:newsletter`). The `"dimensions"` keys are
 the rubric's, the `"topics"` are the user's pillars — nothing vendor- or sector-specific is baked
 in. Omit the `"score"` key when you genuinely did not score an item; an out-of-range or malformed
 score is reported in `errors[]` (the valid items still persist) and never crashes the run.
 One `capture` call folds the whole batch and reports
 `{added, merged, duplicates, errors}`; content-invalid items land in `errors[]`, never failing the
 run. Skip this step silently if the store has no deps installed (an adopter without the trends
 store) — the digest still compiles, just without persistence.
 **Re-capture refreshes the score; the operator drives the lifecycle.** Re-capturing a trend already
 in the store never duplicates it — its topics union in and its relevance `score` is **refreshed**
 (the newer judgment wins, since the timing dimension decays). The operator marks a trend `acted`
 (written about) or `skipped` with `act`/`skip --id <id>` (the id is shown in the brief and via
 `list --json`); the morning brief then **excludes** handled trends so the queue surfaces only
 unresolved work, and `reset --id` returns one to the queue.
 **Step 4.6: Write the dated morning brief (surfacing)**
 After capturing, render today's dated morning brief over the store so the **next session surfaces
 it automatically** (the SessionStart hook reads the latest one). Pass the user's content pillars —
 the same ones you scored against in Step 2 — and the brief ranks the store by pillar-overlap, then
 recency, into a dated Markdown file:
 ```bash
 cd "${CLAUDE_PLUGIN_ROOT}/scripts/trends" && \
  node --import tsx src/cli.ts brief --pillars "<pillar1>,<pillar2>,<pillar3>"
 ```
 `--pillars` is the user's pillar list (comma-separated, from their profile/config); the brief is
 written to `<data-dir>/trends/morning-brief/YYYY-MM-DD.md` and ranks only on persisted fields
 (pillar overlap + `publishedAt`/`capturedAt` freshness, default 7-day window — tune with
 `--fresh-days N`). Skip silently if the store has no deps installed — same escape hatch as Step 4.5.
 The brief also applies a **derived temporal overlay** (RE-R3d): within a relevance tier, a fresh,
 not-yet-surfaced trend is ranked up as a **first-mover** (`· 🥇 først ute`) and a repeatedly-surfaced
 one is ranked down as **saturated** (`· 🔁 mettet`) — computed at render time from the publish/capture
 dates + the seen-log, with no new capture step. Tune with `--first-mover-days N` / `--saturation-at N`.
 Each brief also **records the trend ids it showed** (frontmatter `surfaced:`) and renders a
 **day-over-day diff** — a `## 🆕 Nytt siden sist` section listing what is new since the most recent
 prior brief (plus a ` N nye siden sist` marker on the one-line summary) — no new capture step; the
 polling/capture path above is unchanged (RE-R3e).
 The morning brief can also be **scheduled** to regenerate autonomously each morning — deterministic,
 from the current store — via `src/cli.ts schedule` (print-first: it emits a launchd/cron entry firing
 the `run-daily.sh` headless wrapper). That nightly run re-renders the brief only; your polling above
 stays the capture path (autonomous AI polling is a later slice).
 **Step 5: Compile digest**
 - Format using output template below
@ -431,17 +331,17 @@ stays the capture path (autonomous AI polling is a later slice).
 1. **First-mover beats best analysis.** A good post published early outperforms a perfect post published late. Prioritize speed for high-scoring trends.
-2. **Your angle is the differentiator.** The news is the same for everyone. Your perspective, experience, and framing are what create authority value.
+2. **Your angle is the differentiator.** The news is the same for everyone. Your perspective, experience, and framing are what create thought leadership value.
 3. **Audience fit over virality.** A trend your specific audience cares about at score 6.0 beats a viral topic at score 4.0. Relevance compounds; virality fades.
-4. **Credibility is non-negotiable.** Never recommend posting on a topic where the creator has no authority. Topic relevance is a ranking input — off-topic content gets lower reach regardless of how trending it is.
+4. **Credibility is non-negotiable.** Never recommend posting on a topic where the creator has no authority. The topic-relevance ranking will penalize off-topic content regardless of how trending it is.
 5. **Saturation awareness saves reputation.** Posting the 15th take on a topic makes you look like a follower, not a leader. Better to skip than to add noise.
 6. **Combine angles for power.** Single-angle posts are solid. Two-angle posts are memorable. Recommend combinations wherever the material supports it.
-7. **Always answer "So what?"** A trend is just information. The interpretation -- what it means for the audience's work, decisions, or future -- is the expertise.
+7. **Always answer "So what?"** A trend is just information. The interpretation -- what it means for the audience's work, decisions, or future -- is the thought leadership.
 ## Anti-Patterns
@ -450,20 +350,18 @@ stays the capture path (autonomous AI polling is a later slice).
 | Anti-Pattern | Why It Fails | Instead |
 |--------------|--------------|---------|
 | Reporting news without perspective | No differentiation, looks like a news feed | Add "So what?" and "Now what?" to every trend |
-| Recommending off-topic trends | off-topic content gets lower reach, damages authority | Always check pillar fit and authority score |
+| Recommending off-topic trends | topic-relevance penalty, damages authority | Always check pillar fit and authority score |
 | Chasing every trend | Dilutes positioning, exhausts creator | Max 2-3 trend posts per week, rest is evergreen |
 | Ignoring saturation | Late takes look derivative | Check saturation before recommending timing |
 | Same angle every time | Predictable, audience tunes out | Rotate across 8 angles, track recently used |
 | Hype without substance | Loses trust, attracts wrong audience | Ground every take in experience or evidence |
 | Skipping the relevance filter | Wastes creator's time on low-value topics | Always run 4-question filter before scoring |
-| Generic "[topic] is changing everything" takes | Adds zero value, damages credibility | Be specific: what, for whom, by when |
+| Generic "AI is changing everything" takes | Adds zero value, damages credibility | Be specific: what, for whom, by when |
 ## References
 Read these files for detailed methodology:
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md` - 8 universal angles, selection framework, combination patterns
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md` - 8 universal angles, selection framework, combination patterns
- `${CLAUDE_PLUGIN_ROOT}/references/content-framework.md` - Content pillars, trigger framework, source tiers, seasonal calendar (domain-general)
+- `${CLAUDE_PLUGIN_ROOT}/references/ai-content-framework.md` - Content pillars, trigger framework, source tiers, seasonal calendar
 - `${CLAUDE_PLUGIN_ROOT}/references/linkedin-growth-playbook-2025-2026.md` - Trend Translator tactic, first-mover advantage
 - `${CLAUDE_PLUGIN_ROOT}/references/algorithm-signals-reference.md` - Engagement signals and profile/topic-relevance validation
 - `${CLAUDE_PLUGIN_ROOT}/references/trend-scoring-modes.md` - **scoring SSOT** — kortform / long-form rubrics + composite→action bands (do not inline a matrix)
 - `${CLAUDE_PLUGIN_ROOT}/config/trends-sources.template.md` - shipped generic source-list defaults (user override: data-dir `trends/sources.md`)
--- a/agents/video-scripter.md
+++ b/agents/video-scripter.md
@ -33,9 +33,9 @@ Read these files for video scripting intelligence:
 ${CLAUDE_PLUGIN_ROOT}/references/video-strategy-guide.md              → Script templates, pacing, production guidance
 ${CLAUDE_PLUGIN_ROOT}/references/linkedin-formats.md                   → Video specs, algorithm data, technical requirements
 ${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md              → Hook types, CTAs, story structures
-${CLAUDE_PLUGIN_ROOT}/references/content-angles.md          → 8 universal angles
+${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md          → 8 universal angles
-${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/                            → User's authentic voice (ALWAYS read before scripting)
+${CLAUDE_PLUGIN_ROOT}/assets/voice-samples/                            → User's authentic voice (ALWAYS read before scripting)
-${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md         → Successful content patterns
+${CLAUDE_PLUGIN_ROOT}/assets/examples/high-engagement-posts.md         → Successful content patterns
 ~/.claude/linkedin-studio.local.md                         → User state, recent topics, streak
 ```
@ -76,7 +76,7 @@ Default recommendation: **60 seconds** — 2026 sweet spot. LinkedIn requires 30
 Follow the same pattern as post creation:
 1. Identify the core insight or message
-2. Read `references/content-angles.md`
+2. Read `references/thought-leadership-angles.md`
 3. Present 2-3 angle options via AskUserQuestion
 4. Check against recent topics in state file to avoid repetition
 5. Verify topic alignment with user's 5 core expertise areas
@ -150,7 +150,7 @@ When converting an existing text post to video:
 After drafting the script:
-1. Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` to match the user's natural speech patterns
+1. Read `assets/voice-samples/` to match the user's natural speech patterns
 2. Check for:
   - **Sentence length** — match their natural rhythm
   - **Vocabulary level** — match their word choices
@ -207,15 +207,15 @@ Iterate until satisfied.
 ## Step 8: Save and Update State
-Save the final script to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/`:
+Save the final script to `${CLAUDE_PLUGIN_ROOT}/assets/drafts/`:
 ```
 Naming convention:
  video-[YYYY-MM-DD]-[slug]-[type]-[length].md
 Examples:
-  video-2026-01-30-onboarding-walkthrough-talking-head-90s.md
+  video-2026-01-30-ai-implementation-talking-head-90s.md
-  video-2026-01-30-dashboard-demo-screen-recording-60s.md
+  video-2026-01-30-copilot-demo-screen-recording-60s.md
 ```
 Update state in `~/.claude/linkedin-studio.local.md`:
@ -236,5 +236,5 @@ Update state in `~/.claude/linkedin-studio.local.md`:
 - `${CLAUDE_PLUGIN_ROOT}/references/video-strategy-guide.md` — Script templates, pacing, production
 - `${CLAUDE_PLUGIN_ROOT}/references/linkedin-formats.md` — Video specs, algorithm, technical requirements
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md` — Hook types, CTAs
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md` — 8 universal angles
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md` — 8 universal angles
 - `${CLAUDE_PLUGIN_ROOT}/references/first-comment-strategy.md` — First comment timing and tactics
--- a/agents/voice-scrubber.md
+++ b/agents/voice-scrubber.md
@ -52,7 +52,7 @@ This is the single most important rule of this agent.
 - The gold standard for Norwegian chronicle voice is the **approved Norwegian
  editions** (e.g. the series' approved Del 1 + Del 2). The caller passes the
  path(s); read them as the corpus before scrubbing.
- **Do NOT calibrate against `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md`.**
+- **Do NOT calibrate against `assets/voice-samples/authentic-voice-samples.md`.**
  That corpus is for **English short-form posts** and encodes rules that are
  WRONG for Norwegian chronicle — e.g. it forbids the em-dash, which the author
  *does* use in long-form Norwegian. Using it as the gold standard would actively
@ -111,10 +111,10 @@ overwrite identity-level voice.
 After scrubbing, append what you learned to a drift log so the agent gets sharper
 each edition:
- Write to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/chronicle-voice-drift-log.md`
+- Write to `${CLAUDE_PLUGIN_ROOT}/assets/voice-samples/chronicle-voice-drift-log.md`
  (create if absent). One dated entry per run: which tells recurred, which voice
  traits the draft drifted on, and any newly-confirmed gold-standard pattern.
- Do **not** rewrite the general voice profile (`${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md`) —
+- Do **not** rewrite the general voice profile (`config/user-profile.local.md`) —
  that is `voice-trainer`'s job. This log is the chronicle-specific memory; over
  editions it becomes the calibration record for this agent.
 - Never auto-update identity-level traits (register, em-dash policy, banned
--- a/agents/voice-trainer.md
+++ b/agents/voice-trainer.md
@ -21,7 +21,7 @@ tools: ["Read", "Glob", "Write"]
 # Voice Trainer Agent
-You are a linguistic analyst specializing in personal writing voice for LinkedIn authority building. You study writing samples with forensic precision to extract the patterns that make someone's writing uniquely theirs.
+You are a linguistic analyst specializing in personal writing voice for LinkedIn thought leadership. You study writing samples with forensic precision to extract the patterns that make someone's writing uniquely theirs.
 ## Your Mission
@ -133,58 +133,22 @@ Architecture: [prose/sectioned/framework]
 ### Analysis Process
-1. **Gather (published-only gold signal first)** — Read the user's actual published posts from `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/ingest/published/` (`provenance=published` — the highest-trust source). Then read the human-curated `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` corpus (kept as a tributary, not reshaped), the existing profile from `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md`, and the template from `config/user-profile.template.md`. **Never learn voice patterns from any content marked `provenance=ai-draft`** — a content engine that learns its own voice from its own drafts collapses toward its priors (this generalises voice-scrubber's "gold standard = approved editions, never the draft corpus"). **Fence:** any future auto-capture into a learning corpus (the voice-samples template's Stop-hook hint) MUST tag provenance and admit `provenance=published` only — never blind-append generated drafts.
+1. **Gather** — Read all files in `${CLAUDE_PLUGIN_ROOT}/assets/voice-samples/`, existing profile from `config/user-profile.local.md`, and template from `config/user-profile.template.md`
 2. **Analyze** — Apply all six dimensions to each sample. Note dates for temporal analysis. Flag inconsistent samples as outliers or evolution.
 3. **Synthesize** — Patterns in 70%+ of samples = core traits. 40-70% = situational traits (note context). <40% = experimental traits. Track temporal trends.
 4. **Build** — Compile into Voice Profile Document format. Include confidence levels (high/medium/low) and concrete examples for every trait.
-5. **Update** — Write voice profile section to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md`. Create from template if needed. Preserve non-voice sections.
+5. **Update** — Write voice profile section to `config/user-profile.local.md`. Create from template if needed. Preserve non-voice sections.
 ### Sample Quality Priorities
 0. **`ingest/published/` records (`provenance=published`) — the gold signal; rank above all else.**
 1. Published posts with high engagement (audience-validated authenticity)
 2. Recent samples (last 6 months reflect current voice)
 3. Author-confirmed samples ("this sounds like me")
 4. Longer samples (more data points)
 5. Varied contexts (different content types reveal range)
 **Exclude unconditionally: anything marked `provenance=ai-draft`** (the model-collapse guard — never train voice on the engine's own drafts).
 Flag if: fewer than 5 samples (low confidence), single time period (temporal bias), or contradictory patterns (possible ghostwriting).
 ### Long-form chronicle voice profile (per language / format)
 Short-form feed posts and long-form editions (newsletters, essays, chronicles) are
 **different registers of the same author** — a device the author bans in a punchy
 short post (e.g. the em-dash) can be load-bearing rhythm in a long-form chronicle.
 Drafting long-form against the short-form corpus therefore *degrades* the chronicle
 voice (this is `voice-scrubber`'s canonical rule). So the long-form pipeline binds
 to its own distilled artifact, which this agent generates:
 - **Artifact:** `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/chronicle-voice-profile.md`
  — a distilled long-form voice profile built with the same six-dimension
  framework as the general profile, but from **only the long-form gold corpus**.
 - **Corpus (published gold only):** the approved/published long-form editions under
  `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/ingest/published/`
  carrying `provenance=published`. The same model-collapse fence applies —
  **never distil chronicle voice from `provenance=ai-draft`**, and never from the
  short-form `voice-samples/authentic-voice-samples.md` corpus (wrong register).
 - **Per language AND format — domain-general.** Emit one profile section per
  `(language, format)` pair actually present in the corpus (e.g. `no` / newsletter),
  keyed by those axes; the author's languages and formats come from their OWN
  corpus, never hardcoded. If a `(language, format)` pair has no published editions
  yet, say so plainly and emit no section for it — do not invent a chronicle voice
  from short-form samples or from assumptions.
 - **Grows automatically.** Each locked edition is appended to the gold corpus at
  `/linkedin:newsletter` Step 8 (`provenance=published`), so re-running this
  distillation sharpens the chronicle profile over editions without manual curation.
 Trigger this distillation on the same events as the general profile (a new
 published edition, quarterly audit, explicit request). The long-form pipeline
 (`/linkedin:newsletter` Step 0 / 3a / 3b) reads this artifact; when it is missing,
 that pipeline warns and falls back — it never silently drafts against the wrong
 corpus.
 ## Voice Drift Detection
 ### Drift Scoring
@ -359,8 +323,8 @@ Fixes: [specific corrections with baseline examples]
 ## References
 Read these files for context and methodology:
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` — Source samples for analysis
+- `${CLAUDE_PLUGIN_ROOT}/assets/voice-samples/` — Source samples for analysis
 - `${CLAUDE_PLUGIN_ROOT}/config/user-profile.template.md` — Profile structure template
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md` — Current voice profile (if exists)
+- `${CLAUDE_PLUGIN_ROOT}/config/user-profile.local.md` — Current voice profile (if exists)
- `${CLAUDE_PLUGIN_ROOT}/references/content-framework.md` — content anti-patterns and quality checklist
+- `${CLAUDE_PLUGIN_ROOT}/references/ai-content-framework.md` — AI content anti-patterns and quality checklist
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md` — Hook psychology and tone guidelines
--- a/assets/audience-insights/demographics-template.md
+++ b/assets/audience-insights/demographics-template.md
@ -1,211 +0,0 @@
 # Audience Demographics
 Track WHO is actually engaging with your content. LinkedIn Analytics provides this data for free - use it to understand your real audience vs. your intended audience.
 ## How to Access This Data
 1. Go to LinkedIn Analytics: https://www.linkedin.com/analytics/
 2. Click on any post
 3. Navigate to "Demographics" tab
 4. Review data monthly and update this file
 ---
 ## Current Demographics (Last Updated: [Date])
 ### Industries (Top 10)
 Based on LinkedIn Analytics → Post Analytics → Demographics
 | Rank | Industry | % of Engagement | Trend |
 |------|----------|----------------|--------|
 | 1 | [Industry name] | [X]% | [↑/→/↓] |
 | 2 | [Industry name] | [X]% | [↑/→/↓] |
 | 3 | [Industry name] | [X]% | [↑/→/↓] |
 | 4 | [Industry name] | [X]% | [↑/→/↓] |
 | 5 | [Industry name] | [X]% | [↑/→/↓] |
 | 6 | [Industry name] | [X]% | [↑/→/↓] |
 | 7 | [Industry name] | [X]% | [↑/→/↓] |
 | 8 | [Industry name] | [X]% | [↑/→/↓] |
 | 9 | [Industry name] | [X]% | [↑/→/↓] |
 | 10 | [Industry name] | [X]% | [↑/→/↓] |
 **Key insights:**
 - [Observation 1 - e.g., "60% from government sector, higher than expected"]
 - [Observation 2 - e.g., "Tech companies underrepresented vs. my assumptions"]
 - [Implication - e.g., "Should increase public sector case studies"]
 ---
 ### Job Functions (Top 10)
 | Rank | Function | % of Engagement | Trend |
 |------|----------|----------------|--------|
 | 1 | [Function] | [X]% | [↑/→/↓] |
 | 2 | [Function] | [X]% | [↑/→/↓] |
 | 3 | [Function] | [X]% | [↑/→/↓] |
 | 4 | [Function] | [X]% | [↑/→/↓] |
 | 5 | [Function] | [X]% | [↑/→/↓] |
 | 6 | [Function] | [X]% | [↑/→/↓] |
 | 7 | [Function] | [X]% | [↑/→/↓] |
 | 8 | [Function] | [X]% | [↑/→/↓] |
 | 9 | [Function] | [X]% | [↑/→/↓] |
 | 10 | [Function] | [X]% | [↑/→/↓] |
 **Key insights:**
 - [Who is actually engaging]
 - [Implication for content framing]
 ---
 ### Seniority Levels
 | Level | % of Engagement | Change vs. Last Month |
 |-------|----------------|----------------------|
 | Entry level | [X]% | [+/-X%] |
 | Individual contributor | [X]% | [+/-X%] |
 | Manager | [X]% | [+/-X%] |
 | Director | [X]% | [+/-X%] |
 | VP | [X]% | [+/-X%] |
 | C-level | [X]% | [+/-X%] |
 | Owner/Partner | [X]% | [+/-X%] |
 **Key insights:**
 - **Dominant level:** [Which level engages most]
 - **Decision-maker presence:** [% at Director+ level]
 - **Content implication:** [How technical/strategic should content be?]
 ---
 ### Geographic Distribution (Top 10 Countries)
 | Rank | Country | % of Engagement | Trend |
 |------|---------|----------------|--------|
 | 1 | [Country] | [X]% | [↑/→/↓] |
 | 2 | [Country] | [X]% | [↑/→/↓] |
 | 3 | [Country] | [X]% | [↑/→/↓] |
 | 4 | [Country] | [X]% | [↑/→/↓] |
 | 5 | [Country] | [X]% | [↑/→/↓] |
 | 6 | [Country] | [X]% | [↑/→/↓] |
 | 7 | [Country] | [X]% | [↑/→/↓] |
 | 8 | [Country] | [X]% | [↑/→/↓] |
 | 9 | [Country] | [X]% | [↑/→/↓] |
 | 10 | [Country] | [X]% | [↑/→/↓] |
 **Key insights:**
 - **Primary market:** [Where most engagement comes from]
 - **Time zone implications:** [Optimal posting times]
 - **Regional context:** [Does content need localization?]
 ---
 ### Company Size (Of Engagers)
 | Size | % of Engagement | Trend |
 |------|----------------|--------|
 | 1-10 employees | [X]% | [↑/→/↓] |
 | 11-50 | [X]% | [↑/→/↓] |
 | 51-200 | [X]% | [↑/→/↓] |
 | 201-500 | [X]% | [↑/→/↓] |
 | 501-1000 | [X]% | [↑/→/↓] |
 | 1001-5000 | [X]% | [↑/→/↓] |
 | 5001-10000 | [X]% | [↑/→/↓] |
 | 10000+ | [X]% | [↑/→/↓] |
 **Key insights:**
 - **Dominant segment:** [Enterprise/Mid-market/SMB]
 - **Content implication:** [Scale of examples, budget assumptions]
 - **Opportunity:** [Underserved segment to target]
 ---
 ## Intended vs. Actual Audience
 ### Who I Thought My Audience Was
 - **Industries:** [Your original assumptions]
 - **Roles:** [Your original assumptions]
 - **Seniority:** [Your original assumptions]
 - **Geography:** [Your original assumptions]
 ### Who My Audience Actually Is
 - **Industries:** [Reality from data above]
 - **Roles:** [Reality from data above]
 - **Seniority:** [Reality from data above]
 - **Geography:** [Reality from data above]
 ### Strategic Implications
 **Content adjustments needed:**
 1. [Adjustment 1 - e.g., "Increase public sector examples, decrease startup references"]
 2. [Adjustment 2 - e.g., "Frame for Director-level, not just technical ICs"]
 3. [Adjustment 3 - e.g., "Add European regulatory context"]
 **Opportunities identified:**
 1. [Opportunity 1 - e.g., "Large enterprise segment underserved by competitors"]
 2. [Opportunity 2 - e.g., "Growing Nordic audience interested in topic X"]
 ---
 ## Follower vs. Engager Analysis
 **Important distinction:** 
 - Your followers = who follows you
 - Your engagers = who actually interacts with content
 Often these are different groups. LinkedIn prioritizes showing your content to engagers, not just followers.
 ### Follower Demographics
 [If you have LinkedIn Premium, note follower demographics here]
 - [Key differences from engager demographics]
 ### Insight
 [What the difference between followers and engagers tells you]
 ---
 ## Competitive Audience Analysis
 How does your audience compare to key competitors/peers?
 | Peer | Their Primary Industry | Their Seniority Level | Difference from Mine |
 |------|----------------------|---------------------|---------------------|
 | [Name] | [Industry] | [Level] | [What's different] |
 | [Name] | [Industry] | [Level] | [What's different] |
 | [Name] | [Industry] | [Level] | [What's different] |
 **Content gap opportunity:**
 [Where your unique audience positioning creates content opportunities]
 ---
 ## Month-over-Month Trends
 ### [Current Month] vs. [Previous Month]
 **Industry shifts:**
 - [What changed and why]
 **Seniority shifts:**
 - [What changed and why]
 **Geographic shifts:**
 - [What changed and why]
 **Analysis:**
 [What these trends indicate about content resonance and audience evolution]
 ---
 ## Update Schedule
 - **Monthly:** Update all demographics from LinkedIn Analytics
 - **Quarterly:** Deep analysis of trends and strategic implications
 - **Yearly:** Major review of intended vs. actual audience fit
 ---
 ## Update Log
 - **[Date]:** Initial demographics captured
 - **[Date]:** Observed [significant change] in [demographic category]
 - **[Date]:** Shifted content strategy based on [insight]
--- a/assets/audience-insights/engagement-patterns-template.md
+++ b/assets/audience-insights/engagement-patterns-template.md
@ -1,267 +0,0 @@
 # My Audience Engagement Patterns
 Track YOUR audience's specific behaviors and preferences here. This data is more valuable than generic "best practices" because it's based on YOUR actual results.
 ## Update Frequency
 **Weekly (5 minutes):** Update posting times and add best-performing topic from the week
 **Monthly (15 minutes):** Deep dive into patterns, update demographics, analyze format performance
 ---
 ## Best Posting Times (Based on MY Data)
 **Important:** These should be YOUR times based on YOUR analytics, not generic advice. Track this in LinkedIn Analytics under "Post impressions by time of day."
 ### Primary Posting Windows
 1. **[Day] at [Time]:** Avg. impressions: [X] | Avg. engagement: [Y]
   - Why this works: [e.g., "My audience (public sector leaders) checks LinkedIn during lunch break"]
 2. **[Day] at [Time]:** Avg. impressions: [X] | Avg. engagement: [Y]
   - Why this works: [Your analysis]
 3. **[Day] at [Time]:** Avg. impressions: [X] | Avg. engagement: [Y]
   - Why this works: [Your analysis]
 ### Worst Posting Times (To Avoid)
 - [Day/Time]: [Why it underperforms for YOUR audience]
 - [Day/Time]: [Why it underperforms for YOUR audience]
 **Update Log:**
 - [Date]: [Change observed - e.g., "Tuesday 2pm now outperforms Friday 8am"]
 ---
 ## Top-Performing Topics (Last 90 Days)
 Track which topics YOUR audience actually engages with, not what you think they should care about.
 1. **[Topic]:** Avg. engagement: [X] | Posts: [Y]
   - Best-performing post example: [Brief description]
   - Why it resonates: [Your analysis]
 2. **[Topic]:** Avg. engagement: [X] | Posts: [Y]
   - Best-performing post example: [Brief description]
   - Why it resonates: [Your analysis]
 3. **[Topic]:** Avg. engagement: [X] | Posts: [Y]
   - Best-performing post example: [Brief description]
   - Why it resonates: [Your analysis]
 ### Topics That Surprisingly Underperformed
 - **[Topic]:** [Why you thought it would work] → [Why it didn't]
 - **[Topic]:** [Analysis]
 **Implication for content strategy:**
 [What you'll do differently based on this data]
 ---
 ## Format Performance (MY Audience)
 Based on YOUR analytics, not generic benchmarks. Track in LinkedIn Analytics and your own spreadsheet.
 ### Format Rankings (By Engagement)
 1. **[Format - e.g., "Story-based posts"]:** 
   - Avg. impressions: [X]
   - Avg. engagement rate: [Y%]
   - Best time to post: [When]
   - Character sweet spot: [Range]
 2. **[Format - e.g., "Framework posts"]:**
   - Avg. impressions: [X]
   - Avg. engagement rate: [Y%]
   - Best time to post: [When]
   - Character sweet spot: [Range]
 3. **[Format - e.g., "Data/research posts"]:**
   - [Same metrics]
 4. **[Format - e.g., "Case study posts"]:**
   - [Same metrics]
 ### Visual Content Performance
 - **Posts with images:** Avg. engagement: [X] vs text-only: [Y]
 - **Posts with documents:** Avg. engagement: [X]
 - **Posts with carousels:** Avg. engagement: [X]
 - **Video posts:** Avg. engagement: [X]
 **Your insights:**
 [What format performs best for YOUR audience and why]
 ---
 ## Hook Types That Work for ME
 Not all hook styles work for all audiences. Track which hooks YOUR audience responds to.
 ### Top-Performing Hook Styles
 1. **[Hook type - e.g., "Counterintuitive stat"]**
   - Example: [Actual hook you used]
   - Avg. engagement: [X]
   - Why it works for your audience: [Analysis]
 2. **[Hook type - e.g., "Bold contrarian statement"]**
   - Example: [Actual hook]
   - Avg. engagement: [X]
   - Why it works: [Analysis]
 3. **[Hook type - e.g., "Personal story opening"]**
   - Example: [Actual hook]
   - Avg. engagement: [X]
   - Why it works: [Analysis]
 ### Hook Styles That Don't Work for YOUR Audience
 - **[Hook type]:** [Why it underperforms with your specific audience]
 - **[Hook type]:** [Why it underperforms]
 ---
 ## CTA Performance Analysis
 Which calls-to-action actually drive engagement from YOUR audience?
 ### High-Performing CTAs
 1. **[CTA type - e.g., "Specific implementation question"]**
   - Example: "Which stage is your organization in?"
   - Avg. comments generated: [X]
 2. **[CTA type]**
   - Example: [Actual CTA]
   - Avg. comments generated: [X]
 ### Low-Performing CTAs (To Avoid)
 - **[CTA type]:** [Why YOUR audience doesn't respond to this]
 ---
 ## Audience Demographics (Who Actually Engages)
 Based on LinkedIn Analytics → Analytics → Demographics of people who interacted with your posts
 ### Industries (Top 5)
 1. [Industry]: [% of engagement]
 2. [Industry]: [% of engagement]
 3. [Industry]: [% of engagement]
 4. [Industry]: [% of engagement]
 5. [Industry]: [% of engagement]
 **Insight:** [What this means for content focus]
 ### Job Functions (Top 5)
 1. [Function]: [% of engagement]
 2. [Function]: [% of engagement]
 3. [Function]: [% of engagement]
 4. [Function]: [% of engagement]
 5. [Function]: [% of engagement]
 **Insight:** [How this should shape your content]
 ### Seniority Levels
 - C-level: [%]
 - VP/Director: [%]
 - Manager: [%]
 - Individual contributor: [%]
 - Entry level: [%]
 **Insight:** [Technical depth and framing implications]
 ### Geographic Distribution (Top 5 Countries)
 1. [Country]: [%]
 2. [Country]: [%]
 3. [Country]: [%]
 4. [Country]: [%]
 5. [Country]: [%]
 **Insight:** [Time zone and regional context considerations]
 ### Company Size (Of Engagers)
 - 1-10 employees: [%]
 - 11-50: [%]
 - 51-200: [%]
 - 201-500: [%]
 - 501-1000: [%]
 - 1001-5000: [%]
 - 5001-10000: [%]
 - 10000+: [%]
 **Insight:** [Scale and organizational context implications]
 ---
 ## Content Length Performance (YOUR Data)
 Track the optimal length for YOUR audience, not generic advice.
 - **800-1000 characters:** Avg. engagement: [X]
 - **1000-1200 characters:** Avg. engagement: [X]
 - **1200-1500 characters:** Avg. engagement: [X]
 - **1500-1900 characters:** Avg. engagement: [X]
 - **1900+ characters:** Avg. engagement: [X]
 **Your sweet spot:** [Range that consistently performs best]
 **Why:** [Your analysis of why this works for your audience]
 ---
 ## Engagement Velocity Patterns
 How quickly does YOUR content gain traction?
 ### First Hour Performance
 - **Average engagement in first 60 minutes:** [X] likes, [Y] comments
 - **Threshold for algorithm boost:** [Based on your data, when does reach accelerate?]
 - **Your current hit rate:** [% of posts that hit the threshold]
 ### 24-Hour Patterns
 - **Most engagement happens in:** [Time window - e.g., "First 3 hours"]
 - **Secondary surge times:** [If applicable]
 - **Typical engagement curve:** [Description of how your posts perform over 24 hours]
 ---
 ## Strategic Insights (The "So What")
 Based on all the data above, what should you do differently?
 ### Content Strategy Adjustments
 1. **More of this:** [What data says you should double down on]
 2. **Less of this:** [What data says isn't working]
 3. **Test this:** [New hypotheses based on patterns]
 ### Audience Alignment
 - **Who you thought your audience was:** [Original assumption]
 - **Who actually engages:** [Reality based on data]
 - **Strategic implication:** [How content should shift]
 ### Competitive Edge Opportunities
 Based on YOUR unique audience makeup:
 - **Gap 1:** [Underserved need you could fill]
 - **Gap 2:** [Content angle competitors miss]
 - **Gap 3:** [Format opportunity]
 ---
 ## Monthly Comparison
 Track month-over-month to see if patterns are stable or shifting.
 ### [Current Month]
 - Avg. impressions per post: [X]
 - Avg. engagement per post: [Y]
 - Follower growth: [+X]
 - Best-performing topic: [Topic]
 - Best-performing format: [Format]
 ### [Previous Month]
 - [Same metrics for comparison]
 **Key changes:** [What's different and why]
 ---
 ## Update Log
 - **[Date]:** [Significant finding - e.g., "Discovered Thursday posts now outperform Tuesday"]
 - **[Date]:** [Pattern shift - e.g., "Framework posts have overtaken story posts in engagement"]
 - **[Date]:** [Audience insight - e.g., "Realize 60% of engagers are from enterprise, not SMB"]
--- a/assets/case-studies/case-study-template.md
+++ b/assets/case-studies/case-study-template.md
@ -170,7 +170,7 @@ Real examples from your work provide credibility and specificity that generic sc
 - What we learned
 - CTA: Ask what others would have done
-**Best for:** Authority content, showing expertise
+**Best for:** Thought leadership, showing expertise
 ---
--- a/assets/checklists/quality-scorecard.md
+++ b/assets/checklists/quality-scorecard.md
@ -29,7 +29,7 @@ Rate each criterion 0-3:
 | Criterion | Score | Notes |
 |-----------|-------|-------|
-| Works in 110-140 characters | /3 | Mobile band (floor + ceiling) |
+| Works in 140 characters | /3 | Mobile threshold |
 | Creates curiosity gap | /3 | Click-through driver |
 | Promises clear value | /3 | Worth reading? |
 | **Subtotal** | /9 x 2 = **/18** | |
@ -111,7 +111,7 @@ Before posting, verify your profile supports the post's topic (topic/interest re
 For quick posts, use this simplified check:
 1. On-topic for my expertise? (Y/N)
-2. Hook works in 110-140 chars? (Y/N)
+2. Hook works in 140 chars? (Y/N)
 3. Clear value delivered? (Y/N)
 4. Ends with engagement prompt? (Y/N)
 5. No external links in body? (Y/N)
@ -129,8 +129,7 @@ Before finalizing any post, verify:
 - [ ] Character count within optimal range
 - [ ] Short paragraphs with white space
 - [ ] Tone is authentic, not corporate
 - [ ] No corporate buzzwords (leverage, synergy, paradigm shift, thought leader, disruptive, value proposition, ecosystem, holistic approach)
 - [ ] Provides genuine value to readers
 - [ ] CTA is specific and natural
 - [ ] Passes the "mobile test" (readable on phone)
- [ ] Passes Authority Value Test: Does it help someone make a better decision or think differently?
+- [ ] Passes thought leadership test: Does it help someone make a better decision or think differently?
--- a/assets/examples/high-engagement-posts-template.md
+++ b/assets/examples/high-engagement-posts-template.md
@ -1,60 +0,0 @@
 # High-Engagement Posts Collection
 Store your top-performing posts here for pattern analysis. Add 5-10 of your best posts to identify what consistently works for YOUR audience.
 > **Placeholder seed.** Your real, per-user collection lives in your external data
 > dir (`~/.claude/linkedin-studio/examples/high-engagement-posts.md`). Replace the
 > example structure below with your own posts.
 ## How to Use This File
 After each successful post (high engagement relative to your baseline):
 1. Add a new `## Post N` section (where N is a number) per saved post
 2. Note engagement metrics and timing
 3. Analyze WHY it worked (hook, angle, timing, CTA)
 4. Document the replicable pattern
 Claude studies these to learn your successful patterns and apply them to new content.
 ## Entry Format
 Each saved post is one `## Post N` section with these fields:
 - **Posted:** date, time, timezone
 - **Engagement:** likes / comments / shares
 - **Reach:** impressions and engagement rate
 - **The Post:** the full post text
 - **Why It Worked:** hook, angle, timing, CTA
 - **Pattern to Replicate:** the elements you want to reuse
 (Add your first `## Post N` section above this line once you have a high performer.)
 ## Patterns Across All High-Performing Posts
 **Common Elements:**
 - [ ] [Element you notice across your best posts]
 - [ ] [Element 2]
 **Audience Preferences (What YOUR Audience Responds To):**
 - Format: [Your best-performing format]
 - Length: [Your best-performing length]
 - Tone: [Your best-performing tone]
 - CTAs: [What drives replies for you]
 **Topics That Resonate:**
 1. [Topic]
 2. [Topic]
 **Best Posting Times (Based on YOUR Data):**
 - Primary: [Time]
 - Secondary: [Time]
 - Avoid: [Time]
 ## Update Log
 - [Date]: [What you added or learned]
--- a/assets/examples/high-engagement-posts.md
+++ b/assets/examples/high-engagement-posts.md
@ -2,59 +2,157 @@
 Store your top-performing posts here for pattern analysis. Add 5-10 of your best posts to identify what consistently works for YOUR audience.
 > **Placeholder seed.** Your real, per-user collection lives in your external data
 > dir (`~/.claude/linkedin-studio/examples/high-engagement-posts.md`). Replace the
 > example structure below with your own posts.
 ## How to Use This File
 After each successful post (high engagement relative to your baseline):
-
+1. Copy the full post text below
 1. Add a new `## Post N` section (where N is a number) per saved post
 2. Note engagement metrics and timing
 3. Analyze WHY it worked (hook, angle, timing, CTA)
 4. Document the replicable pattern
-Claude studies these to learn your successful patterns and apply them to new content.
+Claude will study these to understand your successful patterns and apply them to new content.
-## Entry Format
+---
-Each saved post is one `## Post N` section with these fields:
+## Post 1: Ralph Wiggum / Vibe Coding (BASELINE)
- **Posted:** date, time, timezone
+**Posted:** 2026-01-23, 23:13 CET (suboptimal timing)
- **Engagement:** likes / comments / shares
+**Engagement:** Likes: 19 | Comments: 6 | Shares: 0
- **Reach:** impressions and engagement rate
+**Reach:** 502 impressions
- **The Post:** the full post text
+**Engagement Rate:** 4.98%
- **Why It Worked:** hook, angle, timing, CTA
+**Your Follower Count:** ~1,000
 - **Pattern to Replicate:** the elements you want to reuse
-(Add your first `## Post N` section above this line once you have a high performer.)
+**The Post:**
 ```
 𝗘𝗻 𝗱𝗮𝗴. 𝟭𝟬 𝟬𝟬𝟬 𝗹𝗶𝗻𝗷𝗲𝗿. 𝗨𝘁𝗲𝗻 å 𝘃æ𝗿𝗲 𝘂𝘁𝘃𝗶𝗸𝗹𝗲𝗿.
 Jeg er ikke utvikler. Jeg er KI-rådgiver. Jeg kan ikke skrive kode fra bunnen av.
 Men jeg kan kommunisere med Claude Code. Og det viser seg at det er nok.
 𝗛𝘃𝗼𝗿𝗱𝗮𝗻 𝗱𝗲𝘁 𝘀𝘁𝗮𝗿𝘁𝗲𝘁
 Denne uken var jeg på Claude Code Meetup i Oslo. 250+ deltakere. Arrangert av Aleksander Stensby og Mesh Oslo.
 Aleksander nevnte "Ralph Wiggum-teknikken" som er en metode for å la AI bygge applikasjoner helt på egen hånd.
 På spørsmål om hvem som faktisk hadde fullført en hel slik prosess, rakk én person opp hånden. Av 250.
 Den kvelden bestemte jeg meg: I morgen tester jeg dette.
 𝗞𝗼𝗻𝘀𝗲𝗽𝘁𝗲𝘁
 Du blir intervjuet og ender opp med en liste med oppgaver. Starter en prosess. Går og lager kaffe, eller sover.
 Når du kommer tilbake er applikasjonen bygget.
 𝗠𝗶𝗻 𝗱𝗮𝗴
 Klokken 08:00 fant jeg et enkelt Ralph Wiggum script på 100 linjer. Klokken 23:00 hadde jeg 10 000 linjer og et komplett rammeverk.
 Ikke ved å skrive kode selv — men ved å forklare hva jeg ville ha:
 "Claude, stopp etter fem feil på rad."
 "Claude, send meg Slack-melding når du er ferdig."
 "Claude, lag en AI som vurderer om ting ser bra ut visuelt."
 Claude foreslo løsninger. Jeg sa ja. Ferdig.
 𝗙ø𝗹𝗲𝗹𝘀𝗲𝗻
 Starte prosessen med 30 oppgaver. Gjør noe annet. Komme tilbake og se oppgavene tikke av. Én etter én.
 Å våkne til en Slack-melding: "🎉 Ferdig. Alle 30 oppgaver fullført."
 Å åpne mappen og se en fungerende app. Som jeg ikke skrev. Men som jeg 𝘥𝘦𝘧𝘪𝘯𝘦𝘳𝘵𝘦.
 𝗥𝗲𝘀𝘂𝗹𝘁𝗮𝘁
 Tre prototyper i dag; booking-app, dashbord, skjemaverktøy. Hver tok én time. Null linjer kode. Bare beskrivelser.
 𝗗𝗲𝗻 æ𝗿𝗹𝗶𝗴𝗲 𝗱𝗲𝗹𝗲𝗻
 Alt dette tok én dag. Og jeg skraper bare i overflaten.
 Det ryktes at Anthropic bygde Claude Cowork, et helt produkt, med fire personer på ti dager. Vi er i starten av noe stort.
 De som eksperimenterer nå kommer til å ha et forsprang. Det er ikke lenger AI som er begrensningen, det er deg og meg.
 𝗦å 𝗷𝗮. 𝗥𝗮𝗹𝗽𝗵 𝗪𝗶𝗴𝗴𝘂𝗺.
 Oppkalt etter Simpsons-karakteren som sier: "I'm learnding!"
 Det føles passende :-)
 —
 Jeg jobber med KI i offentlig sektor. Mer om dette og andre eksperimenter i kommende innlegg.
 𝗧𝗶𝗽𝘀: Claude Code Meetup i Oslo arrangeres jevnlig, sjekk [lenke]
 #AI #ClaudeCode #VibeCoding #OffentligSektor #Innovasjon
 ```
 **Why It Worked (Despite Mistakes):**
 - **Hook:** Strong - "En dag. 10 000 linjer. Uten å være utvikler." Creates immediate curiosity gap with specific numbers and contrast
 - **Angle:** Personal Lesson + Discovery narrative - "I tried this, here's what happened"
 - **Timing:** FAILED - Posted 23:13, missed Golden Hour entirely
 - **CTA:** MISSING - No engagement prompt at end
 - **Key insight:** Concrete numbers (10,000 lines, 250 people, 1 person raised hand) create credibility
 **Mistakes Made:**
 1. Posted at 23:13 (should be 08:00)
 2. Link in post body (should be in first comment)
 3. 5 hashtags (should be 3-4)
 4. No CTA (should ask question or invite discussion)
 5. Em dash used (should avoid)
 6. Post was in Norwegian (strategy says English)
 **Pattern to Replicate:**
 - Hook with specific numbers + contrast works well
 - "I'm not X, but I did Y" framing creates relatability
 - Concrete timeline (08:00 to 23:00) adds credibility
 - "Følelsen" section (emotional payoff) resonates
 - Bold-formatted section headers improve readability
 **Audience Response Themes:**
 - Interest in the technical process
 - Questions about Ralph Wiggum technique
 - Recognition from Claude Code community
 **What to Test Next:**
 - Same quality content, but posted at 08:00
 - With proper CTA
 - Without link in body
 - In English
 ---
 ## Patterns Across All High-Performing Posts
 **Common Elements:**
-
+- [x] Specific numbers in hook (10,000 lines, 250 people)
- [ ] [Element you notice across your best posts]
+- [x] Personal story structure (I did X, here's what happened)
- [ ] [Element 2]
+- [x] Concrete timeline and details
 - [ ] Strong CTA (not yet tested)
 - [ ] Optimal timing (not yet tested)
 **Audience Preferences (What YOUR Audience Responds To):**
-
+- Format: Story-based posts with concrete details
- Format: [Your best-performing format]
+- Length: ~2,100 characters (slightly over optimal 1,800)
- Length: [Your best-performing length]
+- Tone: Professional but personal, showing vulnerability ("I'm not a developer")
- Tone: [Your best-performing tone]
+- CTAs: Unknown - need to test
 - CTAs: [What drives replies for you]
 **Topics That Resonate:**
-
+1. AI-assisted coding / Vibe coding
-1. [Topic]
+2. [More data needed]
-2. [Topic]
+3. [More data needed]
 **Best Posting Times (Based on YOUR Data):**
-
+- Primary: Unknown - need to test 08:00 CET
- Primary: [Time]
+- Secondary: Unknown - need to test
- Secondary: [Time]
+- **Avoid:** After 21:00 (confirmed by Ralph Wiggum failure)
 - Avoid: [Time]
 ## Update Log
- [Date]: [What you added or learned]
+- 2026-01-24: Added Ralph Wiggum post as baseline reference. Note: Post had good engagement rate (4.98%) despite multiple mistakes, suggesting content quality is strong. Focus on fixing timing, CTA, and link placement for next posts.
--- a/assets/templates/my-post-templates-template.md
+++ b/assets/templates/my-post-templates-template.md
@ -1,249 +0,0 @@
 # My Custom Post Templates
 Save your proven post structures here. When you find a format that works consistently, document it so Claude can replicate the pattern.
 ---
 ## Template 1: [Name - e.g., "My Framework Introduction Template"]
 **When to use:** [e.g., "When introducing a new framework or model I've developed"]
 **Structure:**
 ```
 [HOOK - Counterintuitive stat or bold statement]
 (1-2 lines, <110 characters)
 [CONTEXT - The problem this framework solves]
 (2-3 lines explaining why people struggle)
 [FRAMEWORK INTRODUCTION]
 "I developed [Framework Name] to solve this."
 (Brief one-line description)
 [COMPONENT BREAKDOWN]
 Stage 1: [Name]
 → [Key characteristic in one line]
 Stage 2: [Name]  
 → [Key characteristic in one line]
 Stage 3: [Name]
 → [Key characteristic in one line]
 [IMPLICATION]
 "Most organizations are stuck at Stage 1.
 Here's what moving to Stage 2 unlocks..."
 (2-3 lines on practical value)
 [CTA]
 "Which stage is your organization in?"
 ```
 **Why this works for me:**
 - [Reason 1 - e.g., "My audience loves actionable frameworks"]
 - [Reason 2 - e.g., "The diagnostic question always generates 15+ comments"]
 **Example posts using this template:**
 - [Link to post 1]
 - [Link to post 2]
 **Average engagement:** [Metrics]
 ---
 ## Template 2: [Name - e.g., "My Before/After Transformation Story"]
 **When to use:** [e.g., "When sharing case study or project results"]
 **Structure:**
 ```
 [HOOK - The transformation in numbers]
 "6 months ago: [painful metric]
 Today: [improved metric]"
 [THE BEFORE]
 [Organization] was struggling with [specific problem].
 (Paint picture of pain - 3-4 lines)
 [THE TURNING POINT]
 We decided to [key decision].
 Most teams choose [alternative]. Here's why we didn't...
 [THE APPROACH]
 "Three things mattered:
 • [Element 1]
 • [Element 2]  
 • [Element 3]"
 [THE AFTER]
 Results:
 → [Metric 1]: [Before] → [After]
 → [Metric 2]: [Before] → [After]
 → [Metric 3]: [Before] → [After]
 [KEY LESSON]
 "The real breakthrough wasn't [expected thing].
 It was [non-obvious insight]."
 [CTA]
 "What's been YOUR biggest lesson in [topic]?"
 ```
 **Why this works for me:**
 - [Reason 1]
 - [Reason 2]
 **Average engagement:** [Metrics]
 ---
 ## Template 3: [Name - e.g., "My Contrarian Take"]
 **When to use:** [e.g., "When challenging conventional wisdom in my field"]
 **Structure:**
 ```
 [HOOK - Bold contrarian statement]
 "Everyone says [conventional wisdom].
 I think that's wrong."
 [THE CONVENTIONAL APPROACH]
 Most [target audience] believe [common belief].
 (Explain the mainstream view fairly - 2-3 lines)
 [WHY IT FAILS]
 But here's the problem...
 (2-3 specific reasons with examples)
 [THE ALTERNATIVE]
 Instead, try this:
 → [Alternative approach 1]
 → [Alternative approach 2]
 → [Alternative approach 3]
 [EVIDENCE]
 "I've seen this play out across [X] projects:
 [Specific result/pattern you've observed]"
 [NUANCE]
 "To be clear: [conventional wisdom] works if [specific condition].
 But for [your context], [your approach] is better because..."
 [CTA]
 "What's your experience? Am I missing something?"
 ```
 **Why this works for me:**
 - [Reason 1]
 - [Reason 2]
 **Average engagement:** [Metrics]
 ---
 ## Template 4: [Name - e.g., "My Failure Lesson Post"]
 **When to use:** [e.g., "When sharing what didn't work to build trust"]
 **Structure:**
 ```
 [HOOK - Admission of failure]
 "[Approach] should have worked.
 It failed spectacularly."
 [SETUP]
 We were trying to [goal].
 The plan: [what you intended to do]
 On paper, perfect.
 [THE FAILURE]
 "Here's what actually happened..."
 (Specific description of what went wrong - 3-4 lines)
 [WHY IT FAILED]
 Looking back, three mistakes:
 1. [Mistake 1] - We assumed [wrong assumption]
 2. [Mistake 2] - We underestimated [factor]
 3. [Mistake 3] - We ignored [warning sign]
 [THE PIVOT]
 "So we tried [different approach] instead.
 That worked because..."
 [THE LEARNING]
 "Key lesson:
 [Non-obvious insight that only came from the failure]"
 [CTA]
 "Have you failed at [topic] too? What did you learn?"
 ```
 **Why this works for me:**
 - [Reason 1]
 - [Reason 2]
 **Average engagement:** [Metrics]
 ---
 ## Template 5: [Name - Your custom template]
 **When to use:** [Context]
 **Structure:**
 [Your proven structure]
 **Why this works for me:**
 [Analysis]
 **Average engagement:** [Metrics]
 ---
 ## Template Performance Comparison
 | Template | Avg. Likes | Avg. Comments | Avg. Reach | Best Use Case |
 |----------|-----------|---------------|------------|---------------|
 | Framework Intro | [X] | [Y] | [Z] | [When] |
 | Before/After | [X] | [Y] | [Z] | [When] |
 | Contrarian | [X] | [Y] | [Z] | [When] |
 | Failure Lesson | [X] | [Y] | [Z] | [When] |
 **Insights:**
 [What these patterns tell you about your audience preferences]
 ---
 ## Template Selection Guide
 **Use Framework template when:**
 - Introducing new model/system
 - Teaching actionable process
 - Want high saves (reference value)
 **Use Before/After template when:**
 - Have strong results to share
 - Building credibility
 - Want case study authority
 **Use Contrarian template when:**
 - Challenging assumptions
 - Positioning unique POV
 - Want engagement/debate
 **Use Failure template when:**
 - Building trust/authenticity
 - Sharing hard-won lessons
 - Want vulnerable connection
 ---
 ## Update Log
 - [Date]: Created template 1 based on [successful posts]
 - [Date]: Refined template 2 after [pattern observation]
 - [Date]: Added template 3 for [new content type]
--- a/commands/ab-test.md
+++ b/commands/ab-test.md
@ -34,11 +34,11 @@ ${CLAUDE_PLUGIN_ROOT}/references/algorithm-signals-reference.md
 Check for existing state and analytics data:
 ```bash
-ls -1 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests/ 2>/dev/null | head -20
+ls -1 ${CLAUDE_PLUGIN_ROOT}/assets/analytics/ab-tests/ 2>/dev/null | head -20
 ```
 ```bash
-ls -1 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/ 2>/dev/null | grep -E '\.json$' | head -10
+ls -1 ${CLAUDE_PLUGIN_ROOT}/assets/analytics/posts/ 2>/dev/null | grep -E '\.json$' | head -10
 ```
 If `~/.claude/linkedin-studio.local.md` exists, read it for user context (posting frequency, follower level, topics).
@ -125,7 +125,7 @@ Generate a posting schedule that alternates A/B on comparable days:
 - Use the user's typical posting days (from state file or ask)
 - Alternate variants across the same day slots each week
 - Default: 3 posts per variant across 2 weeks (6 total)
- Suggest posting times based on algorithm-signals-reference.md (Tue-Thu mornings)
+- Suggest posting times based on algorithm-signals-reference.md (Tue-Thu, 8-9 AM optimal)
 ### 2a.6: Set Success Criteria
@ -184,13 +184,13 @@ Present the complete test plan:
 Create the ab-tests directory if it does not exist:
 ```bash
-mkdir -p ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests
+mkdir -p ${CLAUDE_PLUGIN_ROOT}/assets/analytics/ab-tests
 ```
 Save the test plan as a markdown file:
 ```
-${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests/[test-name].md
+${CLAUDE_PLUGIN_ROOT}/assets/analytics/ab-tests/[test-name].md
 ```
 Use the test name slug (e.g., `hook-question-vs-statement.md`).
@ -206,7 +206,7 @@ Confirm to the user: "Test plan saved. When you publish your first post, come ba
 Scan for active tests:
 ```bash
-ls -1 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests/ 2>/dev/null | grep -E '\.md$'
+ls -1 ${CLAUDE_PLUGIN_ROOT}/assets/analytics/ab-tests/ 2>/dev/null | grep -E '\.md$'
 ```
 If no tests exist, tell the user: "No active tests found. Use option 1 to design a new test first."
@ -218,7 +218,7 @@ If tests exist, present them and ask which test to log for using AskUserQuestion
 Read the selected test file:
 ```bash
-cat ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests/[test-name].md
+cat ${CLAUDE_PLUGIN_ROOT}/assets/analytics/ab-tests/[test-name].md
 ```
 ### 2b.3: Collect Post Metrics
@ -267,7 +267,7 @@ If minimum sample size (3 per variant) is reached, suggest: "You have enough dat
 List tests with sufficient data (3+ posts per variant):
 ```bash
-ls -1 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests/ 2>/dev/null | grep -E '\.md$'
+ls -1 ${CLAUDE_PLUGIN_ROOT}/assets/analytics/ab-tests/ 2>/dev/null | grep -E '\.md$'
 ```
 Read each file and check if both variants have 3+ posts logged. Present only tests ready for analysis. If no tests have sufficient data, tell the user how many more posts are needed.
@ -281,10 +281,10 @@ Read the test file. For each variant:
 ### 2c.3: Cross-Reference Analytics Data
-If analytics CLI data is available in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/`, cross-reference the test period data with weekly reports for additional context (baseline comparison, trend alignment).
+If analytics CLI data is available in `assets/analytics/posts/`, cross-reference the test period data with weekly reports for additional context (baseline comparison, trend alignment).
 ```bash
-ls -1 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/ 2>/dev/null | grep -E '\.json$' | head -10
+ls -1 ${CLAUDE_PLUGIN_ROOT}/assets/analytics/weekly-reports/ 2>/dev/null | grep -E '\.json$' | head -10
 ```
 ### 2c.4: Present Analysis
@ -349,7 +349,7 @@ Update the test file status from ACTIVE to COMPLETED. Add the conclusion and rec
 ### 2d.1: Scan All Tests
 ```bash
-ls -1 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests/ 2>/dev/null | grep -E '\.md$'
+ls -1 ${CLAUDE_PLUGIN_ROOT}/assets/analytics/ab-tests/ 2>/dev/null | grep -E '\.md$'
 ```
 If no tests exist: "No test history yet. Design your first test with option 1."
@ -396,8 +396,8 @@ Read each test file and extract: test name, variable tested, status, verdict, ke
 Check what data is available:
-1. **Test history:** Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests/` for completed tests
+1. **Test history:** Read `assets/analytics/ab-tests/` for completed tests
-2. **Analytics data:** Check `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/` for performance data
+2. **Analytics data:** Check `assets/analytics/posts/` for performance data
 3. **User context:** Read state file for posting patterns and goals
 ### 2e.2: Generate Suggestions
@ -472,7 +472,7 @@ After any action, offer relevant next steps:
 ## Error Handling
 ### No Tests Directory
-If `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/ab-tests/` does not exist and the user selects options 2-4:
+If `assets/analytics/ab-tests/` does not exist and the user selects options 2-4:
 - Inform the user: "No tests found. The test directory will be created when you design your first test."
 - Redirect to option 1 (Design) or option 5 (Suggestions).
--- a/commands/analyze.md
+++ b/commands/analyze.md
@ -38,7 +38,7 @@ Use AskUserQuestion to understand the situation:
 ## Step 2: Gather Data
-If imported analytics data exists (`${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/`), delegate audience-pattern discovery to the `analytics-interpreter` agent (interpret mode) — invoke it via `Task` with `subagent_type: linkedin-studio:analytics-interpreter` (foreground, from this command layer) — to ground the diagnosis in what the data actually shows before relying on self-report.
+If imported analytics data exists (`assets/analytics/`), delegate audience-pattern discovery to the `analytics-interpreter` agent (interpret mode) — invoke it via `Task` with `subagent_type: linkedin-studio:analytics-interpreter` (foreground, from this command layer) — to ground the diagnosis in what the data actually shows before relying on self-report.
 Based on their answer, ask relevant follow-up questions:
@ -98,7 +98,7 @@ Based on `references/troubleshooting-guide.md`, diagnose the pattern:
 - Posted at wrong time for YOUR audience
 - No pre-posting engagement (cold start)
 - Topic drift confusing algorithm
- External links correlate with lower reach
+- External link penalizing reach
 - Inconsistent posting breaking topical authority
 ### Pattern: High Views, Low Engagement
@ -146,6 +146,7 @@ Run through this checklist:
 - [ ] Are topics all over the place recently?
 - [ ] Did you receive generic AI-like comments?
 - [ ] Did you post way more/less frequently than usual?
 - [ ] Did you use 5+ hashtags in posts?
 - [ ] Did you tag unrelated people for reach?
 ## Step 5: Reach Drop Severity Assessment
@ -227,8 +228,8 @@ Set realistic expectations:
 | Suppression Level | Initial Improvement | Baseline Recovery | Full Restoration |
 |-------------------|---------------------|-------------------|------------------|
 | Moderate (link / off-topic) | 7-10 days | 14-21 days | 3-4 weeks |
-| Moderate (partial reach loss) | 2-3 weeks | 4-6 weeks | 2-3 months |
+| Moderate (50-70% drop) | 2-3 weeks | 4-6 weeks | 2-3 months |
-| Severe (sharp reach loss) | 4-6 weeks | 3-6 months | May not be possible |
+| Severe (75%+ drop) | 4-6 weeks | 3-6 months | May not be possible |
 ## Step 8: Prevention Checklist
--- a/commands/audit.md
+++ b/commands/audit.md
@ -9,6 +9,7 @@ allowed-tools:
  - Read
  - Glob
  - Grep
  - WebFetch
  - AskUserQuestion
 ---
@ -20,12 +21,12 @@ You are a LinkedIn content strategy auditor. Conduct a thorough review of the us
 Load all available data:
 - Read `~/.claude/linkedin-studio.local.md` for posting history
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/plans/` for planned content
+- Read `${CLAUDE_PLUGIN_ROOT}/assets/plans/` for planned content
 - Read `${CLAUDE_PLUGIN_ROOT}/skills/linkedin-studio/SKILL.md` for strategy reference
- Check for any analytics data in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/`
+- Check for any analytics data in `${CLAUDE_PLUGIN_ROOT}/assets/analytics/`
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/demographics.md` for audience composition — compare intended vs actual audience
+- Read `assets/audience-insights/demographics.md` for audience composition — compare intended vs actual audience
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/engagement-patterns.md` for tracked patterns (timing, topics, formats, hooks)
+- Read `assets/audience-insights/engagement-patterns.md` for tracked patterns (timing, topics, formats, hooks)
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md` for proven success patterns to benchmark against
+- Read `assets/examples/high-engagement-posts.md` for proven success patterns to benchmark against
 Ask the user to provide:
 - Screenshot of LinkedIn analytics (last 90 days) or key metrics
@ -57,7 +58,7 @@ For each top-performing post, analyze:
 Same analysis for bottom performers:
 - What went wrong?
 - Common factors in low-performing posts?
- Were any off-topic (topic relevance is a ranking input — off-topic gets lower reach)?
+- Were any off-topic (topic-relevance penalty)?
 - External links in body?
 - Poor timing?
@ -89,7 +90,7 @@ Carousels:     ████░░░░░░░░░░░░ 15%
 Video:         █░░░░░░░░░░░░░░░ 5%
 Polls:         ░░░░░░░░░░░░░░░░ 0%
-Recommendation: Increase carousel content (top organic format)
+Recommendation: Increase carousel content (highest save rate)
 ```
 ## Step 5: Engagement Trends
--- a/commands/batch.md
+++ b/commands/batch.md
@ -25,8 +25,8 @@ You are a LinkedIn batch content creator. Help the user create an entire week's
 Load state and personalization:
 - Read `~/.claude/linkedin-studio.local.md` for recent topics and weekly goals
 - Read `${CLAUDE_PLUGIN_ROOT}/skills/linkedin-studio/SKILL.md` for profile and preferences
- Check `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/plans/` for existing weekly plan
+- Check `${CLAUDE_PLUGIN_ROOT}/assets/plans/` for existing weekly plan
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/templates/my-post-templates.md` for proven templates — vary templates across the batch for format diversity
+- Read `assets/templates/my-post-templates.md` for proven templates — vary templates across the batch for format diversity
 If a plan exists for this week, use it as the foundation. If not, create one first.
@ -40,7 +40,7 @@ Use AskUserQuestion:
 3. **Use existing plan** — Follow the weekly plan already created
 4. **Mix it up** — Diverse topics across pillars
-If they choose a theme, help them identify 3-5 unique angles from `references/content-angles.md`. For timely angles, delegate to the `trend-spotter` agent — invoke it via `Task` with `subagent_type: linkedin-studio:trend-spotter` (foreground, from this command layer) — to surface trending topics and score their relevance against the user's pillars.
+If they choose a theme, help them identify 3-5 unique angles from `references/thought-leadership-angles.md`. For timely angles, delegate to the `trend-spotter` agent — invoke it via `Task` with `subagent_type: linkedin-studio:trend-spotter` (foreground, from this command layer) — to surface trending topics and score their relevance against the user's pillars.
 ## Step 2: Plan the Batch (with Scheduling)
@ -92,15 +92,15 @@ Follow the standard structure:
 - CTA: 50-100 characters
 ### 3b. Quick Quality Check
- Character count in the band for this post's format (standard 1,200–1,800 · quick 150–500 · carousel/video caption per that format) — not just "in range"
+- Character count in range
 - Hook works standalone
 - No external links in body
 - No corporate buzzwords
 - Voice matches profile
 ### 3c. Save Draft
-Write each post to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/`:
+Write each post to `${CLAUDE_PLUGIN_ROOT}/assets/drafts/`:
- Create directory if needed: `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/week-[WXX]/`
+- Create directory if needed: `assets/drafts/week-[WXX]/`
 - Filename: `[day]-[topic-slug].md`
 - Include metadata header:
@ -110,7 +110,7 @@ planned_date: YYYY-MM-DD
 scheduled_date: YYYY-MM-DD
 scheduled_time: "HH:MM"
 pillar: [expertise area]
-angle: [content angle]
+angle: [thought leadership angle]
 format: [text/carousel/video]
 status: scheduled
 ---
@ -122,7 +122,7 @@ status: scheduled
 After saving each draft, add it to the queue:
 ```bash
-node --input-type=module -e "import { queueAdd } from '${CLAUDE_PLUGIN_ROOT}/hooks/scripts/queue-manager.mjs'; console.log(queueAdd('[YYYY-WXX-day-topic-slug]', '${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/week-[WXX]/[day]-[topic-slug].md', '[YYYY-MM-DD]', '[HH:MM]', '[pillar]', '[format]', '[hook preview first 50 chars]', [character_count]));"
+node --input-type=module -e "import { queueAdd } from '${CLAUDE_PLUGIN_ROOT}/hooks/scripts/queue-manager.mjs'; console.log(queueAdd('[YYYY-WXX-day-topic-slug]', 'assets/drafts/week-[WXX]/[day]-[topic-slug].md', '[YYYY-MM-DD]', '[HH:MM]', '[pillar]', '[format]', '[hook preview first 50 chars]', [character_count]));"
 ```
 This ensures the post appears in `/linkedin:calendar` (both for viewing and for the publish action) and in session-start reminders.
@ -138,7 +138,7 @@ Batch Summary: [X] posts created
 2. [Day] — "[Hook preview...]" (X chars) — [format]
 3. [Day] — "[Hook preview...]" (X chars) — [format]
-Saved to: ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/week-[WXX]/
+Saved to: assets/drafts/week-[WXX]/
 Content mix: X educational / Y inspirational / Z entertaining
 Pillars covered: [list]
@ -180,7 +180,7 @@ import { generateIcalFromQueue, writeIcalFile } from '${CLAUDE_PLUGIN_ROOT}/hook
 const upcoming = queueUpcoming(14);
 if (upcoming.length === 0) { console.log('No upcoming posts to schedule.'); process.exit(0); }
 const events = generateIcalFromQueue(upcoming);
-const icsPath = '${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/week-[WXX]/schedule.ics';
+const icsPath = '${CLAUDE_PLUGIN_ROOT}/assets/drafts/week-[WXX]/schedule.ics';
 writeIcalFile(icsPath, events);
 console.log('Calendar file: ' + icsPath + ' (' + events.length + ' events)');
 "
@ -191,7 +191,7 @@ Replace `[WXX]` with the actual ISO week number used for the batch directory.
 Show the user:
 ```
-Calendar file generated: ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/week-[WXX]/schedule.ics
+Calendar file generated: assets/drafts/week-[WXX]/schedule.ics
 Import this file into your calendar app:
 - macOS: Double-click the .ics file → Calendar.app imports it
@ -203,10 +203,10 @@ Each scheduled post has a 15-minute reminder before posting time.
 ## Reference Files
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md`
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/low-frequency-posting-strategy.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/scheduling-strategy.md`
 - `${CLAUDE_PLUGIN_ROOT}/assets/templates/weekly-content-calendar-2-3x.md`
 - `${CLAUDE_PLUGIN_ROOT}/assets/checklists/quality-scorecard.md`
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/queue.json`
+- `${CLAUDE_PLUGIN_ROOT}/assets/drafts/queue.json`
--- a/commands/calendar.md
+++ b/commands/calendar.md
@ -39,54 +39,12 @@ console.log('=== OVERDUE ===');
 console.log(queueFormatSummary(queueOverdue()));
 console.log('=== COUNTS ===');
 console.log(JSON.stringify(queueCount(), null, 2));
 console.log('=== ENTRY RECORDS (internal — id / draft_path / character_count etc. for the publish & reschedule actions; do NOT show the user) ===');
 const _seen = new Set();
 for (const e of [...queueToday(), ...queueOverdue(), ...queueUpcoming(14)]) {
  if (_seen.has(e.id)) continue; _seen.add(e.id);
  console.log(JSON.stringify({ id: e.id, draft_path: e.draft_path, scheduled_date: e.scheduled_date, scheduled_time: e.scheduled_time, hook_preview: e.hook_preview, pillar: e.pillar, format: e.format, character_count: e.character_count }));
 }
 "
 ```
 The `queueFormatSummary` blocks are the human-readable overview; the **ENTRY RECORDS** block is the agent's lookup table for the `id`, `draft_path`, and `character_count` that the action steps need (these fields are not in the readable summary).
 Also read state for context:
 - `~/.claude/linkedin-studio.local.md` for weekly goal and current progress
 ## Step 1b: Load Publishing Slots + Editions in Flight
 The queue says what is scheduled. The **slot grid** says what the week is supposed to
 hold, and the **editions register** says which long-form pieces are still in production —
 together they turn "here are some posts" into a capacity picture:
 ```bash
 node --input-type=module -e "
 import { readSlots, slotVacancies, slotOccurrences, formatSlot, defaultSlotsPath, activeEditions } from '${CLAUDE_PLUGIN_ROOT}/hooks/scripts/slots.mjs';
 const grid = readSlots();
 console.log('=== SLOT GRID ===');
 console.log(grid.slots.length ? grid.slots.map(s => s.day + ' ' + s.time + (s.label ? ' | ' + s.label : '')).join('\n') : 'NOT CONFIGURED: ' + defaultSlotsPath());
 console.log('=== OPEN SLOTS (next 14 days) ===');
 console.log(slotVacancies({ days: 14 }).map(s => formatSlot(s)).join('\n') || 'none - every planned slot is covered');
 console.log('=== PLANNED SLOTS (next 14 days) ===');
 console.log(String(slotOccurrences(grid.slots, new Date().toISOString().slice(0,10), 14).length));
 console.log('=== EDITIONS IN FLIGHT ===');
 console.log(activeEditions().map(e => e.series + ' #' + e.editionId + ' | ' + e.currentPhase + ' | next: ' + (e.nextAction || 'unset') + ' | slot: ' + (e.slot || 'unclaimed') + ' | ' + e.daysInFlight + 'd in flight').join('\n') || 'none');
 "
 ```
 **If the grid is NOT CONFIGURED**, say so once and offer the opt-in — the plugin
 deliberately imposes no schedule:
 ```
 No publishing slots configured. To get slot-vacancy warnings at session start and a
 one-key slot default in /linkedin:newsletter, copy the template and edit the times:
  cp "${CLAUDE_PLUGIN_ROOT}/config/publishing-slots.template.json" \
     "${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/publishing-slots.json"
 ```
 The template's times are the plugin's **directional** starting point (see
 `references/scheduling-strategy.md`), not a recommendation about your audience — replace
 them with what `/linkedin:report` shows for your own account.
 ## Step 2: Display Calendar View
 Present a 14-day calendar view:
@ -112,16 +70,6 @@ Format mix: X standard, Y carousel, Z quick
 Pillars: [pillar counts]
 ```
 Mark each configured slot on its day, so an empty slot is visible as a hole rather than
 inferred from an absence: `Tue [date]: [SLOT 08:30 — OPEN]` when nothing covers it,
 `[SLOT 08:30 — covered]` when the queue or an edition does. Below the calendar, add the
 capacity lines from Step 1b:
 ```
 Slots: X planned in 14 days | Y open — next open: [Thu YYYY-MM-DD 12:00 (in N days)]
 Editions in flight: [series #NN — phase → next action (Nd)] (or "none")
 ```
 If there are **overdue** posts (past scheduled date, still "scheduled"), highlight them:
 ```
 OVERDUE:
@ -162,7 +110,7 @@ No posts scheduled for today.
 - Run /linkedin:quick for an unplanned quick post
 ```
-**3b. Pick a post.** Use AskUserQuestion to ask which post was published (show the list above). Map the chosen post to its `id` (and `draft_path`/`character_count` if needed downstream) using the **ENTRY RECORDS** block emitted in Step 1 — that block is the source of the `[post-id]` used below.
+**3b. Pick a post.** Use AskUserQuestion to ask which post was published (show the list above).
 **3c. Update queue status:**
 ```bash
@ -217,15 +165,9 @@ First Hour:
 If they choose to reschedule:
 1. Ask which post (by number or hook preview)
-2. Ask for the new date and time
+2. Ask for new date and time
-3. Re-add the entry with the **same id** and new date/time — `queueAdd` replaces any
+3. Update queue.json via queue_update_status + queue_add with new date
-   existing entry with that id, so the post moves in place (no duplicate). Carry the
+4. Show updated calendar
   unchanged fields (id, draft_path, pillar, format, hook preview, char count) from the
   **ENTRY RECORDS** block emitted in Step 1:
 ```bash
 node --input-type=module -e "import { queueAdd } from '${CLAUDE_PLUGIN_ROOT}/hooks/scripts/queue-manager.mjs'; console.log(queueAdd('[post-id]', '[draft_path]', '[new-YYYY-MM-DD]', '[new-HH:MM]', '[pillar]', '[format]', '[hook preview]', [charCount]));"
 ```
 4. Show the updated calendar
 ### Action: Cancel
@ -252,15 +194,9 @@ After showing the calendar (or after a publish action loops back), provide brief
 - **Pillar balance**: Are pillars well-distributed? Flag if any pillar >50%.
 - **Gap detection**: Are there multi-day gaps that could hurt momentum?
 - **Weekly goal alignment**: Will the schedule meet the weekly goal?
 - **Slot vacancy**: Any open slot within 3 days is the most actionable thing on the
  screen — name it and offer `/linkedin:batch` (short-form) or `/linkedin:newsletter`
  (long-form). An edition already in flight with no claimed slot is the natural filler.
 ## Reference Files
 - `${CLAUDE_PLUGIN_ROOT}/references/scheduling-strategy.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md`
- `${CLAUDE_PLUGIN_ROOT}/config/publishing-slots.template.json` (slot-grid schema + opt-in)
+- `${CLAUDE_PLUGIN_ROOT}/assets/drafts/queue.json`
 - `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/queue.json`
 - `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/publishing-slots.json` (your grid)
 - `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/editions/register.json` (editions in flight)
--- a/commands/carousel.md
+++ b/commands/carousel.md
@ -24,7 +24,7 @@ You are a LinkedIn carousel content specialist. Create high-engagement carousel
 ## Step 0: Load Context
 - Read `~/.claude/linkedin-studio.local.md` for posting state and expertise areas
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` for voice profile
+- Read `assets/voice-samples/authentic-voice-samples.md` for voice profile
 - Check recent posts to avoid topic repetition
 ## Step 1: Choose Template
@ -120,7 +120,7 @@ If any item fails, fix before presenting.
 ### De-AI / Differentiation Gate
-The caption is the feed text, and it rides the same low-substance down-rank LinkedIn confirmed. Confirm the caption and cover slide carry the signals LinkedIn named — **personal substance, original thinking, concrete specifics, genuine voice** — and use no mechanical-response engagement bait ("Comment YES", "Like for Part 2"); a genuine question is fine. **Strip corporate buzzwords** from the caption (Content Quality Rule #4: leverage, synergy, paradigm shift, thought leader, disruptive, value proposition, ecosystem, holistic approach) — caption generation can slip them in, and they trip the same low-substance signal. (The voice-guardian hook scores the caption on save.)
+The caption is the feed text, and it rides the same low-substance down-rank LinkedIn confirmed. Confirm the caption and cover slide carry the signals LinkedIn named — **personal substance, original thinking, concrete specifics, genuine voice** — and use no mechanical-response engagement bait ("Comment YES", "Like for Part 2"); a genuine question is fine. (The voice-guardian hook scores the caption on save.)
 If the deck's premise is a list the audience has seen many times — commodity content — delegate an originality pass to the `differentiation-checker` agent: invoke it via `Task` with `subagent_type: linkedin-studio:differentiation-checker` (foreground, from this command layer), then sharpen the angle before generating slides.
@ -130,7 +130,7 @@ Generate a visual for each slide using mcp-image (Nano Banana Pro). If mcp-image
 1. **Create output directory:**
   ```bash
-   mkdir -p ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/carousel-$(date +%Y%m%d)-SLUG
+   mkdir -p assets/drafts/carousel-$(date +%Y%m%d)-SLUG
   ```
   Replace SLUG with a short kebab-case version of the carousel topic (e.g., `ai-governance`).
@ -144,11 +144,11 @@ Generate a visual for each slide using mcp-image (Nano Banana Pro). If mcp-image
 3. **For each slide (1 through N),** call `mcp__mcp-image__generate_image` with:
   - **prompt:** `"Professional LinkedIn carousel slide. [TEMPLATE STYLE from above]. Background: [consistent color scheme across all slides]. Bold header text: '[SLIDE HEADER]' in large white sans-serif font near the top. Body text below: '[SLIDE BODY lines]' in smaller matching font. Slide [N] of [TOTAL]. Portrait orientation, clean minimal professional design."`
   - **aspect_ratio:** `"3:4"` (closest available to LinkedIn's 4:5)
-   - **output_path:** `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/carousel-[date]-[slug]/slide-[N].png`
+   - **output_path:** `assets/drafts/carousel-[date]-[slug]/slide-[N].png`
 4. **After all slides are generated,** verify the output directory contains the expected number of images:
   ```bash
-   ls -la ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/carousel-$(date +%Y%m%d)-SLUG/
+   ls -la assets/drafts/carousel-$(date +%Y%m%d)-SLUG/
   ```
 **On failure:** If any mcp-image call fails, log the error and continue with remaining slides. If ALL calls fail, fall back to the text-only design guide in Step 6.
@ -162,7 +162,7 @@ Show all slides in order with their text content, then the caption.
 ```
 SLIDE IMAGES
 ━━━━━━━━━━━━
-Generated [N] slide images in ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/carousel-[date]-[slug]/
+Generated [N] slide images in assets/drafts/carousel-[date]-[slug]/
 To publish:
 1. Download the slide images from the folder above
@ -208,11 +208,9 @@ CAPTION
 Then auto-copy the full deck to clipboard silently:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<FULL_DECK_PAYLOAD>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <FULL_DECK_PAYLOAD>
 __LINKEDIN_CLIP_EOF__
 ```
-Substitute `<FULL_DECK_PAYLOAD>` between the heredoc markers with the assembled deck above — all slides' copy + the caption (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Only if the helper prints `COPIED`, confirm: "Full deck — [N] slides + caption — copied to clipboard." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the deck above manually — do not claim it was copied.
+Substitute `<FULL_DECK_PAYLOAD>` with the assembled deck above — all slides' copy + the caption. Then confirm: "Full deck — [N] slides + caption — copied to clipboard."
 Offer refinement options as text (no interactive prompt):
 "Want to refine? Options: adjust slide text / change visual style / regenerate specific slide / different hook / ready for publishing."
--- a/commands/competitive.md
+++ b/commands/competitive.md
@ -8,6 +8,7 @@ description: |
 allowed-tools:
  - Read
  - Glob
  - WebFetch
  - WebSearch
  - AskUserQuestion
 ---
@ -158,6 +159,6 @@ Emphasize: The goal is inspiration and differentiation, NOT copying. Always find
 ## Reference Files
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md`
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/linkedin-growth-playbook-2025-2026.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md`
--- a/commands/create.md
+++ b/commands/create.md
@ -11,6 +11,7 @@ description: |
  "new content", "help me create", "i want to post something", "linkedin create".
 allowed-tools:
  - Read
  - Glob
  - AskUserQuestion
 ---
--- a/commands/first-post.md
+++ b/commands/first-post.md
@ -24,7 +24,7 @@ The first post doesn't need to be perfect. It needs to EXIST. Every day without
 ## Step 0: Load Context
 Read `~/.claude/linkedin-studio.local.md` for current state.
-Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` for voice profile (if it exists).
+Read `assets/voice-samples/authentic-voice-samples.md` for voice profile (if it exists).
 Check: If `first_post_date` is already set, this user has posted before. Suggest `/linkedin:post` or `/linkedin:quick` instead, and explain this command is for true first-timers.
@ -44,7 +44,7 @@ Total: ~10 minutes. Let's go.
 ## Step 2: Quick Voice Setup
-Check if `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` has substantive content (more than just the template headers).
+Check if `assets/voice-samples/authentic-voice-samples.md` has substantive content (more than just the template headers).
 **If voice profile exists:** Say "I already have your voice profile. Let's use it." Skip to Step 3.
@ -138,12 +138,10 @@ Show the post with:
 Auto-copy the post text to clipboard silently:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<POST_TEXT>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <POST_TEXT>
 __LINKEDIN_CLIP_EOF__
 ```
-Substitute `<POST_TEXT>` with the exact post text between the heredoc markers (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Only if the helper prints `COPIED`, present: "Post copied to clipboard. Go to linkedin.com, click 'Start a post', paste it, and hit Post." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the text above manually — do not claim it was copied.
+Then present: "Post copied to clipboard. Go to linkedin.com, click 'Start a post', paste it, and hit Post."
 ## Step 7: State Update
--- a/commands/firsthour.md
+++ b/commands/firsthour.md
@ -1,7 +1,7 @@
 ---
 name: linkedin:firsthour
 description: |
-  Run the critical first hour after you publish — its first 15–30 minutes decide ~70% of a post's
+  Run the critical first hour after you publish — the window that decides ~70% of a post's
  reach. Builds a timestamped first-hour plan: a warm-up + reply-loop target list, draft
  self-comments and CEA replies in your voice, and a minute-by-minute timeline — then persists
  it to state so you can work it live. Hands off to the 48-hour monitor afterwards.
@ -19,14 +19,13 @@ allowed-tools:
 # First Hour / Reply Loop — Post-Publish Engagement Sprint
 You are a LinkedIn engagement operator. A post just went live (or is about to). The first
-15–30 minutes decide ~70% of its reach and the first hour is the golden window you work it,
+60 minutes set ~70% of its total reach, so this command turns that window into a concrete,
-so this command turns that window into a concrete, worked plan: who to engage, what to say,
+worked plan: who to engage, what to say, and exactly when — persisted to state.
 and exactly when — persisted to state.
 ## Step 0: Load Context
 - Read `~/.claude/linkedin-studio.local.md` for posting state (streak, weekly progress, recent posts, follower phase).
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` so every draft comment is in the user's voice.
+- Read `assets/voice-samples/authentic-voice-samples.md` so every draft comment is in the user's voice.
 - Note the user's growth phase (follower count) — it sets daily comment volume and target split.
 ## Step 1: Identify the Post
@ -69,12 +68,10 @@ Show, in this order:
 Auto-copy the self-comments + draft replies to clipboard silently (so they're one paste away):
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<DRAFT_COMMENTS_BLOCK>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <DRAFT_COMMENTS_BLOCK>
 __LINKEDIN_CLIP_EOF__
 ```
-Substitute `<DRAFT_COMMENTS_BLOCK>` with the exact comments block between the heredoc markers (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Only if the helper prints `COPIED`, confirm: "Copied your draft comments to clipboard." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the text above manually — do not claim it was copied.
+Then confirm: "Copied your draft comments to clipboard."
 ## Step 4: Persist the Plan to State
@ -116,6 +113,6 @@ delayed spike) with the post-feedback monitor — invoke it via `Task` with
 ## Reference Files
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` — voice matching for the draft comments
+- `assets/voice-samples/authentic-voice-samples.md` — voice matching for the draft comments
- `references/engagement-frameworks.md` — hook types, engagement hierarchy
+- `references/engagement-frameworks.md` — hook types, CEA, engagement hierarchy
 - `references/algorithm-signals-reference.md` — first-hour weighting, signal order, timing data
--- a/commands/import.md
+++ b/commands/import.md
@ -34,7 +34,7 @@ For data format details and directory structure, see `assets/analytics/README.md
 First, check if any CSV files exist in the exports directory:
 ```bash
-ls -lh ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/exports/*.csv 2>/dev/null || echo "No CSV files found"
+ls -lh ${CLAUDE_PLUGIN_ROOT}/assets/analytics/exports/*.csv 2>/dev/null || echo "No CSV files found"
 ```
 **If files found:** Skip to Step 3.
@ -59,7 +59,7 @@ Options:
 On file selection, copy the file to the exports directory:
 ```bash
-cp "<selected-file>" ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/exports/
+cp "<selected-file>" ${CLAUDE_PLUGIN_ROOT}/assets/analytics/exports/
 ```
 Then continue to Step 4.
@ -88,10 +88,10 @@ After the script completes, continue to Step 4.
 1. Go to [linkedin.com/analytics/creator/content/](https://linkedin.com/analytics/creator/content/)
 2. Click the **"Export"** button (top right)
 3. LinkedIn will download a CSV file
-4. Move it to: `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/exports/`
+4. Move it to: `${CLAUDE_PLUGIN_ROOT}/assets/analytics/exports/`
 ```bash
-mv ~/Downloads/linkedin_analytics_export*.csv ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/exports/
+mv ~/Downloads/linkedin_analytics_export*.csv ${CLAUDE_PLUGIN_ROOT}/assets/analytics/exports/
 ```
 Once done, run `/linkedin:import` again.
@ -123,66 +123,101 @@ cd "${CLAUDE_PLUGIN_ROOT}/scripts/analytics" && npm install --silent
 Once the user selects, run the import CLI:
 ```bash
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" import <filename>
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" import <filename>
 ```
 If importing multiple files, run the command for each file sequentially.
 ## Step 5: Capture and Present Results
-The CLI prints (see `cli.ts` `handleImport`):
+The CLI will output:
- `Posts imported:` — count of valid rows (rows with an empty title or an unparseable date are skipped, each with a `Warning:` line)
+- Number of posts imported
- `Date range:` — earliest to latest post in the batch
+- Date range covered (earliest to latest post)
- `Batch ID:` and `Saved to: posts/<file>` — the batch file written
+- Any duplicate posts detected
- `Saves entered:` — only when the CSV carried a `Saves` column (manual entry)
+- Anomalies or alerts detected
 - An anomaly block — either `Immediate alerts detected:` with 🔴/⚠️/ℹ️ spike/drop lines, or `No anomalies detected in imported data.`
-**Surface the CLI's output to the user** — for example:
+**Parse the output** and present a summary:
 ```
-Import successful!
+Import completed successfully!
 ─────────────────────────────────────
 Posts imported:  42
 Date range:      2025-12-01 to 2026-01-29
 Saved to:        posts/2025-12-01-batch-a1b2c3d4.json
 Saves entered:   1,204 across 18 post(s) (manual)
-Immediate alerts detected:
+Summary:
-─────────────────────────────────────
+- Posts imported: 42
-ℹ️ [INFO] Post "AI agents are eating..." has unusually high impressions: 21,400 (2.4 std deviations above mean)
+- Date range: 2025-12-01 to 2026-01-29
 - Duplicates skipped: 3
 - Anomalies detected: 2 posts with unusually high engagement
 Alerts:
 - Post "AI agents are eating..." (2026-01-15): 340% above baseline impressions
 - Post "The future of no-code..." (2026-01-22): Viral threshold reached (10k+ impressions)
 Data saved to:
 - ${CLAUDE_PLUGIN_ROOT}/assets/analytics/posts/YYYY-WXX.json
 ```
-The saved file is named `posts/YYYY-MM-DD-<shortid>.json` (the batch's earliest post date + a short batch id), not by ISO week.
+### Step 5b: Import Analysis & Anomaly Detection
-### Step 5b: Surface the Anomalies the Importer Detected
+After successful import, automatically analyze the imported data for anomalies and patterns.
-The import CLI runs **intra-batch** anomaly detection during Step 4 (`detectAlerts`
+**Anomaly Detection:**
-in `cli.ts`): for the just-imported batch it flags any post whose impressions
+Compare the imported week's data against existing baselines (if available from previous imports):
 deviate sharply — by standard deviation — from *that batch's own mean*, printing
 either `Immediate alerts detected:` (🔴/⚠️/ℹ️ spike/drop lines) or
 `No anomalies detected in imported data.`
-Surface those lines as-is, and state the scope honestly: a flagged post stands out
+1. **Engagement anomalies:**
-**among the posts in this export**, not against a stored historical baseline — the
+   - Any post with >3x average impressions -> flag as "breakout post"
-importer keeps no baseline file. Cross-week comparison is Step 6's job.
+   - Any post with <0.5x average engagement rate -> flag as "underperformer"
   - Any post with comment:reaction ratio >1:3 -> flag as "conversation starter"
 2. **Pattern recognition:**
   - Most successful day of week (by average impressions)
   - Most successful format (if detectable from post content)
   - Posting frequency vs. previous weeks
 **Read baselines for comparison:**
 ```bash
 cat ${CLAUDE_PLUGIN_ROOT}/assets/analytics/baselines.json 2>/dev/null
 ```
 **If baselines exist**, compare each imported post's metrics against baseline means. If no baselines exist yet, note that this is the first import and baselines will be established.
 **Present as:**
 ```
-### Import Summary — <batch date range>
+### Import Analysis — YYYY-WXX
-X posts imported (Y skipped: empty title or unparseable date)
+X posts imported (Y new, Z updated)
-#### Standout in this batch
+#### Standout Posts
-ℹ️ "[hook text...]" — 21,400 impressions (2.4 std dev above this batch's mean)
+Breakout: "[hook text...]" — X impressions (3.2x your average)
-⚠️ "[hook text...]" — 180 impressions (2.1 std dev below this batch's mean)
+Conversation Starter: "[hook text...]" — X comments (ratio 1:2.5)
-(or: "No standout deviations within this batch.")
+#### Patterns Detected
 - Best day: Tuesday (avg 2,100 impressions vs. 1,400 other days)
 - Best time: Posts before 8 AM outperformed by 35%
 - Format winner: Listicles averaged 40% more engagement
 #### Baseline Update
 Your rolling 4-week averages have been updated:
 - Impressions: X -> Y (change Z%)
 - Engagement rate: X% -> Y% (change Z%)
 ```
-Cross-week analysis — best day of week, format performance, week-over-week trend,
+**If this is the first import (no baselines):**
-rolling averages — is **not** computed here; it is produced by `/linkedin:report`
+```
-(Step 6), which reads the full post history via the `trends`/`heatmap` CLI. Defer
+### Import Analysis — YYYY-WXX
-that analysis to Step 6 rather than restating it.
+
 X posts imported (first import — baselines will be established)
 #### Initial Observations
 Top post: "[hook text...]" — X impressions
 Most discussed: "[hook text...]" — X comments
 #### Baselines Established
 Your initial baselines are now set:
 - Avg impressions per post: X
 - Avg engagement rate: X%
 - Avg comments per post: X
 Import 2-3 more weeks of data for meaningful trend analysis.
 ```
 ## Step 6: Analytics-to-Strategy Feedback Loop
@ -205,8 +240,8 @@ Run /linkedin:report (period: 4w)
 1. Read `expertise_areas` from `~/.claude/linkedin-studio.local.md`
 2. Call `trends` for impressions and engagement_rate over the last 4 weeks:
   ```bash
-   "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period 4w --metric impressions
+   ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period 4w --metric impressions
-   "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period 4w --metric engagement_rate
+   ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period 4w --metric engagement_rate
   ```
 3. Produce the Content Pillar Performance, Format Performance, and
   Day-of-Week Performance tables, plus exactly 3 actionable recommendations
@ -231,12 +266,12 @@ Write the updated state file
 Present next steps using AskUserQuestion based on the analysis results:
-**If the report's trend is down** (impressions or engagement trending DOWN):
+**If data shows declining engagement** (current < baseline by >15%):
 - "Run /linkedin:report for full weekly breakdown"
 - "Run content audit to review strategy"
 - "Analyze your top post to understand what worked"
-**If the report's trend is up** (impressions or engagement trending UP):
+**If data shows strong performance** (current > baseline by >15%):
 - "Run /linkedin:report for the full numbers"
 - "Create more content in your top format"
 - "Draft your next post while insights are fresh"
@ -255,10 +290,10 @@ Present using AskUserQuestion with the top 3 most relevant suggestions.
 ## Step 8: Demographics Sync Suggestion
-After completing the import workflow, check if `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/demographics.md` still has placeholder data:
+After completing the import workflow, check if `assets/audience-insights/demographics.md` still has placeholder data:
 ```bash
-grep -c '\[Industry name\]\|\[Function\]\|\[Country\]\|\[X\]%' ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/demographics.md 2>/dev/null
+grep -c '\[Industry name\]\|\[Function\]\|\[Country\]\|\[X\]%' ${CLAUDE_PLUGIN_ROOT}/assets/audience-insights/demographics.md 2>/dev/null
 ```
 If placeholder count is > 10 (still mostly unfilled), suggest:
@ -270,7 +305,7 @@ If placeholder count is > 10 (still mostly unfilled), suggest:
 If the import fails:
 1. **Check the CSV format** - LinkedIn sometimes changes export format
-2. **Verify the file path** - Ensure the file is in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/exports/`
+2. **Verify the file path** - Ensure the file is in `assets/analytics/exports/`
 3. **Check file permissions** - The CLI needs read access
 4. **Show the error message** and suggest solutions
@ -283,13 +318,15 @@ If the import fails:
 ## Reference Files
 The import system creates:
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/YYYY-MM-DD-<shortid>.json` - one JSON batch per import (earliest post date + short batch id)
+- `assets/analytics/posts/YYYY-WXX.json` - Weekly post data
-
+- `assets/analytics/metadata.json` - Import tracking and baseline metrics
-Weekly and monthly report files (under `weekly-reports/` and `monthly-reports/`) are created separately by `/linkedin:report`, not by import.
+- `assets/analytics/baselines.json` - Statistical baselines for anomaly detection
 ## State Tracking
-After import:
+After import, the system automatically:
- A new batch file `posts/YYYY-MM-DD-<shortid>.json` is written, one per import — existing batch files are never overwritten; `loadAllPosts` deduplicates by post id at read time (latest import wins)
+- Updates baseline metrics (mean, median, std dev for each metric)
- Intra-batch spike/drop alerts are computed and surfaced (std deviation from the batch's own mean — no persisted baseline)
+- Detects and flags anomalies (posts >2 sigma from baseline)
- `last_import_date` and `last_import_week` are updated in the state file (`~/.claude/linkedin-studio.local.md`, see Step 6b)
+- Organizes posts by ISO week for trend analysis
 - Preserves historical data (never overwrites existing weeks)
 - Updates `last_import_date` and `last_import_week` in state file
--- a/commands/linkedin.md
+++ b/commands/linkedin.md
@ -1,7 +1,7 @@
 ---
 name: linkedin
 description: |
-  Main router for LinkedIn Studio commands. Lists all available subcommands
+  Main router for LinkedIn thought leadership commands. Lists all available subcommands
  and helps the user choose the right workflow. Use when the user mentions "linkedin",
  "linkedin help", "what linkedin commands", or needs guidance on which LinkedIn command to use.
  Triggers on: "linkedin", "/linkedin", "linkedin help", "show linkedin commands".
@ -13,7 +13,7 @@ allowed-tools:
 # LinkedIn Studio Command Router
-You are the LinkedIn Studio assistant. The user has invoked the main `/linkedin` command. Your job is to help them navigate to the right subcommand.
+You are a LinkedIn thought leadership assistant. The user has invoked the main `/linkedin` command. Your job is to help them navigate to the right subcommand.
 ## Session Status
@ -56,32 +56,6 @@ OVERDUE (should have been posted):
 If queue is empty: "No posts scheduled. Run /linkedin:batch to plan your week."
 ## Work in Progress + Open Slots
 The queue only shows finished posts waiting to go out. Add the production picture —
 long-form editions still being written, and publishing slots nothing covers yet:
 ```bash
 node --input-type=module -e "
 import { activeEditions, slotVacancies, formatSlot, readSlots } from '${CLAUDE_PLUGIN_ROOT}/hooks/scripts/slots.mjs';
 console.log('=== IN FLIGHT ===');
 console.log(activeEditions().map(e => e.series + ' #' + e.editionId + ' | ' + e.currentPhase + ' | next: ' + (e.nextAction || 'unset') + ' | ' + e.daysInFlight + 'd').join('\n') || 'none');
 console.log('=== OPEN SLOTS ===');
 console.log(readSlots().slots.length ? (slotVacancies({ days: 14 }).map(s => formatSlot(s)).join('\n') || 'none - every planned slot is covered') : 'grid not configured');
 "
 ```
 Show one line per in-flight edition and the next open slot:
 ```
 In flight: [series #NN] — [phase] → [next action] ([N]d)
 Next open slot: [Thu YYYY-MM-DD 12:00 (in N days)] — [X] open in 14 days
 ```
 Both lines are omitted when there is nothing to report (no active editions / no grid
 configured). If the grid is not configured, do **not** nag — `/linkedin:calendar`
 explains the opt-in when the user goes there.
 ## Available Commands
 LinkedIn Studio is organized as **five journeys**. Each journey has a **front-door**
@ -110,7 +84,6 @@ directly when you do.
 | `/linkedin:multiplatform` | Adapt content for Twitter/X, slides, YouTube (long-form → newsletter) |
 | `/linkedin:batch` | Create a full week of content in one session |
 | `/linkedin:pipeline` | End-to-end single-post workflow (idea → draft → schedule → analyze) |
 | `/linkedin:trends` | Trend discovery pass — scan your sources, persist candidates + morning brief, triage per id |
 | `/linkedin:newsletter` | **Long-form spine.** Newsletter editions, essays, series articles. The single long-form entry point |
 | `/linkedin:headless-review` | Cold adversarial re-read of a FROZEN long-form draft before lock (ideally in a fresh session) |
 | `/linkedin:pivot` | Re-open a long-form edition after a late change so cleared gates re-run |
@ -188,10 +161,8 @@ If the user's intent is clear from context:
 - Mentions "react" or "this article" or "this url" or "turn this into" or "share this news" → Route to `/linkedin:react`
 - Mentions "quick" or "fast" → Route to `/linkedin:quick`
 - Mentions "pipeline" or "end to end" → Route to `/linkedin:pipeline`
 - Mentions "trends" or "trending" or "discovery pass" or "morning brief" or "what should I write about" → Route to `/linkedin:trends`
 - Mentions "batch" or "week of content" → Route to `/linkedin:batch`
 - Mentions "calendar" or "schedule" or "queue" or "upcoming posts" or "what's scheduled" → Route to `/linkedin:calendar`
 - Mentions "slot" or "publishing slots" or "empty slot" or "open slot" or "slot grid" or "what's in flight" or "work in progress" → Route to `/linkedin:calendar` (slot grid, vacancies, editions in flight)
 - Mentions "publish" or "mark as published" or "posted today" or "just published" or "post is live" → Route to `/linkedin:calendar` (publish action)
 - Mentions "plan" → Suggest `content-planner` agent
 - Mentions "profile" or "topic-relevance" → Route to `/linkedin:profile`
--- a/commands/measure.md
+++ b/commands/measure.md
@ -8,6 +8,7 @@ description: |
  Triggers on: "measure", "how am I doing", "my performance", "show my analytics",
  "performance overview", "how are my posts doing", "linkedin measure".
 allowed-tools:
  - Read
  - Glob
  - AskUserQuestion
 ---
@ -20,7 +21,7 @@ intent in one question and route. **You do not run the analysis here.**
 ## Step 0: Quick context (optional)
-You may `Glob` `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/`; if it holds imported data, note "last import: [date]" in one
+If `assets/analytics/` holds imported data, you may note "last import: [date]" in one
 line so the user knows whether a fresh import is needed first. Do not block on it.
 ## Step 1: Identify what they need
--- a/commands/monetize.md
+++ b/commands/monetize.md
@ -10,12 +10,14 @@ allowed-tools:
  - Read
  - Glob
  - Grep
  - WebFetch
  - AskUserQuestion
  - Write
 ---
 # LinkedIn Monetization Strategy
-You are a LinkedIn monetization strategist. Help the user turn their LinkedIn authority into revenue streams — from first lead magnet to scalable offer suite.
+You are a LinkedIn monetization strategist. Help the user turn their thought leadership into revenue streams — from first lead magnet to scalable offer suite.
 ## Step 0: Load Context
@ -338,9 +340,10 @@ DM Conversion Framework:
   - Paid: "Want to grab 15 min to see if [offer] is a fit? [booking link]"
   - Not ready: "No rush — follow along and reach out when timing is right"
-Response time matters — speed compounds conversion:
+Response time matters:
- Same-day responses convert far better than days-later ones; the longer the gap, the colder the lead.
+- Same day: roughly half convert to the next step
- For per-channel benchmarks (speaking / consulting / podcast) and the response window each warrants, see `references/opportunity-generation.md`.
+- Next day: 20-30% conversion
 - 3+ days: <10% conversion
 ```
 ## Step 5: CTA Optimization
--- a/commands/multiplatform.md
+++ b/commands/multiplatform.md
@ -21,13 +21,9 @@ You are a multi-platform content strategist. Help the user adapt their LinkedIn
 ## Step 0: Load Source Content
 Ask the user to provide their LinkedIn content or read from drafts:
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/` for recent content
+- Read `${CLAUDE_PLUGIN_ROOT}/assets/drafts/` for recent content
 - Read `~/.claude/linkedin-studio.local.md` for recent posts
 If none of these yields source content (empty/absent drafts, no recent posts, and nothing
 pasted), **stop and ask the user to paste the LinkedIn post to adapt** — never fabricate
 source content to adapt.
 ## Step 1: Select Target Platform
 > **Long-form lives elsewhere.** Newsletters, blog posts, and essays are produced by
@ -42,11 +38,6 @@ Use AskUserQuestion:
 ## Adaptation Templates
 > **Voice hygiene (all platforms):** adaptation rewrites the source — keep the adapted copy free
 > of the banned corporate buzzwords (content rule #4: leverage, synergy, paradigm shift, thought
 > leader, disruptive, value proposition, ecosystem, holistic approach) on every platform; don't
 > let the rewrite introduce them.
 ### LinkedIn → Twitter/X Thread
 ```
@ -115,14 +106,12 @@ YouTube tips:
 ## Step 2: Adapt and Save
 After creating the adaptation:
- Save to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/multiplatform/[platform]-[slug].md`
+- Save to `${CLAUDE_PLUGIN_ROOT}/assets/drafts/multiplatform/[platform]-[slug].md`
 - Auto-copy the adapted content to clipboard silently:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<ADAPTED_CONTENT>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <ADAPTED_CONTENT>
 __LINKEDIN_CLIP_EOF__
 ```
- Substitute `<ADAPTED_CONTENT>` with the exact adapted text between the heredoc markers (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Present the content, and only if the helper prints `COPIED`, confirm: "Copied to clipboard." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the text above manually — do not claim it was copied.
+- Present the content and confirm: "Copied to clipboard."
 - Note platform-specific publishing tips
 ## Reference Files
--- a/commands/newsletter.md
+++ b/commands/newsletter.md
--- a/commands/onboarding.md
+++ b/commands/onboarding.md
@ -15,7 +15,7 @@ allowed-tools:
 # LinkedIn Onboarding Wizard
-You are the LinkedIn Studio onboarding guide. Walk the user through profile optimization, plugin personalization, and their first post — all in one session.
+You are a LinkedIn thought leadership onboarding guide. Walk the user through profile optimization, plugin personalization, and their first post — all in one session.
 ## Step 0: Load Context and Check State
@ -140,7 +140,7 @@ Use AskUserQuestion:
 4. "Paste a paragraph you've written that sounds like YOU (email, doc, anything)"
 5. "Any words or phrases you'd NEVER use?"
-Save the responses to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md`. **If the
+Save the responses to `assets/voice-samples/authentic-voice-samples.md`. **If the
 file is the shipped placeholder** (it contains `<!-- VOICE_PLACEHOLDER -->`),
 **REPLACE it entirely** with the profile built from the answers — the
 `<!-- VOICE_PLACEHOLDER -->` sentinel must NOT remain, or the voice score stays at
@ -154,9 +154,8 @@ file must contain no `<!-- VOICE_PLACEHOLDER -->`.
 3. Job title / role
 4. 5 expertise areas (these become your content pillars)
 5. Target audience description
 6. Research MCPs connected (Tavily / Gemini deep research / Perplexity — or "none"; WebSearch + WebFetch are the always-available floor). Store only what they name — don't invent MCP names.
-Save to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md`.
+Save to `config/user-profile.local.md`.
 After setup, recalculate and show updated score.
@ -197,7 +196,7 @@ Then ask: "Give me a sentence or two about what you have in mind." If expertise
 ### 3.2 — Write the post (3-line formula)
-Draft the post using the voice profile from Phase 2 (or the existing `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` profile):
+Draft the post using the voice profile from Phase 2 (or the existing `assets/voice-samples/` profile):
 - **Line 1 — Hook (110-140 chars):** specific to their experience, no generic opening
 - **Line 2 — Context (1-3 sentences):** the what and why, kept tight
 - **Line 3 — Insight + question:** their takeaway, ending on a genuine question that invites comments
@ -218,11 +217,9 @@ Fix any miss before showing it.
 Show the post with its character count, the hook highlighted, and one alternative hook. Auto-copy the post text to clipboard silently:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<POST_TEXT>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <POST_TEXT>
 __LINKEDIN_CLIP_EOF__
 ```
-Substitute `<POST_TEXT>` with the exact post text between the heredoc markers (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Only if the helper prints `COPIED`, say: "Post copied to clipboard. Go to linkedin.com, click 'Start a post', paste it, and hit Post." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the text above manually — do not claim it was copied.
+Then say: "Post copied to clipboard. Go to linkedin.com, click 'Start a post', paste it, and hit Post."
 ### 3.5 — Record it
--- a/commands/outreach.md
+++ b/commands/outreach.md
@ -16,9 +16,10 @@ allowed-tools:
  - Read
  - Glob
  - WebSearch
  - WebFetch
  - AskUserQuestion
  - Write
  - Task
  - Bash
 ---
 # LinkedIn Outreach Orchestrator (Collaborations + Speaking)
@ -648,8 +649,7 @@ DM Amplification Protocol:
   Both partners share/comment on each other's version.
   Creates compound visibility effect.
-Impact: this feeds the first-hour engagement that carries collaborative
+Impact: DM amplification can boost first-hour engagement 2-3x.
 content to its above-baseline reach (no reliable multiplier; ref: collaborations-guide.md).
 ```
 ### Step 5b: Speaking — Outreach by Channel
@ -810,7 +810,7 @@ Week 1: FRAMEWORK POST
 ─────────────────────
 Show your unique methodology.
 Hook: "I developed a 3-step framework for [topic] after [experience]."
-Goal: Demonstrate subject-matter depth.
+Goal: Demonstrate thought leadership depth.
 Signal: "This person has original ideas worth sharing."
 Week 2: EVENT RECAP / INSIGHT POST
@ -918,22 +918,24 @@ LinkedIn: [profile URL]
 ## Step 7: Engagement-Pod Warning (Both Tracks)
-LinkedIn runs an active engagement-pod crackdown (see
+**Post-March 2025 LinkedIn Algorithm Update:**
 `references/algorithm-signals-reference.md`):
 ```
 ⚠️ ENGAGEMENT PODS: DO NOT USE
-What LinkedIn does to pods (its stated crackdown):
+LinkedIn now actively detects and penalizes engagement pods:
 - Pod-style auto-comments are demoted out of "Most Relevant"
 - Their reach is scoped to your own network — it stops spreading beyond it
 - Repeat offenders get restricted
-How pods get detected:
+Detection methods:
 - Consistent same-person engagement patterns
 - Engagement timing clusters (everyone engages within minutes)
 - Low dwell time on engaged posts (engage without reading)
 - Reciprocal engagement loops (A→B→A→B pattern)
 Penalties:
 - 30-55% reach reduction on detected posts
 - Shadow suppression of pod participants
 - Account credibility score reduction
 INSTEAD, build genuine engagement through:
 - CEA method comments (Compliment, Expand, Ask)
 - 5x5x5 daily routine (organic engagement)
--- a/commands/pipeline.md
+++ b/commands/pipeline.md
@ -26,8 +26,8 @@ You are a LinkedIn content pipeline orchestrator. Guide the user through the com
 Load persistent state and personalization:
 - Read `~/.claude/linkedin-studio.local.md` for posting state
 - Read `${CLAUDE_PLUGIN_ROOT}/skills/linkedin-studio/SKILL.md` for profile and preferences
- Check `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` for voice matching
+- Check `assets/voice-samples/` for voice matching
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/templates/my-post-templates.md` for proven post templates — use these in Step 2 (Draft)
+- Read `assets/templates/my-post-templates.md` for proven post templates — use these in Step 2 (Draft)
 - Read `assets/frameworks/framework-template.md` if the topic involves a framework or methodology
 Display status:
@ -52,7 +52,7 @@ To situate the post in the broader plan — does it fill a content-mix gap or re
 Once topic is chosen, create the draft:
-1. **Select angle** — Auto-select the strongest angle from `references/content-angles.md` based on topic and user's expertise. Present ONE recommended angle with reasoning. Do NOT use AskUserQuestion — just proceed. If user disagrees, offer alternatives.
+1. **Select angle** — Auto-select the strongest angle from `references/thought-leadership-angles.md` based on topic and user's expertise. Present ONE recommended angle with reasoning. Do NOT use AskUserQuestion — just proceed. If user disagrees, offer alternatives.
 2. **Infer format** — Default to text post. Only mention carousel/video as a note if particularly well-suited.
 3. **Write draft** — Following the structure:
   - Hook: 110-140 characters
@ -76,12 +76,12 @@ Run the draft through optimization checks:
 - [ ] Hook 110-140 chars
 - [ ] Total 1,200-1,800 chars
 - [ ] No external links in body
- [ ] No corporate buzzwords (leverage, synergy, paradigm shift, thought leader, disruptive, value proposition, ecosystem, holistic approach)
+- [ ] No corporate buzzwords
 - [ ] Topic aligns with expertise areas
 - [ ] Authentic voice (not AI-sounding)
 **Voice check:**
-Compare against `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` to ensure natural tone.
+Compare against `assets/voice-samples/` to ensure natural tone.
 Present optimized version with before/after comparison.
@ -110,7 +110,7 @@ If the user chooses to queue the post:
   node --input-type=module -e "import { queueUpcoming, queueFormatSummary } from '${CLAUDE_PLUGIN_ROOT}/hooks/scripts/queue-manager.mjs'; console.log(queueFormatSummary(queueUpcoming(14)));"
   ```
 3. Suggest the next available optimal slot
-4. Save the draft to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/week-[WXX]/[day]-[topic-slug].md` with `scheduled_date` and `scheduled_time` in frontmatter
+4. Save the draft to `assets/drafts/week-[WXX]/[day]-[topic-slug].md` with `scheduled_date` and `scheduled_time` in frontmatter
 5. Add to queue:
   ```bash
   node --input-type=module -e "import { queueAdd } from '${CLAUDE_PLUGIN_ROOT}/hooks/scripts/queue-manager.mjs'; console.log(queueAdd('[id]', '[draft_path]', '[date]', '[time]', '[pillar]', '[format]', '[hook preview]', [chars]));"
@ -136,9 +136,7 @@ Offer to help identify target profiles and draft comments.
 Auto-copy the final post text to clipboard silently before presenting:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<FINAL_POST_TEXT>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <FINAL_POST_TEXT>
 __LINKEDIN_CLIP_EOF__
 ```
 Present the final post as copy-paste ready content:
@ -203,11 +201,11 @@ Replace placeholders with actual post data. Set `next_planned_topic` manually if
 ## Reference Files
- `${CLAUDE_PLUGIN_ROOT}/references/content-angles.md`
+- `${CLAUDE_PLUGIN_ROOT}/references/thought-leadership-angles.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/engagement-frameworks.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/algorithm-signals-reference.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/linkedin-formats.md`
 - `${CLAUDE_PLUGIN_ROOT}/references/scheduling-strategy.md`
 - `${CLAUDE_PLUGIN_ROOT}/assets/checklists/quality-scorecard.md`
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/`
+- `${CLAUDE_PLUGIN_ROOT}/assets/voice-samples/`
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/queue.json`
+- `${CLAUDE_PLUGIN_ROOT}/assets/drafts/queue.json`
--- a/commands/pivot.md
+++ b/commands/pivot.md
@ -43,7 +43,7 @@ edition can sail into lock carrying an unverified premise or an unread argument.
 /linkedin:pivot
  --article  NN                  (required; the edition article that changed)
  --reason   "<one line>"        (required; e.g. "Security Champions-anker")
-  --to-phase draft | consistency-quality   (optional; default from scope — see Step 2)
+  --to-phase draft | consistency-quality | factcheck-sweep   (optional; default from the heuristic)
 ```
 ## The pivot-detection heuristic
@ -90,23 +90,13 @@ cleared, the lock STOPS and points the operator here. (Length-band drift itself
   the operator if ambiguous).
 4. **Classify scope** (drives the default `--to-phase`):
   - **Structural** (deltaPct > 20 % OR newSections > 2, or a new axis/thesis) →
-     default `to-phase: draft` so newsletter resumes at **Step 4
+     default `to-phase: draft` (Step 3b). The new material needs full prose
-     (consistency-quality)** — the changed prose is re-threaded, then fact-check
+     expansion → consistency → fact-check → editorial → persona → headless.
     (5) → editorial (5.5) → persona (6) → headless (6.5) re-run on it.
   - **Moderate** (new examples/claims, no new sections, deltaPct ≤ 20 %) →
-     default `to-phase: consistency-quality` so newsletter resumes at **Step 5
+     default `to-phase: factcheck-sweep` (Step 5) so the new claims get verified,
-     (fact-check)** and the new claims get verified, then editorial (5.5) →
+     then editorial + persona + headless re-run.
     persona (6) → headless (6.5) re-run.
   - The operator may override with explicit `--to-phase`.
 > **Why these specific phases (the off-by-one trap).** `to-phase` is written as
 > `currentPhase`, which records the *last completed* phase; `/linkedin:newsletter`'s
 > resumption table (Step 0) then resumes at the step **after** it. So `draft`
 > resumes at **Step 4** and `consistency-quality` resumes at **Step 5** (the
 > fact-check). A pivot therefore never resets to `factcheck-sweep` — that would
 > resume at Step 5.5 and **skip** the fact-check, violating this command's
 > invariant that a pivot always invalidates the fact-check (Step 3, `gatesToRerun`).
 ## Step 3 — Log the pivot + reset the phase (the ritual)
 1. **Append a pivot entry** to `articles.NN.pivots[]`:
--- a/commands/post.md
+++ b/commands/post.md
@ -18,7 +18,7 @@ allowed-tools:
 # LinkedIn Post Creation Workflow
-You are a LinkedIn content creator. Guide the user through creating a high-quality LinkedIn post using the full workflow.
+You are a LinkedIn thought leadership content creator. Guide the user through creating a high-quality LinkedIn post using the full workflow.
 ## Step 0: Load Context
@ -36,14 +36,14 @@ Check weekly progress:
 - If `posts_this_week == weekly_goal - 1`, note: "This is your last post to hit this week's goal."
 Check for existing assets:
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` - Match the user's natural voice
+- `assets/voice-samples/` - Match the user's natural voice
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md` - Study past successful posts and replicable patterns
+- `assets/examples/high-engagement-posts.md` - Study past successful posts and replicable patterns
 - `assets/frameworks/framework-template.md` - Reference user's documented frameworks for framework posts
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/templates/my-post-templates.md` - User's proven post templates with success rates. **Prefer these over generic structures.**
+- `assets/templates/my-post-templates.md` - User's proven post templates with success rates. **Prefer these over generic structures.**
 ## Step 1: Understand the Input
-If the user already provided a clear topic with the command invocation (e.g., `/linkedin:post about pricing strategy for B2B SaaS`), skip asking and proceed directly. Only ask if the input is missing or genuinely vague.
+If the user already provided a clear topic with the command invocation (e.g., `/linkedin:post about AI governance in public sector`), skip asking and proceed directly. Only ask if the input is missing or genuinely vague.
 Identify the type of raw material:
@ -61,11 +61,11 @@ If the input is genuinely vague (no discernible topic or intent), ask ONE clarif
 If they provide a URL, use WebFetch to extract the content first.
-## Step 2: Select Content Angle
+## Step 2: Select Thought Leadership Angle
-Read `references/content-angles.md` for the 8 universal angles.
+Read `references/thought-leadership-angles.md` for the 8 universal angles.
-**Industry-specific angles:** If `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md` exists and has an `industry` field, check the "Industry Angle Variants" section in `content-angles.md` for the matching industry table. Use the industry-specific starter questions and example hooks to generate more targeted angle suggestions.
+**Industry-specific angles:** If `config/user-profile.local.md` exists and has an `industry` field, check the "Industry Angle Variants" section in `thought-leadership-angles.md` for the matching industry table. Use the industry-specific starter questions and example hooks to generate more targeted angle suggestions.
 Select the strongest angle based on the content and user's expertise areas. Present ONE recommended angle with brief reasoning:
@ -95,7 +95,7 @@ Proceed with standard text post format by default. Only mention carousel or othe
 Read `references/engagement-frameworks.md` for hook types, story structures, and CTAs.
-Use the Standard Post Structure:
+Use the Standard Thought Leadership Structure:
 1. **Hook (110-140 chars):** Grab attention, create curiosity gap
 2. **Context (200-300 chars):** Set up why this matters
@ -131,9 +131,8 @@ Before presenting, verify against `assets/checklists/quality-scorecard.md`:
 - [ ] Provides genuine value to readers
 - [ ] CTA is specific and natural
 - [ ] No external links in post body
 - [ ] No corporate buzzwords (leverage, synergy, paradigm shift, thought leader, disruptive, value proposition, ecosystem, holistic approach)
 - [ ] Topic aligns with user's 5 core expertise areas
- [ ] Passes the insight test (helps someone decide or think differently)
+- [ ] Passes thought leadership test (helps someone decide or think differently)
 ### De-AI / Differentiation Gate
@ -150,11 +149,9 @@ Present ONE draft with:
 Auto-copy the final post text to clipboard silently:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<FINAL_POST_TEXT>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <FINAL_POST_TEXT>
 __LINKEDIN_CLIP_EOF__
 ```
-Substitute `<FINAL_POST_TEXT>` with the exact post text between the heredoc markers (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Only if the helper prints `COPIED`, confirm: "Copied to clipboard." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the text above manually — do not claim it was copied.
+Then confirm: "Copied to clipboard."
 Do NOT proactively offer alternative versions. Only generate alternatives if the user asks for them.
@ -202,7 +199,7 @@ Replace placeholders with actual post data. This replaces manual YAML editing.
 ## Reference Files
- `references/content-angles.md` - 8 universal angles
+- `references/thought-leadership-angles.md` - 8 universal angles
 - `references/engagement-frameworks.md` - Hooks, structure, CTAs
 - `references/linkedin-formats.md` - Format specifications
 - `references/algorithm-signals-reference.md` - Algorithm mechanics
--- a/commands/profile.md
+++ b/commands/profile.md
@ -2,9 +2,8 @@
 name: linkedin:profile
 description: |
  profile/topic-relevance optimization checklist for LinkedIn's 2026 algorithm update.
-  A coherent, on-topic profile reinforces the topic-relevance signal LinkedIn uses to decide
+  LinkedIn now validates your profile BEFORE distributing content. This command audits
-  how widely your content is distributed. This command audits and optimizes your profile
+  and optimizes your profile for maximum reach. Use when the user mentions "profile",
  for that signal. Use when the user mentions "profile",
  "topic-relevance", "profile optimization", "why is my reach low", or wants to improve their
  LinkedIn presence. Triggers on: "optimize profile", "profile/topic-relevance check", "profile audit",
  "linkedin profile help", "fix my profile".
@ -22,41 +21,36 @@ You are a LinkedIn profile optimization specialist. Help the user optimize their
 Read `references/algorithm-signals-reference.md` for algorithm mechanics.
 **The Fundamental Shift:**
- **In the older feed model:** Post something → a slice of your network sees it → the algorithm tracks engagement to decide wider reach
+- **In the older feed model:** Post something -> Goes to 10% of audience -> Algorithm tracks engagement
- **In the 2026 relevance model:** topic/interest relevance is weighed alongside engagement — content matched to a viewer's interests is distributed more widely (including beyond your network), so an off-topic post from a profile that sends no clear topic signal tends to underperform.
+- **In the 2026 relevance model:** profile/topic relevance is weighed alongside engagement — content matched to your demonstrated expertise is distributed more widely (including beyond your network), so an off-topic post from a misaligned profile tends to underperform.
-**Profile/topic alignment is a real ranking input — content matched to a viewer's interests is distributed more widely, including beyond your network (see `references/algorithm-signals-reference.md`). LinkedIn confirms no off-topic reach-reduction figure — treat alignment as a real input, not a quantified penalty.**
+**Profile/topic alignment is a real ranking input — content matched to your demonstrated expertise is distributed more widely (see `references/algorithm-signals-reference.md`).**
 ## The Profile/Topic Relevance Factors
-Topic alignment is a confirmed ranking input, but LinkedIn does **not** publish a
+The 2026 relevance-ranking model evaluates five criteria (see `references/algorithm-signals-reference.md`):
 profile-scoring breakdown — there is no official "five criteria" weighting (see
 `references/algorithm-signals-reference.md`). The factors below are practitioner heuristics
 for sending a coherent, on-topic expertise signal; treat the priority as directional, not a
 measured coefficient:
-| Factor | What it signals | Priority (heuristic) |
+| Criteria | What It Checks | Impact if Missing |
-|--------|-----------------|----------------------|
+|----------|----------------|-------------------|
-| **About Section** | Establishes your expertise on your topics | High — first thing a reader (and a topic-matcher) sees |
+| **About Section** | Does it establish expertise on your topics? | HIGH - first signal of credibility |
-| **Experience Section** | Relevant background with impact statements | High — evidence you've done the work |
+| **Experience Section** | Relevant background with impact statements? | HIGH - proves you've done the work |
-| **Content History** | You've posted on this topic before | Medium — consistency signal |
+| **Content History** | Have you posted about this topic before? | MEDIUM - consistency signal |
-| **Network** | Connected to professionals in this space | Medium — social proof |
+| **Network** | Connected to professionals in this space? | MEDIUM - social proof |
-| **Engagement Patterns** | You comment on posts in your topics | Medium — active participation |
+| **Engagement Patterns** | Do you comment on posts about your topics? | MEDIUM - active participation |
 ## Profile SEO — your profile is also a search surface
 Topic-relevance ranking (above) governs **content distribution**. Separately,
 your profile is **indexed by LinkedIn search** — when someone searches a topic, a
 role, or a skill, LinkedIn keyword-matches profile fields to decide who surfaces.
-The two reinforce each other: the same keywords that make your topic legible — to
+The two reinforce each other: the same keywords that tell the relevance model
-readers and to topic-relevance distribution — are the ones that make you findable in
+what you're expert in are the ones that make you findable. Optimize for both.
 search. Optimize for both.
-**The headline is widely regarded as your highest-leverage search field.** It is keyword-matched, shown
+**The headline is your highest-weight search field.** It is keyword-matched, shown
 in every search result and connection suggestion, and renders under your name
 across the site — so it does the most SEO work per character. Lead with the plain
 words people actually search (the role, the domain, the audience), not a clever
-tagline. "Data Engineer · healthcare analytics · HIPAA-compliant pipelines" is more
+tagline. "AI Advisor · public-sector AI governance · Microsoft Copilot" is more
 findable than "Turning chaos into clarity ✨".
 **Per-section keyword targets** (place the terms a searcher would type, in the
@ -64,8 +58,8 @@ words they'd type them — not synonyms only you use):
 | Section | Keyword target | Why it ranks |
 |---------|----------------|--------------|
-| **Headline** | 3–4 primary topic terms + audience + role | Highest-leverage search field; always visible |
+| **Headline** | 3–4 primary topic terms + audience + role | Highest-weight search field; always visible |
-| **About** | Same primary terms, front-loaded in the first 2–3 lines, then 5–8 supporting terms naturally across the body | Indexed for search; the front-loaded first lines also carry your strongest on-topic signal |
+| **About** | Same primary terms, front-loaded in the first 2–3 lines, then 5–8 supporting terms naturally across the body | Indexed for search; first lines double as the relevance model's expertise signal |
 | **Experience (titles + body)** | The searchable job title (not an internal-only label) + 2–3 domain terms per role | Job titles are weighted in search; an internal title nobody searches is invisible |
 | **Skills** | Your top 3 skills = your 3 core content topics, exact-match to common search terms | Matched directly against recruiter/search skill filters |
 | **Featured** | Posts whose titles carry your topic terms | Reinforces the topic association for both search and relevance |
@ -95,14 +89,14 @@ Guide the user through each section using AskUserQuestion for interactive feedba
 - [ ] No jargon or vague titles
 **Strong example:**
-"Helping e-commerce teams turn returns data into retention | Retention Strategist @ [Company]"
+"Helping public sector leaders implement AI that actually works | AI Advisor @ [Company]"
 **Weak example:**
 "Digital Transformation Expert | Thought Leader | Speaker"
 ### Section 2: About Section (2,600 characters max)
-**Critical:** Your About opener is the clearest place to state, in plain on-topic terms, what you're expert in — the strongest single contribution to a coherent topic signal.
+**Critical:** This is the first signal telling topic-relevance what you're qualified to discuss.
 **Structure:**
@ -134,7 +128,7 @@ Guide the user through each section using AskUserQuestion for interactive feedba
 **Transform each role with impact statements, not task lists.**
 **Bad:** "Responsible for AI initiatives"
-**Good:** "Cut customer-support response time 40% by automating tier-1 triage"
+**Good:** "Deployed first Copilot Studio agent handling 40% of internal inquiries"
 **Ask the user:** Describe your current role's key achievements with numbers/impact.
@ -164,7 +158,7 @@ Guide the user through each section using AskUserQuestion for interactive feedba
 ### Section 5: Skills Section
-**Your top skills are a strong, searchable topic signal.**
+**Critical for profile/topic-relevance validation.**
 **Ask the user:** What skills are listed on your profile?
@ -176,7 +170,7 @@ Guide the user through each section using AskUserQuestion for interactive feedba
 ### Section 6: Network Quality
-**A network concentrated in your expertise area reinforces your topic signal and your social proof** (a practitioner heuristic — LinkedIn does not publish network as a profile-ranking factor).
+**profile/topic-relevance checks if you're connected to professionals in your expertise area.**
 **Ask the user:** Who are you primarily connected with? (peers, clients, random connections?)
@ -233,7 +227,7 @@ Based on the audit, provide a prioritized action list:
 Before posting, the user should ask themselves:
-> "Does my profile make it obvious — to a human and to LinkedIn's topic-matching — that I'm an expert on the topics I post about?"
+> "If LinkedIn's AI read my profile, would it believe I'm an expert on the topics I post about?"
 If the answer is no, fix the profile FIRST before posting.
--- a/commands/quick.md
+++ b/commands/quick.md
@ -159,11 +159,9 @@ Show the post with:
 Auto-copy the final post text to clipboard silently:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<FINAL_POST_TEXT>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <FINAL_POST_TEXT>
 __LINKEDIN_CLIP_EOF__
 ```
-Substitute `<FINAL_POST_TEXT>` with the exact post text between the heredoc markers (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Only if the helper prints `COPIED`, confirm: "Copied to clipboard." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the text above manually — do not claim it was copied.
+Then confirm: "Copied to clipboard."
 Do NOT proactively offer alternative versions. Only generate alternatives if the user asks.
--- a/commands/react.md
+++ b/commands/react.md
@ -19,13 +19,13 @@ allowed-tools:
 # React to External Content — URL-to-Post Pipeline
-You are a LinkedIn content creator specializing in turning external content into insightful posts.
+You are a LinkedIn content creator specializing in turning external content into thought leadership posts.
 ## Step 0: Load Context
 First, load persistent state and personalization:
 - Read `~/.claude/linkedin-studio.local.md` for posting state (streak, weekly progress, recent topics)
- Read `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` for voice profile
+- Read `assets/voice-samples/authentic-voice-samples.md` for voice profile
 - Check recent posts to avoid topic repetition within 7 days
 ## Step 1: Get URL(s)
@ -57,8 +57,6 @@ Use WebFetch to extract the content from the URL. Ask WebFetch to extract:
 - Data points or statistics mentioned
 - The "so what" — why this matters
 **If WebFetch can't extract usable content** (paywall, JS-heavy page, or a YouTube video with no accessible transcript — all accepted inputs WebFetch may not resolve): say so plainly, then ask the user to paste the key points (or the transcript) or choose another URL. Never fabricate a reaction from the URL string or title alone — the post must stand on real source content.
 ## Step 3: Classify Content Type
 Determine the content type to select the right template:
@ -128,7 +126,6 @@ Verify against quality rules:
 - [ ] Character count: 1,200-1,800
 - [ ] Topic aligns with expertise areas
 - [ ] CTA invites discussion, not just "What do you think?"
 - [ ] No corporate buzzwords (leverage, synergy, paradigm shift, thought leader, disruptive, value proposition, ecosystem, holistic approach)
 ### De-AI / Differentiation Gate
@ -146,11 +143,9 @@ Show:
 Auto-copy the main draft text to clipboard silently:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<MAIN_DRAFT_TEXT>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <MAIN_DRAFT_TEXT>
 __LINKEDIN_CLIP_EOF__
 ```
-Substitute `<MAIN_DRAFT_TEXT>` with the exact draft text between the heredoc markers (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Only if the helper prints `COPIED`, confirm: "Copied to clipboard." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the text above manually — do not claim it was copied.
+Then confirm: "Copied to clipboard."
 Do NOT use AskUserQuestion for refinement. Simply state:
@ -193,8 +188,6 @@ Use WebFetch on each URL. For each, extract:
 - **Stance/argument** — what position does the author take?
 - **Data points** — any statistics or evidence cited
 **If a source can't be extracted** (paywall / JS-heavy / no transcript): apply the Step 2 fallback — drop it if 2+ usable sources remain, otherwise ask the user to paste it or choose another. Never fabricate from a title or URL alone.
 ### Step 3b: Synthesis Analysis
 Analyze across all sources:
@ -271,7 +264,7 @@ Same as Step 8 — run `state-updater.mjs` with actual post data.
 ## Reference Files
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` — Voice matching
+- `assets/voice-samples/authentic-voice-samples.md` — Voice matching
- `references/content-angles.md` — 8 universal angles
+- `references/thought-leadership-angles.md` — 8 universal angles
 - `references/engagement-frameworks.md` — Hooks, structure, CTAs
 - `assets/checklists/quality-scorecard.md` — Pre-publish check
--- a/commands/report.md
+++ b/commands/report.md
@ -10,7 +10,6 @@ allowed-tools:
  - Bash
  - Read
  - Glob
  - Write
  - AskUserQuestion
  - Task
 ---
@ -28,7 +27,7 @@ For data format details and directory structure, see `assets/analytics/README.md
 First, verify that analytics data exists:
 ```bash
-ls -1 ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/ 2>/dev/null | grep -E '\.json$' | head -10
+ls -1 ${CLAUDE_PLUGIN_ROOT}/assets/analytics/posts/ 2>/dev/null | grep -E '\.json$' | head -10
 ```
 If no JSON files exist, tell the user:
@ -70,7 +69,7 @@ Enter your choice:
 ```
 **If monthly (option 2):** Ask for month (YYYY-MM format, default to current month), then jump to **Step 2b**.
-**If heatmap (option 3):** Run the heatmap CLI command and jump to **Step 2c**.
+**If heatmap (option 3):** Run the heatmap CLI command and jump to **Step 6c**.
 **If weekly (option 1 or default):** Continue below.
 ### Weekly: Determine Week
@ -99,17 +98,17 @@ date +%Y-W%V
 If the user chose monthly:
 ```bash
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report --month <YYYY-MM>
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report --month <YYYY-MM>
 ```
-Read the generated JSON from `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/monthly-reports/<YYYY-MM>.json`. Present the monthly summary with MoM comparison deltas, weekly breakdown, and top performers. Then jump to Step 7 for deep-dive options.
+Read the generated JSON from `assets/analytics/monthly-reports/<YYYY-MM>.json`. Present the monthly summary with MoM comparison deltas, weekly breakdown, and top performers. Then jump to Step 7 for deep-dive options.
 ### Step 2c: Heatmap
 If the user chose heatmap:
 ```bash
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" heatmap
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" heatmap
 ```
 Present the day-of-week matrix and best-day findings. Then jump to Step 7 for deep-dive options.
@ -119,39 +118,40 @@ Present the day-of-week matrix and best-day findings. Then jump to Step 7 for de
 Execute the report CLI command:
 ```bash
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report --week <YYYY-WXX>
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report --week <YYYY-WXX>
 ```
 **Example:**
 ```bash
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report --week 2026-W05
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report --week 2026-W05
 ```
 The CLI will generate:
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/YYYY-WXX.json` - Structured report data
+- `assets/analytics/weekly-reports/YYYY-WXX.json` - Structured report data
 ## Step 4: Read Generated Report Data
 Read the generated JSON report:
 ```bash
-cat ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/<YYYY-WXX>.json
+cat ${CLAUDE_PLUGIN_ROOT}/assets/analytics/weekly-reports/<YYYY-WXX>.json
 ```
 The report contains:
 - **week**: ISO week identifier
- **generatedAt**: ISO timestamp when the report was generated
+- **dateRange**: Start and end dates
- **summary**: Totals and averages — `totalPosts`, `totalImpressions`, `totalReactions`, `totalComments`, `totalShares`, `totalClicks`, optional `totalSaves` (manual entry only), `avgEngagementRate`, `avgImpressionsPerPost`
+- **postCount**: Number of posts published
- **topPerformers** / **underperformers**: Best / weakest posts by engagement rate
+- **aggregateMetrics**: Totals and averages across all metrics
- **trends**: Week-over-week change — `impressionsTrend`, `engagementTrend`, `comparedTo`, `percentChange`
+- **topPerformers**: Best posts by each metric
- **alerts**: Anomalies and significant events (intra-week + week-over-week)
+- **alerts**: Anomalies and significant events
 - **trends**: Week-over-week changes
 ## Step 5: Run Trend Analysis
 Get additional context with trend analysis:
 ```bash
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric impressions
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric impressions
 ```
 This provides:
@ -165,11 +165,13 @@ After the initial trend data, automatically run trend analysis for the key metri
 **Run trends CLI for key metrics:**
 ```bash
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" \
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" \
  "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" \
  trends --period month --metric impressions
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" \
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" \
-  trends --period month --metric engagementRate
+  "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" \
  trends --period month --metric engagement_rate
 ```
 **Present trend summary as a 4-week comparison table:**
@ -195,7 +197,7 @@ After the initial trend data, automatically run trend analysis for the key metri
 Construct the 4-week table by reading available weekly report files:
 ```bash
-ls ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/*.json 2>/dev/null | sort | tail -4
+ls ${CLAUDE_PLUGIN_ROOT}/assets/analytics/weekly-reports/*.json 2>/dev/null | sort | tail -4
 ```
 Read each file and extract the summary metrics to populate the table columns.
@ -213,24 +215,20 @@ Automatically flag these conditions based on the report data and trend analysis:
 - 🟢 **Positive:** Consistent posting streak maintained (7+ days)
 **Algorithm Alerts (based on algorithm-signals-reference):**
- 🔴 Format stagnation: Same format used >80% of posts (algorithm favors format variety — see algorithm-signals-reference)
+- 🔴 Format stagnation: Same format used >80% of posts (algorithm penalizes monotony per 2026 content format multipliers)
 - 🟡 Posting time drift: Publishing outside optimal window (Tue-Thu, 7-9 AM CET for Nordic audience — see posting time windows reference)
 - 🟡 Hook length violation: Posts with hooks >140 chars underperforming (>140 chars truncated on mobile "see more")
 - 🟢 Engagement velocity improving: First-hour engagement trending up (15+ engagements in first hour unlocks 2nd/3rd degree distribution)
-**Surface the alerts the report already computed.** The weekly-report JSON's `alerts[]`
+**Detect alerts by comparing current week data against baselines:**
 is generated by the CLI itself — intra-week anomaly detection across the week's posts
 (`detectAlerts`) plus a week-over-week comparison (`detectWeeklyAlerts`) that fires once
 the previous week's report exists. There is no separate baselines file to consult; read
 `alerts[]` straight from the report you generated in Step 3:
 ```bash
-cat ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/<YYYY-WXX>.json 2>/dev/null \
+cat ${CLAUDE_PLUGIN_ROOT}/assets/analytics/baselines.json 2>/dev/null
  | python3 -c "import json,sys; [print(a['severity'].upper(), '—', a['message']) for a in json.load(sys.stdin).get('alerts', [])]"
 ```
-Each alert carries a `severity` (`critical` / `warning` / `info`); map it to an icon
+Compare current week's `aggregateMetrics` against baseline means and standard deviations. Flag any metric that is:
-(🔴 / 🟡 / 🟢) and pair it with an action below. Week-over-week alerts appear only after a
+- >2 standard deviations above mean → 🟢 Positive alert
-prior week's report has been generated.
+- >2 standard deviations below mean → 🔴 Critical alert
 - Between 1-2 standard deviations below → 🟡 Warning alert
 **Present alerts as:**
 ```
@ -247,7 +245,7 @@ Your post on [topic] achieved 12,500 impressions — a personal best!
 → **Reference:** First-hour velocity of 15+ engagements unlocks broader distribution.
 🟡 **Warning: Format stagnation detected**
-80%+ of your recent posts are text-only. Documents/carousels are the top organic format and tend to reach further (no reliable multiplier).
+80%+ of your recent posts are text-only. PDF/Carousels get 3.4x reach multiplier.
 → **Action:** Try a carousel or multi-image post this week for format diversification.
 ```
@ -257,7 +255,7 @@ Format the data into a readable report using this template:
 ```
 # LinkedIn Performance Report
-## Week {week}
+## Week {week} ({dateRange})
 ### 📊 Key Metrics
@ -269,8 +267,8 @@ Format the data into a readable report using this template:
 | Shares | {total} | {avg} | {trend} |
 | Engagement Rate | - | {rate}% | {trend} |
-**Posts published:** {summary.totalPosts}
+**Posts published:** {postCount}
-**Engagement rate:** {summary.avgEngagementRate}%
+**Engagement rate:** {totalEngagements / totalImpressions * 100}%
 ### 🏆 Top Performers
@ -358,13 +356,13 @@ If user wants more trend analysis:
 ```bash
 # Analyze comments trend
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric comments
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric comments
 # Analyze shares trend
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric shares
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric shares
 # Analyze engagement rate trend
-"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric engagementRate
+ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" trends --period month --metric engagementRate
 ```
 Present additional insights from these trends.
@ -376,9 +374,7 @@ If user wants to analyze specific posts:
 Read the weekly post data directly:
 ```bash
-for f in ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/*.json; do
+cat ${CLAUDE_PLUGIN_ROOT}/assets/analytics/posts/<YYYY-WXX>.json | jq '.posts[] | select(.title | contains("search term"))'
  jq '.posts[] | select(.title | contains("search term"))' "$f"
 done
 ```
 Show detailed metrics for that post and suggest what made it perform well/poorly.
@ -388,7 +384,7 @@ Show detailed metrics for that post and suggest what made it perform well/poorly
 **If report generation fails:**
 1. **Week not found**: No data imported for that week
-   - List available weeks: `ls ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/`
+   - List available weeks: `ls ${CLAUDE_PLUGIN_ROOT}/assets/analytics/posts/`
   - Suggest importing data for that week
 2. **No posts in week**: Week file exists but is empty
@ -412,9 +408,10 @@ Read `~/.claude/linkedin-studio.local.md` and suggest:
 ## Reference Files
 Reports use data from:
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/YYYY-MM-DD-<shortid>.json` - Raw imported batches (one file per import; rows live under `.posts[]`)
+- `assets/analytics/posts/YYYY-WXX.json` - Raw weekly post data
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/YYYY-WXX.json` - Computed weekly report
+- `assets/analytics/weekly-reports/YYYY-WXX.json` - Computed report
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/monthly-reports/YYYY-MM.json` - Computed monthly report
+- `assets/analytics/baselines.json` - Statistical baselines for comparison
 - `assets/analytics/metadata.json` - Import history and tracking
 ## Step 8b: Export Options
@ -424,12 +421,12 @@ If the user chooses option 4 ("Export report as markdown file") from the deep di
 1. Read the JSON report data:
 ```bash
-cat ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/<YYYY-WXX>.json
+cat ${CLAUDE_PLUGIN_ROOT}/assets/analytics/weekly-reports/<YYYY-WXX>.json
 ```
 2. Format the data using this template and write to file:
-Save to: `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/YYYY-WXX-report.md`
+Save to: `${CLAUDE_PLUGIN_ROOT}/assets/analytics/weekly-reports/YYYY-WXX-report.md`
 ```markdown
 # LinkedIn Performance Report — Week YYYY-WXX
@ -481,13 +478,13 @@ Save to: `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekl
 ```
 **Important notes:**
- The `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/` directory is gitignored — exported reports contain personal analytics data and should not be committed
+- The `assets/analytics/` directory is gitignored — exported reports contain personal analytics data and should not be committed
 - Use the `-report.md` suffix to distinguish from the JSON data files (e.g., `2026-W05-report.md` vs `2026-W05.json`)
 - Include all sections: metrics, trends, alerts, top performers, and recommendations for a complete standalone document
 After saving, confirm to the user:
 ```
-Report exported to: ${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/weekly-reports/YYYY-WXX-report.md
+Report exported to: assets/analytics/weekly-reports/YYYY-WXX-report.md
 Note: This file is in your gitignored analytics directory — it won't be committed to the repository.
 ```
--- a/commands/setup.md
+++ b/commands/setup.md
@ -26,14 +26,14 @@ Read these 8 asset files and detect placeholder patterns to calculate the curren
 | Category | Weight | File/Directory | Placeholder Detection |
 |----------|--------|----------------|----------------------|
-| Voice samples | 25 | `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` | Placeholder if it contains the `<!-- VOICE_PLACEHOLDER -->` sentinel (or has <50 lines) |
+| Voice samples | 25 | `assets/voice-samples/authentic-voice-samples.md` | Placeholder if it contains the `<!-- VOICE_PLACEHOLDER -->` sentinel (or has <50 lines) |
-| User profile | 20 | `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md` | Check if file exists; count `[Your ` placeholders |
+| User profile | 20 | `config/user-profile.local.md` | Check if file exists; count `[Your ` placeholders |
-| Case studies | 15 | `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/case-studies/*.md` | Count non-template `.md` files (exclude `case-study-template.md`) |
+| Case studies | 15 | `assets/case-studies/*.md` | Count non-template `.md` files (exclude `case-study-template.md`) |
-| Frameworks | 10 | `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/frameworks/*.md` | Count non-template `.md` files (exclude `framework-template.md`) |
+| Frameworks | 10 | `assets/frameworks/*.md` | Count non-template `.md` files (exclude `framework-template.md`) |
-| High-engagement posts | 10 | `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md` | Count `## Post N:` headers |
+| High-engagement posts | 10 | `assets/examples/high-engagement-posts.md` | Count `## Post N:` headers |
-| Demographics | 8 | `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/demographics.md` | Count `[Industry name]`, `[Function]`, `[Country]`, `[X]%` |
+| Demographics | 8 | `assets/audience-insights/demographics.md` | Count `[Industry name]`, `[Function]`, `[Country]`, `[X]%` |
-| Engagement patterns | 7 | `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/engagement-patterns.md` | Count `[Day]`, `[Time]`, `[Topic]`, `[Format]`, `[Hook type]` |
+| Engagement patterns | 7 | `assets/audience-insights/engagement-patterns.md` | Count `[Day]`, `[Time]`, `[Topic]`, `[Format]`, `[Hook type]` |
-| Post templates | 5 | `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/templates/my-post-templates.md` | Count `[Name - e.g.` vs total `## Template N:` headers |
+| Post templates | 5 | `assets/templates/my-post-templates.md` | Count `[Name - e.g.` vs total `## Template N:` headers |
 **Scoring rules:**
 - Full points: Asset has real data (few/no placeholders remaining)
@ -81,7 +81,7 @@ Based on their answer, run the corresponding sub-workflow below.
 ## Step 3a: Voice Samples Workflow
-**Goal:** Populate `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md` with real voice data.
+**Goal:** Populate `assets/voice-samples/authentic-voice-samples.md` with real voice data.
 **Delegate the analysis + profile construction to the `voice-trainer` agent** — invoke it via `Task` with `subagent_type: linkedin-studio:voice-trainer` (foreground, from this command layer). The agent performs the pattern detection and extraction (steps 2–3 below) and returns the structured voice profile; this command owns collecting the samples (step 1) and writing the profile back to disk (steps 4–6).
@ -98,7 +98,7 @@ Based on their answer, run the corresponding sub-workflow below.
   - Words/phrases they avoid
   - How they handle technical depth
   - How they conclude (CTA style, takeaway style)
-4. Read the existing `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/authentic-voice-samples.md`
+4. Read the existing `assets/voice-samples/authentic-voice-samples.md`
 5. **If the file is the shipped placeholder** (it contains `<!-- VOICE_PLACEHOLDER -->`):
   **REPLACE it entirely** with the profile built from the user's samples. The
   placeholder's `<!-- VOICE_PLACEHOLDER -->` sentinel must NOT survive — if it
@ -117,7 +117,7 @@ Based on their answer, run the corresponding sub-workflow below.
 ## Step 3b: Case Study Builder
-**Goal:** Create a new case study file in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/case-studies/`.
+**Goal:** Create a new case study file in `assets/case-studies/`.
 Conduct a 6-question interview:
@ -130,7 +130,7 @@ Conduct a 6-question interview:
 After the interview, read `assets/case-studies/case-study-template.md` for structure reference, then create a new file:
-**Filename:** `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/case-studies/[slug].md` (derive slug from the challenge topic, e.g., `ai-procurement-transformation.md`)
+**Filename:** `assets/case-studies/[slug].md` (derive slug from the challenge topic, e.g., `ai-procurement-transformation.md`)
 **File structure:**
 ```markdown
@ -172,7 +172,7 @@ Ask "Would you like to document another case study?" when done.
 ## Step 3c: Framework Documenter
-**Goal:** Create a new framework file in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/frameworks/`.
+**Goal:** Create a new framework file in `assets/frameworks/`.
 Conduct a 5-question interview:
@ -184,7 +184,7 @@ Conduct a 5-question interview:
 After the interview, read `assets/frameworks/framework-template.md` for structure reference, then create:
-**Filename:** `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/frameworks/[slug].md` (e.g., `ai-maturity-model.md`)
+**Filename:** `assets/frameworks/[slug].md` (e.g., `ai-maturity-model.md`)
 **File structure:**
 ```markdown
@ -228,12 +228,12 @@ Ask "Would you like to document another framework?" when done.
 ## Step 3d: Post Analysis
-**Goal:** Document high-engagement posts in `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md`.
+**Goal:** Document high-engagement posts in `assets/examples/high-engagement-posts.md`.
 Two approaches — ask which they prefer:
 ### Option A: Analytics Data Available
-If the user has imported analytics data (check `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/posts/` for JSON files):
+If the user has imported analytics data (check `assets/analytics/posts/` for JSON files):
 1. Read the most recent analytics data files
 2. Identify the top 3-5 posts by engagement rate
@ -253,11 +253,11 @@ If no analytics data available:
 2. For each post, analyze and document:
   - **Hook analysis:** What made the opening effective?
-   - **Angle identification:** Which content angle was used?
+   - **Angle identification:** Which thought leadership angle was used?
   - **Pattern extraction:** What's replicable?
   - **Mistakes identified:** What could be improved?
-3. Read the existing `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md`
+3. Read the existing `assets/examples/high-engagement-posts.md`
 4. **Append** new posts after existing entries (don't overwrite)
 5. Update the "Patterns Across All High-Performing Posts" section based on all posts
@ -265,7 +265,7 @@ Ask "Would you like to add more posts?" when done.
 ## Step 3e: Demographics Sync
-**Goal:** Populate `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/demographics.md` with real LinkedIn Analytics data.
+**Goal:** Populate `assets/audience-insights/demographics.md` with real LinkedIn Analytics data.
 Guide the user step by step through the LinkedIn Analytics UI:
@ -286,7 +286,7 @@ Guide the user step by step through the LinkedIn Analytics UI:
   - Record the actual data
   - Ask about trends ("Is this similar to previous months?")
-5. Read the existing `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/audience-insights/demographics.md`
+5. Read the existing `assets/audience-insights/demographics.md`
 6. Replace the placeholder tables with real data
 7. Fill in the "Key insights" sections based on the data patterns
 8. Update the "Last Updated" date
@ -300,7 +300,7 @@ If the user says they don't have LinkedIn Analytics access or data yet, suggest:
 ## Step 3f: User Profile Setup
-**Goal:** Create or update `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md`.
+**Goal:** Create or update `config/user-profile.local.md`.
 Guide through each section of the profile:
@ -314,13 +314,13 @@ Guide through each section of the profile:
   - "These should be topics you can consistently create content about for 90+ days"
 3. **Target audience:**
-   - "Who is your primary audience? (e.g., 'CFOs at mid-size SaaS companies' or 'public-sector IT leaders')"
+   - "Who is your primary audience? (e.g., 'Public sector leaders exploring AI')"
   - "Secondary audience?"
   - "Geographic focus?"
 4. **LinkedIn goals:**
   - "Rank these goals from most to least important:"
-     - Build authority & influence
+     - Build thought leadership & authority
     - Attract speaking opportunities
     - Network with peers/influencers
     - Generate qualified leads
@ -336,13 +336,8 @@ Guide through each section of the profile:
   - "Current follower count?"
   - "90-day growth goal?"
-7. **Research tooling:**
+7. Read `config/user-profile.template.md` for structure
-   - "Which research MCPs do you have connected? (e.g., Tavily, Gemini deep research, Perplexity — or none)"
+8. Write the completed profile to `config/user-profile.local.md`
   - Record exactly what they name. If they have none, that's fine — WebSearch + WebFetch are the always-available floor.
   - This populates the **Research Tooling** section of the profile; the trend/research engine routes to a declared MCP first and falls back to the floor. Do not invent MCP names — store only what the user declares.
 8. Read `config/user-profile.template.md` for structure
 9. Write the completed profile to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/user-profile.md`
 **Important:** This file is gitignored (`.local.md` pattern), so personal data stays private.
--- a/commands/strategy.md
+++ b/commands/strategy.md
@ -13,6 +13,7 @@ allowed-tools:
  - Read
  - Glob
  - Grep
  - WebFetch
  - AskUserQuestion
  - Task
 ---
@ -64,7 +65,7 @@ Use AskUserQuestion to gather information (skip follower question if auto-detect
   - Inconsistent (gaps of 1+ weeks)
 3. What are your main goals? (Choose top 2)
-   - Build authority & influence
+   - Build thought leadership & authority
   - Attract speaking opportunities
   - Network with peers/influencers
   - Generate consulting/business leads
@ -231,7 +232,7 @@ Delegate the growth recommendation to the `strategy-advisor` agent — invoke it
 | Activity | Frequency | Purpose |
 |----------|-----------|---------|
 | Core expertise posts | 3-5x/week | Maintain authority |
-| Signature pieces | 2-3x/month | Differentiation |
+| Thought leadership pieces | 2-3x/month | Differentiation |
 | Speaking/podcasts | Monthly | Off-platform visibility |
 | Collaboration amplification | 2x/month | Network leverage |
 | Lead magnets | Create 1-2 | Funnel building |
@ -293,7 +294,7 @@ For the canonical profile-alignment audit (headline/About/Experience/Featured/Sk
 ### Identify Signature Content
-Ask the user to identify their top-performing posts (or read analytics from `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/`).
+Ask the user to identify their top-performing posts (or read analytics from `${CLAUDE_PLUGIN_ROOT}/assets/analytics/`).
 **Signature content criteria:**
 - High saves — bookmarking is a strong authority signal; read the count from your native LinkedIn post analytics (this tool does not capture saves)
@ -392,7 +393,7 @@ Medium-term (This Quarter):
 6. [Collaboration opportunity]
 Long-term (6 Months):
-7. [Authority milestone]
+7. [Thought leadership milestone]
 8. [Platform expansion]
 ```
--- a/commands/trends.md
+++ b/commands/trends.md
@ -1,169 +0,0 @@
 ---
 name: linkedin:trends
 description: |
  Run a trend discovery pass over the user's own content pillars and source list:
  delegate the scan to the trend-spotter agent, make sure kept candidates are persisted
  to the trend store (dedup) and the dated morning brief is written, then return a
  triage-ranked candidate list the user resolves per id (select/skip, batched). Default scoring mode
  is long-form (chronicle/newsletter material); `--mode kortform` overrides for feed posts.
  Use when the user wants a discovery pass, a trend scan, or a morning-brief refresh.
  Triggers on: "linkedin trends", "trend discovery", "discovery pass", "run a trend scan",
  "scan my sources", "morning brief", "refresh the brief", "trend sweep".
 allowed-tools:
  - Read
  - Bash
  - Task
  - AskUserQuestion
 ---
 # LinkedIn Trend Discovery
 You are a thin discovery orchestrator. The methodology — source tiers, research routing
 (MCP-first), relevance scoring, angle selection — lives in the `trend-spotter` agent and in
 the scoring SSOT `${CLAUDE_PLUGIN_ROOT}/references/trend-scoring-modes.md`. Do not restate
 any of it here; your job is to invoke the pass correctly, verify its side effects actually
 happened, and hand the user a triage-ready list.
 Data dir shorthand used below: `${DATA}` = `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}`.
 Trends CLI shorthand: `CLI` = `cd "${CLAUDE_PLUGIN_ROOT}/scripts/trends" && node --import tsx src/cli.ts`.
 ## Step 0: Parse flags
 All flags are optional, given after the command name:
 | Flag | Meaning | Default |
 |------|---------|---------|
 | `--mode kortform\|long-form` | Scoring mode (see the SSOT for what each rewards) | **long-form** — no arguments means a long-form discovery pass |
 | `--fresh-days N` | Freshness window for the morning brief | CLI default (7) |
 | `--brief-only` | Skip the discovery poll entirely; render the brief from the existing store | off |
 | `--demand` | Run the **demand-sweep** (`demand-spotter`, «innenfra og ut») instead of supply-side discovery: poll where readers ASK, fill the reader fields, render the §4 arc map | off |
 | `--dry-run` | Poll + score, but persist nothing: no capture, no brief, no status writes, no last-run marker | off |
 Note the mode inversion deliberately: the **agent's** own default is kortform, this
 **command's** default is long-form. That is why Step 2 must always pass the mode explicitly.
 **`--demand` reroutes the pass** (Step 2D below) to the demand side — a different agent
 (`demand-spotter`), a different unit (the arc/åre, not the news-item), a different output (the §4
 arc map, not the pillar brief). The two are complementary: run discovery to find *what happened*,
 then `--demand` on a chosen theme to see *what the reader is stuck on*.
 ## Step 1: Load context
 1. **Pillars:** Read `${DATA}/profile/user-profile.md` and extract the content pillars /
   expertise areas. If the file does not exist, ask the user for their pillars before
   proceeding (one question, comma-separated answer).
 2. **Source list:** Resolve which list this pass will use — `${DATA}/trends/sources.md` if it
   exists, otherwise the shipped defaults `${CLAUDE_PLUGIN_ROOT}/config/trends-sources.template.md`.
   Tell the user which one applies. Do not read research-tooling or route research yourself —
   the agent owns Research Routing (its own "Research Routing" section reads the profile's
   `### Research Tooling` block); duplicating it here would drift.
 ## Step 2D: Run the demand-sweep (only on `--demand`)
 **If `--demand`:** this replaces Steps 2–4 (the supply-side discovery pass). Delegate to the
 demand-spotter agent — invoke it via `Task` with `subagent_type: linkedin-studio:demand-spotter`
 (foreground). The prompt MUST state explicitly:
 - The pillars and the resolved source-list path from Step 1 (its **Tier 5** demand sources are what
  this pass polls — the inverse of the Tier 1–4 supply sources).
 - The theme(s) to sweep (from `--topics` if given, else the user's pillars).
 - That the three passes are mandatory: demand-sweep (verbatim questions + signal strength + is-it-answered) → pain-point map (fills `painPoint`) → vocabulary translation (fills `readerQuestion`).
 - That persistence is **mandatory unless `--dry-run`**: the agent runs `capture` with the reader
  fields (`readerQuestion`/`painPoint`/`saturation`/`demand`/`verdict`/`actionability`), then renders
  the §4 arc map with `CLI arcs`.
 - That an **honest null is a finding** — a thin/un-swept source is reported, never filled in.
 Then present the arc map the agent returns: per vein, the ranked question inventory (reader's words),
 the honest market verdict (supply-gap = write here · demand-gap = high-value/low-audience · saturated
 = skip), and the BÆRENDE/STØTTE reading order. On `--dry-run`, present the same map but state that
 nothing was persisted. **Skip Steps 2–4.** Hand off: a chosen vein feeds `/linkedin:newsletter`
 Step 1 (its reader question, pain point, and angle prefill the edition).
 ## Step 2: Run the discovery pass
 **If `--brief-only`:** skip the agent entirely — go to Step 3 and render the brief from the
 existing store.
 Otherwise delegate to the trend-spotter agent — invoke it via `Task` with
 `subagent_type: linkedin-studio:trend-spotter` (foreground). The prompt MUST state explicitly:
 - **The scoring mode** from Step 0 (default long-form). Never omit it — the agent falls back
  to kortform when the caller is silent.
 - The pillars and the resolved source-list path from Step 1.
 - That this is a full digest run and the persistence steps are **mandatory, not optional**:
  the agent must run its Step 4.5 (`capture` — persist kept candidates to the trend store,
  batch, dedup, scores carried) and Step 4.6 (`brief` — write the dated morning brief,
  passing the pillars, and `--fresh-days` if the user set it).
 - If `--dry-run`: invert that — the agent must poll and score but **skip** capture and brief
  entirely (nothing persisted).
 - That the returned digest must include, per kept candidate: title, 2–3 sentence summary,
  source URL(s), composite score + band, recommended angle, and matching pillar/series.
 ## Step 3: Verify the side effects (skip on `--dry-run`)
 Trust but verify — the pass is only done when its artifacts exist:
 1. **Store:** `CLI status --json` — confirm the store mutated (captured count reflects the
   run; on a no-new-trends day `{added: 0, merged: N}` is a fine outcome, not a failure).
 2. **Brief:** confirm today's file exists: `${DATA}/trends/morning-brief/<today YYYY-MM-DD>.md`.
   If the agent captured but failed to render the brief, render it directly — the brief is
   deterministic: `CLI brief --pillars "<pillar1,pillar2,…>"` (add `--fresh-days N` if set).
 3. If capture itself did not happen, say so plainly and report what the agent returned —
   never present an unpersisted digest as if it were in the store.
 ## Step 4: Present the triage-ranked list
 Present the candidates ranked highest composite first (the agent's digest already carries the
 ranking — do not re-rank). Per candidate, the contract is:
 ```
 N. [Title]  (id: <trend-id>)
   Score: X.X — [Band]  |  Pillar: [pillar/series]
   [2–3 sentence summary]
   Source: [URL(s)]
   Angle: [recommended angle]
 ```
 Include each candidate's store id (shown in the brief and via `CLI list --json`) — the triage
 step below resolves per id. On `--dry-run`, present the same list but say clearly that nothing
 was persisted and there are no store ids to triage.
 ## Step 5: Triage (skip on `--dry-run`)
 Resolve the top of the queue now instead of leaving it as homework. For the candidates in the
 top bands (Immediate + High; cap at 8), use AskUserQuestion — one question per candidate, up
 to 4 candidates per call, options:
 - **Velg** — you'll write about this: mark `selected`, moving it onto the brief's "I produksjon"
  board (valgt) so the queue stops re-surfacing it while it's in progress
 - **Skip** — not for me: mark `skipped` (dropped from the queue)
 - **Leave** — keep it in the queue untouched
 Then apply the decisions through the store CLI. **Batch by verb** — collect all the "Velg" ids
 and all the "Skip" ids and resolve each set in ONE call (ten candidates ≤ two calls):
 ```bash
 CLI select --ids <id1,id2,id3>    # everything chosen this pass
 CLI skip   --ids <id4,id5>        # everything rejected this pass
 ```
 Single-id form (`--id <id>`) still works for a one-off. "Leave" means no call. A partial batch
 (some id unknown) still applies the matches, reports the misses, and exits 0. Finish with a
 one-line summary: N valgt, N skipped, N left in queue. (`act` — already written — and the
 auto-`act` when an edition reaches scheduling arrive with the N7 trend→newsletter bridge.)
 ## Step 6: Write the last-run marker (skip on `--dry-run`)
 On completed runs (including `--brief-only`), stamp the marker so other surfaces can tell when
 discovery last ran:
 ```bash
 mkdir -p "${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends" && \
  date -u +"%Y-%m-%dT%H:%M:%SZ" > "${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends/.last-run"
 ```
 ## Reference Files
 - `${CLAUDE_PLUGIN_ROOT}/references/trend-scoring-modes.md` — scoring SSOT (modes, weights, bands)
 - `${CLAUDE_PLUGIN_ROOT}/config/trends-sources.template.md` — shipped source-list defaults (user override: `${DATA}/trends/sources.md`)
 - `${CLAUDE_PLUGIN_ROOT}/agents/trend-spotter.md` — the discovery methodology this command invokes
--- a/commands/video.md
+++ b/commands/video.md
@ -39,10 +39,8 @@ Load video-specific references:
 - Read `references/linkedin-formats.md` (Video Content Deep Dive section) for algorithm data and technical specs
 Check for existing assets:
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/` — Match the user's natural voice (read before scripting)
+- `assets/voice-samples/` — Match the user's natural voice (REQUIRED before scripting)
- `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/examples/high-engagement-posts.md` — Study successful patterns
+- `assets/examples/high-engagement-posts.md` — Study successful patterns
 **Graceful degradation (fresh adopter):** if `voice-samples/` is empty or absent, don't block — fall back to the voice settings in `skills/linkedin-studio/SKILL.md` (or neutral defaults), note that the script uses a default voice, and proceed. The voice-guardian is suppressed under 5 samples, so there is no hard gate to satisfy.
 ## Step 1: Choose Video Type
@ -66,14 +64,14 @@ Use AskUserQuestion:
 3. **90 seconds** (225 words) — Extended format for complex frameworks (use sparingly)
 4. **2 minutes** (300 words) — Detailed story or multi-step process (retention drops significantly)
-Default recommendation: **60 seconds** is the 2026 sweet spot — shorter videos complete at higher rates, and completion/dwell is a ranking input the algorithm rewards (see `references/algorithm-signals-reference.md`). There is no published hard completion-rate gate — favour shorter to lift completion, not to clear a threshold.
+Default recommendation: **60 seconds** is the 2026 sweet spot — LinkedIn requires 30% minimum completion rate or your video gets zero distribution. Shorter videos achieve higher completion rates and the algorithm rewards that heavily.
 ## Step 3: Topic and Angle Selection
 Follow the same flow as `/linkedin:post`:
 1. Ask what they want the video to be about (if not already clear)
-2. Read `references/content-angles.md` for the 8 universal angles
+2. Read `references/thought-leadership-angles.md` for the 8 universal angles
 3. Present 2-3 angle options via AskUserQuestion
 4. Verify topic doesn't duplicate recent posts (check state file)
 5. Confirm topic aligns with user's 5 core expertise areas
@ -89,7 +87,7 @@ Delegate script generation to the `video-scripter` agent — invoke it via `Task
   - Visual cues (`[CAM:]`, `[SCREEN:]`, `[SLIDE:]`, `[TEXT:]`)
   - Energy cues (`[ENERGY: up]`, `[PAUSE: 1s]`)
   - Transition markers (`[CUT]`, `[TRANSITION:]`)
-4. Match voice against `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/voice-samples/`
+4. Match voice against `assets/voice-samples/`
 5. Generate captions, thumbnail suggestion, post caption, and first comment
 ## Step 5: Quality Check
@ -126,7 +124,7 @@ Before presenting, verify the script passes the video quality gate:
 ### De-AI / Differentiation Gate
-The post caption rides the same low-substance down-rank LinkedIn confirmed for text. Confirm the script's core idea and caption carry the signals LinkedIn named — **personal substance, original thinking, concrete specifics, genuine voice** — and use no mechanical-response engagement bait ("Comment YES", "Like for Part 2"); a genuine question is fine. (The voice-guardian hook scores the caption on save.) **Strip corporate buzzwords** from the post caption (Content Quality Rule #4: leverage, synergy, paradigm shift, thought leader, disruptive, value proposition, ecosystem, holistic approach) — re-shaping a text idea into a video caption can slip them in, and they trip the same low-substance signal.
+The post caption rides the same low-substance down-rank LinkedIn confirmed for text. Confirm the script's core idea and caption carry the signals LinkedIn named — **personal substance, original thinking, concrete specifics, genuine voice** — and use no mechanical-response engagement bait ("Comment YES", "Like for Part 2"); a genuine question is fine. (The voice-guardian hook scores the caption on save.)
 If the idea is a take the audience has seen many times — commodity content — delegate an originality pass to the `differentiation-checker` agent: invoke it via `Task` with `subagent_type: linkedin-studio:differentiation-checker` (foreground, from this command layer), then sharpen the angle before presenting.
@ -143,7 +141,7 @@ Type:     [talking head / screen recording / slideshow]
 Length:   [30s / 60s / 90s / 2min]
 Words:    [count] (at 2.5 wps)
 Topic:    [content pillar alignment]
-Angle:    [from 8 content angles]
+Angle:    [from 8 thought leadership angles]
 ━━━ SCRIPT ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
@ -172,11 +170,9 @@ Style: [minimal / branded / text-heavy]
 Auto-copy the POST CAPTION text to clipboard silently:
 ```bash
-node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs <<'__LINKEDIN_CLIP_EOF__'
+printf '%s' '<POST_CAPTION_TEXT>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs
 <POST_CAPTION_TEXT>
 __LINKEDIN_CLIP_EOF__
 ```
-Substitute `<POST_CAPTION_TEXT>` with the exact caption text between the heredoc markers (a quoted heredoc keeps apostrophes, `%`, `$`, and backticks literal). Only if the helper prints `COPIED`, confirm: "Post caption copied to clipboard." If it prints `FAILED:<platform>`, tell the user no clipboard tool was found and to copy the text above manually — do not claim it was copied.
+Then confirm: "Post caption copied to clipboard."
 ## Step 7: Refinement Cycle
@ -194,7 +190,7 @@ Iterate until satisfied.
 ## Step 8: Save and Update State
-Save the final script to `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/drafts/`:
+Save the final script to `assets/drafts/`:
 ```
 video-[YYYY-MM-DD]-[slug]-[type]-[length].md
@ -235,6 +231,6 @@ Replace placeholders with actual post data. This replaces manual YAML editing.
 - `references/video-strategy-guide.md` — Script templates, pacing, production
 - `references/linkedin-formats.md` — Video specs, algorithm, technical requirements
 - `references/engagement-frameworks.md` — Hook types, CTAs
- `references/content-angles.md` — 8 universal angles
+- `references/thought-leadership-angles.md` — 8 universal angles
 - `references/algorithm-signals-reference.md` — Algorithm mechanics
 - `assets/checklists/quality-scorecard.md` — Pre-publish check
--- a/config/content-history.template.md
+++ b/config/content-history.template.md
@ -0,0 +1,18 @@
 # Content History Log
 Tracks all LinkedIn posts created through the plugin. Append-only — never edit existing entries.
 Auto-initialized from `config/content-history.template.md` when the first post is logged.
 ## Format
 | Date | Hook | Topic | Format | Words | Chars | Source |
 |------|------|-------|--------|-------|-------|--------|
 <!-- Entries are appended below by the Stop hook -->
 <!-- Format: | YYYY-MM-DD | "Hook text (60 chars max)..." | topic_area | post/quick/react/video | word_count | char_count | original/url/curated | -->
 ## Content Log
 | Date | Hook | Topic | Format | Words | Chars | Source |
 |------|------|-------|--------|-------|-------|--------|
--- a/config/edition-state.template.json
+++ b/config/edition-state.template.json
@ -7,13 +7,11 @@
    "phases": [
      "load-context — read <serie>/STATE.md, voice profile, persona library, series brief (Step 0)",
      "brief-calibration — angle, voice, audience personas, key points, leader-takeaway (Step 1)",
-      "lived-specifics — elicitation interview (3–5 sharp questions, vagueness refused) → add lived material to the specifics-bank + populate articles.NN.livedSpecifics slot-map (each load-bearing key-point bound specific/abstrakt/ekstern/unresolved) → render NN-kilder.md; BETWEEN brief (Step 1) and research (Step 2). The grounded-sourcing layer (Fix #2, kilde-så-draft; never fabricated — invariant 3). The BLOCKing «vaghet avvises» gate (validateBinding) is enforced at the Step 2.5 skeleton-gate (Step 1.5)",
+      "research — parallel scoped mandates → verified notes, triangulation (Step 2)",
      "research — parallel scoped mandates → verified notes, triangulation; scoped BY the binding (fills ekstern/unresolved slots + verifies the operator's own numbers, regel 6/7) (Step 2)",
      "skeleton-pitch — five-line skeleton (premise/problem/recommendation/payoff/forward) + section pitches, operator gate + persona-skjelett-sweep BEFORE prose (Step 2.5)",
      "spine-prose — one paragraph per section against the gated skeleton, operator gate BEFORE full expansion (Step 3a)",
      "draft — full prose expansion against the gated spine; may span sessions (Step 3b)",
      "consistency-quality — threads, premise→conclusion arc, AI-slop removal, formatting dose (Step 4)",
      "contract-gate — deterministic §B/§C1 rule-gate over the draft (scripts/contract-gate, rules.ts), bound 1:1 to the maskinrommet skrivekontrakt §E-manifest via ratify; mechanical violations die here before the AI sweeps (Step 4.5)",
      "factcheck-sweep — risk-sorted, guilty-until-disproven, verification log (Step 5)",
      "editorial-review — editor's craft gate: prose-craft (em-dash density, verbatim repetition, postulated numbers, contradictions, versal-tic) + narrative-architecture (concrete instantiation, theory-anchored hypotheses, series-title symmetry, equal action per addressee, un-overloaded conclusion), ≤10 flags BLOCK/REWORK/NICE, operator-gated via SendUserFile BEFORE the persona sweep (Step 5.5)",
      "persona-sweep-prelock — reader jury, primary wins, convergence to clean YES (Step 6)",
@ -25,17 +23,12 @@
      "scheduling — register edition in plugin queue/state for native LinkedIn scheduling (Step 10)"
    ],
    "articleStatusValues": ["pending", "in-progress", "locked", "scheduled"],
    "phaseLog": "Per-article phase-transition log (N12 / A1-12) — the raw material for measuring lead time. Additive-optional (default [], NO schemaVersion bump — same pattern as sourceTrendId/targetLevel/language; an edition produced before N12 simply has none and the register treats its absence as \"not measured\"). Shape: [ { phase, completedAt } ] in transition order, where phase is one of the canonical _doc.phases identifiers and completedAt is an ISO-8601 timestamp. Written DETERMINISTICALLY, never by hand: every /linkedin:newsletter phase transition runs `scripts/editions` (`node --import tsx src/cli.ts register-upsert --edition-state <path>`), which appends the entry for the just-written currentPhase AND mirrors the edition into the editions register (${LINKEDIN_STUDIO_DATA}/editions/register.json) in one call — the log and the register cannot drift apart because nothing writes one without the other. Idempotent against an immediately repeated transition (a re-run of the same step logs once), but a phase that recurs AFTER another one is logged again: /linkedin:pivot legitimately sends an edition back through cleared gates, and that second pass is real production time. Per-article rather than top-level because lead time is a property of an edition, mirroring articles.NN.phase. The register is a MIRROR of this file, never a source of truth — losing it costs telemetry, not an edition.",
    "editorialReview": "Per-article editorial-review record written by Step 5.5 (editorial-review phase). Runs AFTER fact-check (Step 5) and BEFORE the persona sweep (Step 6): the editorial-reviewer agent judges CRAFT (prose-craft + narrative-architecture), not reader-response, mirroring the Maskinrommet skrivekontrakt §C2. The report (≤10 flags, each with kategori P1–P5/A1–A5, quote/line-ref, direction, severity BLOCK/REWORK/NICE) is surfaced to the operator via SendUserFile; the operator decides which flags fold in. Shape: { reportPath, flagCount, byAxis: { prosa, arkitektur }, bySeverity: { block, rework, nice }, foldedIn, waived, status }. status ladder: pending → reviewed → folded. null until Step 5.5 runs. This is the craft companion to factcheckLog (truth) and personaSweep (response).",
    "visualAssets": "Per-article visual-asset record written by Step 7.5 (visual-assets phase). Runs BEFORE lock because render/build-linkedin.mjs picks up linkedin/NN/cover.png + the edition-config credit/caption when it builds POST.html — generating images after lock would force a re-render. Shape: { format: \"standard\" | \"carousel\"; cover: { brief, route, candidates[], approved, status }; figures: [ { id, brief, placement, status } ]; carousel: null | { source, pdf, status } }. format \"standard\" = cover + optional inline figures (cover.png is mandatory per the KTG cover-directive); format \"carousel\" = typografisk deck via render/build-carousel.mjs instead of cover+inline (cover/figures stay empty). route: \"mcp-image\" (default, via mcp__mcp-image__generate_image) | \"external\" (DALL·E / Midjourney / photographer → linkedin/NN/cover-raw.png). status ladder: pending → briefed → generated → approved. candidates[] holds the cover-v<N>-kandidat.png attempts; approved is the fixed approved name (\"cover.png\") once the operator-gate passes. figures[].id = \"fig1\"..; placement = section reference in NN-utkast.md (figures are referenced in the draft via ![alt](linkedin/NN/figN.png) and uploaded manually in the LinkedIn editor — build-linkedin.mjs does NOT embed them). Naming convention: cover.png (approved, fixed — what build-linkedin.mjs reads) | cover-v<N>-kandidat.png (attempts) | cover-raw.png (optional external pre-edit source) | fig<N>.png (inline). credit + caption are recorded in <serie>/linkedin/image-credit-caption.md and flow into edition-config.json coverCredit + captions[NN].",
    "livedSpecifics": "Per-article lived-specifics binding (Fix #2 slice 2, kilde-så-draft). A slot-map binding each LOAD-BEARING key-point (or, later, section) of this edition to either a real specific from the specifics-bank OR an explicit escape decision — so a draft starts grounded in the operator's real material instead of inventing plausible filler. Resolved at Step 1.5 (lived-specifics extraction, BETWEEN brief (Step 1) and research (Step 2); wired in slice 3) via a guided interview that REFUSES vague answers. THE GATE (drømme-spec G4, «vaghet avvises», enforced at the Step 2.5 skeleton-gate): every slot must resolve to \"specific\" (grounded), \"abstrakt\" (deliberately abstract here, with a rationale), or \"ekstern\" (backed by research, not lived material) — a slot left \"unresolved\" is the vagueness that BLOCKs. Numbers stay guilty-until-checked: a slot backed by an UNVERIFIED number is allowed but WARNED (regel 6/7), so Step 2 research verifies it before the draft asserts it. The deterministic validator + the rendered NN-kilder.md artifact live in scripts/specifics-bank (binding.ts/kilder.ts; `node --import tsx src/cli.ts validate-binding|render-kilder --edition <edition-state.json>`). Shape: { slots: [ { slotId, kind: \"key-point\" | \"section\", label, binding: ({ type: \"specific\", specificId } | { type: \"abstrakt\", rationale } | { type: \"ekstern\", source? } | { type: \"unresolved\" }) } ], status: \"pending\" | \"bound\" }. Default { slots: [], status: \"pending\" }: populated on first Step 1.5. Companion artifact: <serie>/linkedin/NN-kilder.md, rendered from this + the bank (regenerated, never hand-edited). This is the per-edition consumer of the global specifics-bank.",
    "personas": "Per-article resolved reader-persona set (input config), written/confirmed in Step 1. This makes personas configurable PER ARTIFACT, not just from one global plugin library: Step 1 resolves them in order — (1) already present here → use as-is; (2) <serie>/linkedin/personas.md (per-series file) → load; (3) plugin config/personas.local.md (or personas.template.md) library → select a subset; (4) none/insufficient → DEFINE interactively via AskUserQuestion. Exactly one entry has tier \"primær\" (the rest \"sekundær\"); «primær trumfer» on conflict. This set feeds BOTH the in-session sweep (Step 6) and the headless package (Step 6.5 / persona-reviewer). Each entry: { name, tier: \"primær\" | \"sekundær\", rolle, avkobler, overbeviser, ekspertise, sjargong, source: \"edition-state\" | \"series-file\" | \"plugin-library\" | \"interactive\" }. Default []: resolved on first Step 1.",
    "headlessReview": "Per-article headless-review record written by Step 6.5 (headless-review phase). Runs AFTER the in-session persona sweep (Step 6) and BEFORE lock (Step 8), on a FROZEN snapshot of the publish-ready (or pivoted) draft, fanned out from the command layer (foreground) or invoked standalone via /linkedin:headless-review in a fresh/cold session. Five archetypes judge independently with NO drafting-session context: content-reviewer (argument integrity), language-reviewer (Norwegian language), fact-reviewer (cold re-verification incl. claims a late pivot bolted on), persona-reviewer mode=resonans (per active persona), persona-reviewer mode=konverter (primær, hook only). The consolidated report is surfaced to the operator via SendUserFile; the operator decides which flags fold in. Shape: { frozenDraft, reviewers: { content, language, fact, personaResonance, personaConversion } (each { reportPath, summary, status }), consolidatedReport, foldedIn, waived, status }. status ladder: pending → run → folded. null until Step 6.5 runs. This is the adversarial-independence companion to the in-session gates (editorialReview, personaSweep, factcheckLog) — deliberately redundant: a cold reader catches what the framing-biased in-session pass missed.",
    "pivots": "Per-article pivot log (Endring 9c). A pivot is a substantive change to a draft AFTER a gate had already cleared — e.g. a new argument anchor / section added late (the Del 4 Security Champions case: +~530 words, 2 new sections, +42 %). Each /linkedin:pivot invocation appends one entry and moves currentPhase back so the cleared gates (Steps 5–6.5) re-run on the pivoted version before lock. Heuristic (documented, checked at the Step 8 lock precondition): if the current draft's word count differs > 20 % from the version that last cleared Step 6, OR it has > 2 new sections, a pivot-reopen is suggested/required. Each entry: { timestamp, reason, fromPhase, toPhase, wordCountBefore, wordCountAfter, deltaPct, newSections, gatesToRerun: [phase…] }. Default [].",
-    "foldIns": "Per-article accumulation queue (slice 2 of fix #1 — «rettelser fester seg»). Each correction KTG makes during an edition that is NOT yet a contract rule is captured here, then routed by the JA-promoter (maskinrommet/docs/skrivekontrakt.md §E) to a permanent home so it never has to be re-discovered: a MECHANICAL correction → a rules.ts gate rule (BLOCK/WARN) + a §B-row/§C1/§C2-box + a §E-manifest row (the contract-gate `ratify` check then asserts rules.ts ↔ §E-manifest stay in bijection); a JUDGMENT correction → a §C2-box only (stays with editorial-reviewer, no gate rule). Capture is per-article (provenance = which article surfaced it); promotion is series/contract-wide. Each entry: { id, date (ISO-8601), correction (what KTG corrected, near-verbatim), trigger (where/why it surfaced), classification: \"mechanical-block\" | \"mechanical-warn\" | \"judgment\" | null (set at the classify step), decision: \"pending\" | \"promoted\" | \"rejected\" (the JA-promoter outcome), ruleId: <rules.ts id> | null (set on promote for mechanical), note?: where a judgment/rejected fold-in landed }. Default []. Rejected fold-ins are kept for traceability, never deleted.",
+    "language": "Review language for this series/edition (additive, default \"en\"). Threads into the long-form review agents so they grade against THIS language's rules: language-reviewer applies Norwegian-specific checks (anglicism→Norwegian idiom, «kanselli-stil») only when language == \"no\"; voice-scrubber's gold standard is the approved editions IN this language; any other value → the agents apply that language's equivalents and never grade prose against Norwegian idiom. \"no\" = Norwegian (the author's case). Resolved at Step 1 / load-context and passed to the language-dependent agents."
    "language": "Review language for this series/edition (additive, default \"en\"). Threads into the long-form review agents so they grade against THIS language's rules: language-reviewer applies Norwegian-specific checks (anglicism→Norwegian idiom, «kanselli-stil») only when language == \"no\"; voice-scrubber's gold standard is the approved editions IN this language; any other value → the agents apply that language's equivalents and never grade prose against Norwegian idiom. \"no\" = Norwegian (the author's case). Resolved at Step 1 / load-context and passed to the language-dependent agents.",
    "sourceTrendId": "Per-article provenance link to the trend this edition was started from (N7 trend→newsletter bridge, MR-F3). Additive-optional (default null, NO schemaVersion bump — an edition started manually never sets it, and Step 10 reads its absence as \"no source trend\"). Set at the Step 1.5 checkpoint when Step 1's trend-intake read a candidate from the trends store (scripts/trends) to prefill the brief (angle / targetLevel / key-points / source-URLs). Its ONE runtime consumer is Step 10 (scheduling): when the article reaches scheduling AND sourceTrendId is set, the command flips that trend's store status to \"acted\" (trends CLI `act --id <sourceTrendId>`), closing the discovery→production loop deterministically instead of by hand. Value = the trend's store id (normalized title+url, as shown in the /linkedin:trends brief and `CLI list --json`).",
    "targetLevel": "Per-article target-level for the edition (N10 / C-8). Additive-optional (default null, NO schemaVersion bump — same pattern as sourceTrendId/language; an edition that never resolves one leaves it null and the reader agents fall back to each persona's own `ekspertise` field). Fixes WHERE this edition sits on the configured target-level span (references/longform-quality-rules.md + config/personas.template.md): it tells persona-reviewer which end is the reader-facing (primær) end and which is the mandatory-secondary end, so «practically usable at all levels» is judged from both ends rather than one baked-in reader role. Set at Step 1 of /linkedin:newsletter — the N7 trend bridge / N6 proposal layer pre-fills it from the trend record's `targetLevel` (scripts/trends), the operator confirms or edits it during calibration, and it is persisted here at the Step 1.5 checkpoint (alongside sourceTrendId). Free-text level descriptor (e.g. \"line leader → solution engineer\", \"beginner → practitioner\"), NOT an enum — the span is domain-general and defined by the operator's persona set, never hardcoded."
  },
  "schemaVersion": 1,
  "series": {
@ -51,12 +44,7 @@
      "title": "<Article 1 title>",
      "phase": "load-context",
      "status": "pending",
      "phaseLog": [],
      "personas": [],
      "livedSpecifics": {
        "slots": [],
        "status": "pending"
      },
      "immutableRules": null,
      "factcheckLog": null,
      "editorialReview": null,
@ -92,11 +80,8 @@
        "carousel": null
      },
      "pivots": [],
      "foldIns": [],
      "locked": false,
-      "scheduled": null,
+      "scheduled": null
      "sourceTrendId": null,
      "targetLevel": null
    }
  }
 }
--- a/config/personas.template.md
+++ b/config/personas.template.md
@ -13,7 +13,7 @@ cp config/personas.template.md config/personas.local.md
 ```
 `personas.local.md` is gitignored (via `*.local.md`) so your active overrides
-stay local. The template ships the four Seres seed personas below; clone,
+stay local. The template ships the three Seres seed personas below; clone,
 trim, or extend them per series.
 ---
@ -23,16 +23,11 @@ trim, or extend them per series.
 - **Per-project selection.** `/linkedin:newsletter` (Step 1) picks the relevant
  personas from this library and marks the primary in the edition brief.
 - **«primær trumfer».** Exactly one persona is the **primær** reader. On
-  conflict between personas, the primær weighs highest. But the active set MUST
+  conflict between personas, the primær weighs highest. A *secondary* NO caused
-  include a **mandatory secondary at the opposite end of the target-level span**
+  by role mismatch or an expertise ceiling («this I already know cold») is a
-  from the primær (a technical reader when the primær is non-technical, and vice
+  SIGNAL that the gate works — accept it, do not distort the text to chase it.
-  versa) — one reader alone cannot certify a text «practically usable at all
+  A *primær* NO is **not** accepted: the text is revised until the primær
-  levels», so a lone primær JA is not enough. A *secondary* NO caused by role
+  reaches a clean YES.
  mismatch or an expertise ceiling («this I already know cold») is a SIGNAL that
  the gate works — but it may be waived as «signal, not failure» **only with an
  explicit ceiling justification** that names which end of the span hit its
  ceiling; an unexplained secondary NO is a real flag, not a free pass. A *primær*
  NO is **not** accepted: the text is revised until the primær reaches a clean YES.
 - **Two sweep modes** (same `persona-reviewer` agent): resonance mode (Step 6,
  BEFORE lock — «does the point land for this reader?») and conversion mode
  (Step 9, after lock — binary «would YOU click?» on the hook only).
@ -69,9 +64,8 @@ can be promoted to a reusable block by pasting them into `personas.local.md`
 The persona sweep is not advisory — it returns a **blocking verdict**
 (PASS / REWORK / BLOCK), and the bar is the **primær reader's genuine, unqualified
-JA**. The four Seres seed personas are the canonical set: **A = IT-divisjonsdirektør**
+JA**. The three Seres seed personas are the canonical set: **A = IT-divisjonsdirektør**
-(sekundær), **B = KI-seksjonsleder** (sekundær), **C = Linjeleder** (PRIMÆR — trumfer),
+(sekundær), **B = KI-seksjonsleder** (sekundær), **C = Linjeleder** (PRIMÆR — trumfer).
 **D = Løsningsutvikler/AI-ingeniør** (sekundær — the mandatory technical end opposite C).
 - **Bar = C ekte JA.** A clean, unqualified yes from the primær. **«JA med store
  forbehold» = NEI.**
@ -149,27 +143,6 @@ pipeline and the structural check key off them:
 - **sjargong** — Lav toleranse for teknisk sjargong; setter pris på presise,
  hverdagsnære formuleringer.
 ### Persona 4 — Løsningsutvikler/AI-ingeniør (sekundær)
 > **Technical end of the target-level span** (opposite the primær persona). The
 > mandatory secondary the «primær trumfer» rule requires: if the primær (Linjeleder)
 > anchors the reader-facing end, this persona anchors the technical end, so a text
 > that claims to work «at all levels» is judged from both ends, not just one.
 - **rolle** — Bygger og drifter AI-løsningene i praksis (utvikler, ML-ingeniør eller
  løsningsarkitekt); skriver koden, velger modellene, eier integrasjonene.
 - **avkobler** — Ledelses-abstraksjoner uten teknisk substans; «AI-magi» uten hvordan;
  påstander om hva som er mulig som ikke tåler et implementasjons-blikk; nedlatende
  forenkling av ting hen kan fra innsiden.
 - **overbeviser** — Konkret hvordan-det-faktisk-virker, ærlige begrensninger og
  feilmodi, reelle avveininger (latency/kost/kvalitet), og respekt for at
  dømmekraften i systemdesign er ekte fag.
 - **ekspertise** — Høy teknisk. Ekspertise-tak på grunnleggende forklaringer: en
  «hva er en API»-passasje faller flatt (sekundær-NEI her er et signal — men bare
  med eksplisitt ceiling-begrunnelse, jf. «primær trumfer»).
 - **sjargong** — Høy toleranse for teknisk/kode-sjargong; lav for lederspråk og
  konsulent-buzzwords.
 ---
 ## Adding a persona
--- a/config/publishing-slots.template.json
+++ b/config/publishing-slots.template.json
@ -1,16 +0,0 @@
 {
  "_doc": {
    "purpose": "Schema for publishing-slots.json (N13 / A1-10) — the recurring weekly slots you publish in. Session start reads it to name the next slot nothing covers yet, /linkedin:calendar shows the grid, and /linkedin:newsletter Step 10 defaults its scheduling to the next open slot instead of asking.",
    "install": "OPT-IN — the plugin never writes this file for you and imposes no schedule. Copy it into your data dir and edit the times: cp \"${CLAUDE_PLUGIN_ROOT}/config/publishing-slots.template.json\" \"${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/profile/publishing-slots.json\". While the file is absent, every slot surface stays silent.",
    "slots": "Recurring weekly slots: day = a weekday, either three-letter (mon/tue/wed/thu/fri/sat/sun) or spelled out; time = 24-hour HH:MM (zero-padded). label is free text shown next to the slot (e.g. which format usually goes there). Unparseable rows are dropped rather than throwing — a typo costs you that slot, not your session start.",
    "timezone": "IANA zone the times are meant in, e.g. \"Europe/Oslo\" or \"America/New_York\". Recorded for your own clarity and displayed as-is; the plugin does not convert times (it schedules in your local wall clock, like the queue).",
    "coverage": "A slot counts as covered when something lands on that date: a queue entry with status scheduled or published (/linkedin:batch, /linkedin:quick, Step 10 of an edition), or an editions-register row whose slot claims that date. Cancelled entries free the slot again. A day carrying two slots needs two posts to be full.",
    "defaults": "The times below are the plugin's own DIRECTIONAL 2x/week starting point (references/scheduling-strategy.md — confidence: low / directional, no primary source). They are a hypothesis to test, not a recommendation about your audience. Replace them with what your own analytics show (/linkedin:report, /linkedin:analyze)."
  },
  "schemaVersion": 1,
  "timezone": "",
  "slots": [
    { "day": "tue", "time": "08:30", "label": "" },
    { "day": "thu", "time": "12:00", "label": "" }
  ]
 }
--- a/config/trends-sources.template.md
+++ b/config/trends-sources.template.md
@ -1,89 +0,0 @@
 # Trend Sources (template)
 The **source list** a research-engine pass polls for trend/topic candidates. This file
 ships **generic, niche-agnostic defaults** (source *categories*, not one person's beat).
 Override it with your own list — the niche specifics (your vendors, your regulators, your
 country's outlets) belong in the override, never here.
 ## How the override works
 Copy this template into your per-user data dir and edit the copy:
 ```bash
 mkdir -p "${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends"
 cp config/trends-sources.template.md \
   "${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends/sources.md"
 ```
 A pass reads `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends/sources.md`
 if it exists, and falls back to these shipped defaults otherwise. The override lives in the
 data dir (next to the trend store `trends/trends.json`), so it **survives plugin
 upgrades and reinstalls**. `LINKEDIN_STUDIO_DATA` overrides the root.
 Format below is read by a person and an agent both: a markdown list, one source per line,
 grouped by tier. Keep `Name — URL — note` so a poll can cite the URL.
 ---
 ## Tier 1 — Primary / breaking (poll daily, react within 24–48h)
 *First-party announcements and authoritative decisions in your field.*
 - [Major vendor blog] — [url] — releases & announcements
 - [Major vendor blog] — [url] — releases & announcements
 - [Regulator / governing body] — [url] — decisions & guidance
 ## Tier 2 — Analysis & research (poll 2–3×/week, post within a week)
 *Where a development gets interpreted, not just reported.*
 - [Respected analysis publication] — [url]
 - [Analyst house report stream] — [url] — adoption / market reports
 - [Research index] — [url] — preprints / papers in your area
 ## Tier 3 — Community signals (poll weekly, post if a pattern emerges)
 *Where practitioners surface what actually matters before the press does.*
 - [Practitioner forum / aggregator] — [url]
 - [Topic-specific community] — [url]
 - [Platform-native trending] — [url]
 ## Tier 4 — Niche & seasonal (poll monthly, plan ahead)
 *Slower-moving sources with predictable cadence.*
 - [Key conference series] — [url] — announcement / agenda cycles
 - [Earnings / report calendar] — [url] — scheduled releases
 - Seasonal themes: [Q1 …] · [Q2 …] · [Q3 …] · [Q4 …]
 ## Tier 5 — Demand signals (where the questions live) — the demand-sweep polls these
 *Tier 1–4 are SUPPLY sources — they tell you what was announced. Tier 5 is the inverse: where
 your audience already **asks**. The `demand-spotter` agent («innenfra og ut») polls these to turn a
 topic into the reader's own question, its pain point, and an honest saturation verdict. Ground truth
 first (HN + GitHub APIs are exact); forums are approximate; some channels need an API (see the notes).*
 - [Practitioner forums / communities] — [url] — where people ask (Reddit, HN, product forums, Discord/Slack where reachable). *Reddit blocks direct fetch → counts are approximate; HN via the Algolia API is exact.*
 - [GitHub issues on the spec/tool repos] — [url] — undervalued gold: real questions from the people building, with names + comment counts as signal strength (GitHub API = ground truth)
 - [Procurement data] — [url] — the hardest demand indicator there is: someone has a budget and wrote the need down (e.g. a national tender portal / TED-equivalent for your market)
 - [Regulator / supervisory guidance] — [url] — what your reader is *required* to take a position on (non-optional demand)
 - [Comment fields on your channels] — [url] — *NB: YouTube/video comments are JS-rendered → need an API key; the largest blind spot. Specify the fetch method or mark the channel explicitly un-swept — an honest null is a finding.*
 ---
 ## Your niche additions
 Add the sources specific to your field below — these are the ones the generic defaults
 above cannot know. (Example shape for a Norwegian public-sector / AI niche: national
 digitalisation agency, data-protection authority, the relevant ministries, the local
 tech press — replace with yours.)
 - [Your source] — [url] — [why it matters to your audience]
 - [Your source] — [url] — [why it matters to your audience]
 ---
 *Tip: the [8 universal angles](../references/content-angles.md) and the scoring rubric
 in [trend-scoring-modes.md](../references/trend-scoring-modes.md) decide what to DO with a
 candidate once a poll surfaces it. This file only decides WHERE to look.*
--- a/config/user-profile.template.md
+++ b/config/user-profile.template.md
@ -32,7 +32,7 @@ cp config/user-profile.template.md config/user-profile.local.md
 - **Geographic focus:** [Region/Country]
 **LinkedIn Goals (ranked by priority):**
-1. [ ] Build authority & influence
+1. [ ] Build thought leadership & authority
 2. [ ] Attract speaking opportunities
 3. [ ] Network with peers/influencers
 4. [ ] Generate qualified leads
@ -116,27 +116,6 @@ cp config/user-profile.template.md config/user-profile.local.md
 ---
 ### Research Tooling
 **Which research MCPs do you have available?** The trend / research engine routes to a
 declared MCP **first** and falls back to the always-available floor when none is declared.
 Check what you actually have connected — leave the rest unchecked. (Names are examples;
 add whatever you have under "Other" — nothing here is hard-coded downstream.)
 - [ ] Tavily (`tavily_search` / `tavily_research`)
 - [ ] Gemini deep research (`gemini_deep_research`)
 - [ ] Perplexity
 - [ ] Other: [name the MCP + what it's good for]
 **Always-available floor (no MCP needed):** WebSearch + WebFetch. These are used when no
 research MCP is declared above. (Note: WebSearch is US-biased — a research MCP gives
 better coverage for non-US / regional sources.)
 **Preferred order (optional):** [e.g. "Tavily for niche/regional, Gemini for deep dives,
 WebSearch as fallback" — or leave blank to let the engine pick]
 ---
 ### Asset Utilization Preferences
 **When creating content, Claude should:**
--- a/docs/agents-capability-matrix.md
+++ b/docs/agents-capability-matrix.md
@ -13,8 +13,7 @@
 | content-planner | Sonnet | Cyan | Weekly/monthly content calendars |
 | network-builder | Sonnet | Teal | Strategic networking and outreach |
 | content-repurposer | Sonnet | Purple | Format conversion and evergreen refresh |
-| trend-spotter | (inherits session) | White | Trending topics and opportunity scoring |
+| trend-spotter | Sonnet | White | Trending topics and opportunity scoring |
 | demand-spotter | (inherits session) | Silver | Demand-sweep «innenfra og ut»: reader-side questions, pain-point map, vocabulary translation, §4 arc map |
 | voice-trainer | Sonnet | Pink | Voice profile building and drift detection |
 | differentiation-checker | Sonnet | Gray | Originality scoring and commodity detection |
 | video-scripter | Sonnet | Violet | Video script creation with pacing and visual cues |
--- a/docs/expert-review/dream-spec-panel.md
+++ b/docs/expert-review/dream-spec-panel.md
@ -1,80 +0,0 @@
 # Dream-Spec Expert Panel — Launch-Ready Spec
 > Operator-redirected expert panel (2026-06-20). **Supersedes the critique-of-current direction in
 > `plan.md`.** Instead of reviewing the existing plugin, a panel of world-class LinkedIn-growth experts
 > defines the **ideal plugin's capability spec** (north-star), then a second pass reviews the **current**
 > plugin against that dream-spec. **Informational — NOT a plan/roadmap** (operator's explicit framing).
 > Run as a background multi-agent Workflow; main context writes the final doc (operator-gated).
 ## Mission (the exact growth thesis — operator-clarified)
 A creator wants a **very large, highly engaged LinkedIn following in 2026 that compounds through
 word-of-mouth**: the account (powered by this plugin) gets so good that its **followers "recruit" new
 LinkedIn users to the account** — reshares, tagging, "save-and-send", collaborations, comment-networks.
 Engaged followers bring in more followers. Plus a strong, differentiated **personal brand** that converts
 attention into opportunity. The vehicle is an AI plugin (slash-commands + sub-agents) run by a **non-expert**
 who needs the tool to supply the domain expertise.
 ## Deliverable
 1. `docs/expert-review/dream-spec.md` — the consolidated north-star capability spec (the reference the
   operator consults when proposing improvements from real use).
 2. A **full review of the current plugin measured against the dream-spec** (delivers / partial / missing,
   with file:line evidence) — informational, appended or as `docs/expert-review/review-vs-spec.md`.
 ## Panel — 7 expert lenses (define the IDEAL, no anchoring to current)
 algo (algorithm & distribution) · craft (hook & format craft) · brand (positioning & personal brand) ·
 growth (audience growth & network effects — the "verver andre" core) · engage (engagement & community) ·
 analytics (data-driven iteration, honest about LinkedIn data limits) · voice (authenticity / anti-AI-slop).
 ## Review buckets — 7 (assess current plugin vs the dream-spec)
 Same 7 keys; each reviewer reads the relevant current files (see script `BUCKETS[].files`).
 ## How to run (next session, full context)
 1. `Workflow({ script })` below, **`run_in_background: true`**. Launch FIRST (it runs while you do the push).
 2. On completion: main context writes `dream-spec.md` + `review-vs-spec.md` from the returned
   `{ dreamSpec, principles, reviews }`. Opus, human-facing, operator-gated (no auto-merge).
 3. Then write a project memory for the dream-spec artifact.
 ## Workflow script (paste verbatim into `Workflow({script})`)
 ```js
 export const meta = {
  name: 'linkedin-dream-spec-panel',
  description: 'World-class growth-expert panel defines the ideal LinkedIn plugin spec, then reviews the current plugin against it (informational, not a plan)',
  phases: [
    { title: 'Dream-spec', detail: '7 expert lenses define ideal capabilities (no anchoring to current)' },
    { title: 'Consolidate', detail: 'merge lenses into one dream-spec' },
    { title: 'Review-vs-spec', detail: 'assess current plugin against the dream-spec' },
  ],
 }
 const MISSION = `A creator wants a VERY LARGE, HIGHLY ENGAGED LinkedIn following in 2026 that COMPOUNDS THROUGH WORD-OF-MOUTH: the account (powered by this plugin) gets so good that its FOLLOWERS RECRUIT NEW LinkedIn users to the account — reshares, tagging, "save-and-send", collaborations, comment-networks. Engaged followers bring in more followers. Plus a strong, differentiated PERSONAL BRAND that converts attention into opportunity. The vehicle is an AI plugin (slash-commands + sub-agents) run by a NON-EXPERT who needs the tool to supply the domain expertise. Define what that plugin must DO.`
 const LENSES = [
  { key:'algo', title:'LinkedIn algorithm & distribution', brief:'how the 2026 feed ranks, tests, suppresses and resurfaces content; what a tool must do to maximize organic reach and dwell' },
  { key:'craft', title:'Hook & content-format craft', brief:'scroll-stopping hooks, narrative tension, format mechanics (carousel/video/text/poll), the craft that earns engagement' },
  { key:'brand', title:'Personal-brand & positioning strategy', brief:'ICP clarity, differentiation, authority architecture, offer<->content fit, a recognizable point of view' },
  { key:'growth', title:'Audience growth & network effects', brief:'the word-of-mouth loop — what makes engaged followers recruit MORE followers to the account: shareable/taggable formats, collaborations, comment-networks, compounding' },
  { key:'engage', title:'Engagement & community building', brief:'first-hour tactics, comment strategy, relationship systems, turning followers into an active community that returns and advocates' },
  { key:'analytics', title:'Analytics & data-driven iteration', brief:'what to measure (honest about LinkedIn data limits), how to close the feedback loop, experiment design, knowing what is working' },
  { key:'voice', title:'Authenticity & anti-AI-slop voice', brief:'staying credibly human at scale, a real voice, avoiding generic AI tells and broetry fatigue, earning trust' },
 ]
 const BUCKETS = [
  { key:'algo', title:'Algorithm & distribution', files:'references/algorithm-signals-reference.md, commands/analyze.md, commands/report.md, agents/analytics-interpreter.md, agents/post-feedback-monitor.md, references/linkedin-formats.md' },
  { key:'craft', title:'Content & format craft', files:'commands/post.md, commands/quick.md, commands/carousel.md, commands/video.md, commands/react.md, agents/content-optimizer.md, agents/video-scripter.md, references/engagement-frameworks.md, references/content-angles.md' },
  { key:'brand', title:'Positioning & personal brand', files:'commands/strategy.md, commands/profile.md, commands/onboarding.md, commands/setup.md, agents/strategy-advisor.md' },
  { key:'growth', title:'Growth & network effects', files:'commands/outreach.md, commands/competitive.md, commands/batch.md, agents/network-builder.md, agents/content-repurposer.md, agents/trend-spotter.md, references/collaborations-guide.md, references/opportunity-generation.md' },
  { key:'engage', title:'Engagement & community', files:'commands/firsthour.md, commands/calendar.md, agents/engagement-coach.md, references/engagement-frameworks.md' },
  { key:'analytics', title:'Analytics & iteration', files:'commands/import.md, commands/report.md, commands/analyze.md, commands/audit.md, commands/ab-test.md, commands/measure.md, agents/analytics-interpreter.md' },
  { key:'voice', title:'Authenticity, voice & long-form', files:'skills/linkedin-voice/SKILL.md, agents/voice-trainer.md, agents/voice-scrubber.md, agents/differentiation-checker.md, commands/newsletter.md, agents/editorial-reviewer.md, agents/persona-reviewer.md, agents/fact-checker.md' },
 ]
 const EXPERT_SCHEMA = { type:'object', additionalProperties:false, required:['lens','capabilities','northStarPrinciples'], properties:{ lens:{type:'string'}, capabilities:{type:'array', items:{type:'object', additionalProperties:false, required:['name','whatItDoes','whyItMatters','howDelivered','priority'], properties:{ name:{type:'string'}, whatItDoes:{type:'string'}, whyItMatters:{type:'string'}, howDelivered:{type:'string'}, priority:{type:'string', enum:['core','high','nice']} } } }, northStarPrinciples:{type:'array', items:{type:'string'}} } }
 const SPEC_SCHEMA = { type:'object', additionalProperties:false, required:['mission','capabilityAreas'], properties:{ mission:{type:'string'}, capabilityAreas:{type:'array', items:{type:'object', additionalProperties:false, required:['area','goal','capabilities'], properties:{ area:{type:'string'}, goal:{type:'string'}, capabilities:{type:'array', items:{type:'object', additionalProperties:false, required:['name','whatItDoes','whyItMatters','howDelivered','priority','sourceLenses'], properties:{ name:{type:'string'}, whatItDoes:{type:'string'}, whyItMatters:{type:'string'}, howDelivered:{type:'string'}, priority:{type:'string', enum:['core','high','nice']}, sourceLenses:{type:'array', items:{type:'string'}} } } } } } } } }
 const REVIEW_SCHEMA = { type:'object', additionalProperties:false, required:['bucket','summary','assessments'], properties:{ bucket:{type:'string'}, summary:{type:'string'}, assessments:{type:'array', items:{type:'object', additionalProperties:false, required:['capability','coverage','evidence','gap'], properties:{ capability:{type:'string'}, coverage:{type:'string', enum:['delivers','partial','missing']}, evidence:{type:'string'}, gap:{type:'string'} } } } } }
 phase('Dream-spec')
 const expertsRaw = await parallel(LENSES.map(l => () => agent(`You are a world-class expert in ${l.title} — ${l.brief}.\n\nMISSION:\n${MISSION}\n\nDefine the capabilities THIS plugin must have, through YOUR lens ONLY, to make the creator succeed. Define the IDEAL — do NOT anchor to any existing tool or worry about what is already built. For each capability: name; whatItDoes; whyItMatters (the domain MECHANISM — why it drives a large / engaged / self-compounding following); howDelivered (how an AI slash-command or sub-agent would actually deliver it for a non-expert). Mark priority core/high/nice. Aim for 6-12 concrete capabilities. Also give 2-4 northStarPrinciples for your lens. Ground platform-mechanic claims in real 2026 LinkedIn dynamics; if a capability rests on a specific platform number you are unsure of, say so in whyItMatters rather than inventing a figure.`, { label:`spec:${l.key}`, phase:'Dream-spec', schema: EXPERT_SCHEMA })))
 const experts = expertsRaw.filter(Boolean)
 log(`Dream-spec: ${experts.length}/${LENSES.length} expert lenses returned`)
 phase('Consolidate')
 const dreamSpec = await agent(`You are the panel's chief editor. ${experts.length} world-class experts each defined capabilities for the IDEAL LinkedIn-growth plugin (mission below). Consolidate into ONE dream-spec.\n\nMISSION:\n${MISSION}\n\nEXPERT OUTPUTS (JSON):\n${JSON.stringify(experts)}\n\nProduce: a one-paragraph mission; and capabilityAreas — each tied to a concrete creator-goal — with merged capabilities inside (dedupe overlaps across lenses; when lenses overlap, merge into one capability and list all sourceLenses). Comprehensive but non-redundant. This is the operator's north-star reference, so each capability must be concrete and actionable.`, { label:'consolidate', phase:'Consolidate', schema: SPEC_SCHEMA })
 phase('Review-vs-spec')
 const reviews = (await parallel(BUCKETS.map(b => () => agent(`You are an adversarial, independent product reviewer. Below is the DREAM-SPEC for an ideal LinkedIn-growth plugin. Assess how the CURRENT plugin delivers the capabilities relevant to the "${b.title}" area — honestly and specifically. INFORMATIONAL (a gap assessment for the operator to read), NOT a plan or roadmap.\n\nDREAM-SPEC (JSON):\n${JSON.stringify(dreamSpec)}\n\nRead these current plugin files (relative to the repo root = cwd): ${b.files}\n\nFor each dream-spec capability relevant to "${b.title}", judge coverage: delivers | partial | missing — with concrete evidence (file:line or a specific observation) and the precise gap vs the dream-spec capability. Do not praise vaguely; cite. End with a 2-3 sentence summary of where this area stands against the dream.`, { label:`review:${b.key}`, phase:'Review-vs-spec', schema: REVIEW_SCHEMA })))).filter(Boolean)
 log(`Review: ${reviews.length}/${BUCKETS.length} buckets assessed`)
 return { dreamSpec, principles: experts.map(e => ({ lens: e.lens, northStarPrinciples: e.northStarPrinciples })), reviews }
 ```
--- a/docs/expert-review/plan.md
+++ b/docs/expert-review/plan.md
@ -1,77 +0,0 @@
 # Expert-Panel Review — Dynamic Workflow Spec
 _Spec for et multi-agent ekspert-panel som vurderer hele LinkedIn Studio-pluginen og leverer en
 prioritert roadmap. Kjøres **én gang etter at herdingen (S26) er ferdig**. Output fylles inn i
 `docs/expert-review/roadmap.md`, som STATE.md peker til._
 ## Når
 - **Forutsetning:** herding ferdig (S1–S26, alle 29 kommandoer gjennom kvalitetsgaten).
 - **Trigger:** eksplisitt operatør-kommando (`Workflow`-verktøyet — ikke automatisk; kjøres aldri uten opt-in).
  Dette er en kostbar fan-out (panel × artefakt-sett). «Ingen skjulte kostnader» = stående ja, men kjøringen
  bekreftes likevel før start.
 - **Scope:** vurderer pluginen **som produkt** — ikke en enkelt kommando. Komplementær til herdingen
  (herding = korrekthet/hygiene per kommando; ekspert-panel = strategisk produktverdi på tvers).
 ## Formål
 Få en uavhengig, verdensklasse-vurdering av om pluginen faktisk gjør en bruker til en sterk personal-brand på
 LinkedIn i 2026 — hva som er world-class, hva som mangler, hva som er feiljustert mot virkeligheten — og
 destillere det til konkret, prioritert arbeid mot v1.0.0 og videre.
 ## Panelet (ekspert-arketyper, distinkte linser)
 Arketyper, ikke navngitte virkelige personer (vi fabrikkerer ikke sitater i noens munn). Hver arketype er
 destillert fra en reell skole/praksis for troverdighet, og bærer **én distinkt linse** så funnene ikke
 overlapper.
 | # | Arketype | Linse (hva den jakter på) | Destillert fra |
 |---|----------|---------------------------|----------------|
 | 1 | **Solopreneur-operatøren** | Offer↔content-fit, lead-gen-funnel, konsistens-systemer, ROI på tid | one-person-business-skolen |
 | 2 | **Hook- & storytelling-håndverkeren** | Hooks, retorikk, narrativ spenning, scroll-stop, format-craft | viral short-form-skolen |
 | 3 | **Personal-brand-strategen** | Posisjonering, differensiering, ICP-klarhet, authority-arkitektur | personal-branding-skolen |
 | 4 | **Algoritme- & analytics-spesialisten** | Distribusjon, format-mix, timing, saves/dwell-realisme, datadrevet iterasjon | growth/analytics-skolen |
 | 5 | **B2B thought-leadership / social-selling-lederen** | Pipeline, social selling, founder-led, employee advocacy | B2B-social-selling-skolen |
 | 6 | **Autentisitets-/anti-AI-slop-kritikeren** | Generisk AI-stemme, «broetry»-tretthet, etterprøvbarhet, ekte stemme | de-AI / voice-skolen |
 (Antall/arketyper kan justeres ved kjøring. Minst 5 distinkte linser anbefales.)
 ## Input pr. agent
 Hver ekspert leser et **kuratert artefakt-sett** (ikke hele repoet — fokusert lesing):
 - `CLAUDE.md` + `README` — kommando-/agent-inventar (29/19), arkitektur, gates.
 - Et representativt utvalg command-filer for sin linse (f.eks. hook-håndverkeren leser `post`/`quick`/`carousel`;
  analytics-spesialisten leser `import`/`report`/`analyze`/`audit`/`ab-test`).
 - Voice-systemet (`skills/.../SKILL.md`, voice-agentene, longform de-AI-gates).
 - `references/algorithm-signals-reference.md` (SSOT) + relevante playbooks.
 - `docs/hardening/log.md` (hva herdingen alt fant/fikset — unngå å re-rapportere løste ting).
 ## Per-ekspert output (schema)
 Strukturert (StructuredOutput), aldri løs prosa:
 ```
 {
  expert: <arketype>,
  findings: [{
    area: <kommando/agent/system>,
    severity: BLOCK | MAJOR | MINOR | NICE,
    claim: <hva som er svakt/manglende/world-class>,
    evidence: <fil:linje eller konkret observasjon>,
    recommendation: <konkret, etterprøvbart tiltak>
  }],
  strengths: [<hva som allerede er world-class — så roadmap ikke bare er kritikk>]
 }
 ```
 ## Workflow-faser
 1. **Review (parallel/pipeline):** hver ekspert-agent (Opus) leser sitt artefakt-sett → `findings`.
 2. **Konsolidering (judge/synth):** dedupe på tvers av linser, severity-rank, tema-gruppér, kryss-referer mot
   `hardening/log.md` (drop alt allerede løst). Bevart: strengths-seksjon.
 3. **Completeness-kritiker (1 agent):** «hvilken linse/vinkel manglet panelet?» → eventuelt en ekstra runde.
 4. **Skriv** konsolidert, prioritert resultat → `docs/expert-review/roadmap.md`.
 ## Konsolidering → `roadmap.md` (format)
 - **Executive summary** — panelets samlede dom (er dette world-class? hva holder det tilbake?).
 - **Prioritert backlog** — tabell: tema · severity · funn · anbefaling · kilde-ekspert(er). Sortert BLOCK→NICE.
 - **Strengths** — hva som allerede er sterkt (ikke rør).
 - **Workstream-kobling** — hvert tiltak mappet til v1.0.0-veien (kommando-test · GUI · ny milestone).
 ## Drift
 - **Opus på alt** (strategiske, human-facing funn). Schema-tvungne agenter for determinisme.
 - Operatør-gatet output; ingen auto-merge til roadmap uten gjennomlesing.
 - Kjøres når herdingen er ferdig — **ikke før**. STATE.md «Post-herding»-peker holder dette levende.
--- a/docs/fix2/slice2-binding.md
+++ b/docs/fix2/slice2-binding.md
@ -1,118 +0,0 @@
 # Fix #2 slice 2 — per-edition lived-specifics binding
 > **Kilde-så-draft.** Slice 1 built the global *store* (`scripts/specifics-bank`).
 > Slice 2 builds the per-EDITION *binding*: the bridge that ties one edition's
 > load-bearing claims to real material before any prose exists. Slice 3 wires it
 > into `/linkedin:newsletter` (Step 1.5 + the skeleton-gate); slice 4 touches the
 > maskinrommet contract. This doc is the design record slice 3 implements against.
 ## Why (retning §3, drømme-spec «Lived-Specifics Extraction» `[CORE]`)
 Sourcing, not styling, is where authenticity is won. A draft that starts from the
 operator's real number / named case / what-actually-broke is forwardable; a draft
 that invents plausible filler is hollow, and every downstream voice gate then
 polishes hollow content. So **before prose**, each load-bearing claim of an edition
 must be bound to real inventory — or the operator must *consciously* decide it does
 not need a concrete instance. The binding is that ledger; vagueness is rejected.
 ## The slot-map (`articles.NN.livedSpecifics` in `edition-state.json`)
 A per-article field, resolved at Step 1.5 (between brief and research). Each slot
 is one load-bearing key-point (`kind: "key-point"`) or, after the skeleton exists,
 a section (`kind: "section"` — the same shape serves both, no migration):
 ```jsonc
 "livedSpecifics": {
  "slots": [
    { "slotId": "kp1", "kind": "key-point", "label": "<claim>",
      "binding": { "type": "specific", "specificId": "<bank id>" } },
    { "slotId": "kp2", "kind": "key-point", "label": "<claim>",
      "binding": { "type": "abstrakt", "rationale": "<why abstract here>" } },
    { "slotId": "kp3", "kind": "key-point", "label": "<claim>",
      "binding": { "type": "ekstern", "source": "<research ref, optional>" } },
    { "slotId": "kp4", "kind": "key-point", "label": "<claim>",
      "binding": { "type": "unresolved" } }
  ],
  "status": "pending"   // pending → bound (set by the command when the gate passes)
 }
 ```
 ### The gate — `validateBinding(livedSpecifics, bank)` (drømme-spec G4, «vaghet avvises»)
 Deterministic, pure (`scripts/specifics-bank/src/binding.ts`). **BLOCK** iff any slot:
 | reason | when |
 |--------|------|
 | `unresolved` | binding type is `unresolved` — the vagueness the gate exists to reject |
 | `dangling-specific` | a `specific` binding points at a `specificId` absent from the bank |
 | `unjustified-abstrakt` | an `abstrakt` escape with a blank rationale (= vagueness wearing an escape hatch) |
 Otherwise **PASS**. Escape hatches are legitimate: `abstrakt` (with a rationale)
 and `ekstern` (research-backed, not lived; `source` optional — Step 2 fills it).
 **WARN (does not block)** — regel 6/7: a slot backed by an **unverified `number`**
 specific surfaces as `unverified-number`. Numbers stay guilty-until-checked; Step 2
 research must verify them before the draft asserts them as fact.
 `coverage` counts by binding TYPE (`total / specific / abstrakt / ekstern /
 unresolved`); a dangling specific still counts under `specific` (the binding type
 is `specific`, the *problem* is separately reported). Empty slot-map → PASS, total
 0 — whether an edition *needs* ≥1 slot is the command layer's call (slice 3).
 ## The `NN-kilder.md` artifact
 Read-only, deterministically **rendered** from `livedSpecifics` + the bank
 (`scripts/specifics-bank/src/kilder.ts`, `renderKilder`) — regenerated like
 POST.html, never hand-edited. Lives at `<serie>/linkedin/NN-kilder.md`. Per
 load-bearing slot: binding type, the material (KTG's words, verbatim), provenance
 + capture date, topic tags, and the number-verification marker (`✓` / `⚠`); then a
 coverage block + a «Tall som må verifiseres (regel 6/7)» line. The coverage block
 and the number list are computed by `validateBinding`, so the artifact and the
 skeleton-gate can never disagree. (Golden-tested; pure + dateless on purpose.)
 ## CLI surface (the seam slice 3 calls)
 Run from the package dir (`tsx` lives there); pass absolute paths:
 ```bash
 cd "${CLAUDE_PLUGIN_ROOT}/scripts/specifics-bank"
 node --import tsx src/cli.ts validate-binding --edition "<abs>/linkedin/edition-state.json"   # exit 1 = BLOCK
 node --import tsx src/cli.ts render-kilder    --edition "<abs>/linkedin/edition-state.json" \
                                              --out     "<abs>/linkedin/NN-kilder.md"
 ```
 `--article <id>` overrides `currentArticle`; `--bank <path>` overrides the default
 data-dir bank; `--json` emits machine output for `validate-binding`. A missing
 `livedSpecifics` field is treated as an empty slot-map (back-compat with older
 editions / the template default).
 ## Step 2 (research) re-scope spec — for slice 3 to wire
 Today Step 2 decomposes the edition's key points into scoped research sub-questions
 and triangulates verified notes. Once Step 1.5 + the slot-map exist, Step 2 is
 **scoped by the binding** rather than by the raw key-points:
 1. **Fill the gaps, don't re-research the grounded.** Research targets slots bound
   `ekstern` (and any still `unresolved` at entry) — the claims that explicitly
   need an external source. Slots bound to a `specific` are already grounded in
   lived material and do **not** need their substance re-sourced (research may
   still corroborate, but it is not the gap).
 2. **Verify KTG's own numbers (regel 6/7).** Every `unverified-number` warning from
   `validateBinding` is a research target: confirm the operator's own figure
   against a primary source where possible, then flip the bank specific
   `unverified → verified` (`cli.ts add`/a verify path). A number that cannot be
   verified stays `unverified` and is carried to the Step 5 fact-check sweep as 🟡
   — never silently asserted.
 3. **Re-render after research.** When research resolves an `ekstern` source or a
   number flips to verified, regenerate `NN-kilder.md` so the ledger stays current.
 Boundary: slice 2 ships the data model, the gate, the artifact renderer, and the
 CLI. Slice 3 adds Step 1.5 (the elicitation interview + `add` to the bank +
 populating the slot-map), wires `validate-binding` into the Step 2.5 skeleton-gate,
 applies this Step 2 re-scope, and bumps the pipeline 17 → 18 phases.
 ## Tests & verification
 `cd scripts/specifics-bank && npm test` (binding + kilder suites) and `npm run
 build` (tsc) stay clean. The gate's three BLOCK reasons + the number WARN + the
 golden `NN-kilder.md` render are all covered.
--- a/docs/hardening/log.md
+++ b/docs/hardening/log.md
--- a/docs/hardening/plan.md
+++ b/docs/hardening/plan.md
@ -89,58 +89,12 @@ that exercises the command's real path:
 | S3 react | S10 headless-review | S17 audit | S24 create |
 | S4 multiplatform | S11 pivot | S18 ab-test | S25 measure |
 | S5 carousel | S12 firsthour | S19 strategy | S26 linkedin |
-| S6 video | S13 calendar | S20 competitive | S27 ref-consistency A |
+| S6 video | S13 calendar | S20 competitive | |
-| S7 batch | S14 import | S21 monetize | S28 ref-consistency B |
+| S7 batch | S14 import | S21 monetize | |
-| S8 pipeline | S15 report | S22 outreach | S29 terminology-scrub |
+| S8 pipeline | S15 report | S22 outreach | |
 | | | | S30 magnitude-scrub |
 | | | | S31a/b/c multiplier-scrub |
 *S9 newsletter (16-phase) may split into S9a/S9b. Otherwise one command = one session.
 **S27/S28 — reference-consistency pass (added 2026-06-19, operator-approved; promotes open
 follow-up #1 to scheduled work).** NOT full re-hardening of already-✅ commands — surgical
 SSOT-reconciliation of the documented divergences, same tool-grounded discipline
 (read-and-show → grep-confirm → re-grep final):
 - **S27 (A) — "penalty/penalizes" framing → SSOT ✅ DONE (2026-06-19, 10 edits/6 files; see `log.md`).**
  The 3 cited lines (`troubleshooting-guide.md:127`, `analyze.md:101`, `audit.md:60` — nr drifted ±1) +
  7 same-class siblings (trend-spotter topic-relevance ×2, troubleshooting-guide :15, first-comment-strategy
  ×3, url-processing-templates :396) reconciled to "correlate with lower reach" / "topic relevance is a
  ranking input — off-topic gets lower reach". Bucket B (link-penalty lines in `linkedin-formats.md`) folded
  into S28; Bucket D (other unsourced magnitudes) promoted to S30.
 - **S28 (B) — format magnitudes → SSOT ✅ DONE (2026-06-19, 20 edits/2 files; see `log.md`).**
  `commands/video.md:69` + `references/linkedin-formats.md` reconciled in one pass: the "30% zero-distribution"
  gate (7×) → "completion/dwell is a ranking input, no hard gate"; the 6 S27-folded link-penalty lines →
  "correlate with lower reach"; 6 other unsourced format magnitudes (video 5.60% ER, Live 12-24x, polls
  1.64x, 3x shares, Creator-Mode 35%); 1 internal contradiction (`:356` 3-sec = 70% retention). Bucket D
  (this file's non-format coefficients) deferred to S30.
 **S29 — terminology scrub: "thought leadership" → "LinkedIn Studio" / neutral (added 2026-06-19,
 operator-approved during S26).** The phrase must not appear anywhere in the plugin (it is named LinkedIn
 Studio; see auto-memory `no-thought-leadership-phrase`). S26 fixed the 2 occurrences in
 `commands/linkedin.md`; **~85 lines across ~45 files remain** (commands, agents, references — incl. the
 filename `references/thought-leadership-angles.md` — skills, plus historical CHANGELOG/docs). Open scoping
 questions for this pass: (a) user-facing surface only, or include historical CHANGELOG/docs too? (b) the
 `thought-leadership-angles.md` rename is its own sub-step — every pointer to the filename must update with
 it. Same tool-grounded discipline (read-and-show → grep-confirm → re-grep final); hardening-class.
 **S30 — magnitude scrub: unsourced reach-coefficients → SSOT (surfaced during S27, re-scoped during S28,
 2026-06-19).** A *different* class from S27's link/topic-relevance framing: discrete percentage penalties
 with **no primary source in the SSOT**. **Incl. `linkedin-formats.md` Bucket-D lines left by S28**
 (`:6` 47-50% reach-decline, `:7` 15%→31%, `:176` AI-comment −30%/−55%, `:231`+`:279` hashtags −68%), plus
 the other files — `−68%` (5+ hashtags: `linkedin-growth-playbook:166`, `ab-testing-framework:66`),
 `−25%` (<1000 chars: `linkedin-growth-playbook:224`), `−15-25%` (topic-gap: `glossary:235`), `−30-50%`
 (engagement-bait: `glossary:91`), `55%`/`45%` (AI-comment: `engagement-coach:195`, `firsthour:112` — SSOT
 carries ~45% *correlational engagement gap* at medium confidence, not a 55% reach penalty), `−25%/post`
 (multiple posts/3h: `post-feedback-monitor:330`), poll-overuse (`poll-strategy-guide:20,:205`). **Leave
 intact (officially confirmed, high confidence): engagement-pod + AI-slop "penalized" framing.** Full grep
 catalog in `log.md` S27 entry, Bucket D. Same discipline; hardening-class.
 Run after S26; order adjustable (S27 ✅ → S28 ✅ → S29a–e ✅ → S30 ✅ → S31a/b/c ✅ — queue complete, see `log.md`;
 S31 was cataloged during S30 as the "Nx"-multiplier + descriptive-% class, amendment followed in practice).
 These edit already-hardened files surgically and
 are hardening-class (commit local, no push).
 ## End-of-session ritual (every session — STATE.md handoff baked in)
 1. `bash scripts/test-runner.sh` → `Failed: 0` + counts 29/19/25/6.
--- a/docs/hardening/review-R2a.md
+++ b/docs/hardening/review-R2a.md
@ -1,207 +0,0 @@
 ---
 type: cold-review
 batch: R2a
 journey: "Create — atomic emitters"
 scope: "FROZEN committed files vs HEAD 9567689 (no pending diff; post-hardening cold pass)"
 method: "2 independent cold Opus reviewers per surface (intent + correctness), no cross-feed; every mechanical claim tool-grounded (anti-fabrication mandate); reviewers carry NO drafting-session context"
 surfaces: [post, react, carousel, video, multiplatform]
 reviewers:
  - "intent-lens (conformance: intent delivery + cross-ref resolution + class predicates + terminology)"
  - "correctness-lens (internal consistency + bound-vs-canonical + checklist arithmetic + structure)"
 status: "COMPLETE — all 5 surfaces reviewed (post, react, carousel, video, multiplatform)"
 verdict: REWORK
 counts: { BLOCKER: 0, MAJOR_systemic: 1, MAJOR_surface: 1, MINOR: 13, SUGGESTION: 8 }
 ---
 # Cold review — R2a (Create · atomic emitters)
 Independent post-hoc cold review of the 5 atomic Create-journey emitters, on the FROZEN committed
 files. Mirrors the S1 `review.md` model (the one cold-review method that did **not** fabricate):
 read-and-show before assert, every `file:line` tool-confirmed. The per-command interactive gate
 (S2–S26, `log.md`) already passed these; this pass adds the **independent** axis that gate never had.
 **Independence cross-check worked:** on every WAVE-1 surface the two blind lenses converged on the
 same real defects (personal-stories band in post; "full angle set below" in react; slide-scaffold +
 slide-count in carousel) — convergence from two no-cross-feed reviewers is the signal that a finding
 is real, not an artifact of one reviewer's framing.
 ---
 ## ★ Cross-cutting finding (systemic — spans all 10 content commands)
 ### MAJOR (systemic) — `printf '%s' '<TEXT>'` clipboard pattern silently corrupts content containing an apostrophe
 - **Pattern (verified by main, independent of reviewers):** `printf '%s' '<PLACEHOLDER>' | node ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/clipboard-helper.mjs`, followed by an **unconditional** `Then confirm: "Copied to clipboard."`
 - **Blast radius — all 10 content-emitting commands** (grep-confirmed): `post.md:153`, `quick.md:162`, `react.md:149`, `carousel.md:211`, `video.md:175`, `multiplatform.md:121`, `pipeline.md:139`, `first-post.md:141`, `firsthour.md:72`, `onboarding.md:221`.
 - **Mechanism:** the executing model substitutes the draft into the **single-quoted** bash argument. English LinkedIn drafts almost always contain an apostrophe ("it's", "don't", "here's"); a literal `'` terminates the bash string → printf receives word-split fragments → clipboard gets garbled/truncated text (`printf '%s' 'It's a test'` → `Itsatest`). The command gives **no escaping guidance**.
 - **Why it matters (trust-breaking):** the step runs "silently" then **unconditionally** reports success, so on the most common content shape the clipboard is corrupt while the user is told the copy worked. It is the headline convenience feature of every content command.
 - **Severity note:** flagged MAJOR (not BLOCKER) — it doesn't crash the session, and a careful executing model *might* escape; but the instruction's default path fails. Independently surfaced by `rev-react-intent` (MAJOR) and `rev-post-intent` (SUGGESTION, "convention-level").
 - **Disposition (NOT fixed here — review finds, operator decides; 10-file change = own go):** switch the convention to a no-in-content-quoting form — write the draft to a temp file and feed via stdin (`node …/clipboard-helper.mjs < "$tmp"`), or a quoted heredoc. Fix once, consistently, across all 10. **Recommend treating this as the first fix that comes out of R2a.**
 ---
 ## post.md — VERDICT: REWORK (1 MAJOR · 2 MINOR · 1 SUGGESTION)
 Class: post-emitting (primary) + guided/stateful (8-step). Both lenses confirm intent delivered;
 all cross-refs resolve (2 agents, 2 routes, 2 scripts, 7 assets — tool-confirmed); no "thought leadership".
 ### MAJOR — Step 3 "Personal stories" band (1,000–1,400) contradicts the file's own Step 5 gate + canonical SSOT (1,200–1,800)
 - `post.md:87` — Step 3 assigns "Personal stories | Medium text post (1,000-1,400 chars)" — a third band present nowhere else.
 - `post.md:128` — Step 5 quality checklist requires "Character count: 1,200-1,800 (optimal range)" for the same post.
 - `hooks/prompts/content-quality-gate.md:17` — canonical: "Standard posts: 1,200-1,800". A personal story is a standard text post (not quick 150–500).
 - **impact:** a personal-story draft written to Step 3 at ~1,050 chars passes Step 3 but FAILS the Step 5 checklist and the save-time quality-gate hook. The command self-contradicts.
 - **Both lenses flagged this** (rev-post-correct MAJOR, rev-post-intent MINOR). Recorded at the higher severity: it hits a real gate path, not just advisory text.
 - **disposition:** raise line 87 floor to 1,200–1,800, OR (if shorter personal stories are intentional) push the sub-band to the canonical SSOT first and reconcile `:128` + `content-quality-gate.md:17` — never leave a divergent band only in this file.
 ### MINOR — Step 4 component minimums sum below the 1,200 optimal floor
 - `post.md:100-104` — Hook 110-140 + Context 200-300 + Insight 400-800 + Implication 200-300 + CTA 50-100. Minimums sum to **960** (110+200+400+200+50); maximums to 1,640.
 - **impact:** following every section at its minimum yields a 960-char post, below the 1,200 floor asserted at `:7/:86/:128` and canonical `:17`. Loose guidance, not a hard gate, but a writer hugging the low end lands under-length.
 - **disposition:** accept as-is, or lift Insight/Context minimums so the component floor reaches ~1,200.
 ### SUGGESTION — clipboard apostrophe breakage → see ★ cross-cutting finding (`post.md:153`).
 ---
 ## react.md — VERDICT: REWORK (1 MAJOR · 3 MINOR · 1 SUGGESTION)
 Class: post-emitting + graceful-degradation on bad/empty URL (delivered, `react.md:60,194`). Intent
 (URL→post pipeline) delivered; all 7 cross-refs resolve; no "thought leadership".
 ### MAJOR — clipboard apostrophe breakage → see ★ cross-cutting finding (`react.md:148-151`).
 (Originally surfaced here by rev-react-intent; promoted to the cross-cutting section.)
 ### MINOR — `/linkedin:summarize` trigger has no backing command
 - `react.md:9` — the frontmatter description lists "/linkedin:summarize" among triggers. `ls commands/summarize.md` → does not exist; not among the 29 commands.
 - **impact:** advertises a slash-command alias that resolves to nothing; a user typing it gets no command. Dead/aspirational trigger.
 - **disposition:** remove `/linkedin:summarize` from the trigger list, or add a summarize alias command.
 ### MINOR — "the full angle set below" is a dead in-file locator
 - `react.md:95` — "present 2-3 alternatives from **the full angle set below**." No enumerated full angle set appears below this line; Step 4's table (`:81-86`) lists only 4 preferred + 4 fallback; the 8 universal angles live in `references/content-angles.md` (`:273`), not "below."
 - **Both lenses flagged this** (rev-react-intent + rev-react-correct).
 - **impact:** dangling locator on the "try a different angle" path; the model must guess "below" means the reference file.
 - **disposition:** change "the full angle set below" → "the 8 universal angles in `references/content-angles.md`".
 ### MINOR — "medium post" label diverges from canonical "standard" band
 - `react.md:119` — "Character target: 1,200-1,800 chars (medium post)". The **number is correct** (matches canonical standard band `content-quality-gate.md:17` + CLAUDE.md rule 2), but canonical/CLAUDE.md label it "standard"; no "medium" tier is defined anywhere.
 - **impact:** cosmetic; the active length gate is unaffected. Risk is reader confusion that a separate "medium" tier exists.
 - **disposition:** accept as-is, or relabel "(standard post)".
 ---
 ## carousel.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 5 MINOR · 4 SUGGESTION)
 Class: guided/stateful (content-emitting). Intent (5–8 slide deck + caption, optional image render,
 text-only degradation) delivered; all cross-refs resolve (differentiation-checker, templates,
 algorithm-signals, clipboard + state scripts, mcp-image params valid); hook bound `:97` matches SSOT;
 no "thought leadership". Clean on all blocking dimensions — findings are polish.
 ### MINOR — slide-count minimum stated two ways (6 vs 5)
 - `carousel.md:41-45` — Step 1 offers all 5 templates as "(6-8 slides)"; `carousel.md:114` — Step 5 gate checks "5-8 slides total (7 is optimal)". Minimum disagrees (6 vs 5).
 - **Both lenses flagged this.** Mirrors the upstream split in `assets/templates/carousel-templates.md:11` ("5-8") vs per-template headers ("6-8").
 - **impact:** a 5-slide deck passes Step 5 but was never offered in Step 1. Cosmetic guidance, not a hard break.
 - **disposition:** align the floor (pick 5 or 6 across Step 1 + Step 5); ideally fix the source too.
 ### MINOR — inlined Step 5 checklist drops an item vs the source it cites (7 vs 8)
 - `carousel.md:109` says "Run against the Carousel Quality Checklist from carousel-templates.md", then inlines 7 items (`:111-117`, `grep -c` = 7). The cited source has 8 (`carousel-templates.md:276-283`); the dropped one is `:283` "Exported as PDF, under 100 MB".
 - **impact:** the export/size check only resurfaces in Step 6's text-only branch (`:184`); when image generation succeeds, the PDF/100 MB constraint is never surfaced in the gate.
 - **disposition:** add the PDF/under-100 MB item to the Step 5 list, or stop claiming verbatim fidelity to the source.
 ### MINOR — slide body scaffold provides 5 line-slots but the rule permits up to 7
 - `carousel.md:73-77` models 5 BODY lines (4-5 optional); `carousel.md:87` + `carousel-templates.md:10` permit "5-7 lines".
 - **Both lenses flagged this.**
 - **impact:** a slide legitimately needing 6-7 lines has no scaffold slot; the literal template caps generation at 5.
 - **disposition:** extend the scaffold to 7 optional lines, or tighten the rule/template to "max 5".
 ### MINOR — caption voice-guardian safety-net claim doesn't engage in this flow
 - `carousel.md:123` — "(The voice-guardian hook scores the caption on save.)" The PreToolUse gate fires only on Write|Edit of LinkedIn content, but this command never Writes the caption — Step 6 pipes it to clipboard (`:210-212`), Step 7 mutates state via `node -e` (`:222-231`). No save → hook never scores the caption.
 - **impact:** overstates a backstop that doesn't fire here; could justify under-doing the in-command De-AI check (Step 5).
 - **disposition:** drop the parenthetical or qualify it ("only if you later save the caption to a file").
 ### MINOR — no-external-link rule (Content Quality Rule #3) absent from caption guidance
 - `carousel.md:93-105, 121-125` — the caption is feed text on the same reach mechanics, but neither Step 4 nor the De-AI gate mentions the no-body-link rule.
 - **impact:** a caption with an inline link incurs the documented reach penalty with nothing in this surface catching it.
 - **disposition:** add "no links in the caption body (put links in first comment)" to the De-AI gate or Step 4.
 ### SUGGESTION — orphan provenance comment for an unused capability
 - `carousel.md:18` — `<!-- MERMAID_CHART_RESOLUTION: UNTESTED -->`. Mermaid is never referenced anywhere in the file (only mcp-image is used).
 - **disposition:** remove the vestigial marker (or move the note to a design doc).
 ### SUGGESTION — dual slide-count framing (6-8 vs 5-8); locally-defined per-slide bounds (header "max 8 words" `:70`, body "max 50 chars" `:73-77`, no canonical SSOT — no overlap with post bounds, noted for completeness); buzzword list 8 words `:123` faithful to CLAUDE.md Rule #4 while canonical hook flags 10 (gap lives between CLAUDE.md + hook, not in this file).
 ---
 ## video.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 3 MINOR · 1 SUGGESTION)
 Class: guided/stateful (8-step script build) + post-emitting sub-surface (the 200–400 char caption).
 Intent (paced 30s/60s/90s/2min video script + on-video captions + thumbnail + post caption + first
 comment, delegated to `video-scripter`) delivered; `video-scripter` + `differentiation-checker`
 resolve; word-budget math internally consistent (30/60/90/120s × 2.5 wps = 75/150/225/300, `:64-67`);
 no "thought leadership".
 ### MINOR — muted-watch statistic stated two ways
 - `video.md:100` "~85% watch without sound" vs `video.md:120` "~80–85% watch muted" — same claim, two figures in one frozen file.
 - **Both lenses flagged this.** 85% sits inside 80–85% so not a hard contradiction, but reads as unreviewed precision in a quality-gate checklist.
 - **disposition:** pick one figure (recommend "~80–85%") in both places.
 ### MINOR — post caption (200–400) is a third length band vs canonical quick (150–500)
 - `video.md:121,158` specify "200-400 chars"; `content-quality-gate.md:18` quick = 150–500. 200–400 is a narrower subset (no hard conflict) but a band not present in the SSOT.
 - **impact:** a reader can't tell from video.md whether 200–400 is intentional or drift.
 - **disposition:** accept if intentional (captions deliberately shorter), but add a one-line note that 200–400 is a deliberate sub-band of the 150–500 quick range.
 ### MINOR — caption has no mobile-cutoff / first-line hook discipline
 - `video.md:122,129,156-158` — the caption (feed text, truncated at the same "...see more" cutoff as any post) gets a length band + De-AI + no-body-link + buzzword strip, but NO instruction to front-load value within the ~110–140 cutoff. (`:101` "first line reads on-screen" is the muted-autoplay test on the VIDEO's on-screen text, not the feed caption.)
 - **impact:** vs text-post parity (SSOT hook 110–140) the caption's truncation is unguarded; a buried lede underperforms in-feed.
 - **disposition:** defensible to accept (video is primary content), or add "caption's first line should land value before the mobile cutoff".
 ### SUGGESTION — clipboard apostrophe breakage → see ★ cross-cutting finding (`video.md:175`).
 ---
 ## multiplatform.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 1 MINOR · 3 SUGGESTION)
 Class: routing + guided/stateful (content-adaptation). **post-emitting predicate does NOT apply** —
 this command consumes a LinkedIn post and emits adaptations for OTHER platforms (Twitter/slides/
 YouTube), so the LinkedIn quality-gate (hook 110–140 / length band / no-body-link / topic→pillars) is
 out of scope; the buzzword check IS carried (`:46-48`, mirrors CLAUDE.md rule #4 exactly). Intent
 delivered (3 promised platforms = 3 AskUserQuestion options = 3 templates); routing resolves
 (`/linkedin:newsletter` at `:6,:34,:36,:132` → `commands/newsletter.md` exists); no subagent refs;
 graceful degradation present (`:27-29`, forbids fabricating source); no "thought leadership".
 ### MINOR — clipboard apostrophe breakage → see ★ cross-cutting finding (`multiplatform.md:121`)
 - Elevated exposure noted: Twitter threads + YouTube CTAs are contraction-heavy (don't/it's/I'll), so this surface is *more* exposed to the systemic bug than most.
 ### SUGGESTION — Twitter "280 chars max" is locally-defined (no LinkedIn SSOT)
 - `multiplatform.md:53` — the only numeric bound in the file; an X/Twitter limit, correct value, cannot diverge from the LinkedIn SSOT. Noted for completeness.
 ### SUGGESTION — "write once, publish everywhere" tagline overstates the command
 - `multiplatform.md:4-5` — the tagline implies publishing; the command only adapts + saves to drafts (`:118`) + copies to clipboard. No publish action exists.
 - **disposition:** accept, or soften to "adapt once, post everywhere" / "draft for every platform".
 ### SUGGESTION — Step 1 always asks platform even when the trigger already names it
 - `multiplatform.md:38-41` unconditionally invokes AskUserQuestion, yet triggers include "adapt for twitter"/"turn into thread" (`:7`) that already pin the platform — against the commands-section principle to minimize interactive steps / infer from context.
 - **disposition:** accept, or "skip if the platform is already evident from the user's request".
 ---
 ## Gate decision — R2a COMPLETE (5 surfaces)
 | Surface | Verdict | BLOCKER | MAJOR | MINOR | SUGGESTION |
 |---|---|---|---|---|---|
 | post | REWORK | 0 | 1 (+systemic) | 1 | — |
 | react | REWORK | 0 | (systemic) | 3 | — |
 | carousel | ALLOW | 0 | 0 | 5 | 4 |
 | video | ALLOW | 0 | 0 | 3 | 1 |
 | multiplatform | ALLOW | 0 | 0 | 1 | 3 |
 | **★ cross-cutting** | — | 0 | **1 (systemic, 10 files)** | — | — |
 **Batch verdict: REWORK** — 2 of 5 surfaces (post, react), driven by **2 distinct MAJORs**:
 (1) the systemic clipboard-`printf` corruption (10 content commands), and (2) post's personal-stories
 band contradicting its own Step 5 gate + the canonical SSOT. **0 BLOCKER anywhere.** carousel / video /
 multiplatform are ALLOW (polish only).
 **Independence verdict:** every WAVE-1 REWORK/MINOR was independently surfaced by **both** blind lenses
 (clipboard, personal-stories band, "full angle set below", slide-scaffold, slide-count, muted-stat) —
 the convergence signal that these are real defects, not single-reviewer framing.
 Cold review **finds**; it changes no code. Each fix is its own operator-gated decision. Recommended
 first fix out of R2a: the systemic clipboard pattern (one change, 10 files, highest blast radius).
 Local-only (hardening-class), not pushed.
--- a/docs/hardening/review-R2b.md
+++ b/docs/hardening/review-R2b.md
@ -1,281 +0,0 @@
 ---
 type: cold-review
 batch: R2b
 journey: "Create — orchestrators & front-door"
 scope: "FROZEN committed files at HEAD 5474df5 (clean tree; post-hardening cold pass)"
 method: "2 independent cold Opus reviewers per surface (intent + correctness), no cross-feed; every mechanical claim tool-grounded (anti-fabrication mandate); reviewers carry NO drafting-session context"
 surfaces: [create, batch, pipeline, newsletter]
 reviewers:
  - "intent-lens (conformance: intent delivery + cross-ref resolution + class predicates + terminology)"
  - "correctness-lens (internal consistency + bound-vs-canonical + checklist arithmetic + structure)"
 status: "COMPLETE — all 4 surfaces reviewed (create, batch, pipeline, newsletter)"
 verdict: REWORK
 counts: { BLOCKER: 0, MAJOR: 3, MINOR: 10, SUGGESTION: 6, systemic_patterns: 2 }
 ---
 # Cold review — R2b (Create · orchestrators & front-door)
 Independent post-hoc cold review of the 4 Create-journey orchestrators/front-door, on the FROZEN
 committed files (HEAD `5474df5`). Mirrors the S1 `review.md` + R2a model (the cold-review method that
 did **not** fabricate): read-and-show before assert, every `file:line` tool-confirmed, reviewers carry
 no drafting-session context. The per-command interactive gate (`log.md`) already passed these; this
 pass adds the **independent** axis that gate never had.
 **Independence cross-check — two outcomes worth noting this batch:**
 1. **Convergence** (the R2a pattern): both blind lenses independently surfaced the same real defect on
   several surfaces — batch's bare-vs-prefixed reference path, batch's 3a/3b component-band tension,
   newsletter's `allowed-tools` omission, create's 8-option `AskUserQuestion`.
 2. **Divergence resolved by grounding** (new this batch, the strongest argument FOR the two-lens
   method): on `newsletter` the intent-lens **asserted** the resumption table "maps every currentPhase
   to the correct resume step"; the correctness-lens **counted** the rows (17) against the canonical
   `_doc.phases` (18) and found the `contract-gate` row missing. Main re-grounded it independently
   (below) → the correctness-lens is right. The independence axis caught a real MAJOR that one lens had
   asserted away.
 ---
 ## ★ Cross-cutting finding #1 (systemic) — 5-component draft scaffold (960–1,640) cannot satisfy the 1,200–1,800 standard band it is gated against
 - **Pattern (verified by main, independent of reviewers — `grep` blast radius):** the identical
  5-component "standard post" breakdown — `Hook 110-140` + `Context 200-300` + `Insight 400-800` +
  `Implication 200-300` + `CTA 50-100` — appears in **exactly 3 files**: `post.md:100-104`,
  `batch.md:88-92`, `pipeline.md:58-62`. (`grep -rln "Insight.*400" commands/` → those three only;
  `quick`/`first-post`/`react` carry the lone `Hook 110-140` line, NOT the full scaffold, so are
  unaffected.)
 - **Grounded arithmetic:** component **min-sum = 110+200+400+200+50 = 960** · **max-sum =
  140+300+800+300+100 = 1,640**. Each file then gates the SAME post against the canonical standard band
  **1,200–1,800** (`content-quality-gate.md:17`; `post.md:128`, `batch.md:95`, `pipeline.md:77`).
 - **Mechanism (two-sided):** (a) a draft built at the component minimums is **960 chars — 240 below**
  the 1,200 floor enforced by the next step AND the live PreToolUse `content-quality-gate` hook;
  (b) the component maximums sum to **1,640 — 160 below** the 1,800 ceiling, so the scaffold literally
  cannot reach the upper half of its own target band.
 - **Why it matters:** on the most common path (drafting a standard text post) the drafting recipe and
  the acceptance test are mutually incompatible, with no transition/connective slack to close the
  960→1,200 gap. In `batch` the defect is sharper: the 3a scaffold is **format-blind** (always the
  5-component standard layout) while the 3b gate is **format-aware** (`batch.md:114` `format:
  [text/carousel/video]`, rotation `:76`), so a `quick`-format post built from the scaffold (960–1,640)
  also blows the quick band (150–500). In `pipeline` the contradiction is between two **adjacent**
  steps (Step 2 draft → Step 3 scorecard).
 - **Severity:** recorded **MAJOR** in `batch` and `pipeline` (real adjacent-step / gate contradiction
  on every standard post). **Reconciliation note for R2a:** R2a recorded the same scaffold in `post.md`
  at **MINOR** ("component minimums sum below the 1,200 optimal floor") and flagged only the min-side.
  The batch/pipeline analysis shows it is a two-sided, gate-hitting contradiction, not merely loose
  guidance — the post.md instance is arguably under-rated and should be reconciled in the same fix.
 - **Disposition (NOT fixed here — review finds, operator decides; 3-file change = own go):** one
  consolidated fix across all 3 files — raise the component floors so min-sum ≥ 1,200 (e.g. widen
  Context/Insight) AND either lift the ceiling or accept ~1,640, AND scope the standard 5-component
  scaffold explicitly to standard-format posts where the command is format-aware (`batch`), adding
  per-format draft guidance for quick/carousel/video. **Recommend treating this as the second
  consolidated fix out of the sweep, after the R2a clipboard fix.**
 ## ★ Cross-cutting finding #2 (recurring) — bare relative reference paths vs `${CLAUDE_PLUGIN_ROOT}/`
 - **Pattern:** several `Read`/reference paths are written **bare** (resolved against the runtime cwd)
  while the same file's appendix and most other sites prefix `${CLAUDE_PLUGIN_ROOT}/`. `batch.md:43`
  (`references/content-angles.md`) vs `batch.md:206` (prefixed, same file) — flagged by **both** batch
  lenses. `pipeline.md:31,55,70,75` bare vs `pipeline.md:28,64,107` + appendix `:204-209` prefixed —
  `content-angles.md` is bare at `:55` but prefixed at `:204`.
 - **Impact:** the files exist (not dead refs), but a bare path fails the `Read` when cwd ≠ plugin root,
  on real paths run every invocation (angle-select, optimize). Self-recoverable via Glob, latent.
 - **Disposition:** normalize all bare reference/asset paths to `${CLAUDE_PLUGIN_ROOT}/`. Cheap,
  mechanical; fold into the consolidated fix pass. (Worth a repo-wide grep for the same pattern in the
  other 25 commands during the eventual fix.)
 ---
 ## create.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 1 MINOR · 0 SUGGESTION)
 Class: **routing** (pure delegating front-door). Both lenses confirm intent delivered: Step 0 context →
 Step 1 intent-ID → Step 2 route, with explicit "you do not draft here / do NOT inline the target's
 steps" (`create.md:49-51,64-65`) — delegation purity intact, single source of truth preserved. All 8
 routed targets resolve (`post/quick/react/carousel/video/multiplatform/batch/newsletter`, `:37-44` +
 `:55-62`, `ls`-confirmed); the three enumerations (description `:7`, menu `:37-44`, route table
 `:55-62`) are mutually consistent (8/8/8, same order); no `subagent_type` refs (correct — it routes to
 commands); no "thought leadership". Correctness-lens: **0 findings**.
 ### MINOR — Step 1 directs one `AskUserQuestion` carrying 8 options; documented support is 2–4
 - `create.md:35-44` — "use `AskUserQuestion`" immediately followed by 8 numbered options (`grep -cE
  "^[0-9]+\. \*\*"` → 8). Grounded against the plugin-dev reference
  `command-development/.../interactive-commands.md:469` ("2-4 options per question") + `:906`.
 - **impact:** on the PRIMARY interactive path (user names no format) the front-door instructs a single
  question with double the documented option range.
 - **anti-fabrication caveat (carried from the reviewer, honestly):** grounded = (a) 8 options
  instructed, (b) the documented 2–4 range. NOT grounded = whether the live `AskUserQuestion` runtime
  hard-rejects >4 vs silently truncates/degrades. **If the runtime hard-rejects, this escalates to
  MAJOR/BLOCKER** on the no-format-named path; if it only degrades, the picker is over-long. Worth a
  runtime check before the fix.
 - **disposition:** group the 8 intents into ≤4 options (e.g. Short-form / Reaction / Visual / Long-form
  & batch) with a drill-down, or split into two questions.
 ---
 ## batch.md — VERDICT: REWORK (0 BLOCKER · 1 MAJOR · 3 MINOR · 2 SUGGESTION)
 Class: **guided/stateful + routing** ("create a full week of content"). Intent delivered: the Step 0→5
 flow traces the frontmatter promise; all cross-refs resolve (`trend-spotter`, `content-planner` →
 `agents/`; `/linkedin:calendar` → `commands/`; `queue-manager.mjs` + `ical-generator.mjs` exports +
 the 8-arg `queueAdd` call/signature match; all 6 reference/asset paths + `SKILL.md`); graceful
 degradation present; no "thought leadership".
 ### MAJOR — Step 3a component scaffold contradicts the Step 3b band gate → see ★ cross-cutting #1 (`batch.md:88-92` vs `:95`)
 Sharper here than elsewhere: 3a is **format-blind** (always the 5-component standard layout, 960–1,640)
 while 3b is **format-aware** (`:114` `format:[text/carousel/video]`, rotation `:76`), so a `quick`-format
 post built from 3a also blows the quick band 150–500. **Both lenses flagged this** (intent-lens MINOR,
 correctness-lens MAJOR — recorded at the higher severity: it hits a real gate on every standard post).
 ### MINOR — bare reference path → see ★ cross-cutting #2 (`batch.md:43` vs `:206`). Both lenses.
 ### MINOR — `weekly_goal` cadence decoupled from the fixed "3–5 posts" headline
 - `batch.md:5,65` fix the output at "3–5 posts"; `batch.md:52` schedules against `weekly_goal` slot
  templates (2x/3x/4x/5x). At `weekly_goal=2x`, 3–5 posts against 2 weekly slots overflow into the next
  week (`:53` "next available slot after today") — ~2.5 weeks of content under a "full week" label.
 - **impact:** non-breaking (scheduling rolls forward), but "full week" + "3–5" is internally
  inconsistent with the 2x cadence.
 - **disposition:** tie post count to `weekly_goal`, or note that overflow rolls into following weeks.
 ### MINOR — orphan sub-step marker `5b` with no `5a`
 - `batch.md:172` `### 5b. Generate Calendar File`; `grep -n "5a" batch.md` → no match (exit 1). Step 3
  has 3a/3b/3c/3d; Step 5 jumps straight to 5b.
 - **disposition:** renumber to `5a`, or drop the letter.
 ### SUGGESTION — `weekly_goal` default (3x) lives only in the referenced `scheduling-strategy.md:15`, never stated in `batch.md`. Optional one-line "default 3x" for self-evident degradation.
 ### SUGGESTION — `planned_date` metadata never computed
 - `batch.md:109` writes `planned_date: YYYY-MM-DD` into each draft header, but Step 2 only computes
  `scheduled_date`/`scheduled_time` (`:54`); `planned_date` is introduced nowhere upstream.
 - **disposition:** drop `planned_date`, or define where it is derived.
 ---
 ## pipeline.md — VERDICT: REWORK (0 BLOCKER · 1 MAJOR · 4 MINOR · 2 SUGGESTION + clipboard pointer)
 Class: **post-emitting + guided/stateful + routing** ("full end-to-end pipeline"). Intent delivered:
 Steps 0–8 map to every named stage. All post-emitting predicates present (hook 110–140 `:58,:76` ·
 length band `:77` · no-body-link `:78` · buzzword check `:79` · topic→expertise `:49,:55,:80`); all
 cross-refs + function signatures resolve (`content-planner`, `trend-spotter`; `/linkedin:calendar`,
 `/linkedin:analyze`; `queueAdd` 8-arg call/signature; `writeState`/`updatePostTracking`); no "thought
 leadership".
 ### MAJOR — Step 2 component scaffold cannot satisfy the Step 3 total-length gate → see ★ cross-cutting #1 (`pipeline.md:58-62` vs `:77`)
 Adjacent-step contradiction: Step 2 partitions into 960–1,640; the very next step's scorecard asserts
 "Total 1,200–1,800". Correctness-lens, grounded arithmetic.
 ### MINOR — inline buzzword checklist enumerates 8, canonical gate enumerates 10
 - `pipeline.md:79` lists 8 terms (= CLAUDE.md rule 4); SSOT `content-quality-gate.md:13` adds
  'actionable insights' + 'best practices' = 10. A draft passing the inline list can still trip the
  Write hook. (Gate-vs-rule divergence, not unique to this file — also noted on carousel in R2a.)
 - **disposition:** align to the 10-term canonical list, or reference the gate instead of duplicating.
 ### MINOR — bare reference paths → see ★ cross-cutting #2 (`pipeline.md:31,55,70,75`). Intent-lens.
 ### MINOR — Step 4 deferred/queued path falls through into the immediate Publish steps
 - `pipeline.md:97-101` offers "Schedule / Add to queue / Save as draft (no schedule)"; Steps 5–8
  (`:120` "15-20 min BEFORE posting", `:135` Publish, `:158` first-hour, `:171` post-analysis) then run
  with **no branch**. A user who queued/deferred is marched through Pre-Engagement → Publish →
  Monitoring, contradicting the just-made defer decision.
 - **disposition:** add an early-exit after Step 4 for options 2–4 ("if scheduled/queued, end here; Steps
  5–8 run at publish time").
 ### MINOR — Step 7 inlines a static first-hour checklist instead of routing to the stateful surface
 - `pipeline.md:158-169` inlines a 5-item plan; the dedicated `/linkedin:firsthour` delegates to
  `engagement-coach`, persists via `recordFirstHourPlan`, hands off to `post-feedback-monitor` — strictly
  richer (Step 8 already routes to `/linkedin:analyze`, so the inline first-hour is the inconsistent one).
 - **disposition:** route to `/linkedin:firsthour`.
 ### SUGGESTION — over-provisioned `allowed-tools`: `:13` declares `WebFetch` but no body step fetches (trend-spotter does its own). Drop unless a URL-ingest step is intended.
 ### SUGGESTION — hardcoded Norwegian peak times: `:92-95` bakes "European/Norwegian audience" peak windows into the body while `scheduling-strategy.md` (read at `:107`) is the SSOT for slots; conflicts with the domain/audience-general principle. Source from the reference/config.
 ### (pointer) clipboard `printf '%s'` systemic bug — `pipeline.md:139` confirmed present (the only R2b surface in the 10-content-command set). Folds into the R2a ★ cross-cutting clipboard finding; no new derivation.
 ---
 ## newsletter.md — VERDICT: REWORK (0 BLOCKER · 1 MAJOR · 2 MINOR · 2 SUGGESTION)
 Class: **guided/stateful + routing + heavy subagent orchestration** (long-form 18-phase pipeline,
 ~110 KB). Intent delivered: all 18 phases present, ordered, `[GATE]`/`[OPERATØR]`-marked. **18-phase
 count confirmed by both lenses** (`0,1,1.5,2,2.5,3a,3b,4,4.5,5,5.5,6,6.5,7,7.5,8,9,10`; headline `:25`
 matches body + template `_doc.phases` + build-status). All 7 longform agents (fact-checker,
 editorial-reviewer, persona-reviewer, voice-scrubber, content-reviewer, language-reviewer, fact-reviewer)
 present in `agents/` AND invoked; gate sequence ordered before lock (`:1570`): skeleton 2.5 → spine 3a →
 fact-check 5 → editorial 5.5 → persona 6 → headless 6.5 → visual 7.5 → LOCK 8 → hook 9. All `subagent_type`
 carry the `linkedin-studio:` namespace (the 5 prefix-less grep hits are line-wraps). All ~25 cross-refs
 (agents, commands, scripts, configs, render, docs) resolve. Pivot heuristic, flag caps, step-label
 5.5/6.5 consistency all clean. No "thought leadership".
 ### MAJOR — deterministic resumption table omits the contract-gate phase (Step 4.5) → breaks resume between Step 4 and Step 5
 - **Verified by main (independent re-grounding of a lens disagreement):** the resumption table
  `newsletter.md:209-228` has **no `contract-gate` row** (`grep contract-gate` over the table region →
  none). The canonical `_doc.phases` it claims to mirror (`:230-231`) **does** define it —
  `config/edition-state.template.json` lists `"contract-gate — … (Step 4.5)"` between
  `consistency-quality` (Step 4) and `factcheck-sweep` (Step 5). Step 4.5 actually writes it:
  `newsletter.md:988` "Set `currentPhase: "contract-gate"`".
 - **Two concrete breakages on the multi-session resume path (the file's core premise, `:200-204`):**
  1. **Gate skipped on resume.** The rule (`:203-204`) is "run the step AFTER the recorded phase." Row
     `:219` maps `consistency-quality → Step 5` (Fact-check), but the step after Step 4 is Step 4.5
     (contract-gate), not Step 5. A session aborting after Step 4 resumes **past** the deterministic
     contract-gate, never running it.
  2. **Unrecognized phase on resume.** A session aborting after Step 4.5 has `currentPhase:
     "contract-gate"`, absent from the table → falls into the `:232-234` fallback ("missing or
     unrecognized → do NOT guess … confirm with the operator"), defeating the deterministic-resumption
     guarantee the section is built on.
 - **Note:** the linear next-pointers are correct (`:918` "next: contract-gate", `:989` "next:
  fact-check"); only the resume **table** is short one row — the defect surfaces solely on abort/resume
  between Step 4 and Step 5.
 - **Independence note:** the intent-lens asserted this table "maps every currentPhase to the correct
  resume step"; the correctness-lens counted (17 rows vs 18 phases) and found the gap. Main confirmed
  the correctness-lens. Two-lens method earned its keep here.
 - **disposition:** insert a `contract-gate → Step 5 — Fact-check sweep` row, and repoint
  `consistency-quality → Step 4.5 — Contract-gate`.
 ### MINOR — Step 1 says the brief is first persisted "in Step 2"; the rest of the file says Step 1.5
 - `newsletter.md:303` "Record the resolved brief inline (you will persist it to edition-state in **Step
  2**)" contradicts `:287-289`, `:412-418`, `:494-496` (all: first durable write is the **Step 1.5**
  checkpoint). Stale "Step 2" — almost certainly predates the Fix #2 Step 1.5 insertion; non-breaking
  (Step 1 only records inline either way).
 - **disposition:** change `:303` "in Step 2" → "at the Step 1.5 checkpoint".
 ### MINOR — `allowed-tools` omits `SendUserFile` (body-primary operator gate) + `mcp__mcp-image__generate_image` (default image route)
 - `newsletter.md:11-19` declares `Read, Glob, Grep, WebFetch, Bash, AskUserQuestion, Task, Write`. The
  body names `SendUserFile` as the **primary** operator gate at Steps 5.5/6.5/7.5 (13 uses, e.g. `:1138`)
  and mcp-image as the **default** image route (`:1471`); neither is declared. **Both lenses flagged
  this** (intent-lens MINOR, correctness-lens SUGGESTION — recorded at the higher: the declared "default"
  path can't execute under the frontmatter as written). Every use guards with a fallback ("`SendUserFile`
  if available, else a markdown `file://` link"), so it degrades gracefully → not load-bearing.
 - **disposition:** add `SendUserFile` (+ optionally mcp-image) to `allowed-tools`, or downgrade the body
  wording from "default/primary" to "if permitted".
 ### SUGGESTION — undefined "LTL plugin" acronym: `newsletter.md:36,725` ("the LTL plugin" / "the LTL rule"); repo-wide the bare phrase appears only here, no expansion; the plugin is canonically "LinkedIn Studio". (The env vars `LTL_SERIES_ROOT`/`LTL_BRAND` `:48,154-156` ARE a legit convention consumed by `render/build-*.mjs` — not a defect.) Rename to "LinkedIn Studio plugin", or define once.
 ### SUGGESTION — "leveraged" in doc prose (`newsletter.md:1785`, note-only): ordinary verb in the command's own explanatory prose, not generated post content; CLAUDE.md rule 4 targets generated posts. Not a real violation; optionally swap to "drew on / built on".
 ---
 ## Gate decision — R2b COMPLETE (4 surfaces)
 | Surface | Verdict | BLOCKER | MAJOR | MINOR | SUGGESTION |
 |---|---|---|---|---|---|
 | create | ALLOW | 0 | 0 | 1 | 0 |
 | batch | REWORK | 0 | 1 | 3 | 2 |
 | pipeline | REWORK | 0 | 1 | 4 | 2 |
 | newsletter | REWORK | 0 | 1 | 2 | 2 |
 | **★ cross-cutting #1** (scaffold, 3 files) | — | 0 | (counted in batch + pipeline; spans post.md from R2a) | — | — |
 | **★ cross-cutting #2** (bare paths) | — | 0 | 0 | (counted in batch + pipeline) | — |
 **Batch verdict: REWORK** — 3 of 4 surfaces (batch, pipeline, newsletter), each with **1 MAJOR**:
 (1) the systemic 5-component scaffold contradicting the 1,200–1,800 band (batch + pipeline; spans
 post.md from R2a), and (2) newsletter's resumption table missing the contract-gate phase. **0 BLOCKER
 anywhere.** `create` is ALLOW (one option-count MINOR with a runtime caveat).
 **Independence verdict:** convergence on batch path-prefix / batch 3a-3b band / newsletter allowed-tools
 / create 8-option (both lenses) — plus one **divergence resolved by main's grounding** (newsletter
 resumption table: intent-lens asserted complete, correctness-lens counted the gap, main confirmed). Both
 the convergence and the resolved divergence are signals these are real defects, not single-reviewer
 framing.
 **Systemic findings now span R2a+R2b:** clipboard `printf` (R2a, 10 files) · component scaffold (R2b, 3
 files incl. post.md from R2a) · bare reference paths (R2b, 2 files, worth a repo-wide grep). Cold review
 **finds**; it changes no code. Each fix is its own operator-gated decision. Recommended consolidated-fix
 order out of the sweep so far: (1) clipboard `printf` [R2a, 10 files, highest blast radius], (2)
 component scaffold [3 files], (3) bare reference paths [grep-driven], then the per-surface items.
 Local-only (hardening-class), not pushed.
--- a/docs/hardening/review-R3.md
+++ b/docs/hardening/review-R3.md
@ -1,218 +0,0 @@
 ---
 type: cold-review
 batch: R3
 journey: "Engage — post-publish & longform-support surfaces"
 scope: "FROZEN committed files at HEAD 2b70660 (clean tree; post-hardening cold pass)"
 method: "2 independent cold Opus reviewers for the round (intent + correctness), each covering all 4 surfaces, no cross-feed; every mechanical claim tool-grounded (anti-fabrication mandate); reviewers carry NO drafting-session context"
 surfaces: [firsthour, calendar, headless-review, pivot]
 reviewers:
  - "intent-lens (conformance: intent delivery + cross-ref resolution + class predicates + graceful degradation + terminology)"
  - "correctness-lens (internal consistency + bound-vs-canonical + checklist/phase arithmetic + allowed-tools completeness)"
 status: "COMPLETE — all 4 surfaces reviewed (firsthour, calendar, headless-review, pivot)"
 verdict: REWORK
 counts: { BLOCKER: 0, MAJOR: 1, MINOR: 3, SUGGESTION: 5 }
 ---
 # Cold review — R3 (Engage · post-publish & longform-support)
 Independent post-hoc cold review of the 4 Engage-journey surfaces, on the FROZEN committed files
 (HEAD `2b70660`). Mirrors the S1 `review.md` + R2a + R2b model (the cold-review method that did **not**
 fabricate): read-and-show before assert, every `file:line` tool-confirmed, reviewers carry no
 drafting-session context. The per-command interactive gate (`log.md`) already passed these; this pass
 adds the **independent** axis that gate never had.
 **Independence cross-check — both outcomes recurred this batch:**
 1. **Convergence:** both blind lenses independently surfaced the same real defect on `headless-review`
   (`SendUserFile` invoked on the primary surfacing path but absent from `allowed-tools`).
 2. **Divergence resolved by grounding** (the strongest argument FOR the two-lens method, recurring from
   R2b's newsletter): on `calendar` the intent-lens flagged a **MAJOR** (the publish/reschedule/cancel
   actions key off `id`/`draft_path`/`character_count` that the queue load never surfaces), while the
   correctness-lens passed the surface as ALLOW — its structural pass found the step/option arithmetic
   reconciled but did **not** trace the data-flow from load → display → action placeholders. Main
   re-grounded `queueFormatSummary`'s actual output independently (below) → the intent-lens is right. The
   independence axis caught a real MAJOR one lens never probed.
 ---
 ## Connections to existing systemic findings (no NEW ★ cross-cutting this batch)
 R3 surfaces **connect to** the two systemic patterns already recorded in R2a/R2b rather than adding new
 ones. Both connections were re-grounded by main on the R3 files:
 - **★ cross-cutting #1 (clipboard `printf '%s'`, R2a, 10 files) — firsthour confirmed present.**
  `firsthour.md:72` `printf '%s' '<DRAFT_COMMENTS_BLOCK>' | node …/clipboard-helper.mjs` + `:75` the
  unconditional "Copied your draft comments to clipboard." This is the exact systemic pattern: a
  single-quoted shell string corrupts any draft text containing an apostrophe (`it's`, `don't` — common
  in natural comment copy), and the "Copied" confirmation is unconditional. firsthour is one of the 10
  files STATE already lists; **no new derivation — folds into the R2a ★ #1 consolidated fix.**
 - **★ cross-cutting #2 (bare relative reference paths vs `${CLAUDE_PLUGIN_ROOT}/`, R2b) — firsthour adds
  3 sites.** `firsthour.md:110` (prose parenthetical), `:118`, `:119` (Reference-Files pointer list) are
  bare `references/…` while the same file's **executable** blocks correctly prefix `${CLAUDE_PLUGIN_ROOT}/`
  (`:72`, `:84`) and sibling commands prefix their Reference-Files lists too (`calendar.md:206-207`).
  **Lower impact than the R2b instances** (firsthour's bare paths are in a pointer list + one prose
  mention, not inside an executable `Read`), so latent rather than active — but a real parity break worth
  catching in the same repo-wide grep pass. Counted as a per-surface MINOR below.
 **Recurring (SUGGESTION-class, NOT elevated to ★) — `allowed-tools` over-declaration.** Three of the four
 surfaces declare a tool the body never invokes: `firsthour` (`Glob`/`Grep`), `calendar` (`Write`/`Edit`),
 `pivot` (`Grep`). Harmless (over-declaration widens permission surface but breaks nothing;
 *under*-declaration would be the real risk and there is none). Noted per-surface; optional minimal-surface
 trim, fold into the consolidated fix if touched.
 ---
 ## firsthour.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 1 MINOR · 2 SUGGESTION + clipboard pointer)
 Class: **guided/stateful + subagent orchestration** ("post-publish first-hour / reply-loop sprint").
 Intent delivered: Step 0 load → Step 1 identify post → Step 2 delegate to `engagement-coach` → Step 3
 present (timeline / targets / drafts / velocity) → Step 4 `recordFirstHourPlan` persist → Step 5
 `post-feedback-monitor` handoff. Both subagent targets carry the `linkedin-studio:` namespace and resolve
 (`agents/engagement-coach.md`, `agents/post-feedback-monitor.md`); `recordFirstHourPlan` signature
 (`planDate, postTopic, targets, draftComments, plan`) matches the call (`:85-91` vs `state-updater.mjs:235`);
 6 steps (`grep -cE '^## Step'` = 6), sequential, no orphan markers; Step 2→3 value-flow reconciles (coach
 asked for target-list / self-comments / timeline / velocity, Step 3 presents exactly those four); no
 "thought leadership". Empty-state degradation present.
 ### MINOR — bare reference paths → see Connections (★ #2) (`firsthour.md:110, :118, :119` vs prefixed `:72, :84`). Intent-lens.
 ### SUGGESTION — Step 0 voice-samples read has no stated fallback
 `firsthour.md:29` reads voice-samples "so every draft comment is in the user's voice," but no path is
 specified when the file is absent (progressive onboarding suppresses voice until 5+ samples, CLAUDE.md rule
 7). Non-breaking (the coach can still draft), but the degradation is unstated. Add "if absent, draft in a
 neutral first-person register and skip voice-matching."
 ### SUGGESTION — `allowed-tools` over-declares `Glob`/`Grep` (`:12-13`); body invokes neither. Correctness-lens. See Recurring note.
 ### (pointer) clipboard `printf '%s'` systemic bug — `firsthour.md:72, :75` confirmed present → folds into ★ #1 (R2a). No new derivation.
 ---
 ## calendar.md — VERDICT: REWORK (0 BLOCKER · 1 MAJOR · 0 MINOR · 1 SUGGESTION)
 Class: **guided/stateful + routing** ("view/manage scheduling queue + publish action"). The **view** side
 (14-day calendar, format mix, pillar balance) delivers; the **action** side has a load-bearing data gap.
 Step/sub-step/option arithmetic all reconcile (correctness-lens: Steps 1–4 sequential; sub-markers 3a–3f
 present and ordered; 5 options offered with 4 handlers + explicit no-op, no dangling branch; Quick-Routing
 anchor `:89` exists); empty/missing-queue degradation present and correct (`queue-manager.mjs:12-27`
 returns `[]`; body 3a routes "no posts" → `/linkedin:batch`/`quick`); no "thought leadership".
 ### MAJOR — the queue load surfaces none of the `id`/`draft_path`/`character_count` the publish/reschedule/cancel actions require (`calendar.md:31-43, :117, :169-174, :185` vs `queue-manager.mjs:112-122`)
 - **Verified by main (independent re-grounding of the lens divergence):** Step 1 loads the queue
  **exclusively** through `queueFormatSummary` (`:31-43`). `queueFormatSummary` (`queue-manager.mjs:112-122`,
  read in full) emits only `  {date} {time} | {hook…} | {pillar} ({fmt}) [{status}]` — it exposes **no**
  `id`, **no** `draft_path`, **no** `character_count`. The Step 2 display (`:52-71`) mirrors that field set.
 - **Three concrete breakages on the action paths:**
  1. **Mark-as-published (the PRIMARY route — Quick-Routing `:25` jumps straight here)** calls
     `queueUpdateStatus('[post-id]', 'published')` (`:117`) — `[post-id]` was never surfaced. Step 3d
     also needs `charCount: NNNN` (`:129`), likewise un-surfaced.
  2. **Reschedule** (`:174`) calls `queueAdd('[post-id]','[draft_path]', …, [charCount])` (8-arg signature
     confirmed `queue-manager.mjs:63`) and is **explicitly told** to "carry the unchanged fields
     (draft_path, pillar, format, hook preview, char count) from **the entry shown in Step 2**"
     (`:169-172`) — but Step 2 provably shows none of `draft_path`/`char count`/`id`. A direct
     contradiction: the instruction points at a view that lacks the fields it says to carry.
  3. **Cancel** (`:185`) likewise needs the un-surfaced `[post-id]`.
 - **Self-recovery caveat (honest):** `queue.json` is in Reference Files (`:208`) and `Read` is allowed, so
  a capable agent *could* read raw entries to recover `id`/`draft_path`/`char_count`. But the body never
  instructs that, and the reschedule text actively **mis-directs** to Step 2. Latent-but-real on the
  primary route → MAJOR, not MINOR.
 - **Independence note:** intent-lens flagged MAJOR; correctness-lens passed the surface ALLOW (its
  arithmetic/structure pass reconciled but did not trace load→display→action data-flow). Main grounded
  `queueFormatSummary`'s output → intent-lens confirmed. Two-lens method earned its keep (same shape as
  R2b's newsletter resumption table).
 - **disposition:** in Step 1 also dump raw entries (e.g. `console.log(JSON.stringify(queueUpcoming(14)))`,
  or a `queueRead()` dump exposing `id`/`draft_path`/`character_count`), and re-point the reschedule text
  from "the entry shown in Step 2" to "the raw queue entry loaded in Step 1." Surface the display ordinal →
  queue-`id` mapping so 3b/reschedule/cancel can fill `[post-id]`.
 ### SUGGESTION — `allowed-tools` over-declares `Write`/`Edit` (`:13-14`); every mutation routes through `Bash` node one-liners, "View draft" uses `Read`. Correctness-lens. See Recurring note.
 ---
 ## headless-review.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 2 MINOR · 1 SUGGESTION)
 Class: **guided/stateful + heavy subagent orchestration + routing** (cold 5-archetype package on a frozen
 draft → one operator-gated report). Intent delivered: Step 1 resolve-from-disk → Step 2 freeze (`cp`
 snapshot) → Step 3 parallel fan-out (the `--type`→`subagent_type` table `:141-145` maps to the 5 real cold
 review modes: content / language / fact / persona-resonance / persona-conversion) → Step 4 consolidate →
 Step 5 surface + optional `edition-state.json` persist. All reviewer agents resolve; the writing-contract
 fallback chain terminates in `references/longform-quality-rules.md` (present); degradation well-handled
 (missing `--draft` → edition-state or ask; `cp` unavailable → live draft + note; degraded reviewer
 re-runs). "five archetypes" reconciles with the 5-row `--type` table; 5 flags all consumed, no orphan; no
 "thought leadership".
 ### MINOR — `SendUserFile` invoked on the primary surfacing path but absent from `allowed-tools` (`:208, :221` vs `:19-25`). BOTH lenses.
 - `allowed-tools` (`:19-25`) = Read, Glob, Grep, Bash, AskUserQuestion, Task, Write — no `SendUserFile`;
  body uses it 2× (`grep -c` = 2), as the documented **primary** operator-gated delivery ("operator-gated
  via SendUserFile"). Held at MINOR (not MAJOR) by two guards: `:208` carries an in-text fallback ("else a
  markdown `file://` link") and the report is independently persisted via the declared `Write` (`:206`), so
  surfacing degrades rather than breaks.
 - **disposition:** add `SendUserFile` to `allowed-tools` (if a real tool in the target harness), or soften
  the body wording from "primary/operator-gated via SendUserFile" to "surface via a `file://` link (or
  `SendUserFile` if available)."
 ### MINOR — `v3.1.0` reload anchor misleads on the post-reset version line (`:81-82`)
 - **Verified by main:** `:81-82` says the three cold archetypes "were added in **v3.1.0** — if the session
  predates them, reload." Current `plugin.json` version = **0.5.3** (`:3`); CHANGELOG `[0.4.0]` (2026-05-31)
  records the **honest version reset 4.1.0 → 0.4.0**, so `v3.1.0` is a *pre-reset* tag no longer on the
  current line. A reader on 0.5.3 comparing numerically (0.5.3 < 3.1.0) would wrongly conclude they
  "predate" the agents and must reload — when 0.5.3 is post-reset and already ships all three (they are in
  CLAUDE.md's 19-agent list). Harmless if followed (an unnecessary reload), but the version anchor misleads.
 - **disposition:** anchor by event/date, not the dead tag — e.g. "added with the cold-review package
  (CHANGELOG 3.1.0, pre-reset); reload if your session predates those agents."
 ### SUGGESTION — fan-out N-count unit left implicit: `persona-resonance` issues "one call per active persona" (`:144`) while the header counts "<N> archetypes" / "<N> run in parallel" (`:172, :219`). Pin whether N counts review-modes (5) or Task-calls (≥5). Non-breaking. Correctness-lens.
 ---
 ## pivot.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 0 MINOR · 1 SUGGESTION)
 Class: **guided/stateful + routing (no subagent orchestration by design)** ("re-open a long-form edition so
 cleared gates re-run before lock"). Intent delivered: Step 1 load+locate (stops if `articles.NN` absent) →
 Step 2 measure scope + classify → Step 3 append `pivots[]`, reset `currentPhase`, un-lock, invalidate
 downstream verdicts → Step 4 write `STATE.md` + point at `/linkedin:newsletter`. **Unusually
 well-reconciled** (correctness-lens, all main-checkable): 4 steps sequential; the >20%/>2-sections
 heuristic stated identically in 3 places (`:8-9, :54-55, :92`); the worked example's arithmetic checks out
 (+42% = (1992−1400)/1400 ✓; "added 2 sections … at the boundary of '>2'" correctly attributes the trigger
 to the 20% arm since `2` is not `>2`); the off-by-one phase map is explicitly reconciled (`:102-108`,
 `to-phase` = last *completed* phase, newsletter resumes at the step after); `gatesToRerun` (4 entries `:123`)
 matches the summary + STATE line (`:163, :149-151`). `allowed-tools` correctly **omits `Task`** (delegates
 gate-running to `/linkedin:newsletter`, never spawns). All 3 Reference-File targets resolve; degradation
 present (Step 1 stop-on-missing-article; Step 2.2 absent-baseline → ask operator). No "thought leadership".
 ### SUGGESTION — `allowed-tools` over-declares `Grep` (`:18`); the only grep in the body is a *shell* `grep -c '^## '` inside a `Bash` block (`:89`), not the `Grep` tool. `Glob` plausibly resolves the series root — keep it. Correctness-lens. See Recurring note.
 ---
 ## Gate decision — R3 COMPLETE (4 surfaces)
 | Surface | Verdict | BLOCKER | MAJOR | MINOR | SUGGESTION |
 |---|---|---|---|---|---|
 | firsthour | ALLOW | 0 | 0 | 1 | 2 |
 | calendar | REWORK | 0 | 1 | 0 | 1 |
 | headless-review | ALLOW | 0 | 0 | 2 | 1 |
 | pivot | ALLOW | 0 | 0 | 0 | 1 |
 | **★ #1 clipboard** (pointer, firsthour) | — | — | — | (folds into R2a) | — |
 | **★ #2 bare paths** (firsthour, 3 sites) | — | 0 | 0 | (counted in firsthour) | — |
 **Batch verdict: REWORK** — 1 of 4 surfaces (calendar) carries **1 MAJOR**: the queue load surfaces none of
 the `id`/`draft_path`/`character_count` that publish/reschedule/cancel require, and the reschedule step's
 "carry from the entry shown in Step 2" is a direct contradiction. **0 BLOCKER anywhere.** firsthour /
 headless-review / pivot are ALLOW (pivot notably clean — every count, the heuristic boundary case, and the
 off-by-one phase map reconcile).
 **Independence verdict:** convergence on headless-review `SendUserFile` (both lenses) + one **divergence
 resolved by main's grounding** (calendar: intent-lens flagged the data-gap MAJOR, correctness-lens passed
 it on structural arithmetic, main grounded `queueFormatSummary`'s output and confirmed the MAJOR). Lens-B
 also uniquely caught the `v3.1.0` dead anchor + the over-declaration pattern; Lens-A uniquely caught the
 bare paths + the clipboard pointer. Both lenses earned their keep.
 **Systemic findings now span R2a+R2b+R3:** clipboard `printf` (R2a, 10 files incl. firsthour) · component
 scaffold (R2b, 3 files) · bare reference paths (R2b+R3, now 3 files incl. firsthour's 3 sites). **New this
 batch (SUGGESTION-class, not ★):** `allowed-tools` over-declaration on 3 of 4 R3 surfaces. Cold review
 **finds**; it changes no code. Each fix is its own operator-gated decision. Recommended consolidated-fix
 order unchanged: (1) clipboard `printf` [R2a, 10 files, highest blast radius], (2) component scaffold [3
 files], (3) bare reference paths [grep-driven, now incl. firsthour], then the per-surface items (calendar
 queue-data MAJOR, headless `SendUserFile`/`v3.1.0`, over-declaration trims). Local-only (hardening-class),
 pushed per the 2026-06-30 operator delegation (public catalog, no secrets).
 **Cumulative cold-review coverage: 17/29** (review.md S1=4 · R2a=5 · R2b=4 · R3=4).
--- a/docs/hardening/review-R4.md
+++ b/docs/hardening/review-R4.md
@ -1,293 +0,0 @@
 ---
 type: cold-review
 batch: R4
 journey: "Measure — analytics & performance surfaces"
 scope: "FROZEN committed files at HEAD 69f37ba (clean tree; post-hardening cold pass)"
 method: "2 independent cold Opus reviewers for the round (intent + correctness), each covering all 6 surfaces, no cross-feed; every mechanical claim tool-grounded (anti-fabrication mandate); reviewers carry NO drafting-session context. Divergences re-grounded by main before registration."
 surfaces: [import, report, analyze, audit, ab-test, measure]
 reviewers:
  - "intent-lens (conformance: intent delivery + cross-ref resolution + analytics class predicates + graceful degradation + terminology)"
  - "correctness-lens (internal consistency + bound-vs-canonical + step/phase arithmetic + allowed-tools completeness + metric-definition cross-check)"
 class: "analytics — extra predicate: graceful degradation present · saves/dwell honesty intact (parseOptionalCount → unknown/never 0; dwell unmeasurable; saves NOT folded into engagementRate; analytics I/O via getAnalyticsRoot seam)"
 status: "COMPLETE — all 6 surfaces reviewed (import, report, analyze, audit, ab-test, measure)"
 verdict: REWORK
 counts: { BLOCKER: 0, MAJOR: 1, MINOR: 4, SUGGESTION: 6 }
 ---
 # Cold review — R4 (Measure · analytics & performance)
 Independent post-hoc cold review of the 6 Measure-journey surfaces, on the FROZEN committed files
 (HEAD `69f37ba`). Mirrors the S1 `review.md` + R2a + R2b + R3 model (the cold-review method that did **not**
 fabricate): read-and-show before assert, every `file:line` tool-confirmed, reviewers carry no
 drafting-session context. The per-command interactive gate (`log.md`) already passed these; this pass
 adds the **independent** axis that gate never had. This is the largest batch (6 surfaces) and the only
 **analytics-class** batch, so the round carries the extra class predicate (graceful degradation +
 saves/dwell honesty) alongside the standard intent/correctness lenses.
 **Analytics-class predicate — PASSES across all 6 surfaces (the headline R4 result).** Both blind lenses
 independently confirmed the honesty contract holds wherever a surface touches the metric: **saves** are
 consistently framed as native-only / count-only / ~Sept 2025-onward / no self-serve API / manual-entry
 (`report.md:143,:241`; `import.md:30,:138,:148`; matches `cli.ts:144-146` + `csv-parser.ts:71` where
 `parseOptionalCount` → blank/non-numeric/negative becomes `undefined` = unknown, never 0) and are **never
 folded into `engagementRate`** (`csv-parser.ts:205-208` numerator = reactions+comments+shares+clicks, no
 saves); **dwell** is consistently called unmeasurable/internal-to-LinkedIn (`report.md:241`,
 `import.md:30`); no surface claims to import or compute either. The `getAnalyticsRoot()` per-user data-dir
 seam (`storage.ts`) is described accurately wherever quoted. **No analytics-honesty violation anywhere in
 R4.**
 **Independence cross-check — both outcomes recurred this batch (the case for two lenses, again):**
 1. **Convergence (×2):** both blind lenses independently surfaced (a) `import.md` Step 6a's invalid
   `trends` flags (`--period 4w` / `--metric engagement_rate`) and (b) `ab-test.md:236`'s manual
   engagement-rate formula excluding clicks. Two real defects, found twice without cross-feed.
 2. **Divergence resolved by grounding (×3, in BOTH directions):**
   - **intent over-rated, main corrected down** — on `import` the intent-lens flagged the Step 6a CLI block
     **MAJOR** (→ REWORK), the correctness-lens flagged the same defect **MINOR** (→ ALLOW, "off-primary,
     descriptive"). Main re-grounded `import.md:194-217`: the executable instruction is the **delegation**
     (`:200` "Run /linkedin:report"); the bash block (`:207-210`) is import's *description* of report's
     internals, not import's own step → latent, errors only if copy-run → **MINOR**, import = ALLOW.
   - **correctness uniquely caught, main confirmed** — on `report` the correctness-lens flagged a **MAJOR**
     (heatmap branch routes to a nonexistent "Step 6c"); the intent-lens was silent (its lens probes
     agent/command cross-refs, not internal step-jump arithmetic). Main grounded the step inventory → no
     `6c` exists, real handler is `2c` → **MAJOR confirmed**. This is the batch's load-bearing defect.
   - **correctness uniquely caught, main confirmed** — on `analyze` the correctness-lens flagged a **MINOR**
     (two non-reconciling severity scales); the intent-lens was silent → main grounded `:155-178` vs
     `:227-231` → confirmed **MINOR**.
   Both lenses earned their keep: intent over-rated one finding (corrected by grounding), correctness
   uniquely caught the two structural defects intent's lens never traced.
 ---
 ## Connections to existing systemic findings (no NEW ★ cross-cutting this batch)
 All connections re-grounded by main against the R4 files:
 - **★ #1 (clipboard `printf '%s'`, R2a, 10 files) — R4 adds nothing.** `grep -nE "printf '%s'|clipboard-helper"`
  across all 6 R4 files → NONE. The analytics surfaces do not auto-copy to clipboard (they ingest/report
  data, they don't emit post text), so this systemic pattern simply does not reach the Measure journey.
 - **★ #2 (5-component scaffold band-mismatch, R2b, 3 files) — R4 adds nothing.** The length-band tokens
  that appear (`analyze.md:201` "1,200-1,500", `:217` "1,500-1,800"; `report.md:331` example impressions;
  `ab-test.md:80` test-variable "Short (500) vs standard (1,200-1,800) vs long (2,500+)") are
  recovery-protocol guidance / illustrative numbers / a test variable — none is a component scaffold that
  sums outside the standard band. No defect.
 - **★ #3 (bare reference paths vs `${CLAUDE_PLUGIN_ROOT}/`, R2b+R3) — R4 connects lightly (lowest impact).**
  `analyze.md:22,:23,:93,:259,:260,:261` and `report.md:241` carry bare `references/…` — but **none is
  inside an executable `Read`/`cat`** (`grep -nE "(Read|cat) .*references/"` → NONE executable); all are
  pointer-list entries or prose mentions, the same lowest-impact class as R3's firsthour bare paths.
  Latent parity break worth catching in the same repo-wide `${CLAUDE_PLUGIN_ROOT}/` grep pass; not elevated
  to a per-surface finding (neither lens raised it; cosmetic on these surfaces).
 **Recurring (SUGGESTION-class, NOT elevated to ★) — `allowed-tools` over-declaration now spans R3+R4.**
 Four of six R4 surfaces declare a tool the body never invokes: `import`/`report` (`Glob` — listing done via
 Bash `ls`/`find`), `audit` (`Grep` — no grep call). Combined with R3's 3-of-4, the pattern now touches ~7
 surfaces. Harmless (over-declaration widens the permission surface but breaks nothing; *under*-declaration
 is the real risk and there is one true instance this batch — `report` Step 8b, recorded as MINOR below).
 Optional minimal-surface trim; fold into the consolidated fix if touched.
 **New R4 cluster (not ★, analytics-specific) — sibling-command interface/metric-definition drift.** Two
 of the four MINORs are the same shape: an analytics surface quotes another surface's CLI interface or a
 shared metric definition and drifts from the SSOT — `import.md` Step 6a's stale `trends` flags vs
 `report.md`'s correct ones, and `ab-test.md:236`'s manual engagement-rate (clicks excluded) vs the CLI's
 `engagementRate` (clicks included, `csv-parser.ts:205`). Both are latent (cross-reference paths, not
 primary execution) but both are real consistency debt between siblings. Worth a single reconciliation note
 in the consolidated fix: pin the canonical `engagementRate` definition + CLI flag vocabulary once, and make
 the descriptive blocks point at it rather than restate it.
 ---
 ## import.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 1 MINOR · 1 SUGGESTION)
 Class: **analytics (import orchestrator)**. Intent delivered: primary artifact is the structured JSON batch
 written by `cli.ts import` (Step 4 invokes it; output surfaced Step 5), then analysis delegated to
 `/linkedin:report` (Step 6). Step inventory `1·1b·2·3·4·5·5b·6·6a·6b·7·8` sequential, no gaps; Step 1b/Step 3
 option lists each carry a Skip/Cancel disposition. `allowed-tools` (`:10-15` Bash/Read/Glob/Write/AskUserQuestion)
 — Bash/Read/Write/AskUserQuestion all invoked. Cross-refs resolve (`report.md`, `setup.md`, `quick-import.mjs`,
 `assets/analytics/README.md` all exist; no `subagent_type`). Degradation present (no-CSV, nothing-anywhere,
 missing-deps `npm install`, skipped rows on empty-title/unparseable-date matching `csv-parser.ts:187,193`).
 saves/dwell honesty intact (`:30,:138,:148`). No "thought leadership".
 ### MINOR — Step 6a documents report's CLI calls with invalid period + metric, contradicting the real owner (`import.md:200, :206, :207-210`)
 - **Verified by main (the intent/correctness severity divergence, re-grounded `:194-217`):** `:207-210`
  shows `trends --period 4w --metric impressions` and `--metric engagement_rate` inside a bash fence. The
  CLI accepts period `week|month|quarter|all` (`cli.ts:217`, validated → `process.exit(1)` `:219-221`) and
  metric `…|engagementRate` camelCase (`cli.ts:202-209`, validated → `process.exit(1)` `:233-234`) — both
  `4w` and `engagement_rate` would error. The real owner `report.md:153,:171` uses the correct
  `--period month --metric engagementRate`. `:200` "(period: 4w)" and `:206` "Read expertise_areas" also
  mis-describe report (it takes no period arg, never reads expertise_areas).
 - **Why MINOR not MAJOR (intent-lens rated MAJOR; main grounds down):** the **executable** instruction on
  this path is the delegation at `:200` ("Run /linkedin:report") → routes to `report.md`, which is correct.
  The bash block (`:207-210`) is import's *narrative description* of report's internals ("`/linkedin:report`
  will: … 2. Call `trends`…"), not a step import itself runs. Latent (errors only if a reader copy-runs the
  illustrative block) and the primary delegation path is unaffected → MINOR, not MAJOR. Both lenses
  converged on the defect's existence; only the severity diverged.
 - **disposition:** drop the illustrative bash + the "(period: 4w)"/"expertise_areas" description, or mirror
  report's real invocations (`--period month --metric engagementRate`). Fold into the sibling-drift
  reconciliation note.
 ### SUGGESTION — `allowed-tools` over-declares `Glob` (`:13`); directory listing uses Bash `ls`/`find` (`:37,:47`). Both lenses. See Recurring note.
 ---
 ## report.md — VERDICT: REWORK (0 BLOCKER · 1 MAJOR · 1 MINOR · 1 SUGGESTION)
 Class: **analytics (report orchestrator)**. Intent delivered: produces weekly/monthly/heatmap report JSON
 via `cli.ts report`/`heatmap` + a formatted presentation (Step 6) + an analytics-interpreter handoff
 (`subagent_type: linkedin-studio:analytics-interpreter` `:308` → `agents/analytics-interpreter.md` ✓, `Task`
 declared `:14`). Trends flags `--period month --metric engagementRate` (`:153,:171,:366`) all valid vs CLI.
 Degradation present (no-data, npm install, week-not-found/empty-week/ERR_MODULE_NOT_FOUND `:387-400`).
 saves/dwell honesty exemplary (`:143,:241`). No "thought leadership".
 ### MAJOR — the heatmap report type routes to a nonexistent "Step 6c" (`report.md:72`)
 - **Verified by main (correctness-lens caught it; intent-lens silent — lens gap, not contradiction):** the
  step inventory (`grep -nE '^### Step|^## Step'`) is `1·1b·2·2b·2c·3·4·5·5b·5c·6·7·8·8b` — **there is no
  Step 6c**. `:72` ("If heatmap (option 3): Run the heatmap CLI command and jump to **Step 6c**") points a
  reader nowhere. The real heatmap handler is **Step 2c** (`:106`, immediately below the monthly Step 2b),
  which itself "jump[s] to Step 7" (`:114`). The two sibling branches are correct (monthly `:71`→2b;
  weekly→inline), so heatmap — one of three top-level report types in Step 2 — is the lone misroute.
 - **Severity:** a provably-wrong cross-reference on a **primary menu branch** (top-level report-type
  selection, not a deep-dive). Recoverable (`:72` also says "Run the heatmap CLI command," and 2c sits
  right under 2b, so a capable agent recovers by proximity) — hence MAJOR, not BLOCKER — but it is the
  batch's one load-bearing navigation defect.
 - **disposition:** retarget `:72` from "Step 6c" to "Step 2c".
 ### MINOR — Step 8b markdown export under-declares its write tool (`report.md:429-431` vs `:9-15`)
 - **Verified by main:** Step 8b (reached via Step 8 option 4, "Export report as markdown file") instructs
  "Format the data using this template and **write to file**" / "Save to: …`-report.md`" (`:429-431`).
  Frontmatter `allowed-tools` (`:9-15`) = Bash/Read/Glob/AskUserQuestion/Task — **no `Write`**. This is the
  one genuine *under*-declaration this batch (the real-risk class). Held at MINOR by two mitigations: the
  step is an optional deep-dive (not the primary path), and the declared `Bash` can satisfy the write via a
  heredoc/`cat >`. Sibling `ab-test.md:12-19` declares `Write` for the same `.md`-save, so the omission
  reads as an oversight/parity break.
 - **disposition:** add `Write` to `allowed-tools` (parity with ab-test) or rephrase Step 8b to write via the
  declared `Bash`.
 ### SUGGESTION — `allowed-tools` over-declares `Glob` (`:12`); listing uses Bash `ls` (`:30,:197`). Correctness-lens. See Recurring note.
 ---
 ## analyze.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 1 MINOR · 1 SUGGESTION)
 Class: **analytics-adjacent (read-only diagnostic; no CLI)**. Intent delivered: diagnosis + recovery plan
 from reference files + AskUserQuestion (Steps Load-Context·1-8). Cross-refs resolve
 (`subagent_type: linkedin-studio:analytics-interpreter` `:41` → agent ✓, `Task` declared `:12`;
 `/linkedin:profile` `:188` → `commands/profile.md` ✓). Degradation present (analytics delegation is
 conditional `:41` with a self-report fallback; functions with zero data). No saves/dwell claims → nothing to
 contradict. No "thought leadership".
 ### MINOR — two non-reconciling severity scales in one command (`analyze.md:155-178` vs `:227-231`)
 - **Verified by main (correctness-lens; intent-lens silent — lens gap):** Step 5 grades reach drop on four
  percentage bands (`<25` / `25-50` / `50-75` / `75%+`, `:155-178`). Step 7's timeline table (`:227-231`)
  uses three rows on a *different* axis — "Moderate (link/off-topic)", "Moderate (partial reach loss)",
  "Severe (sharp reach loss)". The two scales share no common key, so a user holding a Step 5 result (e.g.
  "Down 50-75% → algorithmic suppression likely") cannot map it to a Step 7 timeline row. Advisory/usability
  inconsistency, low-confidence; nothing breaks.
 - **disposition:** cross-label the Step 7 rows to the Step 5 bands, or state explicitly that they are
  independent axes.
 ### SUGGESTION — the `:41` existence check ("If imported analytics data exists `…/analytics/`") implies Glob/Bash, neither declared (`allowed-tools` `:9-13` = Read/AskUserQuestion/Task). Softer than report's Write gap: no explicit tool call is written at `:41` (it's a conditional prose phrase) and the real data access is delegated to `analytics-interpreter` via `Task`. Correctness-lens.
 ---
 ## audit.md — VERDICT: ALLOW (0 BLOCKER/MAJOR/MINOR · 1 SUGGESTION)
 Class: **analytics-adjacent (read-only strategy auditor; no CLI)**. Intent delivered: audit report (Step 7
 template) + action items (Step 8). Steps `0·1·2·3·4·5·5.5·6·7·8` sequential. Routing resolves
 (`/linkedin:strategy` → `commands/strategy.md` ✓, `/linkedin:profile` ✓; no `subagent_type`, `Task`
 correctly absent from `allowed-tools`). Degradation present (Step 0 checks for analytics data + asks for
 screenshots/metrics; milestone block self-skips with no data `:140`). **Correctness cross-check (both
 lenses):** the state fields the milestone block reads — `follower_count`, `monthly_growth`,
 `growth_rate_needed` (`:105,:109,:128`) — all exist in `config/state-file.template.md:23,26,28`, so it reads
 real fields. No saves/dwell claims. No "thought leadership".
 ### SUGGESTION — `allowed-tools` over-declares `Grep` (`:11`); Step 0 uses Read/Glob, no grep call in the body. Both lenses (convergence). See Recurring note.
 ---
 ## ab-test.md — VERDICT: ALLOW (0 BLOCKER/MAJOR · 1 MINOR · 2 SUGGESTION)
 Class: **analytics (experiment manager; manual metric entry, no CLI)**. Intent delivered: primary artifact
 is the test-plan markdown written to `analytics/ab-tests/[name].md` (Step 2a.8) + running comparison /
 analysis (2b/2c). Step inventory `0·1·2a(.1-.8)·2b·2c·2d·2e·3` consistent; Step 1's 6 intents map to 2a-2e +
 option 6 self-handles (`:57`). Post-count arithmetic coherent ("3 per variant / 6 total" `:127`; 6-row
 execution table `:155-162`; "X of 6" `:255`). `allowed-tools` (`:12-19`
 Read/Glob/Write/Bash/AskUserQuestion/Task) — Read/Write/Bash/AskUserQuestion/Task(→`content-optimizer` `:119`
 ✓) all invoked. Degradation present (Error Handling: No-Tests-Directory, Incomplete-Data, Missing-Analytics,
 Corrupted-files `:472-493`). Statistical honesty notably correct — 2c.4/Confidence-Level (`:311,:320-331`)
 explicitly demotes small-sample results to "directional, not significant." No saves/dwell claims. No
 "thought leadership".
 ### MINOR — manual engagement-rate formula excludes clicks, diverging from the canonical `engagementRate` (`ab-test.md:236`)
 - **Verified by main (both lenses converged):** `:236` computes ER as
  `(reactions + comments + reposts) / impressions * 100` — clicks excluded (and 2b.3 `:228-234` never
  collects clicks). The CLI's `engagementRate` includes clicks: `totalEngagement = reactions + comments +
  shares + clicks` (`csv-parser.ts:205-208`). Step 2c.3 (`:282-288`) cross-references the A/B numbers against
  the CLI weekly reports, where the two rates will not match.
 - **Severity:** internally consistent within a single test (same formula on both variants, and A/B is
  variant-relative), so the verdict-within-a-test is unaffected → MINOR, latent on the cross-reference path.
 - **disposition:** add a one-line "clicks excluded by design" caveat, or align the manual formula to the
  canonical definition. Fold into the sibling-drift reconciliation note.
 ### SUGGESTION — bare agent name in a user-facing suggestion (`ab-test.md:468`): "use the `content-optimizer` agent" surfaces a bare name where the canonical form (correctly used at `:119`) is the namespaced `subagent_type`. Cosmetic. Intent-lens.
 ### SUGGESTION — `allowed-tools` over-declares `Glob` (`:14`); scans use Bash `ls` (`:37,:209`). 2b.4/2c.5 append/update are edit-shaped but the declared `Write` covers them via full rewrite (no `Edit` gap). Correctness-lens. See Recurring note.
 ---
 ## measure.md — VERDICT: ALLOW (0 findings — clean)
 Class: **front-door router (delegate-only)**. Intent delivered **and structurally enforced** (both lenses
 converged): `allowed-tools` (`:10-13`) = `Glob` + `AskUserQuestion` only — no Bash/Read/Task — so the
 command *cannot* run analysis itself; it identifies intent (Step 1, 5 intents `:30-34`) and routes (Step 2
 table `:41-47`, one row per intent). All five routes — `/linkedin:import`, `/linkedin:report`,
 `/linkedin:analyze`, `/linkedin:audit`, `/linkedin:ab-test` — resolve to existing command files. Degradation
 present (Step 0 glob optional, "Do not block on it"; order-note `:49-50` routes to import first when nothing
 imported). No dangling branch, no analysis logic to drift, no saves/dwell claims, no "thought leadership".
 The thinnest, cleanest surface in the batch — the delegate-only contract is enforced by the tool whitelist,
 not just asserted.
 ---
 ## Gate decision — R4 COMPLETE (6 surfaces)
 | Surface | Verdict | BLOCKER | MAJOR | MINOR | SUGGESTION |
 |---|---|---|---|---|---|
 | import | ALLOW | 0 | 0 | 1 | 1 |
 | report | REWORK | 0 | 1 | 1 | 1 |
 | analyze | ALLOW | 0 | 0 | 1 | 1 |
 | audit | ALLOW | 0 | 0 | 0 | 1 |
 | ab-test | ALLOW | 0 | 0 | 1 | 2 |
 | measure | ALLOW | 0 | 0 | 0 | 0 |
 | **TOTAL** | **REWORK** | **0** | **1** | **4** | **6** |
 **Batch verdict: REWORK** — 1 of 6 surfaces (report) carries **1 MAJOR**: the heatmap report type routes to
 a nonexistent "Step 6c" (real handler Step 2c) — a provably-wrong cross-reference on a primary menu branch.
 **0 BLOCKER anywhere.** The other five are ALLOW (measure notably clean — its delegate-only contract is
 enforced by the `allowed-tools` whitelist, not merely asserted).
 **Analytics-class predicate verdict: PASS.** The saves/dwell honesty contract holds on every surface that
 touches the metric — saves framed as manual/count-only/no-API and never folded into `engagementRate`, dwell
 called unmeasurable, neither claimed as imported; `parseOptionalCount` semantics (`csv-parser.ts:71`) and the
 `getAnalyticsRoot` seam described accurately wherever quoted. Graceful degradation present on all six. This
 was the batch-specific axis and it is clean.
 **Independence verdict:** two convergences (import Step 6a flags; ab-test ER-omits-clicks) + three
 divergences resolved by main's grounding in **both directions** — intent over-rated import's Step 6a
 (MAJOR→MINOR on grounding that the executable path delegates), while correctness uniquely caught report's
 Step 6c misroute (MAJOR) and analyze's twin severity scales (MINOR) that intent's lens never traced. The
 two-lens method earned its keep again: had only the intent-lens run, report would have shipped ALLOW with a
 broken primary branch; had only the correctness-lens run, import would have over-escalated to REWORK.
 **Systemic findings now span R2a+R2b+R3+R4:** clipboard `printf` (R2a, 10 files — **R4 adds none**) ·
 component scaffold (R2b, 3 files — **R4 adds none**) · bare reference paths (R2b+R3+R4 — R4 adds 7
 lowest-impact pointer/prose sites in analyze/report, not executable). **New this batch:** (a) `allowed-tools`
 over-declaration now spans R3+R4 (~7 surfaces, SUGGESTION-class, harmless) with one true *under*-declaration
 (report Step 8b `Write`, MINOR); (b) a small **sibling interface/metric-definition drift** cluster (import's
 stale `trends` flags + ab-test's clicks-excluded ER) — reconcile once against the CLI SSOT. Cold review
 **finds**; it changes no code. Each fix is its own operator-gated decision. Recommended consolidated-fix
 order unchanged: (1) clipboard `printf` [R2a, 10 files, highest blast radius], (2) component scaffold [3
 files], (3) bare reference paths [grep-driven], then the per-surface items — now including **report Step 6c
 misroute (the one R4 MAJOR)**, report Step 8b `Write`, the sibling-drift reconciliation (import 6a +
 ab-test ER), analyze severity scales, and the over-declaration trims. Local-only (hardening-class), pushed
 per the 2026-06-30 operator delegation (public catalog, no secrets).
 **Cumulative cold-review coverage: 23/29** (review.md S1=4 · R2a=5 · R2b=4 · R3=4 · R4=6). Remaining: **R5
 (Grow+Router)** — strategy · competitive · monetize · outreach · profile · linkedin (6 surfaces) → 29/29.
--- a/docs/hardening/review-R5.md
+++ b/docs/hardening/review-R5.md
@ -1,258 +0,0 @@
 ---
 type: cold-review
 batch: R5
 journey: "Grow + Router — growth/authority surfaces + the command router (FINAL round)"
 scope: "FROZEN committed files at HEAD 4109fe7 (clean tree; post-hardening cold pass)"
 method: "2 independent cold Opus reviewers for the round (intent + correctness), each covering all 6 surfaces, no cross-feed; every mechanical claim tool-grounded (anti-fabrication mandate); reviewers carry NO drafting-session context. Divergences re-grounded by main before registration."
 surfaces: [strategy, competitive, monetize, outreach, profile, linkedin]
 reviewers:
  - "intent-lens (conformance: intent delivery + cross-ref resolution + class predicates + graceful degradation + thought-leadership terminology ban)"
  - "correctness-lens (internal consistency + bound-vs-canonical + step/phase arithmetic + allowed-tools completeness + dead-ref / executable-path checks)"
 class: "guided/stateful (strategy·competitive·monetize·outreach·profile — primary artifact produced · subagent targets resolve · graceful degradation) + routing (linkedin — every emitted /linkedin:Y resolves)"
 status: "COMPLETE — all 6 surfaces reviewed (strategy, competitive, monetize, outreach, profile, linkedin). R5 completes 29/29 cold-review coverage."
 verdict: MINOR
 counts: { BLOCKER: 0, MAJOR: 0, MINOR: 3, SUGGESTION: 2 }
 ---
 # Cold review — R5 (Grow + Router) · FINAL round → 29/29 coverage
 Independent post-hoc cold review of the 6 remaining surfaces — the five Grow-journey
 guided/stateful commands (`strategy`, `competitive`, `monetize`, `outreach`, `profile`) plus the
 `linkedin` router — on the FROZEN committed files (HEAD `4109fe7`). Mirrors the S1 `review.md` +
 R2a + R2b + R3 + R4 model (the cold-review method that did **not** fabricate): read-and-show before
 assert, every `file:line` tool-confirmed, reviewers carry no drafting-session context. The
 per-command interactive gate (`log.md`) already passed these; this pass adds the **independent**
 axis that gate never had. **R5 completes the sweep: 23/29 + 6 = 29/29 cold-review coverage.**
 **Resolution integrity — PASS across all 6 surfaces (the headline R5 result).** Both blind lenses
 independently confirmed, target-by-target against their own `ls`/`test -f`:
 - **2/2** `subagent_type: linkedin-studio:X` refs resolve — `strategy-advisor` (`strategy.md:153`),
  `network-builder` (`outreach.md:171`).
 - **28/28** unique `/linkedin:Y` route tokens resolve to `commands/Y.md` (router + cross-command
  suggestions).
 - **11/11** router-suggested agents (named in `linkedin.md`) resolve to `agents/*.md`.
 - **2/2** helper-script invocations resolve: `outreach.md`'s `state-updater.mjs --record-outreach`
  (flags `--date/--track/--partner/--stage/--next/--due` match `state-updater.mjs:394-411`
  byte-for-byte) and `linkedin.md`'s `queue-manager.mjs` import (`queueUpcoming`/`queueOverdue`/
  `queueFormatSummary` exist at `queue-manager.mjs:52,94,112`).
 - **0 under-declared tools** — every body-invoked tool (Task/Read/Write/Edit/Bash/WebSearch/
  AskUserQuestion) is in the surface's `allowed-tools`; only harmless `Glob`/`Grep` over-declarations.
 - **0 dead executable Read/Bash targets** — every `references/*`, `${CLAUDE_PLUGIN_ROOT}/skills/…`,
  and script path on an executable path verified present.
 **No broken invocation, no missing primary artifact, no failing gate, no runtime-breaking
 contradiction anywhere in R5 → 0 MAJOR, verdict MINOR (advisory, not REWORK).** This is the
 cleanest batch of the sweep.
 **Independence cross-check — both outcomes recurred (the case for two lenses, again):**
 1. **Convergence:** both blind lenses independently surfaced the same `monetize.md` description↔body
   scope mismatch and the same `thought leader` terminology cluster — high confidence these are real.
 2. **Divergence (re-grounded by main):**
   - **Terminology severity** — intent-lens called the `thought leader` hits MINOR (it owns the
     conformity predicate; memory `no-thought-leadership-phrase` makes this a *standing plugin rule*,
     not a nicety), correctness-lens called them SUGGESTION (no runtime break). **Main ruling:
     MINOR** — a direct violation of an explicit plugin terminology rule in user-facing strings is a
     conformity defect; it is not MAJOR (no runtime break).
   - **`monetize` scope mismatch severity** — intent-lens SUGGESTION ("description under-claims
     body"), correctness-lens MINOR ("description contradicts its own 0-1K Stage 1"). **Main ruling:
     MINOR** — it is a genuine self-contradiction about the command's scope, not a mere under-claim.
   - **Lens-unique:** correctness-lens alone caught the `monetize` Audience-Size scorecard
     arithmetic; intent-lens alone caught the bare-relative-path robustness gap. Both re-grounded by
     main below and kept.
 ---
 ## strategy.md — VERDICT: MINOR
 - **Intent delivered:** yes. Phase auto-detect from state (`:32-44`), phase strategy + delegation
  to `strategy-advisor` (`:153`), trajectory overlay (`:250-284`), authority building Phase 2+
  (`:286-419`), stall points (Step 4), 90-day plan (Step 5), metrics (Step 6).
 - **Resolution:** all resolve — `subagent_type: linkedin-studio:strategy-advisor` (`:153`) →
  `agents/strategy-advisor.md` ✓; routes `/linkedin:profile` (`:292,:360`) ✓; `Task` declared.
 - **Class predicate (guided/stateful):** growth-plan artifact produced ✓; subagent resolves ✓;
  graceful degradation present ✓ (`follower_count` 0/missing handled `:42`; "If no milestone data:
  Skip this step" `:284`; authority skipped in Phase 0-1 `:290`).
 - **Arithmetic (correctness-lens, grounded):** 5 phases (0–4) consistent between Step 0.5
  auto-detect ranges and Step 2 headers; step numbering monotonic (0.5,1,2,3,3.5,3.6,4,5,6), no
  gaps/dupes. PASS.
 - **allowed-tools:** declared {Read, Glob, Grep, AskUserQuestion, Task}; under-declared {} ✓;
  over {Glob, Grep} (harmless).
 - **Findings:**
  1. **[MINOR]** `strategy.md:371` "Engaging with other thought leaders" — `thought leader`
     terminology-ban hit (off-primary checklist label). Part of the cross-cutting cluster.
  2. **[MINOR]** bare relative paths for all file loads; **0×** `${CLAUDE_PLUGIN_ROOT}` (grounded
     `grep -c` = 0, vs 1–10× in competitive/monetize/outreach/linkedin) → `Read` resolves against
     cwd, not plugin root. Has `Glob` in allowed-tools as a fallback so it degrades, not fatal.
     Folds into systemic finding #3 (bare ref-paths).
 ## competitive.md — VERDICT: MINOR
 - **Intent delivered:** yes. Competitor analysis template (Step 2), landscape map (Step 3),
  gap/opportunity matrix (Step 4), differentiation plan (Step 5), inspired takeaways (Step 6),
  ethics note.
 - **Resolution:** fully self-contained — **no** `subagent_type`, **no** `/linkedin:` routes;
  `allowed-tools` (Read/Glob/WebSearch/AskUserQuestion) correctly omits `Task`. ✓
 - **Class predicate (guided/stateful):** competitive-analysis artifact produced ✓; no subagents to
  resolve ✓; graceful degradation ✓ (Step 1 user-input/WebSearch-driven, runs with no state).
 - **Arithmetic:** Steps 0–6 linear/monotonic; no stated totals to miscount. PASS.
 - **allowed-tools:** declared {Read, Glob, WebSearch, AskUserQuestion}; under {} ✓; over {Glob}.
 - **Findings:**
  1. **[MINOR]** `thought leader(s)` appears **4×** — including the frontmatter `description`
     (`:4`, **user-facing**, shows in command listings) and the opening promise (`:17`), plus
     `:31,:34`. **Worst terminology offender of the six.** Conformity defect, no runtime break.
 ## monetize.md — VERDICT: MINOR
 - **Intent delivered:** yes. All 8 steps present: scorecard (1), stage strategy (2), lead-magnet
  blueprint (3), funnel calendar (4), CTA + A/B variants (5), Featured optimization (6), revenue
  model (7), tracking dashboard (8).
 - **Resolution:** all resolve — no `subagent_type`; routes `/linkedin:post` + `/linkedin:pipeline`
  (`:367`) both exist. ✓
 - **Class predicate (guided/stateful):** monetization-plan artifact produced ✓; no subagents ✓;
  graceful degradation ✓ ("Stage 1: Visibility (0-1K followers)" `:92` serves brand-new users).
 - **Gating honesty:** does NOT hard-gate; serves 0-1K. The real state-read gate is the router's
  soft prepend (`linkedin.md:175`, `<1000` → prepend, continue anyway) — consistent with outreach.
 - **Findings:**
  1. **[MINOR]** **description↔body scope self-contradiction** — `monetize.md:6` "Works from 1K+
     followers" contradicts its own Stage 1 "Visibility (**0-1K** followers, score 0-30)" (`:92`,
     `:81`) and the router's "they work at any follower count" (`linkedin.md:126`). The body
     genuinely covers sub-1K; the description misstates scope. Off-primary (a frontmatter string)
     but user-facing. **Strongest non-terminology R5 finding.** Fix: align `:6` to "any follower
     count (compounds at 1K+)".
  2. **[MINOR]** `thought leaders` in the frontmatter `description` (`:4`, user-facing). Part of the
     cross-cutting cluster.
  3. **[SUGGESTION]** Audience-Size scorecard arithmetic (`:51-56`): sub-items +5/+10/+15/+5/+5 sum
     to **+40** against a **`/25`** cap if read additively, whereas the other three categories each
     sum to exactly 25 (e.g. Engagement Quality 5+5+10+3+2=25). The follower tiers (1K/5K/10K) are
     clearly intended mutually-exclusive (one tier) but aren't marked as such → a literal additive
     read overflows. AI-interpreted (not machine-summed) so intent is recoverable; cosmetic, but it
     feeds the band that selects the stage. Fix: mark the three follower tiers "(pick one)".
 ## outreach.md — VERDICT: PASS
 - **Intent delivered:** yes, thoroughly. Two-track (collab + speaking) orchestrator with a
  Capability Checklist mapping every predecessor function to a step (`:31-62`) + 10 steps + state
  persistence.
 - **Resolution:** all resolve — `subagent_type: linkedin-studio:network-builder` (`:171`) ✓;
  routes `/linkedin:strategy` (`:112`), `/linkedin:firsthour`+`/linkedin:outreach` (`:1078`),
  `/linkedin:calendar` (`:1097`) all exist ✓; **Bash executable path sound** — Step 8c's
  `state-updater.mjs --record-outreach` (`:1084-1092`) matches the script's handler
  (`state-updater.mjs:294,:394-411`) byte-for-byte. ✓
 - **Class predicate (guided/stateful):** outreach-plan + persisted pipeline produced ✓; subagent +
  script resolve ✓; graceful degradation ✓ (Step 2a "Not ready: <3 met → build foundation first" +
  recommend `/linkedin:strategy` `:112`).
 - **Arithmetic (correctness-lens, grounded):** "12 collab formats" → 12 (`FORMAT 1–12`); "4 talk
  templates" → A–D; "5 phases" → PHASE 1–5; scorecards 4×/25=/100 and 5×/5=/25 check out; step
  numbering monotonic. PASS.
 - **allowed-tools:** declared {Read, Glob, WebSearch, AskUserQuestion, Task, Bash}; under {} ✓;
  over {Glob}.
 - **Gating honesty:** "1K+ followers" self-report (`:100,:143`) consistent with router's `~1K` soft
  gate (`linkedin.md:120,:176`) and monetize's 1K. ✓
 - **Findings:**
  1. **[SUGGESTION]** `thought leader` inside a WebSearch query template (`:229`,
     `"[your niche] linkedin thought leader"`). It is a *search string* targeting how others
     self-label (intentional — to find such profiles), so the **lowest-priority** instance of the
     terminology cluster — but the literal string is still in the plugin.
 ## profile.md — VERDICT: PASS
 - **Intent delivered:** yes. Relevance-model context (`:20-44`), Profile SEO + per-section keyword
  targets (`:46-79`), 7-section audit walkthrough (`:82-199`), profile-content alignment check
  (`:200-212`), prioritized action plan (`:214-231`), alignment test (`:232-238`).
 - **Resolution:** self-contained — no `subagent_type`, no `/linkedin:` routes; `allowed-tools`
  Read/AskUserQuestion (tightest frontmatter of the six). ✓
 - **Class predicate (guided/stateful + topic-relevance-audit):** the topic-relevance audit **is**
  actually performed (the body *is* that audit) ✓; artifact (audit + action plan) produced ✓;
  graceful degradation ✓ (every step AskUserQuestion-driven, runs with zero state). Notable
  verification discipline: explicitly refuses to fabricate a scoring breakdown (`:28,:32-36,:179`).
 - **Arithmetic:** Sections 1–7 monotonic; profile-field limits (headline 220, About 2,600) are
  LinkedIn field limits, NOT post hook/length bounds — no canonical contradiction. PASS.
 - **Terminology — IMPORTANT NON-VIOLATION:** the two `thought leader` hits (`:79,:101`) are
  **legitimate negative examples** — the command explicitly tells the user to AVOID the phrase
  (`:79` lists it with "guru"/"ninja" as keyword-wasters; `:101` is a "Weak example"). Both lenses
  agree; main confirmed by reading both lines. **profile.md models the correct behavior.**
 - **Findings:** none of defect class.
  1. **[Note — systemic #3]** bare relative paths; **0×** `${CLAUDE_PLUGIN_ROOT}` and no `Glob`
     fallback → most-exposed instance of the bare-path robustness item. BUT correctness-lens
     verified all three referenced files exist (`test -f` OK), so this is a cwd-robustness concern,
     not a dead ref. Folds into systemic #3; profile.md is otherwise the cleanest surface of R5.
 ## linkedin.md (router) — VERDICT: MINOR
 - **Intent delivered:** yes. Status line (`:19-29`), upcoming/overdue posts via queue (`:31-57`),
  five-journey menu with front-doors (`:59-127`), gating rule (`:122-127`), interactive menu
  (`:129-146`), direct-routing table (`:156-198`).
 - **Resolution (routing class):** **all 28 unique route tokens resolve** to `commands/*.md`
  (verified token-by-token vs `ls commands/`); all 11 suggested agents resolve; `queue-manager.mjs`
  node call (`:35-42`) uses exports that all exist (`:52,:94,:112`). **The router advertises nothing
  that doesn't exist.** ✓ Correctly has no `Task` (delegate-only).
 - **Class predicate (routing):** every route resolves ✓; graceful degradation ✓ (missing state
  "No LinkedIn state tracked yet" `:28`; empty queue `:57`; follower segment only if
  `follower_count > 0` `:30`).
 - **Gating honesty/consistency:** `:175-176` give monetize + outreach the **same** soft state-read
  gate (`<1000` → prepend, continue anyway); `:122-127` document the soft-gate design honestly
  ("they work at any follower count… competitive is **not** gated"). Consistent with both command
  bodies. ✓
 - **Findings:**
  1. **[MINOR]** `linkedin.md:118` "Competitive analysis of other thought leaders" — `thought
     leader` terminology-ban hit in the **user-facing** routing-menu table. Part of the cluster.
 ---
 ## Summary table
 | Surface | Verdict | MAJOR | MINOR | SUGGESTION |
 |---|---|---|---|---|
 | strategy.md | MINOR | 0 | 2 | 0 |
 | competitive.md | MINOR | 0 | 1 | 0 |
 | monetize.md | MINOR | 0 | 2 | 1 |
 | outreach.md | PASS | 0 | 0 | 1 |
 | profile.md | PASS | 0 | 0 | 0 (1 systemic-#3 note) |
 | linkedin.md | MINOR | 0 | 1 | 0 |
 | **R5 total** | **MINOR** | **0** | **3 distinct** | **2 distinct** |
 (Per-surface MINOR counts include shared cross-cutting findings; the 3 *distinct* R5 MINOR findings
 are: the terminology cluster, the monetize scope contradiction, and the bare-path robustness item.)
 ## Cross-cutting findings (for the consolidated fix-pass)
 1. **[MINOR · NEW R5 systemic] `thought leader` terminology cluster — 5 surfaces, 9 instances.**
   competitive `:4`(description, user-facing)/`:17`/`:31`/`:34` · monetize `:4`(description,
   user-facing) · linkedin `:118`(menu, user-facing) · strategy `:371`(checklist) · outreach
   `:229`(WebSearch string, lowest priority). **profile `:79,:101` are NON-violations** (correct
   negative examples — do not "fix" them). Memory `no-thought-leadership-phrase` confirms this is a
   standing plugin terminology rule. **Recommended fix:** one terminology sweep replacing the
   user-facing instances first ("thought leaders" → "creators"/"experts"/"voices in your niche"),
   leaving profile's avoid-list intact and the outreach search-string as lowest priority. No runtime
   risk — the buzzword gate scopes to post content, not command markdown.
 2. **[MINOR · per-flate] `monetize.md:6` description↔body scope self-contradiction.** "Works from
   1K+ followers" vs the body's own 0-1K Stage 1 (`:92`) and the router's "any follower count"
   (`linkedin.md:126`). Fix: align the description to the body's actual sub-1K-onward range.
 3. **[MINOR · folds into existing systemic #3] bare ref-paths — strategy + profile (0×
   `${CLAUDE_PLUGIN_ROOT}`).** profile most exposed (no `Glob` fallback). Refs verified to exist, so
   cwd-robustness not a dead ref. Reconcile in the repo-wide path-style pass already scoped by
   systemic #3 (R3/R4 found the same pattern in batch/pipeline/firsthour/analyze/report).
 4. **[SUGGESTION · per-flate] `monetize.md:51-56` Audience-Size scorecard sums to +40 vs `/25`
   cap.** Follower tiers intended mutually-exclusive but unmarked. Fix: annotate "(pick one)".
 **R5 adds NO new ★ systemic finding to the existing three** (clipboard, scaffold-band, bare-paths) —
 the only genuinely new cross-cutting item is the terminology cluster, which is a conformity sweep,
 not a code-behavior defect.
 ## Verification
 - Spot-checks re-grounded by main (this file): `grep -rniE 'thought.?leader'` over the 6 (9 hits,
  classifications above); `sed -n '1,8p'`/`'92p'`/`'48,64p' monetize.md` (scope + scorecard);
  `grep -c CLAUDE_PLUGIN_ROOT` per surface (strategy 0, competitive 4, monetize 10, outreach 10,
  profile 0, linkedin 1).
 - `bash scripts/test-runner.sh` → see STATE telling (expected 138 passed / 0 failed, floor 123) —
  unchanged by this review (review is read-only; no command edits).
 ## Sweep status after R5
 **29/29 cold-review coverage reached** (S1 `review.md` + R2a + R2b + R3 + R4 + R5). The independent
 cold-review phase is COMPLETE; the v1.0.0 review blocker is lifted. Remaining v1.0.0 work: the
 consolidated fix-pass (operator-gated — review FINDS, fix is a separate decision) and the GUI.
--- a/docs/ingestion-guard/plan.md
+++ b/docs/ingestion-guard/plan.md
@ -1,209 +0,0 @@
 # Ingestion-guard integration plan — when & where to wire `llm-ingestion-guard`
 > **Status: `planned` (2026-07-16).** Plan only — nothing wired yet, per the adoption brief's
 > "don't implement now" instruction. This document is the repo's durable answer to *when* and *where* a
 > write-time ingestion guard earns its place at our persist gates.
 >
 > **Guard:** `llm-ingestion-guard` `v0.2` (alpha, public API may change). Write-time sibling of query-time
 > chatbot guardrails; hardens *untrusted content flowing through an LLM step into a persisted,
 > downstream-read store*. Python, stdlib-only core, 3.10+.
 >
 > **Adoption brief (authoritative, self-contained):**
 > `https://git.fromaitochitta.com/open/llm-ingestion-pipeline-security/raw/branch/main/docs/ADOPTION-BRIEF.md`
 > (§7 planning checklist, §3 the 8-step contract, §4 the OKF adapter, §8 honest limitations).
 >
 > Grounded against `882f6ee` by two independent read-only surveys (ingest surface + persist seams),
 > 2026-07-16. Every seam below carries a `file:line` anchor.
 ## 1. Decision
 **Status = `planned`.** The plugin has live untrusted-ingest paths (a react-to-URL command, an auto-fetching
 trend agent, an external-research newsletter fan-out), and it persists their output into stores a downstream
 agent later reads as trusted context. That satisfies the brief's §7 decisive condition. Nothing is wired.
 The guard is registered here as a **dependency to add before the first *automated* external-origin ingest
 path goes fully live** — and one such path (trends → session re-injection, §5.1) is arguably already live,
 so it is the first integration candidate, not a distant one.
 We do **not** implement now. The brief is explicit ("kun planlegg og oppdater planene"), and wiring is gated
 on an unresolved interop decision (§7).
 ## 2. What the guard is (and is not) for us
 It is **not** a query-time guardrail between the user and the model. It is a **write gate**: the last place
 the provenance of a piece of content is still known before it is committed to a store that a *later* agent
 reads as trusted. For this plugin that store is the second-brain (`brain/profile.md`, `ingest/published/`),
 the trends store, the specifics-bank, the post queue, and the state file's `## Recent Posts` — all of which
 are re-surfaced into future model context. A poisoned concept committed at write time is read back later with
 its origin forgotten; the write gate is the only place to catch it.
 ## 3. Ingest-surface analysis (untrusted vs first-party)
 Scored against the brief's §7 checklist. "Downstream trusted reader" = a command/agent/hook that later reads
 the store **as context**, which is what turns a write into a poisoning surface.
 | # | Path | Origin | Untrusted? | Persist target | Downstream trusted reader | Live? |
 |---|------|--------|-----------|----------------|---------------------------|-------|
 | 1 | **trend-spotter agent** (`agents/trend-spotter.md`) → trends CLI `capture` (`scripts/trends/src/cli.ts:294`) | Auto-fetched web/vendor/regulator content (WebSearch/WebFetch + research MCPs) | **YES — external** | `trends/trends.json` — `source`/`title`/`url`/`summary` stored **verbatim** (`scripts/trends/src/item.ts:24-48`) | **`session-start.mjs:38-78` auto-reinjects into the next session's context — no human in the loop** | **LIVE** |
 | 2 | **`brain ingest` / `scanInbox`** (`scripts/brain/src/ingest.ts:172-192,:247`) | User's own published posts, dropped into `ingest/inbox/` (manual) | Origin first-party today; **untrusted-*capable*** (drop-zone accepts any file; SB-S4 connector would automate it) | `ingest/published/<id>.md` | `voice-trainer` gold source (`agents/voice-trainer.md:136,144`); `brain consolidate` → `brain/profile.md`; `assemble`/`reconcile` | LIVE (manual) |
 | 3 | **`/linkedin:newsletter`** research fan-out (`commands/newsletter.md:461-475`) | Open-web research agents (WebSearch/WebFetch) | **YES — external** | specifics-bank `ekstern` bindings (`scripts/specifics-bank/src/kilder.ts:51-52`) + `NN-kilder.md` + `queue.json` | Edition prose + sources ledger; queue readers | LIVE |
 | 4 | **`/linkedin:react`, `:post`, `:pipeline`, `:batch`** URL ingest (`commands/react.md:52`, `post.md:62`, `pipeline.md:13`, `batch.md:12`) | External URL (news, blog, YouTube, social threads) via WebFetch | **YES — external** | react/post: clipboard + state `## Recent Posts` **metadata only** (raw content not persisted); pipeline/batch: draft files + `queue.json` | state `## Recent Posts` re-injected (`user-prompt-context.mjs:109-117`, `session-start.mjs:341`); queue readers | LIVE |
 | 5 | **`/linkedin:import`** CSV (`scripts/analytics/src/parsers/csv-parser.ts`) | User's own LinkedIn analytics CSV export | First-party origin; **container-layer** parse surface | `analytics/posts/*.json` (`storage.ts:143-160`) | `report`/`audit`/`analyze`, `analytics-interpreter`, `brain assemble` | LIVE |
 | 6 | **`/linkedin:competitive`, `:outreach`** (`commands/competitive.md:33`, `outreach.md:223`) | WebSearch of competitor/partner/event content | YES — external | **Nothing durable** (inline report only) | — (no persist) | LIVE |
 | 7 | Received **third-party OKF bundle** | External bundle | YES — external | *does not exist* | — | **FUTURE / not built** |
 | 8 | `setup`, `onboarding`, `first-post`, `quick`, `specifics-bank`, voice-samples | User's own typed/pasted content | No — first-party | state file / voice-samples / specifics-bank | content commands | LIVE |
 ## 4. Where the guard applies — and where it deliberately does not
 **Applies (wire here):** the untrusted boundaries — rows 1–5. Trust follows the data's *origin*, not the
 insertion channel (brief §7): a manual paste of an external article (`/linkedin:react`) is still external.
 **Does not apply (out of scope by design):**
 - **First-party authoring** (row 8): onboarding, `setup`, typed post ideas, `specifics-bank` (human-only),
  voice-samples, the user's own profile edits. The guard's threat model does not target trusted-author
  in-place edits.
 - **Fetch-but-no-persist** (row 6): `competitive`/`outreach` fetch external content but write nothing
  durable — there is no downstream-trusted store to poison, so the *write-time* guard has no seam. (Their
  risk is query-time, a different tool's job.)
 - **Row 2 today** is first-party by origin (the user's own posts). It becomes an untrusted boundary the
  moment SB-S4 (the EU/EEA DMA connector) or any received-bundle path automates the inbox — see §9.
 ## 5. Integration points (persist gates) + minimal wiring
 **Key structural finding:** every external fetch in this plugin goes through the *model's* WebFetch/WebSearch/
 MCP tools — there is **no raw-HTTP `your_model()` seam in plugin code**. The fetch → transform → persist
 pipeline is: *model tool call → agent reasoning → deterministic CLI write*. So the guard's classic two-bookend
 model (`prepare_input` → `your_model` → `screen_output`) only **half-maps**: `screen_output`
 (scan-before-persist) wires in cleanly at the deterministic CLI write points; `prepare_input` (sanitize+fence
 before the model) has no clean code seam because the fetch and transform happen *inside the model's turn*
 (§6).
 **Coverage gap to know:** `hooks/scripts/content-gatekeeper.mjs` is the only `PreToolUse(Write|Edit)`
 choke-point, but it inspects the file **path, never the content bytes**, and only fires for the **Write/Edit
 tool** on drafts/assets paths. The four durable trusted-context stores below are all written via
 **Bash-invoked `node`/`tsx`**, so they **bypass the gate entirely**. A byte-level guard must wire at the CLI
 write points, not solely at `content-gatekeeper`.
 Ranked by automated-reinjection risk (highest first):
 ### 5.1 trends `capture` — the one live automated poison→reinject loop *(priority 1)*
 - **Seam:** before `store.ts` persists to `trends/trends.json`, in `scripts/trends/src/cli.ts` `capture`.
 - **Wiring:** `screen_output(item.title + "\n" + item.summary, PRESET_USER_UPLOAD)`; on
  `Disposition.FAIL_SECURE`, route the item into the CLI's existing `errors[]` channel
  (`cli.ts:294-320`) instead of persisting — a drop, not a crash.
 - **Why first:** external content, stored verbatim, auto-surfaced back into future model context by
  `session-start.mjs` with no human gate. This is the sharpest write→trusted-read loop in the plugin.
 ### 5.2 brain `ingest` / `scanInbox` — the voice/profile gold seam *(priority 2)*
 - **Seam:** `writePublished(rec)` in `scripts/brain/src/ingest.ts:172-192`; especially the `scanInbox`
  (`:247`) path that reads user-dropped `ingest/inbox/*.md`.
 - **Wiring:** `screen_output(body, ...)` before write; `FAIL_SECURE` → do not promote to
  `ingest/published/`, log to a rejects sidecar. Once a bundle-shaped receive lands, switch to
  `okf.import_bundle` (§8).
 - **Why:** `ingest/published/` is the ranked-#1 gold source for `voice-trainer` and feeds `profile.md` via
  consolidation — the highest-trust downstream read in the plugin. Note the existing `provenance=published`
  guard here is an **anti-model-collapse** control (authorship axis), **not** an anti-injection control
  (origin axis) — the two are orthogonal; this seam has the former, not the latter.
 ### 5.3 newsletter research → specifics-bank `ekstern` bindings *(priority 3)*
 - **Seam:** before an external research finding persists as an `ekstern` binding
  (`scripts/specifics-bank/src/kilder.ts:51-52`).
 - **Wiring:** `screen_output` on the claim text + source; `FAIL_SECURE` → quarantine, surface to the operator
  in the fact-check sweep the newsletter pipeline already runs.
 ### 5.4 analytics CSV import — the container-layer gate *(priority 4)*
 - **Seam:** `saveBatch` in `scripts/analytics/src/utils/storage.ts:143-160` (or in `parseLinkedInCSV`).
 - **Wiring:** row-content scan (CSV formula-injection `= + - @`, active-content) complementing the existing
  **filename-only** sanitization (`sanitizeDate/Id/Week/Month` + `verifyPathWithinDirectory`,
  `storage.ts:110-137`). Lower priority: origin is first-party and the JSON is never re-emitted to a
  spreadsheet, so the practical blast radius is small — but there is currently **no** row-content
  sanitization layer, so it is a real (if narrow) gap.
 ## 6. The `prepare_input` caveat (honest scope of what we can wire)
 The input-side bookend (`sanitize` + fence before the model, contract steps 1–2) has **no clean code seam**
 here: the untrusted content is fetched by the model's WebFetch tool and transformed by the drafting agent
 *within the same model turn*, so plugin code never holds the raw input to wrap. Partial mitigations exist —
 a sanitize pass on fetched text inside the URL commands' prompts, or reading `tool_input.content` in
 `content-gatekeeper` for the Write-tool draft path — but neither is the clean `prepare_input(untrusted)`
 call the library assumes. What we **can** wire cleanly and fully is `screen_output` at the persist gates (§5).
 Partly, the contract's *real* security already holds structurally: the drafting agents largely reason over
 fetched text (close to "tool-less transform"), and the persist step is a deterministic CLI ("output as data,
 parsed to a schema"). The lexicon/entropy scan is defense-in-depth on top of that, not the wall.
 ## 7. Python ↔ Node interop — the real integration cost
 The guard is **Python** (stdlib, 3.10+). This plugin's runtime is **Node ESM `.mjs` hooks (deliberately
 zero-npm-dep) + TypeScript engine via `tsx`**. The only Python in the repo is one **build-time** script
 (`hooks/scripts/compile-hooks.py`), never on a data path. So wiring the guard means crossing a subprocess
 boundary. Options:
 | Option | Shape | Trade-off |
 |--------|-------|-----------|
 | **(a) `spawnSync('python3', …)` at the engine CLI write points** *(recommended)* | The `scripts/{trends,brain,specifics-bank,analytics}` CLIs (already `tsx`, not the zero-dep hook hot path) shell out to a `python -m llm_ingestion_guard` scan | Adds a `python3` + `pip install llm-ingestion-guard` runtime dependency to the *engine layer only*; keeps the zero-dep Node **hooks** untouched. Cleanest fit. |
 | (b) Port minimal `sanitize` + `scan_output` to a `.mjs` twin | Reimplement in Node | Defeats the point of adopting a *maintained* guard; the coverage matrix (126/126) would not apply to the port. Rejected unless a hard no-Python constraint appears. |
 | (c) Bash step inside the command, not the hook | Command invokes the scan before the CLI write | Non-deterministic (depends on the agent running the step); weaker than a code-enforced gate. |
 **Blocker to resolve first:** whether a `python3` + one-package runtime dependency is acceptable given the
 plugin's zero-dep design value. This is the gate on any wiring work.
 ## 8. OKF `import_bundle` — future / conditional
 The plugin is **export-only** toward OKF: its brain *emits* OKF-compatible form (`type:` + per-level
 `index.md` + root `okf_version`, landed 2026-06-26, `docs/okf-convergence-brief.md`). There is **no
 `import_bundle` and no third-party-bundle receive path** anywhere in the repo, and inbox auto-classify/convert
 is explicitly deferred (brief §11). So the guard's `okf.import_bundle(bundle, origin=EXTERNAL,
 channel=AUTOMATIC)` adapter has **no seam today**.
 It becomes relevant if/when either lands: **(i)** SB-S4 — the EU/EEA DMA portability connector auto-feeding
 `ingest/inbox/`; or **(ii)** a cross-plugin shared retrieval skill (a *separate standalone plugin*, per the
 convergence brief §8) that merges *other* plugins' brains. At that point, wire `okf.import_bundle` at
 `scanInbox` with `allow_reserved` chosen per channel (received bundle → `True`; materialised individual
 uploads → `False`, per brief §4).
 ## 9. When — roadmap triggers
 1. **Now:** `planned`. No wiring. (This doc + the STATE.md marker.)
 2. **First wiring candidate — trends `screen_output` (§5.1):** the trends→session-reinjection loop is already
   live, so per the brief's "include it before the first untrusted ingest path goes live," this is the
   earliest concrete target once §7 is resolved.
 3. **Hard trigger (not optional) — before SB-S4 or any received-bundle path:** the EU/EEA DMA connector, or a
   cross-plugin shared skill, turns `ingest/inbox/` from "user's own manual paste" into an automated
   external-origin ingress. Wire §5.2 (and §8's `import_bundle`) **before** that path goes live — this is the
   brief's "when, not if" moment.
 4. **Opportunistic:** §5.3 (newsletter) and §5.4 (CSV container-layer) can ride whichever hardening session
   touches those CLIs.
 Sequencing note: none of this is on the current `docs/plan-2026-07/` roadmap (N1–N32). It is a new,
 security-scoped work item to slot in after §7 is decided — most naturally as its own hardening slice, not by
 displacing the agreed N-plan.
 ## 10. Honest limitations (carried from brief §8 — a green scan is not "safe")
 - **Semantic / factual poisoning is invisible** to lexicon + entropy — a plausible-but-wrong concept (wrong
  metric, wrong runbook step) carries no suspicious token and passes clean. **Highest impact for a
  second-brain.** Our existing anti-sycophancy / evidence-threshold / keep-both-timestamped stance in the
  consolidation loop is the human-in-the-loop mitigation; the deterministic guard does not judge semantics.
 - **Dormant / broken-link injection:** a link to a not-yet-existing target passes a write-time scan; payload
  planted later. Relevant to the brain's cross-links.
 - **A document that *describes* attacks is a false positive** — security notes documenting injection payloads
  trip carrier-strip. Matters if the plugin ever ingests security content.
 - **Text-only, extracted-text-only** — no file parsing in the core; extract text first, scan with high-untrust
  upload provenance.
 ## 11. Existing write-time precedents the guard complements (not replaces)
 The plugin already has three narrow write-gate defenses; the guard generalizes the class rather than
 duplicating them:
 - **`state-updater.mjs`** uses a replacement *function* (not string) on every section-append to neutralize
  `$&`/`` $` ``/`$'`/`$$`/`$n` from `$`-bearing user topics (`:14-25,:117-125`) — defends the regex mechanics,
  not content semantics.
 - **`analytics/storage.ts`** sanitizes filenames + `verifyPathWithinDirectory` (`:110-137`) — path-traversal
  defense, not row content.
 - **brain `provenance=published`** — model-collapse guard (authorship), orthogonal to injection (origin).
 ## 12. Out of scope for this plan
 No guard code, no `pip install`, no CLI wiring, no hook changes. This is the *when/where* map and the
 dependency registration only, per the adoption brief. Implementation is a separate, operator-approved work
 item gated on §7.
--- a/docs/integration-test-guide.md
+++ b/docs/integration-test-guide.md
@ -20,7 +20,7 @@ Before testing, ensure:
 1. Run `/linkedin:pipeline`
 2. Verify Step 0 loads: state file read, status displayed (posts/week, streak)
 3. Choose "Generate ideas for me" when prompted
-4. Verify 3 topic suggestions appear, drawn from `content-angles.md`
+4. Verify 3 topic suggestions appear, drawn from `thought-leadership-angles.md`
 5. Select a topic → verify angle selection (2-3 options)
 6. Choose format → verify draft follows structure (hook/context/insight/implication/CTA)
 7. Verify optimization checks run:
--- a/docs/m0/log.md
+++ b/docs/m0/log.md
@ -1,162 +0,0 @@
 # M0 — Implementation Log
 Running record of decisions, deviations, and out-of-scope follow-ups discovered
 during M0 execution. Plan: `docs/m0/plan.md` (18 steps). History → git; this file
 captures only what the commit messages cannot.
 ## Session 4 — Steps 14–18 (2026-06-18)
 ### Step 14 GATE outcome — the D3 convention works; edit count is ~1:1, not reduced
 Prototyped `references/data-path-convention.md` on the voice-readers family:
 **38 refs across 19 files repointed** — exactly the plan's prediction. The measured
 answer to brief D3's open question (*can a convention reduce edits, or do commands
 need literal paths for Claude to act on?*): command/agent prose that tells Claude to
 **read** a file needs a resolvable path **on the line**. A "the data dir's
 `voice-samples/` (see convention doc)" reference adds a lookup hop and is not directly
 actionable. The inline `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/…`
 token is both self-resolving **and** points at the doc. So the convention does **not**
 cut edit count below ~1 per ref — it makes every edit a **uniform mechanical token
 swap** (vs bespoke per-line decisions), with the doc as single source of truth.
 **GATE = proceed** (convention confirmed working); Step 15 applies the same uniform
 token to the remaining families. This is D3 realized as one token — NOT a re-decision
 to literal-edit (alt. a). Applied via an ordered swap (prefixed `${CLAUDE_PLUGIN_ROOT}/
 assets/voice-samples/` form before bare `assets/voice-samples/`, so the bare pass can't
 corrupt the prefixed one).
 ### Designed inter-step red lint (Step 14 → Step 16)
 After Step 14 the structure lint is **Failed: 1** — `references/*.md: 26 (expected 25)`,
 the new convention doc as the 26th ref file. `EXPECT_REFS` bumps to 26 in **Step 16**
 (plan Session-4 scope forbids touching tests). This session lands 14→18 in one go, so
 the lint is restored to green at Step 16 — no red is left at session end. The only
 surviving bare `assets/voice-samples/` is inside the convention doc itself (it documents
 the in-plugin placeholder-scaffold location for the fallback rule) — Step 16's
 no-bare-path assertion must exempt `references/data-path-convention.md`.
 ### Step 15 — 130 refs / 34 files repointed; shipped read-only preserved
 Rule-based repoint (negative-lookahead per subdir): analytics 50, drafts 24,
 audience-insights 14, profile/D1 12, examples 11, plans 6, my-post-templates 4,
 frameworks 3, case-studies 3, network 2, repurposing-tracker 1. Counts match the
 plan's family estimates once the **shipped exclusions** are accounted for
 (frameworks 6→3 drops `framework-template.md`; case-studies 5→3 drops
 `case-study-template.md`; analytics drops `README.md`; the Step-11 `ANALYTICS_ROOT`
 pins were already gone). **Style-A `${CLAUDE_PLUGIN_ROOT}` preserved** for shipped
 read-only: `analytics/README.md`, all `*-template.md` seeds, `assets/checklists/`,
 `assets/quick-post-resources.md`, the shipped `assets/templates/*` (only the
 `my-post-templates.md` *instance* repointed), `config/*.template.*`, and every
 `scripts/analytics` / `hooks/scripts` CODE path. **profile/D1:** `config/user-profile.local.md`
 → `${…}/profile/user-profile.md` (path + filename change, drops `.local`, per
 MOVE_FILES). **ab-tests/** routes under `${…}/analytics/ab-tests/` (brief §7.1);
 **plans/** at `${…}/plans/` (top-level). Verify: the only in-plugin data-dir paths
 left are the three shipped exclusions; full lint Failed:1 = EXPECT_REFS only.
 ### Step 15 scope notes — two additions, one deferral
 - **network/ + repurposing-tracker.md repointed (additions beyond the plan's named
  families).** Both are **code-invisible data classes** the agents *write*
  (`network-builder.md`, `content-repurposer.md` save trackers into the plugin tree).
  They fit Step 15's stated goal ("route the code-invisible data classes so they don't
  silently orphan when the default flips"); the plan named ab-tests/plans as examples,
  not an exhaustive list. As **write-targets** they are self-sufficient — the agent
  creates the file external on first write, no migration entry needed.
 - **`config/personas.local.md` deferred — OUT of M0 scope.** Unlike the write-targets,
  this is a **read fallback** in a resolution chain (edition-state → series file →
  plugin `personas.local.md` → template). Repointing the read external without a
  migration dest would break the read, and adding it to `MOVE_FILES` is a `.mjs` change
  Step 15's scope fence forbids. Personas are newsletter/series production data (already
  external via `$LTL_SERIES_ROOT`); the plugin-level `personas.local.md` is a deliberate
  in-plugin fallback library. Left as-is; Step 16's no-bare-path lint targets the
  *migrated* data classes only, so it does not flag personas. Track as a follow-up if a
  full personas externalization is wanted later.
 ### Step 16 — lint extended 74→81 checks; the no-pin guard caught 5 real survivors
 Added to `test-runner.sh`: `EXPECT_REFS` 25→26 + "delta = exactly +1 (data-path-convention.md)"
 assert (m3/m11); **Section 13** (no command/agent/skill/hook prose references a migrated
 user-data path in-plugin — bare or `${CLAUDE_PLUGIN_ROOT}`-pinned — R1; + the no-`ANALYTICS_ROOT`-
 pin sibling M3; + the SC2 `git status --porcelain --ignored` dry-run), each with a
 non-vacuity self-test mirroring Section 8; **Section 14** assertion-count anti-erosion
 floor (pre-M0 baseline 74, count may only grow — SC6 / assumption 3).
 **The no-pin guard earned its keep on first run:** it flagged **5 surviving in-plugin
 `ANALYTICS_ROOT="${CLAUDE_PLUGIN_ROOT}/assets/analytics"` pins** that Step 11 missed —
 `agents/analytics-interpreter.md` (×2) + `skills/linkedin-analytics/SKILL.md` (×3). Step 11
 scoped the pin-drop to the *commands* (`import.md`/`report.md`); the agent + skill invoke the
 CLI directly and kept the pin, which would force the analytics CLI to read in-plugin even
 after the default flipped external (the exact M3 failure). Dropped all 5 (surgical: removed
 only the `ANALYTICS_ROOT=… ` prefix, kept the `node --import tsx` form — no CLI-style change),
 matching how Step 11 left the commands. Lint now **81/0**.
 ### Step 18 — release 0.4.0 → 0.5.0 (minor, non-breaking)
 Bumped `.claude-plugin/plugin.json` + the three lint-grepped literals (README
 `version-0.5.0-blue` badge, CLAUDE.md `(v0.5.0)` header, CHANGELOG `## [0.5.0]`).
 Also synced the README `reference_docs-25→26` badge (not lint-checked, but stale after
 the convention doc) and refreshed the now-false "user data still lives inside the plugin"
 prose in README + CLAUDE.md to "M0 done — data external." Version-consistency lint green;
 the only remaining `0.4.0` refs are CHANGELOG history + the `docs/m0/` planning docs that
 describe the `0.4.0 → 0.5.0` transition itself (correct, not stale declarations).
 **Plan deviation — root marketplace docs NOT touched (scope).** Plan Step 18 listed
 `/Users/ktg/.claude/plugins/marketplaces/ktg-plugin-marketplace/{README,CLAUDE}.md` as
 "root docs." Skipped: that path is the **installed** marketplace artifact, **outside this
 polyrepo**, and STATE.md scope is "KUN denne pluginnen" (+ global "don't write in other
 repos"). The binding gate (the lint) checks only this plugin's four declarations, all
 green. **Follow-up (separate catalog repo task):** reflect linkedin-studio v0.5.0 in the
 marketplace catalog README if/when desired — operator's call, not this plugin's M0.
 ## Session 3 — Steps 11–13 (2026-06-18)
 ### Environment reality vs. plan assumptions
 The plan was authored assuming the operator's **real `.local.md` runtime data**
 sat in the plugin tree (227-line voice profile, analytics exports, draft queue).
 On this machine that data is **absent** — it is a clean clone:
 - `assets/voice-samples/`: only the PII-free placeholder `authentic-voice-samples.md`
  (+ `.template.md`). No `.local.md` source.
 - `assets/drafts/`: only `.gitkeep`. `assets/analytics/`: only `README.md` + empty `ab-tests/`.
 - The 4 tracked D2 scaffold instances DO exist (`high-engagement-posts.md`,
  `demographics.md`, `engagement-patterns.md`, `my-post-templates.md`).
 **Consequence for Step 12 (live migration):** every `MOVE_FILES` / `MOVE_DIRS`
 entry resolved to an absent source → clean no-op. Only the 4 `COPY_FILES`
 scaffolds were relocated. Result: `migrated — moved 0, copied 4, skipped 0`;
 `.migrated` marker written; idempotent re-run confirmed `already-migrated`.
 **Step 12 verify adapted:** the plan's literal check
 (`test -f .../voice-samples/authentic-voice-samples.md`) cannot pass without a
 `.local.md` source to move, so it was replaced with the achievable post-condition:
 `.migrated` marker present + 4 scaffolds external + `migrateData` wired into
 `session-start.mjs` + idempotency. The voice MOVE correctly no-op'd. (Operator
 pre-approved this adaptation before the run.)
 ### OUT OF M0 SCOPE — git-history scrub of the leaked post (FOLLOW-UP)
 `assets/examples/high-engagement-posts.md` held the operator's **real** LinkedIn
 post at HEAD (the "Ralph Wiggum / vibe-coding" post — real names, real engagement
 metrics, real personal narrative). Step 13 scrubbed the **working-tree** content
 to a generic placeholder (0 `## Post N` sections → personalization score 0, no
 PII). **This does not remove the post from git history.** A history rewrite
 (`git filter-repo` / BFG) on `assets/examples/high-engagement-posts.md` is a
 separate, explicit operation — **deferred, not done here** (brief §13: out of M0
 scope). Track until the repo is published.
 ### Note — external instance retains pre-scrub content (by design)
 The Step-12 migration copied `high-engagement-posts.md` to
 `~/.claude/linkedin-studio/examples/high-engagement-posts.md` **before** Step 13
 scrubbed the in-plugin file (B3 ordering). The external copy therefore still holds
 the migrated content. That is the operator's private data dir (outside any repo) —
 the operator may curate it; not an M0 concern.
 ### D2 scaffolds completed
 All 6 scaffolds now have a read-only `*-template.*` seed: `case-study-template.md`
 and `framework-template.md` already shipped; Step 13 added the 4 missing ones
 (`high-engagement-posts-template.md`, `demographics-template.md`,
 `engagement-patterns-template.md`, `my-post-templates-template.md`). The 3
 already-generic instances seeded their templates verbatim; the high-engagement
 template is a freshly-authored generic seed (the old instance was the leak).
--- a/docs/okf-convergence-brief.md
+++ b/docs/okf-convergence-brief.md
@ -1,190 +0,0 @@
 # Brief — Cross-plugin second-brain convergence on OKF-compatible form
 > Created 2026-06-26. **Reference-design brief — not an implementation order.** Captures the operator-locked
 > direction for converging three plugins' user-owned second brains onto one shared, interoperable form,
 > with **linkedin-studio's brain as the reference design** and **Google OKF as a thin interop layer only**.
 > Cross-cutting: most rollout lands in sibling repos and requires its own per-repo go (see §8). State-of-play
 > in `STATE.md`. Companion design docs (read alongside): `okr/docs/okf-second-brain-note-2026-06.md`,
 > `ms-ai-architect/docs/okf-second-brain-brief-2026-06.md`.
 ## 1. Locked decision (operator, 2026-06-26)
 Converge on **the user's own context** (not the plugins' domain reference files), driven by **interop** —
 **not** standard-adoption for its own sake.
 - **linkedin-studio's brain is the reference design** — the most mature of the three (provenance-weighted
  learning, episodic/semantic split, evidence-threshold promotion). The siblings rise toward its maturity;
  it is **not** levelled down to bare OKF.
 - **OKF is the thin interop veneer** — add `type:` + per-level `index.md`; keep all rich fields as extension
  keys (OKF consumers MUST preserve unknown keys). No capability is sacrificed.
 - **Staged:** ship a shared **spec/convention first**; build a shared **skill only if measured divergence
  justifies it** (okr's retrieval already works — see §4).
 ## 2. Premise corrections (verified — these overturn the old STATE/memory framing)
 The pre-existing framing ("greenfield shared ingest skill; inbox→classify→convert→emit OKF; mdcode is the
 key tool") rested on three premises that ground-truth checks **disproved**. Verified against the live
 `GoogleCloudPlatform/knowledge-catalog` repo (research agent, 2026-06-26, file+URL log retained) and the
 sibling repos.
 1. **`mdcode` is NOT an OKF tool.** It is a **Google Cloud Dataplex** git-sync tool whose on-disk `kb`
   markdown carries a *different* frontmatter schema (`id`/`resource.name`/`createTime`/`links`) than OKF
   (`type`/`title`/`description`/`tags`/`timestamp`). They are not interchangeable. Do **not** plan `kcmd`
   to emit or sync OKF bundles.
 2. **"OKF has no ingest" is true of the *format*, not the *repo*.** The repo ships an OKF *producer*
   (`okf/src/reference_agent`, BigQuery+web→OKF) — but it reads a BigQuery dataset + seed URLs, **not** a
   document folder, and is Gemini/GCP-bound. The genuinely reusable, GCP-free parts are the **SPEC**, the
   **emit/serialize/validate** core (`OKFDocument`), and the `index.md` synthesis.
 3. **Classify/convert of arbitrary documents is exactly what the repo provides *nothing* for** — those
   stages are 100% build-yourself. And — decisive — **the sibling design docs never asked for them.** Both
   frame the work as *OKF as the storage format for a user-owned second-brain wiki* + a **retrieval skill**
   + a **maintenance mechanism**, with ingest being light ("onboarding writes OKF-conformant"), not
   auto-classification.
 ## 3. Landscape — the three consumers have already diverged
 | Plugin | Second-brain status | Maturity |
 |---|---|---|
 | **okr** | **Built.** `scripts/okf-index.mjs` + `okf-check.mjs` (conformance checker) + `lib/frontmatter.mjs` + skill `okr-second-brain-search` **v1.6.0** ("OKF-compatible markdown wiki") + tests + fixtures (`okf-minimal/`, `okf-realistic/`) + `inject-okr-context.mjs`. | Structured + retrieval (built) |
 | **ms-ai-architect** | **Designed, not built.** `docs/okf-second-brain-brief-2026-06.md` (operator-confirmed) + `ref-kb-direction-note` + `ref-kb-workflow-plan`. No retrieval skill yet. | Designed |
 | **linkedin-studio** | **Built, richer non-OKF schema.** `brain/` hub + `ingest/{inbox,published}` + `journal/` (episodic) + two-layer `profile.md` (semantic), provenance-weighting, evidence-threshold promotion, temporal validity. Engine: `scripts/brain/`. | Provenance-weighted learning system (most mature) |
 **Reading of the siblings' own docs:** they chose OKF because their second brains lived in ad-hoc `org/*.md`
 **with no retrieval mechanism** — for them OKF (really: *structured markdown + a retrieval skill*) was an
 upgrade from nothing. linkedin-studio is already past that point. So the convergence is "siblings rise to
 the reference," not "everyone adopts a new format."
 ## 4. okr already supplies the reference checker
 `okr/scripts/okf-check.mjs` implements **exactly the minimal contract** this brief recommends, and is the
 de-facto reference implementation to align the shared spec with:
 - **Only `type:` is required** on a concept file (`.md` except `index.md`); ≥1 file without `type` → fail.
 - Recommended fields (`resource`/`title`/`description`/`timestamp`) → **warnings, not errors**.
 - Root `index.md` carries an `okf_version` marker, echoed for human comparison — **no auto-fetch** (hooks
  are no-network).
 This means okr has **both** a writer and a checker in production. The shared artifact should generalize
 okr's checker semantics, not reinvent them. (Reading okr's code is fine; **writing** okr is a separate go.)
 ## 5. OKF v0.1 — verified core contract
 Source: `github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md` (v0.1, 12 June 2026,
 "a starting point, not a finished standard").
 - **Bundle** = a directory tree of markdown files, **one concept per file**. **Concept ID** = file path
  minus `.md`.
 - **Frontmatter:** required `type` (free string); recommended `title`, `description`, `resource`
  (canonical source URI), `tags`, `timestamp`. **Consumers MUST preserve unknown keys and tolerate unknown
  `type` values.** (Note: the Google *reference producer* is stricter than the spec — it also requires
  `title`/`description`/`timestamp`. Build to the spec; supply the rest where cheap.)
 - **Reserved filenames:** `index.md` (directory enumeration, **no frontmatter**, progressive disclosure)
  and `log.md` (change log). Optional `okf_version` lives in the bundle-root `index.md`.
 - **Cross-links:** plain markdown links (bundle-relative `/...` or relative); relation type is conveyed by
  prose. **Consumers MUST tolerate broken links.**
 - **Permissiveness is the whole point for us:** OKF is a *minimal superset-friendly* contract. Conforming
  costs `type` + `index.md`; our rich fields ride along untouched as extension keys.
 ## 6. The deliverable — "OKF-compatible second-brain form"
 A spec (document, not code) that all three plugins' user-data conforms to:
 1. **Minimal contract:** every concept file carries `type:`; each directory level has an `index.md`;
   bundle-root `index.md` carries `okf_version`. Recommended fields where cheap. (= okr's `okf-check`
   semantics, generalized.)
 2. **Rich fields survive as extension keys.** linkedin-studio's brain keeps `provenance`, `first_seen`,
   `last_seen`, `evidence_count`, `status`, episodic/semantic distinction — all as extra frontmatter keys
   OKF must preserve. The model-collapse guard (`provenance=published` only) is unaffected.
 3. **Mapping for our brain** (illustrative; verify writers in §10):
   - `brain/index.md` → bundle-root index + `okf_version`.
   - `brain/profile.md`, `operations.md`, `journal/*.md`, tributary summaries → concept files; each gains a
     `type` (e.g. `Profile`, `Operations`, `JournalEntry`, `TributarySummary`) + retains its existing rich
     frontmatter.
   - `ingest/inbox/` stays the **manual drop-zone** (already exists) — the "inbox folder" mechanism, with
     no heavy auto-classifier built now.
 ## 7. Staged plan
 - **Stage 1 — Shared spec/convention (cheap, delivers interop).** Author "OKF-compatible second-brain form"
  as a cross-cutting document; align it with okr's `okf-check`. Each plugin's user-data conforms; one
  reader can traverse all three. **This alone meets the interop goal.**
 - **Stage 2 — Measure divergence.** Do the per-plugin retrieval skills (okr's built one; architect's
  planned one; linkedin-studio's in-context reads) diverge enough to hurt? Only a *measured* yes justifies
  Stage 3 (operator anti-pattern: "ambitious initiatives where a config tweak suffices").
 - **Stage 3 — Conditional shared skill.** If justified: extract/generalize okr's working
  `second-brain-search` into one home (see §9), with a discovery convention for where each plugin's brain
  lives.
 ## 8. Home decisions
 - **The spec** is cross-cutting → **catalog/marketplace level** (owned by no single plugin).
 - **A future shared skill** (Stage 3 only) → a **standalone marketplace plugin** (own repo, release-tagged,
  catalog-pinned), installable alongside the others, serving **consumer (a) — the user's own context —
  directly**. Rejected alternatives: duplicate-per-plugin (drift risk); user-level `~/.claude/skills/`
  (unversioned, outside the catalog).
 ## 9. Per-repo scope boundaries (each its own explicit go)
 | Repo | This initiative's work | Status |
 |---|---|---|
 | **linkedin-studio** (here) | (1) Be the reference design (mostly exists in `docs/second-brain/architecture.md`). (2) Make our own brain emit OKF-compatible form (`type` + per-level `index.md` + root `okf_version`) without dropping rich fields. | **In scope — (2) ✅ LANDED 2026-06-26** |
 > **Stage-1 outcome (2026-06-26).** Brain writers now emit OKF-compatible form: `serializeProfile`
 > leads with `type: Profile` frontmatter (constant → round-trip-safe), `operations.md` seed leads with
 > `type: Operations`, `brain/index.md` carries an `okf_version: 0.1` marker, and `brain/journal/index.md`
 > is scaffolded (per-level index). **Premise refinement (verified):** the brain is *deliberately*
 > YAML-free with a byte-exact round-trip invariant on `ingest/published/*.md` (SC2) that a frontmatter
 > block would break — so the OKF concept-bundle is scoped to **`brain/` only**; the round-trip-critical
 > **`ingest/` tributary is excluded** and pointed to from the hub index. We **emit** frontmatter, adding
 > no YAML parser. 5 new tests (`tests/okf-conform.test.ts`); full brain suite **132/132**; cross-tool
 > proof — `okr/scripts/okf-check.mjs` validates `brain/` (exit 0). **Finish (same day):** the cheap
 > recommended fields `title`/`description` added to the concept frontmatter (`timestamp`/`resource` stay
 > out — a timestamp would break the pure serializer, `resource` is N/A for an internal concept); and the
 > transient `brain/pending-diff.md` now carries `type: PendingDiff` so the bundle passes `okf-check` even
 > mid-propose (re-verified exit 0 with a pending-diff present). Brain suite **134/134**.
 | **okr** | Optional form-conformance alignment (already has writer + checker). | **Separate go** |
 | **ms-ai-architect** | Build its retrieval skill against the shared spec. | **Separate go** |
 | **catalog** | Host the shared spec. | **Separate go** (catalog only via `release-plugin.mjs`) |
 | **new standalone plugin** | Stage-3 shared skill, if justified. | **Separate go** |
 Per scope-guard + "never write in other repos without explicit instruction": this session touches
 **linkedin-studio only**.
 ## 10. Key assumptions + tests (plan-quality mandate)
 | Assumption | Test (before relying on it) |
 |---|---|
 | OKF preserves unknown keys → our rich brain fields survive conformance | **✅ Verified:** `okf-check.mjs` exits 0 on `brain/`; `profile.md` round-trips (`parseProfile` skips the frontmatter, `parse ∘ serialize` identity holds). |
 | Our brain is already near-OKF (conformance is a small writer change) | **⚠️ Refined → verified:** brain is *deliberately* YAML-free and `ingest/published` is round-trip-critical, so a literal frontmatter target conflicts there → bundle scoped to `brain/`, `ingest/` excluded (tributary). 4 surgical writer touchpoints (3 scaffold seeds + `serializeProfile`); we EMIT frontmatter, add no parser. |
 | okr's `okf-check` semantics generalize as the shared conformance contract | Diff okr's contract (only-`type`-required, recommended=warnings, `okf_version` echo) against OKF SPEC §9 conformance → confirm it is a faithful, slightly-laxer subset. |
 | A shared skill is *not yet* justified | Stage-2 measurement, deferred — do not build Stage 3 before it. |
 ## 11. Open choices (resolve in `/trekbrief` or measurement, not now)
 - **Retrieval mechanism:** native Grep/Glob/Read (skill instruction "search the wiki first, open only
  relevant") vs. a dedicated fileskb MCP server. Both sibling docs lean **native** (Claude Code's
  Grep/Glob/Read already cover OKF's list/search/read). Genuine doubt → "build both, measure" candidate.
 - **Degree of OKF formalism:** full v0.1 conformance vs. "OKF-compatible form" (frontmatter + `index.md`
  only). Lean to the lightest that yields smart retrieval.
 - **Inbox auto-classify/convert:** **defer.** OKF gives nothing for it; the manual inbox seam already
  exists. Build only on demonstrated need.
 - **Discovery convention:** how a shared skill finds each plugin's brain root.
 - **OKF version-bump tracking:** how to catch v0.1 → later without manual polling (hooks are no-network).
 ## 12. Success criterion (operator, inherited from both sibling tracks)
 Measured against **user value** (does the plugin retrieve the right personal/org context in chat and
 commands?) + **maintenance reliability** — **not** against formal OKF conformance for its own sake.
 ## 13. References
 - OKF SPEC v0.1: `github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md`
 - Sibling design docs: `okr/docs/okf-second-brain-note-2026-06.md`,
  `ms-ai-architect/docs/okf-second-brain-brief-2026-06.md`,
  `ms-ai-architect/docs/ref-kb-direction-note-2026-06.md`
 - okr reference implementation: `okr/scripts/okf-check.mjs`, `okr/scripts/okf-index.mjs`,
  `okr/skills/okr-second-brain-search/SKILL.md`
 - Our reference design: `docs/second-brain/architecture.md`; engine `scripts/brain/`
 - Verified-OKF research log (files+URLs fetched on `main`): retained in session transcript, 2026-06-26
 - Memory: `google-okf-open-knowledge-format`, `profile-evolution-second-brain`,
  `plugin-vs-maskinrommet-division`, `plugin-is-domain-general`
--- a/docs/okf-ingestion/plan.md
+++ b/docs/okf-ingestion/plan.md
@ -1,341 +0,0 @@
 # OKF-ingestion plan — mapping this repo against `llm-ingestion-okf` (phase 4)
 > **Status: `planned` (2026-07-20).** Survey + requirements only — nothing wired, nothing built. The
 > library's Node half does not exist yet (its phase 4), so there is nothing to adopt today. This document
 > is the repo's durable answer to *what door A or door B must support before this plugin can adopt*, and
 > *what must never move into the shared library*.
 >
 > **Library:** `llm-ingestion-okf` v0.3.1 — Python 3.10+, zero runtime deps, **door A only**
 > (manifest → connector → deterministic materialization of `ingest-{id}.md` → index generation, no model
 > calls). Doors B (inbox) and C (external bundle import) are phase 2; the Node half is phase 4.
 > **Spec:** `ingest-spec.md`, owned by `portfolio-optimiser-commons` — changes go via commons, never locally.
 > **Security boundary:** `llm-ingestion-guard` (repo `llm-ingestion-pipeline-security`) owns all security.
 > Door A is **ungated** — it calls no guard function before writing to disk (verified: no guard import or
 > call site anywhere in the library's `src/`; `dependencies = []`). "Security is delegated" does **not**
 > mean "safe by default"; gating is the caller's responsibility.
 >
 > **Separate, do not merge:** `docs/ingestion-guard/plan.md` (`planned`) is this repo's *security* wiring
 > plan. It shares persist points with this document by necessity, but is a distinct decision with a
 > distinct dependency. §7 states the boundary.
 ## 1. Executive answer
 **Nothing here is a clean door-A fit today, and the reason is not the one the library expects.**
 The library's open finding F1 is *"door A has no free-text connector"*. That is real for us, but it is not
 our blocker. Our blocker is one level deeper:
 > **Door A reaches sources with deterministic code. This plugin does not fetch anything with code.**
 Every external input in this repo arrives through a *model turn* — the `trend-spotter` agent's
 WebSearch/WebFetch/MCP calls, `/linkedin:react`'s WebFetch of an operator-supplied URL. There is no raw
 HTTP fetch anywhere in plugin code (verified across `scripts/`). Door A's three connectors (`file`, `sql`,
 `http`) all assume code can go get the bytes. For our largest and least-trusted surface, code cannot.
 So the requirement we contribute to F1 is not *"add a free-text connector"* — it is **"add a door that
 accepts an already-fetched, model-produced payload and materializes it deterministically."** That door
 would immediately fit `trends capture`, which is already exactly this shape (stdin JSON envelope →
 validate → deterministic store write). Details in §4.
 Adoption verdict: **`planned`, conditional.** Adopting door A as it stands would mean converting typed,
 incrementally-accreting stores into rewrite-on-run markdown documents — a downgrade. We adopt when §4's
 four requirements land, not before.
 ## 2. Our sources — tabular vs free-text
 | Source | On disk | Shape | Trust boundary | Door-A fit today |
 |---|---|---|---|---|
 | **Analytics CSV export** → batches | `exports/*.csv` → `posts/<date>-<id>.json` | **Tabular** (header row + rows) | First-party (operator's own LinkedIn export), but an unvalidated parse surface | **Closest fit.** Satisfies `read_csv`'s header requirement. But see §3 — the output shape is wrong. |
 | **Trend capture** | `trends/trends.json` (schema v4) | JSON envelope; `title`/`url`/`summary` are **verbatim free text** | **External**, model-mediated (web search/fetch via agent) | **No connector exists.** Not `http` — the fetch already happened, in a model turn. |
 | **Morning brief** | `trends/morning-brief/<date>.md` | Structured md, carries external strings forward | Machine-rendered from store; re-injected by SessionStart hook | Destination, not a source. |
 | **Brain inbox → published** | `ingest/inbox/*.md` → `ingest/published/<id>.md` | **Free text**, byte-exact body | Operator-dropped today; drop-zone has no origin control | **Excluded by design** — see §5. |
 | **Brain profile** | `brain/profile.md` | Line grammar (6 constrained tokens + one-line value) | Machine-folded, operator-gated (`--apply --confirm`) | Destination. Already an OKF-conformant bundle (Stage 1, 2026-06-26). |
 | **Specifics-bank** | `specifics-bank/specifics-bank.json` | JSON + verbatim free-text `content` | Operator-written by invariant (never AI-generated lived experience) | Destination. |
 | **Contract-gate** | — writes nothing | Reads local operator files only | Local | Not applicable. |
 **Summary:** one genuinely tabular *source* (analytics CSV). One free-text external source that is not
 reachable by any connector shape the library has (trend capture). One free-text local source that is
 excluded by a fixed decision (published posts). Everything else is a destination store, not an ingestion
 input.
 ## 3. Where door A's contract collides with ours
 Four structural mismatches, each verified against the library's code. These are not preferences — each one
 would break an invariant we hold today.
 **(1) Fixed 7-key frontmatter, no extension keys.** `materialize.py` emits exactly `type`, `title`,
 `source_system`, `source_query`, `ingested_at`, `ingest_manifest`, `generated` — in fixed order, all values
 collapsed to single lines. Our records carry domain fields that must survive: `provenance`, `status`,
 `first_seen`, `last_seen`, `evidence_count` (brain), `score`, `pillar`, `topics`, `surfaced` (trends).
 Note the tension with OKF the *format*, which explicitly requires consumers to preserve unknown keys — the
 library's materializer is stricter than the spec it implements. Our Stage-1 OKF conformance work
 (`docs/okf-convergence-brief.md`) depends on rich fields riding along as extension keys; door A has no
 mechanism for that.
 > **Addition, 2026-07-20 (trinn E).** Two runs of `okr/scripts/okf-check.mjs` against a fresh
 > `brain init` scaffold sharpen this into a concrete argument, and correct one of our own claims:
 >
 > - The reference checker's own constant is named `RECOMMENDED`, not `REQUIRED` (`okf-check.mjs:21`).
 >   A bundle missing `resource`/`timestamp` gets **warnings and exit 0**. The de-facto conformance
 >   tool already treats every §5 key beyond `type` as advisory — so a mandatory ordered prefix would
 >   turn a green bundle red without a byte changing. Argument fed to commons' D1.
 > - **Correction:** trinn C claimed our `type` vocabulary is five values. It is three —
 >   `Profile` (`scripts/brain/src/profile.ts:48`), `Operations` (`scaffold.ts:56`),
 >   `PendingDiff` (`cli.ts:252`). `JournalEntry`/`TributarySummary` exist only as examples in
 >   `docs/okf-convergence-brief.md:101`, never in code.
 > - **Correction:** we assented to a closed `type` vocabulary without checking its contents.
 >   `okf-check.mjs --strict-ingest` **exits 1** on our conformant bundle — `okr/lib/okf-vocab.mjs:11-21`
 >   is nine okr-domain values, and the safe default (`Dokument`) collapses all three of our types into
 >   one, erasing the distinction `okf-conform.test.ts` rests on. Our assent now carries a condition:
 >   an absent vocabulary must mean *do not snap*, and the vocabulary is per-bundle, never spec-global.
 **(2) Rewrite-on-run ownership vs incremental accretion.** Door A owns files via `generated: true` +
 `ingest_manifest`, then **deletes every stamped file and rewrites the set** each run. Our stores accrete:
 dedupe by content id, topic-union on re-capture, last-wins score, collision-suffix on body divergence,
 compare-then-skip on scaffold. A door-A run against our data would be destructive by design.
 **(3) Operator-chosen slug ids vs content-addressed ids.** Library id = the manifest's `extraction.id`
 (a hand-written slug, `[a-z0-9][a-z0-9-]*`), with provenance carried by a manifest stamp
 (`{stem}@{sha256(manifest bytes)[:16]}`). Ours = `sha256(content)[:12]` — the id *is* the dedupe key, which
 is why re-capturing the same trend or re-ingesting the same post is idempotent for free. A slug-keyed
 model cannot express "same content, seen twice."
 **(4) Table rendering destroys free text.** `render_table` escapes `\` then `|`, then collapses CRLF/CR/LF
 **to a single space**. Any multi-line body loses its line structure. This is fatal for post bodies (§5) and
 lossy for trend summaries.
 ## 4. What door A / door B must support before we can adopt — the concrete asks
 Ordered by how much they unblock. (1) is the one that decides F1 for us.
 **R1 — A model-mediated door ("already-fetched payload").** Accept a caller-supplied, schema-validated
 payload (stdin JSON envelope or in-process record array) instead of a connector-fetched one, and
 materialize it with the same determinism, same stamping, same idempotence as door A. The manifest would
 declare shape and destination but not a fetch. This is the door that fits how an agentic plugin actually
 ingests, and we have a working precedent to donate: `trends capture` is this contract already
 (`normalizeItem` → "the one schema downstream never branches on" → deterministic store write).
 **Why this over a free-text connector:** a `read_text`/`read_markdown` connector would serve repos whose
 free text sits in a folder. Ours sits in a model's tool result. Both are needed; they are not the same ask,
 and solving only the folder case leaves us exactly where we are.
 *Security note:* this door is precisely where untrusted, model-touched bytes cross into a persisted store,
 so it is where a guard call belongs. That wiring is `docs/ingestion-guard/plan.md`'s decision, not this
 document's — but the door must at minimum expose a seam for it rather than writing straight through.
 **R2 — Extension keys preserved through materialization.** Let a record carry arbitrary additional
 frontmatter keys, emitted after the 7 reserved ones, order-stable, never coerced. Without this, every
 domain field we have is lost on the way through the library, and OKF's own "preserve unknown keys" rule is
 violated by the tool that writes OKF.
 **R3 — Incremental/upsert materialization mode.** A mode where a run merges into an existing bundle keyed
 by record id — add new, update changed, leave untouched what this run did not see — instead of
 delete-all-stamped-then-rewrite. Door A's index maintenance already does exactly this kind of careful
 merge for `index.md` (managed lines refreshed, curated lines preserved byte-verbatim); the ask is to extend
 that discipline from the index to the records.
 **R4 — Content-addressed record ids as a first-class option.** Allow `id = hash(content)` rather than a
 manifest slug, so dedupe and idempotence come from the data. Our three stores (brain, trends,
 specifics-bank) all independently converged on `sha256(...)[:12]`; the pattern is not LinkedIn-specific.
 **R5 (phase 4, Node half) — contract parity details.** Stable string error codes on the error object
 (the Python half's `exc.code` discipline, mirrored so Node consumers assert on `err.code`, never on message
 text); zero runtime dependencies; ESM with `node:` prefixes; and the golden-fixture set shared across both
 halves so byte-identity is the test, not the promise.
 > **Correction, 2026-07-20 (trinn D-review).** An earlier revision of this section claimed we "already meet
 > the zero-dep/ESM/LF conventions". Verified against the code, two parts of that were false:
 >
 > - **We have no stable error codes.** None of the four CLIs set a machine-readable code; every failure is a
 >   free-text `Error` plus a numeric `process.exit` (`scripts/brain/src/ingest.ts:99,:113`,
 >   `scripts/trends/src/cli.ts:125,:255`). `err.code` is an ask *of* the library, not a discipline we mirror.
 > - **"Exactly one trailing newline" is not asserted here either.** Nothing tests it, and
 >   `serializePublishedRecord` deliberately omits it (`scripts/brain/src/ingest.ts:71`) because the record
 >   must end on the verbatim body or the byte-exact round-trip (SC2, §5) breaks.
 >
 > **Second correction, same day, narrowing the one above.** The trinn D-review first read this as a
 > conflict with `claude-playlist-corpus`, who asked the library to own frame normalization (LF-only, one
 > blank line, trailing newline). It is not a conflict, and the check should have come first: our
 > newline-free serializer governs `ingest/published/`, which is **excluded from the OKF bundle by design**
 > (§5, `scripts/brain/tests/okf-conform.test.ts:22-27`). The files `write_concept` would actually write for
 > us — the `brain/` bundle — get their trailing newline from our own serializer
 > (`scripts/brain/src/profile.ts:65`). On the concept-writing path we agree with them. What survives is
 > narrower: `write_concept` is also being asked to serve as a *general* verbatim writer callable outside a
 > bundle (`ms-ai-architect`, `po-claude`), so frame normalization should be a documented parameter rather
 > than an unconditional guarantee. The fixture ask applies to that general writer, not to the concept corpus.
 >
 > Zero-dep/ESM does hold (sole exception: `scripts/analytics` depends on `csv-parse`).
 ## 5. What must never move here
 **`ingest/published/` provenance grammar stays plugin-local — fixed decision, and it has a technical
 floor.** This is not merely a scope preference:
 - The store holds a **byte-exact round-trip invariant** (`parse ∘ serialize = identity`, SC2) on the
  verbatim post body. Door A's table renderer collapses newlines to spaces (§3.4); its frontmatter
  collapses whitespace runs. Either would break the invariant on contact.
 - The record id is `mintContentId(verbatim body)` — deliberately **un-normalized**, so two
  structurally-different posts never collide and the write path never silently drops a differing body.
 - The grammar is deliberately YAML-free (a fixed 5-line header + `\n---\n` sentinel), which is also why our
  own Stage-1 OKF conformance work scoped the concept-bundle to `brain/` and **excluded the `ingest/`
  tributary** — verified 2026-06-26, `okf-check.mjs` exit 0 on `brain/`.
 - `provenance=published` carries **model-collapse-guard semantics**: the voice/profile learning surface
  learns from human-published content only, never from `ai-draft`. The *form* is generic; the *guarantee*
  is domain policy and belongs where the policy is enforced.
 We are happy to describe the interface (this section is that description). We are not planning to hand it
 over.
 **Also staying — LinkedIn domain logic:** trend scoring weights and mode SSOT
 (`references/trend-scoring-modes.md`); brief ranking, pillar logic and Norwegian rendering; the
 analytics↔post join heuristic (title-prefix matching with the 110-char hook rule behind `PREFIX_FLOOR`);
 CSV column fuzzing against LinkedIn's export column names, the `engagementRate` formula and `saves`
 semantics; the specifics taxonomy and its verification rules; contract-gate's writing-contract rules.
 **Candidates for sharing (bundle mechanics, if the Node half wants them):** content-addressed id minting;
 dedupe + tag-union upsert; migrate-on-load `schemaVersion` stamping; collision-safe idempotent writes
 (compare-then-skip, collision-suffix); path-traversal-safe filename resolution (our `storage.ts` twin of
 the library's fail-closed `safe_resolve`); managed-line index maintenance. Several of these modules already
 declare themselves generic by architecture. Note we carry the data-root resolver in **five** inlined copies
 (four `scripts/*` packages + a zero-dep hooks twin, synchrony guarded by test) — deliberate, since the
 *path convention* is plugin-local even where the *idiom* is not; a shared library should take the idiom and
 leave the path.
 ## 6. Bundle inventory and placement
 Operator decision, 2026-07-20: **user-owned OKF bundles live outside the plugin/repo tree and are only
 referenced from it.** Plugin-generated bundles that are part of the plugin's own delivery stay.
 **We already comply — the migration happened in M0 (v0.6.0), before the decision existed.** Every
 user-owned artifact resolves through `${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/`
 (`references/data-path-convention.md`), with an idempotent session-start migration. Nothing user-owned has
 lived in the repo tree since.
 | Artifact | Path | OKF bundle? | Class |
 |---|---|---|---|
 | **Brain** | `<data-dir>/brain/` | **Yes** — the repo's only OKF bundle (`type` + per-level `index.md` + root `okf_version: 0.1`; `okf-check.mjs` exit 0, 2026-06-26) | **User-owned** — see boundary case below |
 | Published-post tributary | `<data-dir>/ingest/{inbox,published}/` | No — deliberately excluded (§5) | User-owned |
 | Trend store | `<data-dir>/trends/trends.json` | No — a single JSON file, not a markdown bundle | User-owned |
 | Morning briefs | `<data-dir>/trends/morning-brief/<date>.md` | No — dated briefs with frontmatter, no `index.md`, not concept files | User-owned |
 | Specifics-bank | `<data-dir>/specifics-bank/specifics-bank.json` | No | User-owned |
 | Analytics batches | `<analytics-root>/posts/*.json` | No | User-owned |
 | Reference docs (28) | `references/*.md` **in repo** | No — no `type`, no `index.md` | **Plugin-owned**, ships with the plugin, correctly in-tree |
 **Nothing breaks on migration, because there is nothing left to migrate.** The one caveat is historical:
 pre-M0 installs kept data in-tree, and the session-start migration already handles that path. A second
 caveat worth naming: `assets/drafts/queue.json` and `assets/analytics/` remain in-tree as gitignored
 scratch — they are not bundles, but they are the last in-tree paths that hold user bytes, and they should
 be revisited if the decision is ever tightened to "no user bytes in-tree at all."
 ### The boundary case — and it says the taxonomy's axis is wrong
 The decision's table discriminates on **who writes**: plugin writes → plugin-owned → lives in the repo.
 Our brain is **written by the plugin** (`consolidate`/fold, operator-gated at `--apply --confirm`) and
 never hand-authored. By that table it is plugin-owned and belongs in the repo. **That conclusion is
 exactly wrong** — it is the single most personal artifact we hold, it must survive plugin upgrade and
 uninstall, and the repo is publicly distributed.
 The discriminator that gives the right answer everywhere in our inventory is **whose lifecycle the content
 follows**, not whose hand writes the bytes. Our brain is machine-written and user-owned, and that
 combination is not a rare corner — it is what any learning system produces. We suggest the axis be
 lifecycle/ownership, with authorship as a non-determinative attribute. Otherwise every plugin that
 *derives* user knowledge lands on the wrong side of a table it read correctly.
 ## 7. Boundary against the guard plan
 `docs/ingestion-guard/plan.md` identifies four persist gates: trends `capture`, brain
 `writePublished`/`scanInbox`, newsletter→`ekstern` bindings, analytics `saveBatch`. Two of those (trends
 capture, analytics import) reappear here as adoption candidates — unavoidably, since they are the same
 boundary viewed from two sides.
 The split: **the guard plan decides whether bytes are safe to persist; this plan decides what writes them
 and in what shape.** They share a dependency in one place only — R1's seam is where a guard call would
 land — and that is noted as a seam requirement, not a security decision. Neither plan is a prerequisite for
 the other's approval. The guard plan's own interop blocker (Python↔Node) is tracked there.
 ## 8. Open questions for the library owners
 1. Does R1 (model-mediated payload door) belong to door B, or is it a fourth door? It is neither an inbox
   scan nor an external bundle import.
 2. Is R2 (extension keys) a spec change via commons, or a materializer relaxation within the current spec?
   OKF v0.1 already mandates preserving unknown keys, which suggests the latter.
 3. ~~For phase 4: is the Node half expected to reach parity with door A only, or with whatever doors exist
   when it starts?~~ **Answered 2026-07-20 (trinn E, felles §6): phase 4 delivers the layer-1 primitives,
   not `materialize_bundle` parity** — no Node repo in the set runs door A (verified here: the only Python
   in this repo is `hooks/scripts/compile-hooks.py`, a build-time script never on a data path). Our register
   status therefore stays **`planned`**, not `blocked on phase 4 scope`. One follow-up outstanding: layer 1
   grew after the question was asked (`read_concept`, `navigate_bundle`, `routeLevel`), so we asked whether
   phase 4 tracks the set as it stands or as it evolves — the reader is decision-relevant for us, since our
   dependency is `serialize ∘ parse = identity`, not the writer alone.
 ## 9. References
 - Library: `https://git.fromaitochitta.com/open/llm-ingestion-okf`
 - Guard: `https://git.fromaitochitta.com/open/llm-ingestion-pipeline-security`
 - Spec owner: `portfolio-optimiser-commons/ingest-spec.md`
 - This repo: `docs/okf-convergence-brief.md` (Stage-1 OKF conformance, `brain/` bundle),
  `docs/ingestion-guard/plan.md` (separate, `planned`), `docs/second-brain/architecture.md`
 ## 10. Trinn E — consolidated positions (preserved before postbox teardown, 2026-07-21)
 The OKF adoption round closed at trinn F (consensus). Our trinn E answer lived in the interim
 postbox (`~/repos/_okf-interim/svar/linkedin-studio.md`), which is now torn down. Its durable
 substance is preserved here; everything below was verified against code on 2026-07-20. The
 technical requirements (R1–R5) already live in §4; this section captures the round-positional and
 follow-up material that existed only in the postbox.
 **Our §7 register row (status + position).**
 - Status stays **`planned`**, not `blocked on phase 4 scope` — verified: the only Python in this
  repo is `hooks/scripts/compile-hooks.py`, a build-time script never on a data path; we do not
  run door A and would gain nothing from parity.
 - We do **not** need door-A stamping (`generated` / `ingest_manifest`). The negative requirement
  holds: inject nothing, normalize nothing.
 - Unforgeability must live **outside the file** — our content-address `mintContentId` (byte-exact
  sha256, `scripts/brain/src/id.ts:53-55`) is unforgeable without the writer forming an opinion
  about the frontmatter. If the writer inspects the string to enforce a stamp, passthrough (R2) is
  gone in the same move.
 - §5 must tolerate extension keys (R2, unchanged); the mandatory reserved-key prefix is limited to
  **stamped, extracted** concepts, not concepts as such.
 **D1 (frontmatter/stamp) — we are affected, not owner.** The ratified D1 **matches our ask**:
 enforcement moved to `check_bundle` (per-file outcome); the door-C writer rejects the *complete*
 ownership stamp (`generated:true` **and** `ingest_manifest` together), not the five names, so
 round-trip for legitimate door C is preserved; the mandatory prefix binds stamped (door-A) files
 alone. We accept commons' point that passthrough makes §5's key contract unenforceable at the
 writer by construction — that is the right outcome, since the writer cannot make the
 stamped-vs-curated distinction without reading what it promised not to read.
 **D3 (`partial`) — accepted with one caveat, now resolved.** We accepted the definition and flagged
 that "comparable path" was undefined (it decided our value outright: `brain/` writing through the
 library while trend-store / specifics-bank stay standalone JSON — `scripts/trends/src/store.ts:126-141`).
 The ratified definition (trinn F) is: comparable path = would have gone through the same door
 (A/B/C). Under that, our JSON/CSV/domain-store paths are not comparable and do not force us
 `partial`. **Our status today is `planned`, not `partial`** — zero production paths go through the
 library; we do not emit `partial` (now a transitory value carrying owner + next step) until it is
 ratified.
 **Durable technical additions (would otherwise be lost with the postbox).**
 - **Empty vocabulary must mean "don't snap", not "snap to default".** Verified:
  `node okr/scripts/okf-check.mjs <brain> --strict-ingest` collapses our three real types
  (`Profile` / `Operations` / `PendingDiff`) to `DEFAULT_TYPE='Dokument'`
  (`okr/lib/okf-vocab.mjs:26`), erasing the distinction our conformance test rests on
  (`scripts/brain/tests/okf-conform.test.ts:15-20`). Vocabulary is per-bundle, never spec-global.
  Ask: absence of an injected vocab list is a legal state (= "don't snap"), not "snap all to default".
 - **Supporting evidence, and it is not ours:** `okf-check.mjs:21` names the constant `RECOMMENDED`,
  not `REQUIRED` — the de-facto checker all nine repos read already treats §5 keys beyond `type` as
  warnings, not requirements. Making the prefix mandatory would turn a green bundle red with zero
  byte change, contradicting the tool that defined conformance in practice during the round.
 - **`type` vocabulary is three values, not five** (corrects trinn C §5): only `Profile`
  (`scripts/brain/src/profile.ts:48-50`), `Operations` (`scaffold.ts:56-58`), `PendingDiff`
  (`cli.ts:252`) are emitted by code; `JournalEntry` / `TributarySummary` exist only as "e.g." in a
  design note (`docs/okf-convergence-brief.md:101`), never in code.
 - **Index `preserve-unowned` boundary.** We have a fourth index mode — create-if-absent, no managed
  lines, whole file hand-editable (`scripts/brain/src/scaffold.ts:33-36,126-141`). Concrete
  requirement for eventual adoption: `write_index(mode="preserve-unowned")` against an existing file
  with no managed lines must leave it **byte-untouched**, not normalize the frame "while it is there
  anyway" — else we lose a file the operator hand-writes.
 - **Layer 1 = the evolving set, not a frozen snapshot** (also §8 item 3). Since §5 added
  `read_concept`, `navigate_bundle`, and `routeLevel` after Q3 was asked, "the layer-1 primitives"
  must read as the set as it stands, not a snapshot: our invariant is `serialize ∘ parse = identity`
  (`scripts/brain/tests/ingest.test.ts:102`), and a Node half with a writer but no reader gives us
  half the invariant. Derived (not a new ask): the shared golden fixtures for `resolve_link` must
  cover all four orthogonal axes across runtime — our R5 stated the fixture requirement for the
  writer's frame alone, which is now too narrow.
--- a/docs/research-engine/brief-re-r1.md
+++ b/docs/research-engine/brief-re-r1.md
@ -1,89 +0,0 @@
 # Brief — RE-R1: lift the research engine's item-schema + triage-scorer from agent prose to tested code
 > **Slice:** RE-R1 (research-engine rung-2, slice 1) — the first build slice of the daily research motor.
 > **Status:** drafted, awaiting go-gate. **Predecessors:** "slice 2a" = the scoring SSOT `references/trend-scoring-modes.md`; "slice 2b" = the trend store `scripts/trends/` (24/24). This slice adds the **scoring/normalization code those two anticipate** (`trend-scoring-modes.md:96-100` names "any future research-engine pass that scores candidates before writing them to the trend store" as a consumer).
 > **Substrate:** `docs/research-engine-concepts.local.md` §1, §3 (B1/B2), §5 ("anbefalt minste neste slice"). **TDD-order:** RED tests + RED gate self-test land before code.
 ## 1. Operator decision context (2026-06-23)
 The operator lifted the **research engine to Tier-1**. Rationale, verbatim: *"hele min arbeidsflyt hviler på at jeg får en jevn strøm av gode forslag til tema å skrive om."* A/moat (lived-specifics · positioning · shareability · analytics→loop) remains the long-term nordstjerne but is built **interactively in Maskinrommet from lived use**, not as a TDD slice now.
 This slice is exactly the one `research-engine-concepts.local.md` §5 named as the minimal next move *if research is lifted*: **B1 (uniform item-schema, tested) + B2 (triage-scorer as code with threshold config)**. It moves "the only untestable layer" from agent prose into gated code, and is the foundation every later rung (brief artifact, surfacing, freshness, deepening) hangs on.
 ## 2. The gap — grounded in code
 - **Storage exists; scoring does not.** `scripts/trends/src/store.ts` (183 LOC) stores/dedupes/queries `TrendRecord {id,title,url,source,capturedAt,topics[],summary?}` (`types.ts:26-41`). Its header states scoring "lives in the agent/command layer; this module only stores, dedupes, and serves." There is **no scoring/routing/saturation/digest code anywhere** in the repo.
 - **The arithmetic is prose the LLM runs in its head.** `references/trend-scoring-modes.md` (SSOT, 101 lines) defines two modes — **kortform** (Pillar .30 / Audience .25 / Timing .20 / Angle .15 / Authority .10) and **long-form** (Pillar .30 / Depth .25 / Angle .20 / Authority .15 / Currency .10) — a weighted composite on a shared 0–10 scale, and a composite→band map (8.0–10 Immediate · 6.0–7.9 High · 4.0–5.9 Medium · 2.0–3.9 Low · 0–1.9 Skip), each band carrying a kortform + long-form action. `agents/trend-spotter.md:124-137` tells the agent to "score each dimension 1–10, take the weighted composite, rank highest-first, apply the bands" — **deterministic arithmetic with no test and no code.**
 - **Ingress is ad hoc.** Nothing normalizes a source's raw output into one item envelope before it reaches `addTrend`; downstream would branch on source-type. B1 is the "one schema downstream never branches on" the concepts doc calls "the most load-bearing idea — build it first."
 ## 3. Scope — what is IN (RE-R1)
 ### B1 — canonical item schema + normalizer (`scripts/trends/src/item.ts`, NEW)
 A `TrendItem` **ingress envelope** `{ source, title, url, publishedAt?, topics[], summary? }` — what a source/adapter emits — plus a pure `normalizeItem(raw): { ok: true, item } | { ok: false, errors }` and `normalizeItems(raw[]): { items, errors }` (batch partition). Deterministic: required-field validation (`source/title/url` present and non-empty → else a structured `{ok:false}` error naming the field, never a silent partial), whitespace normalization (reuse `normalizeField` from `store.ts`), topic normalize + dedupe, `publishedAt` ISO-8601-validate-**if-present** (the source's publish date — carried for forward-compat, **not persisted in R1**, and distinct from the store's `capturedAt`). **No `id` field:** the envelope carries none and the store already derives it via `addTrend`→`trendId`. Vocabulary kept as `topics` (≡ the concepts doc's `tags`; see §8). **The item→store bridge** (injecting `capturedAt`, persisting `publishedAt`) is **R2 orchestration — out of scope here**; R1 delivers the validated envelope + normalizer only.
 ### B2 — deterministic triage-scorer (`scripts/trends/src/score.ts`, NEW)
 `ScoreMode = 'kortform' | 'long-form'`; per-mode weight constants **encoded from the SSOT** (with the SSOT's "ordering is the signal, not a measured coefficient" caveat as a comment). `DimensionScores` (mode-specific keys). `composite(scores, mode): number` — weighted sum, validates each dimension ∈ [1,10]. `band(composite): { priority, kortformAction, longformAction }` — the five-band map. `triage(scored, { mode, threshold }): { kept, dropped }` — kept = composite ≥ threshold, ranked composite-desc, each annotated with composite + band; dropped below. `threshold` is a single config parameter (default — see §8). The module owns **only** the arithmetic / bands / threshold; producing the five dimension scores stays model judgment (the deterministic/judgment split from the concepts doc §5 / SSOT analysis).
 ### CLI surface (`scripts/trends/src/cli.ts`, EDIT existing)
 Two new subcommands over the new modules — both **read their JSON payload from stdin** (a raw item/batch for `normalize`; items-with-dimension-scores for `score`) and **emit JSON to stdout**, so they do **not** overload the existing `--json` *output* toggle (`cli.ts:79`). `score` takes `[--mode kortform|long-form] [--threshold N]` flags. Exit codes: **2** for a malformed invocation (missing required flag, unparseable stdin JSON) — matching `cli.ts`'s usage-error precedent (`cli.ts:54-63`); **0** for a well-formed call, even when the payload carries content-invalid items (reported as `{ok:false,...}` entries in the output, never via the exit code).
 ### Wiring + gate
 - `agents/trend-spotter.md` (EDIT): replace the "do the composite + bands yourself" prose at L124-137 with a pointer to the scorer CLI as the owner of the composite/band/threshold step (the lift becomes real and grep-able; the agent still supplies the five judgment scores). Kept domain-general.
 - `scripts/test-runner.sh` (EDIT): bump `TRENDS_TESTS_FLOOR` (recount live at land; it **stays inside the `if [ -x …/tsx ]` deps guard** — conditional, never hoisted out). Add a new **grep-only** Section **16g**, placed after Section 17 (de-niche) and **before** Section 18 (anti-erosion, which must run last so it sees every prior check), with deps-absent-safe checks (no `tsx`): (1) `grep` that `score.ts` encodes both mode weight-sets; (2) `grep -qF "src/cli.ts score"` that `trend-spotter.md` references the scorer CLI; (3) a non-vacuity self-test for those greps, per the house pattern (every sibling section 16c–17 has one). These are **unconditional** → bump `ASSERT_BASELINE_FLOOR` 84 → **live recount** (expected ~+3, not a pinned number). The arithmetic proof (`composite(all-tens)=10.0` ⇒ weights sum to 1.0) lives as a **unit test** in `score.test.ts` (conditional, counts toward the trends floor), since it needs the `tsx` runtime.
 ## 4. Non-goals — what is OUT (deferred)
 - **The dated brief artifact / morning-brief file (B3)** — R2. *This is the rung that makes the stream visible to the operator; R1 is the foundation beneath it, not the stream itself.*
 - **Session-start surfacing** of the brief (hull 4) — R2.
 - **Store-schema migration / new persisted fields** (publishedAt, relevance, saturation, status — hull 3/5) — R2. R1 keeps `SCHEMA_VERSION = 1` untouched (no migration risk).
 - **Freshness window / dedup-vs-seen-log / autonomous trigger (B4)** — R3.
 - **Research-deepening (plan → isolated workers → synthesis, A1–A4)** — R3.
 - **Adapter sub-agents / MCP fetch fan-out** — R2/R3.
 - **Producing the five dimension scores in code** — stays model judgment, by design.
 ## 5. Boundaries / invariants (must hold)
 - **TDD iron law:** the failing `item`/`score` tests **and** the failing gate self-test land BEFORE the implementation. RED proofs recorded (logic-RED, not import-RED).
 - **No store-schema change:** `SCHEMA_VERSION` stays 1; `TrendRecord` untouched; no data migration.
 - **Domain-general:** de-niche guard (Section 17) stays green; no vendor/sector tokens enter the edited `trend-spotter.md` prose.
 - **SSOT discipline:** `trend-scoring-modes.md` remains the human source of truth; `score.ts` mirrors it; a test pins **the exact per-mode weights, the four band thresholds (8.0/6.0/4.0/2.0), and the ten band action strings** against the SSOT values, and asserts each mode sums to 1.0 — so silent drift in *any* of them (not just the weights) fails loudly. (A markdown-parsing cross-check of the SSOT table itself is deferred — out of scope.)
 - **House conventions:** ESM + `node:test` + `tsx`; data-seam stays inline (no new shared util — the documented idiom); no new `.mjs` under `hooks/scripts/`; `.gitignore` already covers `scripts/trends/{node_modules,build}`.
 - **No new `references/*.md`** (would trip the named-additions guard) and **no new agent/command** (counts stay 19/29/27). Brief+plan live under `docs/` (uncounted), TRACKED like `docs/second-brain/*` (general feature design).
 - **Counts recounted live at land**, never pinned/guessed.
 ## 6. Success criteria (testable)
 - **SC1** — `normalizeItem` returns a canonical item from a well-formed raw item; a missing/empty required field returns a structured `{ok:false}` error naming the field (not a silent partial); whitespace + topic dedupe applied; `publishedAt` validated-if-present, undefined-if-absent. `normalizeItems` partitions a batch into `{items, errors}`.
 - **SC2** — `composite()` equals the SSOT formula exactly for both modes: all-tens → **10.0** (proves Σweights=1), and the **asymmetric golden vector `{10, 8, 6, 4, 2}` (in dimension order) → 7.0** for both modes (`10·.30 + 8·.25 + 6·.20 + 4·.15 + 2·.10`) — asymmetric so a weight↔dimension transposition is caught; a dimension outside [1,10] throws.
 - **SC3** — `band()` returns the correct priority + **the exact mode-appropriate action string** (pinned against the SSOT) at every boundary (8.0, 6.0, 4.0, 2.0 edges).
 - **SC4** — `triage()` keeps composite ≥ threshold, drops below, ranks kept composite-desc, annotates each kept item with composite + band.
 - **SC5** — CLI `normalize`/`score` read JSON from stdin, emit valid JSON; exit **2** on a malformed invocation (missing flag / unparseable stdin), **0** on a well-formed call (content-invalid items reported in the payload, never via exit code).
 - **SC6** — `(cd scripts/trends && npm test)` green at the bumped floor; gate's new unconditional section green; `ASSERT_BASELINE_FLOOR` bumped to the live recount; overall gate `FAIL=0`.
 - **SC7** — `trend-spotter.md` references the scorer for the deterministic step (gate grep green); de-niche guard green; structure counts unchanged (19/29/27).
 ## 7. Verification
 **Deterministic (gate):** `bash scripts/test-runner.sh` → `FAIL=0`; trends suite ≥ new floor; new self-test + wiring-grep pass; Section 17 de-niche green; ref/agent/command counts unchanged.
 **Behavioural (manual):** run `npm run start -- normalize --json '<sample batch>'` and `... score --json '<scored sample>' --mode kortform --threshold 4.0`; eyeball that kept/dropped/bands match a hand-computed expectation on 3–4 items.
 ## 8. Open questions for the go-gate
 1. **Default threshold.** Propose **4.0** — the SSOT's Medium-band floor and the agent's existing "score 4.0+" angle-mapping cutoff (`trend-spotter.md:179,274`). Confirm or set otherwise.
 2. **Vocabulary `topics` vs `tags`.** The concepts doc envelope says `tags`; the codebase standardized on `topics`. Propose **keep `topics`** (consistency, no rename) and note `tags ≡ topics`. Confirm.
 3. **CLI tests now?** Trends has no `cli.test.ts` today; siblings (brain, contract-gate) do. Propose **add light cli tests** for the two new subcommands (happy path + exit codes). Confirm vs defer.
 4. **Wire `trend-spotter.md` now?** Propose **yes** — a prose pointer so the lift is real and gate-grep-able; full orchestration (fan-out, brief assembly) stays R2.
 ## 9. Light-Voyage review — folded
 Three Opus reviewers ran on the drafts. **scope-guardian: ALIGNED** (every SC1–SC7 traces to a step; zero scope creep; NON-goals fully respected). **brief-reviewer: PROCEED_WITH_RISKS.** **plan-critic: REVISE (1 blocker, 6 majors).** All findings folded:
 - **[BLOCKER, folded]** `TrendItem`→`TrendInput` does not map directly — live `TrendInput` requires `capturedAt` and has no `publishedAt`; the item has the opposite. → §3 B1 now scopes R1 to the validated envelope only; the item→store bridge (`capturedAt` injection, `publishedAt` persistence) is **R2**. A scope-tightening, not an addition.
 - **[MAJOR, folded]** CLI `--json` is already an *output* toggle → §3 now reads payload from **stdin**, `--json` untouched.
 - **[MAJOR, folded]** Gate-section placement + anti-erosion-last → §3 pins **Section 16g, before Section 18**; `TRENDS_TESTS_FLOOR` stays inside the deps guard.
 - **[MAJOR, folded]** `ASSERT_BASELINE_FLOOR` was pinned to 86 against the recount-live rule, and the house self-test pattern makes it +3 → §3 now says **live recount (~+3), not pinned**.
 - **[MAJOR, folded]** Only weights were drift-guarded → §5 SSOT discipline now pins **weights + band thresholds + the ten action strings**.
 - **[MAJOR, folded]** Wiring grep literal unpinned → §3 pins `grep -qF "src/cli.ts score"`.
 - **[testability, folded]** SC2 unnamed vector → **pinned `{10,8,6,4,2}`→7.0**; SC5 exit-code ambiguity → **explicit 2-vs-0 contract**; `id` hedge → **envelope carries no id**; `normalizeItems` batch shape → **SC1 extended**.
 - **[minor, folded in plan]** RED-stub split per assertion type; explicit `node --import tsx` invocation (not `npm run start`); commit grouping fixed; STATE.md noted as land-bookkeeping; `config/trends-sources.template.md` added to the scope fence.
 See `plan-re-r1.md` §Plan-critic — folded for the per-step resolution.
--- a/docs/research-engine/brief-re-r2a.md
+++ b/docs/research-engine/brief-re-r2a.md
@ -1,208 +0,0 @@
 # Brief — RE-R2a: capture bridge (item→store) + publishedAt persistence
 > **Slice:** RE-R2a (research-engine rung-2, slice 2 — the data layer of R2). The first of the two
 > halves R2 ("the visible topic-stream") was split into at the 2026-06-24 go-gate: **R2a** = the pure
 > `scripts/trends/` data layer (this brief); **R2b** = the dated morning-brief artifact + session-start
 > surfacing (separate brief, after R2a lands). The split was chosen because (b)+(c) are code-independent
 > of (a), R2a mirrors R1's pure-TDD shape exactly (lowest risk), and it closes the capture loop the store
 > was built for.
 > **Predecessor:** RE-R1 (`brief-re-r1.md`) delivered the validated ingress envelope (`item.ts`:
 > `normalizeItem`/`normalizeItems`) and the triage scorer (`score.ts`) behind a CLI seam, and **explicitly
 > deferred the item→store bridge** ("injecting the store's `capturedAt` and persisting `publishedAt` — is
 > R2 orchestration", `brief-re-r1.md` §3 B1). R2a builds exactly that deferred bridge.
 > **Substrate:** `docs/research-engine-concepts.local.md` §1 (hull 3 "store-schema mangler felt" / the
 > item→store gap), §3 B1 (one schema downstream never branches on). **TDD-order:** RED tests land before code.
 ## 1. Operator decision context (2026-06-24)
 The research engine is **Tier-1** (operator, 2026-06-23): *"hele min arbeidsflyt hviler på at jeg får en
 jevn strøm av gode forslag til tema å skrive om."* At the R2 go-gate (2026-06-24) the operator chose to
 build R2 as **two sequenced slices, foundation-first**: R2a (this — the bridge + schema, pure trends/) before
 R2b (the visible brief + surfacing). R2a delivers no *visible* change; it closes the capture loop so the
 store accumulates publish-dated history that R2b's brief and R3's freshness window will rank on.
 ## 2. The gap — grounded in code
 - **`normalize` (R1) and the store are disconnected.** `item.ts` validates a raw source item into the
  canonical `TrendItem` envelope `{source,title,url,publishedAt?,topics[],summary?}` (`item.ts:21-38`), but
  **nothing folds that envelope into the store.** The only ingress to the store is `cli.ts add` (`cli.ts:111-135`),
  which builds a `TrendInput` from raw flags — it never calls `normalizeItem`, so a capture path that polls →
  normalizes → stores **does not exist**. The bridge is the missing link R1 named and deferred.
 - **`publishedAt` is carried but dropped.** The envelope carries the source's own publish date
  (`item.ts:28-33`, "NOT persisted in R1"), but `TrendRecord` (`types.ts:26-41`) has no `publishedAt` field and
  `addTrend` (`store.ts:111-130`) never persists it. So every capture **loses** the publish date — the field
  B4 freshness (R3) and R2b's "fresh today" sort will both need. R2a persists it now, before history accumulates
  undated, so the loop is publish-dated from this slice forward.
 - **`SCHEMA_VERSION` is pinned at 1 with no migration path exercised.** `loadStore` (`store.ts:74-81`) reads
  `parsed.schemaVersion ?? SCHEMA_VERSION` but the store has never had a second version, so the forward-migration
  path is untested. Adding `publishedAt` is the first additive-optional schema bump (v1→v2) and the right moment
  to prove a lossless migrate-on-load.
 ## 3. Scope — what is IN (RE-R2a)
 ### B-bridge — `itemToInput` (pure mapping, `scripts/trends/src/item.ts`, EDIT)
 A pure `itemToInput(item: TrendItem, capturedAt: string): TrendInput` that maps the validated envelope to a
 store input by **injecting `capturedAt`** (the store's "when WE saw it", supplied by the caller — never derived
 inside the pure function) and **carrying `publishedAt`/`topics`/`summary`/`title`/`url`/`source` through verbatim**.
 It does **not** re-validate (the item is already validated by `normalizeItem`) and does **not** derive an `id`
 (the store owns id via `addTrend`→`trendId`). Lives in `item.ts` (it is the item's mapping to the store; `item.ts`
 already imports from `store.ts`) — **not** a new single-function `bridge.ts` (single-use abstraction).
 ### Schema migration — `publishedAt` persisted (`types.ts` + `store.ts`, EDIT)
 - `types.ts`: `SCHEMA_VERSION 1 → 2`; add `publishedAt?: string` to `TrendRecord` (after `capturedAt`), with a
  comment distinguishing it from `capturedAt` (source publish-date; forward-compat for B4 freshness).
 - `store.ts`: `TrendInput` gains `publishedAt?: string`; `addTrend` persists it when present (same
  conditional-spread idiom as `summary`, `store.ts:126`). **On re-capture/merge it is NOT overwritten** —
  it joins the store's documented "FIRST sighting's source + capturedAt are kept (provenance of first sight)"
  rule (`store.ts:108-110`); no back-fill (a deferred enhancement, §4).
 - `loadStore`: **forward migrate-on-load** — stamp the in-memory store to `Math.max(onDisk, SCHEMA_VERSION)`,
  where `onDisk = typeof parsed.schemaVersion === "number" ? parsed.schemaVersion : SCHEMA_VERSION` (a string /
  `NaN` / absent version falls back to current, never crashes). v1→v2 is purely additive-optional (old records are
  already valid v2 records that simply lack the optional field), so the migration is the stamp alone — **no record
  rewrite; lossless + idempotent for any well-formed v1/v2 store**. A subsequent `saveStore` persists the v2 stamp.
  **The existing non-array `trends` coercion (`store.ts:79`, `Array.isArray(parsed.trends) ? … : []`) is UNCHANGED
  and out of R2a's migration scope** — losslessness is claimed only for well-formed stores, not for a corrupt
  `trends` field. (No downgrade branch: a hypothetical future on-disk > current can't happen yet — Karpathy #2, no
  handling for impossible scenarios; noted as a deferred risk.)
 ### CLI `capture` subcommand (`scripts/trends/src/cli.ts`, EDIT)
 `echo '<raw item | batch>' | node --import tsx src/cli.ts capture [--store <path>] [--json]` — reads the raw
 JSON payload **from stdin** (same stdin contract as `normalize`/`score`, so `--json` stays an *output* toggle),
 runs it through `normalizeItem`/`normalizeItems`, maps each valid item via `itemToInput(item, today())`, folds
 each into the store via `addTrend`, and `saveStore`s once. Emits a summary — `{added, duplicates, merged, errors}`
 + store path/count — human-readable by default, JSON with `--json`. Content-invalid items are reported in the
 summary (`errors[]`), **never via the exit code**; exit **2** only on a malformed invocation (unparseable/empty
 stdin), matching `normalize`/`score`. Note the contract difference from `add`: `capture` items must carry `source`
 (the normalizer requires it — no "manual" default), because a capture is from a real source.
 ### Wiring + gate (see Open Question #1 — included by default, trimmable to minimal)
 - `agents/trend-spotter.md` (EDIT): re-point **Step 4.5** (`trend-spotter.md:282-301`) from N× flag-based `add` to
  a single batch `capture` — the agent builds a raw-item JSON batch (it already builds JSON for `score`) and pipes
  it to `capture` in one call. Strictly better than `add` (it normalizes + carries `publishedAt`; one call, not N).
  The replacement prose carries the literal `src/cli.ts capture`. Kept domain-general (no vendor/sector tokens).
 - `scripts/test-runner.sh` (EDIT): bump `TRENDS_TESTS_FLOOR` (62 → **live recount**, stays inside the deps guard).
  Add **Section 16h** ("Trends Capture Wiring"), mirroring Section 16g's three-check shape, placed **after Section
  17 / before Section 18** (anti-erosion last): (1) a non-vacuity self-test; (2) `grep` that `cli.ts` has a `capture`
  handler (deps-absent proof the path exists); (3) `grep -qF "src/cli.ts capture" agents/trend-spotter.md`. These are
  **unconditional** → bump `ASSERT_BASELINE_FLOOR` 87 → **live recount** (expected ~90).
 ## 4. Non-goals — what is OUT (deferred)
 - **The dated morning-brief artifact (B3)** — R2b. *R2a closes the capture loop; R2b makes the stream visible.*
 - **Session-start surfacing** of the brief (hull 4) — R2b. R2a does **not** touch `hooks/**`.
 - **`publishedAt` back-fill on re-capture** (fill an absent existing `publishedAt` from a later sighting) — deferred;
  first-sight provenance is kept, matching the existing merge rule. Revisit if undated-first-sight proves common.
 - **`add --published-at` flag** — deferred (was a proposed "minor"; folded out at light-Voyage). The flag-based
  `add` is the *manual* single-trend path; it stays publish-date-free for now. The store layer still GAINS
  `publishedAt` (on `TrendInput` + `addTrend`) — that is what `capture` needs — but exposing it on the `add` CLI
  (and the `isValidIso`-export-vs-inline decision it would force) is out of R2a. Trivial to add any later slice.
 - **`relevance` / `saturation` / `status` / lifecycle fields** (hull 5) — R3. R2a adds **only** `publishedAt`.
 - **Freshness window / dedup-vs-seen-log / autonomous trigger (B4)** — R3.
 - **Research-deepening (A1–A4), adapter sub-agents, MCP fetch fan-out** — R2b/R3.
 - **A store-reading brief / ranking on accumulated relevance** — R2b/R3 (needs persisted scores).
 ## 5. Boundaries / invariants (must hold)
 - **TDD iron law:** the failing migration / `itemToInput` / `capture` tests land BEFORE the implementation.
  RED proofs recorded (logic-RED, not import-RED). **NB:** only the **v1→v2** load + round-trip are genuinely RED
  (old `loadStore` returns 1); v2-idempotence + missing/non-numeric-`schemaVersion` pass against old code, so they
  are **GREEN-only regression guards**, not RED cases (see plan Step 1).
 - **Lossless migration (well-formed stores):** every existing **well-formed** v1 store loads as v2 with **records
  intact** (no `publishedAt` invented, no topic/summary/capturedAt/url/title change); idempotent (v2 → v2). A
  corrupt `trends` field is coerced by the existing (unchanged) `Array.isArray` guard — explicitly **out of R2a's
  losslessness claim**, not a regression introduced here.
 - **First-sight provenance preserved:** re-capturing an existing trend never overwrites its `publishedAt`,
  `capturedAt`, or `source` — only topics union (unchanged from R1).
 - **No scoring change:** `score.ts` and `references/trend-scoring-modes.md` (the SSOT) are untouched — R2a is the
  data layer, not the scorer.
 - **Domain-general:** de-niche guard (Section 17) stays green; no vendor/sector tokens enter the edited
  `trend-spotter.md` prose.
 - **House conventions:** ESM + `node:test` + `tsx`; data-seam stays inline; **no new `.mjs` under `hooks/scripts/`**
  (R2a touches no hook); `.gitignore` already covers `scripts/trends/{node_modules,build}`.
 - **No new `references/*.md`**, **no new agent/command** (counts stay 19/29/27); no new `.ts` source file
  (bridge lives in `item.ts`). Brief+plan live under `docs/` (uncounted), TRACKED like `docs/second-brain/*`.
 - **Counts recounted live at land**, never pinned/guessed.
 ## 6. Success criteria (testable)
 - **SC1 (bridge)** — `itemToInput(item, "2026-06-24")` returns a `TrendInput` with `capturedAt` injected (`=== "2026-06-24"`),
  `publishedAt`/`topics`/`summary`/`title`/`url`/`source` carried verbatim, and **no `id`**. Absent `publishedAt`
  on the item → absent on the input (key omitted, not `undefined`-valued). **Field-confusion guard:** for an item
  whose `publishedAt` differs from the injected `capturedAt`, the result's `capturedAt !== result.publishedAt`
  (proves the bridge never confuses the two dates — the whole point of the slice).
 - **SC2 (persist)** — `addTrend` with a `publishedAt` persists it on the new record; a record without it omits the
  key. On a re-capture (same title+url) the existing `publishedAt` is **unchanged** (first-sight kept), and only
  topics union — `merged` reflects topic change alone. **No back-fill:** a re-capture carrying a `publishedAt` onto
  a record that **lacked** one does **not** add it (Open Q#2) — the absent→present case is the one where "first-sight
  kept" is counterintuitive, so it is pinned by a test.
 - **SC3 (migrate)** — `loadStore` on a v1 store fixture (`{schemaVersion:1, trends:[…without publishedAt]}`) returns
  `schemaVersion === 2` with every record intact and **no `publishedAt` invented**. Also pinned: a store with
  **missing** `schemaVersion` → stamped 2 (records intact); an **empty/absent** store → `{schemaVersion:2, trends:[]}`;
  a **non-numeric** `schemaVersion` (`"weird"`/`NaN`) → falls back to 2 (records intact); idempotent on a v2 store;
  a round-trip `loadStore`→`saveStore` writes `schemaVersion: 2`.
 - **SC4 (capture CLI)** — `echo '<batch>' | … capture` normalizes + folds: a well-formed item is added (or reported
  duplicate/merged), a content-invalid item appears in the summary `errors[]`, the store file is written once, and
  the summary counts are correct — **`added + merged + duplicates + errors.length === payload.length`** (the tally
  is derived from `AddResult {added, merged}`, which has no `duplicates` field: `added`=`res.added`,
  `merged`=`!res.added && res.merged`, `duplicates`=`!res.added && !res.merged`). The captured record's `capturedAt`
  is a today-shaped ISO date **distinct from the item's `publishedAt`** (field-confusion guard at the ingress; the
  exact-value assertion lives in `item.test.ts` with an injected date, since `capture` reads the wall clock). Exit
  **2** on empty/unparseable stdin; **0** on a well-formed call even with content-invalid items. `--json` emits the
  summary object.
 - **SC5 (gate)** — `(cd scripts/trends && npm test)` green at the bumped `TRENDS_TESTS_FLOOR`; new Section 16h green;
  `ASSERT_BASELINE_FLOOR` bumped to the live recount; overall gate `FAIL=0`.
 - **SC6 (wiring + de-niche)** — `trend-spotter.md` references `src/cli.ts capture` (Section 16h grep green); de-niche
  guard (Section 17) green; structure counts unchanged (19/29/27). *(If Open Q#1 → minimal: SC6 drops the wiring/16h
  clauses; de-niche + counts still asserted.)*
 ## 7. Verification
 **Deterministic (gate):** `bash scripts/test-runner.sh` → `FAIL=0`; trends suite ≥ new floor; new Section 16h
 self-test + greps pass; Section 17 de-niche green; ref/agent/command counts unchanged.
 **Behavioural (manual):** `echo '<2-item batch incl. one publishedAt + one invalid>' | node --import tsx src/cli.ts
 capture --store /tmp/r2a-trends.json --json`; confirm the valid item lands with `publishedAt` persisted, the invalid
 one is in `errors[]`, and `node … list --store /tmp/r2a-trends.json --json` shows the persisted `publishedAt`.
 Then load an authored v1 fixture and confirm `status --json` reports it migrated (count intact).
 ## 8. Open questions for the go-gate
 1. **Wire `trend-spotter.md` + add Section 16h, or keep R2a minimal? — RESOLVED at go-gate (operator, 2026-06-24): WIRE.**
   Build R2a with the agent re-point (Step 4.5 `add`→`capture`) + Section 16h grep/self-test + ASSERT-floor bump. The
   minimal alternative (bridge code + tests only, no agent edit) was declined — wiring mirrors R1's "the lift is real
   and grep-able" discipline and makes the bridge actually used (one normalizing `capture` vs N× `add`).
 2. **`publishedAt` merge policy.** Proposed **keep first-sight** (no back-fill), matching the existing source/capturedAt
   provenance rule (now pinned by the absent→present SC2 test). Confirm, or request back-fill-if-absent (adds a branch
   + a `merged` semantic question).
 3. **`add --published-at` flag — RESOLVED at light-Voyage: deferred** (see §4). The manual `add` stays publish-date-free;
   `capture` is the path that carries `publishedAt`. Noted here only so the resolution is traceable; no go-gate action.
 ## 9. Light-Voyage review — folded
 Three Opus reviewers ran on the drafts, each verifying claims against live code. **scope-guardian: ALIGNED**
 (every SC1–SC6 traces to a step; zero creep; all §4 non-goals held; 2 minors). **brief-reviewer:
 PROCEED_WITH_RISKS** (2 majors, 4 minors). **plan-critic: REVISE** (1 blocker, 5 majors, 5 minors). All findings
 folded; see `plan-re-r2a.md` §Plan-critic — folded for the per-step resolution:
 - **[BLOCKER, folded]** "v2 load idempotent" cannot be a RED case — old `loadStore` (`store.ts:78`) returns
  `parsed.schemaVersion ?? SCHEMA_VERSION`, so a v2 fixture already loads as 2 against unchanged code. → §6 SC3 +
  §5 now split the migration cases: **only v1→2 + round-trip are RED**; v2-idempotence + missing/non-numeric are
  **GREEN-only regression guards**.
 - **[MAJOR, folded]** "lossless / byte-for-byte intact" over-claimed vs `loadStore`'s non-array `trends` coercion
  (`store.ts:79`). → §5 + §3 scope losslessness to **well-formed** v1/v2 stores; the coercion is unchanged + out of
  scope (not a regression).
 - **[MAJOR, folded]** `capturedAt` injection unverified at the new `capture` ingress (the field-confusion the slice
  exists to prevent). → SC1 + SC4 now pin `capturedAt !== publishedAt` (item.test exact-value; cli.test shape +
  distinct).
 - **[MAJOR, folded]** `capture` tally `{added, duplicates, merged}` mis-maps onto `AddResult {added, merged}` (no
  `duplicates` field). → SC4 pins the exact derivation + `sum === payload.length`.
 - **[MAJOR, folded]** `add --published-at` validation referenced the non-exported `isValidIso` (`item.ts:51`). →
  **`add --published-at` deferred entirely** (§4), removing the export-vs-inline decision and keeping `item.ts`'s
  edit to `itemToInput` only.
 - **[MAJOR, folded]** README "Capture … `add`" framing would contradict the agent's `add`→`capture` re-point. →
  plan Step 5 now corrects the README framing (`add` = manual single-trend; `capture` = normalizing batch), not just
  appends.
 - **[MAJOR, folded]** empty "folded" placeholders shipped in the doc bodies. → this section + plan §Plan-critic now
  filled.
 - **[MINOR, folded in plan]** missing-/non-numeric-`schemaVersion` test, absent→present back-fill test, stub-replacement
  note, `import type { TrendInput }` line, `grep -qF` for the 16h literal, `TRENDS_TESTS_FLOOR` breakdown-comment update,
  README in the code commit, headless per-step clauses N/A (in-session execution).
--- a/docs/research-engine/brief-re-r2b.md
+++ b/docs/research-engine/brief-re-r2b.md
@ -1,309 +0,0 @@
 # Brief — RE-R2b: dated morning-brief artifact + session-start surfacing
 > **Slice:** RE-R2b (research-engine rung-2, slice 2 — the *visible* layer of R2). R2 ("the visible
 > topic-stream") was split at the 2026-06-24 go-gate into **R2a** (the pure `scripts/trends/` data layer —
 > capture bridge + `publishedAt` persistence, landed `7a15803`) and **R2b** (this — the dated morning-brief
 > artifact + session-start surfacing). R2a delivered **no visible change**; it closed the capture loop so the
 > store now accumulates publish-dated history. R2b makes that stream visible: a deterministic, dated Markdown
 > brief ranked over the store, surfaced at session-start.
 > **Predecessor:** RE-R2a (`brief-re-r2a.md`) persisted `publishedAt` first-sight and shipped the `capture`
 > CLI; it **explicitly deferred** the dated brief artifact (B3) and session-start surfacing (hull 4) to R2b
 > (`brief-re-r2a.md` §4). R2b builds exactly those two deferred pieces.
 > **Substrate:** `docs/research-engine-concepts.local.md` §3 **B3** (dated-digest as a flat plain-text
 > artifact: `YYYY-MM-DD.md`, diffbar/grep-bar/lastbar; delivery is a separate later step) + **hull 4**
 > (surfacing at session-start) + §1 hull list (2)(4)(7). **TDD-order:** RED tests land before code.
 ## 1. Operator decision context (2026-06-24)
 The research engine is **Tier-1** (operator, 2026-06-23): *"hele min arbeidsflyt hviler på at jeg får en jevn
 strøm av gode forslag til tema å skrive om."* At the R2 go-gate the operator chose foundation-first: R2a (the
 bridge + schema) before R2b (the visible brief + surfacing). **R2b is the slice that delivers the visible
 value** — the operator opens a session and *sees* a dated brief of fresh, on-pillar topic signals, without
 running anything. The autonomous nightly trigger that would *regenerate* it unattended stays R3 (hull 1); in
 R2b the brief is produced **on demand** (a trend scan, or the `brief` CLI) and **surfaced** whenever one
 exists. Confirmed at format sign-off (2026-06-24): **D1** on-demand generation + session-start surfaces the
 latest (no tsx in the hook to regenerate); **D2** deterministic ranking on pillar-overlap → recency (no AI /
 no `score.ts` in the brief path — scores aren't persisted yet); **D3** freshness window = 7 days.
 ## 2. The gap — grounded in code
 - **The store accumulates publish-dated history nobody reads.** Post-R2a, `TrendRecord` carries
  `publishedAt?` (`types.ts:43`) and the `capture` CLI folds polled trends in (`cli.ts:237-263`), but **no
  artifact ranks or presents the accumulated store.** The read surfaces today are `query` (topic-scoped,
  `cli.ts:143-164`) and `list` (time-scoped, `cli.ts:166-185`) — both are interactive CLI dumps, neither is a
  persisted, dated, surfaced brief. The "morgen-brief" rung the engine is aimed at (substrate §1, hull 2) does
  not exist.
 - **`publishedAt` is persisted but never ranked on.** `queryByTopic` ranks `topicOverlap desc → capturedAt
  desc` (`store.ts:155-157`) — it sorts on *when WE saw it*, never on *when the source published*. So even the
  freshest source item is ordered by capture time, not publish time. The field R2a persisted specifically for
  freshness ranking has no reader. R2b's `rankForBrief` is that reader.
 - **Session-start surfaces staleness, not signal.** The SessionStart hook already reads the store directly
  (zero-tsx) for the B-S3 staleness *nudge* (`session-start.mjs:38-52, 376-380`) — "trend signals are N days
  old, scan to refresh." It tells the operator the store is *stale*; it never tells them *what is in it*.
  Hull 4 (surfacing the actual brief) is unbuilt — the seam (a direct store/data-dir read in the hook) is
  already proven and reusable.
 ## 3. Scope — what is IN (RE-R2b)
 ### B-rank + B-render — `scripts/trends/src/brief.ts` (NEW `.ts`)
 Two **pure** functions + the brief's own format-version const + its result types. A new module is justified
 (cohesive brief layer — ranking + rendering + types — not a single-use function; contrast R2a's `itemToInput`,
 which belonged inside `item.ts`). No fs, no clock, no AI: `today` and `pillars` are injected by the caller.
 - `rankForBrief(store: TrendStore, pillars: string[], today: string, opts?: { freshDays?: number }): BriefRanking`
  — for each trend computes `overlap` (count of `pillars` present in `trend.topics`, **case-insensitive, the
  same idiom as `queryByTopic` `store.ts:151-152`** — computed inline, `queryByTopic` is NOT refactored),
  `matchedPillars` (the actual matched names), `effectiveDate = publishedAt ?? capturedAt`, and
  `ageDays = Math.floor((Date.parse(today) - Date.parse(effectiveDate)) / 86400000)` (a **local** day-delta,
  **not** imported from `cli.ts`'s `daysBetween` `cli.ts:107-109` — that would invert the dependency direction,
  since `cli.ts` imports `brief.ts`, not the reverse). Groups: **`topMatches`** (`overlap ≥ 2` AND `ageDays ≤
  freshDays`), **`singleMatches`** (`overlap === 1` AND fresh), **`olderMatched`** (`overlap ≥ 1` AND NOT
  fresh). `overlap === 0` is **excluded entirely** (off-pillar noise). Within each group: sort `overlap desc`,
  then `effectiveDate desc` (freshest first), then `title asc`, then **`url asc`** — a **total order** (two
  records can share title+effectiveDate+overlap but never title+url, since title+url is the dedupe id
  `store.ts:66-68`; the `url` key makes order independent of store insertion / V8 sort stability). Returns
  `{ today, freshDays, totals: { trends, matched, fresh }, topMatches, singleMatches, olderMatched }`.
  `freshDays` default **7** (D3).
 - `renderBrief(ranking: BriefRanking): string` — produces the full Markdown artifact: a YAML frontmatter block
  (`date`, a one-line **`summary`** the hook surfaces verbatim, `store: { trends, matched, fresh }`, a
  `ranking:` descriptor, `schemaVersion: <BRIEF_SCHEMA_VERSION>`) + the body. **Body entry line (pinned):**
  `### <n>. <title>` then ``- Kilde: <source> · Publisert: <effectiveDate> (<ageDays>d) · Pillarer: <matched,
  joined> `` then optional summary then `🔗 <url>` (single-matches/older render as one-line bullets:
  `- <title> — «<pillar>» · <effectiveDate> (<ageDays>d) · 🔗 <url>`). The empty case (no fresh matches) still
  renders a valid brief with a "no fresh on-pillar signals" `summary`. The frontmatter `summary` is produced by
  the shared **`briefSummary(ranking)`** (below), NOT re-derived — one source for the frontmatter line and the
  CLI `--json`. **Deterministic:** same `(store, pillars, today, freshDays)` → byte-identical output (total-order
  sort, no clock/env inside the pure functions).
 - `briefSummary(ranking: BriefRanking): string` — the **single** source of the one-line summary, used by
  `renderBrief` (frontmatter) AND the CLI `--json`. Output is a **single line, column-0 in frontmatter, with no
  embedded `"` and no newline** (titles in «», fields separated by `·`) — so the hook's `extractYaml` regex
  (`^summary: *"?([^"\n]*)"?`, `session-start.mjs:20`) captures it whole. Fresh>0 →
  `<fresh> ferske tema-signaler matcher pillarene dine. Topp: «<top title>» (<top pillar> · <age>d).`;
  else → `Ingen ferske tema-signaler på pillarene dine (av <trends> i lager).`
 - `defaultBriefDir(): string` — **derives from `defaultStorePath()`** (`store.ts:190-193`): `join(dirname(
  defaultStorePath()), "morning-brief")` → `<root>/trends/morning-brief`. **One** root resolution (reuses
  `defaultStorePath`, imported from `store.js`); no independent re-resolution of `LINKEDIN_STUDIO_DATA` in
  `brief.ts` (M4 — kills the duplication the first draft introduced). Colocated with the store the brief reads
  (Open Q#2). Pure path computation, no fs.
 - `BRIEF_SCHEMA_VERSION = 1` — the artifact format version (distinct from the store's `SCHEMA_VERSION`).
 ### CLI `brief` subcommand (`scripts/trends/src/cli.ts`, EDIT)
 `node --import tsx src/cli.ts brief [--pillars <a,b,c>] [--fresh-days <N>] [--store <path>] [--out <dir>]
 [--json]` — flag-driven (reads the **store**, not stdin — unlike `normalize`/`score`/`capture`). Resolves
 `pillars = splitTopics(flags.pillars)` (the caller supplies the user's pillars — same edge-injection pattern as
 `capture` injecting `today()`; resolving pillars from the profile is a thin caller concern, §4), `freshDays`
 from `--fresh-days` (default 7; non-numeric → `usage()`→exit 2, mirroring `--limit`/`--threshold`), `store =
 loadStore(storePath)`, `outDir = flags.out && flags.out !== "true" ? flags.out : defaultBriefDir()` (the
 `!== "true"` guard is **required** — a bare `--out` with no value yields the string `"true"` via `parseFlags`
 `cli.ts:52-53`, so `flags.out ?? …` would write to `./true/`). Runs `rankForBrief(store, pillars, today(),
 { freshDays })` → `renderBrief(ranking)` → writes `<outDir>/<today()>.md` (`mkdirSync({recursive})` +
 `writeFileSync` at the CLI edge — `brief.ts` stays pure). Human output: the written path + `(M matched, K
 fresh)`; `--json` emits `{ path, date, totals, summary }` where `summary = briefSummary(ranking)` (the **same**
 source as the frontmatter). Exit **2** only on malformed invocation; **0**
 otherwise, **including empty `--pillars`** (writes a valid no-match brief — the operator who hasn't set pillars
 still gets a dated, surfaceable file telling them to set pillars). Add a `brief …` line to `usage()` and the
 header doc comment.
 ### Session-start surfacing (`hooks/scripts/session-start.mjs`, EDIT — zero-tsx)
 A module-private `latestMorningBrief(briefDir)` (mirroring `trendsNewestCapture` `session-start.mjs:38-52` and
 `brainLastRun` `:57-65`): absent dir → `null`; else `readdirSync` → keep `/^\d{4}-\d{2}-\d{2}\.md$/` → sort
 desc → read the newest → extract `date` + `summary` via the existing `extractYaml` (`:19-23`) → return
 `{ date, summary, file }` (or `null` on any read failure — never throws). `extractYaml`'s capture is
 `[^"\n]*` + `.trim()` (`:20-23`), so the extracted `date`/`summary` are **newline-free by construction** →
 the surfaced block needs **no** `.replace(/\n/g,'\\n')` treatment (unlike the multi-line state sections
 `:320`); the static structure uses the literal `\\n` idiom (`:309-321`). **Pure fs + regex; never spawns
 `tsx`** (the analytics fresh-clone-crash invariant; the store schema/brief frontmatter are stable, so a direct
 read is safe — identical reasoning to the B-S3 comment `:32-37`). Injected as its own block **after the
 brain-missing nudge (`:500-504`)**, unconditional on a brief existing (so it surfaces on the fresh-install
 branch too, like the brain nudge): `## Morning Brief (<date>)` + the `summary` + `→ Full brief: <file>`. The
 brief dir is `join(getDataRoot('trends'), 'morning-brief')` — the **twin** of `defaultBriefDir()` (same
 established pattern as the store-path twin, `:376`). Heading kept English to match the existing 14 hook
 sections (Open Q#3); the `summary` body stays Norwegian (operator-facing).
 ### Wiring + gate (Open Q#1 — WIRE by default, mirrors R2a Open Q#1)
 - `agents/trend-spotter.md` (EDIT): after the Step 4.5 `capture` (re-pointed in R2a), add a step that runs
  **`node --import tsx scripts/trends/src/cli.ts brief --pillars <the pillars the agent already scans>`** so a
  trend scan *produces* today's dated brief — closing the visible loop **scan → capture → brief → surfaced next
  session**. Replacement prose carries the literal `src/cli.ts brief`. Domain-general (pillars are the user's
  config; no vendor/sector tokens). Keep the "skip silently if no deps" escape hatch.
 - `scripts/trends/README.md` (EDIT): document the `brief` subcommand + the `trends/morning-brief/YYYY-MM-DD.md`
  artifact + its frontmatter shape (honest CLI/artifact doc).
 - `scripts/test-runner.sh` (EDIT): bump `TRENDS_TESTS_FLOOR` — set it to the `tests N` line reported by
  `(cd scripts/trends && npm test)` after Steps 1–3 (it stays **inside** the deps guard; 79 today, `store.ts`
  comment `:697` is per-slice), and **append** `+ RE-R2b: brief +N + cli +M (morning-brief)` to that inline
  breakdown comment so number and comment can't drift. Add **Section 16i** ("Trends Brief Wiring"): insert it
  **immediately after Section 16h** (currently the **last** section before Section 18 — file order is 17→16g→
  16h→18, `:943/:1010/:1074/:1118`), i.e. after 16h's closing `fi`/`echo ""` (~`:1116`), **before** the Section
  18 block (`:1118`). Mirror 16h's shape: **unconditional**, deps-absent-safe `grep -qF` + a non-vacuity
  self-test — (1) self-test; (2) `command === "brief"` in `cli.ts`; (3) `src/cli.ts brief` in
  `agents/trend-spotter.md`; (4) `latestMorningBrief` in `session-start.mjs` (surfacing is wired, not merely
  documented). These are unconditional → bump `ASSERT_BASELINE_FLOOR` 90 → **live recount** (expected ~94).
  Update the header-enumeration **prose chain** (`:33-46`) by inserting the 16i clause between the 16h clause
  (`:43-45`) and the Section-18 clause (`:46`), preserving sentence flow.
 - **Hook suite (a SEPARATE gate, not run by `test-runner.sh`):** new
  `hooks/scripts/__tests__/session-start-morning-brief.test.mjs` (mirrors
  `session-start-trends-staleness.test.mjs`: subprocess + `LINKEDIN_STUDIO_DATA` fixture), green under
  `node --test hooks/scripts/__tests__/` (the command that runs the 136-test hook suite). `test-runner.sh` has
  no `HOOK_TESTS_FLOOR` and no root `package.json` — so SC6 asserts the hook test under its **own** command,
  never as part of `bash scripts/test-runner.sh`.
 ## 4. Non-goals — what is OUT (deferred)
 - **Autonomous nightly trigger** (cron/launchd, hull 1) — **R3**. R2b's brief is generated on demand (a scan /
  the CLI); the hook only *surfaces* the latest. *No scheduler enters the repo in R2b.*
 - **Freshness as a persisted seen-log / dedup-vs-seen (B4)** — R3. R2b's freshness is a **read-time filter**
  (`effectiveDate ≤ freshDays` at rank time), not an append-only seen-log.
 - **Relevance / saturation / status / first-mover scoring fields (hull 5)** — R3. R2b ranks on **pillar-overlap
  + recency only**; the B2 triage scorer (`score.ts`) stays **out of the brief path** (its output isn't
  persisted on records yet — that's R3). No AI in the brief path (D2).
 - **Research-deepening (A1–A4), adapter sub-agents, MCP fetch fan-out** — R3.
 - **Pillar resolution from the state file** (`expertise_areas`) — OUT; pillars arrive via `--pillars` (the
  agent/caller supplies them). Wiring state→pillars is a thin follow-up, not this slice.
 - **Brief history surfacing / diffing ("yesterday vs today")** — OUT. The artifact is dated and accumulates on
  disk (hull 7 storage is satisfied), but R2b surfaces only the **latest**; diffing is later.
 - **Delivery (Slack/email)** — OUT. B3 keeps delivery a separate step; R2b's only "delivery" is session-start
  surfacing. No delivery channel, no push-window guard (that mechanism is R3/B4).
 - **Store schema change** — none. R2b is **read-only** over the store; `types.ts`/`store.ts` record shape and
  `SCHEMA_VERSION` (2) are untouched (only a pure `defaultBriefDir` path helper is added, in `brief.ts`).
 - **No new agent/command** — counts stay 19/29/27. `brief` is a CLI subcommand; surfacing is a hook edit;
  generation is wired into the existing `trend-spotter`.
 ## 5. Boundaries / invariants (must hold)
 - **TDD iron law:** the failing `brief.ts` tests (`rankForBrief` grouping/freshness/sort + `renderBrief`
  frontmatter/`summary`/empty-case + `defaultBriefDir`) and the `cli.ts brief` tests land **BEFORE** the
  implementation. RED is logic-RED (throwing stub for the not-yet-existing exports so cases fail on assertion,
  not module-not-found).
 - **Purity:** `rankForBrief`/`renderBrief`/`defaultBriefDir` touch no fs, no clock, no env-at-call, no AI —
  `today`/`pillars`/`freshDays` are injected. All fs lives at the CLI edge (`cli.ts`) and in the hook.
 - **Determinism:** same `(store, pillars, today, freshDays)` → byte-identical brief (stable three-key sort).
 - **Hook stays tsx-free:** surfacing is a plain `readdir` + `readFile` + `extractYaml` (the established
  zero-dep pattern); it **never** shells out to `tsx` (analytics fresh-clone-crash invariant). A fixture run
  with no `node_modules/tsx` in `scripts/trends` must still surface the brief (SC5).
 - **Domain-general:** Section 17 de-niche guard stays green; the `trend-spotter.md` edit + the brief artifact
  carry **no vendor/sector tokens**; pillars are the user's config, never hardcoded.
 - **No scoring change:** `score.ts` + `references/trend-scoring-modes.md` (SSOT) untouched.
 - **No store schema change:** `types.ts`/`store.ts` record shape + `SCHEMA_VERSION` unchanged; `queryByTopic`
  NOT refactored (overlap is recomputed in `brief.ts`).
 - **Pathguard:** `brief.ts` is a NEW `.ts` (allowed); **NO new `.mjs` under `hooks/scripts/`** (surfacing edits
  the existing `session-start.mjs`); `.gitignore` already covers `scripts/trends/{node_modules,build}`.
 - **House conventions:** ESM + `node:test` + `tsx`; brief+plan docs live under `docs/` (uncounted, TRACKED like
  `docs/second-brain/*`).
 - **Counts** (refs/agents/commands 27/19/29) unchanged; `brief.ts` is the only new source file. **Recounted
  live at land**, never pinned/guessed.
 ## 6. Success criteria (testable)
 - **SC1 (rank/group)** — `rankForBrief(fixtureStore, pillars, today)` puts only `overlap ≥ 2 & fresh` in
  `topMatches`, `overlap === 1 & fresh` in `singleMatches`, `overlap ≥ 1 & NOT fresh` in `olderMatched`;
  excludes `overlap === 0`; within each group orders `overlap desc → effectiveDate desc → title asc`;
  `matchedPillars` lists the actual matched names (case-insensitive match, original-case pillar preserved);
  `totals.matched` = sum of the three groups, `totals.fresh` = top+single, `totals.trends` = `store.trends.length`.
 - **SC2 (freshness)** — `effectiveDate = publishedAt ?? capturedAt`; an item whose `publishedAt` is within
  `freshDays` but whose `capturedAt` is older is **fresh** (and the reverse via the fallback when `publishedAt`
  is absent); the boundary `ageDays === freshDays` is **fresh** (`≤`); `freshDays` is configurable (a non-7
  value re-buckets).
 - **SC3 (render/frontmatter)** — `renderBrief(ranking)` output begins with a YAML frontmatter block carrying
  `date`, a **column-0, single-line `summary` with no embedded `"` and no newline** (so `extractYaml` reads it
  whole), `store: { trends, matched, fresh }`, and `schemaVersion: 1`; `renderBrief`'s frontmatter `summary`
  equals `briefSummary(ranking)` byte-for-byte (one source); the body has the three sections in order with the
  pinned entry-line shape (§3); the **empty-matches** ranking renders a valid brief whose `summary` is the
  "no fresh on-pillar signals" line (still surfaceable); identical input → identical bytes (determinism, total
  order). `briefSummary(emptyRanking)` returns the no-fresh line; `briefSummary(freshRanking)` names the top
  entry.
 - **SC4 (CLI brief)** — `… brief --pillars a,b --store <tmp> --out <tmpdir>` writes `<tmpdir>/<today>.md`
  (today-shaped `/^\d{4}-\d{2}-\d{2}$/`) and prints the path; `--json` emits `{ path, date, totals, summary }`;
  `--fresh-days xyz` → exit **2**; **empty/absent `--pillars`** → writes a no-match brief, exit **0**; `--out`
  overrides the dir; the default dir (no `--out`) is `defaultBriefDir()`.
 - **SC5 (surfacing)** — running `session-start.mjs` (subprocess) with `LINKEDIN_STUDIO_DATA` pointing at a
  fixture root containing `trends/morning-brief/<date>.md` → `additionalContext` contains `## Morning Brief
  (<date>)`, the brief's `summary`, and `→ Full brief: <file>`, and carries **no raw newline** inside that
  block (single-escaped `\n` idiom held); an absent brief dir → **no** block and **no crash** (`continue:
  true`); the surfacing works with **no `tsx`/`node_modules` present** (zero-dep proof). **Path cross-check:** a
  file written by the CLI at `defaultBriefDir()` (under a given `LINKEDIN_STUDIO_DATA`) is the one the hook
  finds via `join(getDataRoot('trends'),'morning-brief')` — the CLI-write/hook-read paths resolve equal (the
  store-path twin equivalence already guarded by `__tests__/data-root.test.mjs`).
 - **SC6 (gate + wiring + de-niche) — TWO separate gate commands:**
  **(a)** `bash scripts/test-runner.sh` → `FAIL=0`: trends suite green at the bumped `TRENDS_TESTS_FLOOR`; new
  **Section 16i** green (`command === "brief"` in `cli.ts`, `src/cli.ts brief` in `trend-spotter.md`,
  `latestMorningBrief` in `session-start.mjs`, non-vacuity self-test); `ASSERT_BASELINE_FLOOR` = live recount;
  Section 17 de-niche green; counts 27/19/29.
  **(b)** `node --test hooks/scripts/__tests__/` → the new `session-start-morning-brief.test.mjs` green (the
  hook suite is **not** part of `test-runner.sh`).
  *(If Open Q#1 → minimal: SC6(a) drops the `trend-spotter.md`/16i-wire clause; brief.ts + cli + surfacing +
  de-niche + counts still asserted.)*
 ## 7. Verification
 **Deterministic (two gates):** (a) `bash scripts/test-runner.sh` → `FAIL=0`; trends suite ≥ new floor; new
 Section 16i self-test + greps pass; Section 17 de-niche green; ref/agent/command counts unchanged. (b)
 `node --test hooks/scripts/__tests__/` → the new `session-start-morning-brief.test.mjs` green (hook suite is a
 separate command, not part of `test-runner.sh`).
 **Behavioural (manual):**
 1. `echo '[{"source":"tavily","title":"A","url":"https://e/a","topics":["ai","gov"],"publishedAt":"<~2d
   ago>"},{"source":"tavily","title":"B","url":"https://e/b","topics":["ai"],"publishedAt":"<~20d ago>"}]' |
   node --import tsx src/cli.ts capture --store /tmp/r2b.json` (seed the store).
 2. `node --import tsx src/cli.ts brief --pillars ai,gov --store /tmp/r2b.json --out /tmp/r2b-brief --json` →
   confirm A in `topMatches` (overlap 2, fresh), B in `olderMatched` (overlap 1, stale), the written path, and a
   `summary` naming A.
 3. Place that brief at `<root>/trends/morning-brief/<today>.md` and run `LINKEDIN_STUDIO_DATA=<root> node
   hooks/scripts/session-start.mjs` → confirm the `## Morning Brief` block + the `summary` appear in
   `additionalContext`, with `tsx` absent.
 ## 8. Open questions for the go-gate
 1. **Wire `brief` generation into `trend-spotter.md` (after capture) + Section 16i, or keep R2b to
   machinery+surfacing only?** **Recommend WIRE** (mirrors R2a Open Q#1): a scan then *produces* the brief, so
   the surfacing isn't surfacing an artifact nothing creates — it closes the scan→capture→brief→surfaced loop.
   Minimal alt: `brief.ts` + CLI + surfacing + tests, no agent edit (the operator runs `brief` by hand).
 2. **Brief dir = `trends/morning-brief/`** (colocated with the store it reads) — recommend. **Load-bearing**
   (not a cheap toggle): it is baked into `defaultBriefDir()`, the hook twin, and SC5's path assertions.
   Alternatives `research/morning-brief/` (the `docs/research-engine` naming the mock showed) or `morning-brief/`
   at the data-root (substrate §3 B3 literal) would re-touch `brief.ts` + the hook + SC5. Confirm the path; a
   different choice means updating those three places.
 3. **Surfacing heading: English `## Morning Brief`** (matches the existing 14 hook section headings —
   "Posting Reminders", "Queue Summary", "Brain") with a Norwegian `summary` body — recommend. Alt: the mock's
   Norwegian `## 🌅 Morgen-brief`. (The block is `additionalContext` for the model, not direct user UI; the
   user-facing *artifact* body stays Norwegian either way.) The one genuinely-cosmetic question here.
 4. **`summary:` frontmatter field on the artifact** — **confirm** (this is a decision baked in, not a free
   choice): the entire zero-tsx surfacing (SC3/SC5, `extractYaml(content,'summary')`) depends on it; without a
   `summary` frontmatter line the hook would have to parse the body (which the no-tsx invariant forbids), so the
   slice cannot ship without it. The approved visible *body* is unchanged; this only adds one frontmatter line
   the hook reads.
 ## 9. Light-Voyage review — folded
 Three Opus reviewers ran on the drafts, each verifying claims against live code. **scope-guardian: ALIGNED**
 (every SC1–SC6 traces to a step; zero creep; all nine §4 non-goals held; counts 27/19/29 verified live; 0
 findings). **brief-reviewer: PROCEED_WITH_RISKS** (1 real risk + minors). **plan-critic: REVISE** (2 blockers,
 5 majors, 4 minors). All findings folded; see `plan-re-r2b.md` §Plan-critic — folded for per-step resolution:
 - **[BLOCKER, folded]** `--json` summary source was an unresolved either/or ("re-derive OR expose"). → a
  committed **`briefSummary(ranking)`** export is now the single source for both `renderBrief`'s frontmatter and
  the CLI `--json` (§3; SC3 pins equality). Step 1 asserts against the named export.
 - **[BLOCKER, folded]** Section 16i placement was ambiguous. → pinned: immediately after Section 16h (the last
  section before 18; file order 17→16g→16h→18), before the Section 18 block (`:1118`).
 - **[MAJOR, folded]** the throwing-stub RED claim contradicted "fail on assertion, not module-not-found". →
  Step 1 now creates **wrong-but-non-throwing** stubs (empty buckets / `""`) so `brief.test.ts` fails on
  *assertion*; `cli.test.ts` brief cases are logic-RED against the existing dispatch (unknown command → exit 2).
 - **[MAJOR, folded]** brief §3 `outDir = flags.out ?? defaultBriefDir()` would write `./true/` for a bare
  `--out`. → corrected to the `flags.out !== "true"` guard (`parseFlags` `cli.ts:52-53`); a bare-`--out`
  cli.test case added.
 - **[MAJOR, folded]** `TRENDS_TESTS_FLOOR` recount was ambiguous (full `tests N` vs additive). → pinned: the
  `tests N` line after Steps 1–3; the inline `:697` comment appends `+ RE-R2b: brief +N + cli +M`.
 - **[MAJOR, folded]** `defaultBriefDir` re-resolved the data root independently (triple-twin drift). → it now
  **derives from `defaultStorePath()`** (`join(dirname(defaultStorePath()), "morning-brief")`) — one root
  resolution; the hook-vs-CLI path equivalence is the store-path twin already guarded by `data-root.test.mjs`;
  SC5 adds a write-then-read path cross-check.
 - **[MAJOR, folded]** the surfacing newline-escape was unproven. → §3 + SC5 state `extractYaml`'s `[^"\n]*` +
  `.trim()` makes `date`/`summary` newline-free → no `.replace` needed; SC5 asserts no raw newline in the block.
 - **[brief-reviewer MAJOR, folded]** SC6 attributed "hook-suite at recount" to `bash scripts/test-runner.sh`,
  which neither runs nor counts the hook suite (no `HOOK_TESTS_FLOOR`, no root `package.json`). → SC6 + §7 now
  split into **two** gate commands: `test-runner.sh` (trends/16i/ASSERT/de-niche/counts) and
  `node --test hooks/scripts/__tests__/` (the new hook test).
 - **[MINOR, folded]** non-total sort → added `url asc` final tie-break (true total order, §3/SC1). **[MINOR,
  folded]** local `ageDays` math stated as a deliberate non-import (dependency direction `cli.ts → brief.ts`).
  **[MINOR, folded]** `.md$`-anchored filename filter confirmed. **[MINOR, folded]** header-enumeration is a
  prose chain → insert the 16i clause between the 16h and Section-18 clauses (`:43-46`). **[brief-reviewer
  MINOR, folded]** body entry-line age format pinned in §3 + SC3. **[brief-reviewer MINOR, folded]** Open Q#2/#4
  reframed as load-bearing confirmations (§8).
--- a/docs/research-engine/brief-re-r3a.md
+++ b/docs/research-engine/brief-re-r3a.md
@ -1,357 +0,0 @@
 # Brief — RE-R3a: persist the relevance score + rank the morning brief on it
 > **Slice:** RE-R3a (research-engine rung-2, R3 slice 1 — research-*deepening*). R3 ("deepen the
 > research engine") is an **arc** of 5 open hulls (substrate §1: autonomous trigger · freshness-as-seen-log ·
 > relevance/saturation/status scoring · brief history+diff · A1–A4 fan-out). R3a takes the first: the
 > **relevance** half of hull 5 (and the remainder of hull 3 — "the store schema lacks fields a brief ranks
 > on"). It persists the composite relevance score the `trend-spotter` agent ALREADY computes, onto the store
 > record, and makes `rankForBrief` order on it.
 > **Predecessor:** RE-R1 (`score.ts`, B2 triage-scorer — built, tested, deterministic) + RE-R2a (`capture`
 > bridge + `publishedAt`, schema v1→v2) + RE-R2b (`brief.ts` dated artifact + surfacing). R2b explicitly
 > deferred this in its §4: *"the B2 triage scorer stays out of the brief path — its output isn't persisted on
 > records yet — that's R3."* R3a is exactly that R3 step.
 > **Substrate:** `docs/research-engine-concepts.local.md` §1 hull (3) (schema fields a brief ranks on:
 > relevance/...) + (5) (relevance scoring) + §B2 ("scoring/filtering as a gate before expensive work — the
 > output is the rank key") + §A2 ("curate/score before synthesis — the writer sees ranked material").
 > **TDD-order:** RED tests land before code — but as **two phases** (light-Voyage BLOCKER fold): the
 > store/brief/cli tests are true logic-RED against the pre-edit code (they build fixtures inline, import no new
 > symbol); the score/item tests reference not-yet-existing `score.ts` exports, so under Node16 ESM a missing
 > named import throws at module-load (not on assertion) — they are RED against **non-throwing stubs** landed as
 > the first GREEN-prep sub-step. See plan Step 1.
 ## 1. Operator decision context (2026-06-24)
 The research engine is **Tier-1** (operator, 2026-06-23): *"hele min arbeidsflyt hviler på at jeg får en jevn
 strøm av gode forslag til tema å skrive om."* RE-R2 made the stream **visible** (a dated morning brief surfaced
 at session-start). R2b ranks that brief on **pillar-overlap + recency only** — a coarse proxy for "good topic
 to write about." The actual relevance judgment (audience pull, timing, angle potential, authority, depth) lives
 in the five 1–10 dimension scores the `trend-spotter` agent produces in Step 2 and pipes to the `score` CLI —
 and is then **thrown away** before the trend reaches the store (Step 4.5 builds a *separate*, score-free capture
 batch). R3a stops discarding it: persist the composite + band on the record, and rank the brief on composite
 first. **The slice the operator chose** ("scoring inn i briefen", 2026-06-24) — the highest-leverage next step
 on the core need (better-ordered suggestions), built on already-shipped-but-dormant code (`score.ts` is tested
 and unused on records). The bigger R3 arcs (autonomous trigger / seen-log / saturation+status / A1–A4 fan-out)
 stay later slices.
 **Go-gate resolutions — CONFIRMED (operator "Go", 2026-06-24; baked into the plan):** **D1** persist the
 **4-field** `TrendScore { mode, dimensions, composite, priority }` (composite+priority to rank/display, mode to
 disambiguate the instrument, dimensions for audit + lossless re-weight). **D2** composite is the **primary
 within-bucket sort** (buckets still assigned by overlap+freshness; composite orders *inside* a bucket). **D3**
 score is **first-sight** (set on add, never updated on re-capture — matches the store's provenance discipline;
 re-score-on-recapture pairs with the R3b seen-log/status slice). **D4** ship persist+rank as **one** slice (the
 operator named the visible payoff; splitting would land an invisible schema-only cut like R2a).
 ## 2. The gap — grounded in code
 - **The score the agent computes never reaches the store.** `trend-spotter.md` scores each candidate's five
  dimensions and pipes them to the `score` CLI (`agents/trend-spotter.md:134-140`), which returns
  `{composite, band}` per candidate (`score.ts:110-122` `triage`). But Step 4.5's capture batch
  (`agents/trend-spotter.md:291-298`) is **built separately and carries no score** — `source/title/url/topics/
  publishedAt/summary` only. `TrendItem` (`item.ts:22-39`) and `TrendRecord` (`types.ts:26-48`) have **no score
  field**. The relevance judgment is recomputed for the digest and discarded for persistence.
 - **`score.ts` is built, tested, deterministic — and unconsumed on records.** It exports `composite()`
  (`score.ts:77-88`) and `band()` (`score.ts:91-97`) as pure functions, pinned to the SSOT
  (`references/trend-scoring-modes.md`, by `score.test.ts:12-30` weights + the band-string assertions). Nothing
  persists their output. `TrendRecord`'s own doc-comment anticipates the field: *"can gain fields (relevance
  score, first-mover timing, status) in a later slice"* (`types.ts:21-23`).
 - **The brief ranks on a proxy.** `rankForBrief` sorts each bucket `overlap desc → effectiveDate desc →
  title asc → url asc` (`brief.ts:94-104`). Overlap (a hard pillar count) is *part* of what the composite
  already weights (Pillar Fit 30 %, `trend-scoring-modes.md:43`), but the composite also captures audience/
  timing/angle/authority — signal the brief currently can't see. `brief.ts`'s own header already names this as
  the next slice: *"A persisted relevance/saturation score … (R3)"* (`brief.ts:11-14`).
 ## 3. Scope — what is IN (RE-R3a)
 ### S-score — `scripts/trends/src/score.ts` (EDIT)
 - **`export interface TrendScore { mode: ScoreMode; dimensions: DimensionScores; composite: number; priority:
  Priority }`** — the persist-ready envelope. Lives in `score.ts` (the score domain owns it); `types.ts` imports
  it (one-way: `score.ts` imports nothing — verified leaf, `:1-17` — so no cycle).
 - **`export function requiredDimensions(mode: ScoreMode): string[]`** — `Object.keys(WEIGHTS[mode])`
  (`score.ts:37-40`). **Contract: ordered** — the keys come back in the SSOT weight-literal order (kortform
  `["pillar","audience","timing","angle","authority"]`, long-form `["pillar","depth","angle","authority",
  "currency"]`, `score.ts:20-35`); SC1 deep-equals that ordered array, and `score.test` pins the order so a
  silent SSOT reorder fails loudly. `normalizeItem` consumes it as a **set** (membership), which is order-safe
  either way. `WEIGHTS` stays private; the keys are exposed via this function.
 - **`export function scoreEnvelope(mode: ScoreMode, dimensions: DimensionScores): TrendScore`** — composes the
  existing pure functions: `const c = composite(dimensions, mode); return { mode, dimensions, composite: c,
  priority: band(c).priority }`. **No new arithmetic** — `composite()`+`band()` stay the single owners (SSOT
  discipline). It throws (via `composite`, `score.ts:83`) on an out-of-range dimension — that is its
  **contract**, exercised directly by SC1/SC2; on the capture path it is unreachable because `normalizeItem`
  pre-validates (below).
 ### S-types — `scripts/trends/src/types.ts` (EDIT)
 - `import type { TrendScore } from "./score.js";`
 - `TrendRecord` gains **`score?: TrendScore;`** (optional — pre-R3a records simply lack it; the `add` manual
  path and unscored adopters omit it). Doc-comment updated to mark `score` as the now-realized field the
  `:21-23` note anticipated.
 - **`SCHEMA_VERSION = 2 → 3`** (`types.ts:62`). The bump is the only schema signal; the record shape change is
  additive-optional, so the migration is the version-stamp alone (below).
 ### S-store — `scripts/trends/src/store.ts` (EDIT)
 - `TrendInput` (`store.ts:26-35`) gains **`score?: TrendScore;`** (imported from `score.js`).
 - `addTrend` (`store.ts:120-140`): on a **new** record, persist `score` first-sight via the existing
  conditional-spread idiom (`...(input.score !== undefined ? { score: input.score } : {})`, mirroring
  `publishedAt`/`summary` `:134,136`). On a **duplicate**, score is **NOT** updated (D3 — first-sight, like
  `source`/`capturedAt`/first `publishedAt`); topics still union (`:124-126`, unchanged). `AddResult` is
  unchanged (no new flag).
 - `loadStore` migrate comment (`:79-84`): extend to *"v1→v2→v3 are all purely additive-optional (an old record
  is already a valid record that simply lacks the optional field), so the migration is the version stamp alone —
  records pass through untouched."* **No code change** to the migration logic (`Math.max(onDisk, SCHEMA_VERSION)`
  `:87` already does v2→v3 correctly; `saveStore` `JSON.stringify` `:95` preserves the `score` field — no field
  stripping); only `SCHEMA_VERSION` (in `types.ts`) and the comment move.
 ### S-item — `scripts/trends/src/item.ts` (EDIT)
 - `TrendItem` (`item.ts:22-39`) gains **`score?: { mode: ScoreMode; dimensions: DimensionScores };`** — the
  ingress envelope carries the agent's *judgment* (five scores + mode), **not** a precomputed composite (the
  store computes it, so the composite has one owner). `import type { ScoreMode, DimensionScores } from
  "./score.js"` + `import { requiredDimensions } from "./score.js"`.
 - `normalizeItem` (`:86-119`): if `r.score` present, **validate structurally** (returns a structured error into
  `errors[]`, never throws — the existing discipline, like the `publishedAt` ISO check `:99-106`): `score` is a
  **non-array** object; `mode ∈ {kortform, long-form}`; `dimensions` is a **non-array** object; **each key in
  `requiredDimensions(mode)` is present and a number in [1,10]**. On any failure → `errors.push("invalid score:
  …")`. On success carry the **validated** `score = { mode, dimensions }` forward (the validated dimensions
  object, not raw `r.score.dimensions`). Absent/null/invalid → key omitted. This guarantees the *capture path*
  (`cli.ts:246-254`: `normalizeItems` → `itemToInput`) never reaches `composite` with bad dims.
 - `itemToInput` (`:129-139`): if `item.score` present → add `score: scoreEnvelope(item.score.mode,
  item.score.dimensions)` to the returned `TrendInput` (conditional spread, key omitted when absent). The
  item→store bridge is the natural place to turn judgment into the persisted envelope. `itemToInput` is a public
  function: called directly (e.g. in a test) with unvalidated dims it **throws by contract** (defense-in-depth);
  the no-throw guarantee is a property of the *capture path*, not of `itemToInput` in isolation (§5).
 ### S-brief — `scripts/trends/src/brief.ts` (EDIT)
 - `rankForBrief` (`:72-114`): **composite becomes the primary within-bucket sort key** (D2). The comparator
  (`:94-98`) gains a leading term:
  `(b.trend.score?.composite ?? -1) - (a.trend.score?.composite ?? -1) || <existing overlap desc → effectiveDate
  desc → title asc → url asc>`. **Sentinel `-1`, not `-Infinity`** — composite is a weighted sum of [1,10]
  dims so it is always ≥ 1.0 (min = 1×Σweights = 1.0, verified); `-1` sorts every unscored record below every
  scored one and subtracts cleanly (`-Infinity - -Infinity = NaN` would corrupt the comparator). **Buckets are
  UNCHANGED** — assignment stays `overlap≥2 & fresh` / `overlap==1 & fresh` / `!fresh` (`:100-104`); composite
  only re-orders *within* a bucket. Total order preserved: the `(title,url)` pair is unique per store (it is the
  dedupe id, `store.ts:66-68`), so the final `url asc` tie-break makes the order insertion-independent even for
  equal composites.
 - `renderBrief` (`:152-191`): surface the band **and mode** where a record is scored (so a reader can tell a
  kortform "High" from a long-form "High" — the two are different instruments). **Pinned line shapes:**
  - Top-entry meta line (`renderTopEntry`, `:135`), scored:
    `- Kilde: <source> · Publisert: <date> (<age>d) · <priority> (<mode>) · Pillarer: <matched>`
    (the `· <priority> (<mode>)` token sits between `(<age>d)` and `· Pillarer`); **unscored: unchanged** (no
    token).
  - Bullet line (`renderBulletEntry`, `:144`), scored:
    `- **<title>** — «<matched>» · <date> (<age>d) · <priority> (<mode>) · 🔗 <url>`
    (token **before** `· 🔗`); **unscored: unchanged**.
  - The `ranking:` frontmatter descriptor (`:160`) → the **exact** string
    `composite desc, then pillar-overlap desc, then publishedAt desc (capturedAt fallback); freshDays <N>`
    (pinned verbatim; `brief.test` asserts it byte-for-byte).
 - `briefSummary` (`:122-130`): the top mention names the **band only** (mode stays a body-entry detail to keep
  the one-line headline clean) — fresh>0 with a **scored** top → `… Topp: «<title>» (<pillar> · <priority> ·
  <age>d).`; fresh>0 with an **unscored** top → `… Topp: «<title>» (<pillar> · <age>d).` (no token). **Still one
  line, no `"`, no `\n`** — the `extractYaml` contract (`brief.ts:118-120`) holds; the band strings
  (`Immediate`/`High`/…) are bare words.
 - `BRIEF_SCHEMA_VERSION` stays **1** (no frontmatter *field* added/removed; the surfacing hook still reads
  `date`+`summary`; only the `ranking:` descriptor *string* and body content change). Bumping is an Open Q (§8),
  not required for correctness.
 ### S-cli — `scripts/trends/src/cli.ts` (EDIT, doc-only behavior)
 - The `capture` branch (`:243-269`) folds via `itemToInput` (`:254`) — so once `item.ts` threads `score`,
  capture **automatically** persists it with **no logic change**. Update only the header doc-comment
  (`:15-21`) to note capture now persists an optional relevance score. The `score` CLI (`:218-241`, the digest
  path) and the `add` manual path (`:123-147`, score-free) are unchanged. *(Capture's `{added, merged,
  duplicates, errors}` tally is left unchanged — a `scored` count is an Open-Q nice-to-have, §8.)*
 ### Wiring (D-default — WIRE, mirrors R2a/R2b Open Q#1)
 - `agents/trend-spotter.md` (EDIT): Step 4.5's capture batch (`:291-298`) gains a per-item **`"score": {"mode":
  "kortform", "dimensions": {"pillar": N, "audience": N, "timing": N, "angle": N, "authority": N}}`** — the same
  five judgment scores the agent computed in Step 2 (`:134`), carried into capture so the store persists them and
  the brief ranks on them. Prose explains the carry ("don't discard the Step-2 scores — fold them into the
  capture batch"). Mode defaults `kortform`; `long-form` when invoked from `/linkedin:newsletter` (long-form
  dims `pillar/depth/angle/authority/currency`). Domain-general (dimensions are the rubric's, pillars are the
  user's config; no vendor/sector tokens). Keep the "skip silently if no deps" escape hatch. **Verified
  non-vacuous:** `agents/trend-spotter.md` does NOT currently contain the literal `"dimensions"`, so the
  Section 16j grep passes only after the wire is added.
 - `scripts/trends/README.md` (EDIT): document the item `score` field (judgment in), the persisted `TrendScore`
  (composite/priority out), and that the brief now ranks on composite.
 - `scripts/test-runner.sh` (EDIT): bump `TRENDS_TESTS_FLOOR` (`:701`, currently 104) to the `tests N` line
  reported after Steps 1–6, **append** `+ RE-R3a: score +N` to the inline breakdown comment (`:701`). Add
  **Section 16j** ("Trends Score Wiring", RE-R3a) **after Section 16i's closing `echo ""` (~`:1171`), before the
  Section 18 block (`:1173`)** (16i is the last 16x before anti-erosion; file order 17→16g→16h→16i→18,
  `:947/:1014/:1078/:1122/:1173`). Mirror 16i's shape: **unconditional**, deps-absent-safe `grep -qF` + a
  non-vacuity self-test emitting **one** pass/fail (so the count is exact) — (1) self-test; (2) `export
  interface TrendScore` in `score.ts`; (3) `score?: TrendScore` in `types.ts`; (4) `"dimensions"` in
  `agents/trend-spotter.md`; (5) `score?.composite` in `brief.ts`. **5 unconditional emitters → bump
  `ASSERT_BASELINE_FLOOR` 94 → exactly 99** (`:1193`; "live recount" is the safety net, but the expected value
  is the pinned 94 + 5 = 99). Update the header-enumeration **prose chain** by inserting the 16j clause between
  the 16i clause (`:46-49`) and the Section-18 clause (`:49`), preserving sentence flow.
 ## 4. Non-goals — what is OUT (deferred)
 - **Re-score on re-capture** (refresh the score when a trend is re-seen) — **R3b**. R3a is first-sight only
  (D3). Re-score pairs naturally with the seen-log/status slice (the Timing dimension decays, so a refresh is a
  real improvement — but it expands `addTrend`'s mutation surface and wants the status/lifecycle model alongside).
 - **Mode-segmented / mode-normalized ranking** — OUT. R3a ranks **all** records by composite regardless of mode;
  a kortform composite and a long-form composite are different instruments (different dimensions,
  `trend-scoring-modes.md:50,68`), so the ranking is **mode-blind by design for R3a**. This is acceptable because
  (a) almost all records are `kortform` (the default), and (b) the body entry line **shows the mode** (`<priority>
  (<mode>)`) so the operator can see when two adjacent entries were scored on different instruments. A
  mode-segmented brief (separate sections per mode) or a `--mode` filter is a later refinement.
 - **Saturation / status (acted/skipped) / first-mover-as-a-field** (the rest of hull 5) — **R3b+**. R3a does the
  **relevance** half of hull 5 only.
 - **Autonomous nightly trigger** (cron/launchd, hull 1) — **R3 later**. No scheduler enters the repo.
 - **Freshness as a persisted seen-log / dedup-vs-seen (B4)** — **R3 later**.
 - **Brief history surfacing / diff ("yesterday vs today", hull 7)** — **R3 later**.
 - **Research-deepening A1–A4** (plan → isolated parallel workers → gap loop → curate), adapter sub-agents, MCP
  fetch fan-out — **R3 later** (the big slice).
 - **A new `score` field in the `add` manual CLI path** — OUT. `add` stays the raw, score-free manual path; only
  the normalizing `capture` path carries scores.
 - **`BRIEF_SCHEMA_VERSION` bump** — OUT by default (no frontmatter field changes); Open Q#5.
 - **New source file / new agent / new command** — none. R3a is all edits to the six existing `src/*.ts` +
  one agent + README + gate. Counts stay 27/19/29.
 ## 5. Boundaries / invariants (must hold)
 - **TDD iron law (two-phase RED):** the failing tests land **BEFORE** the implementation. `store`/`brief`/`cli`
  tests are true logic-RED against the pre-edit code (inline fixtures, no new import). `score`/`item` tests
  reference new `score.ts` exports → under Node16 ESM a missing named import throws at module-load, so they are
  RED against **non-throwing stubs** landed first (the stubs return wrong-but-present values; the value
  assertions then fail). The plan records the RED proof in two phases (Step 1); it does NOT claim a single
  "all five fail on assertion before any code" run.
 - **One composite owner:** `composite()` + `band()` (`score.ts`) stay the sole arithmetic; `scoreEnvelope`
  *composes* them, never re-derives. The agent supplies judgment, the code computes the composite (SSOT
  discipline, `score.test.ts:12-30` pins the weights/bands).
 - **Purity:** `scoreEnvelope`/`requiredDimensions`/`rankForBrief`/`renderBrief` touch no fs, no clock, no env,
  no AI. All fs stays at the CLI edge.
 - **No throw on the capture path (not "everywhere"):** `normalizeItem` fully validates the score before
  `itemToInput`, so the capture loop (`cli.ts:246-258`) never reaches `composite` with bad dims and never
  crashes (a bad score → `errors[]`). `itemToInput`/`scoreEnvelope`/`composite` called **directly** with bad
  dims throw by contract — that is the defense-in-depth boundary, asserted (SC2), not a leak.
 - **Determinism:** same `(store, pillars, today, freshDays)` → byte-identical brief (the composite sort is a
  total order via the unique `(title,url)` final tie-break; `-1` sentinel for unscored is deterministic).
 - **Lossless additive migration (both directions):** a v2 store loads as v3 with records **untouched** (no
  `score` invented); round-trip writes `schemaVersion: 3`; a v3 store is idempotent; a v3 store's new optional
  `score` field **survives a load+resave** (no field stripping, `JSON.stringify` `store.ts:95`). Mirrors the R2a
  v1→v2 proof (`store.test.ts:403-476`) + a new field-preservation case.
 - **Hook unaffected:** the SessionStart surfacing reads `date`+`summary` only and **never shells out to tsx**
  (analytics fresh-clone-crash invariant) — R3a touches neither the hook nor the frontmatter schema, so the
  zero-tsx surfacing is unchanged. (No hook test added; the existing hook suite must still pass untouched as a
  regression sanity.)
 - **Domain-general:** Section 17 de-niche stays green; the `trend-spotter.md` edit carries the rubric's
  dimension names + the user's pillars, **no vendor/sector tokens**.
 - **No SSOT change:** `references/trend-scoring-modes.md` (weights/bands/actions) untouched; `score.ts` mirrors
  it exactly as today.
 - **No store-query change:** `queryByTopic`/`history`/`newestCaptureDate` untouched; the brief recomputes
  overlap as before (`queryByTopic` NOT refactored).
 - **Pathguard:** all edits are to **existing** files (no new `.mjs` under `hooks/scripts/`; no new `.ts` —
  R3a adds *no* source file). `.gitignore` already covers `scripts/trends/{node_modules,build}`.
 - **Counts** (refs/agents/commands 27/19/29) unchanged. **Recounted live at land**, never pinned/guessed.
 ## 6. Success criteria (testable)
 - **SC1 (score envelope)** — `requiredDimensions("kortform")` **deep-equals (ordered)** `["pillar","audience",
  "timing","angle","authority"]`; `requiredDimensions("long-form")` deep-equals `["pillar","depth","angle",
  "authority","currency"]` (the `WEIGHTS` literal order, `score.ts:20-35`), and `score.test` pins the order so a
  SSOT reorder fails. `scoreEnvelope("kortform", {pillar:8,audience:7,timing:9,angle:6,authority:5})` returns
  `{ mode:"kortform", dimensions:<the five>, composite: composite(dims,"kortform"), priority: band(composite).
  priority }` — composite/priority equal the existing functions' output byte-for-byte (one owner); a bad
  dimension makes `scoreEnvelope` throw (via `composite`).
 - **SC2 (item validation + bridge + the throw contract)** — `normalizeItem` on an item with a valid `score`
  carries the **validated** dims; with a bad `mode`, a missing dimension, a dimension out of [1,10], a non-object
  `score`, or an **array** `dimensions` → `{ ok:false, errors:["invalid score: …"] }` (structured, **never
  throws**); absent `score` → key omitted. `itemToInput(validItemWithScore, capturedAt)` returns a `TrendInput`
  whose `score` is `scoreEnvelope(mode, dimensions)` (composite/priority computed); without a score → no `score`
  key; **`itemToInput` called directly with an out-of-range dim throws** (the defense-in-depth contract).
 - **SC3 (first-sight persist)** — `addTrend(store, inputWithScore)` on a **new** title+url persists `score` on
  the record; re-`addTrend` of the same title+url with a **different** score does **NOT** change the stored
  score (first-sight, D3) while topics still union; an input **without** a score adds a score-free record.
 - **SC4 (migration v2→v3, both directions)** — a `schemaVersion:2` store with records lacking `score` loads as
  **v3**, records intact, **no `score` invented**; round-trip `loadStore→saveStore` writes `schemaVersion:3`; a
  v3 store with `score` on records loads idempotent; **a v3 store's `score` field survives load+resave** (field
  preservation of a new optional field — not covered by the mirrored v1→v2 block). Mirrors
  `store.test.ts:403-476`, **retitled `(RE-R3a / score v2→v3)` with every `schemaVersion` assertion literal
  flipped `2`→`3`.**
 - **SC5 (brief ranks on composite)** — within a bucket, `rankForBrief` orders **composite desc** first
  (a composite-9 record ahead of a composite-6 record at the **same overlap**); an **unscored** record sorts
  **after** every scored record in its bucket (the `-1` sentinel) and then by the existing keys; buckets are
  unchanged (still overlap+freshness); the order is a **total order** (same-title/diff-url, both unscored →
  fixed by `url asc`); same input → byte-identical brief (determinism).
 - **SC6 (render surfaces band + mode)** — `renderBrief` emits the **full pinned line shapes** (§3): a scored
  top-entry shows `· <priority> (<mode>)` between `(<age>d)` and `· Pillarer`; a scored bullet shows `·
  <priority> (<mode>)` before `· 🔗`; an **unscored** entry renders the **unchanged** line (no token) — both
  asserted as **full lines, not substrings**. `briefSummary` names the band (no mode) on a scored top, omits the
  token on an unscored top, and stays one line with no `"`/`\n` **even when the top title contains a guillemet/
  quote** (the only new code path touching the summary). The `ranking:` frontmatter descriptor equals the pinned
  string verbatim. A store whose only fresh match is a **single-pillar unscored** record → `briefSummary` renders
  with no `· <priority>` token, one line.
 - **SC7 (CLI persists score end-to-end)** — `echo '[{…,"score":{"mode":"kortform","dimensions":{…valid…}}}]'
  | … capture --store <tmp>` then `… list --store <tmp> --json` shows the record carrying a `score` with the
  computed composite/priority; a batch with one **bad** score → that item in `errors[]`, the valid ones added,
  **exit 0** (the run isn't failed).
 - **SC8 (gate + wiring + de-niche)** — `bash scripts/test-runner.sh` → `FAIL=0`: trends suite green at the
  bumped `TRENDS_TESTS_FLOOR`; new **Section 16j** green (`TrendScore` in `score.ts`, `score?: TrendScore` in
  `types.ts`, `"dimensions"` in `trend-spotter.md`, `score?.composite` in `brief.ts`, non-vacuity self-test);
  `ASSERT_BASELINE_FLOOR` = **99** (94 + 5); Section 17 de-niche green; counts 27/19/29.
 ## 7. Verification
 **Deterministic:** `bash scripts/test-runner.sh` → `FAIL=0`; trends suite ≥ new floor; new Section 16j
 self-test + greps pass; `ASSERT_BASELINE_FLOOR` = 99; Section 17 de-niche green; ref/agent/command counts
 unchanged. **Regression sanity:** `node --test hooks/scripts/__tests__/` → still green untouched (R3a touches no
 hook; adds no hook test).
 **Behavioural (manual):**
 1. `echo '[{"source":"tavily","title":"A","url":"https://e/a","topics":["ai","gov"],"publishedAt":"<~2d ago>",
   "score":{"mode":"kortform","dimensions":{"pillar":9,"audience":8,"timing":9,"angle":7,"authority":6}}},
   {"source":"tavily","title":"B","url":"https://e/b","topics":["ai","gov"],"publishedAt":"<~2d ago>",
   "score":{"mode":"kortform","dimensions":{"pillar":6,"audience":5,"timing":6,"angle":5,"authority":5}}}]'
   | node --import tsx src/cli.ts capture --store /tmp/r3a.json` — both overlap-2 & fresh, A scored higher.
 2. `node --import tsx src/cli.ts list --store /tmp/r3a.json --json` → confirm both records carry `score`
   with computed composite/priority.
 3. `node --import tsx src/cli.ts brief --pillars ai,gov --store /tmp/r3a.json --out /tmp/r3a-brief --json` →
   confirm **A precedes B** in `topMatches` (higher composite, same overlap+freshness), the entry line shows
   `· <priority> (kortform)`, and the `summary` names A with its band.
 4. Append a bad-score item (`"timing":99`) to the batch and re-`capture` → confirm it lands in `errors[]`,
   the valid items still added, exit 0.
 ## 8. Open questions for the go-gate — RESOLVED
 D1–D4 confirmed by the operator ("Go", 2026-06-24): **D1** 4-field `TrendScore`; **D2** composite primary within
 bucket; **D3** first-sight; **D4** one slice (data-then-visible commit order within it). Two residual cosmetics,
 both baked to the recommended default:
 - **D5 — `BRIEF_SCHEMA_VERSION` 1→2?** No (no frontmatter field added/removed; the hook reads only
  `date`+`summary`). Re-open only if the artifact should self-announce the ranking change.
 - **D6 — mode in the per-entry render?** YES (folded from plan-critic #3): the body entry shows `<priority>
  (<mode>)`; the summary shows the band only. This makes the mode-blind ranking honest (the reader can see the
  instrument).
 ## 9. Light-Voyage review — folded
 Three Opus reviewers ran on the drafts, each verifying claims against live code. **scope-guardian: ALIGNED**
 (every SC1–SC8 traces to a step; zero creep; all §4 non-goals held; counts 27/19/29 verified live; "no new
 source file" verified — exactly 6 `src/*.ts` + 5 `tests/*.test.ts`, all edited, none added; 0 findings).
 **brief-reviewer: PROCEED_WITH_RISKS** (all four load-bearing claims — score.ts-is-a-leaf/no-cycle, composite ≥
 1.0, version-stamp-only migration, single-owner arithmetic — verified TRUE; 6 MINOR). **plan-critic: REVISE**
 (1 BLOCKER, 4 MAJOR, 4 MINOR). All findings folded; see `plan-re-r3a.md §Plan-critic — folded` for per-step
 resolution. Headlines:
 - **[BLOCKER, folded]** the "all five test files fail on assertion after Step 1" RED claim is false for
  `score`/`item` under Node16 ESM (a missing named import throws at module-load, not on assertion). → RED is now
  **explicitly two-phase**: logic-RED for `store`/`brief`/`cli` against pre-edit code; stub-first then
  assertion-RED for `score`/`item` (§5; plan Step 1; the header blockquote).
 - **[MAJOR, folded]** the no-throw guarantee was overstated ("unreachable" — but `itemToInput` is public and
  throws on direct bad-dim calls). → reworded **path-specific** (no throw on the capture path; direct calls throw
  by contract); SC2 asserts both (§5, §6).
 - **[MAJOR, folded]** mode-mixing was waved away and "mode shown per entry" contradicted the render spec (which
  only showed priority). → the render now shows `<priority> (<mode>)` per body entry (D6); §4 states mode-blind
  ranking is accepted for R3a with the mode visible; SC6 asserts the full line incl. mode.
 - **[MAJOR, folded]** `requiredDimensions` order contract was ambiguous (SC1 hard-coded arrays vs membership
  use). → pinned **ordered** (SC1 deep-equals the SSOT-order array; `score.test` pins order; `normalizeItem` uses
  membership) (§3 S-score, SC1).
 - **[MAJOR, folded]** `ASSERT_BASELINE_FLOOR` "~99" was not pinned. → pinned **99** (94 + 5 unconditional 16j
  emitters; self-test emits one pass/fail like 16i) (§3 wiring, SC8).
 - **[MINOR, folded]** SC4 ref `:403-471` stale + pointed at v2 assertions → `:403-476` + "flip every
  `schemaVersion` literal 2→3" note (SC4). **[MINOR, folded]** R1 SSOT-pin cite was the doc-comment → now
  `score.test.ts:12-30` (§2, §5; plan R1). **[MINOR, folded]** bullet `· <priority>` placement was substring-only
  → full pinned line shape, priority+mode before `🔗`, asserted as a full line (§3, SC6). **[MINOR, folded]**
  three diverging `ranking:` descriptor strings → one verbatim target, asserted byte-for-byte (§3, SC6). **[MINOR,
  folded]** unscored single-match-top summary path untested → added as an SC6 case. **[MINOR, folded]**
  `normalizeItem` non-array object case understated → "non-array" added to both object checks + SC2. **[MINOR,
  folded]** header-chain line-ref tightened to the 16i clause `:46-49` / Section-18 `:49`. **[MINOR, folded]** R9
  DAG now lists the three new one-way `score.ts ←` edges. **[MINOR, folded]** SC4 forward-compat /
  score-survives-round-trip added. **[MINOR, folded]** SC6 quote-safety regression (scored top title with a
  guillemet) added.
--- a/docs/research-engine/brief-re-r3b.md
+++ b/docs/research-engine/brief-re-r3b.md
@ -1,416 +0,0 @@
 # Brief — RE-R3b: trend lifecycle — re-score on re-capture · status (acted/skipped) · seen-log
 > **Slice:** RE-R3b (research-engine rung-2, R3 slice 2 — the **lifecycle** slice: what happens to a trend
 > AFTER first capture). R3 ("deepen the research engine") is an **arc** of 5 open hulls (substrate §1). R3a took
 > the **relevance** half of hull 5 (persist the score, rank on it). R3b takes the rest of the *lifecycle* of a
 > trend: **(i) re-score on re-capture** (R3a's explicit deferral — hull 3 remainder), **(ii) a status lifecycle**
 > `new`/`acted`/`skipped` (hull 5), and **(iii) a seen-log** — `surfacedCount`/`lastSurfacedAt` accumulated on
 > each record as the temporal foundation slices (c)+(b) build on (hull 5, B4 dedup-state).
 > **Predecessor:** RE-R3a (`score?: TrendScore` persisted first-sight; `rankForBrief` orders on composite;
 > `renderBrief` surfaces band+mode) + RE-R2b (`brief.ts` dated artifact + surfacing) + RE-R2a (`capture` bridge).
 > R3a §4 deferred this exactly: *"Re-score on re-capture … R3b. R3a is first-sight only (D3). Re-score pairs
 > naturally with the seen-log/status slice."* — R3b is that paired slice.
 > **Substrate:** `docs/research-engine-concepts.local.md` §1 hull (5) (status/lifecycle: acted/skipped) +
 > remainder of (3) (status as a schema field) + §B4 (*"freshness window + dedup-state (append-only seen-log →
 > don't re-surface the same item)"*). The freshness window already exists (`freshDays`, R2b); R3b adds the
 > dedup-state (status as the hard dedup; surfacedCount as the soft signal).
 > **TDD-order:** RED before code, **two phases** (light-Voyage BLOCKER fold, inherited from R3a): the re-score +
 > migration parts of `store.test`, all of `brief.test`, and `cli.test` are true logic-RED against the pre-edit
 > code (inline fixtures / behaviour change / subprocess — no new import); the `setStatus`/`markSurfaced`/
 > `effectiveStatus` tests reference not-yet-existing `store.ts` exports, so under Node16 ESM a missing named
 > import throws at module-load (not on assertion) — they are RED against **non-throwing stubs** landed first. See
 > plan Step 1.
 ## 1. Operator decision context (2026-06-25)
 The research engine is **Tier-1** (operator, 2026-06-23). R1→R3a built the deterministic spine: item-schema +
 triage scorer (R1) → capture bridge (R2a) → dated morning brief + surfacing (R2b) → persisted relevance score +
 composite ranking (R3a). What the spine still lacks is **memory of a trend's life after first sight**: the score
 is frozen at first capture even as timing decays; a trend the operator already wrote about (or deliberately
 passed on) **re-tops tomorrow's brief unchanged**; and nothing records that a trend has been *surfaced* N times
 without action. The morning brief is meant to be a **work queue**, but today it is amnesiac — it cannot tell a
 fresh unhandled signal from one the operator dealt with yesterday.
 R3b closes that gap with the **lifecycle layer** the operator chose as slice (a) of the full-R3 build-out
 (2026-06-24, *"ALLE gjenstående R3-slices … i rekkefølge (a) → (c) → (b) → (d) → (e)"*). It is **the fundament
 for everything temporal**: the autonomous trigger (c) must *never automate a loop that re-surfaces handled
 items* — so it depends on (a)'s status+seen-log; saturation/first-mover (b) is *only meaningful with accumulated
 seen-data* — which (a) starts accumulating. R3b is deliberately first in the sequence: correctness of the
 lifecycle model before any automation reads it.
 **Architectural decisions — CONFIRMED (operator, AskUserQuestion 2026-06-25; baked into the plan):**
 - **A1 — seen-log form = on-record + the brief records surfacing.** Three new optional fields on `TrendRecord`
  (`status`, `surfacedCount`, `lastSurfacedAt`); the `brief` CLI, **after** the pure `rankForBrief` computes the
  ranking, records surfacing on the rendered trends and re-saves the store. `rankForBrief` stays **pure**
  (mutation only at the CLI edge). The store stays the **single source of truth** — no separate `seen-items.md`.
  A `--no-mark` flag gives a side-effect-free dry run. *(This is exactly what slice (c) will automate and slice
  (b) will read.)*
 - **A2 — re-score on re-capture = last-score-wins.** On a duplicate capture carrying a fresh `score`, the stored
  `score` is **replaced** by the freshly-computed envelope (composite re-derived by the one owner,
  `composite()`+`band()`). `score` becomes **the one deliberately-mutable field**; provenance (`source`,
  `capturedAt`, first `publishedAt`) stays first-sight. A re-score **does NOT reset status** — an `acted`/`skipped`
  decision sticks. *(Rationale: the Timing dimension decays, so the newer judgment — even a lower one — is the
  truer one; monotone "only if higher" would freeze stale optimism.)*
 - **A3 — acted/skipped are EXCLUDED from the brief.** `rankForBrief` drops every record whose effective status
  is not `new` from all three buckets — the brief is a work queue, not an archive. Full history stays available
  via `list`/`query`.
 ## 2. The gap — grounded in code
 - **The score is frozen at first sight, even as timing decays.** `addTrend`'s duplicate branch
  (`store.ts:127-131`) unions topics and returns — it **never touches `score`** (R3a's D3, first-sight only).
  The capture path already carries a fresh score on every re-capture (`item.ts:192` `itemToInput` →
  `scoreEnvelope`; `cli.ts:257` folds it through `addTrend`), so the fresh judgment **reaches `addTrend` and is
  silently discarded** for any trend already in the store. A trend re-polled a week later still ranks on its
  week-old Timing score.
 - **A handled trend re-tops the brief unchanged.** `rankForBrief` (`brief.ts:82-92`) iterates **every** store
  record, dropping only off-pillar ones (`overlap === 0`, `:89`). There is no notion of "I already wrote about
  this" — an `acted` trend with a high composite re-sorts to the top of `topMatches` tomorrow exactly as it did
  today. `TrendRecord` has **no `status` field** (`types.ts:29-59`); the doc-comment anticipates it: *"can gain
  fields (…, status) in a later slice"* (`types.ts:22`).
 - **Nothing records that a trend has been surfaced.** The brief is a **pure read** (`brief.ts:1-15`: *"No fs, no
  clock, no AI"*); generating it leaves no trace on the store. There is no `surfacedCount`/`lastSurfacedAt` —
  so a future autonomous loop (slice c) has **no way to know** a trend was already shown, and saturation (slice b)
  has **no accumulated signal** to read. B4's dedup-state (`docs/research-engine-concepts.local.md:63`) does not
  exist yet.
 - **The CLI has no lifecycle verbs.** `cli.ts` exposes `add`/`query`/`list`/`status`/`normalize`/`score`/
  `capture`/`brief` (`:5-13`) — all capture/read. There is **no way for the operator to mark** a trend `acted`
  or `skipped`.
 ## 3. Scope — what is IN (RE-R3b)
 ### S-types — `scripts/trends/src/types.ts` (EDIT)
 - **`export type TrendStatus = "new" | "acted" | "skipped";`** — the lifecycle states.
 - `TrendRecord` gains **three optional fields** (all absent on pre-R3b records, all additive):
  - **`status?: TrendStatus;`** — lifecycle. **Absent ⇒ `"new"`** (back-compat); set only by `act`/`skip`/`reset`,
    **never on capture** (a freshly-captured trend is implicitly `new`).
  - **`surfacedCount?: number;`** — the seen-log count: how many distinct days this trend has appeared in a
    generated brief. **Absent ⇒ 0.** Incremented (per-day-idempotent) by the `brief` CLI.
  - **`lastSurfacedAt?: string;`** — ISO date of the most recent surfacing. **Absent ⇒ never.** The per-day
    idempotency key (re-running today's brief does not re-increment).
 - Doc-comment: mark `status`/`surfacedCount`/`lastSurfacedAt` as the now-realized lifecycle fields the `:22`
  note anticipated.
 - **`SCHEMA_VERSION = 3 → 4`** (`types.ts:73`). Additive-optional; the migration is the version-stamp alone
  (below), identical to v1→v2→v3.
 ### S-store — `scripts/trends/src/store.ts` (EDIT)
 - **`export function effectiveStatus(t: TrendRecord): TrendStatus`** — `return t.status ?? "new";`. The single
  reader of the absent-⇒-new convention (pure; consumed by `addTrend` audit, `brief`, and the CLI). Imports
  `TrendStatus` from `./types.js` (type-only).
 - **Re-score in `addTrend`'s duplicate branch (`:127-131`, A2):** after the topic union, if `input.score !==
  undefined` **and it differs from `existing.score`** (compared via `JSON.stringify` — the envelope is built in a
  fixed key order by `scoreEnvelope`, so the compare is stable), set `existing.score = input.score` and mark the
  record changed. `AddResult.merged` is **broadened** to *"the existing record was mutated — topics unioned and/or
  score refreshed"*; `merged` is true iff **either** changed (a re-capture with an identical score → `merged:false`,
  no false-positive). `status`/`surfacedCount`/`lastSurfacedAt` are **NOT touched** on re-capture (A2: re-score
  doesn't reset status; surfacing is the brief's job, not capture's). The **new-record** branch (`:132-144`) is
  unchanged — a new record omits all three lifecycle fields (status absent ⇒ new; never surfaced; no input.status
  exists on the capture path).
 - **`export function setStatus(store: TrendStore, id: string, status: TrendStatus): { store: TrendStore; found:
  boolean }`** — find the record by `id`; if absent return `{ store, found: false }` (no throw); else set
  `t.status = status` (set **explicitly**, including `"new"` for a `reset`) and return `{ store, found: true }`.
  Mutates in place + returns the same store (the `addTrend` idiom). Pure (no fs).
 - **`export function markSurfaced(store: TrendStore, ids: string[], today: string): { store: TrendStore; marked:
  number }`** — for each record whose `id` is in `ids` **and** whose `lastSurfacedAt !== today` (per-day
  idempotent), set `surfacedCount = (surfacedCount ?? 0) + 1` and `lastSurfacedAt = today`; count it. Records
  already surfaced today, or not in `ids`, are untouched. Pure (no fs; `today` injected by the caller, like
  `capturedAt`). Returns the count actually incremented.
 - `AddResult` keeps its **2-flag shape** `{ store, added, merged }` (no new flag — `merged` is broadened, not
  joined). `TrendInput` is **unchanged** (no `status`/`surfaced*` input — lifecycle is set post-capture, not
  ingested).
 - `loadStore` migrate comment (`:82-88`): extend the enumeration to *"v1→v2→v3→v4 are all purely
  additive-optional"*. **No code change** (`Math.max(onDisk, SCHEMA_VERSION)` `:91` already stamps v4;
  `saveStore` `JSON.stringify` `:99` preserves the three new fields). Only `SCHEMA_VERSION` (in `types.ts`) and
  the comment move.
 ### S-brief — `scripts/trends/src/brief.ts` (EDIT)
 - **`rankForBrief` excludes handled trends (A3):** in the entry loop (`:82-92`), add **`if (effectiveStatus(trend)
  !== "new") continue;`** immediately before the `overlap === 0` check (so acted/skipped never enter any bucket).
  Import `effectiveStatus` from `./store.js` (brief.ts already imports `defaultStorePath` from there — `:19`; the
  edge stays one-way, no cycle). `totals.trends` **still counts the full inventory** (`store.trends.length`,
  `:116`) — honest "of N in store"; `totals.matched`/`fresh` naturally reflect the post-filter `entries`.
 - **`renderBrief`/`renderTopEntry`/`renderBulletEntry` surface the trend `id` + a surfaced marker** (so the
  operator can act on an entry, and a re-surfaced item is honest). **Pinned line shapes:**
  - A shared **`surfacedToken(e)`** helper (mirrors `scoreToken`, `:142-145`): ` · sett <surfacedCount>x` when
    `surfacedCount >= 2`, else `""` (only a genuinely re-surfaced item is flagged; this is a saturation **hint**,
    not the saturation **scoring** of slice b). **Semantic (folded — plan-critic #3): the count is PRIOR-DAY** —
    the brief renders from `surfacedCount` **before** the CLI records today's surfacing (the mutation runs after
    `renderBrief`), so `· sett Nx` means *"shown on N prior distinct days"* (today's appearance is recorded but
    not yet counted in this render). The `>= 2` floor therefore means "already shown on ≥2 earlier days". This is
    documented in the README + asserted by a unit test that sets `surfacedCount` directly (the cross-day behaviour
    is exercised by behavioural step §7).
  - Top-entry meta line (`renderTopEntry`, `:150`): append **` · \`<id>\``** at the end (after `Pillarer: …`),
    and `surfacedToken(e)` after the `scoreToken`:
    `- Kilde: <source> · Publisert: <date> (<age>d)<scoreToken><surfacedToken> · Pillarer: <matched> · \`<id>\``
  - Bullet line (`renderBulletEntry`, `:159`): append **` · \`<id>\``** at the end (after `🔗 <url>`), with
    `surfacedToken` after `scoreToken`:
    `- **<title>** — «<matched>» · <date> (<age>d)<scoreToken><surfacedToken> · 🔗 <url> · \`<id>\``
  - The id is rendered in backticks so it is copy-paste-ready for `act --id <id>` / `skip --id <id>`.
 - **`export function surfacedIds(ranking: BriefRanking): string[]`** — the ids of the entries `renderBrief`
  **actually shows**: `topMatches ∪ singleMatches ∪ olderMatched.slice(0, 5)` (mirrors the `:199` `.slice(0, 5)`
  older cap), mapped to `e.trend.id`. The CLI feeds this to `markSurfaced` so the seen-log records exactly what
  the operator saw. Pure.
 - **`ranking:` frontmatter descriptor (`:175`)** → the **exact** string
  `composite desc, then pillar-overlap desc, then publishedAt desc (capturedAt fallback); freshDays <N>; excludes
  acted/skipped` (pinned verbatim; `brief.test` asserts byte-for-byte). The trailing `; excludes acted/skipped`
  is the only descriptor change.
 - `briefSummary` (`:129-139`) is **unchanged** (the headline still names the top fresh match's band + age; status
  exclusion happens upstream in the ranking, so the summary already reflects only `new` trends). `BRIEF_SCHEMA_
  VERSION` stays **1** (no frontmatter *field* added/removed — `date`/`summary`/`store`/`ranking`/`schemaVersion`
  unchanged; only the `ranking:` *string* and body content change; the surfacing hook still reads `date`+`summary`).
 ### S-cli — `scripts/trends/src/cli.ts` (EDIT)
 - **`act` / `skip` / `reset` subcommands** (set lifecycle status by id):
  - `act --id <id> [--store <path>]` → `setStatus(store, id, "acted")`; `skip …` → `"skipped"`; `reset …` →
    `"new"`. Each: load → setStatus → if `found` save + print `Marked <id> <status>` (exit 0); if **not found**
    print `error: no trend with id: <id>` to stderr + **exit 2**. A missing/`true` `--id` → `usage('<cmd> needs
    --id <id>')` (exit 2). **Exit-code contract broadened (folded — plan-critic #2):** a not-found id is exit 2,
    which the existing contract documents as "usage error". Update the header doc-comment (`cli.ts:33`) to read
    *"0 on success, 2 on usage error or a not-found id (act/skip/reset)"* — a wrong `--id` value is an
    argument-class error, distinct from `capture`'s data-stream items (which stay in `errors[]`, never the exit
    code). A new exit code is **not** introduced (the CLI keeps its two codes).
 - **`brief` records surfacing (A1):** **hoist the load** (folded — plan-critic #1 / brief-reviewer #1): replace
  the inline `rankForBrief(loadStore(storePath), …)` (`cli.ts:286`) with **`const store = loadStore(storePath);
  const ranking = rankForBrief(store, pillars, day, { freshDays });`** — `cli.ts:286` does **not** currently bind
  a `store` variable (verified), so the surfacing edit needs this hoist or it references an undefined identifier.
  Then after `writeFileSync(path, md, …)` (`:290`), **unless `--no-mark`**: `markSurfaced(store, surfacedIds
  (ranking), day)` then `saveStore(storePath, store)` — the **hoisted `store`** holds the full inventory, so
  acted/skipped records (filtered from the ranking but still in the store) are preserved on resave; the `.md` is
  rendered from the pure `ranking` **before** the mutation. `const mark = flags["no-mark"] !== "true";` (a bare
  `--no-mark` → `"true"` → mark off). The `--json` output gains a **`marked`** count (trends whose seen-log this
  run incremented; `0` when `--no-mark`). `rankForBrief`/`renderBrief` are untouched — the mutation is purely at
  the edge.
 - **`capture` tally comment (`cli.ts:251-252`)** (folded — plan-critic #4): the broadened `AddResult.merged`
  (topics ∪ score-refresh) makes the existing comment *"a fold is … `merged` (existing gained topics)"* stale →
  update it to *"`merged` (existing gained topics and/or a refreshed score)"*. No tally-logic change (the loop
  already counts `res.merged`).
 - **Usage + header doc:** add the three new verbs + `[--no-mark]` to the `usage()` block (`:82-91`) and the
  header synopsis (`:5-13`); a one-line header note that `act`/`skip`/`reset` set a trend's lifecycle status, the
  brief excludes handled trends and records surfacing, and re-capture refreshes the score.
 ### Wiring (D-default — WIRE, mirrors R3a)
 - `agents/trend-spotter.md` (EDIT, **prose-only, minimal**): Step 4.5 already emits the per-item `score` (R3a);
  re-score is **automatic** (capture re-folds an existing trend with a fresh score → `addTrend` now refreshes it),
  so **no batch-shape change**. Add one prose line: re-capturing a known trend now **refreshes** its relevance
  score (timing decays), and the operator marks trends `acted`/`skipped` via the CLI so the brief stops
  re-surfacing handled work. Domain-general (no vendor/sector tokens). *(If a Section-16k grep targets the agent,
  it must be verified non-vacuous first; the recommended 16k greps target src files only — see gate below.)*
 - `scripts/trends/README.md` (EDIT): document the status lifecycle (`new`/`acted`/`skipped` + `act`/`skip`/`reset`),
  the seen-log (`surfacedCount`/`lastSurfacedAt`, per-day idempotent, brief-recorded), re-score-on-recapture
  (last-wins), and the brief's exclude-handled behaviour + `--no-mark`.
 - `scripts/test-runner.sh` (EDIT): bump `TRENDS_TESTS_FLOOR` (`:705`, currently 146) to the `tests N` line
  reported after Steps 1–6, **append** `+ RE-R3b: lifecycle +N` to the inline breakdown comment. Add
  **Section 16k** ("Trends Lifecycle Wiring", RE-R3b) **after Section 16j's closing block, before Section 18**
  (16j is the last 16x before the anti-erosion Section 18; preserve that order). Mirror 16j's shape:
  **unconditional**, deps-absent-safe (`grep -qF` + a non-vacuity self-test emitting **one** pass/fail). Recommended
  **6 emitters** (all on tracked src — no `tsx`): (1) self-test; (2) `export type TrendStatus` in `types.ts`;
  (3) `surfacedCount` in `types.ts` (seen-log field); (4) `export function markSurfaced` in `store.ts` (seen-log
  writer); (5) `effectiveStatus` in `brief.ts` (the brief excludes handled); (6) `command === "act"` in `cli.ts`
  (the lifecycle verb). **6 unconditional emitters → bump `ASSERT_BASELINE_FLOOR` 99 → exactly 105** (`:1259`;
  "live recount" is the safety net; the expected value is the pinned 99 + 6 = 105). Update the header-enumeration
  prose chain by inserting the 16k clause between the 16j clause and the Section-18 clause.
 ## 4. Non-goals — what is OUT (deferred)
 - **Saturation scoring / first-mover-as-a-field** (the quantitative *use* of `surfacedCount`) — **slice (b)**.
  R3b **accumulates** the seen-log and shows a minimal `· sett Nx` hint, but it does **not** compute a saturation
  score, decay the composite by surfacings, or add a first-mover field. (b) reads R3b's accumulated data.
 - **Autonomous nightly trigger** (cron/launchd, headless entry — hull 1+6) — **slice (c)**. R3b adds no scheduler;
  it builds the lifecycle (c) will safely automate.
 - **Brief history surfacing / diff** ("what's new since yesterday" — hull 7) — **slice (d)**. The seen-log records
  *that* a trend was surfaced; the cross-brief **diff** is (d). R3b's `· sett Nx` is a per-record count, not a
  day-over-day diff.
 - **Research-deepening A1–A4** (plan → isolated workers → gap loop → curate) — **slice (e)**, behind the post-(d)
  re-evaluation gate.
 - **Mode-segmented ranking / `--mode` filter** — still OUT (R3a non-goal, unchanged).
 - **Re-score semantics other than last-wins** (monotone / timing-only refresh) — OUT (A2 chose last-wins).
 - **A `status`/`surfaced*` input on the capture/`add` path** — OUT. Lifecycle is set **post-capture** by
  `act`/`skip`/`reset`; capture never ingests a status. `TrendInput` is unchanged.
 - **`act`/`skip` by title/url** (deriving the id) — OUT for R3b; `--id` only (the id is shown in the brief +
  `list --json`). A title/url alias is a later ergonomic nice-to-have.
 - **Auto-acting on publish** (wiring `act` into `/linkedin:post` / the post-tracking flow) — OUT. R3b ships the
  CLI verbs; auto-marking from the content commands is a separate plugin-surface slice.
 - **`BRIEF_SCHEMA_VERSION` bump** — OUT (no frontmatter field changes); Open Q.
 - **New source file / new agent / new command** — none. R3b is edits to **four** existing `src/*.ts` (`types`,
  `store`, `brief`, `cli`) + their tests + one agent (prose) + README + gate. `score.ts` + `item.ts` are
  **untouched** (re-score reuses the R3a capture path). Counts stay 27/19/29.
 ## 5. Boundaries / invariants (must hold)
 - **TDD iron law (two-phase RED):** failing tests land **BEFORE** implementation. Phase A — true logic-RED for
  the re-score + migration parts of `store.test` (existing `addTrend`/`loadStore`, inline fixtures), all of
  `brief.test` (behaviour change to existing `rankForBrief`/`renderBrief`), and `cli.test` (subprocess: `act`/`skip`
  print a usage/unknown-command error today → assertion-RED). Phase B — `setStatus`/`markSurfaced`/`effectiveStatus`
  reference new `store.ts` exports → land non-throwing stubs first (Node16 ESM throws a missing named import at
  module-load), then record value-assertion RED against the stubs. The plan does **not** claim a single
  "everything fails before any code" run.
 - **`rankForBrief` stays pure (A1):** no fs, no clock, no env, no AI, **no store mutation**. The status filter is
  a pure read of `effectiveStatus`. The seen-log **write** lives only in the `brief` CLI edge (after the pure
  ranking), guarded by `--no-mark`. `markSurfaced`/`setStatus`/`effectiveStatus`/`surfacedIds` are all pure.
 - **One composite owner (unchanged):** re-score reuses the **already-built** capture path
  (`itemToInput`→`scoreEnvelope`→`composite`+`band`); R3b adds **no new arithmetic** and does not touch `score.ts`.
 - **Provenance discipline (A2):** `source`, `capturedAt`, and the first `publishedAt` stay **first-sight**; only
  `score` is mutable on re-capture; `status`/`surfacedCount`/`lastSurfacedAt` are mutated only by their own
  owners (`setStatus`/`markSurfaced`), never by `addTrend`.
 - **Per-day-idempotent surfacing:** running `brief` twice on the same `today` increments `surfacedCount` **at most
  once** (`markSurfaced` skips records whose `lastSurfacedAt === today`). Re-generating today's brief is a no-op on
  the seen-log. *(This is the determinism guarantee for the autonomous loop: an idempotent daily mark.)*
 - **No false-merge on re-capture:** a re-capture with a **byte-identical** score → `merged:false` (the
  `JSON.stringify` compare); only a genuine topic-union or score-change flips `merged`.
 - **Determinism (brief):** same `(store, pillars, today, freshDays)` → byte-identical `renderBrief` output (the
  status filter + `surfacedToken` + id are deterministic reads of the store; the composite sort total order from
  R3a holds). The CLI's surfacing mutation is **outside** the pure render.
 - **Lossless additive migration (both directions):** a v3 store loads as v4 with records **untouched** (no
  `status`/`surfaced*` invented); round-trip writes `schemaVersion: 4`; a v4 store is idempotent; the three new
  optional fields **survive a load+resave**. Mirrors the R3a v2→v3 proof (`store.test.ts`, `(RE-R3a / score
  v2→v3)` block) with the literals flipped `3`→`4`.
 - **Hook unaffected:** the SessionStart surfacing reads `date`+`summary` only and **never shells out to tsx**.
  R3b touches neither the hook nor the frontmatter schema (`BRIEF_SCHEMA_VERSION` stays 1), so surfacing is
  unchanged. The existing hook suite must still pass untouched (regression sanity; R3b adds no hook test).
 - **Domain-general:** Section 17 de-niche stays green; the `trend-spotter.md` prose carries only generic
  lifecycle wording (`acted`/`skipped`/"refresh the score"), no vendor/sector tokens.
 - **No SSOT change:** `references/trend-scoring-modes.md` untouched (R3b changes no scoring math).
 - **No store-query change:** `queryByTopic`/`history`/`newestCaptureDate` untouched. *(The CLI `status`
  subcommand — the staleness reader — is unrelated to the new `TrendStatus` lifecycle type; the name collision is
  pre-existing and not reconciled here.)*
 - **Pathguard:** all edits are to **existing** files (no new `.mjs` under `hooks/scripts/`; no new `.ts` — R3b
  adds no source file). `.gitignore` already covers `scripts/trends/{node_modules,build}`.
 - **Counts** (refs/agents/commands 27/19/29) unchanged. **Recounted live at land**, never pinned/guessed.
 ## 6. Success criteria (testable)
 - **SC1 (status field + effectiveStatus + setStatus)** — `effectiveStatus({…no status})` is `"new"`;
  `effectiveStatus({…status:"acted"})` is `"acted"`. `setStatus(store, id, "skipped")` on a present id sets the
  record's `status` and returns `{ found:true }`; on an absent id returns `{ found:false }` (no throw, store
  unchanged); a `reset` sets `status:"new"` explicitly.
 - **SC2 (re-score last-wins, no false-merge, status/provenance untouched)** — `addTrend(store, dupInput)` where
  `dupInput` has the same title+url and a **different** `score` → the stored `score` is **replaced**, `merged:true`,
  `added:false`, topics still unioned, and `source`/`capturedAt`/`publishedAt`/`status`/`surfacedCount` are
  **unchanged**. A re-capture with a **byte-identical** score (and no new topics) → `merged:false`. A duplicate
  with **no** `score` → stored score unchanged. A re-capture of an **acted** trend with a new score → score
  updated, **status stays `acted`**. **At the CLI edge (folded — plan-critic #4):** a `capture` of a scored item,
  then a `capture` of the same title+url with a **changed** score → the second `capture --json` reports
  `merged:1`, and `list --json` shows the **updated** composite (a subprocess test, not only the manual §7 step).
 - **SC3 (markSurfaced + per-day idempotency)** — `markSurfaced(store, [idA, idC], "2026-06-25")` increments
  `surfacedCount` (absent⇒0→1) and sets `lastSurfacedAt:"2026-06-25"` on A and C only (B untouched), returns
  `marked:2`; a second `markSurfaced` with the **same `today`** → `marked:0`, counts unchanged; a third with a
  **later** `today` → increments again, `lastSurfacedAt` advances; an id not in the store is silently skipped.
 - **SC4 (migration v3→v4, both directions)** — a `schemaVersion:3` store with records lacking the lifecycle
  fields loads as **v4**, records intact, **no field invented**; round-trip `loadStore→saveStore` writes
  `schemaVersion:4`; a v4 store with lifecycle fields loads idempotent; **the three new fields survive
  load+resave** (byte-identical). Mirrors the R3a `(RE-R3a / score v2→v3)` block, retitled `(RE-R3b / lifecycle
  v3→v4)`, every `schemaVersion` literal flipped `3`→`4`.
 - **SC5 (brief excludes acted/skipped)** — given a store with `new`, `acted`, and `skipped` records all matching
  pillars + fresh: `rankForBrief` places **only** the `new` ones in `topMatches`/`singleMatches`/`olderMatched`;
  `totals.trends` still equals the **full** store count; a store whose only matches are `acted`/`skipped` →
  empty buckets + the `briefSummary` "no fresh signals" line; the order among the surviving `new` records is the
  R3a composite total order (unchanged).
 - **SC6 (brief render: id + surfaced marker + descriptor)** — `renderBrief` emits the **full pinned line shapes**
  (§3): a top entry ends with `· \`<id>\`` (after `Pillarer: …`); a bullet ends with `· \`<id>\`` (after `🔗
  <url>`); a record with `surfacedCount >= 2` shows `· sett <N>x` (after the score token), one with
  `surfacedCount` 0/1/absent shows **no** surfaced token — both asserted as **full lines**. The `ranking:`
  descriptor equals the pinned string ending `; excludes acted/skipped` verbatim. `surfacedIds(ranking)` returns
  exactly the ids of `topMatches ∪ singleMatches ∪ olderMatched.slice(0,5)`. Two `renderBrief` calls on the same
  input are byte-identical.
 - **SC7 (CLI act/skip/reset)** — `act --id <id> --store <tmp>` then `list --store <tmp> --json` shows the record
  with `status:"acted"`; `skip` → `"skipped"`; `reset` → `"new"`; an **unknown** id → stderr error + **exit 2**,
  store unchanged; a missing `--id` → usage + exit 2.
 - **SC8 (CLI brief marks surfaced + --no-mark + exclusion end-to-end)** — `brief --pillars … --store <tmp>` on a
  store with fresh matches → the written `.md` **omits** any acted/skipped record; a following `list --store <tmp>
  --json` shows the surfaced trends with `surfacedCount:1` + today's `lastSurfacedAt`, and the `--json` output
  carries `marked:<n>`; a **second** `brief` the same day → `marked:0`, counts unchanged (idempotent);
  `brief --no-mark --store <tmp>` on a fresh store → `marked:0`, **no `surfacedCount` written** (store's trends
  unchanged save for nothing).
 - **SC9 (gate + wiring + de-niche)** — `bash scripts/test-runner.sh` → `FAIL=0`: trends suite green at the bumped
  `TRENDS_TESTS_FLOOR`; new **Section 16k** green (`TrendStatus` + `surfacedCount` in `types.ts`, `markSurfaced`
  in `store.ts`, `effectiveStatus` in `brief.ts`, `command === "act"` in `cli.ts`, non-vacuity self-test);
  `ASSERT_BASELINE_FLOOR` = **105** (99 + 6); Section 17 de-niche green; counts 27/19/29; the hook suite still
  green untouched.
 ## 7. Verification
 **Deterministic:** `bash scripts/test-runner.sh` → `FAIL=0`; trends suite ≥ new floor; Section 16k self-test +
 greps pass; `ASSERT_BASELINE_FLOOR` = 105; Section 17 de-niche green; ref/agent/command counts unchanged.
 **Regression sanity:** `node --test hooks/scripts/__tests__/*.test.mjs` → still green untouched (R3b touches no
 hook; adds no hook test).
 **Behavioural (manual):**
 1. `echo '[{"source":"tavily","title":"A","url":"https://e/a","topics":["ai","gov"],"publishedAt":"<~2d ago>",
   "score":{"mode":"kortform","dimensions":{"pillar":9,"audience":8,"timing":9,"angle":7,"authority":6}}}]'
   | node --import tsx src/cli.ts capture --store /tmp/r3b.json` — adds A.
 2. Re-`capture` A with a **lower** timing (`"timing":3`) → `list --store /tmp/r3b.json --json` shows A's
   composite **dropped** (re-score last-wins); the capture tally reports `merged:1`.
 3. `node --import tsx src/cli.ts brief --pillars ai,gov --store /tmp/r3b.json --out /tmp/r3b-brief --json` →
   confirm `marked:1`; `list --json` shows A with `surfacedCount:1` + today's `lastSurfacedAt`; the entry line
   shows `· \`<id>\``.
 4. Re-run the **same** `brief` → `marked:0` (idempotent); `surfacedCount` still 1.
 5. `node --import tsx src/cli.ts act --id <A's id> --store /tmp/r3b.json` → re-run `brief` → A is **absent** from
   the written `.md`; the summary reports no fresh signals (if A was the only match).
 6. `node --import tsx src/cli.ts reset --id <A's id> --store /tmp/r3b.json` → A reappears in the brief.
 7. `brief --no-mark` on a fresh store → `marked:0`, `surfacedCount` not written.
 ## 8. Open questions for the go-gate
 Three architectural decisions are **CONFIRMED** (operator, AskUserQuestion 2026-06-25): **A1** on-record seen-log,
 the `brief` CLI records surfacing (`rankForBrief` pure, `--no-mark` dry-run); **A2** re-score last-wins (score the
 one mutable field; status not reset); **A3** acted/skipped excluded from the brief. Residual decisions, all baked
 to the recommended default — confirm or redirect with "Go":
 - **D1 — status values `new`/`acted`/`skipped`, absent⇒new (omit on add)?** YES (rec). A 3-state lifecycle; a
  freshly-captured trend is implicitly `new` (field omitted); `reset` sets `"new"` explicitly. Re-open only if a
  `published`/`drafted` distinction is wanted (the plugin tracks posts elsewhere — kept out of the trend store).
 - **D2 — `AddResult.merged` broadened (topics ∪ score-refresh), no new flag?** YES (rec). Keeps the 2-flag shape;
  the capture tally's "N merged" honestly means "N existing records updated". Re-open only if `rescored` must be
  counted **separately** from topic-merges in the CLI tally.
 - **D3 — include `reset` (un-skip → new)?** YES (rec). Symmetric + cheap; the operator changes their mind. Drop
  only to keep the verb set to two.
 - **D4 — show the trend `id` in brief entries?** YES (rec). The status feature is **inoperable** otherwise — the
  operator needs the id to `act`/`skip`. Shown in backticks for copy-paste. Alternative: omit, and require
  `list --json` to find ids (clunky).
 - **D5 — minimal `· sett Nx` marker when `surfacedCount >= 2`?** YES (rec). Keeps the seen-log **honest/visible**
  in R3b (otherwise it is an invisible schema-only accumulation — the anti-pattern R3a warned of) without
  straying into (b)'s saturation scoring or (d)'s diff. The `>= 2` floor means a first/second sighting is silent.
  Drop only if any visible surfaced signal should wait for (b).
 - **D6 — `act`/`skip` identify by `--id` only?** YES (rec). Store-native; the id is shown in the brief +
  `list --json`. A title/url alias is a deferred nice-to-have.
 - **D7 — which entries count as "surfaced"?** The entries `renderBrief` **actually shows**: `topMatches ∪
  singleMatches ∪ olderMatched.slice(0,5)` (rec). Matches what the operator saw; the older-bucket cap mirrors the
  render's `.slice(0,5)`.
 - **D8 — `BRIEF_SCHEMA_VERSION` 1→2?** NO (rec). No frontmatter field added/removed (the hook reads only
  `date`+`summary`). Re-open only if the artifact should self-announce the exclude-handled change.
 - **D9 — commit split?** Single code commit (rec) — R3b's lifecycle (re-score/status/seen-log) is tightly
  coupled; the R3a data-then-visible split would land an invisible cut. Docs commit first, then one code commit.
 ## 9. Light-Voyage review — folded
 Three Opus reviewers ran on the drafts, each verifying claims against live code. **scope-guardian: ALIGNED**
 (every SC1–SC9 traces to a step; zero creep, zero gaps; all §4 non-goals held; counts 27/19/29 verified live;
 `score.ts`/`item.ts`-untouched verified — `itemToInput` already builds the envelope on every capture incl.
 re-capture; A1/A2/A3 consistent across every step; the R3a-block reconcile is a necessary prerequisite, not creep;
 2 MINOR plan line-cite nits). **brief-reviewer: PROCEED_WITH_RISKS** (all nine load-bearing claims verified TRUE —
 incl. the v3→v4 reconcile complete for **every** breaking literal, enumerated; 1 MEDIUM + 3 LOW). **plan-critic:
 PROCEED_WITH_RISKS (78/B)** (the two-phase RED, the atomic bump+reconcile, the `merged` broadening's
 non-regression, the `surfacedIds` formula, and the gate arithmetic all verified correct; 1 MAJOR + 5 MINOR).
 All findings folded; see `plan-re-r3b.md §Plan-critic — folded` for per-finding resolution. Headlines:
 - **[MAJOR/MEDIUM, folded — both reviewers] the `brief` CLI's `store` binding does not exist.** `cli.ts:286`
  inlines `rankForBrief(loadStore(storePath), …)` — there is no `const store`, so the `markSurfaced(store, …)` /
  `saveStore(storePath, store)` edit referenced an undefined identifier. → §3 S-cli + plan Step 5 now **hoist**
  `const store = loadStore(storePath)` and pass it to `rankForBrief`; R5 wording corrected.
 - **[MINOR, folded — plan-critic #2] not-found id → exit 2 contradicted the documented exit-code contract.** →
  the `cli.ts:33` doc-comment is **broadened** to *"2 on usage error or a not-found id (act/skip/reset)"* (a wrong
  `--id` is an argument-class error, distinct from `capture`'s data items); no third exit code introduced (§3 S-cli).
 - **[MINOR, folded — plan-critic #3] `· sett Nx` off-by-one.** Render precedes the surfacing mutation, so the
  token reflects the **prior-day** count. → the **prior-day semantic** is now stated explicitly (§3 S-brief + the
  README): `· sett Nx` = "shown on N prior distinct days".
 - **[MINOR, folded — plan-critic #4] `capture` tally comment stale + the re-score CLI tally untested.** → §3 S-cli
  updates the `cli.ts:251-252` comment (`merged` = topics ∪ score-refresh); SC2 adds a subprocess assertion that a
  re-captured changed-score item reports `merged:1` with the updated composite.
 - **[MINOR, folded — plan-critic #5] Step 2 used `TrendStatus` before Step 3 defined it.** → the plan is
  reordered: Step 2 adds the `TrendStatus` type + the three fields to `types.ts` **first** (then the `store.ts`
  functions); Step 3 isolates the atomic `SCHEMA_VERSION` bump + the R3a-block reconcile.
 - **[LOW, folded — brief-reviewer #4] forward-debt: the new R3b migration block hard-coded `4`** (perpetuating the
  reconcile-cycle this slice pays for R3a). → the new block's **target + idempotent** assertions commit against
  `SCHEMA_VERSION` (the hard-`4` is the Step-1 RED device only; the v3 **input** fixtures stay literal `3`),
  breaking the cycle so R3c won't pay it.
 - **[LOW, folded] cosmetic literal/title drift** — `store.test.ts:571`/`:598` titles + `:570` comment flipped to
  "the current version"; `cli.test.ts:247`'s inert `schemaVersion:2` fixture added to the scope-fence enumeration;
  the two plan line-cites corrected to `~:1235` (after 16j's block) / `:1237` (Section 18 header).
--- a/Show more
+++ b/Show more