Documented origin of Scanapse
Scanapse has a documented starting point on 11 December 2025. This date concerns the project, not the domain registration.
HISTOIRE / Product history
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.
This timeline documents the public use of the scanapse.com name in the product. It is not a WHOIS, ownership, or registrant history.
Scanapse has a documented starting point on 11 December 2025. This date concerns the project, not the domain registration.
Release 2.0.1 places scanapse.com and www.scanapse.com in production scope while almouatin.com remains temporarily in use.
Production configuration, technical contacts and canonical URLs converge on scanapse.com while preserving the temporary deployment trace.
The public Canary adds dated cryptographic proof to scanapse.com, with verifiable history and continuity.
Changes are preserved with their context: reading experience, methodology, security, storage, presentation, and fixes. Technical detail remains when it helps explain a decision.
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.
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.
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.
2.9.4 resumes an interrupted run from durable checkpoints without recollecting already accepted phases.
2.9.3 adds bounded recovery for interrupted jobs without replaying a reading when durable evidence makes replay ambiguous.
2.9.2.1 fixes the technical completion step that could leave a finished reading displayed as still running.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
2.7.3 aligns the public Canary page and administration cockpit with the Scanapse design system without changing the P1.8 cryptographic protocol.
P1.8 introduces delegated Ed25519 Canary signing, administration/WebCron automation, and completes verifiable professional exports.
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.
2.6.2 removes release versions from local configuration and rebuilds administration with left navigation, clearer service states and a denser cockpit.
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.
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.
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.
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.
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.
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.
2.5.3 makes stockage interne the permanent memory for successful readings, turns history into an explanatory timeline and adds accountless visibility control.
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.
2.5.1 corrects visual-direction regressions introduced by Core Domain Folder 2.5.0 without changing the engine, data or product positioning.
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.
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.
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.
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.
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.
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.
2.4.3 tightens the report, harmonises public pages, simplifies headings and restores product history in the footer without removing any route.
2.4.2 simplifies public wording, tightens headings and spacing, filters the public trajectory to useful changes and focuses exports on evidence.
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.
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.
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.
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.
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.
2.3 turns each measurement into usable timestamped history: immutable scans, explicit watchlist, administration automations, real stockage interne diagnostics, baselines, and encrypted private rulepacks.
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.
2.1.1 adds the stockage interne operational core, privacy-by-design administration, local messages, coherent themes, and progressive knowledge-first reading.
2.1 refocuses Scanapse on evidence, changes, and dependencies without a global score.
The release explicitly allows scanapse.com and almouatin.com while continuing to reject every other production Host.
Scanapse now separates observations, evidence, claims, relations, signals, and knowledge coverage. Constellation becomes an observatory and previous scores remain only as V1 history.
Native PDO writes are fixed, signed reports can be synchronised to internal storage, the wall is deduplicated by domain, and feature styles are isolated.
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.
The internal storage connection is fixed, diagnostics are explicit, and an optional database outage no longer blocks creation of the signed file report.
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.
Scanapse becomes a continuous observatory: latest reports, changes, and dominant dependencies are brought together without turning the index into an opaque ranking.
Full release rebuild, module isolation, and report continuity on network failure.
Shorter headings, tighter visual hierarchy, and a scan form compatible with password managers.
Removed the hard-coded canonical domain and added automatic active-host adaptation.
Flat PHP architecture, ten passive modules, signed reports, and black-or-white interface.
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.
Keeping Scanapse simple does not remove the need for discipline. A release must remain reproducible, reviewable, and compatible with the intended hosting environment.
Define the goal, what changes for the reader, and what must remain untouched.
Limit the change so a local improvement does not silently become a regression elsewhere.
Check tests, syntax, routes, assets, translations, and important behaviours before delivery.
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.