Search
Results for “html”
Index built 45 min ago · 190 repositories · 92,061 paths
Repositories 1
-
poster-ka
Posters de présentation des marques du Groupe KA — HTML autonomes, impression A3 portrait
Files 20
- src/lib/export/html.ts
- types/html-docx-js.d.ts
- docs/connecteurs/html.md
- src/parsing/html_parser.py
- services/parser/html_parser.py
- packages/connectors/src/html.ts
- src/aiatlas/sdk/extract/html.py
- src/lib/export/html-document.ts
- index.html
- index.html
- ui/tx.html
- index.html
- ui/api.html
- dist/404.html
- dist/404.html
- ui/chain.html
- ui/flows.html
- ui/index.html
- ui/token.html
- web/index.html
Commits 20
- Revert "[ka6] fix generic.py _fetch_html: 2e application du fix charset (57dcac4, 11-11, PERDU par un revert concurrent) — honorer l'encodage réel quand le serveur omet le charset dans Content-Type: requests décode alors en latin-1 par défaut (RFC 2616) → mojibake sur les pages UTF-8 (constaté sur rudimenterre.com Hydrogen, « Vous êtes » dans la description ingérée). Si « charset » absent de l'en-tête content-type, r.encoding = r.apparent_encoding (charset_normalizer, livré avec requests) avec repli utf-8; les sites qui déclarent leur charset sont strictement inchangés. Validé par sync réel 2026-11-12: rudimenterre.com ok / 1 avec description UTF-8 propre (« Vous êtes un aventurier… », 585.0 CAD); non-régression atelierora.ca ok / 24 (+0 ~0 -0). Si le mojibake revient: grep apparent_encoding fabrika/connectors/generic.py."
- [ka6] fix generic.py _fetch_html: 2e application du fix charset (57dcac4, 11-11, PERDU par un revert concurrent) — honorer l'encodage réel quand le serveur omet le charset dans Content-Type: requests décode alors en latin-1 par défaut (RFC 2616) → mojibake sur les pages UTF-8 (constaté sur rudimenterre.com Hydrogen, « Vous êtes » dans la description ingérée). Si « charset » absent de l'en-tête content-type, r.encoding = r.apparent_encoding (charset_normalizer, livré avec requests) avec repli utf-8; les sites qui déclarent leur charset sont strictement inchangés. Validé par sync réel 2026-11-12: rudimenterre.com ok / 1 avec description UTF-8 propre (« Vous êtes un aventurier… », 585.0 CAD); non-régression atelierora.ca ok / 24 (+0 ~0 -0). Si le mojibake revient: grep apparent_encoding fabrika/connectors/generic.py.
- Revert "[ka6] fix connecteur colorantic.com: migration de la FICHE woocommerce→shopify (platform shopify + catalog_endpoint /products.json) — le site a MIGRÉ de WooCommerce vers Shopify (HTML live avec shopify.exit_interstitial, vérifié 2026-11-12): /wp-json/wc/store/v1/products renvoie désormais une page HTML Shopify 404 → le fallback ?rest_route= (ab18da4, toujours en place dans woocommerce.py pour les autres cas) renvoie aussi du HTML 200 non-JSON → via Scrapfly « upstream 400 » → broken (6 échecs consécutifs depuis 11-11 ~16h, dernier succès 11-11 14:20 à 241). Vérifié live: https://colorantic.com/products.json?limit=250 → 200 JSON, 240 produits publiés avec prix (tabliers 45,99 $, rubans 7,99 $…). Pattern midi34/santrel/produitszinda (migration Woo→Shopify = migrer la FICHE). Édition directe ciblée de 2 lignes dans data/stores.json (jamais de json.dump global), AUCUN code touché. Sync réel 2026-11-12: colorantic.com ok / 240 produits (+240 ~0 -0) ≈ médiane historique 241.0; les ~241 anciennes fiches Woo (/magasinez/…) seront désactivées automatiquement par MISS_GRACE=2 en 2 syncs (mécanisme standard db.py). Non-régression: ateliersaintcerf.com ok / 62 (chemin shopify nominal), atelierora.ca ok / 24 (chemin generic nominal) — 3 ok, 0 erreur en 6 s. pm2 restart fabri-ka-sync fait, web local 200. Si re-broken: grep -A4 colorantic data/stores.json (doit être shopify + /products.json), re-vérifier la plateforme live avant de toucher la fiche; ne pas toucher woocommerce.py (rest_route sert à d'autres)."
- [ka6] fix connecteur colorantic.com: migration de la FICHE woocommerce→shopify (platform shopify + catalog_endpoint /products.json) — le site a MIGRÉ de WooCommerce vers Shopify (HTML live avec shopify.exit_interstitial, vérifié 2026-11-12): /wp-json/wc/store/v1/products renvoie désormais une page HTML Shopify 404 → le fallback ?rest_route= (ab18da4, toujours en place dans woocommerce.py pour les autres cas) renvoie aussi du HTML 200 non-JSON → via Scrapfly « upstream 400 » → broken (6 échecs consécutifs depuis 11-11 ~16h, dernier succès 11-11 14:20 à 241). Vérifié live: https://colorantic.com/products.json?limit=250 → 200 JSON, 240 produits publiés avec prix (tabliers 45,99 $, rubans 7,99 $…). Pattern midi34/santrel/produitszinda (migration Woo→Shopify = migrer la FICHE). Édition directe ciblée de 2 lignes dans data/stores.json (jamais de json.dump global), AUCUN code touché. Sync réel 2026-11-12: colorantic.com ok / 240 produits (+240 ~0 -0) ≈ médiane historique 241.0; les ~241 anciennes fiches Woo (/magasinez/…) seront désactivées automatiquement par MISS_GRACE=2 en 2 syncs (mécanisme standard db.py). Non-régression: ateliersaintcerf.com ok / 62 (chemin shopify nominal), atelierora.ca ok / 24 (chemin generic nominal) — 3 ok, 0 erreur en 6 s. pm2 restart fabri-ka-sync fait, web local 200. Si re-broken: grep -A4 colorantic data/stores.json (doit être shopify + /products.json), re-vérifier la plateforme live avant de toucher la fiche; ne pas toucher woocommerce.py (rest_route sert à d'autres).
- Revert "[ka6] fix generic.py _fetch_html: honorer l'encodage réel quand le serveur omet le charset dans Content-Type — requests décode alors en latin-1 par défaut (RFC 2616) → mojibake sur les pages UTF-8 (constaté sur rudimenterre.com Hydrogen, « Vous êtes » dans la description ingérée). Fix général et non site-spécifique: si « charset » absent de l'en-tête content-type, r.encoding = r.apparent_encoding (charset_normalizer, livré avec requests) avec repli utf-8. Les sites qui déclarent leur charset sont strictement inchangés. Validé par sync réel 2026-11-11: rudimenterre.com ok / 1 produit avec description UTF-8 propre (« Vous êtes un aventurier… », 585.0 CAD); non-régression atelierora.ca ok / 24 (+0 ~0 -0) et maisondherbes.com ok / 122 (+0 ~0 -0) — aucun contenu modifié sur les boutiques qui déclaraient déjà leur charset."
- V9 design (2/2): provider and venue logos in Swap and Futures, agent cards, iOS launch images, showcase, performance tooling
- Wave 1: Optimism, BNB Chain, Avalanche, HyperEVM; 24 verified tokens (63 deployments); asset page with chart
- [ka6] fix connecteur sante_montreal: nouveau variant du challenge Radware « Radware Page / Loader page » sur emplois.santemontreal.qc.ca — rejeu de la session Scrapfly en render_js quand le loader est détecté (njoyn.py). Stale causé par 2 échecs « page liste illisible (118 446 octets) » à 16:15 et 17:45 après un vert found=809 à 12:53 : le domaine personnalisé sert depuis cet après-midi une page de challenge JS (<title>Radware Page</title>, « Loader page », incident-id, script stormcaster.js) en HTTP 200, MÊME via Scrapfly ASP sans rendu JS — l'ancien mur « Radware Block Page » de septembre était franchi par ASP seul, ce nouveau variant exige l'exécution du JS. Mono-tenant prouvé : les 10 frères Njoyn (cgi, rtc_quebec, stl_laval, rtl, cusm_ir, groupe_master, groupe_bellemare, ville_gatineau/terrebonne/mirabel) TOUS verts sur la même fenêtre, donc ni maintenance plateforme ni blip du frontal (angles déjà couverts par les fiches njoyn-*). Reproduction live : curl direct ET Scrapfly render_js=False renvoient le loader 118 446 octets 0 offre ; render_js=True seul ne suffit PAS (loader encore servi) ; render_js=True + rendering_wait=10000 franchit le mur (page liste réelle, 50 articles) et la clearance COLLE à la session Scrapfly — l'appel suivant sans JS sur la même session reçoit la vraie page (vérifié 3 appels successifs), donc pagination POST et pages détail repassent au tarif économique. Fix minimal dans njoyn.py : _RADWARE_LOADER_RE (marqueurs « Radware Page »/« Loader page » UNIQUEMENT — gotcha : perfdrive et stormcaster apparaissent AUSSI dans la vraie page liste, monitoring Radware embarqué, ils ne discriminent pas) + helper _scrapfly_html qui escalade en render_js+wait sur la même session quand le loader est détecté, branché sur les deux chemins de _html (USE_SCRAPFLY direct et bascule auto) ; coût : 1 appel render_js par sync tant que Radware sert le loader, zéro changement pour les tenants non touchés. Docstring chronologie mise à jour dans sante_montreal.py. Tests réels : run.py sync sante_montreal → ok=1 found=828 (médiane 809.5) added=10 updated=37 removed=2 en 98,6 s (contre ok=0 avant) ; 108 tests pytest verts ; fiches sante_montreal.md + ats-njoyn.md + INDEX.md régénérées (1131 autres restaurées hors périmètre) ; pm2 restart job-ka-sync OK ; site local 200, www.job-ka.com 200. Si le loader évolue encore (taille ~118 ko, title différent), vérifier d'abord que _RADWARE_LOADER_RE matche toujours dans les 4000 premiers octets.
- public overview: background refresh (inline recompute took 40 s); HTML no-cache, hashed assets immutable
- [ka6] connecteur orthoclinical: stale = faux positif « volume QC nul » (récidive, 2e intervention) + unique ok=0 = fenêtre de maintenance planifiée Workday, rien à réparer — syncs VERTS en continu (ok=1 found=0) depuis la dépublication légitime de R0016868 le 2026-10-14 (intervention précédente), le « aucun succès depuis 394,7 h » de la supervision compte found=0 comme non-succès ; profil « ok=1 found=0 médiane 0.0 » (70+ cas, fiche stale-volume-zero-faux-positif, orthoclinical y figure déjà). L'unique échec du 2026-10-31 02:24 était la fenêtre de maintenance planifiée Workday (302 → static.community.workday.com/maintenance-page.html), SYSTÉMIQUE (~40 tenants, même épisode que myview 2a5092fe) — fiche workday-maintenance-fenetre-systemique appliquée : cxs re-sondé 200 = fenêtre finie. Re-vérification live exhaustive : board vivant total=20 (US/Inde/Tchéquie/Allemagne), searchText Quebec/Québec/Canada/Montréal = 0, unique offre multi-lieux R0016638 = 5 lieux US au détail cxs ; zéro migration d'ATS. found=0 est le reflet EXACT de la source, reverdira seul à la prochaine publication QC de QuidelOrtho. Sync isolé rejoué : vert ok=1 found=0 en 2,1 s. Aucun code de fetch modifié, note de re-vérification 2026-10-31 ajoutée à la docstring. Fiches orthoclinical.md/ats-workday.md/INDEX.md régénérées (1132 autres restaurées, hors périmètre). 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Si orthoclinical est re-signalé stale avec board sans lieu QC : rien à faire.
- [ka6] connecteur myview: stale = faux positif « volume QC nul » (récidive, 2e intervention) + unique ok=0 = fenêtre de maintenance planifiée Workday, rien à réparer — le tenant myview.wd3 (Loblaw Provigo/Maxi) est VIVANT et vide depuis la dépublication du 2026-09-08 (R2000587691) : API cxs 200 total=0 sur loblaw_careers ET sdm_careers, site frère careers 7 offres toutes ON/AB/SK, zéro lieu QC, aucune migration d'ATS. found=0 est le reflet EXACT de la source (médiane 0.0, embauche de masse Loblaw via careers.loblaw.ca, le site Workday ne porte qu'un filet d'offres) ; profil « ok=1 found=0 médiane ≤1 » (70+ cas, fiche stale-volume-zero-faux-positif). L'échec consécutif unique du 2026-10-31 02:15 était la fenêtre de maintenance planifiée Workday (302 → static.community.workday.com/maintenance-page.html), SYSTÉMIQUE : ~40 tenants Workday de l'app en rafale 02:06–02:53 (medtronic, michelinhr, miele, moneris, motorolasolutions… = la quasi-totalité des « degraded » du scan), tous reverdissent seuls — fiche workday-maintenance-fenetre-systemique appliquée : cxs sondé 200 = fenêtre finie, sync isolé rejoué immédiatement : vert ok=1 found=0 removed=0 en 1,8 s. Angle mort type Baie-D'Urfé exclu (total=0 global, pas de lieux à relire). Aucun code de fetch modifié, note de re-vérification 2026-10-31 ajoutée à la docstring. Fiches myview.md/ats-workday.md/INDEX.md régénérées (1132 autres restaurées, hors périmètre). 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Si myview est re-signalé stale avec cxs total=0 : rien à faire, reverdira à la prochaine publication QC de Loblaw sur Workday.
- [ka6] fix connecteur ingeniuinc: migration d'ATS SmartRecruiters → site Odoo de l'employeur le 2026-10-27 — tenant SR vidé, nouvelle plateforme odoo.py. Diagnostic : vert found=1 en continu jusqu'à 07:32 EDT, puis ok=1 found=0 dès 10:23 (removed=1 à la règle des 2 absences) — l'unique offre, un fantôme paru le 2021-08-02, dépubliée entre les deux. Vérification live : API postings SmartRecruiters IngeniuInc 200 totalFound=0 (tenant existant mais vidé), page board 404 ; l'entreprise s'est rebaptisée Ingeniu Solutions (ingeniu.ca → www.ingeniusolutions.com) et publie désormais sur son PROPRE site Odoo (module website_hr_recruitment, /jobs) : 2 offres publiées. Nouvelle classe de plateforme jobka/connectors/odoo.py (pattern glow) : liste HTML rendue serveur (cartes jobs_grid, ancre /jobs/<slug>-<id>, titre <h3>, libellé <address>), pagination /jobs/page/N suivie, détail par MICRODONNÉES schema.org/JobPosting (meta datePosted/employmentType, div itemprop=description) — ⚠️ la div description ne porte que l'intro, le corps (responsabilités, compétences, avantages) vit dans les blocs website-builder qui la suivent : capture jusqu'au footer, CTA retiré ; cache BD + budget de re-visites (JOBKA_ODOO_DETAIL_LIMIT=60), garde-fou anti faux « 0 offre » (marqueur jobs_grid + retry). Lieux en cascade (doctrine bento_sushi, rien d'inventé) : addressLocality structurée → libellé <address> QC → ville citée dans le bloc JobPosting (« à notre bureau de Montréal », « Située à Montréal ») validée contre le référentiel des municipalités QC ; tout ce qui suit <footer> (siège en pied de page) jamais lu. ingeniuinc.py re-pointé sur OdooConnector (ids 743999764601957 → 15/38), sources.json mis à jour (url, careers_url, connector=odoo). Tests réels : fetch isolé 2 offres Montréal (teletravail/hybride, temps_plein, descriptions 2623/3633 car.), sync vert ok=1 found=2 added=2 en 0,3 s (médiane 0.5 — le nouveau board porte réellement 2 offres), 2 offres actives en base, l'ancienne offre SR inactive. 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Fiches ingeniuinc.md/ats-odoo.md/ats-smartrecruiters.md/INDEX.md régénérées (1132 autres restaurées, hors périmètre).
- [ka6] fix connecteur groupepmi: migration d'ATS Zoho Recruit → Glow in the Cloud le 2026-10-27 — tenant Zoho RÉSILIÉ, nouvelle plateforme glow.py. Diagnostic : vert found=10 en continu jusqu'à 07:20 EDT, puis ok=1 found=0 dès 10:10 (retraits suspendus par le garde-fou de dérive) ; le RSS et /jobs/Careers de groupepmi.zohorecruit.com renvoient tous deux une page d'erreur Zoho « groupepmi.zohorecruit.com does not exist » (200, 2596 octets) — tenant supprimé chez Zoho, pas un blip. La page carrières officielle groupepmi.ca/carriere/ pointe désormais (4 liens) vers jobs.glowinthecloud.com/groupepmi : ATS québécois Glow in the Cloud, 10 offres publiées (= médiane historique). Nouvelle classe de plateforme jobka/connectors/glow.py (pattern JazzHR) : liste HTML rendue serveur (cartes avec adresse complète), détail JSON-LD JobPosting (tabulations littérales absorbées par _jsonld), cache BD + budget de re-visites, garde-fou anti faux « 0 offre » (marqueur jobSearch-result + retry). Lieux en cascade (doctrine bento_sushi, rien d'inventé) : adresse de liste → jobLocation JSON-LD → ville citée dans la description validée contre le référentiel des municipalités QC (« Chantier Joliette ») ; le <address> des pages détail est le SIÈGE en footer, jamais utilisé ; 1 offre sans aucun marqueur de lieu correctement écartée. groupepmi.py re-pointé sur GlowConnector (ids 717696… → 20261015002…), sources.json mis à jour (careers_url, connector=glow). Tests réels : fetch isolé 9 offres QC/10 publiées, 2 syncs verts ok=1 found=9 (médiane 10) en 1,1 s puis 1,7 s avec removed=10 (anciennes offres Zoho retirées à la règle des 2 absences), 9 offres actives en base. 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Fiches groupepmi.md/ats-glow.md/ats-zoho_recruit.md/INDEX.md régénérées (1131 autres restaurées, hors périmètre).
- [ka2] fix connecteur immogex: refonte du site — GoDaddy Website Builder → site statique Netlify (www.immogex.com). Au sync de 11:55 le connecteur rapportait found=0 « ok » (zéro silencieux) : immogex.com a été entièrement refait (assets versionnés v=20261026h, déployé le jour même) — l'ancienne page /%C3%A0-louer redirige vers www.immogex.com/a-louer.html, nouveau gabarit SSR sans aucun bloc ABOUT_* (data-aid) que l'ancien parseur lisait. Réécriture : la liste /a-louer expose les logements en cartes <li class=annonce> (titre, adresse, prix, dispo, photo) pointant vers de vraies pages détail /logements/<slug> (nouveauté : galerie complète, immeuble en surtitre, <dl> de faits Disponibilité/Grandeur/Étage/Adresse, description, inclusions) — parsing liste + détail via self.detail() (cache BD, clé = hash titre|adresse|prix|dispo de la carte). external_id = slug de la page détail, PAR UNITÉ — l'ancien schéma nom+civique fusionnait les unités d'un même immeuble (« 4955-4955 » couvrait les logements 14 et 17 du 4955 Fugère) → les 2 anciens ids sont de vrais retraits remplacés par 3 ids granulaires. Garde-fous : ul.annonces introuvable = erreur franche (gabarit changé) ; cartes affichées mais 0 parsée = erreur franche ; ul présent et vide = vrai zéro. Bonus : amenities, étage et immeuble (details), galeries 5-7 photos (vs 1 avant). sources.json : URLs migrées vers www.immogex.com. Fixture ré-enregistrée (4 requêtes, 3 annonces), pytest immogex 2 passed. Testé : fetch() venv → 3 unités (3½, 955-1 355 $, 100 % prix/adresse/dispo/images/inclusions), run.py sync immogex → found=3 ok (added=3, removed=2, 2,8 s) vs médiane 1.0 et dernier bon sync à 2, pm2 restart lou-ka-sync, site :8095 → 200.
- [ka2] fix connecteur gestion_isr: la table listings passée derrière RLS — lecture dynamique de LISTINGS_URL (vue listings_public) + retry anti-timeout. Depuis le run du 2026-10-20 15:03 le connecteur rapportait found=0 « ok » (alerte dérive, retraits suspendus) : le portail location.gestion-isr.com a migré ses annonces publiques vers la VUE expurgée /rest/v1/listings_public (migration 145-listings-vue-publique.sql visible dans le JS inline) et l'ancienne table /rest/v1/listings renvoie désormais 200 [] à la clé anon (RLS) — zéro silencieux classique. Fix : le connecteur lit maintenant le chemin REST dans la const LISTINGS_URL du HTML du portail (même philosophie que l'URL/clé Supabase déjà lues dynamiquement — se répare seul au prochain renommage), erreur FRANCHE si la const disparaît. Piège rencontré en route : la vue est coûteuse côté Postgres — « canceling statement due to statement timeout » (57014 → 500) sur 2 runs sur 4 → retry ×3 (pause 4 s/8 s, pattern solaris 8eff094), même URL (timeout serveur, pas un cache). Schéma de la vue identique à l'ancienne table pour tous les champs consommés (pk, id_app, titre, id, loyer, adresse_geo, units, photos…) : _parse_row inchangé, external_id stables. Fixture ré-enregistrée (2 requêtes, 20 annonces), pytest gestion_isr 2 passed. Testé : fetch() venv → 20 annonces (médiane 20 ; 21 lignes dans la vue, 1 exclue par les filtres), run.py sync gestion_isr → found=20 ok (updated=1, 2,5 s), pm2 restart lou-ka-sync, site :8095 → 200.
- [ka2] fix connecteur nomade: refonte du site — le PDF mensuel remplacé par une mini-app liste.nomadegestion.com, granularité unité. Le run du 2026-10-15 14:48 levait « lien PDF Liste de prix introuvable » : le bouton de la home Squarespace pointe désormais vers /liste-location, page qui embarque en iframe https://liste.nomadegestion.com/ — mini-app rendue serveur (JSON-LD ItemList + sections HTML sémantiques), plus aucun /s/*.pdf nulle part. Réécriture du parseur : lecture des <section class="building-section"> (h2 nom, .owner-addr, .owner-link URL immeuble, data-photos UUIDs → /photo/<uuid>/image — plus besoin du cache détail ni de _fetch_images) et des <article class="unit"> (data-type, data-rent en cents, data-avail "now"/ISO, .unit-meta étage, badges aria-label = inclusions). Plus de pdfplumber dans nomade (la dep reste pour sept_elements/consolata — commentaire requirements ajusté). Schéma d'external_id inchangé ({slug}-{typo.5}-{étage|x} + compteur) : 3 ids réutilisés tels quels (astral-3.5-5, nordet1-5.5-4, nordet2-5.5-1) ; granularité PDF (étages agrégés « 1-4 ») → unité désormais. Téléphone concierge derrière POST /visit-phone avec jeton anti-bot + pot de miel : non collecté (politesse). Garde-fous anti zéro silencieux (pattern sotramont bcdf125) : erreur FRANCHE si aucune building-section ni section no-availability (gabarit remanié) ou si 0 unité parsée alors que les data-total annoncent des logements ; sections vides explicites = vrai zéro accepté. Fixture enregistrée pour la première fois (1 requête, 16 annonces), pytest nomade 2 passed. Testé : fetch() venv → 16 unités (7 immeubles : Nordet 1-2, Melozio, Astral, Bélanger, Griffon, Marie-Chapelier ; 1 275–2 025 $, dates ISO, 3-10 photos), run.py sync nomade → found=16 ok (added=13, updated=3, 0,1 s), pm2 restart lou-ka-sync, site :8095 → 200.
- [ka2] fix connecteur res_soleil: refonte du site — grille de prix HTML remplace l'image OCR « Notre offre ». Les syncs du 2026-10-06 17:18 au 2026-10-07 rapportaient found=0 (dérive signalée, puis les 54 annonces retirées le 07 07:36) et le dernier passage échouait en DNS transitoire (vague systémique connue du nœud). Vérifié live : l'API wp-json closest_residence_locator est intacte (15 manoirs, 200), mais les fiches manoir ne publient PLUS l'image uploads/…/Notre-offre_*.jpg que le connecteur lisait par OCR tesseract — elles embarquent désormais une grille de prix HTML sémantique (section .lrs-<manoir>-pricing : .pricing-row avec .unit-type / .meal-plan « Sans repas | N repas/mois » / .monthly-price « X $ à Y $ »), confirmée sur les 15 fiches. Fix : _parse_grille lit les .pricing-row de la soupe (plus d'OCR, plus de subprocess tesseract, plus de cache detail — la grille est inline), schéma d'external_id {slug}-{typo}-5 et logique de prix (plancher « sans repas » sinon forfait le moins cher) inchangés → aucune ré-ingestion. Erreur FRANCHE si AUCUNE fiche n'a de grille (pattern sotramont bcdf125 : gabarit remanié ≠ vrai zéro — c'est exactement le zéro silencieux qui a causé les retraits). Fixtures enregistrées pour la première fois (16 requêtes, 55 annonces). Testé : fetch() venv → 55 annonces (1½ Manoir Brossard 1 716 $ 60 repas/mois, 3½ 1 464 $ sans repas, 15 photos — 54 historiques + 1 typologie), pytest res_soleil 2 passed, run.py sync res_soleil → found=55 ok (added=1, updated=54 : les 54 retirées réactivées, 16,3 s), 55 actives en BD, pm2 restart lou-ka-sync, site :8095 → 200.
- [ka2] fix connecteur gimcote: rotation d'IP résidentielle collante contre les IP Oxylabs flaguées par SiteGround — même durcissement que boreal_abitibi (763a8ca), qui notait déjà la flakiness gimcote. Le sync du 2026-09-14 06:42 a échoué franc (« challenge sgcaptcha non contourné » sur /property-type/appartement/) : l'unique IP résidentielle collante tirée était elle-même flaguée, et _get_html ne tentait qu'UNE IP à cause du guard `if not self.session.proxies` (fix 12df764) — ~1 run sur 2 selon l'humeur du filtre SiteGround, le passage ka2 du 2026-09-13 19:56 avait diagnostiqué « échec transitoire » mais la récurrence prouve le trou. Vérifié live : direct → 202 sg-captcha: challenge ; session collante fraîche → 200, 75 Ko, cartes présentes. Fix minimal, pattern boreal : _get_html tire jusqu'à 2 nouvelles sessions collantes (sessid en time_ns, fini les collisions de int(time.time())) avant l'erreur franche ; le chemin direct reste tenté d'abord (gratuit si SiteGround déflague l'IP du nœud) ; un éventuel 403 passe déjà par l'escalade du wrapper résilient. Testé : fetch() venv x3 → 79 annonces chaque run (3½ Ste-Foy semi-meublé 995 $/mois, 14 photos — médiane 79.0 pile), pytest fixtures 2 passed, run.py sync gimcote → found=79 ok (14,9 s), pm2 restart lou-ka-sync, site :8095 → 200.
- Add SPB Agent chat widget (Claude Haiku 4.5, streaming) + auto-generated CV software sections
- Editorial redesign, per-project & per-paper detail pages, blog, full CV PDF
README content 20
-
poster-ka
…lection de posters de présentation pour les marques du Groupe KA — des fichiers HTML 100 % autonomes (hors site), pensés pour être ouverts dans un navigateur et imprimés en A3 portrait (ratio √2, 860 × 1216 px). Auteur :…
-
fabri-ka
…uébec , associations, wording du site). SEO / SSR — 385 000+ pages indexables : HTML complet dès la 1ʳᵉ requête, JSON LD schema.org, sitemaps exhaustifs, 301/404/410 propres (détails plus bas). « Inscrire mon atelier » —…
-
job-ka
…ffres sont actives, avec leur volume — des pages SEO programmatiques rendues en HTML côté serveur ( ), indexables et rapides. 3. Carte des offres — /carte Les 21 044 offres géocodées sur une carte MapLibre GL (sans jeton…
-
spboucher.ai
…Fully responsive — mobile first, 1/2/3 column app grid ♿ Accessible — semantic HTML, alt text on all app icons, keyboard friendly nav 💚 Health endpoint — for uptime monitoring 🗺️ Site Map Route Content Hero, bio, educ…
-
uqo-imm1003
…. Arborescence du site généré ( ) 7. Le serveur 8. Chaîne de génération LaTeX → HTML 9. Déploiement sur le cluster MacLustr ( ) 10. Exploitation au quotidien 11. Mettre à jour le contenu 12. Données personnelles, sécurit…
-
htr-platform
…ndencies: (torch ≥ 2.4, transformers ≥ 4.45, accelerate). The frontend is plain HTML, CSS and JS: no build step and no bundler. Keep plus under 70 kB. The CSP forbids inline scripts. The server passes page data (examples…
-
spbgit
…eck). Rendered Markdown is sanitized with a strict allowlist (badges, , , align HTML survive; scripts, iframes, event handlers never do). serves with + sandbox CSP, and repo HTML is served as . hook routes accept loopbac…
-
note-spboucher-ai
…ownership Import Markdown/Notion ZIP/DOCX/PDF/CSV/BibTeX/JSON; export Markdown/HTML/CSV/JSON/ZIP; nightly encrypted backups with off node copy and a tested restore. Architecture One process for UI + API (App Router, rou…
-
chat-spboucher-ai
…XLSX, CSV, images, audio (dictation via STT); drag and drop or paste Artefacts HTML / React / SVG / Mermaid previews in a sandboxed iframe ( , no shared origin) Research deep research runs: plan → sources → extraction →…
-
uqo-imm1033
…. Arborescence du site généré ( ) 7. Le serveur 8. Chaîne de génération LaTeX → HTML 9. Déploiement sur le cluster MacLustr ( ) 10. Exploitation au quotidien 11. Mettre à jour le contenu 12. Données personnelles, sécurit…
-
vrai-prix
…nt pas). Documentation Guide utilisateur en ligne : www.vrai prix.com/doc/index.html — à quoi sert le site, utilisation en 5 étapes, provenance des données, FAQ. Guide PDF téléchargeable : vrai prix documentation.pdf. Mé…
-
immo-ka
…utes les plateformes Ka ; widget de chat KA Agent intégré. SEO programmatique — HTML complet rendu côté serveur, une page indexable par ville / type / ville+type, route canonique , sitemaps et données structurées. API pr…
-
food-ka
…· BeautifulSoup · Scrapfly / Firecrawl (sites anti bot) 1 module par bannière : HTML rendu serveur, APIs JSON (Shopify , WooCommerce Store API), … Frontend React 18 · Vite · TypeScript PWA, react router, ka ui vendorisé,…
-
vquant
…is latest Portfolio analytics latest Web scraping latest HTTP client latest XML/HTML parsing latest Image processing Web Research Engine Source Capabilities Badge Tavily AI powered search with generated answers, time fil…
-
websensor
…he connector turns the observation into a comparable representation: (canonical HTML/plain text with navigation, footers, cookie banners, timestamps, tokens and counters stripped), (sorted keys, volatile paths ignored) o…
-
sorti-ka
…ste Carte (Leaflet à la demande), pilules de filtres actifs, page SEO rendue en HTML. 7 · Page catégorie — Arts & scène — /categorie/arts scene Vue par catégorie (4 225 événements arts scène) combinable avec les filtres…
-
trawls
…é cohérente). Le mode résolu est mémorisé par host. Sortie LLM ready : pipeline HTML → Markdown maison (nettoyage, suppression du boilerplate, scoring du contenu principal, tables avec rowspan/colspan, citations), métado…
-
rent-ka
…vacy by design — no trackers, no third party cookies, no ads. SEO — server side HTML rendering (meta, JSON LD, breadcrumbs), robots and sitemap suite ( , pages/cities/listings sitemaps). Architecture Forked from Lou Ka o…
-
house-ka
…esolved server side. Map = Ka Maps ( , expected at ). SEO — renders server side HTML (meta, JSON LD, sitemaps, ) in English. Mortgage engine — shared with Immo Ka ( ), national Canadian rates. See . Removed vs Immo Ka —…
-
crea-ka
…ogrammatique (rendu serveur) La page telle que servie aux moteurs de recherche (HTML rendu côté serveur avant hydratation de la SPA) : « Créateurs québécois par plateforme — 19 plateformes », une entrée par plateforme av…