Module use_cases 

The application layer: one module per phase, and account_linking for the linking mail resend, each reading its rows, asking the study registry through its port, deciding, and writing the decision back.

Use cases call the models crate directly and reach the study registry only through crate::registry::StudyRegistry or crate::registry::InteractiveStudyRegistry: Suotar’s client, wire types, request ids, limiter and breakers are runtime::suotar’s.

Modules

account_linking 🔒

The account-linking action an admin or a teacher sets off by hand: re-running the linking mail send path for one person on one course. Not a phase: no schedule and no allowance, and no breaker learns from its calls, so one click cannot trip the workers’.

batch_flow 🔒

The loop every “claim rows, send one batch, write one answer per row” flow shares: the claim’s transaction, splitting a batch the study registry refused as malformed, the halves held back and released when a shutdown or an error stops the split, the refusals, one row’s failed write not costing the rest theirs, the moved-on rows and the batch summary. What goes on the wire, request ids, the limiter and the breakers are the registry adapter’s.

config_validation 🔒

The config-validation phase: the daily pass over every Suotar-enabled module’s configuration.

enrolment_discovery 🔒

The enrolment-discovery phase: who the study registry says is on the course.

import 🔒

The import phase: the one call that creates something in the study registry.

ledger_snapshot 🔒

The ledger-snapshot phase: the day’s queue depth for every ledger state.

legacy_mirror 🔒

The legacy-mirror phase: copying successful registrations to the legacy ledger.

link_emails 🔒

The link-emails phase: turning a claimed mail slot into a queued message.

mail_queue 🔒

What the two mail phases share: the template lookup, and the accounting of what one iteration queued and skipped.

materialize 🔒

The materialize phase: the ledger rows for completions that became eligible, and for grades that improved on a registered one.

preconditions 🔒

The preconditions phase: moving rows along, or out of, the chain of things that must be true before we submit.

resolve_enrolments 🔒

The resolve-enrolments phase: which enrolment the attainment belongs to, and what we will send.

retention_sweep 🔒

The retention-sweep phase: clearing out records past their retention window.

student_notifications 🔒

The student-notifications phase: the only thing that queues a student mail about a credit registration.

verify 🔒

The verify phase: asking the study registry what became of a submission.