The security review of 39d874a (FRE-369) found the address fix recorded
the wrong thing twice. Both are fixed here; the branch is the same one
under review, this commit does not rewrite it.
Q1 — the first x-forwarded-for hop is attacker-chosen text. In
client → Cloudflare → same-host proxy → app, both proxies *append*, so
the header arrives as `<client spoof…>, <true client>, <CF edge>` and
`split(",")[0]` took the sender's own invention — the loopback-peer gate
was sound, the hop selection defeated it. Preference is now
`cf-connecting-ip` (Cloudflare overwrites it, so a client value never
survives the edge), then x-forwarded-for counted from the right with one
trusted hop discounted, then the direct peer. Every candidate must parse
as an address. h3's `getRequestIP(…, { xForwardedFor: true })` has the
same leftmost flaw and is documented as not a fix.
Q4 — the table held full client addresses indefinitely. Every analytics
entry now passes through `truncateIpAddress` in `enrichAnalyticsEntry`
(IPv4 /24, IPv6 /56, unparseable dropped), so no writer can persist a
full address by accident. Retention got the schedule it never had:
`/api/analytics/retention` on a daily Vercel cron, Bearer-authenticated
and fail-closed, with the window parameterised (the old
`cleanupOldAnalytics` spliced the number into the SQL). Default 365 days
rather than the review's 90 so enabling the cron is not itself a
destructive event — the tighter window is an operational decision, named
on the task.
Also from the review: the module doc now forbids feeding this helper into
any security decision; `isLoopbackAddress` parses instead of
string-matching (`::ffff:127.9.9.9`, `0:0:0:0:0:0:0:1`); and `host` is
normalised (lowercased, port stripped) so `nook.freno.me:443` cannot
silently miss the `host = ?` scope. The weekly loopback caveat matches
the truncated shapes writers produce now, and says plainly that "unique
visitors" counts prefixes.
Marketing tree
One voice, one place. Every later artifact draws on positioning.md — do not
invent framing per-asset.
positioning.md # source of truth: wedge, voice, banned phrasings, approved claims
calendar.json # scheduled pushes: date, channel, status
briefs/<channel>.md # per-channel rules, format, limits, what "good" looks like
drafts/<id>/ # agent output: copy.md, assets/, rationale.md
pending/ approved/ posted/ # human gate by directory move
metrics/weekly.md # funnel snapshot, generated
listening.md # buying-intent threads + drafted replies
Hard rule
approved/ is the only thing a human ever publishes from. Nothing posts itself.
Workflow: agent drafts into drafts/<id>/ → moves to pending/ when complete →
a human reviews and moves it to approved/ → the human publishes from approved/
under their own account → the artifact (or a pointer) lands in posted/.
Nothing in drafts/ or pending/ is ever publishable, by anyone, by any means.
The weekly read
bun --env-file=.env scripts/weekly-metrics.ts (or bun run metrics:weekly)
rewrites metrics/weekly.md from the live databases: the staged funnel, the
campaign breakdown (getAnalyticsSummary.topCampaigns' grouping), and the one
stage that moved. It needs TURSO_DB_URL, TURSO_DB_TOKEN, NOOK_DB_URL and
NOOK_DB_TOKEN — no other production secret. The file is generated; never
hand-edit it. The numbers are engineering's; the interpretation is the CMO's.