Platform Updates

Repositories: social.furries.ph, partners-api, partners.furries.ph

Status: Local implementation only; database migration, authenticated privacy checks, and Git-connected Pages release remain required

What’s Changed

• Social members can choose separately whether to show upcoming events and past event activity. Both settings are private by default and can be revoked.
• Event cards are requested only when a profile visitor selects the Event activity section. They contain only the approved event name, canonical Regosite link, date, and neutral Going or Attended label.
• The API derives these cards directly from the canonical registration and event records after member consent, event-organizer approval, eligible registration status, public event lifecycle, and signed-in viewer block checks. It does not copy event history into Social.
• The Social app remains a static Cloudflare Pages SPA. All authenticated and data requests go to the existing partners-api Worker; it uses no Pages Function, direct Supabase browser access, or direct upload deployment.

Impact

• Members retain control over whether event participation appears on their Social profile, without exposing ticket, payment, check-in, registration answers, or attendee details.
• Releases must use the repository-connected Cloudflare Pages project. Direct build uploads are not approved.

Validation

• Social type checking, unit tests, static build, and API TypeScript diagnostics passed locally.
• The migration remains unpublished. Synthetic cross-user, organizer suppression, block, revocation, RLS, and authenticated end-to-end checks are still required before release.

Repositories: social.furries.ph, moderation.furries.ph, partners-api, partners.furries.ph

Status: Locally validated; database migration, authenticated integration, and Git-connected Pages release remain required

What’s Changed

• A signed-in Social member can report another activated public profile using the existing review categories. The subject is not told who submitted the report.
• A service-authorized moderator sees an Open moderation continuation on that profile. It creates a short-lived, single-use opaque pointer; the browser address contains no internal profile identifier, reporter detail, or credential.
• The same local triage path now covers public Social Pages, including partner-verified Event Pages. A Page report and handoff use the Page’s public identity only; Page managers, partner records, and canonical Event data are not disclosed to the reviewer.
• Moderators can now archive or restore a reported Page with a required reason and immutable case receipt. This reverses only the Social Page lifecycle; it does not change Event information, partnership verification, Page membership, or any member account.
• Archiving a Page also hides only the Page-authored posts that were visible at that instant. Restoring the Page restores only those marked posts, never a post separately hidden by another moderation action.
• Moderators can also dismiss a case directly from the focused queue. Dismissal requires the same recorded reason as every other decision and does not notify or identify a reporter.
• Case priority can be set explicitly to normal, attention, or urgent with a recorded reason. It is a human triage decision, not an automated ranking score.
• A moderator can release only their own claimed case back to the shared queue. The service rejects claim takeover and attempts to release another moderator’s case, so browser changes cannot bypass work ownership. Cross-staff assignment is not enabled yet.
• Cursor-polled Page events now retain their Page identity through the API to the static dashboard, matching post and profile continuity without increasing polling or downstream request counts.
• The dashboard now visibly lists cursor-recovered publish, edit, report, and moderation events. A moderator can deliberately start a review from an otherwise unreported published post; it creates an auditable staff-review case and continues through the existing single-use opaque handoff, without inventing a member report or opening a case for every post automatically.
• Profile cases can now hide or restore the target’s public Social profile with the same recorded reason and case receipt. Hiding removes only public profile, event-card, discovery, and new-follow access; it does not disable the Furries PH account, change Rego access, modify friendships, private settings, or delete posts.
• Moderators can add a bounded internal note to a case. Notes are append-only audit entries in the restricted case view and are never sent to members, included in reports, or exposed by the dashboard polling stream.
• The focused dashboard can triage a profile case using only its public name, handle, and public bio snapshot. Staff may claim, resolve, or dismiss it. Profile hiding, account penalties, private-profile evidence, and automatic enforcement are not part of this local slice.
• The moderation bootstrap runs in bounded batches: ordinary post-only work uses five downstream API/database calls, while a mixed post/profile/Page queue uses nine and never opens more than three connections concurrently. Both stay beneath the task’s 12-call operating ceiling and Cloudflare Free hard limits.

Validation

• API TypeScript diagnostics, the 10-assertion polling-budget contract, and the 11-assertion profile-moderation contract pass locally.
• Social type checking, 29 unit tests, and the static production build pass. Moderation type checking, three unit tests, and the static production build pass. Synthetic browser evidence verifies the profile controls and accessible report dialog.
• The database migration remains staged only. No hosted Worker or Cloudflare Pages release occurred; release must use the connected Git integration, never direct upload.

Repositories: social.furries.ph, moderation.furries.ph, partners-api, partners.furries.ph

Status: Locally validated; database migration, authenticated integration, and Git-connected Pages release remain required

What’s Changed

• The focused moderation console is now a static React/Tailwind Cloudflare Pages app. It has no Pages Function or separate Worker: all signed-in queue, case, action, handoff, and polling requests go to the existing partners-api Worker.
• The first moderation vertical covers reported local Social posts. Staff can open a role-scoped queue, review a minimized case timeline, claim or resolve work, hide or restore a post with a reason, and receive an immutable action receipt.
• Social staff can open the exact post context in the dashboard through a short-lived, single-use opaque handoff. The URL never contains the post ID, reporter detail, media address, or staff credential.
• That same moderator continuation now appears wherever a current post-backed object is rendered in Social: Home, member profiles, public Pages, conversation roots, and replies. This covers posts, replies, quotes, Page announcements, polls, and attached media without adding a second moderation command or per-card polling. Profile-only, reaction-only, channel/topic, custom-asset, private, and federated objects remain outside this local vertical.
• The dashboard uses cursor-based polling instead of an always-on interrupt channel: 60 seconds while visible, five minutes while hidden, with 70/85/95-percent client backoff protections for the reserved free-plan request budget.
• The API now enforces the daily automatic-poll reserve at the shared database boundary (5,000 checks per UTC day) and serializes a 60-second manual-check throttle per moderator. The dashboard’s Check updates action uses that manual lane; Reload queue only reloads the current case view.
• Social and moderation production builds now carry the public https://api.furries.ph origin through a versioned production build file. This value is public browser configuration, not a secret; credentials remain outside the repository.

Impact

• Moderators have a dedicated starting workspace for reported posts while remaining on the single Furries PH API and authentication boundary.
• Pages should be connected to their Git repositories for release. Direct build uploads are not an approved delivery path.
• Page/event moderation, media evidence, appeals, bulk actions, policies, staff-role administration, and federation controls are not yet released.

Validation

• Partners API TypeScript diagnostics passed locally.
• Social type checking, unit tests, and static build passed locally.
• Moderation type checking, polling-budget tests, static build, whitespace validation, and a rendered responsive static-shell check passed locally. The API polling-budget contract has nine assertions, including the daily cap, service-only access, and concurrent first-request guard.
• The associated Supabase migration is local only; shared-project migration publication and authenticated end-to-end checks remain release gates.

Repositories: signals.furries.ph, partners-api, partners.furries.ph

Status: Released through Git-integrated Cloudflare Pages and the shared API

What’s Changed

• Signals now supports independently operated partner and Furries PH staff survey workspaces through the shared Furries PH account and permission model.
• Public surveys can be completed without signing in. If a survey has rewards, the completed respondent is given one final chance to sign in and claim them; rewards never attach to anonymous identities.
• The release includes typed questions, conditional logic, localized copy, response limits and closing time, scoped analytics, response review/discard receipts, automated analysis, and encrypted webhook delivery with retry state.
• The survey form is static Cloudflare Pages content. Publish or hide now uses a protected production deploy hook to create a route rebuild, while the form itself loads current survey content from the API.
• partners-api remains the only Worker in this flow. The supporting survey and webhook schema has been published to production.

Impact

• Partner operators and authorised Furries PH staff can use the Signals workspace without receiving a separate survey account.
• The canonical signals.furries.ph domain is active on the Git-integrated Pages project, which deploys reviewed commits from furriesph/signals.furries.ph on main.
• Webhook endpoint registration stays unavailable until an administrator supplies an explicit list of approved destination hosts. This prevents an operator from sending respondent events to an unreviewed host.

Validation

• Signals Astro checks completed with zero diagnostics; its static Pages release returned HTTP 200 from the deployed workspace.
• The production API returned HTTP 200 from its published Signals-route index after the schema migration.
• API TypeScript checks completed before deploying the current Worker release.
• The Git-triggered Pages deployment and a separate protected deploy-hook build both completed successfully; the canonical survey route returned HTTP 200.

Repositories: social.furries.ph, signals.furries.ph, partners-api

Status: Signals deployed to Cloudflare Pages; canonical-domain and deploy-hook configuration remain required

What’s Changed

• The new Social interface is a static Cloudflare Pages application, not a separate Worker or Pages Function.
• Social Pages releases must use the Cloudflare Git integration from reviewed commits; direct uploads are not an approved delivery path.
• Signals is a static Cloudflare Pages application; each published survey is materialized as a Pages route, while its current form content still hydrates from the existing API.
• Account setup collects only e-mail, profile name, username, and password, then uses the existing Furries PH API and canonical attendee account.
• Existing Regosite members can sign in and finish only their Social profile name and username; their Rego-only information and event history are not returned to Social.
• The Social page makes a single direct request to the API for setup. It does not receive a database credential or make direct Supabase or Sanity calls.
• partners-api is the sole Furries PH Worker/API boundary for these public applications.
• The first local Social timeline now stores authored Markdown through that API and renders it through a restricted sanitizer boundary; raw HTML, arbitrary image embeds, and private Rego data are not supported.
• Members can now report a local Social post using clear categories. Repeated independent reports create a reversible moderator triage signal, not an automatic removal or account sanction.
• The third independent open report is now clustered inside the database transaction, so its reviewer queue priority, audit receipt, activity event, and count-only evidence stay aligned even under concurrent reports. It still cannot hide content, sanction an account, or reopen a human-closed case.
• Report intake now allows up to 20 new post reports per member per hour. Correcting an existing report stays available without using that limit; reaching it shows a temporary cooldown only and never affects account standing or content visibility.
• The first mechanical anti-spam guardrails cap short post bursts and stop immediate duplicate reposts. They are temporary action cooldowns, not hidden reputation scoring or automated moderation decisions.
• Post creation also has visible caps for member mentions and web links. These reject only the over-limit action and do not fetch links or make an automated policy judgement.
• Public Social handle pages now show only a member’s local Social posts. Regosite contact information, friendship state, and event activity remain excluded.
• Public Social handles use the direct /:username address; there is no /u/ prefix to remember or share.
• Members can add a bounded local reaction to a post. The visible timeline and public profile receive reaction totals in a batch; the interface does not make an extra API request for every card.
• Signed-in members can privately mute or block a Social profile. The selected handle is immediately suppressed from that member’s local timeline; the profile owner is not notified and the action does not trigger automatic moderation.
• Members can privately follow a Social profile and choose a chronological Following feed. The public local feed remains clearly labelled Local; follows are separate from Regosite friendships and do not enable federation.
• The Social composer can now attach up to four small JPEG, PNG, GIF, or WebP images. Images are validated before they are stored in Sanity, include optional alt text, and are delivered through the existing Furries PH API proxy rather than a direct media URL.
• Posts marked with a content warning now keep their text and images hidden until each viewer explicitly chooses to reveal them.
• That content-warning choice now applies consistently on public profile pages as well as the local timeline.
• Authors can now delete their own local posts through a clear confirmation step. Deleted posts leave the public feed while required safety-review evidence stays available to moderators.
• To protect the free-tier media allowance, each member is limited to 20 Social image uploads per hour. The check happens inside the existing API before an image reaches Sanity; it does not add a new Worker, queue, or AI service.
• A later upload that exactly matches a moderator-confirmed prohibited image fingerprint is now held before it can reach Sanity. The member sees that it was not uploaded; staff receive a minimized review receipt, can retire a mistaken policy, and then release the receipt so the member can deliberately upload again. This is exact SHA-256 matching only—there is no AI classifier, fuzzy similarity match, automatic account penalty, or raw media exposed to the reviewer queue.
• Exact-media holds and releases also enter the existing moderator update stream as opaque receipt events. Repeated matching uploads coalesce safely rather than creating a new alert on each retry, and the dashboard keeps its existing budgeted polling schedule.
• Each local post now has a shareable conversation page. It shows the original visible post and up to 50 direct local replies in one bounded API response without exposing private data.
• Members can reply to a visible local post. Replies use the same safety, media, and account boundaries as original posts.
• Members can also create a local quote post that references a visible local post without enabling federation.
• Social now includes an on-demand private notification inbox and explicit-submit public people discovery. Neither feature uses realtime connections or exposes Rego/event/private-profile data.
• Page operators can keep up to 20 private Page drafts, update their Page profile, make an explicit ownership succession, archive a Page with a confirmation, and load a bounded shared inbox for public reactions, replies, and quotes. Followers and private member data are never included in that inbox.
• An authorized event-partner manager can now use a short-lived, single-use pointer to open the matching Social Page workspace from the Partner Dashboard. The pointer is not a credential or role grant: Social checks the same signed-in user’s existing Page role separately, then removes the pointer from the browser address.

Impact

• Members will be able to start a Social account without completing Rego-only personal details. Those details remain requested only when a later Rego feature needs them.
• The deployed Pages project is available at its Cloudflare Pages address. The canonical signals.furries.ph domain, a Git-connected Pages deploy hook, and its protected API secret still need to be configured before publish/hide can trigger route rebuilds.
• The production database now contains the additive survey foundation and invitation schema, and the deployed API exposes the published-route build index used by Signals Pages.

Validation

• Social type checking, unit tests, and static production build pass locally.
• Browser validation confirms that an unconfigured static preview still renders safely and exposes the accessible sign-in dialog instead of crashing.
• Social Markdown rendering and direct API-client tests pass locally, alongside the static production build and API TypeScript check.
• The local report client, API route, and database migration are type-checked; publishing the migration and testing it against the shared Supabase project remain release gates.
• The local reaction API/client and its additive database migration are type-checked; migration publication and shared-project verification remain release gates.
• Private mute/block controls and their additive migration are source-validated; shared-project migration publication and end-to-end safety-control testing remain release gates.
• Local follow/following-feed routes, client calls, and additive migrations pass API/Social TypeScript checks and Social client tests; shared-project migration publication and live-route testing remain release gates.
• Image-upload, attachment, and proxy contracts pass API/Social TypeScript checks and Social client tests. The Social database migrations remain unpublished, so shared-project, real-Sanity, and media-review lifecycle verification are still release gates.
• Partners API TypeScript checking passes locally.
• The Page drafts, Page activity, and one-time dashboard-to-Social handoff contracts pass local API/Social type checks, Social client tests, static production builds, and diff checks. Their additive Supabase migrations and hosted replay/expiry/cross-origin checks remain release gates.
• Atomic report-cluster source contracts and API TypeScript checks pass locally. The additive migration cannot be exercised until a local or authorized shared PostgreSQL environment is available; migration publication and hosted reviewer-flow checks remain release gates.
• The report-intake quota contract and full API type check pass locally. Its unpublished Supabase migration still requires database execution, advisors, and hosted safety-flow certification before release.
• The exact-media quarantine source contract, static staff review panel, API type check, dashboard typecheck/tests/build, and local visual review pass. Its unpublished migration, authenticated Worker authorization, policy-owner approval, real-Sanity confirmation, and release/re-upload verification remain release gates.

Repositories: signals.furries.ph, partners-api, partners.furries.ph

Status: Signals Pages project deployed; data migration and publish-hook configuration remain required

What’s Changed

• The survey product and deployment identity is now Signals at signals.furries.ph; the existing local checkout path remains unchanged during the rename.
• Partner operators with the new survey permissions and authorised Furries PH staff have separate owner-scoped survey workspaces.
• Signals supports public no-login survey responses. Where a reward is configured, the completed response is held for a short-lived account-claim decision: a respondent can sign in to their existing Furries PH account to claim perks or explicitly finish without them.
• The initial platform foundation includes typed rewards, immutable published survey versions, scoped response/analytics records, mandatory GA4/Clarity loading when deployment IDs are configured, and automated response-analysis snapshots.
• The Partner Dashboard now shows an owner-safe Signals analytics summary alongside the Signals workspace entry.

Impact

• Operators should use the Surveys entry in the Partner Dashboard, which now opens signals.furries.ph.
• The static Pages shell is deployed. Publishing is held behind the additive survey schema migration; the canonical domain, analytics IDs, and Pages deploy hook must be configured before live survey publication.

Validation

• Signals Astro check and production build pass with zero diagnostics.
• Partners API TypeScript check passes.
• The deployed Pages shell and a deep survey URL were inspected in a real browser.
• Signals and the API now support Yes/No and bounded slider questions with matching server-side validation.

Repositories: partners.furries.ph

Status: Validated locally

What’s Changed

• Moving between Event Planning workspaces now closes any open record or action dialog before the new workspace renders.
• Personal notification preferences can be opened reliably after moving between planning areas.
• Templates now provides a dedicated Import records action that opens the CSV preview-and-apply flow without replacing project settings actions.

Impact

• Event operators will no longer encounter an invisible previous-workspace dialog blocking the next planning action.

Validation

• Event Planning source contracts, resilience checks, and the full browser workflow certification passed locally, including CSV bulk import and clean browser runtime output.

Repositories: partners.furries.ph

Status: Released

What’s Changed

• Protected dashboard actions now open a shared six-digit authenticator-code prompt instead of leaving operators at a recent-MFA error.
• After a successful code verification, the original protected action resumes automatically.
• Admin member controls now use a working action dialog for editing or removing access.

Impact

• Administrators can complete security checks and continue their work without restarting the action.

Validation

• Dashboard type checks, production build, and dashboard button-interaction certification passed.

Repositories: partners.furries.ph

Status: Released

What’s Changed

• Partner-dashboard invitation, confirmation, recovery, and email sign-in links now use a 24-hour validity setting in the hosted authentication service.
• The deployment helper now keeps that hosted setting synchronized with the checked-in Supabase configuration and the 24-hour wording in FPH email templates.

Impact

• New Partner invitations no longer expire after the prior one-hour default. Existing expired invitations still need to be sent again.

Validation

• Confirmed the hosted authentication configuration reports a 86,400-second email-link expiry after deployment.

Repositories: partners.furries.ph

Status: Validated locally

What’s Changed

• Restored the established Partner roles — Admin, Trust and Safety, ConOps, Marketing, and Partner member — in the FPH Admin Users & Access form.
• The access API accepts those Partner roles again when inviting someone to a partner organisation.
• Admin directories now replace a failed access check with a clear retryable error instead of remaining indefinitely on a loading state.

Impact

• FPH administrators can add a user to a partner organisation without receiving the role-validation error.

Upgrade Notes

• Reload Admin → Users & Access, choose the partner organisation, enter the email address, and grant Partner member access.

Validation

• Verified the form’s submitted role matches the API’s accepted membership-role registry. Dashboard and documentation diagnostics and static builds passed locally.