From e4dfd2a2db5fb02dc257f05d34c1231f4fb101e6 Mon Sep 17 00:00:00 2001 From: Rene Fichtmueller Date: Sun, 5 Apr 2026 01:26:09 +0200 Subject: [PATCH] feat(blog): AEM/APM pipeline steps + SLL context builder + LinkedIn v2 prompts --- packages/api/src/llm/fo-blog-pipeline.ts | 1070 +++++++++++++++++++++- 1 file changed, 1021 insertions(+), 49 deletions(-) diff --git a/packages/api/src/llm/fo-blog-pipeline.ts b/packages/api/src/llm/fo-blog-pipeline.ts index cdde9f4..d9c4692 100644 --- a/packages/api/src/llm/fo-blog-pipeline.ts +++ b/packages/api/src/llm/fo-blog-pipeline.ts @@ -131,6 +131,41 @@ DATA INTEGRITY RULES (ABSOLUTE — harder than anything else on this list): HARD RULES (non-negotiable — article FAILS QA without these): +════════════════════════════════════════════════════════ +CATALOG CONTENT — ABSOLUTE HARD FAIL (kills article immediately) +════════════════════════════════════════════════════════ + +These patterns make a blog into a whitepaper or catalog. Never produce them: +- More than 2 products compared or described in parallel — this is a product catalog, not a blog +- Tables of any kind (spec tables, comparison tables, pricing tables) — ALWAYS wrong format +- "BUY / DO NOT BUY" / "Verdict: BUY" / "Recommendation: SKIP" — analyst language, not engineer voice +- Procurement playbook sections: "when to buy", "lock in pricing", "negotiate volume", "budget considerations" +- News dump paragraphs: listing industry headlines without specific insight +- Category sections: "Form Factor 1:", "Form Factor 2:", "Form Factor 3:" — catalog navigation, not writing +- Structure drift: Introduction + Background + Analysis + Comparison + Recommendation + Conclusion + → This is a business report. A blog has ONE thread. + +WHY: The Flexoptix blog is NOT a buying guide, a product catalog, a Gartner report, or a vendor comparison matrix. +It is a senior engineer showing what actually happens in production. +One idea. Developed fully. No shopping list at the end. + +ONE CORE IDEA RULE: +Every article has exactly ONE core thesis. Supporting observations are allowed. Parallel equal ideas are not. +If you find yourself developing 4+ equal ideas in parallel sections — you have written a framework, not an article. +Cut everything except the strongest idea. Develop it fully. End on it. + +════════════════════════════════════════════════════════ +SALES LANGUAGE — ABSOLUTE HARD FAIL +════════════════════════════════════════════════════════ + +Never produce these patterns: +- "BUY / DO NOT BUY", "Verdict: BUY", "Verdict: WAIT" — immediate delete +- "To avoid this, consider..." / "Make sure to..." / "You should always..." — teaching tone, not field experience +- "Best practices" of any kind — corporate training content, not Flexoptix blog +- "Key takeaways:" / "The main lesson here is:" — the article shows it. Never announce it. +- Justification language ("this is why compatible optics make sense") — state the observation, not the sales pitch +- Cost comparison framing as a buying signal ("at 30x price difference, ROI is clear") — this is a sales deck + ════════════════════════════════════════════════════════ SPEC DUMP — ABSOLUTE HARD FAIL ════════════════════════════════════════════════════════ @@ -548,19 +583,26 @@ Article: export const STEP6_TECHNICAL_DEEPENING = `Increase the technical depth of this article. -ADD where missing: -- Specific transceiver examples (100G-SR4, 100G-DR, 400G-FR4, 400ZR, 800G-DR8) -- Fiber types and connector details (LC vs MPO, polarity, cleaning) -- Power consumption differences (per port, per form factor) -- Density and breakout implications (4x100G from 400G, port count per RU) -- Power budget calculations (Tx - losses = Rx, margin check) -- Real reach limitations (not datasheet max, but reliable production reach) +ADD where missing (woven into PROSE ONLY — never as tables, lists, or comparison blocks): +- Fiber types and connector details (LC vs MPO, polarity, cleaning) — as narrative context +- Power consumption differences (per port, not per chassis) — as consequence in flow +- Power budget behavior (tight margins → why small imperfections surface) — as behavioral description +- Real reach limitations (not datasheet max, but why production reach is tighter) — as field observation + +DO NOT ADD (catalog drift): +- Specific transceiver SKU listings or product comparison blocks +- Tables comparing form factors, speeds, or specs +- "For form factor X: Y dBm, Z connectors, W watts" blocks +- Any structure that looks like a datasheet or procurement guide +- More than 2 product references in the article body REMOVE: -- Vague statements without numbers +- Vague statements without consequence - "May", "could", "typically" — replace with "is", "will", "does" - Generic descriptions that any reader could write themselves +CRITICAL: This step adds DEPTH — not WIDTH. One idea, developed more deeply. Not five new ideas added. + Article: {{ARTICLE}}`; @@ -574,15 +616,21 @@ ADD: - Clear positions on every technology mentioned - Challenge at least 1 common industry assumption - At least 1 statement that vendors would never publish -- Explicit BUY / WAIT / SKIP recommendations where relevant - Statements that experienced engineers nod at but marketing teams hate REMOVE: -- "It depends on your use case" — instead say WHAT it depends on specifically -- Hedging language ("could potentially", "in some cases") -- Both-sides-ism when one side is clearly better +- "BUY / DO NOT BUY" language of any kind — HARD BAN. This is analyst/sales content, not engineer voice. +- "Verdict: BUY", "Verdict: WAIT", "Verdict: SKIP" — REMOVE ALL. Treat these like LaTeX: immediate delete. +- "Procurement advice" framing ("consider your budget", "evaluate your options") — REMOVE. +- "It depends on your use case" — instead say WHAT it depends on specifically. +- Hedging language ("could potentially", "in some cases"). +- Both-sides-ism when one side is clearly better. -The reader should finish the article knowing exactly what to do. +CRITICAL: Opinion = observing what actually happens and saying it directly. +NOT: telling people what to buy. +YES: "At 400G, teams that skip connector inspection spend the next week debugging behavior that has nothing to do with the optics." + +The reader should finish with a clear perspective — not a shopping list. Article: {{ARTICLE}}`; @@ -858,6 +906,50 @@ CALIBRATION FAILS (auto-reject — fix before returning): 32. INVENTED VENDOR NAMES: Any vendor cited that was NOT in the context data or in the system prompt reference list (Cisco, Juniper, Arista, Flexoptix, FS.com, ProLabs, InnoLight, Coherent, Lumentum) — REMOVE. +33. CATALOG DETECTOR (HARD FAIL): Count the number of distinct products mentioned by name or class. + → If more than 2 products are listed, compared, or described individually — this is a CATALOG, not a blog. + → REMOVE product listings. Keep at most one product reference as a narrative anchor. + → Any table comparing multiple products → DELETE entirely. Replace with one behavioral sentence if needed. + → Any "structured comparison block" (SR4 vs DR4 vs FR4 vs ZR with parallel attributes) → DELETE. + → Test: could this section be copy-pasted into a procurement guide? If yes — cut it. + +34. SALES DRIFT HARD STOP (HARD FAIL): Search for sales and analyst language. + → "Verdict: BUY", "BUY / DO NOT BUY", "DO NOT BUY", "Recommendation: BUY" → DELETE ALL. + → Procurement playbook sections ("when to buy", "budget considerations") → DELETE. + → Pricing strategy advice ("lock in pricing now", "negotiate volume") → DELETE. + → "News dump" sections (recent industry news listed without insight) → DELETE or reduce to one sentence. + → These patterns are Gartner/analyst content — not Flexoptix engineer voice. + +35. TITLE ALIGNMENT LOCK (HARD FAIL): Read the article title carefully. + → If the title contains "what the specs don't tell you" or "beyond the specs" or "what specs miss": + ALL spec tables, ALL spec comparisons, ALL dBm listings, ALL wattage tables → DELETE. + The entire point is that specs don't tell the story. Specs in the body contradict the title completely. + → If the title is "what actually happens" or "real-world X": + Remove any content that reads like a datasheet or vendor spec comparison. + → Title/content alignment check: does the body CONSISTENTLY deliver what the title promises? + If the article drifts from the title premise after paragraph 3 → CUT the drifting sections. + +36. ONE CORE IDEA (QUALITY FAIL): Count the number of distinct core ideas in the article. + → A well-written Flexoptix article has ONE core idea, developed fully. + → Two or three sub-points that all support that one idea = fine. + → Four or more disconnected ideas = assembled framework = FAIL. + → If multiple unrelated ideas exist: identify the strongest one. Delete or reduce all others to one sentence. + → The core idea for most FO technical articles: "high-speed optics expose what was already marginal." + Everything else is context or consequence — never an equal parallel idea. + +37. LAST 15% CUT (QUALITY FAIL): Read the last 15–20% of the article. + → Are these sentences weaker than the first 80%? If yes — cut them. + → Do they summarize or restate what was already said? → CUT. The article already said it. + → Does the ending drift into generic advice after a strong core? → CUT the drift, keep only the closing line. + → Rule: if removing a sentence makes the article stronger, it should not be there. + → Do NOT replace what you cut. End sooner. End harder. + +38. STRUCTURE DRIFT (HARD FAIL): Count the number of distinct labeled sections or structural units. + → More than 4 named/labeled sections = framework, not article. + → Any section that is "Category X" + "Category Y" + "Category Z" in sequence = whitepaper structure. + → COMBINE OR CUT. The article should read as a single continuous thought, not as chapters. + → If the article has: introduction + background + analysis + comparison + recommendation + conclusion → this is a business report. Reduce to: hook + one core thread + ending. + CRITICAL OUTPUT RULE: Return ONLY the fixed article text. NO review commentary. NO numbered issue lists. NO "Critical Review" section. NO "HARD FAIL CHECKS" header. NO markdown review structure. @@ -1469,6 +1561,355 @@ WRONG PATTERNS (both styles — never produce): ❌ "100G-SR4 → up to 8×10G from a single 100G port" or similar density breakout math — remove or mark explicitly as theoretical maximum. This is marketing language in a technical article. ❌ "compatible optics are a gamble" or any framing that makes compatible optics sound inherently unreliable — this is not Flexoptix voice. Correct framing: "compatible optics shift responsibility from vendor to operator." ❌ Stacking 5-6 worst-case scenarios in a row — this reads as AI-constructed, not field experience. Max 2-3 scenarios, each deeper, not more. +❌ Tables anywhere in the article body — ALWAYS wrong. "SR4 | DR4 | FR4 | ZR" side-by-side = datasheet. Cut it. +❌ "Verdict: BUY" or "BUY / DO NOT BUY" sections — analyst language, not engineer voice. Immediate delete. +❌ Procurement playbook sections ("when to buy", "lock in pricing", "negotiate volume") — sales content, not blog. +❌ Product lists with 3+ entries described in parallel ("FS.com: $89. ProLabs: $120. OEM: $1,100.") — this is a catalog, not an article. Max 2 product references in any article. +❌ "News dump" paragraphs (industry headlines listed without analysis) — not Flexoptix voice. Cut or reduce to one sentence with a specific insight. +❌ Structure like "Introduction + Background + Analysis + Comparison + Recommendation + Conclusion" — this is a business report, not a blog. +❌ More than 4 distinct labeled/named sections — assembles like a framework, not written like experience. +❌ Title says "what the specs don't tell you" but body contains spec tables — direct contradiction. Remove ALL specs from the body when the title frames specs as insufficient. +❌ "Best practices" anywhere — HARD DELETE. This is corporate training content. Replace with a direct observation or cut. +❌ "You should always..." / "Make sure to..." / "To avoid this..." — teaching tone, not field experience. Remove. +❌ Any section that could be copy-pasted unchanged into a procurement guide or vendor datasheet — it doesn't belong in a blog. +❌ "The key takeaway is..." / "The main lesson here is..." — the article should demonstrate the takeaway, not announce it. +❌ More than one "core idea" developed in parallel — one thread, developed deeply. Everything else is supporting context. + +━━━ STYLE B GOLD EXAMPLE 7 (2026-04-04 validated — first corrected "What Specs Don't Tell You") ━━━ +Topic: 400G/800G — what actually happens at high speed. Zero specs. Pure physical layer reality. +This is the corrected version after a catalog/whitepaper failure (score 6 → first correction step). + + "400G and 800G: What the Specs Don't Tell You + + You're looking at a new batch of 400G or even 800G optics. + + Everything looks good. Specs line up. Vendors are ready. Roadmaps make sense. + + Nothing suggests this should be complicated. + + That's usually where things start to drift. + + Because the problem isn't the specs. + + It's everything the specs don't show. + + On paper, these modules look predictable. Same form factors, same interfaces, higher speeds. Just another upgrade cycle. + + In reality, behavior changes just enough to expose everything that wasn't quite right before. + + Links don't just fail. + + They behave inconsistently. + + One comes up clean and starts throwing errors hours later. + Another stays stable until traffic ramps up. + A third refuses to come up at all, even though everything looks correct. + + Nothing obviously broken. + + Just unstable enough to waste your time. + + That's when optics get blamed. + + Swapped. Replaced. Escalated. + + And most of the time, they're not the problem. + + What actually changes at 400G and beyond isn't just speed. + + It's margin. + + At lower speeds, there's enough headroom to hide imperfections. Cabling doesn't have to be perfect. Connectors don't have to be spotless. Systems absorb small mistakes. + + At higher speeds, that headroom disappears. + + Not completely. Just enough that everything that used to be 'fine' becomes visible. + + That's why the same setup behaves differently. + + Same optics. Same topology. Different result. + + I've seen deployments where everything looked clean in the lab, passed initial testing, and then started failing under real traffic. + + Hours of debugging. Swapping hardware. Checking configs. + + Until someone actually inspected the physical layer properly. + + Cleaned connectors. Verified polarity. Rechecked the path. + + And suddenly everything stabilized. + + That's the part no spec sheet captures. + + Because it's not in the optics. + + At 400G and especially at 800G, small things start to matter more. + + A connector that looks clean might not be. + A polarity mismatch that never showed up before suddenly kills the link. + Cabling that worked for years sits right at the edge. + + Nothing new broke. + + You just lost the margin that was hiding it. + + That's also where most of the cost sits. + + Not in the hardware. + + In the time spent debugging behavior that doesn't fail cleanly. + + Higher speeds don't introduce new problems. + + They expose the ones that were already there. + + If there's one thing that makes the difference, it's this: + + Treat the physical layer like it actually matters. + + Not as something that 'should be fine'. + + Something you verify. + + Because 400G and 800G don't fail in design. + + They fail when your assumptions stop holding up." + +KEY ELEMENTS OF GOLD STANDARD 7: + - Zero spec tables, zero product listings, zero "BUY/DON'T BUY" — pure behavioral narrative + - Title "what the specs don't tell you" → body contains NO specs. Perfect alignment. + - ONE core idea: margin disappears at speed, exposing what was marginal before + - Physical layer described as a process of discovery, not a checklist + - Ending: reframes the whole article in two sentences + +━━━ STYLE B GOLD EXAMPLE 8 (2026-04-04 final 10/10 — "What Specs Don't Tell You", sharpened) ━━━ +Topic: Same topic, final tighter version. Every sentence earns its place. + + "400G and 800G: What the Specs Don't Tell You + + You're about to sign a purchase order for 400G or even 800G optics. + + On paper, it looks straightforward. Fewer ports. Higher density. Lower cost per bit. Everything looks mature. + + That's usually where things start to drift. + + Because the problem isn't the optics. + + It's everything around them. + + I've seen deployments where everything looked clean in the lab. Links came up, traffic was stable, no indication of problems. + + Then production hits. + + A few links start throwing CRC errors. Others begin flapping intermittently. Nothing fails completely. Just enough instability to slow everything down. + + That's when optics get blamed. + + Swapped. Replaced. Moved to different ports. + + Nothing changes. + + Until someone actually checks the physical layer. + + Not visually. Properly. + + Clean connectors. Verify the path. Look at what's actually there. + + And suddenly everything stabilizes. + + Same optics. Same setup. Different result. + + That's the part no spec sheet tells you. + + Because it's not in the optics. + + At lower speeds, there's enough margin to hide imperfections. Cabling doesn't have to be perfect. Connectors don't have to be spotless. Systems absorb small mistakes. + + At 400G and beyond, that margin gets tight. + + Not completely gone. Just enough that everything that used to be 'fine' becomes visible. + + A connector that looks clean might not be. + A polarity issue that never showed up before suddenly kills the link. + Cabling that worked for years sits right at the edge. + + Nothing new broke. + + You just lost the margin that was hiding it. + + That's why these problems are so frustrating. + + They don't fail cleanly. + + They show up as inconsistent behavior. + As links that work — until they don't. + + And that's where the real cost sits. + + Not in the optics. + + In the time spent debugging something that technically works — just not reliably. + + Higher speeds don't introduce new problems. + + They expose the ones that were already there. + + If there's one thing that makes the difference, it's this: + + Take the physical layer seriously. + + Not as something that 'should be fine'. + + Something you actually verify. + + Because 400G doesn't fail in design. + + It fails when your assumptions don't hold up anymore." + +KEY ELEMENTS OF GOLD STANDARD 8: + - "Fewer ports. Higher density. Lower cost per bit." — three-beat rhythm, then immediate break: "That's usually where things start to drift." + - "Not visually. Properly." — two words that do more than two sentences + - Every concept appears exactly ONCE: connector cleaning once, polarity once, cost once + - Ending arrives at exactly the right moment — no summary, no checklist + - 330 words. Nothing wasted. + +━━━ LINKEDIN GOLD EXAMPLE 3 (2026-04-04 — from v1.0 generator, FO Style, Contradiction Hook) ━━━ +This post demonstrates the Flexoptix LinkedIn voice at its cleanest. 147 words. + + "Everything looks fine. Until it doesn't. + + You bring up a new batch of 400G links. Lab tests were clean. Traffic is stable. No reason to expect problems. + + Then a few hours later, error counters start creeping up. + + Not enough to drop the link. Just enough to slow everything down. + + So optics get blamed. + + Swapped. Replaced. Moved to different ports. + + Nothing changes. + + Config looks correct. Hardware is fine. Everything points to 'should work'. + + Until someone actually checks the physical layer properly. + + Same optics. Same setup. Different result. + + At 100G, you get away with it. + At 400G, you don't. + + Full breakdown in the blog — link in first comment. + + #OpticalNetworking #DataCenter #NetworkEngineering #Flexoptix" + +KEY ELEMENTS OF LINKEDIN GOLD 3: + - Hook type: CONTRADICTION ("Everything looks fine. Until it doesn't.") + - 80–180 word sweet spot — reads fully, no "see more" + - Structure: Reality → Behavior → Confusion → Insight (no advice, no checklist) + - No "•" bullet markers — short lines with breathing room + - No explanation — reader connects the dots themselves + - Engineers recognize themselves in this. That's the goal. + +━━━ STYLE B GOLD EXAMPLE 9 (2026-04-04 — Human-rated GOLD. The canonical reference.) ━━━ +Topic: 400G upgrade reality. This is the GOLD VERSION rated by human feedback. Zero drift, one idea. +"If the article explains more than one thing, it's broken." This is what correct looks like. + + "400G: The Upgrade That Exposes Everything + + You're about to sign a purchase order for a few hundred 400G optics. + + On paper, everything looks straightforward. Higher density, fewer ports, mature technology. Nothing suggests this should be difficult. + + That's usually where things start to drift. + + Because the problem isn't the optics. + + It's everything around them. + + I've seen deployments where everything looked clean in the lab. Links came up, traffic was stable, nothing indicated a problem. + + Then production hits. + + A few links start throwing CRC errors. Others begin flapping intermittently. Nothing fails completely. Just enough instability to slow everything down. + + That's when optics get blamed. + + Swapped. Replaced. Moved to different ports. + + Nothing changes. + + Until someone actually checks the physical layer. + + Not visually. Properly. + + And suddenly everything stabilizes. + + Same optics. Same setup. Different result. + + That's the part no spec sheet tells you. + + Because it's not in the optics. + + At lower speeds, there's enough margin to hide imperfections. Cabling doesn't have to be perfect. Connectors don't have to be spotless. + + At 400G, that margin gets tight. + + Not gone. Just tight enough that everything that used to be 'fine' becomes visible. + + A connector that looks clean might not be. + A polarity issue that never showed up before suddenly kills the link. + Cabling that worked for years sits right at the edge. + + Nothing new broke. + + You just lost the margin that was hiding it. + + That's why these problems are so frustrating. + + They don't fail cleanly. + + They show up as inconsistent behavior. As links that work — until they don't. + + And that's where the real cost sits. + + Not in the hardware. + + In the time spent debugging something that technically works — just not reliably. + + Higher speeds don't introduce new problems. + + They expose the ones that were already there. + + Because 400G doesn't fail in design. + + It fails when your assumptions don't hold up anymore." + +KEY ELEMENTS OF GOLD STANDARD 9 (what makes this the canonical reference): + - ONE core idea: "400G exposes what was already marginal." Nothing else. + - ZERO secondary topics: no power, no cost breakdown, no vendor comparison, no fiber deep dive. + - ZERO scenarios: no named scenario, no "Scenario: polarity mismatch" — just the lived experience. + - ZERO repetition: connector cleaning once, polarity once, cost once. Not twice. + - ZERO education mode: no "most people", no "imagine", no "consider" — only observation. + - Every concept is a statement, not an explanation: "Nothing new broke. You just lost the margin." + - Ending lands exactly on the core idea: "It fails when your assumptions don't hold up anymore." + - ~370 words. Tight. Nothing wasted. + +WHAT THE WRONG VERSION DID (learn from it — this is the canonical failure pattern): + ❌ Multi-topic: connectors + polarity + power consumption + OEM vs compatible + cost breakdown + fiber types + ❌ 3 parallel scenarios labeled and developed equally + ❌ Connector cleaning explained twice (once in "production" section, once in "cost" section) + ❌ "Most migrations start with a simple assumption..." → education mode opener + ❌ "Imagine rolling out 400G across multiple data centers..." → classroom scenario framing + ❌ "Consider a scenario where..." → textbook mode + ❌ Sales drift: "So the question isn't just about choosing between OEM and compatible optics..." + ❌ "An inspection scope costs $1,500. MMF to SMF re-cabling can cost between $50-200 per drop..." → cost section + ❌ "At 400G, power consumption also becomes a critical factor..." → power section → DRIFT + ❌ Ending answered a different question than the title set up + +THE SINGLE SENTENCE THAT DEFINES THIS SYSTEM: +"Wenn der Artikel mehr als eine Sache erklärt, ist er kaputt." +("If the article explains more than one thing, it's broken.") FLEXOPTIX BALANCE RULES (critical — this is a Flexoptix blog, not an OEM vendor blog): - Never frame compatible optics as "a gamble" or "ticking time bomb" @@ -1497,63 +1938,407 @@ POWER / LOSS BUDGET PRECISION (always apply): // (2026-04-04: LinkedIn hard limit = 3,000 chars. Optimal = 800-1500 chars.) // ═══════════════════════════════════════════════════════ -export const STEP_LINKEDIN_POST = `Write a LinkedIn post for this article. +export const STEP_LINKEDIN_POST = `Write a LinkedIn post for this article using the FLEXOPTIX LINKEDIN GENERATOR v1.0. -HARD LIMIT: Maximum 2,800 characters. OPTIMAL: 350–600 characters (reads in full, no "see more"). +════════════════════════════════════════════════════════ +GOAL: Posts that feel like real experience. Not content. Not marketing. +════════════════════════════════════════════════════════ -THE FORMAT THAT WORKS (use this exactly): +Engineers must recognize themselves in this post. +Not be lectured. Not be sold to. Not be impressed by vocabulary. -Line 1-2: HOOK — reframe or uncomfortable truth. NOT "I published something." NOT a question. - "400G doesn't break your network. It shows you what was already broken." +LENGTH: 80–180 words (optimal). HARD LIMIT: 2,800 chars. +Reads fully in feed — no "see more". One screen. -[blank line] +FORMAT (fixed — no variations): -3-4 SHORT BEATS — each beat = 1-3 lines. One insight per beat. Breathing room between each. - Short standalone sentences are fine: "Dirty connector. Wrong polarity. Zero margin left." - This is NOT a bullet list — it's a rhythm. No "•" or "-" markers. - -[blank line] - -CTA — ONE LINE: "Full breakdown in the blog — link in first comment." - Do NOT include a URL. No "Check out my article". No "I'm excited to share". - -[blank line] - -HASHTAGS: 3-4 only. Last line. Always include #Flexoptix. + [HOOK: 1-2 lines] + [blank line] + [BEHAVIOR: 2-4 short beats, 1-3 lines each, blank lines between] + [blank line] + [INSIGHT: 1-2 lines — observation, not advice] + [blank line] + CTA: "Full breakdown in the blog — link in first comment." + [blank line] #OpticalNetworking #DataCenter #NetworkEngineering #Flexoptix -GOLD EXAMPLE (346 chars — this is the target format): +════════════════════════════════════════════════════════ +HOOK ENGINE — pick one pattern based on the article's core idea: +════════════════════════════════════════════════════════ -400G doesn't break your network. +HOOK TYPE 1 — CONTRADICTION: + "Everything looks fine. Until it doesn't." + Use when: article is about subtle failures or unexpected behavior. -It shows you what was already broken. +HOOK TYPE 2 — REALITY BREAK: + "400G doesn't break your network." + [next line] "It shows you what was already broken." + Use when: article reframes a common assumption. -Most teams blame the optics first. -Swap them. Replace them. Escalate. +HOOK TYPE 3 — FALSE ASSUMPTION: + "Most people think the optics are the problem." + Use when: article corrects a widespread misconception. -And then someone finally checks the physical layer. +HOOK TYPE 4 — EXPERIENCE: + "I've seen links run clean for hours…" + Use when: article is built around a specific deployment moment. -Dirty connector. Wrong polarity. Zero margin left. +HOOK TYPE 5 — MOMENT: + "Friday afternoon deployment. Everything green." + Use when: article opens with a situation the reader has been in. -Same optics. Same config. Different result. +════════════════════════════════════════════════════════ +BEHAVIOR ENGINE — describe what actually happens: +════════════════════════════════════════════════════════ -At 100G, you get away with it. At 400G, you don't. +Show real production behavior. Never explain. Never define. + +Good behavior beats: + "Links come up. Error counters start creeping. Not enough to drop. Just enough to slow everything down." + "Optics get blamed. Swapped. Replaced. Moved to different ports. Nothing changes." + "Config looks correct. Hardware is fine. Everything points to 'should work'." + +Bad (explanation mode — never use): + "CRC errors occur when the optical signal is degraded beyond the receiver threshold." + "This is caused by dirty connectors reducing available optical margin." + +════════════════════════════════════════════════════════ +BREAK ENGINE — introduce the confusion: +════════════════════════════════════════════════════════ + +This is the moment where nothing obvious is wrong but nothing works. +The reader thinks: "yes, exactly — that's what happened to us." + +Good break beats: + "Until someone actually checks the physical layer properly." + "Same optics. Same setup. Different result." + "That's the part that costs time. Not hardware." + +════════════════════════════════════════════════════════ +INSIGHT ENGINE — end with observation, not advice: +════════════════════════════════════════════════════════ + +NEVER: + "You should always clean connectors." + "Best practice: verify physical layer before deployment." + "To avoid this, implement a validation checklist." + +ALWAYS: + "At 100G, you get away with it. At 400G, you don't." + "Higher speeds don't introduce new problems. They expose the ones that were already there." + "That's where the problem actually is." + +════════════════════════════════════════════════════════ +ENGAGEMENT BOOSTER v1.0 — apply after drafting: +════════════════════════════════════════════════════════ + +Engagement does NOT come from asking questions. It comes from: + ✔ Recognition — "that's exactly what happened to us" + ✔ Friction — "I see this differently" + ✔ Provocation — "I need to comment on this" + ✔ Unfinished feeling — space for the reader to complete the thought + +APPLY THESE BOOSTER TYPES (pick 2-3 that fit the topic): + +TYPE 1 — RELATABILITY: Add one moment that feels extremely real and specific. Do not explain it. + Effect: reader remembers their own experience. + Example: "Lab tests were clean. Then production hit." + +TYPE 2 — FRICTION: Introduce a subtle contradiction to common belief. Do not explain it. + NOT: "Connectors need to be clean." + BUT: "Most people don't check connectors until everything else has failed." + +TYPE 3 — BLAME SHIFT: Move the problem away from the obvious target to something less expected. + NOT: "The optics failed." + BUT: "The optics were fine. Everything around them wasn't." + Effect: triggers "exactly this" / "not always" / "depends" comments. + +TYPE 4 — UNRESOLVED EDGE: End with a strong observation, not a conclusion. Leave it open. + NOT: "Always validate your setup." + BUT: "That's usually where things start to go wrong." + +TYPE 5 — PATTERN BREAK: One short punchy sentence that breaks flow intentionally. + "Nothing fails." + [blank] + "Until it does." + +MICRO-BOOSTERS (apply anywhere): + ADD EDGE: make the tone slightly more direct, less neutral. + ADD TENSION: sharpen the contrast between expectation and reality. + ADD PAIN: emphasize wasted time — not technical failure. + REMOVE SAFETY: delete "sometimes", "often", "can", "may" — make assertions direct. + +════════════════════════════════════════════════════════ +AUTO-KILL FILTER — scan and delete: +════════════════════════════════════════════════════════ +→ "what do you think?" / "agree?" / "have you experienced this?" / "let me know" → DELETE ALL +→ "to avoid this" → DELETE +→ "best practice" → DELETE +→ "make sure to" → DELETE +→ "important to" → DELETE +→ "you should" → DELETE +→ "ensure that" → DELETE +→ "I just published" / "Excited to share" / "Check out my article" → DELETE +→ Bullet markers "•" or "-" inside the post → REMOVE (use short standalone lines instead) +→ Any emoji except ONE optional opener → REMOVE +→ More than 4 hashtags → REMOVE extras +→ Corporate tone / hedging language → REMOVE +→ Anything that explains the insight instead of showing it → REMOVE + +════════════════════════════════════════════════════════ +ENGAGEMENT FINAL CHECK — before returning: +════════════════════════════════════════════════════════ +Ask: Does this post — + ✔ trigger recognition in a working engineer? + ✔ create slight friction or disagreement? + ✔ avoid explaining the insight? + ✔ feel slightly unfinished — space for the reader to add their thought? +If any NO → rewrite that section. + +Rule: "If the post explains everything, nobody comments." + +════════════════════════════════════════════════════════ +ANTI-AI FILTER — make it human: +════════════════════════════════════════════════════════ +→ Perfectly parallel sentence structures → vary the rhythm +→ Every beat same length → break one up +→ Smooth transitions everywhere → add one abrupt line +→ Symmetric structure → make it slightly uneven + +════════════════════════════════════════════════════════ +GOLD REFERENCE (engagement-boosted — this is the target): + +Everything looks fine. Until it doesn't. + +You bring up a new batch of 400G links. Lab tests were clean. Traffic is stable. + +Then error counters start creeping up. + +Not enough to fail. Just enough to waste your time. + +So optics get blamed. + +Swapped. Replaced. Escalated. + +Nothing changes. + +Config looks correct. Hardware looks fine. + +That's usually the point where people start looking in the wrong place. + +Same optics. Same setup. Different result. + +At 100G, you get away with it. +At 400G, you don't. Full breakdown in the blog — link in first comment. #OpticalNetworking #DataCenter #NetworkEngineering #Flexoptix +════════════════════════════════════════════════════════ ---- +Return ONLY the post text. No commentary. No "Here is the post:". Start directly with the hook. -HARD RULES: -- No emojis (unless ONE strategic opener, never mid-text) -- No "I'm thrilled" / "Excited to share" / "Let's dive in" -- No markdown, no bold, no headers -- No explanation blocks — short beats only -- Engineer voice, not influencer voice -- If over 2,800 chars — cut until under +Article: +{{ARTICLE}}`; -Return ONLY the post text. No commentary. No "Here is the post:". +// ═══════════════════════════════════════════════════════ +// STEP AFE: AUTO-FOCUS ENFORCER v1.0 +// (2026-04-04: Added — kills multi-topic drift BEFORE reduction. +// "If more than one thing is important, nothing is important.") +// ═══════════════════════════════════════════════════════ + +export const STEP_AFE = `You are running the FLEXOPTIX AUTO-FOCUS ENFORCER (AFE v1.0) on this article. + +RULE: Every Flexoptix article has exactly ONE core idea. +If this article has more than one, reduce it to the strongest one. + +════════════════════════════════════════════════════════ +STEP 1 — IDENTIFY THE CORE IDEA +════════════════════════════════════════════════════════ + +Read the article. Identify: +- The ONE thing this article is really about (one sentence) +- All secondary ideas that could be removed without destroying the article + +Core idea examples: +- "400G exposes physical layer weaknesses hidden at lower speeds" +- "Compatible optics don't fail — unvalidated deployments do" +- "Price drops change the ROI calculation for compatible optics" + +Secondary idea candidates (remove if not core): power consumption, cost breakdowns, vendor comparisons, fiber type deep dives, spec tables, additional scenarios unrelated to the core. + +════════════════════════════════════════════════════════ +STEP 2 — HARD REMOVAL RULES +════════════════════════════════════════════════════════ + +Remove immediately if NOT the core idea: +- Power consumption sections (unless the article IS about power) +- Cost breakdown sections (unless the article IS about cost) +- Vendor comparisons (unless the article IS a comparison) +- Fiber type deep dives (unless fiber IS the core) +- Any section starting with "Another thing to consider is..." +- Any section that could be lifted unchanged into a different article + +════════════════════════════════════════════════════════ +STEP 3 — SCENARIO LIMITER +════════════════════════════════════════════════════════ + +Count distinct scenarios: +- 1 scenario: keep as-is +- 2 scenarios: keep only the strongest, remove the other +- 3+ scenarios: framework, not article. Keep 1. Remove the rest. + +════════════════════════════════════════════════════════ +STEP 4 — REPETITION KILL +════════════════════════════════════════════════════════ + +Each concept appears ONCE. If connector cleaning appears twice: +- Keep the sharper instance. Delete the other — completely, no replacement. + +Warning signs: "Another issue is...", "Also worth noting...", "Additionally...", "There is also..." +Each of these = likely repetition or drift. Evaluate and cut aggressively. + +════════════════════════════════════════════════════════ +STEP 5 — EDUCATION MODE KILL +════════════════════════════════════════════════════════ + +These openers signal classroom/textbook mode — kill them: +- "Most people..." → replace with "I've seen..." or direct observation +- "Imagine a scenario..." → replace with "In one deployment..." +- "Consider the following..." → delete, start with the thing itself +- "It is important to understand that..." → delete the preamble, keep the point +- "Many engineers make the mistake of..." → "This is the standard failure mode." + +════════════════════════════════════════════════════════ +STEP 6 — WORD BAN LIST (hard replace/delete) +════════════════════════════════════════════════════════ + +These words are BANNED. Replace or delete every single occurrence: + + "validation" / "validate" → use specific action: "inspect", "check connectors", "run BERT", "measure with OPM" — never the abstract noun + "real-world conditions" → "in production" or delete + "under certain conditions" → state the condition or delete + "due to" → rewrite actively: "X causes Y" not "Y due to X" + "in reality" → delete, start with the fact + "in practice" → delete, start with the fact + "this means" / "this means that" → assert directly, remove the preamble + "significantly" → use a number or delete + "typically" / "generally" → assert directly or delete + "actually" / "basically" → delete always, no exceptions + "can cause" / "can lead to" → "causes" / "leads to" — remove the hedge + +════════════════════════════════════════════════════════ +STEP 7 — TITLE ALIGNMENT +════════════════════════════════════════════════════════ + +Does the article title match what the article is actually about? + +- "Investment Guide" but content is a failure story → rewrite title to match the failure story angle +- "Migration Guide" but no migration steps → change title to "Why Migration Fails" or similar +- Rule: The title must be a one-line summary of the actual article. If it isn't — fix the title. +- Always prefer fixing the title over changing the content. +- Strong title patterns: "[Speed]: The Upgrade That Exposes Everything" | "Why [X] Fails" | "The Real Cost of [X]" + +════════════════════════════════════════════════════════ +OUTPUT RULE +════════════════════════════════════════════════════════ + +Return ONLY the focused article (with corrected title if changed). No commentary. No focus score. No explanation of changes. +Target: cut 30–50% if multi-topic drift was present. Do NOT replace what you cut. +The article gets shorter and stronger — not shorter and incomplete. + +Article: +{{ARTICLE}}`; + +// ═══════════════════════════════════════════════════════ +// STEP AEM: AUTO-EDITOR MODE v1.0 (Senior Engineer Simulation) +// (2026-04-04: Added — voice polish after reduction. +// "If it has to explain itself, it's not good enough yet.") +// ═══════════════════════════════════════════════════════ + +export const STEP_AEM = `You are running the FLEXOPTIX AUTO-EDITOR MODE (AEM v1.0) on this article. + +GOAL: Make this read like a senior engineer who has seen this problem 50 times. +Not explaining. Not convincing. Describing what happens — because they know. + +════════════════════════════════════════════════════════ +PASS 1 — SENTENCE LENGTH +════════════════════════════════════════════════════════ + +Maximum ~16 words per sentence. Anything longer → split or cut the weaker half. +After a long build-up, add one very short sentence: "It isn't.", "That's it.", "Every time." +Vary length deliberately: long, short, long, very short. + +════════════════════════════════════════════════════════ +PASS 2 — AUTHORITY WITHOUT EXPLANATION +════════════════════════════════════════════════════════ + +Remove all justification: +- "...because X" after a clear statement → delete the because-clause. Statement stands alone. +- "this means that..." → delete. Reader infers. +- "this happens due to..." → delete. State the effect, not the cause chain. +- "this is why..." → delete. Move on. + +Before: "Connectors need to be clean because dirt reduces optical margin." +After: "Connectors need to be clean. Dirt kills margin." + +════════════════════════════════════════════════════════ +PASS 3 — CONFIDENCE INJECTION +════════════════════════════════════════════════════════ + +Replace hedges with direct assertions: +- "often" → remove or assert directly +- "can" → "does" or "will" +- "might" → "will" (if true) or delete +- "typically" → state the fact directly +- "in some cases" → name the case or cut +- "may lead to" → "leads to" +- "tends to" → just say what it does + +Before: "This can often lead to issues in production." +After: "This causes problems in production." + +════════════════════════════════════════════════════════ +PASS 4 — EXPERIENCE SIGNALS (max 2) +════════════════════════════════════════════════════════ + +If the article has fewer than 2 experience markers, add one naturally: +- "I've seen this before." +- "This usually shows up at the worst time." +- "That's where things start to drift." + +If the article already has 2+, skip this pass. + +════════════════════════════════════════════════════════ +PASS 5 — STRUCTURE BREAK +════════════════════════════════════════════════════════ + +Break any pattern that's too symmetric: +- Three paragraphs of equal length → shorten one +- Every paragraph opening with "The" → vary one opener +- Every beat following identical rhythm → disrupt one + +Add ONE rough edge: a fragment, an abrupt cut, a sudden 3-word paragraph. +Example: "That's the cost. Not hardware." + +════════════════════════════════════════════════════════ +PASS 6 — FINAL VOICE CHECK +════════════════════════════════════════════════════════ + +Read the article. Ask: does this sound like — + A) A system generating content + B) Someone who was actually there + +If A → find the sentences that give it away. They justify, explain the obvious, over-qualify. +Rewrite those sentences. Do not add new content — sharpen what's there. + +════════════════════════════════════════════════════════ +OUTPUT RULE +════════════════════════════════════════════════════════ + +Return ONLY the polished article. No commentary. No analysis. +Do NOT add new content, new sections, or new facts. +Only improve voice, sentence rhythm, and directness. Article: {{ARTICLE}}`; @@ -1679,6 +2464,107 @@ Return only the fixed article. No commentary. Article: {{ARTICLE}}`; +// ═══════════════════════════════════════════════════════ +// STEP APM: AUTO-PRECISION MODE v1.0 (Final Cut — Last Filter Before Publish) +// (2026-04-04: Added — micro-editing layer, runs after Style Lock and QA. +// "If a word can go, it must go.") +// ═══════════════════════════════════════════════════════ + +export const STEP_APM = `You are running the FLEXOPTIX AUTO-PRECISION MODE (APM v1.0) on this article. + +This is the FINAL FILTER before publication. Nothing after this step. +Goal: maximum impact per word. No dead weight. No filler. No over-explanation. + +════════════════════════════════════════════════════════ +PASS 1 — SENTENCE EVALUATION +════════════════════════════════════════════════════════ + +For every sentence, ask: + 1. Does it add new information? + 2. Does it move the narrative forward? + 3. Would the article be weaker without it? + +If no to all three → delete the sentence. No replacement. + +════════════════════════════════════════════════════════ +PASS 2 — WORD REDUCTION +════════════════════════════════════════════════════════ + +Rewrite every sentence using fewer words. Target: 20–50% reduction per sentence. +Never lose meaning. Only lose weight. + +Examples: + BEFORE: "This is where things start to become problematic in production environments." + AFTER: "This is where things break." + + BEFORE: "At higher speeds like 400G and 800G, the margin for error becomes significantly smaller." + AFTER: "At 400G, the margin gets tight." + + BEFORE: "This is where the real cost sits, not in the optics themselves but in the time spent debugging." + AFTER: "The cost isn't the optics. It's the time." + +════════════════════════════════════════════════════════ +PASS 3 — FILLER WORD KILL +════════════════════════════════════════════════════════ + +Delete immediately (no replacement): + actually · basically · essentially · significantly · typically · generally · simply + in reality · in practice · in fact · it is worth noting · it is important to note + as mentioned · as noted · needless to say · at the end of the day + +════════════════════════════════════════════════════════ +PASS 4 — DUPLICATE IDEA DETECTOR +════════════════════════════════════════════════════════ + +Scan for any idea that appears more than once. Keep the sharpest version. Delete the rest. +One idea = one appearance. No "echo" paragraphs that restate what was just said. + +════════════════════════════════════════════════════════ +PASS 5 — VERB STRENGTHENING +════════════════════════════════════════════════════════ + +Weak → Strong: + "can cause" → "causes" + "can lead to" → "leads to" + "might create" → "creates" + "may result in" → "results in" + "tends to" → assert directly + +════════════════════════════════════════════════════════ +PASS 6 — HARD CUT (20%) +════════════════════════════════════════════════════════ + +Remove the weakest 20% of sentences. No replacement. The article must survive the cut. +If a section collapses without its filler — that section was filler. + +════════════════════════════════════════════════════════ +PASS 7 — MICRO-CUT +════════════════════════════════════════════════════════ + +Remove 1–2 words from every sentence without breaking meaning. +Repeat until no further reduction is possible without losing information. + +════════════════════════════════════════════════════════ +PASS 8 — RHYTHM CHECK +════════════════════════════════════════════════════════ + +After all cuts: vary sentence length deliberately. +Pattern: long → short → very short → medium → short. +Avoid 3+ sentences of the same length in a row. +A two-word sentence after a long paragraph creates impact. Use it. + +════════════════════════════════════════════════════════ +OUTPUT RULE +════════════════════════════════════════════════════════ + +Return ONLY the final article. No commentary. No explanation of what was changed. +The article will be shorter. That is correct. Shorter is better when every word earns its place. + +THE SINGLE RULE: If a word can go, it must go. + +Article: +{{ARTICLE}}`; + /** * Injects the calibration gold standard into the system prompt. * Use sparingly — only when available Ollama context allows. @@ -1686,3 +2572,89 @@ Article: export function withCalibration(systemPrompt: string): string { return systemPrompt + CALIBRATION_GOLD_STANDARD; } + +/** + * SLL v1.0 — Build Self-Learning Loop context from DB. + * Queries current learned patterns and weekly state, returns a compact + * context block that gets prepended to the system prompt. + * + * Returns empty string if no data available (safe fallback). + */ +export async function buildSLLContext(): Promise { + try { + const { pool } = await import("../db/client"); + + const [stateRes, patternRes, statsRes] = await Promise.all([ + pool.query( + `SELECT * FROM blog_sll_state ORDER BY week_start DESC LIMIT 1` + ), + pool.query( + `SELECT pattern_type, pattern_value, performance_class, avg_engagement, sample_count + FROM blog_learned_patterns WHERE active = TRUE + ORDER BY performance_class, avg_engagement DESC NULLS LAST LIMIT 20` + ), + pool.query( + `SELECT COUNT(*) as total, AVG(engagement_score) as avg_score + FROM blog_performance WHERE engagement_score IS NOT NULL` + ), + ]); + + const total = Number(statsRes.rows[0]?.total || 0); + if (total < 3) return ""; // Not enough data yet + + const state = stateRes.rows[0]; + const winners = patternRes.rows.filter((p: any) => p.performance_class === "winner"); + const losers = patternRes.rows.filter((p: any) => p.performance_class === "loser"); + + const lines: string[] = [ + "", + "════════════════════════════════════════════════════════", + `SELF-LEARNING LOOP (SLL v1.0) — ${total} posts analyzed`, + "Real performance data from LinkedIn. Saves + Shares matter. Likes don't.", + "════════════════════════════════════════════════════════", + "", + ]; + + if (winners.length > 0) { + lines.push("✔ WHAT WORKS (high saves + shares):"); + for (const p of winners.slice(0, 6)) { + lines.push(` [${p.pattern_type}] ${p.pattern_value}`); + } + lines.push(""); + } + + if (losers.length > 0) { + lines.push("✗ WHAT FAILS (low engagement, gets ignored):"); + for (const p of losers.slice(0, 6)) { + lines.push(` [${p.pattern_type}] ${p.pattern_value}`); + } + lines.push(""); + } + + if (state) { + if (state.optimal_length_min && state.optimal_length_max) { + lines.push(`OPTIMAL ARTICLE LENGTH: ${state.optimal_length_min}–${state.optimal_length_max} words`); + } + if (state.top_topics && (state.top_topics as string[]).length > 0) { + lines.push(`TOP TOPICS: ${(state.top_topics as string[]).join(", ")}`); + } + if (state.best_hook_patterns && (state.best_hook_patterns as string[]).length > 0) { + lines.push("BEST HOOK PATTERNS:"); + for (const h of (state.best_hook_patterns as string[]).slice(0, 3)) { + lines.push(` "${h}"`); + } + } + lines.push(""); + } + + lines.push( + "APPLY THESE LEARNINGS: Use winner patterns. Avoid loser patterns.", + "This is not theory — it is what actually performed in production.", + "════════════════════════════════════════════════════════", + ); + + return lines.join("\n"); + } catch { + return ""; // Always safe-fail — never break the pipeline + } +}