Updates
Platform Updates
Public-facing release notes for meaningful changes across Furries PH operational systems.
First created Last updated
Consolidated Partners branches and overview query optimization
Repositories: Partners and shared documentation.
Status: Committed branch histories reconciled; database migration source validated locally. Production database publication remains separate.
What’s Changed
Partners development branches now share the current main history. Previously released fixes retain the current React implementation; superseded donor work and the cancelled automatic inbox-opening proposal do not replace current behavior. Uncommitted development remains preserved for separate review.
A registration overview migration skips add-on usage queries for events without add-on purchase limits. Events with limits retain the existing response contract and private service-role access.
Impact
Maintainers can retire merged development worktrees without losing committed fixes. This consolidation does not change the shared WYSIWYG default, task-file safeguards or modal reporting behavior.
Upgrade Notes
The SQL fixture verifies unlimited, limited, zero-limit and foreign-event cases, event admission and denied public-role execution. Partners typecheck, shared textarea ownership, 103-module Rego parity and production build pass. These checks do not apply the migration to the production database or establish hosted query latency.
WYSIWYG editing across Partners
Repositories: Partners, canonical Rego form controls and shared documentation.
Status: Partners and Rego deployed through linked Git builds; hosted editor assets verified.
What’s Changed
Multiline prose opens directly in the existing WYSIWYG editor. Planning, incident reports and general dashboard fields share the same default; Write and sanitized Preview remain available. Partners application components now use one native textarea primitive, and the production build rejects new native-textarea bypasses.
Inputs whose destinations require exact literal text use the same primitive through an explicit plain-text variant. These include registration answers, username lists, profile biography normalization, provider messages, addresses, authenticator data and structured operational lists. This preserves their existing validation and delivery contracts.
Impact
Partner teams can see formatting while writing without selecting WYSIWYG on each form. Shared labels, native form values, reset and validation remain supported. Guardian instructions and brand guidance use sanitized Markdown in their read views.
Upgrade Notes
Reload Partners to receive the updated shared editor. Partners 16aca3a8 and Rego 881a7d86 both passed their Cloudflare production builds. Four current Partners assets and two Rego assets match the tested builds byte for byte.
Canonical Rego controls and their Partners previews pass 103-module source parity. Chromium, Firefox and WebKit each pass the shared default, form compatibility, exact literal-value and layout checks. Existing editor, planning creation/retention, consent and sanitizer checks pass, along with typechecks, production builds and the documentation build. These fixtures do not create production records or send provider messages; hosted assets and signed-in production persistence remain separate evidence.
Task files, retained planning drafts and accessible problem reporting
Repositories: Partners, Partners API and shared website reporting.
Status: Git-linked API and dashboard deployment verified; documentation publication follows in this release.
What’s Changed
File creation and editing now follow the API’s field and capability contracts. Saving retention or access settings preserves named-user access, replacement dialogs reopen with current file metadata, and date-only retention remains stable across time zones. Busy forms prevent duplicate writes and accidental dismissal. The current requirement-owned evidence policy and multiple-file submission safeguards remain in place.
Planning forms keep their drafts when users return to the page or click the dimmed background. Cancel, Close and Escape remain available. Continuing through the requirement wizard does not submit it before the explicit Create action.
The shared Report a problem button remains reachable above application dialogs using clicks or keyboard navigation. The report form appears above the button. Opening or closing a report preserves the application draft, and changes in browser layers preserve completed report verification.
Impact
Partner teams can create and update task files and report problems while a planning form is open. Reload after release to receive the updated dashboard and reporter. The reporting script may remain cached for up to five minutes.
Upgrade Notes
The release uses the linked Git production workflows: Partners df70db16 and Partners API 7d33027c. Both Cloudflare builds succeeded. The ordinary public reporter script matches the tested release byte for byte, and its downloaded production payload passes the intercepted-provider layer tests. The current dashboard manifest and planning Files, data and dialog chunks also match the local release build byte for byte.
Local verification includes real rendered components, file creation/editing and retention, ten-file submissions, revision history, Chromium/Firefox/WebKit modal tests, API checks and build checks. Documentation check and static build pass. Hosted assets do not establish signed-in task persistence or real GitHub/email delivery; no real report is sent by the regression fixtures.
Protect email and platform notification scheduling
Repositories: Partners API and documentation.
Status: API scheduling correction deployed through Git; interactive bot controls remain OFF.
What’s Changed
Bot cleanup and recovery now use bounded alarms in the existing maintenance object, outside the shared email and platform cron batch. The repair wake tolerates normal timestamp offsets. Shared jobs reuse sufficiently covered leases while retaining each task’s required time and stopping when renewal fails.
Impact
This corrects request-budget exhaustion found during the OFF release checks. Existing notification processors, provider consent and retry policies remain in place. A failed Worker can hold its buffered lease for up to 90 additional seconds; normal completion releases it. No new bot notifications are enabled.
Upgrade Notes
The API passes 11 portable suites, focused alarm/lease tests, TypeScript and a Worker dry bundle. Empty-path fixtures retain all 16 existing processors and five notification recovery wakes, using 34 requests normally or 36 during repair/CMS work, compared with 49 previously. These intercepted fixtures do not certify populated production workloads, inbox delivery or enabled bot capacity. The qualified OFF production window records 11 runtime-ok cron invocations with zero application errors, 59 successful maintenance alarm logs with no warnings and two repair wakes. This includes the next repair/CMS interval. Continue reviewing application-error logs; runtime outcome ok alone does not prove job completion. Enabled and populated workload acceptance remains open.
Interactive bot experience deployed with feature controls off
Repositories: Partners API and shared documentation.
Status: The API, Partners, RegoSite, Admin and documentation are deployed through Git. The interactive bot switch remains OFF pending provider and real-user acceptance.
What’s Changed
The released code includes linked-account notification choices, private transaction and eligible QR access, and separately selected email-blast copies, while retaining the latest guardian-consent registration flows. Operators also have a documented deployment order for the new bot executor: Cloudflare branch previews cannot apply its object migration, while the existing production Git trigger can. Preview and production trigger settings remain unchanged.
Impact
Users do not need to change settings. Existing email and established bot notifications retain their own policies; new private interactions and notification copies remain gated.
Upgrade Notes
Eleven isolated bot suites, focused registration/consent checks, TypeScript and the locked-toolchain Worker dry build pass. Partners passes 102 canonical form-module checks and 23 account browser groups; Rego passes its route/QR and 19 guardian browser groups; Admin passes 93 tests; Docs builds 411 pages. Cloudflare confirms all five production Git deployments, and hosted pages/application assets respond successfully. The executor binding is present and all four existing object namespaces are unchanged. Discord’s private command registration was applied and read back without sending messages; Telegram setup remains pending. Production master readback remains OFF. Genuine linked-account, inbox-delivery, hosted resource/cadence and device-scanning acceptance remain separate checks before activation.
Further native PostgreSQL checks pass 27 platform-notice groups / 289 assertions and 42 campaign groups / 633 assertions. These checks use synthetic constrained source rows, including populated email/inbox baselines, and simulated provider acceptance; they do not prove real delivery. Current Join waitlists have no verified account association, so their bot copies remain unavailable even when an email matches a linked account. Email-only Join delivery remains independent. Verified association support remains in the programme.
Guardian consent and signed registration documents
Repositories: Partners, Partners API and RegoSite.
Status: Production schema, API, Partners and Rego deployed; release checks passed.
What’s Changed
- EMS Conditions of Entry configures minimum age, the guardian-consent age threshold, digital/printed signing, consent text, optional partner PDF forms, signed-original/upload requirements, attendee instructions and step placement. Settings and document assignments use switches. Rego Config links there.
- Eligible attendees complete consent inside the existing registration flow, before payment by default. Organizers can choose another supported position. Guardian name, relationship, phone, email, reading confirmation and a personally drawn guardian signature are required in both printed and digital modes.
- Digital documents use a read-to-the-end screen. Printed mode also requires the online signature and retains the event’s signed-paper/upload rules.
- RegoSite event pages explain the configured minimum age and which eligible ages need guardian consent before registration starts. Guidance uses age at the start of the event and explains digital signing or the configured printed-copy rules. Disabled consent does not show a consent requirement.
- Existing attendee and dealer records show captured consent, the signature, exact document, server signing time and private signed files. Historical acknowledgements remain unsigned until the guardian completes signing.
- Paid/free/gift registrations, group purchase/redemption and dealer slots retain their existing workflows with the required consent checks. Captured requirements survive later event edits; transfer resets consent for the new holder.
Impact
Guardian consent never admits an attendee below the event’s minimum age. A booking holder can prepare details, then hands the device to the guardian to read and sign personally. The recorded guardian identity is self-declared. Signed files use encrypted storage and protected API delivery for authorized people.
Upgrade Notes
The release requires these three migrations, followed by the matched API and sites:
20261020074027_guardian_consent_documents.sql20261020081932_guardian_consent_embedded_preparation.sql20261021021143_guardian_consent_signed_documents.sql
Use Save guardian consent for policy and digital document changes, and Save conditions for the document library. Blank PDF uploads/removals save immediately. Consent remains opt-in for organizers; existing events are not automatically enabled.
Verification and Release
- The three migration versions are present in the production ledger. All 36 consent function bodies and security settings match the native PostgreSQL 17 fixture that passed 72 signing assertions. Base/embedded SQL fixtures pass 48/102 checks. The six consent tables use RLS with no direct attendee access; signature receipts cannot be updated by the application service role.
- Rego passes 19 isolated browser groups, including printed/digital signing, paid/free/gift paths, prepaid group redemption, independent dealer slots and signed-document recovery. Partners passes 10 consent groups, 11 Conditions groups, 10 actual preview groups and 53 shared-signature checks. The canonical preview contract passes all 101 module pairs.
- API fixtures exercise actual mounted standard/gift, group and dealer submission handlers, required-field refusals, encrypted-file routes and frozen requirements. All affected repositories pass their typechecks and production builds.
- Linked Cloudflare deployments succeed for Partners API, Partners and Rego. Live consent-template reads return 200 and protected attendee consent denies unauthenticated access. Fresh deployed assets contain the expected consent settings, reading, signature and frozen-requirement guards.
- The public age notice passes 10 isolated browser scenarios, covering printed and digital consent, missing/zero minimum age, a single qualifying age, disabled/unconfigured consent and invalid/empty ranges. Desktop/mobile views have no horizontal overflow or console errors; navigating back into an event reads its current policy.
Verification uses synthetic browser/API/database fixtures and read-only hosted checks. A genuine signed-in attendee payment, guardian identity and physical signed-original acceptance have not been certified by these checks.
Interactive bot database foundation published with controls off
Repositories: Partners API, Partners schema, Admin, Rego and shared documentation.
Status: Database foundations are published; the interactive bot experience remains OFF pending API deployment and live acceptance.
What’s Changed
The database now supports owned transaction details and eligible QR access, independent Telegram/Discord notification choices and reviewed email-blast copies. Older interactions stay revoked after an account is unlinked and relinked; later consent cannot retroactively enroll an old event. Existing email and established bot notification policies remain independent. Payment-plan features remain held for their separate release.
Validation and Next Steps
Native PostgreSQL verification passes 51 groups / 3,299 assertions. Production readback confirms the expected 692-entry migration ledger and master switch OFF. Email templates and secrets were untouched, and publication sent no messages. Keep the Admin switch OFF until the API deployment, genuine linked-user delivery and device checks are accepted. Users do not need to change settings for this database publication.
Interactive bot candidate verification and release gates
Repositories: Partners API, Admin, Partners, Rego and shared documentation.
Status: Five draft review requests contain the candidate. Interactive bots remain OFF by default; users and event teams do not need to change their settings.
Linked users can review the candidate’s private transaction/details and eligible QR journeys, notification choices and website fallback in the user guide. Event and platform operators have separately selected Telegram/Discord email copies, reviewed message text and independent recovery in the candidate. Existing required email, inbox and staff-bot workflows retain their separate policies. The operator guide covers OFF, pilot, rollback and accepted/unknown-send recovery; payment-plan features remain held for their separate release.
Validation: Exact locked-toolchain API type/bundle checks pass locally. A finite local platform test captures the complete 1,025-recipient source audience in about 2.413 seconds under the unchanged five-second limit. Operator guide v2.3 passes a 411-page build and two desktop/mobile views with eight screenshots, including complete initial signature visibility at390px. The unchanged user guide/layout retain their earlier twelve-configuration proof. Partners, Rego, Docs and Admin candidate Pages checks pass; Rego’s WCAG check also passes, and ten Admin static assets match its approved revision. Admin’s temporary preview settings were restored to their prior policy. Static preview and local guide checks do not establish an enabled API, production database acceptance, genuine sign-in or private delivery.
Next steps: Keep the Admin switch OFF while the full database semantic check, API build diagnosis, hosted OFF/routing, provider setup and genuine linked-user delivery and physical-device acceptance remain open. No additional message, relink or activation is required by this update.
Interactive bot release candidate and private guides
Repositories: Partners API, Admin, Partners, Rego and shared documentation.
Status: Code is assembled in release branches and review requests. The new experience remains OFF by default. A Git check or frontend preview does not establish an enabled API, provider delivery or production release.
What’s Changed
- Linked-account private transaction/detail and eligible QR workflows, independent notification choices and safe website fallback are included in the candidate. Personal details remain private; current ownership, source state and policy are checked at each action.
- Event, Admin and Join email composers have separate Telegram/Discord copies, initially unchecked, explicit reviewed plain text and independent delivery recovery. Single-registration Write follow-up also keeps one operation identity so a pending, accepted or unknown email is not sent again to repair a bot copy.
- Full user guidance and the operator release runbook include the eight transaction families, all 67 classified event types, exclusions, OFF/pilot/rollback and unknown-send recovery. The mobile contents menu now settles its layout before placing a selected heading below the docked controls, with keyboard focus and reduced-motion support.
Impact
The candidate’s catalogue has 53 automatic-copy candidates, five reviewed campaign types, four credential/guest exclusions and five established-delivery entries. Source classification and local mounting are not release acceptance. The minimum bot release profile keeps the held pay-later business schema, payment-plan features and their copies unavailable; ordinary paths require the reviewed complete-absence compatibility check, while partial finance schema presence fails closed.
Required email, inbox, automatic link activation and established staff/bot workflows keep their separate policies and budgets. Accepted and unknown sends must not be replayed. A later link or opt-in cannot fill an old notice/campaign audience. The new additive provider setup tool defaults to a read-only plan; live apply requires a fresh release-owner receipt for verified hosted OFF and routing.
Validation and Next Steps
The portable API aggregate passes nine local suites with 770 finite groups/cases, including twelve-family boundaries and the absent-finance profile; it uses synthetic/intercepted transports and makes no live provider request. Source-specific/native checks, complete original-audience acceptance, exact Git-linked deployment/OFF readback, provider setup and real recipient/device validation retain their own release gates. Hosted Workers Free CPU, full memory, backlog and retention are not established by the local bundle or runtime checks. Keep the Admin switch OFF until the release owner records the applicable evidence.
Interactive bot release work and full guides in progress
Repositories: Partners API, Admin, Partners, Rego and shared documentation.
Status: Local implementation and verification in progress; interactive bots remain OFF. No hosted release or live message is claimed.
What’s Changed
- Local source routing now includes platform updates, existing pay-later lifecycle summaries and optional campaign copies. The selected capture design keeps the complete original eligible audience and prevents later links or opt-ins from filling an old notice.
- Partners and Admin composers have independent, initially unchecked Telegram/Discord copies, explicit reviewed plain text, eligibility previews and separate delivery recovery. A legacy registration follow-up path is still being completed.
- Full user guidance and an operator/release runbook now explain linking, private transaction/QR access, choices, safe recovery, OFF behavior and staged acceptance.
Impact
Existing required email, inbox and established bot workflows retain their own policies. A listed category or locally mounted source is not a release promise. Nine earlier source families have accepted local checkpoints; the three additions still require complete SQL/native and release acceptance. Provider acceptance, recipient confirmation and physical scanning remain separate evidence.
Upgrade Notes
Keep the Admin switch OFF. Source/Worker/SDK and focused composer checks pass within their recorded scope; the full Admin suite retains one unchanged mirror-test failure. The coordinated documentation build, final compatibility checks, hosted Workers Free measurements, provider setup and authorized real-user/device acceptance remain open. No operator action or additional test message is needed from this development entry.