Crate cratefield_module_waitlist 

cratefield-module-waitlist: per-product waitlist with confirm, position, referral codes and status (issue #11, architecture section 6).

use cratefield_module_waitlist::Waitlist;

let module = Waitlist::new()
    .products(["kontinuum", "undercover-rockstars"])
    .confirm_ttl_days(7)
    .referrals(true);

Positions are atomic. Confirmation reads the product’s position from a per-product counter on waitlist_position_lock that the lock-taking UPDATE increments in the same statement, and that UPDATE plus the flip and the referrer credit run in one cratefield_core::Database::batch_atomic — atomic on D1, a transaction on the sqlite and Postgres adapters — so concurrent confirms of one product serialize on every engine and a UNIQUE (product, position) index means a duplicate position cannot survive even if the allocation raced (issues #20, #173, #126). Positions are dense at assign time per product and never recomputed on delete.

No enumeration (section 11): POST /v1/waitlist answers the same 202 {"ok":true} bytes whatever the row state; an unknown ref code is silently ignored.

cratefield-module-waitlist

Per-product waitlist for a Cratefield venture: POST /v1/waitlist joins, a signed confirmation link assigns a dense per-product position, referral codes credit the referrer, and a status endpoint shows the entry’s place and share link.

use cratefield_module_waitlist::Waitlist;

let module = Waitlist::new()
    .products(["kontinuum", "undercover-rockstars"])
    .confirm_ttl_days(7)
    .referrals(true);

Joins may carry a free-form answers JSON object: .answers_schema(|answers| ..) validates it whenever answers are present, .require_answers(true) rejects joins without them, and the admin export carries the stored answers as a quoted CSV column.

Position semantics: positions are per product, assigned densely at confirm time from a per-product counter on waitlist_position_lock that the lock-taking UPDATE increments, inside one all-or-nothing Database::batch_atomic, so concurrent confirms of the same product serialize on every engine (D1, SQLite, Postgres) and never share a position; a UNIQUE(product, position) index backstops the allocation. Positions are never recomputed when rows are deleted.

Register the default mail templates in the venture’s src/lib.rs:

use cratefield_core::Harness;
use cratefield_module_waitlist::default_templates;

let builder = Harness::builder().templates(default_templates());

Emits waitlist.joined and waitlist.confirmed; pair with cratefield-module-email-signup’s .subscribe_on_waitlist_confirm(true) to mirror confirmed addresses into the signup list — no crate dependency between the modules.

See docs/ARCHITECTURE.md section 6 (Waitlist) and section 11.

---

MIT. Built in the open for Cratefield, a Factory Zero venture.

Structs

ConfirmMailData

Typed data for waitlist/confirm.

ConfirmedMailData

Typed data for waitlist/confirmed (the “you’re in” mail).

Waitlist

A per-product waitlist.

Functions

default_templates

The module’s default askama templates, for Harness::builder().templates(..).

Type Aliases

AnswersSchema

A venture’s validation for the free-form answers field of a join. Err(detail) becomes a 400 validation-failed problem.