Valida una o más páginas HTML contra los techos/pisos duros declarados en un SEO.md (protocolo: github.com/MauricioPerera/seo-md).

No escribe contenido — solo verifica lo que ya se escribió. Chequea: / dentro de sus presupuestos de caracteres (max_chars, y min_chars si está declarado), contra locale, que cada página no-pilar linkee a una pillar_page, títulos duplicados entre páginas, términos prohibidos bloqueados en / (informados, no bloqueados, si aparecen en el body — evita falsos positivos en frases comparativas), techo de densidad de keywords (nunca exige presencia), forbidden_structure (solo "table" tiene sentido en HTML), y validez del JSON-LD si está presente.

Args:

• config (string): el bloque YAML de frontmatter de tu SEO.md, tal cual (sin los ---).

• pages (array): páginas a validar, cada una { ruta, html }.

Returns: texto "PASS"/"FAIL" seguido del detalle por página (✗ = gate duro que bloquea, · = señal blanda informativa que nunca bloquea), más structuredContent con el resultado crudo.

Errores: si config no es YAML válido, o si a una página le falta /, se reporta como violación de gate duro, no como excepción — sigue devolviendo PASS/FAIL sobre el resto.

Valida un tagline + descripción de lanzamiento de Product Hunt contra los techos duros declarados en un PRODUCTHUNT.md.

A diferencia de lint_web_content, los términos prohibidos (negative.terms) se bloquean en TODO el post, no solo en una superficie corta — no existe un uso legítimo de "votá por nosotros" en tu propio tagline o descripción (Product Hunt lo prohíbe sin matices y remueve el post).

Args:

• config (string): frontmatter YAML de tu PRODUCTHUNT.md.

• tagline (string), description (string): el contenido a validar.

• imageCount (number, opcional): cantidad de imágenes en la galería, para chequear contra gallery.min_images.

Returns: texto "PASS"/"FAIL" con el detalle, más structuredContent.

Valida un copy de feed y/o un artículo de newsletter de LinkedIn contra los techos duros de un LINKEDIN.md. Los dos formatos son schemas separados (feed_copy / newsletter_article) porque casi no comparten restricciones reales — mandá al menos uno de los dos, podés mandar ambos.

El contenido del artículo es estructurado (title, seoDescription, hook, contextParagraph, sections: [{heading, body}], closing), no texto libre a re-parsear con regex de headings — contar secciones es leer la longitud del array.

forbidden_structure en LinkedIn SÍ chequea "table", "raw_html" y "literal_markdown" (a diferencia de lint_web_content, donde el medio ya es HTML y solo "table" aplica) — el editor de LinkedIn no renderiza ninguno de los tres.

Args:

• config (string): frontmatter YAML de tu LINKEDIN.md.

• feedCopy (opcional): { text, hashtags? }.

• newsletter (opcional): { title, seoDescription, hook?, contextParagraph?, sections: [{heading, body}], closing? }.

Returns: texto "PASS"/"FAIL" con el detalle de cada pieza enviada, más structuredContent.

Genera el bloque JSON-LD () a partir del bloque schema: de un SEO.md — templating puro sobre el YAML, sin LLM de por medio, cero ambigüedad posible (SEO.md, regla 6).

Requiere que schema: tenga default_type, name y description — sin esos dos últimos no hay JSON-LD válido que generar, y el tool falla con un mensaje claro en vez de generar algo incompleto. applicationCategory/operating_system son opcionales.

Args:

• config (string): frontmatter YAML de tu SEO.md.

• url (string, opcional): URL de la página específica, se agrega como campo "url" del JSON-LD.

Returns: el objeto JSON-LD y el string del completo, listo para pegar en el .