Platform Updates

Repositories: Partners API and Partners authentication documentation. Status: Documentation correction for the published Discord and Telegram login release.

What’s Changed: The operations guides now distinguish the enabled production services from the earlier isolated canary. They record the applied login, messaging and legacy-link migrations, current API callbacks, and sign-in through eligible existing connections without Relink. Historical canary cleanup is clearly separated from a deliberate production rollback.

Impact: Operators should use current provider checks and retain the existing account connections. The guide no longer describes applied migrations as unpublished or instructs routine cleanup to disable the live providers. Application behavior and provider configuration are unchanged.

Upgrade Notes: No migration or account action is needed. Hosted readback confirms the five relevant migration ledger entries. Fresh real Telegram account selection, controlled inbox confirmation, passwordless return and recipient delivery remain separate acceptance checks.

Repositories: Partners API and Partners authentication documentation. Status: Published through successful Git-linked Cloudflare builds for API 0c2d6d75 and Partners 82169a2a.

What changed: Choosing between two existing Telegram-connected accounts now preserves the browser’s form origin and allows the return to the intended Furries PH app. The correction addresses the API’s “Origin is not allowed” error and a separate browser block on the return redirect.

Impact: Both account connections, histories, permissions and EPS preferences remain intact. Existing origin, security-proof, expiry and account ownership checks still apply. No provider settings, database migration or relinking are required.

What to do next: Start a fresh Telegram sign-in and select the intended account. Earlier attempts may have expired.

Validation: 147 mounted handler/middleware and 19 renderer checks pass in both the release candidate and integrated original checkout. A native browser fixture reproduces the old rejection, submits the corrected form and returns to its intended app origin without a referrer. Tests cover both owners and all four products; the anonymous fixture does not prove a real Telegram account choice or inbox delivery. API typechecks and dry build pass, with successful exact-commit Git-linked publication. Fresh real-account choice and inbox acceptance remain open.

Repositories: Partners, Admin and Social. Status: Published through successful Git-linked Cloudflare builds for Partners 096324b7, Admin 091b8eb4 and Social eb91ebd1.

What changed: Account pages keep React Router’s startup scripts in the browser’s normal execution path, using the same Cloudflare exclusions already present in Rego. Builds check the complete expected bootstrap before publication.

Impact: Sign-in methods, permissions, sessions and account connections retain their existing behavior. Users need no configuration change. This is a startup compatibility adjustment, with no measured speed improvement claimed.

Validation: Partners passes16 focused checks, typecheck and build; Admin passes16 focused checks, all65 tests, typecheck and build; Social passes13 focused checks, all651 application tests, typecheck and build. Checks cover script-body/order preservation, unrelated scripts, repeated finalization and missing bootstrap. All three served pages now have protected startup scripts and native modules. Their55 initial JavaScript/CSS assets match the exact immutable releases. Deployed Admin and Social render provider, email/password and email-code choices; Partners retains the existing denial for an account without partner access. These page checks do not establish new provider sign-in, permissioned-account access or inbox delivery.

Repositories: Partners API and Partners authentication/schema documentation. Status: Additive migration applied; API and Partners published through successful Git-linked Cloudflare builds.

What changed: When an eligible Telegram connection belongs to a Partners account and an older connection belongs to a separate attendee account, sign-in offers an explicit account choice. Users can retain both accounts and their existing EPS/community connections.

Impact: Selecting the attendee account does not move the Partners connection, remove its notices, merge account histories or copy permissions. Normal Telegram confirmation is still required, with no Relink step for the fixed eligible connections. Each account retains its own login-method removal controls.

What to do next: Start Telegram sign-in normally and select the intended account when prompted. Account choices expire with the original sign-in attempt. Unsupported conflicting credentials still stop safely for support review.

Validation: API 3c9f3499 and Partners c3d5fbda have successful exact-commit Git-linked builds. The additive migration is applied with service-only access and unchanged account, membership, connection and notification counts. Local signed-handler tests cover both selected owners across four products, CSRF, expiry, replay, races and revocation. The database suites pass 130 disposable and 143 native PostgreSQL checks; the prior historical-subject suite passes 195 with the addition. Typecheck/dry build, desktop/mobile chooser rendering and seven hosted rejection/privacy probes pass. Real phone selection remains a separate acceptance check.

Repositories: Partners API, Partners, Rego, Admin and Social. Status: Published through successful Git-linked API and four-client builds; legacy compatibility is active.

What’s Changed: Personal Telegram and Discord linking now connects the same Furries PH account for sign-in, community features and supported notifications. Profile setup, account security, EPS and Rego use the same account connection. Personal authorization in organization setup follows the same rule; bot installation and group/server selection retain their existing permission checks.

Impact: Returning through a newly linked provider keeps the original account and its permissions. Existing notification preferences remain effective, and provider privacy settings can still block delivery. A new linking attempt waits for its own completion receipt instead of accepting an old connection as success.

Upgrade Notes: Existing eligible EPS and community links are migrated automatically: use the normal Telegram or Discord sign-in confirmation, with no Relink step. Older Telegram connections that stored an OIDC subject are also covered; fresh confirmation safely resolves the numeric messaging identity. The migration preserves the original account, permissions and notification choices. It does not import later profile edits, transfer another account’s provider identity, or copy permissions. Migrated methods are visible and removable in account security. Disconnecting community messages and removing a login method remain separate controls.

Validation: API 4316d785 has a successful Git-linked Cloudflare build, confirmed directly in the dashboard, with 100% traffic and 64 text/secret variables on Free. Three reviewed migrations are applied at their canonical versions; hosted readback verifies private/service-only access and unchanged profile, identity and membership counts. The historical Telegram follow-up passes 195 disposable and 202 native PostgreSQL checks, including real competing claims and revocation races. Mounted social (131), legacy (75) and installed-SDK linking (37) groups plus type/dry-build checks pass. Current-release Discord confirmation reaches the original Rego account without Relink, retains its two prior transaction records through reload, and returns protected pages to sign-in after sign-out. That controlled account has no Partners membership, so a permissioned-account admission check remains open. This does not establish provider-message delivery or inbox/passwordless receipt.

Client release: Partners 187da03b, Rego 531989ab, Admin a658e33f and Social 7d567997 have successful exact-commit Cloudflare builds. Local rendered-component checks cover desktop/mobile connection status, optional relinking, failed attempts and removal dialogs. Published asset evidence is recorded separately from actual signed-in profile and permission acceptance.

Repositories: Partners API and Partners. Status: Migration applied; API and Partners published through successful Git-linked Cloudflare builds.

What changed: Signing in or linking a verified Telegram or Discord account now automatically prepares personal bot messages. Telegram asks for message permission during authorization. A successful bot notice confirms readiness, and unchanged ready accounts do not receive another setup notice. Partners shows setup progress without requiring a separate Start, Verify or Test action.

Impact: Existing notification settings and account ownership still apply. Discord may block delivery because of its privacy or shared-server requirements; Telegram may refuse a blocked bot. Temporary confirmed-unsent failures retry automatically. Uncertain sends stay paused for support review, and unlinking stops messages to the matching account.

What to do next: Sign in or link normally. Telegram asks for the new message permission during authorization; prior grants cannot gain it automatically. No existing accounts are bulk messaged. Provider blocks still require correcting the provider’s permissions. Operators should confirm actual receipt using an authorized controlled account.

Validation: The reviewed migrations applied at their canonical versions. Hosted readback confirms RLS, service-only activation RPCs and the identity-invalidation trigger, with no display or messaging jobs created by publication. API ba8d8964 and Partners 66342bed have successful Cloudflare builds; current custom-domain feature assets match the immutable Partners deployment. Live provider capabilities pass for all four products, Telegram authorization includes message access, and Discord retains the API-owned callback. Unsigned internal dispatch is rejected. A hosted signed-dispatch probe was not run because its signing secret has no local copy; local signed dispatch/native Worker/SQL/Hono fixtures pass. Desktop/mobile settings checks cover automatic progress and provider failures. Actual recipient delivery remains unverified; no test message was sent to a real user.

Repositories: Partners API, Admin, Partners and Rego. Status: Migration applied; all four applications published through successful Git-linked Cloudflare builds.

What’s Changed: Furries PH administrators can configure a BIR registration seal and QR code in Admin under Business registration. Partner administrators can configure a separate record in Partners organization settings. Rego Legal shows the published platform record; event-related pages show the relevant organizer record, including registration, Dealers Den and Shop. Uploading prepares the image; an explicit save controls publication, replacement and removal.

Impact: Buyers can view uncropped badges and QR images and follow an optional official BIR verification link. Each record identifies its registered business. When no published images are supplied, Legal and event pages hide the entire BIR section, including placeholder messages and reserved spacing. Uploads stay behind API media URLs, and each saved change has API-owned audit history. Unpublished settings and other partners’ configuration stay protected.

Upgrade Notes: Operators can now supply genuine BIR-issued seal/QR images in Admin or Partners, enable publication, save, and verify their public pages. Keep the badge clear and unaltered; do not upload the entire Certificate of Registration. Public BIR sections remain hidden until published images are supplied. No attendee setup is required.

Validation: API ba8d8964, Admin 4af4a2d1, Partners 66342bed and Rego 94c32355 have successful Cloudflare builds. Their custom-domain BIR feature modules match the corresponding immutable deployments. The live public platform read returns an empty registration with no-store caching; anonymous management reads reject. Live desktop/mobile Legal and event pages fetch the new endpoints successfully and render no BIR section or reserved wrapper when unconfigured; legal navigation, overflow and runtime checks pass. Release-checkout typechecks/builds, scoped API/SQL tests and synthetic upload/save/reload/removal/error browser checks pass. Genuine BIR documents, physical-device scans and hosted authenticated upload/save persistence remain separate operator acceptance checks.

Repositories: Partners API and Partners authentication/schema documentation.

Status: Published through successful Git-linked Cloudflare builds. Both reviewed compatibility migrations are applied; Supabase Free is retained.

What changed: Connecting Discord as a login method now uses the same api.furries.ph consent destination as ordinary Discord sign-in. Signed OIDC proof binds the selected Discord account before connecting it. Existing native Discord accounts retain their account IDs and sign-in path. Free is retained.

Who may notice: People adding Discord in linked login methods across Partners, Rego, Admin and Social. Existing Telegram, email/password, profile and membership requirements remain available. Discord may still show its own login or security prompts, and Supabase remains the session issuer.

What to do next: Connect from account settings after a fresh sign-in. A Discord account already attached to another Furries PH account cannot be moved through this flow. No new bot/guild permission or paid domain is required.

Validation: API a71292fa passed its exact Cloudflare release.126 mounted callback groups,115 signed-proof/native Worker groups,108 SDK identity groups, 156 SQL checks,96 operator groups,56 messaging cases and type/build checks pass. Real hosted Social consent names the API and returns to the existing native account; Settings retains both provider methods after reload. Both short-lived stages clear their proofs. Four audiences pass capability/privacy readback, and service-only database privileges are verified. New-method attachment, inbox/passwordless and remaining account-safety acceptance remain distinct. Concurrent direct Auth flows can still create ambiguous ownership across native/OIDC namespaces; the API rejects it without automatically merging or unlinking accounts.

Prior release — Discord sign-in identifies the Furries PH API

Repositories: Partners API and Partners authentication documentation. Status: Published through the linked GitHub branch and Cloudflare build.

What changed: Discord’s first sign-in consent screen now names api.furries.ph, like the API-owned Telegram flow. An already-authorized native Supabase continuation completes sign-in without a second consent screen when Discord permits it. Existing accounts and free services are retained.

Who may notice: People choosing Continue with Discord across the shared Furries PH login surfaces. Discord’s own login and security prompts can still appear, and Supabase remains part of the session flow. Connecting a new Discord login method retains its existing native consent and may still name Supabase.

What to do next: Sign in normally. No account migration or paid upgrade is required. Existing email-confirmation instructions and resend controls remain.

Validation: 114 helper/native Worker groups, 77 mounted route groups, full API typecheck, dry build and independent review pass. Real hosted Social authorization shows the API destination and returns without another consent screen. Signed-in Settings survives reload with both existing provider methods. Read-only evidence shows the native account/identity predates release and both short-lived stages completed and cleared proofs. Capabilities pass four audiences; broader inbox, linking and account-safety acceptance remains separate.

Repositories: Partners, Rego, Admin and Social.

What changed: Telegram and Discord appear alongside the other sign-in methods immediately, with Telegram first. Each button uses its own logo and brand colours. Availability checks update the existing buttons without inserting or reordering them; unavailable methods remain visible and disabled.

Who may notice: People opening any shared Furries PH sign-in screen, especially on a slow connection.

What to do next: Choose your preferred sign-in method. If a provider is unavailable, use another method; a failed availability check offers a retry. Normal profile and account-security requirements still apply.

Validation: All four typechecks and production builds pass, along with 56 rendered component groups and eight desktop/mobile sign-in route checks. Those route checks keep provider availability pending until both buttons and the ordinary controls are visible. Keyboard access, light/dark presentation, failure/retry, disabled/pending states and local logo loading pass. Hosted Git-linked builds and matching provider assets are checked separately before this release note is published. Existing email/password controls remain available.

Repositories: Partners API, Partners, Rego, Admin and Social. Status: Schema/API/frontend changes published and both provider options enabled; revised real account and inbox acceptance remain in progress.

What changed: Shared login components include API-controlled Discord and Telegram options and account settings for connecting/removing login methods. Provider sign-in will not require email verification. Normal profile setup collects and registers email with the same account for later passwordless email login. Linking that email pauses the current setup page and directs the user to continue from the confirmation email. Existing product sessions, membership, profile and security checks remain in place. Bluesky login is abandoned; its research, design and task file are retained outside active release requirements.

Who may notice: Account holders now see Discord and Telegram options on the four shared sign-in screens. Existing email, password and passkey controls remain available where supported. Normal profile, membership, legal and security requirements still apply.

What to do next: Complete normal profile setup after provider sign-in. When linking an email, check your inbox and spam or junk manually, then continue from the confirmation email link to enable later passwordless email login on the same account. The check-email modal offers an explicit resend action; it does not open a mail app, composer or web inbox. Provider sign-in remains available without a verified email. Controlled inbox delivery and passwordless-return testing remain open.

Validation: The reviewed migration and five application builds are published through normal release paths. Current custom-domain and immutable frontend assets match, and public login/callback screens pass desktop/mobile checks. Both provider controls are enabled across all four sites. Local native PostgreSQL passes 479 assertions; current SDK and native Worker fixtures cover same-account pending email attachment, redirect rejection and inbox/passwordless behavior. Earlier controlled real Discord and Telegram login/refresh/sign-out and Telegram enrollment evidence is retained. The controlled Rego profile save now passes same-account pending email attachment. Inbox delivery, confirmation and later passwordless return remain unverified; deployment and public controls do not establish those outcomes.

2026-10-14 preflight: The reviewed application code is unchanged. A standard Supabase dry-run confirms only the reviewed authentication migration would apply. Providers remain disabled; publication and real inbox/hosted acceptance remain pending.

2026-10-15 staged release: The reviewed authentication migration, API and four frontend changes are published through the normal release paths. Current frontend assets, ordinary sign-in controls and stricter email-callback headers pass hosted checks. The API release fits the existing hosting plan after two redundant configuration values were removed; email delivery policy is unchanged. A native Worker transport failure was reproduced and corrected while retaining strict redirect rejection. Discord and Telegram are now enabled in the API for all four sites, with visible provider controls verified. Revised real profile setup and inbox/passwordless account acceptance remain open; this staged release is not a claim that those tests have passed.

2026-10-15 consent names and account check: Discord authorization now displays Furries PH. Real hosted Social sign-in, session refresh, device sign-out and returning Discord sign-in retain the same account and profile; signed-in settings display the existing Discord and Telegram login methods. The free API-owned Telegram route is now deployed. A controlled real Rego sign-in through that route preserves the same account/profile and creates a refreshed Supabase session without email verification, then opens normal profile setup. Telegram’s bot name is Furries PH; the tester confirms its new consent hostname is api.furries.ph, while literal title wording remains unverified. The current free plan is retained. Partners correctly denies this account access because it has no partner membership. The test profile save attaches its supplied contact email as pending email on the same Auth account and returns to Transactions. Inbox confirmation, later passwordless return and new-route account-linking acceptance remain open.

OAuth fallback recovery: Known expired or invalid provider attempts now appear before a retained Partners session can mask them with a membership error. The error screen uses fixed messages and clears raw query/hash data; retry returns to the ordinary sign-in picker. Local before/after browser checks and all four frontend typechecks/builds pass. All four exact Git-linked releases pass, with matching public assets and ten desktop/mobile checks.

Complete profile legal documents: Rego profile setup now displays the full approved Terms and Conditions and Privacy Policy, including every section and list. Each document must be scrolled to its end before it can be accepted. Closing a document does not accept it. Desktop/mobile component checks, typecheck/build and the published signed-in readers pass. The legal text is unchanged.

Validation follow-up: Rego’s contract check now recognizes the reviewed email-confirmation navigation validator while preserving checks against direct database clients and retired profile routes. The plan and API notes now match the deployed free Telegram route. The controlled first-email confirmation has an unknown delivery outcome; inbox confirmation and later passwordless login remain unverified. The uncertain message is retained for reconciliation.

Email-link continuation: Partners, Rego, Admin and Social pause pending email-link setup in a blocking “Check your email” modal. It tells users to open their inbox manually and continue from the confirmation email link. Mail-opening buttons, webmail links, service choices and automatic app/browser launches are removed. Pressing Escape, clicking outside, reloading or requesting another email cannot complete confirmation. “Resend confirmation email” explicitly requests the same account’s pending confirmation, waits one minute between attempts and retains the blocker. Request acceptance does not prove delivery. Confirmed links keep the normal product checks; provider sign-in still has no verified-email prerequisite.

Email delivery: A controlled delivery check identified the current mail provider’s daily sending quota as the reason new confirmation emails are blocked. The localized rejection now receives a clear quota diagnostic. Email linking and later email login remain under verification until sending recovers and a fresh inbox confirmation succeeds. Current free services are retained; uncertain messages are not automatically replayed.

Handoff verification: Actual-component and built-route desktop/mobile checks cover instructions, explicit resend, focus, cooldowns, account changes, pending reloads, callback readiness and the absence of mailbox/app launches. Browser fixtures intercept resend; actual inbox confirmation and later passwordless return remain unverified.