fix(blog): complete pipeline rewrite — eliminate sections/bullets, fix DR4 wavelength, fix scope description

Core changes:
- HARD RULES rewritten: zero tolerance for ## headers, #### Scenario: patterns, bullet sections
- Gold article added as reference standard in STEP4_MASTER_DRAFT
- MANDATORY SECTIONS removed — replaced with continuous prose requirement
- STEP3_OUTLINE: now a flow plan (3-4 beats), not a section list
- STEP5_REALITY_INJECTION: no longer adds 'What Breaks' sections — injects into prose
- STEP9_QA_CHECK: format violations now primary HARD FAIL, above content checks
- DR4 wavelength fix: 1310nm = 0.35 dB/km (not 1550nm = 0.22 dB/km)
- Scope description fix: visual inspection tool ≠ loss measurement device
- Invented firmware version numbers now explicit HARD FAIL

packages/api/src/llm/fo-blog-pipeline.ts

@@ -101,36 +101,84 @@ DATA INTEGRITY RULES (ABSOLUTE — harder than anything else on this list):
 - Power specs (dBm, Watts) may ONLY be cited if they appear in the [PRODUCT] data or in the REFERENCE VALUES section below. Never derive or estimate them.
 
 HARD RULES (non-negotiable — article FAILS QA without these):
-1. Start with a BRUTAL hook — not "If you're still..." but "You're about to sign a PO. Stop."
+
-2. Include a "WHAT BREAKS IN PRODUCTION" section with at least 2 SPECIFIC failure scenarios:
+════════════════════════════════════════════════════════
-   - Name the exact problem (e.g., "DR4 link won't come up")
+FORMAT: THE ONE RULE THAT OVERRIDES EVERYTHING ELSE
-   - Name the exact cause (e.g., "wrong MPO polarity — Type A vs Type B")
+════════════════════════════════════════════════════════
-   - Name the exact fix (e.g., "flip the key on one end, or use a Type B to Type A conversion cable")
+
-3. Include a "HIDDEN COSTS NOBODY MENTIONS" section:
+ZERO TOLERANCE FORMAT VIOLATIONS (immediate FAIL):
-   - Cleaning effort (MPO end-faces need inspection scope, not just wipes)
+- NO markdown headers of any kind: ##, ###, ####, **Bold Title:** — NEVER. Not one.
-   - Troubleshooting time (dirty connector = 2 hours of debugging before someone checks)
+- NO "#### Scenario:" patterns — EVER. This is the #1 sign of LLM-generated content.
-   - Migration mistakes (SR4 to DR4 = different fiber count, different patch panels)
+- NO section labels followed by colon: "What Breaks:", "Hidden Costs:", "When Not To:"
-   - Cabling redesign cost (MMF to SMF re-cabling = $50-200 per drop)
+- NO bullet lists as the core structure — failure scenarios, costs, and anti-patterns MUST
-4. Include a "WHEN NOT TO USE THIS" section — every technology has anti-patterns
+  be woven into prose, not listed.
-5. NEVER make absolute statements without conditions:
+- NO numbered "1. 2. 3." recommendations — write as a direct statement in prose
-   BAD: "The cost per Gbit on 400G has dropped below 100G"
+- NO "Let's break down", "Here's why", "In this article" openings — hard fail
-   GOOD: "In most leaf-spine deployments with 50+ ports, 400G cost per Gbit is now below 100G — if you factor in switch density and power"
+- MAX 3-4 core ideas per article — if it covers 7+ topics, it reads like a framework,
-6. Every claim with a number MUST have context (deployment size, vendor, conditions)
+  not an article. CUT anything that doesn't serve the core angle.
-7. The article must feel DIRTY — like someone wrote it after a bad deployment, not after reading a whitepaper
+
-8. Reference specific optics (SR4, DR4, FR4, LR4, ZR, etc.) with REAL problems, not just specs
+════════════════════════════════════════════════════════
-9. Include real numbers (dBm, watts, price per port, cost per Gbit)
+GOLD STANDARD — REFERENCE ARTICLE (match this style):
-10. Cabling reality MUST be addressed: MPO polarity, SR4→DR4 migration fiber count changes, cleaning
+════════════════════════════════════════════════════════
-11. ENDING MUST HIT: Last sentence must be a hammer. Example: "400G doesn't fail in design. It fails in production. Fast." NOT: "Consider your options carefully."
+
-12. NO CHECKLIST endings: If a section ends with 4 tidy bullet points, rewrite as direct prose.
+This is the target. Every article must read like this:
-13. NEVER USE "PoE" in optics context. PoE = Power over Ethernet for endpoints. Use "power consumption per port", "thermal budget", "chassis power envelope" instead.
+
-14. DR4 vs ZR: Always separate. DR4 = leaf-spine (500m), ZR = coherent DCI (80km+). Never treat them as variants of the same thing.
+---
-15. SR4 vs DR4 FIBER COUNT: BOTH use 8 fibers (4 TX + 4 RX). Never say SR4=4 or DR4=2. The difference is MMF vs SMF, reach, and loss budget.
+You're looking at a quote for a few hundred 400G DR4 optics.
-16. POWER PER PORT: 400G ≈ 10-15W/port. 800G ≈ 15-25W/port. A switch chassis draws kW total — NOT per port. Writing "1kW per port" is a HARD FAIL.
+Pricing looks reasonable. Vendor says it's production-ready. Future-proof. Standard stuff.
-17. PRICING CONTEXT: Always distinguish OEM ($1,000-5,000) from compatible ($200-600 for 400G DR4). Mixing them destroys credibility.
+
-18. NO MARKDOWN HEADERS: The article MUST NOT contain ##, ###, ####, or **bolded header lines**. Plain text only. Sections flow naturally or use a single line break.
+And to be fair — none of that is wrong.
-19. MAX 6 SECTIONS: An article with more than 6 named sections reads like a framework, not a human. Combine or cut. Migration guides get 6, opinion pieces get 4.
+
-20. NO REPEATED TOPICS: Each concept (cleaning, polarity, power) may be explained EXACTLY ONCE. If cleaning appears in "hidden costs" it cannot reappear in "cabling reality" as a separate block.
+400G works. It's widely deployed. It's not experimental anymore.
-21. FLOW OVER FORMAT: Prefer connected narrative paragraphs over modular section-bullet-example patterns. The engine's default output feels "assembled" — it should feel "written".
+
+But that's also exactly why people underestimate it.
+
+Because the failure doesn't come from the optics. It comes from everything around them.
+
+Most migrations start with a simple assumption: we're moving from 100G SR4 to 400G DR4. Same concept, just faster. On paper, that makes sense. Both use parallel optics. Both run on eight fibers. Same connector family. Looks like a clean upgrade.
+
+In reality, that's where things start drifting.
+
+The moment you move from multimode to singlemode, your entire margin for error shrinks. What used to be "good enough" suddenly isn't. Connectors that worked fine at 100G start causing problems at 400G.
+
+[...continues as prose with NO section headers...]
+
+400G doesn't fail in design. It fails in production. Fast.
+---
+
+WHAT MADE THAT ARTICLE WORK:
+- Started with a real situation (signing a PO)
+- No section labels anywhere
+- Failure scenarios described as natural narrative: "links that don't behave consistently"
+- Costs mentioned as consequences within the flow: "that's where the real cost sits"
+- "When not to use" never became a section — it was one sentence at the end
+- Ending hits hard in one line
+
+════════════════════════════════════════════════════════
+TECHNICAL ACCURACY RULES (hard fails):
+════════════════════════════════════════════════════════
+1. DR4 wavelength = 1310nm. Loss = 0.35 dB/km @ 1310nm. NEVER use 1550nm numbers for DR4.
+2. Inspection scope = visual inspection tool for end-face cleanliness. It does NOT measure loss.
+   A scope does not give you "insertion loss readings" — that's an optical power meter (OPM) or OTDR.
+   CORRECT: "inspect with a fiber inspection scope — even a tiny dust particle blocks a lane"
+   WRONG: "verify <0.5 dB insertion loss with a scope" — scope measures nothing
+3. SR4 AND DR4 BOTH use 8 fibers (4 TX + 4 RX). Never confuse fiber count with fiber type.
+4. Firmware versions MUST NOT be invented. Never cite "firmware 9.3.2" or "version 10.0" —
+   that is LLM hallucination. If you mention firmware issues, keep it generic.
+5. POWER PER PORT: 400G ≈ 10-15W/port. 800G ≈ 15-25W/port. NOT per chassis.
+6. NEVER use "PoE" in optics context.
+7. PRICING: OEM ($1,000-5,000) vs compatible ($200-600). Never mix without context.
+
+════════════════════════════════════════════════════════
+CONTENT APPROACH:
+════════════════════════════════════════════════════════
+- Start with a real situation (signing a PO, a deployment, an outage, a customer call)
+- Weave failure scenarios INTO the narrative, not as labeled blocks
+- Mention costs as consequences within the flow, not as a separate section
+- Anti-patterns get ONE direct sentence at the end, not a "When Not To" header
+- Max 3-4 core ideas — pick the best ones and develop them deeply
+- End with a single sentence that sticks
+- Never qualify everything to death — say what you think
 
 REFERENCE VALUES:
 - SFP+ SR: Tx -8.2 to +0.5 dBm, Rx sensitivity -18.0 dBm, 1.0W typical
@@ -205,22 +253,25 @@ Expanded scenarios:
 // STEP 3: OUTLINE GENERATION
 // ═══════════════════════════════════════════════════════
 
-export const STEP3_OUTLINE = `Create a blog outline for a technical article.
+export const STEP3_OUTLINE = `Create a prose outline for a Flexoptix blog article.
 
-Requirements:
+NOT a section list. NOT a structure. A flow plan — the sequence of ideas as the reader will experience them.
-1. Start with a real-world scenario (NOT "Introduction" or "Overview")
+
-2. Focus on decisions, not definitions
+FORMAT: Write the outline as 3-4 narrative beats. Each beat = one core idea and how it connects to the next. No bullet points. No section headers.
-3. Must include:
+
-   - "What people think vs reality" section
+The outline should describe:
-   - "What breaks in production" section
+- Opening situation: what moment the reader is in
-   - Trade-offs with real numbers
+- Core tension: what assumption they have that is wrong
-   - A clear, opinionated recommendation
+- Production reality: 1-2 specific things that fail (described as moments, not scenarios)
-4. No generic sections like "Conclusion" or "Summary"
+- Consequence/resolution: what actually matters at the end
-5. Each section has a specific purpose that helps the reader decide
+
+Keep the outline focused on 3-4 ideas MAX. If you can't write it in 3-4 beats, it's too broad.
 
 Angle: {{ANGLE}}
 Target audience: {{AUDIENCE}}
-Decision question: {{DECISION}}`;
+Decision question: {{DECISION}}
+
+Write the flow plan (3-4 beats, as prose):`;
 
 // ═══════════════════════════════════════════════════════
 // STEP 4: DRAFT GENERATION (MASTER)
@@ -228,56 +279,90 @@ Decision question: {{DECISION}}`;
 
 export const STEP4_MASTER_DRAFT = `Write the full technical blog article based on the outline below.
 
-Follow these rules EXACTLY:
+═══════════════════════════════════════════════════════
+FORMAT: CONTINUOUS PROSE — NO EXCEPTIONS
+═══════════════════════════════════════════════════════
 
-MANDATORY SECTIONS (article fails without ALL of these):
+This article MUST be written as continuous flowing prose. Like the gold standard below.
-1. BRUTAL HOOK (3-5 sentences) — put the reader in a real situation. Not "If you're still planning..." but "You're about to sign a PO for 200 optics. The vendor quote is on your desk. Before you sign — read this."
-2. WHAT PEOPLE THINK vs REALITY — challenge a specific common assumption with evidence
-3. SPEED/TECHNOLOGY BREAKDOWN — only what matters for the decision, with REAL numbers
-4. WHAT BREAKS IN PRODUCTION (MANDATORY, minimum 2 scenarios):
-   - Scenario 1: Specific failure with exact cause + fix (e.g., "DR4 link won't come up → wrong MPO polarity")
-   - Scenario 2: Operational pain point (e.g., "Dirty MPO end-face → 3 dB insertion loss → intermittent CRC errors → 2 hours debugging")
-   - Include: firmware incompatibilities, cabling mistakes, power budget violations
-5. HIDDEN COSTS NOBODY MENTIONS (MANDATORY):
-   - Cleaning effort (MPO requires inspection scope at $2K, not just IPA wipes)
-   - Troubleshooting time ($150/hr engineer × 4 hours for a dirty connector = $600 per incident)
-   - Migration costs (SR4→DR4 = same fiber count but completely different fiber TYPE, new patch panels, re-termination — people assume it's just an optic swap, it's not)
-   - Cabling redesign (MMF→SMF = $50-200 per drop × number of drops)
-6. WHEN NOT TO USE THIS (MANDATORY):
-   - Small DCs (<50 ports)
-   - Legacy MMF environments
-   - Specific anti-patterns for the technology discussed
-7. COST + TCO ANALYSIS — real numbers with CONTEXT (deployment size, vendor type, conditions)
-8. CABLING REALITY — MPO polarity (Type A vs B vs C), fiber count changes, cleaning requirements
-9. CLEAR RECOMMENDATION with SPECIFIC CONDITIONS — not "consider your needs" but "If you have X, do Y. If you have Z, do W."
 
-ABSOLUTE STATEMENT RULE:
+ABSOLUTE FORMAT RULES:
-- NEVER write "X has dropped below Y" without conditions
+- NO section headers of ANY kind — no ##, ###, ####, no **Bold Title**, no "Section Name:"
-- ALWAYS qualify: "In deployments with 50+ ports..." or "When you factor in power and density..."
+- NO "#### Scenario:" patterns — the most visible LLM fingerprint that exists
-- EVERY number needs context: price ranges, deployment sizes, vendor types
+- NO bullet lists as structure — failure scenarios are narrative, costs are consequences in prose
+- NO numbered recommendation lists at the end
+- NO "Let's break down", "Here's why", "In this article"
+- NO "WHAT BREAKS IN PRODUCTION" as a header — describe production failures as prose
+- NO "HIDDEN COSTS NOBODY MENTIONS" as a header — mention costs naturally in context
+- NO "WHEN NOT TO USE THIS" as a header — say it once as a direct statement
 
-STYLE:
+ONE STYLE ONLY — PROSE NARRATIVE:
-- Direct, opinionated, occasionally sarcastic
+- Continuous paragraphs, 1-3 sentences each, separated by line breaks
-- Write like you just came back from a failed deployment
+- Start with a real situation that a reader recognizes immediately
-- No buzzwords, no corporate language
+- 3-4 core ideas MAX — developed deeply as experience, not listed as bullets
-- Short sentences, direct paragraphs
+- Failure scenarios woven INTO the narrative as things that actually happened
-- Specific transceiver types (SR4, DR4, LR4, FR4, ZR) with REAL problems, not just specs
+- Costs mentioned as consequences: "that's where the real cost sits — not in the optics"
-- Real numbers (dBm, watts, $/port, €/Gbit, $/year power cost)
+- End with a single sentence that hits. "400G doesn't fail in design. It fails in production. Fast."
 
-STYLE CHOICE:
+GOLD STANDARD REFERENCE (write like this):
-Two valid output formats — pick based on the outline's angle and audience:
-- STYLE A (structured): Max 6 sections, each concept mentioned ONCE. Use plain-text section titles (not markdown headers), failure scenario blocks, minimal bullets. Best for troubleshooting guides, migration how-tos.
-- STYLE B (prose narrative): No section titles, no bullet points, pure flowing paragraphs (1-3 sentences each). Best for roundups, opinion pieces, "state of the technology" takes. Ending MUST be a one-liner reframe, not a list.
 
-Both styles are 10/10 valid. Choose the one that fits the angle selected in the outline.
+---
+You're looking at a quote for a few hundred 400G DR4 optics.
+Pricing looks reasonable. Vendor says it's production-ready. Future-proof. Standard stuff.
 
-FORMATTING RULES (both styles — non-negotiable):
+And to be fair — none of that is wrong.
-- NO markdown headers: ## / ### / #### / **Bold Title:** are FORBIDDEN in the article body
-- NO repeated topics: if cleaning appears in one section, it does NOT appear in another
-- MAX 6 sections in Style A — more than that reads like a framework, not an article
-- PLAIN TEXT ONLY: write section transitions as prose, not as formatted labels
 
-MINIMUM 2000 words. No placeholders. No TODO markers. Complete article.
+400G works. It's widely deployed. It's not experimental anymore.
+
+But that's also exactly why people underestimate it.
+
+Because the failure doesn't come from the optics. It comes from everything around them.
+
+Most migrations start with a simple assumption: moving from 100G SR4 to 400G DR4 is the same concept, just faster. Both use parallel optics. Both run on eight fibers. Same connector family. Looks like a clean upgrade.
+
+In reality, that's where things start drifting.
+
+The moment you move from multimode to singlemode, your entire margin for error shrinks. What used to be good enough suddenly isn't. Connectors that worked fine at 100G start causing problems at 400G. Patch panels nobody touched in years become part of your problem.
+
+You don't see that in the lab.
+
+[...CONTINUES AS PROSE THROUGH THE FULL ARTICLE...]
+
+400G doesn't fail in design. It fails in production. Fast.
+---
+
+WHAT MADE THAT WORK — follow this pattern:
+- Opened with the reader's actual situation
+- No named sections anywhere
+- Polarity problem described as "someone finally traces the physical path" — not "#### Scenario: Polarity"
+- Power mentioned as "shows up later" — not "Power Consumption Section"
+- Ended with one line that reframes everything
+
+═══════════════════════════════════════════════════════
+TECHNICAL ACCURACY (HARD FAILS):
+═══════════════════════════════════════════════════════
+- DR4 = 1310nm. Loss at 1310nm = 0.35 dB/km. NEVER use 1550nm numbers for DR4 links.
+- Fiber inspection scope = visual inspection tool. Does NOT measure insertion loss.
+  A scope shows cleanliness — an OPM or OTDR measures actual loss.
+- Never cite specific firmware version numbers (invented = hallucination = immediate QA fail)
+- SR4 and DR4 both use 8 fibers. Difference = fiber type (MMF vs SMF), not count.
+- 400G per port ≈ 10-15W. Not per chassis. Not "1kW per port."
+
+═══════════════════════════════════════════════════════
+CONTENT APPROACH:
+═══════════════════════════════════════════════════════
+- Include production failures as narrative ("links that don't behave consistently")
+- Include real costs as consequences in the flow ("that's where the real cost sits")
+- Include what not to do as a single direct statement, not a section
+- Every number gets context (deployment size, vendor type, conditions)
+- Max 3-4 core ideas — pick the best and develop them through experience
+
+MINIMUM 1500 words. No placeholders. No TODO markers. No sections. Complete prose article.
+
+Context data from Flexoptix database (verified — use exactly as provided):
+{{CONTEXT_DATA}}
+
+Outline:
+{{OUTLINE}}`;
 
 CONTEXT DATA RULES (read before writing a single word):
 The context below contains REAL data from the Flexoptix product database.
@@ -297,35 +382,40 @@ Context data from Flexoptix database (verified — use exactly as provided):
 // STEP 5: REALITY INJECTION
 // ═══════════════════════════════════════════════════════
 
-export const STEP5_REALITY_INJECTION = `Improve this article by injecting REAL production pain.
+export const STEP5_REALITY_INJECTION = `Improve this article by injecting REAL production experience.
 
-The article is currently too clean, too perfect. It reads like someone who read about networking, not someone who does networking. Fix that.
+The article is currently too clean. It reads like someone who read about networking, not someone who has been in a DC at 2AM chasing a dirty connector. Make it feel real — without adding any section headers.
 
-MANDATORY ADDITIONS (check that ALL exist, add if missing):
+═══════════════════════════════════════════════════════
+CRITICAL: DO NOT ADD NEW SECTIONS OR HEADERS
+═══════════════════════════════════════════════════════
+- Do NOT add "#### Scenario:" headers — this is the #1 LLM tell
+- Do NOT create a "What Breaks in Production" section
+- Do NOT create a "Hidden Costs" section
+- Do NOT create a "When Not To Use" section
+- All reality injections MUST blend into existing prose
 
-1. AT LEAST 2 SPECIFIC FAILURE SCENARIOS with:
+HOW TO INJECT REALITY INTO PROSE:
-   - Exact symptoms ("link flapping every 45 seconds", "CRC errors climbing at 200/min")
+- Take an existing paragraph and extend it with what actually happens in production
-   - Exact cause ("dirty MPO-12 end-face on port 3 of the trunk", "firmware 9.3.2 doesn't support DR4 breakout")
+- Turn a vague statement into a specific moment: "links that behave strangely" → "links that came up clean, ran fine for 6 hours, then started generating CRC errors just as the team went home"
-   - Exact fix ("clean with IBC one-click, re-inspect with 400x scope, verify <0.5 dB insertion loss")
+- Add cost as a consequence, not a section: "That's 3 hours of engineering time at $150/hr because nobody cleaned the connector before deployment"
-   If the article doesn't have these, ADD them in a "What Breaks in Production" section.
+- Mention what engineers usually do wrong — as a natural aside in the flow
 
-2. CABLING REALITY (add if missing):
+FAILURE SCENARIOS — woven into prose:
-   - MPO polarity nightmare: "You ordered Type A cables for a Type B system. Half your links are crossed. That's a $15K re-termination job."
+- MPO polarity: describe as something that happened, not as a scenario template
-   - SR4 to DR4 migration: "SR4 and DR4 both use 8 fibers (4 Tx, 4 Rx). What changes is the fiber TYPE: OM3/OM4 multimode becomes OS2 single-mode. That difference alone changes your entire physical layer — new patch panels, tighter loss budgets, different cleaning tolerances."
+- Dirty connectors: describe the debugging process — what the engineer checked first, last, and what actually fixed it
-   - Cleaning: "An MPO-12 connector has 12 fiber end-faces. ONE dirty end-face = entire link degraded. You need an inspection scope, not just wipes."
+- Cabling reality (MPO-12 = 12 fiber end-faces, ONE dirty = link degraded): weave into existing connector discussion
+- SR4→DR4: fiber TYPE changes (MMF→SMF), not count — mention once, as context for why the existing plant matters
 
-3. HIDDEN COSTS (add if missing):
+COST REALITY — integrated as consequences:
-   - "Your $350 optic just cost you $2,400 in troubleshooting time because nobody cleaned the connector"
+- "An inspection scope costs $1,500. Most teams don't own one. That's why the first few deployments are expensive."
-   - "Re-cabling from MMF to SMF: $50-200 per drop × 200 drops = $10K-40K that wasn't in your optics budget"
+- "MMF→SMF re-cabling: $50-200 per drop. Nobody puts that in the optics budget."
-   - "Training your team on MPO handling: 2 days × 5 engineers × $1,500/day loaded cost = $15,000"
+- Mention once, naturally, not as a named section.
 
-4. QUALIFY ABSOLUTE STATEMENTS:
+TECHNICAL ACCURACY FOR THIS STEP:
-   Find every sentence that says "X is cheaper than Y" or "X has dropped below Y" and add conditions.
+- DR4 scope = visual inspection, NOT loss measurement. A scope does not give dB readings.
-   BAD: "400G cost per Gbit is now below 100G"
+- DR4 runs at 1310nm — if article mentions loss budget, ensure 0.35 dB/km is used.
-   GOOD: "In leaf-spine deployments with 50+ uplink ports, 400G cost per Gbit undercuts 100G by 30-40% — once you factor in switch density and power draw"
+- Do NOT invent specific firmware version numbers — keep firmware references generic.
-
-5. "WHEN NOT TO" SECTION (add if missing):
-   Every technology has anti-patterns. If the article recommends something without saying when NOT to use it, add that section.
 
 Article:
 {{DRAFT}}`;
@@ -477,10 +567,20 @@ WHEN NOT TO USE must be a concrete list, not a vague category:
 
 LOSS BUDGET MATH — always show it correctly:
   CORRECT FORMULA: Loss Budget = TX_min - RX_sensitivity = (-2.9 dBm) - (-7.7 dBm) = 4.8 dB available
-  Then: Link Loss = Fiber Loss + Connector Loss = (0.5km × 0.22 dB/km) + 0.3 dB = 0.11 + 0.3 = 0.41 dB
+  For DR4 (1310nm): Link Loss = Fiber Loss + Connector Loss = (0.5km × 0.35 dB/km) + 0.3 dB = 0.175 + 0.3 = 0.475 dB
-  Then: Margin = 4.8 dB - 0.41 dB = 4.39 dB (healthy)
+  Margin = 4.8 dB - 0.475 dB = 4.325 dB (healthy)
+  For ZR (1550nm/C-band): Fiber loss = 0.22 dB/km — but ZR is a different technology entirely.
+  CRITICAL: DR4 = 1310nm. NEVER use 0.22 dB/km (1550nm) for a DR4 loss calculation.
   WRONG FORMULA: "Loss Budget = TX - (Fiber + Connector)" where result is a negative dBm value — that's the RX level, not the budget.
 
+SCOPE vs LOSS MEASUREMENT:
+  A fiber inspection scope (400x or digital) shows the physical cleanliness of an end-face.
+  It is a VISUAL tool — it does not give dB readings.
+  To measure actual insertion loss you use an Optical Power Meter (OPM) or OTDR.
+  WRONG: "verify <0.5 dB insertion loss with a scope"
+  CORRECT: "inspect with a fiber scope to verify the end-face is clean, then measure insertion loss with an OPM"
+  Any sentence using "scope" + "dB" or "scope" + "loss" is technically wrong. Fix it.
+
 HIDDEN COSTS must have actual numbers, not vague ranges:
   BAD: "A $350 optic turned into a multi-thousand-dollar problem."
   GOOD: "$350 optic → $18,000 problem: 2 engineers × 6h × $120/h = $1,440 troubleshooting, plus missed maintenance window = SLA penalty, plus customer escalation = real business damage."
@@ -495,24 +595,40 @@ Article:
 // STEP 9: QA CHECK
 // ═══════════════════════════════════════════════════════
 
-export const STEP9_QA_CHECK = `Review this article critically as a senior engineer who has been in the field for 20 years.
+export const STEP9_QA_CHECK = `Review this article critically as a senior engineer with 20 years of field experience.
 
-HARD FAIL CHECKS (if ANY of these fail, the article is NOT publishable):
+═══════════════════════════════════════════════════════
+IMMEDIATE HARD FAILS — CHECK THESE FIRST
+═══════════════════════════════════════════════════════
 
-1. PRODUCTION FAILURES: Does the article have at least 2 SPECIFIC failure scenarios with exact symptoms + causes + fixes?
+1. FORMAT VIOLATIONS (HARD FAIL — fix before anything else):
-   → If not: ADD them. "DR4 link won't come up → wrong MPO polarity" is a real example.
+   → Any markdown headers: ##, ###, #### → REMOVE ALL. Not one should remain.
+   → "#### Scenario:" patterns anywhere → REMOVE. This is the #1 LLM tell.
+   → "What Breaks in Production:" as a header → REMOVE. The content stays, the label goes.
+   → "Hidden Costs Nobody Mentions:" as a header → REMOVE.
+   → "When Not to Use This:" as a header → REMOVE.
+   → Bullet lists as core structure → convert to prose.
+   → More than 4 distinct named/labeled sections → COMBINE or CUT.
 
-2. HIDDEN COSTS: Is there a section about costs nobody calculates? (cleaning, troubleshooting time, cabling redesign, training)
+2. TECHNICAL ACCURACY (HARD FAIL):
-   → If not: ADD it.
+   → DR4 loss budget uses 1550nm numbers → FIX. DR4 = 1310nm = 0.35 dB/km.
+   → "verify <0.5 dB insertion loss with a scope" → FIX. Scope = visual inspection tool, not loss meter.
+     A scope shows whether a fiber end-face is clean. An OPM (optical power meter) measures loss.
+   → Specific invented firmware versions (e.g., "9.3.2", "10.0") → REMOVE. Generic references only.
+   → SR4 or DR4 described as different fiber COUNTS → FIX. Both = 8 fibers. Difference = fiber type.
+   → "1kW per port" for 400G → FIX. 400G ≈ 10-15W per port.
 
-3. "WHEN NOT TO USE": Does EVERY recommendation have an anti-pattern section?
+3. FLOW CHECK (quality fail if violations exist):
-   → If not: ADD "When NOT to use this" for every technology recommended.
+   → Article reads like assembled modules, not written experience → identify and flow together
+   → Any paragraph that explains the same concept as a previous paragraph → merge or delete
+   → "Let's break down", "Here's why", "In this article" openings → REMOVE
+   → Ending is a bullet list or numbered recommendation → convert to ONE direct sentence
 
-4. ABSOLUTE STATEMENTS: Find EVERY sentence that makes an absolute claim without conditions.
+QUALITY CHECKS:
-   → "400G is cheaper than 100G" → MUST become "In deployments with 50+ ports, 400G is cheaper per Gbit than 100G when factoring in density"
+4. Does production experience feel real? (Not a textbook scenario, but something that happened)
-
+5. Are costs mentioned as consequences within the narrative, not as a named section?
-5. CABLING REALITY: Is MPO polarity, cleaning, or fiber migration mentioned?
+6. Does the ending hit hard in one sentence?
-   → If not: ADD it. This is the #1 operational pain point.
+7. Would an experienced engineer share this — or roll their eyes?
 
 QUALITY CHECKS:
 6. Any technical inaccuracies? (wrong dBm, wrong reach, wrong specs)