HISTOIRE / Product history

The story of Scanapse

Scanapse evolves through visible decisions: clearer wording, better evidence, a more cautious rule, or a more readable interface. This page keeps that continuity so the current product remains understandable over time.

The history is not a showcase of version numbers. It documents the choices that changed how a domain is observed, how evidence is kept, and how knowledge is presented without hiding limits. Older phases remain when documented, without inventing versions or dates.

DOMAIN NAME

The public history of scanapse.com

This timeline documents the public use of the scanapse.com name in the product. It is not a WHOIS, ownership, or registrant history.

Documented origin of Scanapse

Scanapse has a documented starting point on 11 December 2025. This date concerns the project, not the domain registration.

scanapse.com enters the production scope

Release 2.0.1 places scanapse.com and www.scanapse.com in production scope while almouatin.com remains temporarily in use.

Public identity consolidated

Production configuration, technical contacts and canonical URLs converge on scanapse.com while preserving the temporary deployment trace.

Signed public proof

The public Canary adds dated cryptographic proof to scanapse.com, with verifiable history and continuity.

Documented changes

What changed, release by release

Changes are preserved with their context: reading experience, methodology, security, storage, presentation, and fixes. Technical detail remains when it helps explain a decision.

Version2.9.5-rc.1
Current

Service restoration candidate

This candidate reconnects the forms to the existing engine, separates scan and recovery prerequisites, and refreshes the presentation without removing content. Deployment acceptance remains required.

Workflow

  • Editable inputs and direct execution by default.
  • Authentication independent of recovery tables.
  • Content-addressed assets and responsive light/dark presentation.
Version2.9.4.2
Archived

Deployment and scan-readiness stabilization

2.9.4.2 cleanly blocks new readings until schema 2.9.2 is complete, strengthens the 64/64 to 65/99/21 contract, and aligns delivery with the V4 package contract.

Readiness

  • A public reading is no longer queued when the expected operational schema is not ready
  • The reading service remains paused until its operational storage is ready
  • The public form shows a temporary-unavailability state without exposing schema, SQL, or internal details

Schema 2.9.2

  • The 2.9.1 baseline remains 64/64 with contact_messages.public_id and dependencies.provider_id
  • The complete target remains 65 tables, 99 critical columns, and 21 critical indexes
  • Preflight, migration, and verification capture the application database and reject system databases

Web and delivery

  • The XML sitemap references its XSL stylesheet and rendered XSL links are directly navigable
  • Reading-progress polling is throttled while the tab is hidden
  • FULL and PATCH packages follow the V4 separation between code, database, documentation, and verification evidence
Version2.9.4.1
Stable

Schema deployment hotfix

2.9.4.1 corrects the 2.9.1 baseline contract and hardens the 2.9.2 migration and verification scripts without changing the Phase Resume engine.

Schema

  • The diagnostic uses the real contact_messages.public_id and dependencies.provider_id columns
  • The preflight remains 64/64 and the complete 2.9.2 schema targets 99/99 critical columns
  • The verifier explicitly qualifies scanapse_schema_meta with the captured application database
  • The migration requires the exact 2.9.1 baseline before creating either P2.3B table
Version2.9.4
Stable

P2.3B Phase Resume

2.9.4 resumes an interrupted run from durable checkpoints without recollecting already accepted phases.

Deterministic resume

  • Completed, partial, and skipped phases remain immutable in the resumed run
  • The same scan_run is retained and the previous_scan_id reference stays frozen during resume
  • The resume window is bounded to 30 minutes and the global budget remains limited to three attempts

Persistence and validation

  • The final report and signed envelope are checkpointed exactly so persistence can resume without a new signature
  • The internal schema moves to 2.9.2 through an additive two-table migration after a 64/64 baseline preflight of 2.9.1
  • P2.3B remains locally validated until real recovery and concurrency drills are completed
Version2.9.3
Stable

P2.3A Recovery Core

2.9.3 adds bounded recovery for interrupted jobs without replaying a reading when durable evidence makes replay ambiguous.

Recovery

  • Leases that expire before execution can be returned to the queue without consuming an attempt
  • Explicitly allowlisted transient failures can use bounded retries before a durable run is created
  • An exact final result that is already recorded can be reconciled without rescanning the domain

Administration and observability

  • Manual recovery actions are protected by role, CSRF, reauthentication, and audit
  • Observability measures recoveries, waits, reconciliations, and cases requiring phase-level resume
  • P2.3B Phase Resume remains planned; overall P2.3 and convergence Gate B remain partial
  • The internal schema remains 2.9.1 and no SQL migration is required
Version2.9.2.1
Stable

Reading completion hotfix

2.9.2.1 fixes the technical completion step that could leave a finished reading displayed as still running.

Public flow

  • A finalized reading correctly publishes its terminal state and then automatically opens the available dossier
  • The internal schema remains 2.9.1 and no data migration is required
Version2.9.2
Stable

Public Flow & Surface Cleanup

2.9.2 completes the reading flow through to the public dossier and removes implementation details that are not useful to readers from visible interfaces.

Public flow

  • A completed reading automatically opens its complete or partial dossier when the public result is valid
  • Job completion and its public result are published atomically

Product surface

  • Public and administration interfaces use factual wording without unnecessarily exposing implementation names
  • Application version 2.9.2, internal schema 2.9.1 unchanged, no SQL migration
Version2.9.1
Stable

P2.2 Progressive Persistence

2.9.1 makes scan phases durable: each valid checkpoint is retained before the next phase, public progress reflects only persisted facts, and a dossier may be explicitly partial without inventing unexecuted phases.

Progressive persistence

  • Completed phases are checkpointed in stockage interne with canonical status, bounded result, SHA-256 hash, and persistence timestamp
  • Each job attempt can be linked to its scan_run without exposing numeric identifiers publicly
  • The refresh trigger remains distinct from public in scan provenance
  • The historical verify-scanapse-2.9.0.sql verifier is hardened for phpMyAdmin: the selected schema is captured before information_schema reads and application tables are qualified

Phase truth

  • The completed, partial, failed, skipped, and untested states remain distinct and sequence order reflects actual execution
  • Public progress is derived only from durable checkpoints, with no fake percentage or estimated remaining time

P2.3 boundary

  • Scan jobs remain at max_attempts=1; no automatic retry, backoff, dead-letter, or replay is introduced
Version2.9.0
Stable

P2.1 Asynchronous Scan Jobs

2.9.0 unifies public reads, administration, refreshes, and watchlists in one stockage interne queue: every scan becomes a job executed by the existing scheduler, with minimal public status and WebCron fallback.

Every scan is a job

  • Public submissions, refreshes, administration scans, and watchlists use the same generic scan job
  • Submission returns a UUID quickly and /scan/job/<uuid> follows only actually known states
  • An opportunistic worker may start after the HTTP response; WebCron remains the durable fallback mechanism

Queue and privacy

  • Transactional deduplication reuses an active job for the same domain unless a super-admin forces a new read
  • Jobs do not store raw IP addresses; only the existing daily Scanapse pseudonym is passed to the worker
  • Public status exposes no lease, worker, SQL, or raw internal error

P2.1 contract

  • Additive stockage interne migration from 2.6.1 to 2.9.0 with target_id, trigger_type, and scan deduplication index
  • Scan jobs remain at max_attempts=1; retry and recovery remain reserved for P2.3
  • No public per-phase progress is invented before P2.2 progressive persistence
Version2.8.1
Stable

P1.10 Observability Metrics

2.8.1 closes P1.10 with factual administration observability for the synchronous engine: median/P95, phases, partial runs, scheduler, changes, security, stockage interne errors, and observed versions.

Performance and execution

  • New super-admin-only administration Observability page with 24-hour, 7-day, and 30-day windows
  • Median, P95, minimum, maximum, and sample size are calculated only from actually measured durations
  • Missing durations remain unmeasured and are never turned into 0 ms

Operational quality

  • Failures and partial runs are correlated with phases, safe error categories, security blocks, and stockage interne errors
  • The existing scheduler exposes its states and attempts without being presented as the future P2 asynchronous queue
  • Per-scan retry remains explicitly not instrumented until the P2.3 model

Memory and privacy

  • Temporal changes aggregate persisted canonical summaries and distinguish raw change records
  • The version matrix distinguishes current application, expected/observed schema, engine, rule, and private rulepack
  • All detailed metrics remain private in administration; public /health remains minimal
  • No SQL migration: expected stockage interne schema remains 2.6.1
Version2.8.0
Stable

Canary Trust Layer

2.8.0 turns Canary into a Scanapse trust and public-memory layer with strategic reading, a KM timeline derived from signed evidence, product bridge, administration alerts, and a private operational journal.

Public Trust Layer

  • The Canary page now explains why the proof exists, how to read it, and how it fits the Scanapse method
  • A strategic reading exposes trust state, freshness, publication count, and visible history without an artificial score
  • A KM timeline is derived only from signed envelopes and distinguishes genesis, manual publication, and WebCron renewal

administration and governance

  • The Canary cockpit adds actionable alerts for expiry, continuity, renewal, WebCron, and publication failures
  • A private operational journal keeps bounded secret-free Canary events and explicitly distinguishes them from public signed evidence
  • Journal failures remain fail-open and never turn a successful signature into an application failure

Technical contract

  • The signed scanapse-canary/1 payload and Ed25519 chain remain unchanged
  • No SQL migration: expected stockage interne schema remains 2.6.1
Version2.7.9
Stable

Public Canary UI

2.7.9 makes the public Canary proof more readable and presentation-ready with detailed history, visual states, copyable hashes, responsive layout, and historical metadata extracted from signed envelopes.

Public presentation

  • Public history displays sequence, publication, expiry, origin, state, and proof in a readable card
  • Temporal states use explicit badges and full SHA-256 values remain copyable
  • The layout switches to stacked cards on mobile without losing verification information

Signed metadata

  • Historical publication dates and origin are read from each envelope signed payload
  • An unreadable historical envelope does not break the public page and still keeps its sequence and file SHA-256 metadata
  • No SQL migration and no Ed25519 protocol change
Version2.7.8
Stable

administration Canary Operations

2.7.8 turns Canary into a complete operational workflow with a administration cockpit, direct first publication, observable WebCron renewal, readiness testing, immutable history, and a compact public page.

administration operations

  • The cockpit separates public state, sequence, last publication, next due time, expiry, and WebCron health
  • The first publication saves, signs, and publishes statements in one serialized operation
  • Public verification and automation readiness actions do not change sequence

WebCron and continuity

  • Every authenticated WebCron call records a non-secret heartbeat before the stockage interne dependency
  • Automatic renewal publishes only when due and reuses already approved statements
  • WebCron health distinguishes never seen, active, and late using a default 45-minute threshold

Public proof

  • The public Canary page is more compact with status, dates, continuity, statements, collapsible proof, and bounded history
  • Full fingerprints and SHA-256 values remain accessible and copyable without exposing private material
  • No SQL migration: expected stockage interne schema remains 2.6.1
Version2.7.7
Stable

P1.9 Discovery & Sharing

2.7.7 makes every public dossier discoverable and shareable through a dynamic sitemap, local OG image, factual Report JSON-LD, and native sharing, all governed by the same visibility contract.

Discovery

  • Persisted public dossiers dynamically join the XML and human sitemaps in FR/EN
  • A private or deleted dossier immediately disappears from application discovery surfaces
  • Historical snapshots are not indexed individually

Sharing and structured data

  • Each public dossier gets a locally generated 1200×630 OG image with deterministic ETag
  • JSON-LD adds a schema.org Report node derived only from persisted data
  • Sharing prefers Web Share and keeps a clipboard fallback without tracking URLs

Evidence contract

  • No global score, rating, or safe/unsafe judgment is added to discovery surfaces
  • Expected stockage interne schema remains 2.6.1 with no SQL migration
Version2.7.6
Stable

Domain Guard & Cleanup

2.7.6 blocks dossier creation for domains without DNS evidence, adds controlled domain deletion in administration, and fixes the public Canary state before its first publication.

Domain Guard

  • A DNS preflight using A, AAAA, CNAME, NS, MX, or SOA runs before any durable scan creation
  • A domain without DNS evidence is rejected without a dossier, snapshot, or durable target
  • Resolver failure is distinguished from a nonexistent domain and returns a measurement-unavailable state

administration cleanup

  • The administration scan list adds an Actions column with deletion restricted to super-admins
  • Purge requires CSRF, current password, and exact domain confirmation, and hides the dossier before deletion
  • Reports, files, target, runs, related watchlist/jobs, and scan events are purged in a controlled flow

Public Canary

  • An initialized trust chain without a publication is shown as awaiting its first publication, not as an unconfigured Canary
  • The public Canary page is more compact before the first signed proof and History keeps four shorter milestones
  • No stockage interne migration: expected schema remains 2.6.1
Version2.7.5
Stable

Public Canary Proof

2.7.5 turns /canary into a public proof page with readable status, signed statements, full fingerprints, continuity, immutable history, and direct access to verification JSON.

Public proof

  • Status distinguishes valid, renewal approaching, expired, continuity break, and unconfigured
  • Payload, envelope, identifiers, and fingerprints are shown in full and can be copied
  • The page explicitly explains what the signature proves and what it does not establish

Continuity and history

  • Recent Canary publications link to their immutable JSON envelopes
  • Current verification actually checks the expected predecessor when sequence is greater than 1
  • The History page now documents public use of scanapse.com without claiming to provide WHOIS or ownership history

Public navigation

  • Canary joins the public route catalog and sitemap
  • The footer exposes Canary and the current release version next to the History link
  • No stockage interne migration and no change to the P1.8 Ed25519 protocol
Version2.7.4
Stable

Scanapse 2.7.4

2.7.4 simplifies Canary activation in administration: one personal key initializes or rotates the root and operational key without manual public-key or delegation copy steps.

Version2.7.3
Stable

Canary UI

2.7.3 aligns the public Canary page and administration cockpit with the Scanapse design system without changing the P1.8 cryptographic protocol.

Public interface

  • The /canary page now uses the public editorial hero, cards, verification states and proof blocks
  • The /canary.json and /canary.pub endpoints intentionally remain raw JSON for machine verification

administration

  • All Canary forms now use administration components with readable fields, clear action hierarchy and explicit destructive treatment
  • The Canary cockpit adds status cards and a clearer root, delegation, publication and rotation workflow
Version2.7.2
Stable

Scanapse 2.7.2

P1.8 introduces delegated Ed25519 Canary signing, administration/WebCron automation, and completes verifiable professional exports.

Version2.7.1
Stable

P1 Advanced Evidence

2.7.1 deepens public evidence without turning an unavailable measurement into absence: passive Canary signals, post-quantum TLS according to actual client capability, OpenPGP, DNSSEC, mail and modern Web transport, advanced CSP, and V2 report integration.

Advanced evidence

  • P1 collectors keep observed, not_observed and untested states distinct
  • The post-quantum TLS probe separates local capability, negotiation result and measurement failure
  • DNSSEC separates DS/DNSKEY presence from cryptographic validation

2.7 reliability

  • The temporal engine filters volatile noise without modifying raw evidence
  • Public health is minimal while administration keeps detailed diagnostics
  • The public observatory uses factual counts instead of a knowledge percentage
Version2.6.2
Stable

Single Config Source + administration Left Cockpit

2.6.2 removes release versions from local configuration and rebuilds administration with left navigation, clearer service states and a denser cockpit.

Configuration

  • Application version and expected schema version are defined only in app/config.php
  • config.local.php can no longer override app_version or database.schema_version
  • stockage interne schema remains 2.6.1 and no SQL migration is required

administration

  • Primary navigation moves to the left on desktop and the mobile drawer opens from the left
  • The dashboard strengthens service states, KPIs, recent activity and monitoring
Version2.6.1
Stable

Security + administration UI

2.6.1 separates administration security from the public rate limiter, adds server challenges, a private security log and administrative blocks, then refines the mobile-first cockpit.

Authentication

  • Bootstrap, login and recovery use short single-use challenges and dedicated counters
  • IP remains a private security signal, not the primary attempt counter

Cockpit

  • A Security page centralises events, risks, signatures and active blocks
  • The right rail becomes collapsible on desktop while keeping an accessible mobile drawer

Database

  • Additive migration to internal storage schema 2.6.1 without destructive reset
Version2.6.0.1
Stable

Persistence Fix

2.6.0.1 separates report storage from normalized knowledge indexes so a secondary indexing error can no longer cancel an already stored signed dossier.

Persistence

  • The domain, report, dependencies and verification are committed before V2 normalization
  • A knowledge-table failure becomes a logged degradation and no longer blocks the public folder
  • The The internal storage schema remains at 2.6.0 with no SQL migration
Version2.6.0
Stable

Clean Baseline and verifiable persistence

2.6.0 aligns application and internal storage schema versions, rebuilds a canonical 60-table baseline and makes each persistence stage verifiable from administration without exposing secrets.

Baseline

  • Application and schema now both use version 2.6.0
  • A canonical SQL installer and destructive reset SQL directly recreate all 60 expected tables
  • The SQL verifier checks the real structure instead of trusting only the version number

Persistence

  • Domain, report, dependency, knowledge, verification and transaction writes expose safe technical stages in administration
  • The administration persistence probe writes a temporary domain and report then rolls the transaction back

Mobile-first administration

  • Navigation becomes a right-side rail on desktop and an accessible drawer on mobile
  • Inline SVG icons stay local and CSP compatible
Version2.5.4.2
Stable

administration cockpit and Infomaniak local mail

2.5.4.2 turns administration into an operational cockpit, ties its indicators to recorded reports, adds scans from administration and uses local PHP mail without mail credentials.

administration cockpit

  • The dashboard distinguishes recorded reports, operational activity, messages, hidden domains and jobs requiring attention
  • Scans can be launched from administration and the Scans page falls back to recorded observations when the operational journal is incomplete
  • administration navigation is grouped into Operations, Monitoring, Expertise and Administration

Reconciliation

  • A super-admin can rebuild missing operational runs from scanapse_reports without modifying reports, evidence or visibility decisions
  • Rebuilt historical runs do not invent an unknown application version

Local mail

  • Notifications, administration recovery and replies use Infomaniak local PHP mail transport
  • No mail username or password is required in config.local.php

Database

  • The internal storage schema remains at 2.3.3: no additional SQL migration
Version2.5.4.1
Stable

Hardening, translation and administration diagnostics

2.5.4.1 hardens public forms, completes French and English copy, compacts several editorial surfaces and makes administration stockage interne diagnostics explicit without exposing secrets.

Contact and security

  • Contact adds a honeypot, signed minimum delay, dedicated rate limiting and dangerous or excessive URL checks
  • SMTP notifications remain limited to a reference and administration link, without message bodies

Languages and interface

  • French and English surfaces are harmonised, French apostrophes are corrected and dossier becomes domain folder in English
  • Methodology and comparison use more compact compositions and surfaces compatible with both themes

administration and stockage interne

  • administration distinguishes disabled database, missing driver, failed connection, unavailable schema, version mismatch, incomplete structure and ready state
  • The schema remains 2.3.3 and the verifier also checks prerequisites inherited from 2.3.2
Version2.5.4
Stable

Public observatory and operational administration

2.5.4 makes Scanapse public-by-default behavior explicit, expands administration domain and message administration, secures bootstrap and recovery and fixes one-click light/dark switching.

Public observatory

  • Every scan launched from the public interface remains public by default and enriches the domain stockage interne memory
  • administration can hide the domain folder or its history without deleting stored observations
  • Domain folders and constellation can discover all public readings while curated entries keep their editorial metadata

administration administration

  • stockage interne schema 2.3.3 adds admin email, two-channel recovery, local message replies and soft deletion
  • The first super-admin can be created through a server-token Web bootstrap with a local CLI fallback
  • SMTP notifications never contain contact message bodies

Interface

  • The theme button switches directly between light and dark, with system preference used only on first load
  • History offers direct rescanning of the domain and strengthens the observatory timeline reading
Version2.5.3
Stable

Permanent memory and explanatory history

2.5.3 makes stockage interne the permanent memory for successful readings, turns history into an explanatory timeline and adds accountless visibility control.

Memory

  • The stockage interne schema moves to 2.3.2 and historical reports are no longer purged by age
  • The file cache remains bounded and is not the canonical permanence source

History

  • The History page becomes a paginated timeline explaining domain trajectory and observed changes
  • History and Compare remain noindex and stop exposing snapshots when visibility is private

Domain control

  • A DNS TXT or HTTPS well-known challenge can hide or republish history without an account
  • The raw token is never stored in stockage interne, only its SHA-256 digest is retained

Themes

  • Residual dark backgrounds in the light theme are replaced by semantic surfaces compatible with light, dark and system modes
Version2.5.2
Stable

Editorial block compaction

2.5.2 compacts the short home and domain folder blocks to reduce visual voids, keep card dimensions more consistent and avoid an overlong page.

Home

  • Method and public domain folders are brought together in a simple desktop two-card grid with harmonised height
  • The mobile flow remains vertical and readable without breaking the editorial logic introduced in 2.5.1

Domain folder footer

  • Evidence and the correction or clarification path now share the same two-column zone when space allows
  • Short blocks use more regular dimensions to reduce the feeling of an overly long page

Continuity

  • Engine, administration, 2026.09.4 patterns and stockage interne schema 2.3.1 unchanged; no SQL migration
Version2.5.1
Stable

Visual direction stabilization

2.5.1 corrects visual-direction regressions introduced by Core Domain Folder 2.5.0 without changing the engine, data or product positioning.

Editorial hierarchy

  • Section introductions stay in one vertical flow: label, title, explanation, then content
  • Large section titles are visually tightened without removing the semantic H1 to H4 hierarchy

2.5 page consistency

  • Home, domain folder, public domain folders, angles, glossary, history and comparison use visual components that are actually defined
  • 2.5 public classes without matching CSS rules are replaced by the existing editorial system

Continuity

  • Engine, administration, 2026.09.4 patterns and stockage interne schema 2.3.1 unchanged; no SQL migration
Version2.5.0
Stable

Core Domain Folder

2.5.0 repositions Scanapse as a public domain folder, makes time and evidence first-class concepts and keeps the collection engine as an internal layer.

Domain folder

  • Executive summary, four-block short view and six knowledge states before the twelve detailed angles
  • Snapshot history and comparison with appeared, modified, stable or disappeared changes

Evidence

  • Evidence, methods, limits and reproduction commands only when verification is genuinely supported
  • Deterministic JSON exports with SHA-256, Markdown, URL sharing and printing

Public domain folders

  • Constellation filtered through a curated catalog and public cases shown only when a real stored reading exists
  • Correction and clarification path attached to public domain folders

Acquisition

  • New home centered on product benefit, use cases, time and real domain folders
  • Glossary, public pages for the twelve angles and updated LLM context

Continuity

  • Engine, administration, 2026.09.4 patterns and stockage interne schema 2.3.1 unchanged; no SQL migration
Version2.4.8
Stable

Public index and canonical security.txt

2.4.8 separates the machine sitemap from its human-readable view, publishes a visual FR/EN index and normalises the security.txt entry point without changing the engine.

Sitemap

  • New dark, readable /sitemap page automatically powered by the same catalog as sitemap.xml
  • The XML sitemap remains machine-focused and keeps lastmod, hreflang and automatic generation

Security

  • Root security.txt redirects to /.well-known/security.txt, which exposes email, Contact page, expiration, languages, canonical and policy

Continuity

  • Engine, administration, 2026.09.4 patterns and stockage interne schema 2.3.1 unchanged; no SQL migration
Version2.4.7
Stable

Readable sitemap and structured data

2.4.7 replaces the sitemap XSLT presentation with native XML CSS, adds public structured data and leaves the engine, administration and stockage interne unchanged.

Sitemap

  • The XML remains a standard sitemap but is directly readable in browsers through a local CSS stylesheet without XSLT
  • Logo, FR/EN markers, dates, frequencies and priorities are presented without JavaScript or third-party resources

SEO and AI

  • Indexable public pages expose a WebSite, Organization and WebPage JSON-LD graph
  • HSTS preload is not automatically enabled: this remains conditional on prior verification of every subdomain

Continuity

  • Engine, administration, 2026.09.4 patterns and stockage interne schema 2.3.1 unchanged; no SQL migration
Version2.4.6
Stable

Dynamic sitemap and public route catalog

2.4.6 centralises indexable public pages and produces an automatic, dated FR/EN sitemap that is readable in a browser without changing the engine.

Sitemap

  • The XML sitemap is generated from a single public route catalog and no longer duplicates a hard-coded list
  • Each FR and EN URL keeps its hreflang alternatives and receives a lastmod calculated from source files
  • A local sitemap.xsl stylesheet displays the Scanapse logo and a readable view without changing XML semantics

Continuity

  • FR/EN routing, LLM files, engine, administration, 2026.09.4 patterns and stockage interne schema 2.3.1 unchanged
  • No SQL migration required
Version2.4.5
Stable

Bilingual routing and SEO/LLM discovery

2.4.5 keeps French at the root, publishes English under /en and aligns canonical, hreflang, sitemap, robots and LLM discovery files without changing the engine.

Languages and SEO

  • English public routes use /en while French remains canonical at the root
  • Legacy ?lang= URLs redirect to localized equivalents without relying on browser language
  • Canonical, fr/en/x-default hreflang, Open Graph and sitemap share the same URL topology

Search and LLM

  • Added llms.txt, llms-full.txt, ai.txt and updated humans.txt
  • robots.txt allows public discovery and expresses training opt-out where dedicated crawler tokens exist
  • No change to the engine, 2026.09.4 patterns or stockage interne schema 2.3.1
Version2.4.4
Stable

Editorial pages fixed and layout isolated

2.4.4 fixes a legacy CSS collision that compressed some editorial pages and permanently isolates their layout without changing the homepage, report or engine.

Layout

  • Sections across the eight editorial pages now use a dedicated namespace that no longer inherits the legacy Editorial grid from main.css
  • Contact, Our approach, Read a domain, Records, Security, Privacy, Legal notice and History regain normal width and coherent columns
  • The assets/css/editorial.css stylesheet remains separate from the homepage and report to keep future iterations safe

Continuity

  • Homepage, report, engine, 2026.09.4 patterns and stockage interne schema 2.3.1 unchanged
  • No SQL migration required
Version2.4.3
Stable

More compact reading and harmonised public journey

2.4.3 tightens the report, harmonises public pages, simplifies headings and restores product history in the footer without removing any route.

Report

  • Priority items, legal context, useful texts and changes are grouped in a compact responsive grid
  • Visible relations and open questions are brought together in a shorter complementary reading
  • The domain and main title use more available width to avoid fragmented headings

Public pages

  • Headings, introductions and navigation revised with simpler explanatory wording
  • The History page remains at /changelog and returns to the footer without returning to the header
  • Homepage enriched with a mini domain folder example so a former empty area becomes useful explanation
  • Engine, 2026.09.4 patterns and stockage interne schema 2.3.1 unchanged

Editorial redesign

  • Read a domain, Records, Our approach, Contact, Security, Privacy, Legal notice and History now use their own editorial compositions
  • A dedicated editorial stylesheet isolates these pages from the homepage and report for safer future UX iterations
  • The legal notice identifies Scanapse as a service operated by Koperateur Consulting, Mehdi Kachouri as service manager and publication director, and Infomaniak as hosting provider
  • SEO metadata, introductions and headings are rewritten with descriptive language and no keyword stuffing
Version2.4.2
Stable

Tighter public reading and evidence on demand

2.4.2 simplifies public wording, tightens headings and spacing, filters the public trajectory to useful changes and focuses exports on evidence.

Reading

  • Simplified public navigation: Read a domain, Records and Our approach
  • Stronger domain identity in reports, more compact headings and empty states hidden when they add no value
  • Public trajectory limited to useful changes, with volatile values such as CSP nonces normalised

Evidence

  • Evidence-only JSON export and evidence-only print mode
  • Source icons added to evidence cards
  • Engine, 2026.09.4 pattern and stockage interne schema 2.3.1 unchanged
Version2.4.1
Stable

New visual identity and constellation trace

2.4.1 strengthens Scanapse identity without changing the engine: new constellation S, baseline below the logo, functional palette and a new visual hierarchy for the homepage and report.

Identity

  • New S monogram built from traces, nodes and reading markers
  • Observe · Connect · Understand baseline moved below the logo
  • Favicon aligned with the new mark and teal, copper and violet palette

Interface

  • Homepage and report enriched with constellation motifs, stronger hierarchy and functional accents
  • Twelve angles retained with stronger identity without exposing more technical detail
  • Evidence-first engine and stockage interne schema 2.3.1 unchanged
Version2.4.0
Stable

Explanatory record and regulatory context

2.4.0 puts knowledge management first: understand observations, qualify jurisdiction context, cautiously connect regulatory frameworks, explore twelve knowledge angles, then trace statements back to evidence.

Understand before technical detail

  • The public report now follows Understand, Jurisdiction, Regulation, 12 knowledge angles and Evidence
  • Technical counters become secondary information and are never presented as a global score
  • Detailed evidence and technical metadata are collapsed by default to preserve progressive reading

Jurisdiction and contextual regulation

  • Public jurisdiction uses Established, Probable or To confirm states and shows reasons and limitations
  • Regulatory texts are linked to observed context with relevance levels and official sources
  • Scanapse produces no automatic compliance, certification or illegality verdict from an external scan

Twelve angles and visual identity

  • The twelve 2.3.1 engine mappings remain unchanged but become twelve public knowledge angles
  • Each angle has a distinctive SVG symbol, knowledge state, evolution and Why, How, Purpose and Limitations explanation
  • The engine, rulepacks and fine-grained correlation mechanisms remain server-side
Version2.3.4
Stable

Visual pass and first identity markers

2.3.4 strengthens the visual hierarchy of the homepage and report, introduces the first SVGs for the twelve pillars and improves explanation of record figures without changing the engine.

Interface

  • Short header baseline replaces the version badge
  • Stronger color accents while keeping light, dark and system themes
  • SVG markers added to the twelve pillars with visual continuity in detail panels
Version2.3.2
Stable

Understanding-first homepage

2.3.2 rebuilds the header, homepage and footer around the user journey: scan, understand the twelve pillars, read real measurements and reach evidence without reintroducing a global score.

Homepage and navigation

  • New utility-first hero with immediate scan control and knowledge-record preview
  • Simplified header with direct access to Scan, Observatory, Methodology, Changelog and Contact
  • Footer reorganised around product, method, resources and ecosystem

Twelve pillars and real data

  • The canonical 2.3.1 twelve pillars are shown directly on the homepage with their business question
  • Statistics and latest observations remain stockage interne-backed and no demonstration number is fabricated
  • No global security, trust, sovereignty or compliance score is added

Responsive and accessibility

  • Mobile-first layout with progressive pillar grid and observation table transformed into cards on small screens
  • Burger menu, keyboard focus, light/dark/system themes and progressive disclosure remain available
Version2.3.1
Stable

Twelve pillars to explain the evidence

2.3.1 keeps full technical depth in stockage interne and turns the public report into twelve fixed pillars that are readable and comparable over time.

Public reading

  • Twelve fixed pillars separate public synthesis from technical collection modules
  • Each pillar provides a plain explanation, associated observations, and technical details on demand
  • Previous technical indicators remain available through progressive disclosure and no longer dominate the reading

stockage interne memory

  • Pillar definitions, mappings, snapshots, and evidence links are persisted additively
  • Every new scan produces exactly twelve snapshots, including unknown or untested states
  • Source evidence remains authoritative and lack of evidence never becomes a favorable result

administration and deployment

  • administration can inspect definitions, mappings, and snapshots and preview the projection without modifying evidence
  • The 2.3.0 to 2.3.1 migration is additive and can be imported with phpMyAdmin on Infomaniak shared hosting
Version2.3.0
Stable

Foundations for Continuous Evidence

2.3 turns each measurement into usable timestamped history: immutable scans, explicit watchlist, administration automations, real stockage interne diagnostics, baselines, and encrypted private rulepacks.

Memory and automation

  • Each scan keeps its timestamp, target, trigger, engine and rule versions, coverage, and relationship to the previous measurement
  • The administration watchlist is the only source of automatic rescans and the scheduler uses idempotent leased jobs
  • Shared-hosting WebCron calls only an authenticated automation endpoint

Private engine and evidence

  • Declarative rulepacks can be encrypted in stockage interne with the key kept outside the database and public release
  • No PHP, SQL, eval, or arbitrary network call can be supplied by a rulepack
  • Public signals expose the conclusion and useful evidence without distributing private conditions

administration and UX

  • administration shows the real stockage interne version, detected schema, critical tables and indexes, and a rollback transaction probe
  • Public headings use natural line wrapping instead of forced one or two word fragments
  • Statistics and history use 2.3 scan_runs as the primary operational memory
Version2.2.0
Stable

Strategic Evidence Engine

2.2 turns Scanapse into a strategic knowledge engine: canonical targets, stockage interne memory, correlated signals, trajectory, versioned KM and a public observatory without a global score.

Engine and knowledge

  • Server-side URL normalization to a versioned canonical target
  • Measured and versioned scan phases
  • stockage interne becomes operational memory for targets, runs, changes, signals and knowledge
  • Deep Scan remains reserved for 2.5 at the latest and is not enabled implicitly
Version2.1.1
Stable

administration privacy, explanatory KM and stockage interne

2.1.1 adds the stockage interne operational core, privacy-by-design administration, local messages, coherent themes, and progressive knowledge-first reading.

Administration and knowledge

  • administration without raw IP, persistent User-Agent, or fingerprint
  • stockage interne 10.11 for metrics, messages, KM, and administration
  • System, light and dark themes plus progressive explanatory reporting
Version2.1.0
Stable

Evidence-first intelligent dashboard

2.1 refocuses Scanapse on evidence, changes, and dependencies without a global score.

Interface and method

  • Intelligent dashboard with essential and expert views
  • Evidence cards with method, source, reliability, and limitations
  • Explanatory standards and regulatory context without compliance verdicts
Version2.0.1
Stable

Host fix for the temporary deployment

The release explicitly allows scanapse.com and almouatin.com while continuing to reject every other production Host.

Security and deployment

  • Fixes the 421 Misdirected Request before local configuration is present
  • Allowlist limited to scanapse.com, www.scanapse.com, almouatin.com, and www.almouatin.com
  • The stockage interne schema and Evidence-first methodology remain at 2.0.0
Version2.0.0
Stable

Evidence-first, Knowledge Engine, and trust observatory

Scanapse now separates observations, evidence, claims, relations, signals, and knowledge coverage. Constellation becomes an observatory and previous scores remain only as V1 history.

Knowledge

  • Seven explicit epistemic states, including unknown, contradictory, and untested
  • Observed quality and knowledge coverage separated in the Trust Profile
  • No lack of evidence automatically produces a favorable result

Monitoring

  • Temporal comparison of observations with appeared, disappeared, modified, stable, or unresolved changes
  • Constellation refocused on coverage, signals, unknowns, visible providers, and changes

Database and security

  • Additive stockage interne 2.0.0 schema and backfill without fabricating V2 data
  • Production Host allowlist, explicit HSTS, and release guard against secrets
Version1.5.2
Stable

internal storage persistence, scan wall, and stabilised styles

Native PDO writes are fixed, signed reports can be synchronised to internal storage, the wall is deduplicated by domain, and feature styles are isolated.

Database

  • Unique SQL parameters compatible with native stockage interne prepared statements
  • Verified transactional writes for domains, reports, and dependencies
  • doctor, probe, and import-files commands to verify and synchronise the database

Interface

  • Return to the stable main stylesheet and isolation of telemetry, ranking, and module components
  • One public result per domain, with the latest scan and total measurement count
Version1.5.0
Stable

Public telemetry, three-band rankings, and module catalogue

The homepage now exposes engine metrics, a readable three-column ranking, and the latest scan ledger. The Modules page documents all twelve analysers, while rules 2026.08.2 reduce further false positives.

Homepage and rankings

  • Engine telemetry with indexed domains, archived scans, recent activity, best score, coverage, and visible dependencies
  • Public ranking with three configurable bands: 90 to 100, 50 to 89, and 0 to 49
  • Latest scan ledger with score, coverage, dependencies, change, and date
  • Counters use stockage interne when available and keep signed file storage as fallback

Module catalogue

  • New detailed page for all twelve modules, their signals, outputs, and affected indices
  • Presentation of the collection, qualification, correlation, and reporting pipeline
  • Security boundaries, network budget, and extension contract documented

Engine accuracy

  • Public detection rule version: 2026.08.2
  • Resources quoted in code samples or JavaScript strings no longer become fake dependencies
  • Third-party WordPress, Drupal, and Joomla paths no longer suffice to attribute the technology to the scanned domain
  • An isolated quoted challenge marker no longer suffices to classify a page as an active protection
  • Conservative validation and normalisation of Set-Cookie lines

Validation

  • Expanded regression tests for rankings, telemetry, modules, and false positives
  • Typography convention automatically checked with the standard hyphen
Version1.4.1
Stable

internal storage stabilisation and scan continuity

The internal storage connection is fixed, diagnostics are explicit, and an optional database outage no longer blocks creation of the signed file report.

stockage interne fixes

  • Separated SQL session statements to avoid a PDO connection syntax error
  • Explicit schema version check before any read or write
  • Safe diagnostic codes for missing driver, host, authentication, rights, schema, and timeout issues
  • New php bin/database.php doctor command without credential disclosure

Service continuity

  • Signed file mode remains operational when stockage interne is expected but unavailable
  • Blocking scans now requires the explicit block_on_failure option
  • Health output distinguishes connection, schema, degraded mode, and blocking

Security

  • No SQL secret is displayed by diagnostic commands or the health route
  • The database remains protected by prepared queries and a least-privilege application account
Version1.4.0
Stable

Public rankings, internal storage persistence, and revised detection rules

The homepage now exposes recent scans through three readable levels. Storage becomes hybrid, with optional internal storage and signed file reports retained. Detectors now prioritise structural evidence to reduce false positives.

Rankings

  • Always-visible homepage table with controlled signals, trust to consolidate, and insufficient visibility
  • Ranking based on Trust Index and coverage level, with history and change
  • /classement and /ranking aliases to the Constellation page

Data

  • Versioned stockage interne schema for domains, reports, dependencies, and migrations
  • Hybrid file and stockage interne mode with automatic fallback when the optional database is unavailable
  • Command to import existing signed JSON reports into stockage interne
  • Optional manual domain band and public hiding without modifying the signed report

Accuracy

  • Public detection rule version: 2026.08.1
  • Technology detection based on resource paths, attributes, and runtime markers
  • Remote protection detection weighted by structural evidence
  • Sensitive cookie names recognised through complete tokens instead of generic fragments
  • Removed false Fastly attribution caused by a generic Varnish header

Security and validation

  • Prepared SQL parameters, schema constraints, validated prefix, least-privilege SQL account, and optional TLS
  • Required stockage interne mode writes to the database before publishing the file report, and public health output hides detailed SQL errors
  • Engine and rule version retained in every report and stockage interne row
  • Regression tests added for false positives, rankings, hybrid storage, and titles
  • Uniform typography convention using the standard hyphen throughout the project
Version1.3.0
Stable

Constellation, trajectories, and trust chain

Scanapse becomes a continuous observatory: latest reports, changes, and dominant dependencies are brought together without turning the index into an opaque ranking.

New

  • Constellation page with filters, SVG map, reading bands, and latest signals
  • Enriched domain history with Trust Index curve, deltas, and snapshots
  • Bilingual Changelog page powered by a structured source
  • Latest-report preview on the homepage

Engine

  • Two additional modules: third-party resource control and email trust
  • SRI, mixed content, form destinations, iframes, and new-tab link measurement
  • DNS reading extended to TLS-RPT, MTA-STS, and BIMI when email is advertised
  • Report schema 1.3 and rebalanced category calculation

Security and quality

  • The Constellation only publishes minimised summaries and never raw evidence
  • Configurable exclusion of domains from the public wall
  • Tests added for new modules, history, and public aggregation
Version1.2.2
Stable

Shared-hosting engine stabilisation

Full release rebuild, module isolation, and report continuity on network failure.

Fixes

  • Removed the conflict between the module directory and the public /modules route
  • Secure cURL-to-socket transport fallback
  • DNS, TLS, and HTTP errors converted into partial or minimal coverage
Version1.1.0
Archived

Editorial redesign and removal of false anti-abuse rejections

Shorter headings, tighter visual hierarchy, and a scan form compatible with password managers.

Interface

  • Removed the hidden field that triggered anti-bot false positives
  • Reduced heading sizes and spacing on desktop and mobile
  • Coverage levels made explicit in every report
Version1.0.1
Archived

Portable deployment

Removed the hard-coded canonical domain and added automatic active-host adaptation.

Deployment

  • Canonical, sitemap, robots, and security.txt generated from the current domain
  • Domain-root or subdirectory compatibility
Version1.0.0
Archived

Initial Trust and Dependency foundation

Flat PHP architecture, ten passive modules, signed reports, and black-or-white interface.

Foundations

  • index.php front controller with isolated pages
  • Strict CSP, SSRF validation, rate limiting, and HMAC storage
  • Provider mapping and five trust dimensions
VersionOrigine
Archived

Scanapse project origin

11 December 2025 is the documented starting point of the project. The following months include several exploratory trials and directions; no intermediate version number is invented where the record does not establish one.

Experimental period

  • Early exploration around OSINT, local analysis, and source structuring
  • The detailed timeline only resumes with milestones documented by retained releases
Before publishing

How a release reaches production

Keeping Scanapse simple does not remove the need for discipline. A release must remain reproducible, reviewable, and compatible with the intended hosting environment.

01

Frame

Define the goal, what changes for the reader, and what must remain untouched.

02

Isolate

Limit the change so a local improvement does not silently become a regression elsewhere.

03

Verify

Check tests, syntax, routes, assets, translations, and important behaviours before delivery.

04

Deliver

Rebuild the packages, verify integrity, and keep the upgrade path understandable.

A useful change should remain explainable Scanapse keeps its history so readers can understand why a reading may differ between versions. An interface or rule change should never make older records impossible to understand.