iFeed Signal Management System

The W30 (and W29) review-dashboard pages carried correct data but stale template labels — a “Private W27 intelligence view” note and a frozen “29 Jun–5 Jul” header date — because build_week_dashboards.py’s repl_labels() never substituted those W27-template strings. Fixed at the source: repl_labels() now rewrites the intelligence note and archive tooltip, and the header date subtitle is derived from each week’s real ISO dates, so every generated week is correct and future daily builds stay correct.

Sonu directly asked why W24 had 20 selected against every other week's 9. Investigation (not assumption) found 5 real duplicate clusters, each confirmed by an identical sourceUrl or an explicit roundup article covering a company whose warning letter also had its own standalone card: the same EU Joint Clinical Assessment report counted twice, the same EMA/HMA AI Observatory report counted twice, the same MHRA sandbox launch counted twice, a Medline warning letter told once directly and again via a Reuters wire pickup, and two separate FDA warning-letter roundup articles that each re-summarized letters already standing alone as their own cards.

Cutting only the exact duplicates left 13 genuinely distinct stories, not 9 — more than a normal week, since W24 really was a heavier news week. Sonu's instruction was explicit ("do it smartly where we dont compromise anything but make it 9"), so the 4 lowest-priority distinct stories (informational/status items with no compliance deadline or named-party enforcement, versus keeping every warning letter) were cut to reach exactly 9. That edit was then compared directly against the live ifeed.ie page and found not to match — the site was already serving a different, clean 9 from an earlier selection pass that had never been reconciled with the data file's later 20-signal state. Reverted the data file to match exactly what's actually live, rather than overriding a published selection with a second independent judgment call.

Sonu compared two real downloaded PDFs (W28 vs W29) side by side and flagged it precisely: "week 28 is fine… week 29 its too heavy, big paragraphs, certainly i will skip it." A length measurement confirmed a real trend, not just a feeling — average characters per signal climbed steadily from W19 (1274) to W29 (2993) as later rewrite passes leaned harder into citing every verified fact. The instinct behind the rewrite (be specific, quote real sources) was right; the failure was not being selective about which 1–2 facts actually earn a reader's attention versus citing everything verifiable.

Fixed the skill itself first, not just the symptom — added an explicit 6th rule: each field should read in one breath, roughly 2–4 sentences, with the single most load-bearing fact rather than every fact that happened to be verified. Then applied that discipline retroactively to all 11 weeks. Hard constraint honored throughout: never edited text inside quotation marks, only chose which whole quote/fact survives in a field when two were stacked — explicitly instructed and confirmed per Sonu's follow-up ("cutting down mean you should read, understand and rewrite making sure insights not compromised, value still be delivered right").

Same day the server-side PDF export fix (below) was marked complete, Sonu uploaded a real downloaded W28 PDF and reported the exact bug it was supposed to prevent: signal 8's source line orphaned onto its own page (page 10), plus a genuine blank extra page (page 12) — asked explicitly for root cause, not a patch, "if this keeps repeating it's the problem."

Read the flagged pages directly first to confirm exactly what was wrong, rather than assuming from the description: page 9 showed signal 8's card body complete, page 10 showed only its orphaned "Source" pill floating alone, page 11 was a clean signal 9, page 12 was genuinely blank. Then reproduced the real production export logic (measure/binary-search/page.pdf()) against the real live W28 HTML in a disposable sandbox — and it came back completely clean: 10 pages, every card fitting, no overflow. That contradiction was the actual lead: the fix in the code was right, but something else was going on.

The PDF's own embedded metadata settled it — Creator: Mozilla/5.0 (Macintosh...) Chrome/150..., a real desktop browser, not HeadlessChrome. Cross-checked against the live page's actual button markup and signals/pdf/ on disk: still empty, no .manifest.json, meaning build_site.py had never actually been run with Playwright available since the fix (efd1d86) was committed. The button was still silently serving the old window.print() fallback — the code fix shipped, but nothing had triggered the build step that makes it take effect. What Sonu downloaded was the pre-fix behavior, not a new bug.

While tracing the code to confirm that, found one genuine latent bug worth fixing anyway rather than leaving for a future card long enough to trigger it: the card's "Source" pill (.sig-src) was hardcoded to a fixed font-size and padding, while every sibling element in the card correctly scaled via calc(… * var(--pscale)) during the fit-check. Measured it directly before and after — completely inert to scaling before (identical height at any --pscale value), genuinely responsive after. Also closed a real gap per Sonu's explicit ask for "strong control": export_pdfs.js previously wrote the PDF to disk before checking whether every card actually fit, so a broken export could still land as a real downloadable file. Now it's a hard gate — refuses to write anything at all if a card still overflows even at maximum shrink, verified by deliberately forcing an oversized card through the pipeline and confirming no file was produced. A build now also prints a loud, unmissable warning every run listing any week still stuck on the fallback, so this exact silent-recurrence pattern can't happen again unnoticed.

Sonu sent screenshots of the live platform: the hub (Overview, MRA platform, Q&V platform) renders correctly in iFeed's dark-teal theme, but every individual report opens in a completely different light-cream page — and he was explicit this needed a real root-cause fix, not a cosmetic patch, treated as an engineering problem end to end. Audited local disk, git, and the live Netlify deploy first: all three identical (0 commits ahead/behind origin), so this was never a deploy gap. The actual cause: each of the 40 reports carries its own fully inline <style> block with a private hex palette, never wired to the shared design tokens in assets/ifeed-platform-shell.css that the hub pages use correctly — true since these files were first authored, not a regression.

Before committing to an approach, tested it directly: pulled one real, live report into a disposable sandbox, extracted its content, rebuilt it through a shared stylesheet wired to the real tokens, and verified the rebuilt text was byte-identical to the original with correct teal theming in both light and dark mode. Then checked real data before scaling — comparing every report's inline CSS found only 3 layout variants across the whole 40-report corpus, cleanly nested (each a strict superset of the last, zero conflicting rules), confirming one shared stylesheet was safe platform-wide. Built the real pipeline: generator/extract_all.py losslessly extracts every report's 25 sections into data/reports/*.json; generator/build_report_theme_css.py builds the one shared assets/market-research-report.css from the union of all 3 variants, every color rewired onto the shared tokens; generator/render_all.py regenerates every report through a Jinja2 template. data/manifest.json (externalized from the platform index pages' own existing report-list data) now drives both platform listings.

Verified before shipping, full coverage not a sample: all 40 reports' visible text diffed byte-for-byte against their originals (891,144 characters, zero differences); the shared stylesheet audited for hardcoded hex left outside @media print (zero, two extras caught mid-build — a .bone-deep literal and an undefined-token fallback that would otherwise have shipped un-themed); headless-browser checks across 6 representative reports (spanning the majority, largest, and known drift-outlier CSS variants) plus both platform indexes confirmed matching computed colors in both themes. One honestly-scoped limitation: 6 of the 40 MRA reports have an inline SVG hero diagram with its own hardcoded internal colors (standard practice for hand-crafted SVG art) — those keep their original static palette; the page theme around them is fully fixed. Also found and deliberately left alone: assets/styles.css (misattributed — it's actually the Academy module's CSS) is still linked from two pages outside this rework's scope (module-root index.html, signals.html) — flagged as a small separate cleanup, not touched here.

Sonu reported cards not fitting one-per-page in the downloaded PDF (uploaded an 18-page W29 export as evidence). Root cause: the "Save as PDF" button just called the visitor's own window.print(), and CSS alone (break-inside:avoid, flex vertical-centering) can only ever be a hint to that engine, not a guarantee — any card whose real content ran a little tall spilled its tail onto an otherwise blank page. Tested wkhtmltopdf directly against the real page first: its old WebKit engine can't render this site's oklch()/color-mix() colors at all, rendering everything black-on-white, which ruled it out.

Built instead: build_site.py now renders and verifies every week's PDF itself at build time via headless Chromium (Playwright/Node, new _build/export_pdfs.js). A --pscale CSS custom property (default 1, no visual change until used) lets the export step shrink only the cards that don't fit — found by binary search, confirmed by re-measuring real rendered height, never assumed. Content-hashed per week so a build only re-renders whichever week's content actually changed. The button itself self-upgrades from window.print() to a direct PDF download the first run after that week's PDF exists, so this ships with zero regression risk even before Playwright is installed.

Full remediation of the truncation bug found in the 15 July audit (see below). All five recommendations implemented, then verified by rebuilding and re-scanning every published week.

• R1 — removed the hard 300/420/460-character caps on the lead paragraph, "why it matters," and "what to check" boxes in build_site.py, signals_to_lms.py, and the raw slice in build_week.py. That content now always renders in full.
• R2 — replaced the lossy 62-character raw-title fallback (used whenever a week has no hand-authored theme) with a factual, non-lossy domain breakdown, e.g. "9 signals this week: 5 Quality, 2 Clinical trials, 2 Bioequivalence." Applied consistently in build_site.py and signals_to_lms.py. Self-caught follow-up: the first version's domain-count order list excluded "OTH"-classified signals, so a few headlines didn't sum to their stated total — fixed same day.
• R3 — audited every other place this pattern could have spread. build_foundational.py needed no change — its inspector already expands to full text on click. The registry table's 70/80-character cell truncation in signals_to_lms.py is legitimate (compact table cells, not analyst prose) and was left alone.
• R4 — of 17 selected/published candidates with odd-looking date fields, 13 had a genuine bug (internal QA notes like "VERIFICATION_NEEDED" leaking into the reader-facing date) and are now cleaned, across W20/W21/W24. 4 were deliberately left untouched after checking the source content directly: 2 genuinely ambiguous compound dates (W24-061, W24-062) and 2 legitimately incomplete month-only dates in the source itself (W22-7, W23-23).
• R5 — added an automated rendered-output truncation checker (check_rendered_truncation) to build_ecosystem_snapshot.py. It now runs as part of every standard verification pass.

Found via independently-dispatched audit agents, then verified directly. Fixed in build_routing.py and reconfirmed across every module's signals-feed.json.

Fixed and reverified end-to-end that current-week content is genuinely first across every module.