Plan 2026: report card domeny na stronie host

Widok hosta (/hosts/:hostname) pokazuje dziś mniej użytecznych informacji, niż pozwala baza — kod już zawiera dane, których nie renderujemy: dns.*/tls.* na hoście, historię errors, protocol, cf_block, quality_score, content_length + text_len (baza pod complexity i carbon), health.

Cel: przekształcić stronę domeny w publiczny report card — Błędy / Security / Tekst-SEO / Complexity / Carbon z ocenami A–E i listą rekomendacji. Właściciel strony ma z jednego widoku dowiedzieć się, co poprawić. To realizuje kierunki z Co jeszcze możemy wdrożyć (internet health observatory, crawl cost accounting, oszczędzanie energii) oraz SEO na podstawie crawlingu.

Value / Effort

Fazy i poprawki do wprowadzenia

Faza 1 — tylko UI, dane już w bazie

1. Panel Security: kontroler domeny już wyszukuje target (MongoStore.find_by_url("targets", url) w _index_item.html.erb). Przekazać znaleziony dokument do collections/_next_security — partial jest generyczny (czyta doc["dns"], doc["tls"]), więc działa bez zmian.
2. Panel Błędy: zapytanie do kolekcji errors po url/hostname (ostatnie N wpisów: reason, status, redirect_chain, created_at) + last_error/attempts z targetu; link do /errors?url=....
3. Panel Carbon: liczyć z zapisanego content_length tym samym wzorem co UrlInspector#carbon_estimate — wydzielić do wspólnego helpera. Zaktualizować współczynniki do Sustainable Web Design v4 (0.81 kWh/GB to przestarzały model; v4 rozdziela datacenter / sieć / urządzenie i daje ~0.36 kWh/GB części sieciowej). Podawać zawsze basis, żeby liczby były porównywalne w czasie.
4. Rekomendacje Tekst/SEO — czysta funkcja doc → [rekomendacje] na polach już zapisanych:

Sekcja zastępuje statyczny akapit "Research analysis" (auto-generowany duplicate content — zgłoszony już w dokumencie SEO).

1. Complexity score v1 z istniejących pól: stosunek text_len / content_length (narzut markupu), redirects, protocol (HTTP/1.1 vs h2/h3), latency_ms, cf_block.
2. Report card: pasek 5 badge'ów A–E na górze strony (Errors / Security / SEO / Complexity / Carbon), każdy linkuje kotwicą do swojego panelu.
3. Pola publiczne: dodać do PUBLIC_INDEX_FIELDS (application_helper.rb): quality_score, lang, canonical_url, indexed_at, protocol.

Faza 2 — crawler zapisuje nowe sygnały (wymaga re-crawla)

1. Security headers: w crawler/parsing.py → build_item sub-dokument security z nagłówków odpowiedzi: hsts, csp, x_content_type_options, x_frame_options, referrer_policy, permissions_policy (bool/str, proste typy).
2. SEO/complexity przy crawlu: h2_count, links_int/links_ext, images_missing_alt, json_ld_count, liczba i ciężar <script>/<style>. Przenieść definicje metryk z live-only UrlInspector#seo_data tak, aby crawl i live inspection liczyły to samo.
3. Carbon per crawl: pole carbon_g na dokumencie + suma w crawls — punkt "mierzyć koszt crawla per root domain" z roadmapy. Optymalizacja

• Warunkowy parsing (Early Exit): Pomijaj ekstrakcję metryk SEO/Complexity dla statusów innych niż 200 OK, ... oraz dla typów MIME innych niż text/html.
• Kompresja schematu BSON: Przy wielomilionowym korpusie używaj skróconych kluczy w poddokumentach MongoDB (np. seo, sec, carb), aby zminimalizować narzut indeksów i zużycie RAM.
• Jedna biblioteka parsująca (DRY): Jeśli UrlInspector (Ruby) i Crawler (Python) mają liczyć to samo, przenieś logikę liczenia wag i tagów HTML do Crawlera. Live inspection może wywoływać Crawlera asynchronicznie przez mikro-API lub kolejkę, eliminując potrzebę przepisywania logiki na dwa języki.

Faza 3 — obserwatorium 2026

1. Dashboard agregaty: adopcja HTTPS / HSTS / h2+h3 / IPv6 per region i suffix, suma CO2e korpusu, mediana wagi strony — publiczne metryki "stanu internetu".
2. AI-readiness: /llms.txt, polityka robots dla botów AI (punkt 1 roadmapy).
3. Trendy: historia ocen domeny w czasie (po wdrożeniu statystyk okresowych).

Implementacja techniczna

Architektura (DDD)

• Nowe value objects w warstwie UI (ui/app/services/), czyste funkcje bez stanu:
• DomainReportCard — wejście: dokument hosts (+ opcjonalnie sparowany target), wyjście: hash {errors:, security:, seo:, complexity:, carbon:} z oceną a..e i listą rekomendacji per sekcja;
• CarbonEstimate — jeden wzór dla UrlInspector i report card (usuwa duplikację).
• Zero nowych kolekcji w fazie 1 — wyłącznie prezentacja danych już zapisanych; ocena liczona przy renderze (dokumenty są małe, brak potrzeby cache).
• Faza 2 rozszerza agregat hosts o sub-dokumenty security i seo — spójnie z istniejącym wzorcem dns/tls na hosts. Ubiquitous language: sec, seo, carbon_g — te same nazwy w Pythonie, Mongo i Rails.
• Kontroler: akcja show domeny dokłada @target (już wyszukiwany) i @errors (jedno zapytanie z limitem); brak dodatkowych round-tripów przy braku danych.
• Pre-agregacja dashboardu (Materialized Views): Całkowicie zrezygnuj z agregacji on-the-fly na kolekcji produkcyjnej. Uruchamiaj dobowy skrypt map-reduce lub agregację w tle, zapisując wyniki do dedykowanej, płaskiej kolekcji global_network_stats.
• Ograniczona tablica trendów (Capped History): Zamiast tworzyć nową kolekcję dla historii ocen, przechowuj historię wewnątrz dokumentu domeny jako tablicę obiektów o stałym limicie wielkości (np. ostatnie 12 miesięcy).

# MongoDB update via Mongoid / Ruby driver
RootDomain.where(id: domain_id).to_adapter.update_attributes(
  '$push' => { 
    trends: { 
      '$each' => [{ date: '2026-07', scores: 'AABCE' }], 
      '$slice' => -12 # Keeps only the last 12 snapshots
    } 
  }
)

• Heurystyka AI-Readiness: Rozszerz sprawdzanie /llms.txt o automatyczny skan pliku robots.txt pod kątem dyrektyw disallow dla znanych User-Agentów botów AI (GPTBot, ClaudeBot, PerplexityBot). Pozwoli to na stworzenie unikalnego wskaźnika "AI Resistance Score" w dashboardzie agregatów.

Czy progi ocen A–E dla wskaźnika Carbon powinny uwzględniać podział na strony mobilne i desktopowe, czy zachowujemy jeden globalny standard Sustainable Web Design v4?

Design widoku /hosts/:hostname

[ URL + linki targets/WWW ]
[ A  Security ][ B  SEO ][ C  Errors ][ B  Complexity ][ A  Carbon ]   <- report card, badge A–E
[ Content ]                       [ Rekomendacje (lista "co poprawić") ]
[ Technical ]                     [ Quality ]
[ Security: DNS | TLS ]           [ Errors: ostatnie wpisy + last_error ]
[ Complexity: ratio, protokół ]   [ Carbon: bytes, kWh, gCO2e, basis ]
[ Admin / Live URL inspection ]   <- bez zmian, tylko admin

• Badge: istniejące klasy Bootstrap (text-bg-success/warning/danger), konwencja kolorów jak przy ratingu TLS cipher w widoku targets.
• Panele to karty w istniejącej siatce row g-3; każda sekcja ma kotwicę (#security, #seo, ...).
• Wersja publiczna pokazuje report card i rekomendacje (bez sekcji Admin) — to jest główne "value dla internetu": darmowy audyt domeny, analogicznie do oferty monitoringu DNS/TLS.

Ocena A–E (progi startowe)

Progi trzymane w jednym miejscu (DomainReportCard), do kalibracji po pierwszych agregatach.

Kolejność wdrożenia

1. Faza 1 w całości (punkty 1–7) — sam UI, efekt natychmiastowy dla całego korpusu.
2. Punkty 8–10 + re-crawl próbki, kalibracja progów.
3. Faza 3 po zebraniu danych z fazy 2.

Powiązane: Co jeszcze możemy wdrożyć · SEO na podstawie crawlingu