Kjell Tore Guttormsen
0907b2b92d
SessionStart now warns (>=7d, warn-only) when the persistent trend store's newest capture is stale, firing ONLY when the store already holds captures (a never-scanned user is never nagged). Neutral wording — "scan for trends" hits trend-spotter's own trigger; no hardcoded beat (de-niche invariant). - store.ts: newestCaptureDate() — pure max-capturedAt staleness signal (SSOT) - cli.ts: status [--json] subcommand (count + newest + daysStale) - session-start.mjs: trendsNewestCapture() reads trends.json as raw JSON (no tsx spawn at session start) + the reminder line, beside import-staleness - tests: +3 store tests (newestCaptureDate) + hook subprocess test (3 cases: >=7d fires, <7d silent, absent/empty silent + no crash) - test-runner.sh: trends floor 21->24 Verified: trends 24/24 · all hook tests 131/131 · gate 89/0/0 · real render confirms "Trend signals are N days old. Scan for trends…". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RigJBiRFNtFZKCz21qNbQ4 |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
linkedin-trends-store
Persistent trend store — the foundation layer of the research engine (retning §5). A topic-tagged, provenance-bearing inventory of trend signals captured over time, so the engine accumulates history instead of starting amnesiac each session.
Twin of scripts/specifics-bank: same deterministic
store / dedup / query discipline, different dedupe key — a trend is identified by
its normalized title+URL, not by free-text content.
Generic by architecture
Nothing niche-specific lives here. A TrendRecord carries free-form topics
tags and a free-form source string; which topics matter and which sources
to poll are decided upstream (config/profile + the capture agent), never
hard-coded in this module. The same store serves any niche.
Data location
The store lives under the per-user data dir (M0 data-path convention), so trend history survives plugin upgrades/reinstalls:
${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends/trends.json
LINKEDIN_STUDIO_DATA overrides the root. No path is hard-coded in prose.
Record shape (minimal generic core)
interface TrendRecord {
id: string; // sha256(normalized title+url).slice(0,12) — also the dedupe key
title: string; // headline, verbatim
url: string; // source URL, verbatim
source: string; // "tavily" | "websearch" | "manual" | <mcp-name>
capturedAt: string; // ISO-8601 date
topics: string[]; // query tags; unioned across re-captures
summary?: string; // optional, verbatim
}
Fields (relevance score, first-mover timing, status) can be added in a later slice without breaking the shape.
CLI
# Capture a freshly-polled trend (dedupes on title+url; unions topics on re-capture)
node --import tsx src/cli.ts add \
--title "Agentic workflows hit production" \
--url "https://example.com/agentic" \
--topics "agents,engineering" --source tavily \
--summary "Teams ship multi-step agents past the demo stage."
# Topic-scoped history — trends matching these topics, ranked by overlap then recency
node --import tsx src/cli.ts query --topics "agents,engineering" [--json]
# Time-scoped history — newest first, optionally windowed/capped
node --import tsx src/cli.ts list [--since 2026-06-01] [--limit 10] [--json]
Re-running add with the same title+url never appends a duplicate.
Tests
cd scripts/trends
npm install
npm test # deterministic store: normalize/id, load/save, dedup+union, query, history
npm run build