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 runs 1 + MAX(position) for the product inside the position UPDATE, and that UPDATE plus the referrer credit run in one cratefield_core::Database::batch — atomic on D1, a transaction on the sqlite adapter — so concurrent confirmations never share a position. 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 Factory Zero 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);

Position semantics: positions are per product, assigned densely at confirm time as 1 + max(position) inside one atomic Database::batch that opens with a per-product lock statement (UPDATE … SET referrals = referrals WHERE product = ? — value-neutral), so concurrent confirms of the same product serialize on every engine (D1, SQLite, Postgres) and never share a position. Positions are never recomputed when rows are deleted.

Register the default mail templates in harness.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.

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.