Coupon journeys

The Store's side of a QR coupon journey (MeshWeaver.Plugins#2063). Design of record: QR Coupon Journeys. The link itself is an Essentials action link (MeshWeaver.Plugins#2060); this page is what a coupon link's Continue opens.

Launch terms (decided)

The owner decided the launch terms of the first campaign on MeshWeaver.Plugins#2066 (the proposal and the decision record are comments there). The launch is a free claim only: no payment method, no renewal.

Launch: what is left (phase 1)

Every line of phase-1 code is on main: the journey, the claim, the bounded plan, the course install through the plan, the retention sweep, the publisher scope and both acceptance suites (above and below). What remains is the owner's, in this order. Each step names the record that proves it done, so the state can be read rather than remembered.

🚨 Why the enable comes before the run. A disabled rule refuses Publish and stops the review page (acceptance scenario 7), so no journey can exist on the destination before the enable, and the run has to happen with the rule enabled. What the publish scope isolates is the PUBLISHER: only holders of Update on CouponJourney/Publishers can publish — the step-3 group's members and the administrators of the CouponJourney space (step 2's creator and the step-3 signer), who hold Update there by their role. While the group holds only the tester, nobody outside those can publish a journey. It does NOT hide the tester's journey: D12 is a listing grant (Public → Viewer on a), so after step 4 any signed-in user can list the links under a and follow the test link without being handed it, and claim the coupon within its cap and window. Steps 4 to 6 therefore expose the test coupon to every signed-in user. The owner accepted that exposure for the run (decision recorded on #2066) and bounds it on the coupon instead: the test coupon carries a redemption cap of 1 or 2 and a validity window of a day or less, so at most that many people can claim it, and only while it runs. This page claims no isolation beyond the publisher's and that bound. The real publishers are added (step 8) only after the run and the device checks passed.

Publishing is a form: Publish invitation. CouponJourney/Publishers (node type Essentials/CouponJourneyPublishers) shows a framework Edit form over CouponInvitationInput — the coupon code (D3), the course the recipient lands on (D2, AgenticEngineering by default; empty for none), the card's title and text, and the last day the link serves (D4: the coupon's own end; the link stops at the end of that day, UTC) — and a Publish button. The button runs CouponInvitation.Publish, which declares exactly the journey of the launch terms (Actions.Link(…).Do(Coupons.Journey(code).Benefit(b => b.UseCouponTierAndExactExpiry()).OpenCourse(course).AfterClaim(a => a.OpenSelectedCourse()).BuildAction()).ForSite(ActionLinkPublisher.ServingSite(hub)).WithCard(…).ValidUntil(…))) and publishes it through the one publish path, Publish(hub) (see Action links), as the signed-in person who clicked — captured at the click and re-established for the publish. Nothing in the form authorizes: the publish path checks the rule's Update on CouponJourney/Publishers (the group's Editor), writes the link as the platform, and refuses everyone else by name, and the form shows that refusal. On success it shows the link and its 📱 phone card (the QR code). The request id is derived from the inputs, so publishing the same invitation twice returns the first link, and changing any value publishes a new one. The suite case ThePublishInvitationForm_PublishesForAGroupMember_AndRefusesANonMember pins both answers.

The form keeps what the publisher typed: the input model is seeded once, only when absent, and the editor binds to it by type, while the click's progress and outcome render in their own view — so a "Publishing…" or a refusal never puts a blank model over the fields, and the click reads the input before it writes any status. A course the journey rules refuse (a pasted web address) is the form's refusal naming it, never a fault. A fault after the click says the publication could not be confirmed, not that nothing was published — the definition may already exist — and asks to publish the same invitation again unchanged, which returns the existing link (same request id) or publishes it. The node type's Tests area runs the drafting cases and two live cases against the rendered page (an outcome redraw keeps the typed input; the real Publish click submits it), and CouponInvitationFormLiveTest runs the same live cases on a disposable mesh.

Phase 2 (the renewal, the deferred subscription, the required payment setup and the wallet payments) continues in MeshWeaver.Plugins#4844, which carries the terms still undecided. #2063 and #2064 closed as phase 1 delivered; #2065 and #2066 closed with the steps above recorded, and reopen if the launch reveals a defect.

Acceptance suite (phase 1)

The free claim, sender → recipient, is pinned end to end by CouponJourneyPhaseOneAcceptanceTest (src/Memex.Portal.Gui.Test, MeshWeaver.Plugins#2065) on a DISPOSABLE mesh — the only kind on which the publisher group may be granted and this rule enabled. It compiles the Essentials action-link sources and the Store sources of Store/CouponClaim unchanged, writes the SHIPPED ReviewRule file through the mesh, builds the publisher group in the exact shape group.scoped-create writes, grants D12 on a, and runs the portal's own retention sweep. Every refusal has a negative control.

The course a journey lands on carries the access model Store/Plugin declares: the fixture registers the real AddPluginGating hook on the plugin type (the Store/Publishing sources are already compiled into the suite, so this pulls nothing new in), and settles the gating with the explicit PluginGate.SeedGating pass before anything reads through it — the same idempotent reconcile the hook's watcher runs, never a race with that watcher's delayed start (the pattern of Store/Licensing/Test/EntitlementPrivacyTests). Course access is then asserted AS THE CLAIMANT, by a direct read of the course's own Exercises through the exact-node stream: denied before the claim, readable after it; a signed-in recipient who never claimed stays denied, while the cover stays readable to both (the positive control that the gating ran). MeshWeaver.Plugins#4521.

What the suite found when it was written (each case asserts the intended behaviour, so it stays red until the defect is fixed):

• Fixed: the review could not read a published link. CouponClaimStore read the link's page and definition with ContentAs<CouponJourneyLinkPage> / ContentAs<CouponJourneyLinkFacts>, a field-name contract with Essentials' records. The owner's node stream hands that content over TYPED as ActionLinkPresentation / ActionLinkDefinition, and ContentAs returns null for a differently named type by design, so every journey reviewed as Unavailable. Save and the claim control plane's re-check go through the same decision, so they refused as well (scenarios 2–5 and 8). Store cannot read with Essentials' own types: Essentials requires Store, so compiling its records into a Store type would make the two packages a cycle. The reader (CouponClaimStore.LinkRecord) therefore takes the content as JSON first (NodeElement.Of, which round-trips a typed record without adopting its type into the reader's registry). It then reads that JSON with the canonical As<T> accessor. See "The link facts it reads" below.
• enabled: false reads back as true (scenario 7): core's ActionHandlerRule.Enabled defaults to true and is not marked JsonIgnoreCondition.Never, so the hub's WhenWritingDefault drops the explicit false on a typed write and the reader re-applies the initializer. Measured on the disposable mesh (the shipped file deserialized with the mesh's options and created); whether a portal's package import stores the rule through the same typed write was not established there.

D15's "one isolated end-to-end run on the destination" is still owed: this suite is the disposable-mesh half.

Acceptance suite (payment setup, Stripe test mode)

Phase 2 turns on .RequirePaymentSetup(…). CouponJourneyPaymentSetupAcceptanceTest (src/Memex.Portal.Gui.Test, MeshWeaver.Plugins#2065 and #2064) pins that journey end to end on a disposable mesh, with Stripe faked at the HTTP boundary and nothing else. The real Stripe provider is mounted through the module's own registration (AddStripePaymentServices). Only its named HttpClient (store-stripe) reaches a fake that answers in Stripe's wire shapes, and every key is a test-mode placeholder. The webhook goes through the portal's own inbox (WebhookInbox.Deliver, which is what POST /api/hooks/Store/Payments runs) and the Store's PaymentInboxWatcher. The provider verifies the Stripe-Signature against the arrival instant (#3544).

Turning phase 2 on therefore needs, besides the owner's Stripe acts on MeshWeaver.Plugins#2064 (the test-mode keys and webhook secret through the write-only secrets screen, the publishable key, wallet domain registration, and Apple Pay and Google Pay enabled on the account), one edit to the rule: capabilities: ["PaymentMethodSetup"] on Store/CouponJourney/ReviewRule. That edit is the site's declaration that it can save a method (policy declared-not-derived).

What the review page does

It trusts nothing it was handed. As the viewer it checks that a person is signed in and may read the link's page a/{linkId}. As the platform it reads the link's presentation and private definition, the coupon, and any claim the viewer already holds, and decides (CouponClaimRules.Decide), in this order: signed in; the link serves (revoked, expired, unknown and unreadable all render the same line); the link is bound to this site; the journey reads; the coupon can still be claimed (window, plan tier, bounded term, budget); an existing claim.

It shows the exact quote — the plan tier, the real benefit start and end dates (and that the term is reduced when the coupon's validity cuts it short), Due today: 0 — the method-storage consent when the journey requires a payment setup, and an optional renewal as not available on this site yet. Visiting, refreshing or previewing it writes nothing.

Save my claim re-decides everything as the platform, then reserves a redemption slot and creates the claim. The save itself grants no plan, installs no course, saves no payment method and charges nothing. After the save, the claim's own control plane activates the bounded plan (see Activating the plan below) when the journey needs no payment setup. When the page is opened again, it says where the claim stands: being activated, active until the accepted end, already covered by the recipient's plan, needing the site's attention, or ended. Every line says nothing was charged.

The page follows the viewer's own claim through the claim's node stream (CouponClaimStore.FollowClaim, read as the platform, which owns the claims partition, at the one path derived from the viewer and the offer). Existence is observed live through the query transport, so a first visit that saves its claim sees the new claim at once. The claim's node stream is opened only once it exists, so an absent path is never point-read. "No claim" is read only from the existence query's own ANSWER (MeshQueries.ObserveNodeAnswered), never from a seed placed before it: "no claim" is what offers the consent and Confirm, so until the query answers the page stays Loading. A returning claimant therefore never sees the decision to claim an offer they already hold, or a refusal of it, while the query is slow. The page therefore moves to the claim's next state as its control plane advances it, without a reload. While the claim waits for its payment method (SetupPending, with an open client-rendered setup and no verified method), the page shows the embedded payment-method form (PaymentFormOf → core PaymentSetupFormControl), and only for the claim's own buyer. The control names only the setup. The form's view obtains the one-time secret in the buyer's own session (MeshWeaver.Plugins PaymentSetupFormView), and the provider answers only that buyer. Once the method is verified the form is gone, because the claim has moved on. A claim waiting on a hosted setup gets a link to the provider's own https page instead (HostedSetupLinkOf, opens in a new tab), under the same conditions.

The claim and its consents

CouponClaims/{claimKey} (node type Store/CouponClaim), a platform-owned partition nobody is granted anything on. The key is CouponJourneyRules.ClaimKey — site, recipient and coupon offer, never the link — and the create of the node is the atomic arbiter of one claim per site, person and offer: a second tab, a double click or a second QR link returns the claim the first one created.

The claim keeps the accepted quote and its hash, the phase (Prepared), the slot, and two separate consent records, each { kind, textHash, textVersion, acceptedAt, acceptedBy, quoteHash }:

• methodStorageConsent — present exactly when the journey requires a payment setup, over the journey's own consent text.
• recurringConsent — only for a selected renewal whose terms were quoted. This build quotes no renewal terms, so a selected renewal or a recurring consent is refused; the two are never merged into one record.

The redemption budget

There is no cluster-atomic counter (core: Expressing a Write → Status: a cross-hub fold can lose a count), so the budget is reserved by creating slot nodes: CouponClaims/Slots/{CODE}/{n} for n in 1…maxRedemptions. A listing of the existing slots only picks where to start (CouponClaimRules.ProbeOrder); the first successful create is the reservation; all taken is "no redemptions left". At most maxRedemptions slots can exist, and no two claims hold one. A coupon with no limit takes no slot.

Known limits, stated rather than hidden:

• A slot is taken before the claim is created. A run that loses the claim create gives its slot back; a process that dies between the two leaves a slot held by no claim. Both failures can only issue FEWER redemptions, never more.
• A stopped claim (expired, revoked or cancelled) gives its slot back (see below). A claim that became active used its unit, and that unit is never given back.

Activating the plan

CouponClaimControlPlane is a watcher on the claim node's own hub. It has the same shape as SubscriptionControlPlane. It re-reads the claim, takes one step, and moves the phase only along CouponClaimPhase.CanAdvance. Steps run one at a time, and nothing else writes a saved claim. A step runs on EVERY emission that finds the claim in its phase. So an operator's repair on a running hub is acted on straight away, and a queued emission of a phase the claim has since left does nothing. The save starts the claim's hub by reading the new claim once.

0. Prepared → SetupPending → SetupVerified, when the journey requires a payment setup (MeshWeaver.Plugins#2064). Nothing is charged at any point of it.

   • Prepared: the recipient's authority and the coupon are checked again, exactly as in step 1 below, before anything is asked of a payment provider on the recipient's behalf. Then SetupPending.
   • SetupPending, nothing frozen yet: the attempt's request inputs are frozen on the claim before anything is created (setupIntendedUse, setupCurrency, setupReturnUrl, setupHandoff). Every creation retry and every verification composes the request from them alone (CouponClaimSetupRules.RequestOf), so a configuration or coupon change after the freeze never sends different parameters under the same idempotency key.
   • SetupPending, frozen, nothing opened: the recipient and the offer are re-checked again before each create, so a resumed or repaired claim whose invitation was revoked or whose coupon ended stops instead of creating a provider object. The site's IPaymentMethodSetupProvider is asked what it can save for the journey's use. The claim froze the use when it was saved (setupPurpose); individually-approved-purchases is customer-present only, and never authorizes an off-session charge. The setup opens on the handoff the provider offers for that use, preferring the site's embedded form, under the claim's own idempotency key (coupon-claim-setup/1, the claim key, setupAttempt). The claim records setupId, setupHandoff, setupHostedUrl and setupCustomerId, and never the client secret. A site with no provider, an unavailable one, or one that offers no handoff for the use needs attention. It never charges and never skips the setup.
   • SetupPending, opened: on every emission of the claim (an activation, a restart, a recycle, a repair), the setup is read back from the provider (RetrieveSetup). The verdict (CouponClaimSetupRules.Decide) is taken over that reading, matched to the claim's own recomposed request with the platform's Satisfies. A browser return is never the verdict. A method saved for this claim moves it to SetupVerified and records paymentMethodId. An unfinished setup waits. A failed, cancelled, expired or mismatched one needs attention: an off-session permission the claim never asked for, or another buyer, counts as a mismatch, never as a bonus. The setup is then forgotten and setupAttempt counted, so the repair opens a fresh setup. A claim that failed in its setup may still stop, because nothing was granted.
   • The step itself is CouponClaimSetupStep.Run, over the provider it is given; the suite executes it over a contract fake (create once, restart without a duplicate, repair with a fresh key, provider unavailable or failing, re-check before create), and pins the dispatch (StepOf).
   • SetupVerified continues exactly as Prepared without a setup does (step 1).

   What a site still needs before a recipient can complete the setup: the review page draws the embedded form (see What the review page does). The Stripe provider offers the embedded (client-rendered) handoff for a customer-present use only when the site's Stripe publishable key is set (Commerce:Stripe:PublishableKey). The wallet buttons also need every portal domain that shows them registered as a Stripe payment-method domain, with Apple Pay and Google Pay enabled on the account. Both are owner acts on MeshWeaver.Plugins#2064. Until the publishable key is set, a claim that needs a setup finds no handoff and needs attention; it is never charged and never skips the setup.

   • An unfinished setup is cancelled when it can no longer be used. This covers a claim that stops (expired, revoked, cancelled) before any method was verified, and a setup the claim abandoned (failed or mismatched; setupToCancel). In both cases the setup is cancelled at the provider through CancelSetup. That call reads first, writes only for a setup that can still stop, and returns an already-stopped one as it is. The claim then settles the debt (setupCancelled / a cleared setupToCancel, plus setupCancelOutcome). A settled cancellation is never sent again. A verified method is never cancelled, because the recipient consented to saving it. A site without a provider keeps the debt visible on the claim and does not drop it (CouponClaimSetupStep.Cancel).
   • An open setup is re-checked on every read, so an invitation revoked or a coupon ended while a setup is pending stops the claim, and the stop cancels the setup.
   • "A create was sent" is persisted before the create (setupCreateRequested). A create whose answer was lost (a lost response, or a restart before the setup was recorded) is therefore never forgotten. If the claim then stops, it re-sends the frozen request under the same idempotency key, which returns the setup that create made, and cancels it (OwesCreateReconcile).
   • A verified setup delivery wakes its claim (CouponClaimWake, shared by the payment inbox and the claim). The inbox writes requestedSetupCheckAt and requestedSetupCheckEvent onto the claim the delivery names, through the claim's own stream, as System. The write lowers to a merge patch of those two fields and goes to the claim's owning hub. That emission makes the claim's control plane read the setup back from the provider now, not on its next unrelated update. A wake never decides anything; the provider's reading does. Only an authentic delivery naming a claim directly under CouponClaims/ wakes, and only a claim whose setupId is the setup the delivery reports on, so a late delivery about an abandoned setup changes nothing.

1. Prepared, when the journey needs no payment setup, or SetupVerified. The control plane follows policy authorize-as-caller-execute-as-system:

   • The recipient's authority is checked again (CouponClaimStore.Recheck, the review page's own decision). The recipient must still be signed in and still allowed to read the invitation; the link must still serve on this site, through an enabled handler rule. If the link no longer serves, the claim is Revoked. If the check cannot be made, the step faults; that is never a verdict.
   • The coupon is checked again (CouponClaimGrantRules.OfferRefusal). If the coupon was withdrawn, is out of its window, no longer grants the accepted plan, or the accepted period is over, the claim is Expired, and the benefit is never granted.
   • The selected course is checked against the coupon (CouponClaimGrantRules.CourseRefusal). The coupon's package list must name it, and a declared scope must cover it. These are the restrictions the free redemption and a coupon's key enforce, so a journey never installs a course its coupon was not issued for. A course outside them needs attention before anything is granted.
   • Then the claim moves to GrantPending, with coupon-claim:{claimKey} as its request id.

2. GrantPending: the claim's ONE bounded plan is requested on the recipient's subscription record (CouponGrants.Request). The request writes only requestedCouponGrant: the tier, the EXACT accepted end, and the request id. The record's own control plane decides and applies it in ONE write, on the record's own turn (SubscriptionContent.SettleCouponGrant). So the plan it protects is the plan the record holds at that instant, never a reading that another writer has changed since. The decision (CouponGrants.Decide) protects what the recipient already holds:

   • It applies the offer when there is no live plan (none, lapsed or cancelled), a granted plan of the same rank that ends sooner, or a lower granted plan that ends no later than the offer. The record becomes Active on the offer's tier: manual cadence, not permanent, no processor subscription behind it, ending exactly at the accepted end. A cancelled plan's retained term is replaced by that end, never kept.
   • The offer is covered when there is a plan that is higher, sold (a billing cadence), permanent, or of the same rank and unbounded or reaching as far, or when this site's own plan covers it. The record does not change, and the claim goes to Active with grant: Covered.
   • It is refused when a lower plan is sold, permanent, unbounded, or reaches beyond the offer. The offer would re-tier, cut short or extend that plan, so the claim needs attention.

   Pending requests and their settlements are kept by request id (requestedCouponGrants, couponGrantOutcomes). Two claims of one person therefore never overwrite each other. They are decided oldest first in the same write: the first may apply, and the second then finds the plan covering it. Each claim reads its own receipt. An applied grant is final for its claim only once the record has reconciled it, meaning it has revoked the unlocks the new tier no longer covers, as an activation does. That reconciliation is the record's own resumable step: a restart runs it again, and a sweep that fails is recorded on the receipt, so the claim needs attention. Its repair asks again, which clears the failure and retries the sweep. An ACTIVE permanent plan is never replaced, whatever date is left on it.

   A claim acts only on a receipt that is final AND whose id is no longer pending (CouponGrants.SettledReceipt), read off the record's own live stream. A repair that asks again therefore never reads the previous round's receipt as its answer. Receipts are trimmed as history only: one that still owes its reconciliation, or that failed and waits for repair, is always kept.

   The request id is applied at most once. A claim asking again (after a crash, a recycle or a repair) gets the settlement it already had, and a second claim for the same offer finds the plan covers it. This is never RedeemFree, and never an eternal entitlement.

3. A stopped claim with a slot gives the slot back, which returns the unit to the coupon's budget, but only while the slot is still this claim's. The slot is read first. A slot that is gone, or that names another claim or holder (it was given back before and taken again), is left alone. This claim's own slot is deleted with the version that read saw as a precondition, which the owning hub checks. The claim then records slotReleased. This is the coupon budget's one give-back (CouponBudget.Release, ownership by CouponBudget.Holds), the same one a lost save and a free redemption's ticket use; a journey slot reserved before slots recorded their holder is owned by its claim key alone.

4. Active → Installing → Complete: the course. The claim records the course the journey selected (course). The watcher reads the course's tier, then waits until a reading SHOWS the recipient's plan covering it. That is the same read Subscriptions.Unlock decides with, re-read because it trails the grant. A record that states it is permanent reads as live whatever date is left on it (Subscriptions.Parse). A read that fails reads as nothing, never as "no plan".

   • If this site's plan covers the course, the audience verdict (PlanAccess.Grants) must admit the recipient.
   • Otherwise the course is unlocked through the plan (Subscriptions.Unlock): an unlock record under the subscription plus the plan's own grant, and never an eternal entitlement marker, so the course goes when the plan lapses. An unlock that completes empty is a refusal, not a success.
   • Only then is the course installed (DependencyInstall.InstallAfterAcquisition), as System for the recipient, the same shape order fulfilment uses.
   • A course confirmed not covered is never unlocked: one with no tier, or one a live plan of a lower rank cannot reach. The claim completes, and its note says why.
   • An inconclusive reading, a refusal, or a failed install leaves the plan granted and the claim in NeedsAttention with failedIn: Installing. Its repair runs the install again.
   • A journey that selected no course completes straight away.

A first re-check that answers nothing never parks a claim silently. When the recipient-and-offer re-check completes without a verdict (for example, the handler resolution answered nothing), Prepared and SetupVerified record a named reason in place (undecided), with no phase change. The claim's next update (a wake, a recycle, a repair) therefore runs the step again. Writing the same reason again changes nothing, so an unchanged re-check never loops, and a step that decides clears the reason. Both steps share one rule: CouponClaimGrantRules.FirstRecheck for BeginSetup and CouponClaimGrantRules.FirstReview for Fulfil write the same NoVerdict transition, and the suite executes each one.

A step that faults moves the claim to NeedsAttention, with the phase it failed in (failedIn) and why (problem). The repair is an operator moving the claim back to failedIn, and the running hub runs the step again.

The link facts it reads

Store never compiles Essentials. The review page reads the link's presentation (linkId, definition) and private definition (linkId, site, invocation, validFrom, expiresAt, revokedAt, revision) as data (CouponJourneyLinkFacts) — a field-name contract with Essentials' ActionLinkDefinition, read tolerantly: a missing field reads as "does not serve".

Both records cross a package boundary. Essentials requires Store, so Store cannot compile them without a package cycle. They therefore reach a Store hub in whichever shape that hub resolved: stored JSON, or Essentials' typed record when the type is known there. ContentAs over the typed record is null by design. So the one reader, CouponClaimStore.LinkRecord, goes through NodeElement.Of and then As<T>, and the review, Save and the control plane's re-check all use it.

One budget

A coupon has ONE redemption budget, maxRedemptions, and both ways of redeeming it reserve from the same ledger: the free redemption (CouponRedemption.RedeemFree, the coupon field on a package page) and a coupon journey's claim. Two ledgers over one budget could each see a unit left and each take it, so there is one (Store/Coupon/Source/CouponBudget.cs).

Pinned by CouponClaimTests in the Store/CouponClaim Tests area (the pure capacity and ticket rules; a live race in which the free redemption's reservation and a journey claim's reservation are subscribed together for the last unit and exactly one wins; one person's concurrent submissions holding one unit) and by CouponBudgetEntrypointTests in the Store/Plugin Tests area, on a hub that does not register the slot type: RedeemFree and a free coupon order refused before any grant when a journey holds the last unit, and a successful RedeemFree writing redeemedBy and slottedBy together and leaving the other unit.

Retention

Claims, the slots they used and the links that led to them are removed once their period is over (the owner's decision D14 on MeshWeaver.Plugins#2066), and so are free redemptions (a later owner decision on the same issue). Before this, nothing removed them. The portal's JourneyRetentionSweeper (src/Memex.Portal.Gui/ActionLinks/JourneyRetention.cs) runs the clock on every replica: the first pass 15 minutes after start, then every ActionLinks:RetentionSweepMinutes (360 in the shipped appsettings.json; 0 turns it off).

🚨 One replica per pass. A pass sweeps only on the replica that takes the pass lease (Admin/RetentionLease/journey, node type RetentionLease). Taking it is a fold on that one node, decided by its owning hub. The lease is held for 90% of the interval and never less than an hour; the pass is cut at half the hold, so everything it issued has settled before the lease can lapse; and a finished pass releases the lease (only its own). So two sweeps never overlap.

🚨 Declared, never defaulted. A period that is missing from configuration, or out of range, keeps every record of that kind: nothing is removed on a value the code made up.

🚨 The budget stays whole. A claim whose plan became active USED one unit of the coupon's maxRedemptions, and its slot is what counts that unit. The slot is therefore never removed: on the slot's own hub its holder is emptied and its claimKey set to retired — it names nobody, keeps counting, and is never given back, adopted or released (no claim key matches it). Then the claim is removed. Removing the slot, even after moving its unit into the coupon's count, would let a reservation that had read the coupon BEFORE the count moved take the unit again.

🚨 A free redemption stays counted — on its own slot. The TICKET is the evidence of a free unit — only the free redemption mints one, and only for a person the ledger had not counted otherwise. The sweep moves NO count and frees NO slot number. For each ticket, ONE coupon write replaces every entry of the holder in redeemedBy and slottedBy with an anonymous entry retired:{slot}@{reservedAt} (one per ticket, naming nobody, never a person's id); redeemed is left as it is. So the distinct counted people, the counted people holding a slot and redeemed all read the same afterwards: the capacity and the redeemed >= maxRedemptions refusals are exactly what they were. Then, on each slot's own hub, every free-redemption slot of the holder is anonymized in place like a journey slot — holder emptied, claimKey set to retired — so it names nobody, keeps counting its unit, and is never given back, adopted or released. Then the ticket is removed (last, so a pass cut short resumes from it). A holder the ledger never counted (the free redemption tolerates a failed count write, because the slot preserves the budget) is named nowhere on the coupon, and their slot alone keeps the unit. A retry finds no holder named and writes nothing. Kept: a person the coupon counted WITHOUT a ticket (a paid checkout counts buyers the same way, or a redemption before the ledger), and the redemptions audit entries — nothing records whether an entry was free or paid.

Why in place, never deleted (Plugins#4398): a reservation computes its capacity from a coupon snapshot it read earlier and probes slot creates, where only an already-exists conflict stops a probe. Deleting a free-redemption slot after moving its unit into redeemed (the first version of this sweep) let a reservation that had read the coupon before that write take the deleted number again — one unit over maxRedemptions once an administrator extends validUntil. An anonymized slot keeps its number taken. Pinned by AReservationHoldingASnapshotFromBeforeTheSweepCannotTakeASweptSlot.

Kept, whatever the period:

• a claim that changed after it was selected: it is read again and re-decided, and deleted only at the version that re-read saw (a wake that stamps a newer event in between keeps it);
• everything, when the CouponClaims partition root is not the Space the platform created — and any claim, slot or ticket the platform did not create itself (its createdBy), so a record someone else wrote never drives a change to a coupon or a slot;
• a claim that is still in progress or needs an operator (only Active, Complete, Expired, Revoked and Cancelled are removed);
• a claim that still owes its payment provider a cleanup — the states the claim's control plane acts on: setupToCancel, a stopped claim's setupId with no verified method and not setupCancelled, or a stopped claim that sent a setup create (setupCreateRequested) whose answer it never recorded;
• a claim that stopped before its plan was active and has not given its slot back yet — its slot counts nothing, and its own control plane gives it back;
• a record written under a contract version this build does not read — for a link, the definition's OR its page's contractVersion;
• a record with a date the decision reads that is present but cannot be read (it might be the latest event), and a claim without a readable createdAt (it keys the slot's retirement).

The sweep reads every record BY PROPERTY NAME: a field-name contract with CouponClaim, CouponClaimSlot, CouponContent, ActionLinkDefinition and ActionLinkPresentation, which the portal never compiles. Renaming one of the fields it reads (phase, quote.benefitEndsAt, slot, slotReleased, claimKey, recipient, code, createdAt, the payment fields, redeemed, redeemedBy, slottedBy, redemptions[].viewer/at, holder, reservedAt, tier, tierDays, validUntil, grantsAll, scope, keyDays, linkId, expiresAt, revokedAt, definition, contractVersion) breaks it silently: it then keeps the record. Pinned by JourneyRetentionTest (src/Memex.Portal.Gui.Test).

Not covered yet. What a redemption granted OUTSIDE these records — the plan's subscription record, an eternal entitlement marker, an issued key — is not touched here. "The last transaction" of a claim that touched a payment is the last event the CLAIM records — payments recorded elsewhere (orders, subscriptions) are not read. No renewal exists at launch (D7), so no later charge can be missed today; the renewal must stamp its claim before phase 2 is enabled.