Platform Updates

Repositories: Rego and Partners.

What changed: Activity forms no longer repeat the generic activity heading and field-checking explanation above their questions. The activity title remains in the form header. EMS previews use the same simplified component.

Validation: The existing application browser fixture passed against the actual form and produced an updated screenshot. Rego and Partners type checks and production builds passed, alongside all 84 shared-preview source checks. Documentation checks also passed. Both source releases were pushed for Git-linked deployment.

Repositories: Partners and Rego.

What changed: The former Merchandise requirement field is now Dealers Den landing page body. Its saved content is retained and displayed as the full formatted introduction on both dealer application and registration landing pages. Approved applicants review the introduction before selecting Start registration to choose their package. The application form no longer repeats the body as plain text.

Who may notice: Partners updating dealer instructions and applicants completing their table registration. Both pages support the same safe Markdown extensions as event descriptions. Existing approval checks and required registration package selection remain in place.

Validation: Application Markdown and settings browser fixtures passed; the field retains its existing saved data key. Type checks, production builds and all 84 shared-preview module checks passed. Desktop/mobile registration fixtures use the actual route, session gate, API clients and shared components, with mocked transport. They checked full Markdown extensions, sanitization, no early capacity reservations, fresh package selection, empty-body guidance and anonymous, denied and unapproved access. No production applications were submitted. Git-linked Partners and Rego deployments completed successfully. Their live module files contain the renamed field and shared application and registration body controls.

Repositories: Partners, Rego and Partners API.

What changed: Dealers Den Config has a Require package selection on application switch, off by default. With it off, new and revised applications omit package selection; the package is chosen during dealer registration. When enabled, applications require an available, eligible package. Dealer registration always asks for its own package choice. View package on the event page now opens the same details modal used for inclusions.

Who may notice: Dealer applicants and event teams. Existing events start with the switch off. Submitted or paid dealer registrations retain their revision protection. Partners previews use the same application code and setting as Rego.

Validation: Type checks, production builds and the 84-module shared-preview parity check passed. Desktop/mobile browser fixtures checked switch saves, application on/off and revision behavior, missing packages and package details modals. API fixtures checked package requirements and ignored preferences while off. The migration was installed; hosted database rollback tests passed for both policies and committed-registration protection without retaining test applications. Git-linked API, Partners and Rego deployments completed successfully. Live module files contain the switch and modal controls, and the public test event returns the switch as off. Browser application journeys use fixtures rather than retained attendee applications.

Repositories: Partners, Rego and Partners API.

What changed: Activity applications open with an introduction showing their full formatted description. Dealers can review table packages and select a preferred package before answering application questions. Dealer packages also appear after rego tiers on the event page. Account owners can revise submissions and change dealer package preferences; a revision returns the application to review.

Who may notice: Attendees applying for activities or dealer tables, and event teams reviewing applications. Submitted or paid dealer registrations protect their existing pricing and cannot be changed through an application revision. Event teams can enable multiple dealer applications per account and multiple submissions for each activity. Both switches start off; existing submissions remain available to edit.

Validation: Type checks and production builds passed. Desktop and mobile browser fixtures exercised introductions, full Markdown extensions and sanitization, package preferences, saved switch values and hidden prices. All 84 canonical Rego presentation modules passed the EMS source-parity check. API fixtures checked owner access, stale revisions and closed activities. Hosted database rollback tests checked duplicate limits, review resets, revision history, package eligibility and paid-registration protection. The migration was installed and those tests passed again without retaining test applications. Git-linked API, Rego and Partners deployments completed. Live route files contain the new controls and introductions, public endpoints return the controls, and the owned revision endpoint requires sign-in. Browser journeys were fixture-based; no real attendee applications were submitted during verification.

Repositories: Partners, Rego and Partners API.

What changed: Rego Config now offers optional prefill rewards: a fixed peso or percentage discount on the registration tier, a personal single-use event shop coupon, or both. Prefill registration discounts also have an optional event-wide redemption limit; a blank limit means unlimited, with one use per attendee. Attendees see their earned rewards on the event page and at checkout. Coupons have an Allow with prefill rewards switch. New coupons start with this off; existing coupons retain their eligibility.

Who may notice: Event teams can configure rewards and review coupon compatibility before enabling them. Rewards belong to one account and event. Issued shop coupons remain available after prefill becomes registration; cancelling or revoking the prefill cancels unused rewards. Disabling new reward issuance retains already-earned benefits. The API checks ownership, coupon compatibility and final prices.

Validation: Settings, required amounts, saved coupon eligibility, mobile layouts and signed-in reward visibility were checked using local browser fixtures. Registration and prefill previews retain their canonical Rego source checks. Hosted database rollback tests verified ownership, tier-only amounts, repeat-use rejection, cancellation, retention after conversion, redemption exhaustion and stale-quote rejection. A concurrent probe confirmed the event redemption lock excludes another checkout. Type checks and production builds passed. The Git-linked API and web deployments completed, and the refreshed live reward and registration scripts were verified. No test registrations or orders were retained.

Repositories: Partners and Rego.

What changed: Registration and prefill previews now run the actual Rego wizard. Dealer applications and registration, activity submissions, volunteer applications and feedback share the views used by the public site, including question controls, document readers, item details, payment presentation and review. Desktop and mobile previews use their own viewport. Unsaved registration and group settings are applied over the event snapshot.

Who may notice: Event teams reviewing forms before publishing. Open the relevant form preview and test its required answers, conditions and steps. Preview completion and uploads stay local; no real registration, capacity reservation, payment or account report is submitted.

Validation: Complete source equivalence is checked for 81 canonical modules during the Partners build. Both applications passed type checks and production builds. Focused validation tests and browser journeys covered required fields, legal readers, mobile layouts, embedded payment dialogs and local completion. This validates the preview implementation, not a real payment or provider transaction.

Repositories: Partners, partners-api and Rego.

What changed: A package requiring an existing event registration may include zero new attendee slots, or retain any valid positive slot count. Zero-slot checkout verifies the representative’s current event registration, charges the table package and creates no duplicate attendee registrations, tier charges or attendee inclusion allocations. Package bot entitlements still apply to the representative.

Who may notice: Partners offering tables to attendees who already registered for the event.

Next steps: Enable the existing registration requirement before setting included attendee slots to zero. Positive counts remain supported and are not automatically changed.

Validation: Configuration, eligibility, pricing and database checkout checks verify both table-only and positive-slot packages. Type checking and production build checks cover the affected applications. The conditional database constraint and checkout guard are deployed separately from the linked application release.

Repository: Partners.

What changed: New dealer packages begin with no selected type. Pricing, attendee choices and entitlements appear only after choosing a tier-based or standalone package. Save remains disabled until a type is selected. Existing package edits retain their saved configuration.

Who may notice: Partners creating Dealers Den packages.

Validation: Type checking and production build pass. Browser checks verify the initial hidden fields and disabled Save, followed by the correct fields after choosing each package type.

Repositories: Partners, partners-api and Rego.

What changed: Dealer packages now use the same Discord and Telegram entitlement editor as registration tiers and add-ons. Discord role failures stay inside the role picker; partners can retry bot assignments without losing their package draft. Each package can require every dealer and assistant to already hold a confirmed or onsite registration for that event. Rego checks current eligibility and checkout enforces it again inside the database transaction.

Who may notice: Partners configuring dealer packages and registrants choosing a package with this requirement enabled.

Next steps: Refresh after deployment. Enable the requirement only for packages that need it. Install the Discord bot in the assigned server before assigning roles if the picker reports that it is missing.

Validation: Partners and Rego type checking and production builds pass; Worker bundle checking passes. Focused assignment, authorization and eligibility tests pass, including actual database checkout fixtures for both package modes, rejected unpaid/transferred/wrong-event registrations and rollback. The targeted production migration is installed with service-only execution; local UI screenshots verify the shared editor and requirement switch. Linked production builds completed for Partners, Rego and partners-api. Hosted component previews show the shared editor and disabled ineligible package choice; live eligibility requests return 401 without authentication and 403 for unrelated attendees. The assigned Discord server reports that the bot is not installed, so role assignment still needs that setup step.

Repository: Partners.

What changed: Removed corrupted punctuation from the event-settings and dealer-package loading messages and from package summary separators.

Who may notice: Partners opening Dealers Den configuration.

Next steps: Refresh after the linked deployment completes.

Validation: Partners type checking and production build pass. The actual component’s initial loading state renders both messages correctly in a local screenshot.