DevBehindYou · Nov 8, 2026 · Nov 8, 2026 · Nov 8, 2026
diff --git a/.gitignore b/.gitignore
@@ -42,9 +42,9 @@ tests/load/results/
 # ── Local AI tooling (machine-specific paths) ─────────────────────────────────
 .claude/
 
-# Private operator materials and retirement snapshots (portable protection)
+# Private operator materials and retirement snapshots (portable protection).
+# blog-pipeline/ is tracked so the editorial campaign can be shared and resumed.
 /project-docs/
-/blog-pipeline/
 /docs/mdify-history/
 /.codex-recovery/
 

diff --git a/blog-pipeline/01-STYLE-RULES.md b/blog-pipeline/01-STYLE-RULES.md
@@ -0,0 +1,79 @@
+# 01. Style and Humanization Rules
+
+Write like an engineer who has shipped this explaining it to a peer. Clear,
+specific, opinionated where earned. These rules match the ones LLMiser's Privacy
+Policy and Terms follow, so the whole product speaks with one voice.
+
+`check.mjs` enforces the mechanical rules. The rest is on you.
+
+## Structure
+
+- Start the body with one **TL;DR** line: `**TL;DR:** ...`. Two or three
+  sentences, self-contained. The Blog dialog shows it in its own card.
+- Intro under 120 words. A strong angle in the first sentence and the thesis by
+  the third. No throat-clearing ("In today's fast-paced world...").
+- Every `##` section opens with a 25 to 40 word answer, then the detail.
+- Paragraphs of 2 to 4 sentences. One idea per section.
+- End with `## Frequently Asked Questions` (5 or 6 questions as `###`, each
+  answered in 2 to 4 sentences) and a one-line call to action.
+- Target 1,200 to 2,000 words. The dialog is a reading pane, not a book.
+
+## Punctuation and voice
+
+- **No em dashes.** Use a colon, a period, a comma or "and". Check: `grep -c "—"` is 0.
+- **No semicolons** in prose. The `TL;DR` label is the only allowed one. Code
+  blocks are exempt.
+- Use contractions (you're, it's, don't, we'll).
+- Active voice, present tense where true. Second person ("you") for the reader.
+- Vary sentence length. Mix short punchy sentences with longer ones and never
+  put three sentences of the same length in a row.
+- Bold the primary and secondary keywords on their first natural use only. No
+  forced keyword density.
+- Give one real point of view per `##` section ("in practice", "here's what
+  actually works").
+
+## Banned vocabulary
+
+Rewrite any of these. `check.mjs` flags them outside code blocks.
+
+- **Words:** peril, fraught, thwart, dire, vibrant, bustling, essential, vital,
+  crucial, soul, crucible, tapestry, landscape, pesky, reverberate, enhance,
+  emphasise, delve, revolutionize, folks, foster, labyrinthine, labyrinth,
+  remnant, nestled, symphony, gossamer, enigma, metamorphosis, indelible,
+  embark, navigate, navigating, mastering, elevate, unleash, harness,
+  meticulous, meticulously, complexities, realm, tailored, underpins,
+  everchanging, ever-evolving, daunting, amongst, robust, seamless, seamlessly,
+  leverage, unlock, game-changer, revolutionary, cutting-edge, firstly,
+  moreover, furthermore, additionally, consequently, nonetheless, notably,
+  essentially, subsequently, arguably, ultimately.
+- **Phrases:** "in today's world", "at the end of the day", "needless to say",
+  "it's worth noting", "that being said", "it is advisable", "when it comes
+  to", "in conclusion", "in order to", "not only... but also".
+
+## Visuals
+
+- A banner plus at least 4 figures per article (owner's rule, 2026-10-03).
+  Each figure earns its place: a number comparison, a process, a before and
+  after, or a checklist. No decorative charts.
+- Figure titles are short claims ("Output tokens cost 5x input"), captions
+  name the source or say "Illustration".
+
+## Accuracy (hard rules)
+
+- Every statistic gets a named source and a link where it's used, checked for currency at drafting time. Older primary sources are acceptable when still authoritative.
+- Never fabricate quotes, benchmarks, statistics, authors or token savings.
+- Frame token or size figures as **examples or estimates**. They depend on the
+  document and the tokenizer.
+- Describe only features that exist. Check `03-BRAND-ENTITY.md` and the code.
+- The author is `DevBehindYou` unless a real, named person wrote the piece.
+
+## Final pass
+
+1. Run `node blog-pipeline/check.mjs frontend/content/blog/{slug}.md`
+   and fix every error. Review each warning.
+2. Read the article aloud once. Anything you stumble over, rewrite.
+
+
+## Current roadmap note (4 November 2026)
+
+Use the intent registry and briefs for topic ownership. Keep the existing checker contract, but do not pad an article with unsupported FAQs, figures or claims just to meet a count. If a brief cannot support a useful full article, propose a section in its existing owner instead. These rules do not authorize editing current articles. Public pages render Markdown in addition to the dialog view.
diff --git a/blog-pipeline/02-SEO-GEO.md b/blog-pipeline/02-SEO-GEO.md
@@ -0,0 +1,42 @@
+# SEO and answer-engine rules
+
+Updated 4 November 2026. Authority for assignments: `intent-registry.json`. Authority for metrics: `research/keyword-evidence.csv`. Research limitations and source links: [research/RESEARCH.md](research/RESEARCH.md).
+
+## Corrected evidence
+
+The previous version attributed a keyword-volume table to Google Keyword Planner on 28 September. Its raw export is not present here and conflicts with the later research account of available access. It is **UNVERIFIED historical material**, preserved in `history/2026-11-04-before-roadmap/02-SEO-GEO.md`, and excluded from prioritization. “LOW” advertiser competition would not mean low organic difficulty anyway.
+
+The 26 October Semrush report for “pdf to markdown” is inherited evidence from `../docs/README_KEYWORD_RESEARCH.md`, not a fresh query. All newly proposed keyword volumes are null/unmeasured. No Ahrefs or Planner keyword dataset was acquired in this task.
+
+## Current publishing behavior
+
+Public `/blog/{slug}` pages are statically generated and also appear in the app dialog. The article helper generates a canonical, BlogPosting and BreadcrumbList. Open Graph and Twitter cards currently use the shared `/og-card.png`, not the article SVG banner. The per-article card idea in a brief is a manual social export until separately implemented.
+
+The parser accepts title, slug, description, excerpt, date, author, category, tags, primaryKeyword, optional secondaryKeywords, banner, bannerAlt, featured, draft and updated. Adding invented `canonical`, `ogImage`, `faqSchema` or `seoTitle` frontmatter does not wire them into the renderer. Primary/secondary keywords are editorial inputs, not a ranking mechanism.
+
+## Page content
+
+- Use the owned task in title, opening and main answer naturally.
+- Keep titles concise; around 60 characters is an editorial target, not a universal pixel rule. Description max 170 is an app constraint. Engines can rewrite either.
+- Answer the question first, then explain scope, steps, evidence and limitations.
+- One H1 is generated from title. Body starts with TL;DR and uses H2/H3.
+- Keywords are not quotas. No hidden text, repetitive synonyms or prompt instructions to search bots.
+- Each substantial claim needs a source, a dated measurement or an explicit illustrative label.
+- Dates reflect actual publication or material revision, not automated freshness.
+- Structured data must agree with visible content. No promised FAQ rich results or special AI schema.
+
+## Search and AI visibility
+
+[Google](https://developers.google.com/search/docs/appearance/ai-features) says established SEO practices apply to its AI features. Indexability and useful, reliable content matter; there is no special AI schema requirement or inclusion guarantee.
+
+[Bing's guidelines](https://www.bing.com/webmasters/help/bing-webmaster-guidelines-30fba23a) reject manipulative promotion and AI manipulation. Write material a reader can verify. Do not plant instructions telling an answer engine to recommend LLMiser.
+
+[DuckDuckGo](https://duckduckgo.com/duckduckgo-help-pages/results/sources) largely sources traditional links from Bing while using other sources too. A Bing result is not proof of a DuckDuckGo position. [Brave](https://search.brave.com/help) describes its own index and AI-generated snippets; inspect it separately.
+
+The existing `llms.txt` can remain a factual discovery file. It is not a substitute for crawlable pages or a guaranteed citation technique. Do not conflate SEO tools (Semrush, Ahrefs, Keyword Planner) with answer engines.
+
+## Links and metadata
+
+Use canonical LLMiser URLs. Give each article a relevant parent and contextual siblings, not mandatory reciprocal links. One useful CTA to the converter is enough. Keep `/usecase` and `/privacy` links where relevant.
+
+Update generated blog index, verify sitemap and maintain the existing `llms.txt` guide list in a publication task. No language-blog duplication, old-host crawl blocks, mass keyword landing pages or external link scheme. See [PUBLISHING.md](PUBLISHING.md).
diff --git a/blog-pipeline/03-BRAND-ENTITY.md b/blog-pipeline/03-BRAND-ENTITY.md
@@ -0,0 +1,51 @@
+# LLMiser brand and claims
+
+Updated 4 November 2026. Capabilities below are source-inspected at `8eb8c509`, not freshly conversion-tested for this content pack.
+
+## Identity
+
+**LLMiser**, by **DevBehindYou**. Positioning: **LLM cost optimizer for document inputs**. Tagline: **Make Every Token Count.**
+Canonical origin: https://llmiser.devbehindyou.com
+Repository: https://github.com/DevBehindYou/LLMiser
+License: GPL-3.0. Use the approved study 11 “Prompt L” mark.
+
+LLMiser converts files to editable Markdown so readers can inspect and reduce unnecessary context before using AI. Cost reductions depend on input path, model, workload and retained answer quality. The tool is not provider billing management or an autonomous cost-reduction agent.
+
+Use LLMiser-only current public branding. Historical MDify mentions belong only in explicitly needed provenance. Do not revive markdify.com or use old archive logos/worker counts. Public articles describe reader tasks, not internal database/hosting architecture. Provider documentation can support claims without implying partnerships.
+
+## Capability source map
+
+| Claim | Source to inspect before drafting |
+| --- | --- |
+| Formats, batch/size limits, profiles | `../frontend/lib/formats.js`, `../frontend/lib/siteContent.js` |
+| Upload, review, edit, download flow | `../frontend/components/`, README conversion steps |
+| Retention/privacy | `../frontend/lib/legal/policies.js`, live `/privacy` |
+| Token estimate | `../frontend/lib/documentStats.js` (characters divided by four, rounded) |
+| ZIP outputs/limits | `../backendZ/` and actual fixture outputs |
+| OCR limits/languages | `../backendO/`, public capability copy and readiness |
+| Profiles | Current conversion implementation and original output comparisons |
+| Extension status | `../extension/README.md`, `../docs/ai-handover/HANDOVER.md` |
+
+## What can be described
+
+- Documents: PDF, DOCX, XLSX, XLS, PPTX, EPUB, HTML/HTM, CSV, TSV, JSON, XML, TXT, Markdown.
+- Images: JPG/JPEG, PNG, WebP, TIF/TIFF, BMP, GIF; verify first-frame behavior when discussing animation.
+- Scanned PDF pages use OCR; current configured recognition is English. Six interface languages do not imply six OCR languages or translation.
+- ZIP projects produce combined Markdown and project index/manifest artifacts. Inspect actual contents before explaining fields or completeness.
+- Standard, Clean, Compact and RAG-ready profiles. RAG-ready markers are not an embedding service, vector database, retrieval engine or quality guarantee.
+- Editable output, copy and Markdown/ZIP download. Rough character-based token estimate, not model billing.
+- Current upload limits: 20 files per batch, 15 MiB document/ZIP and 10 MiB image (UI says MB); other decoded-image, archive and scanned-page limits also apply. Do not advertise “unlimited.”
+- Files upload to the service. Link the current privacy policy for retention and exceptions; never claim browser-only conversion or immediate deletion.
+- Extension source exists as a toolbar popup with file conversion and user-triggered Paste. Public store availability and native acceptance are not established by this pack. No extension CTA until checked.
+
+## Never claim
+
+Automatic model routing/caching, guaranteed bill reduction, live provider billing, provider-tokenizer accuracy, automatic LLM submission, translation, multilingual OCR, legacy .doc/.ppt, reverse conversion, flawless tables/formulas/charts, guaranteed image understanding, guaranteed secret detection or complete ZIP extraction.
+
+## Claims and experiments
+
+For token/cost comparisons, record input fixture/hash, representation, model/version, tokenizer or heuristic, price source/date, cached/uncached input, output, OCR/extraction costs and answer-quality criteria. Distinguish a worked example from observed billing. Conversion memory savings are not LLM token savings.
+
+Old model-price and image-token examples in earlier pipeline documents are historical, not preapproved evergreen facts. Recheck official provider documentation before reuse. A smaller input can omit decisive evidence. Explain when the original PDF/chart/image should accompany the text.
+
+Byline is DevBehindYou unless a real contributor is named. Never fabricate test results, quotes, customer stories, authors, review scores or statistics.
diff --git a/blog-pipeline/04-OUTPUT-FORMAT.md b/blog-pipeline/04-OUTPUT-FORMAT.md
@@ -0,0 +1,35 @@
+# Article and metadata contract
+
+Source of truth: `../frontend/lib/blog.mjs`, `../frontend/lib/articleSeo.mjs`, `../frontend/app/blog/[slug]/page.js`.
+
+Draft in `Blogs/{slug}/draft.md` first. The finished application file is `frontend/content/blog/{slug}.md`. The actual slug must match its filename.
+
+```yaml
+---
+title: "Use the approved registry title"
+slug: "reserved-slug"
+description: "Use the approved description, at most 170 characters."
+excerpt: "A useful one- or two-sentence card summary."
+date: "YYYY-MM-DD"
+author: "DevBehindYou"
+category: "GUIDE"
+tags: ["Document conversion", "Markdown", "AI context"]
+primaryKeyword: "Owned primary phrase"
+secondaryKeywords: ["Relevant variant"]
+banner: "/blog/reserved-slug/banner.svg"
+bannerAlt: "Describe the actual banner."
+featured: false
+draft: true
+---
+```
+
+This is a template, not parser-valid metadata until placeholders are filled. Actual publication date is required; no future-date publishing. Optional `updated` is the real material revision date. Parser supports scalar strings, booleans and flow arrays, not nested YAML. Tags: 3–6. Secondaries: at most four.
+
+Body begins with `**TL;DR:**`. Use H2/H3, simple tables, fenced code only when useful and verified, and ordinary links. A figure is a standalone line:
+`![Descriptive alt](/blog/reserved-slug/figure-name.svg "Caption and source")`
+
+Keep the existing banner + at least four useful figures rule. SVGs must pass the app safety checks. No figure-count padding with fake charts. Public article pages render Markdown; the app also has its dialog reader.
+
+The app derives canonical/OG/Twitter/BlogPosting metadata. Shared social card is currently `/og-card.png`. Proposed social image exports do not become page metadata automatically. Existing post order is featured first, then newest date, then title, not just newest.
+
+Read [PUBLISHING.md](PUBLISHING.md) before moving anything into the public app. Keep raw sources, local evidence and post drafts in this private workspace.