Platform Updates

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

Status: Local implementation only; the migration and paired-account release certification remain required

What’s Changed

• Regosite and Social now render accepted friends, incoming requests, and sent requests from the same canonical relationship summary rather than maintaining separate graphs or making several browser calls for one Friends screen.
• The summary is capped at 100 entries per state and excludes contact details, registrations, attendance, payments, events, posts, follows, moderation, and local safety controls.
• Social continues to keep follows and local blocks separate. Regosite continues to request its consented Friends-at-events view separately; that data does not cross into Social.
• A personal Social post can now be marked Friends only. The static Social app has a bounded Friends timeline, while the existing API checks the current canonical relationship before it returns a Friends conversation or accepts a reaction or report. Social Pages cannot use this audience, and replies/quotes stay in their original audience.
• Friendship summaries and Friends-only timelines now explicitly bypass browser and intermediary caches. Sending a request refreshes the open Social Friends dialog, and every subsequent authorized read resolves the current shared relationship without a polling loop or copied graph.
• The Friends dialog is relationship management, not a directory of Social accounts: it no longer links every Regosite friend to a Social profile merely because they are friends.
• A staged activation marker separates a Furries PH account from a Social presence. It is set by Social signup/profile completion and backfilled only for existing Social post authors, so being a Regosite member or friend never alone creates a public Social profile.

Impact

• Members see the same relationship state in both products with fewer browser/API requests. A removed friendship revokes future Friends-only Social access without turning follows, attendance, contacts, or moderation records into shared data. Regosite now also sends an idempotency key for friend requests and changes, so the canonical action receipt can recognize a repeated client command. Existing notification and privacy choices remain unchanged.

Validation

• The 16-assertion summary contract certificate checks caps, service-only database execution, its no-event/no-Social-content join boundary, both API facades, and cache-safe reads. A 13-assertion Friends-audience certificate checks the bounded feed, access guards, and no-store freshness. Social type-checking, 60 unit tests, and the static production build pass. The migrations are staged only, and no direct deployment or data migration occurred.

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

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

What’s Changed

• Social account creation still asks only for email, profile name, username, and password. A member can later add, edit, preview, or clear an optional Markdown bio from their own Social profile.
• The same versioned, safe Markdown contract now stores a long description for a Social Page. Public profiles and Pages render through one safe display component; the API rejects raw HTML and keeps a bounded plain-text projection for non-rich-text uses.
• These fields extend the existing canonical member/Page records instead of creating duplicate Social profiles. The static Pages app calls only the existing partners-api Worker, with no new Worker, Pages Function, direct browser database, or direct browser Sanity connection.
• When a Social member later opens incomplete Regosite setup, the already loaded canonical display name and username are visibly identified as shared account details for review. Regosite does not copy Social posts, follows, bios, or event activity, and it does not make another cross-site request.
• Page owners and managers can write, character-check, preview, and save the optional long description from the Page workspace. The current role and public-display boundaries remain unchanged.

Validation

• The Social API client and rendering tests pass locally (26 tests), as do the Social production build and API type-check. Fixture-backed browser captures verify both profile and Page Markdown write/preview flows.
• The additive database migration is staged only. No migration was applied, deployed, or uploaded directly; any future Cloudflare Pages release must use the existing Git repository integration.

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

Status: Local implementation only; the projection migration, reviewed canonical mappings, and Git-integrated release remain required

What’s Changed

• Social now has an /events browse route for public Furries PH events. It is deterministic, searchable by keyword and event format, cursor-paged, and links only to the canonical main-site event page.
• The API owns an explicit public-event projection instead of reading the operational Event Management tables from a browser. Its 25-result ceiling keeps one Social browse interaction to one bounded API request and one bounded database read.
• The projection excludes attendee, registration, payment, staff, RSVP, check-in, exact venue, coordinates, raw media origin, and recommendation data. Browser access to its table is denied by RLS and database grants.
• Event archival and partner reassignment automatically remove the matching projection. Its intended source is now a secret-gated CMS webhook that accepts only reviewed public metadata and controlled coarse-area/topic identifiers; the staff command is recovery-only.
• The first browse screen intentionally does not request location, inspect a social graph, or personalize results. Saved events, social RSVP, and recommendations remain separate privacy-gated work.
• Members can now explicitly narrow that same public catalogue by up to five controlled topic IDs and an optional two-letter country code. The static browser stores neither selection; it sends them only with the one bounded catalogue request and does not infer a member’s interests or device location.
• Signed-in members can privately save or remove a public event. A saved event is owned by the canonical member account and is not a registration, RSVP, attendance signal, admission permission, Event audience list, or profile disclosure.

Impact

• Members can inspect the public event catalogue without revealing whether they plan to attend. Event operators keep registration and admission flows on their canonical Furries PH event pages.

Validation

• The API’s public-event contract certificate passes 13 assertions. Social type-checking, 28 unit tests, and its static production build pass. A browser fixture verifies the rendered event card, filters, canonical link, and privacy notice.
• The CMS webhook still needs its independently stored Worker secret and Git-configured Sanity webhook before it can populate the catalogue. Until then, the new endpoint rejects every request.
• The Supabase migration is staged but not applied: local Postgres was unavailable. No direct upload or deployment was performed; Cloudflare Pages will receive the change only through a reviewed Git commit.

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

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

What’s Changed

• Survey owners can cap a categorical answer or a Yes/No answer directly in the Signals workspace.
• The selected rule is part of the immutable published survey definition. It applies consistently to public links, signed-in respondents, and invitation links.
• Final submissions are committed through one database transaction per survey, so simultaneous responses cannot exceed a configured quota.
• When a quota is already full, Signals records a neutral disqualification outcome. It does not disclose the threshold, issue a reward, or include the response in completed-response analytics.
• Survey pages can now randomize their question order per respondent. The order is derived from the respondent’s existing resume key, keeping a saved public response stable after a reload.
• Survey authors can carry an earlier answer into a later prompt with a validated {{question-id}} placeholder. It resolves only inside that respondent’s active response and never looks up another person’s data.
• Owners can compare a categorical outcome between one selected answer group and all other answers. Signals suppresses groups and outcome cells below five completed responses and never returns raw response or account data for this view.
• Survey owners can add forward page branches for a categorical answer. The API validates that a branch only uses an earlier controller and moves to a later page, while the respondent form and draft path preview use the same immutable rule.
• Owners can group related questions into page-scoped research blocks. Published forms retain those sections and use deterministic per-respondent block and question ordering when configured.
• Owners can schedule daily or weekly private aggregate-report snapshots. Each run is leased by the shared API and uses a durable run token, so an interrupted Worker retry cannot create a duplicate snapshot.
• Owners can grant a saved aggregate snapshot to one Furries PH account at a time, set an optional expiry, and revoke it later. Recipients see only the immutable aggregate report—never individual responses or respondent account data.
• Survey owners can test their unpublished conditional-display paths before publishing. The draft inspector flags missing, impossible, or misordered controller questions and keeps preview answers entirely in the browser.
• Authorized owners can see an opaque review flag when the same Furries PH account submits a survey again. The flag does not reject a response, change rewards, or reveal an account identifier.

Impact

• Partners and Furries PH staff can use safe screen-out quotas for research without creating a separate survey, account, or deployment service.

Validation

• Signals Astro diagnostics and static Pages builds pass. The supporting API type-check and focused schedule/quotas certifications pass. The report-sharing contract certificate passes locally, and its isolated additive migration is applied to the production database. No direct Pages upload was used; the corresponding shared API Worker deployment and authenticated hosted checks remain required.

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

Status: Local implementation only; migration publication, production attestation/deploy-hook secrets, authenticated lifecycle checks, and Git-connected release remain required

What’s Changed

• Event managers with the dedicated permission can now open a focused Social verification workspace from Event Management and review only the requesting Social Page, the exact canonical event, partner scope, decision state, expiry, and bounded audit history.
• Approve, decline, and revoke decisions require an explicit reason and show the Page/event/partner boundary before submission. The decision does not grant Social Page roles or change canonical event data.
• The dashboard requests a fresh partner-scoped API read for the exact event, and the control plane rate-limits owner requests and converts expired requests atomically before a new request can be made.
• The workspace is a static dashboard SPA client of the existing partners-api Worker. It adds no Pages Function, new Worker, direct browser Supabase connection, or direct deployment path.
• Approval now consumes a service-only, short-lived signed proof bound to the exact Page, canonical event, current partner, issuing authority, audience, and expiry. The signed value never reaches a browser.
• Event archival or reassignment, explicit revocation, proof expiry/key retirement, and approving-authority loss invalidate the relationship automatically. A small leased outbox coalesces the resulting static main-site refreshes and invokes only the Git-connected furries.ph Pages hook.
• Native FPH CMS administrators now have a UUID-only canonical operational Event ID field. The static public event page reads the public-safe projection only while generating the page and shows a compact Partner-verified Social Event Page link only when the proof is current.

Impact

• Partner teams have a contained place to confirm whether a Social Event Page represents their event, while Social content, Page staff, analytics, credentials, and dashboard sessions remain outside this review surface.

Upgrade Notes

• Publish the reviewed database migrations and API/dashboard/CMS/main-site code through the existing Git-integrated deployment paths before use.
• Install the retained attestation key ring and real Git-connected furries.ph Pages deploy-hook URL as Worker secrets. This session could not install them because Cloudflare CLI authentication is unavailable; no secret values were created or guessed.
• Set and independently verify a real native-CMS canonical Event ID mapping, then certify issuance, revoke, reassignment, archival, expiry, key rotation, authority loss, failed-hook retry, and public static output.

Validation

• Partner Dashboard Astro diagnostics and production build pass locally. A fixture-backed browser run verifies direct SPA loading, modal approval with version/reason receipt, refreshed revocation state, desktop/mobile rendering, and no browser errors.
• The API TypeScript check and signed-proof key-rotation/replay certificate pass locally. The main-site Astro check passes with zero diagnostics. Migration apply, production secrets, full static build, and authenticated hosted checks remain open.

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

Status: Local implementation only; the migration, authenticated Page-role checks, and Git-connected Pages release remain required

What’s Changed

• A Page owner, manager, or publisher can now create, load, edit, and delete only their own drafts for that Page. Page staff do not share a draft inbox.
• Each author/Page pair has a bounded 20-draft limit and versioned saves, so an out-of-date browser cannot silently overwrite a newer draft.
• Loading a draft into the normal composer preserves its optional content warning. Publishing still creates a separate, normal Page-authored post through the existing role, link-safety, duplicate, and rate-limit path.
• Deleting a draft has an explicit confirmation. Drafts never become a public post, notification, moderation item, federation output, Page audit event, or media upload.
• Active Page owners and managers can edit only the public Page name and summary. The API records a profile-update receipt; Page address, roles, lifecycle, verification, and event links remain separate protected controls.
• An owner can separately confirm archive of an active Page. That removes it from public discovery and normal publishing while retaining post/moderation identities and audit history; restoration is intentionally not a casual browser toggle.
• Ownership succession now uses an owner invitation and recipient acceptance before a current owner can explicitly step down to manager. The database rejects an attempt that would leave the Page ownerless.
• Operational Page roles can explicitly load a bounded shared activity inbox for public reactions, replies, and quotes, with private per-staff-member read state. It excludes follows, analysts, Page staff identities, and private attendee/event information.
• The static Social SPA calls only partners-api; no Pages Function, new Worker, direct browser Supabase access, or direct deployment path was added.

Validation

• Social type checking, 20 API-client tests, production build, and whitespace validation pass locally.
• The Partners API type-check still reports two unrelated existing errors in src/routes/surveys.ts; the new Social draft route added no diagnostic. No Supabase migration, deployment, or authenticated browser action was performed.

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

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

What’s Changed

• A Page owner or appropriately scoped manager now sees a confirmation before requesting removal of an eligible Page member role.
• Page-authored timeline posts now link directly to the corresponding public Page profile without leaving the Social SPA.
• Eligible Page publishers can use the existing confirmation-based post deletion flow; the API verifies their current Page publishing role before changing post state.
• The confirmation makes clear that it removes Page access only: it does not delete the person’s Social account or the Page’s published history.
• The static Social SPA remains a client of partners-api; the API and database continue to decide role scope, append the audit receipt, and reject removal of a final active owner.

Validation

• Social type checking, 19 unit tests, production build, rendered local-shell review, and whitespace validation pass locally.
• The role-removal action was not invoked against a live account. Its unpublished migration and authenticated authorization/revocation evidence remain release gates.

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

Status: Local implementation only; migration publication, policy-owner approval, staff-dashboard integration, and authenticated checks remain required

What’s Changed

• The Social API now normalizes post-link hosts locally and checks active exact-domain or subdomain safety entries without fetching a member’s URL or generating link previews.
• The same service-only database call retains the existing duplicate-post and short posting-velocity checks, keeping the normal post flow bounded without a new Worker, Pages Function, KV, Queue, AI service, or browser Supabase access.
• The unpublished Page-post path now applies those controls to the effective Page author too, and resolves a publisher’s active Page role in one bounded lookup rather than separate Page and membership requests.
• Authorized staff have audited API controls to list, create, and retire deterministic link-safety entries. Retiring a rule preserves its actor and reason while allowing a later reviewed replacement.
• The unpublished policy migration now rejects malformed host and policy-version values and limits each privileged function to schema-qualified database access with an empty search path.

Impact

• A documented prohibited destination can be stopped before one post is published, with a member-visible correction instead of a hidden score, account sanction, or automatic subjective moderation decision.
• This is an operator control plane, not a release of an AI classifier or automatic account enforcement. It requires a named policy owner and staff dashboard before it can be used in production.

Validation

• The host-normalization test cases and Partners API TypeScript check passed locally, including case, punctuation, Unicode-host, scheme, path, credential, version, and expiry boundaries.
• The Supabase CLI could not authenticate to inspect the remote migration list in this session. No migration was published and no direct upload or deployment was performed.

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

Status: Local implementation only; migration publication and authenticated browser checks remain required

What’s Changed

• Social post authors can switch between a plain-text Markdown editor and an in-place preview without sending preview content to a server.
• The preview supports the approved extended Markdown profile, including tables, task lists, fenced code, footnotes, highlight, subscript, and superscript. Mermaid is displayed only as inert code.
• One source-owned rendering component now owns every member Markdown HTML sink. Raw HTML, Markdown image URLs, embeds, unsafe protocols, and executable diagrams remain unavailable; external links use safe browser behavior.
• Posts now have an unpublished format-version and bounded API-derived plain-text projection alongside their canonical Markdown source. Rendered HTML is never stored.

Impact

• Members can check how approved Markdown will look before publishing, while moderators and future search/notification surfaces retain source and safe text projections instead of browser-generated HTML.
• This remains a static Pages experience backed only by partners-api; no Pages Function, direct Supabase browser client, or direct upload release path was added.

Validation

• Social type checking, 18 unit tests, production build, API TypeScript, and whitespace validation passed locally.
• The schema migration is unpublished. Authenticated cross-user, profile/Page/Event Markdown, moderator rendering, and rendered browser checks remain release gates.

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

• Social now reads, requests, accepts, declines, and removes connections through the same private friend graph as Regosite. It does not copy followers, event attendance, registration details, contact details, or Social safety controls.
• Moderators now confirm a structured policy reason in the moderation dashboard before applying the first post-review actions. The dashboard remains a static Cloudflare Pages app and uses partners-api for every dynamic request.
• Both static sites carry the public https://api.furries.ph build origin in Git. This is public configuration, not a secret; releases remain Git-integrated Cloudflare Pages builds with no direct upload.
• Local type checks, tests, production builds, and a synthetic visual review pass. The canonical-friend migration and the moderation migration are still unpublished, and authenticated cross-user/end-to-end checks remain required before release.