Module trace_ingest 

Mouse-trace ingest server — receive traces from a consenting- human harvester (Chrome extension or instrumented page) and append them to a crate::training_corpus::TrainingCorpus- style on-disk store.

Operators run an instance of [TraceIngestServer] inside their Santh / wafrift / SaaS deployment; consenting users install the captchaforge-trace-recorder browser extension (a separate deliverable in roadmap B1.5) and POST their recorded traces here. The server appends each trace to a per-day JSONL file.

The data feeds crate::mouse_sampler expansions: as the corpus grows, operators bake the new traces into the bundled sampler’s with_extra_traces() list, raising the sampler’s diversity floor.

What this module ships

• [TraceIngestServer] — Tokio-based HTTP server with one endpoint: POST /v1/traces accepting a JSON-encoded TracePayload. Returns 201 Created on success.
• On-disk persistence to <root>/<vendor>-<YYYY-MM-DD>.jsonl.
• Schema validation: rejects payloads whose step count is out of the realistic envelope (≥3 steps, ≤500 steps), whose inter-step delays are sub-millisecond (suggests synthetic), or whose total duration exceeds 60 seconds (suggests AFK).
• Privacy: server logs sample count + bytes only, never URL or anonymisation tokens. Caller is responsible for client-side anonymisation BEFORE POSTing.

What this module does NOT ship

• The Chrome extension (separate deliverable; non-Rust).
• Authentication (operators wrap with their existing reverse proxy + auth middleware; this server is internal-network).
• Rate-limiting (same — proxy responsibility).
• HTTPS (proxy / sidecar concern).

Structs

TracePayload

One trace payload as received from a recording client.

TraceStep

One step in a recorded trace.

TraceStore

On-disk trace store.

Enums

ValidationError

Why a TracePayload was rejected. Each variant carries a short reason string for the response body.

Functions

validate

Validate a payload against the realistic-trace envelope.