Platform Updates

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

Status: Local integration certificate passed; Git-connected release of the schema and certificate updates remains required

What’s Changed

• Signals now has a repeatable local certificate for the full account boundary: an FPH staff member creates and publishes an FPH-owned survey, an anonymous visitor completes it, then signs in with the same Furries PH account to claim a configured digital reward.
• The certificate also verifies the owner analytics projection and removes its disposable local Auth account. Its synthetic published survey is archived so immutable version history remains intact.
• Fresh databases now give the trusted API only the read access it needs for canonical partner scope, partner labels, and account-to-reward resolution. A completion-command repair also prevents an internal SQL naming collision from blocking public survey submissions.
• Deleting an account now preserves an already-published survey version while removing its publisher reference, so historic survey content does not retain the deleted account identifier.

Validation

• A clean local Supabase reset replayed every migration. The local certificate passed FPH staff authorization, anonymous completion, sign-in reward handoff, digital reward issuance, owner analytics, and disposable-account removal. API TypeScript validation passed.

Repository: cms.furries.ph

Status: Locally validated; deployment pending

What’s Changed

• Directly authenticated Sanity Project Administrators now retain the complete Furries PH Studio workspace even when they also have a scoped editor profile.
• Partner robot sessions remain limited to their signed partner scope. Native non-administrator accounts without a recognized scope now receive no Studio content or creation templates rather than an unrestricted workspace.
• Direct Studio entry remains protected by the existing Partner-dashboard handoff; this change does not weaken the CMS access gate.
• Removed the TarsierDesk attribution badge from the Furries PH Studio interface.
• Gallery batch uploads process up to 12 image optimization and upload jobs concurrently; the progress message now makes that visible.

Impact

• Furries PH administrators can use their native Sanity account without inheriting a partner editor’s document filters, reference-picker limits, required organiser/author validation, or Studio Settings block.
• The account must be a Project Administrator for the exact Sanity identity provider used at sign-in. Accounts from different providers are distinct even when they use the same email address.

Validation

• Studio TypeScript, lint, and production-build checks, plus documentation Astro diagnostics, passed locally. Deployment remains pending.

Repositories: partners-api, partners.furries.ph

Status: Locally validated

What’s Changed

• Restored the first-time authenticator-app setup flow in Account Settings.
• The API now reads the signed-in user’s passkey inventory with the same caller JWT it uses for the enrollment request, rather than trying to load a browser-managed SDK session that does not exist in the Worker.
• Existing safety controls remain unchanged: adding a factor to an already protected account still requires a recent MFA step-up, and factor-inventory failures still fail closed.

Impact

• Signed-in users without an existing authenticator app can generate a TOTP QR code and complete setup again.
• Users with an existing TOTP or passkey cannot add another factor from an AAL1 session.

Validation

• Partner API TypeScript diagnostics and the auth-security regression certificate passed locally.

Repositories: partners.furries.ph, partners-api, fph-lan-ems, docs.furries.ph

Status: Released for Telegram and Discord; SMS remains safety-gated

What’s Changed

• Event Planning keeps operational email mandatory and can fan the same logical reminder out to a user’s explicitly enabled linked Telegram private chat or linked Discord direct-message account.
• Account Settings provides masked personal-channel readiness, verification, test, unlink, and recovery controls without exposing provider identifiers, bot credentials, message locators, or full phone numbers.
• The production database and Worker now own account-link verification, identity-version cancellation, channel-isolated retries, provider-safe message rendering, delivery history, and the SMS device queue and policy boundary.
• The Android SMS bridge has an Android 15-compatible durable service, pre-send cancellation and policy rechecks, encrypted native credentials, bounded leases, and fail-closed recovery. Event Planning SMS remains separate from attendee SMS Blasts.

Impact

• Users continue receiving mandatory email when every optional channel is unlinked, unavailable, or failing.
• Telegram and Discord require the signed-in user’s linked provider identity plus a successful private-chat or DM readiness check.
• SMS remains disabled by the production kill switch until a signed Android release, authorized physical device, verified non-roaming SIM, consented test number, and carrier canary are recorded. No paid or carrier-visible traffic was sent in this release.

Validation

• The hosted EPS migration was applied independently of unrelated pending migrations. All four service-owned tables have RLS enabled, ordinary browser roles have no access, and post-migration database advisors report no security or performance errors.
• The Worker release passed TypeScript, focused reminder, mandatory-email, bundle, OpenAPI, authorization, secret-binding, and 100% production-version checks with SMS fail-closed.
• Dashboard and Android local certificates cover exact reminder cadence, mandatory email, masked identities, link/relink/revoke, consent, cancellation, token rotation, leases, retries, cost and pacing policy, Android 15 service recovery, and unsigned release packaging. Physical-device receipt and store review remain explicit release gates for SMS.

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

Status: Preview; locally validated

What’s Changed

• Authorized partner teams can open Sanity Studio from the dashboard again without receiving a project-wide Editor credential.
• Each dashboard user and partner scope receives an expiring Sanity robot identity whose custom role is limited to that partner’s marked documents. Shared categories and tags remain reference-only, while asset access is limited to the operations needed for uploads.
• Robot credentials are encrypted at rest and delivered in a short-lived authenticated handoff bound to the launching client. The Studio keeps the credential only in the current tab and removes the handoff parameters before loading the editing interface.
• Strong issuance barriers prevent access-removal, partner-disable, rotation, and revocation races from leaving a usable robot behind. Robot and handoff expiry are also capped at the caller’s effective permission deadline.
• Furries PH administrators continue to use native Sanity authentication. The integration fails closed if Sanity custom roles are unavailable; it never falls back to a project-wide Editor token.
• Production dependency advisories were reduced to zero in the API, dashboard, and Studio trees as part of the restoration.

Impact

• Partner editors regain their familiar Studio workflow, but can read or change only content assigned to their partner scope.
• Operators must configure the API credential-encryption secret and give the Sanity management integration permission to backfill scope markers and manage custom roles and robots before rollout.
• Before deployment, operators must run the documented live canary and confirm that a partner robot cannot read, create, update, or delete another partner’s documents or alter its immutable scope marker.

Validation

• The API CMS boundary certificate passed 66 checks; the dashboard certificate passed 13 checks. TypeScript/Astro diagnostics, production builds, Cloudflare deployment dry-run, dependency audits, and desktop/mobile visual checks also passed locally. No production deployment or external robot creation was performed.

Repositories: partners.furries.ph, partners-api

Status: Preview; locally validated

What’s Changed

• EPS now creates a system-managed email destination for every person assigned to operational planning work.
• Department membership and team-lead assignments, work-item and requirement RACI assignments, approval reviews, meeting participation, risk/control ownership, watched-record updates, direct mentions, and later workflow updates now send transactional email through the existing delivery outbox.
• Work items and requirements now notify assigned people at 30 days, 28 days, 24 days, 21 days, 18 days, 14 days, 10 days, 7 days, 3 days, 36 hours, 24 hours, 12 hours, 6 hours, 3 hours, 1 hour, 30 minutes, 15 minutes, 5 minutes, and the due time. Requirements stop their sequence when submitted; work items stop when completed. Overdue work items and unsubmitted requirements then repeat every six hours until closed.
• These operational messages are not held for digests, quiet hours, or optional notification subscriptions. Standard delivery retries and audit records remain in place.

Impact

• Event teams receive the assignment and escalation information needed to act without depending on a manually configured EPS notification destination.
• Platform operators must keep the existing transactional-mail integration configured before releasing this change.

Validation

• Focused EPS communications certification, Worker TypeScript diagnostics, and migration source review were completed locally. No hosted migration or production deployment was performed.

Repositories: partners.furries.ph, partners-api

Status: Preview; locally validated

What’s Changed

• Files & Evidence now explains Public-ready, Internal, Confidential, and Restricted as distinct security levels instead of displaying classification as a label only.
• Internal files require event-plan membership and may be narrowed to selected roles or departments. Confidential files additionally require sensitive-file clearance and are encrypted before Sanity storage.
• Restricted files require sensitive-file clearance plus an explicit matching role or department policy, unless the caller is an authorized planning or platform administrator. When role and department scopes are both configured, both must match.
• All four file levels now record successful file-metadata access and downloads in the access audit trail. File controls can also grant a specific active project member by selecting their username; named access is additive, while role and department scopes still intersect.
• A named grant never bypasses project membership or sensitive-file clearance. Restricted files remain administrator-only until they have at least one valid role, department, or named-user scope.
• The same fail-closed decision now protects file lists, detail metadata, replacement versions, retention/access controls, requirement evidence, handoff exports, and downloads. Unauthorized callers receive a non-enumerating not-found response.
• Initial uploads save their role/department policy atomically. Reclassification creates a new immutable version so the stored bytes use the encryption appropriate to the new level.

Impact

• Event planners can see who may access each file and how it is protected before they upload or change it.
• Existing Restricted files with an empty or invalid policy are visible only to authorized administrators until their controls are corrected.
• No database migration is required; this uses the existing classification, access-policy, version, and encryption fields.

Validation

• Dashboard Astro diagnostics completed with 0 errors. Desktop and 390 px mobile browser QA showed all four level definitions, distinct badges, policy choices, selection-gated controls, and no console errors.
• A focused browser flow passed the four-level guide, preselection guard, and atomic Confidential upload policy. Partner API type-check plus requirement, generic-schema, and pagination/classification certificates passed.
• No hosted database or production deployment was performed.

Repository: partners.furries.ph

Status: Preview; locally validated

What’s Changed

• The Event Planning My Work page is now a personal action centre: staff can complete assigned work, request work-item review, submit written requirement responses, and attach evidence files without leaving their queue.

• Pending requirement reviews can be accepted, returned for revision, rejected, or waived directly from My Work. Every action continues to use the existing version checks, audit trail, and approval controls.

• The same queue surfaces personal RACI entries and pending event-configuration change reviews, with direct links into the corresponding governed project workspace where a broader approval context is required.

• My Work is the sole cross-event EPS surface. Every other EPS navigation target stays tied to its selected event plan.

• Work items now expose RACI details in My Work and let staff request review from a connected accountable, responsible, consulted, or informed teammate; the selected reviewer is recorded on the work item.

• My Work now includes personal Gantt and calendar views that show only staff-linked tasks, requirements, reviews, and meetings across their authorized event plans.

• My Work now presents one deadline-sorted personal action list, with filters for work type and event plan instead of separate operational queues.

• Queue rows now show a traffic-light countdown instead of due-date badges: green through amber as the deadline approaches, then red when overdue.

• The My Work action list is paired with personal Gantt and calendar cards using the same compact EPS schedule-card pattern, limited to records tied to the signed-in person.

• My Work action rows now open their submission, review, RACI, evidence, and decision context in-page before taking any governed follow-up action.

• The consolidated My Work queue now uses the same shared stacked list-card renderer as RMS Registration Configuration, keeping record layout, responsive behavior, and icon actions consistent across operational tools.

• My Work now renders its personal Gantt and calendar through the same EPS Schedule renderers, preserving Schedule’s zoomable timeline, status presentation, and agenda/day/week/month calendar controls while filtering the data to that staff member’s queue.

• My Work action rows now keep their controls aligned beside the corresponding record on desktop, and action buttons pair their Lucide icon with a readable label for clearer completion, submission, review, and RACI workflows.

• Requirement submission, review, RACI, and decision dialogs now use the dashboard’s primary button treatment for their commit action, rather than an unstyled class.

• My Work dialogs now center in the viewport, and submitted requirement reviews remain visible as direct review actions in the personal queue.

• Cancel and close controls in My Work dialogs now dismiss immediately without requiring a response, reviewer, or confirmation checkbox.

• The shared My Work list card now filters by operational status, including completed and overdue, and hides deadline badges once work is closed.

• Staff can now search the shared My Work list card across item names, event plans, work types, and statuses.

• My Work now folds a record’s linked RACI assignment into that record’s actions instead of showing a duplicate queue row.

• Department administrators can now remove a member from the member-access editor or delete a department from its edit dialog through explicit, audited confirmation actions.

• EPS task, requirement, scenario, and compliance-control edit dialogs now include a Remove action. Removal archives the record, cancels its pending reminders, and retains its audit trail.

• Department perspectives now use the records and column labels that match the selected view: people, work-item RACI accountability, and calculated capacity each have their own table. Their primary action also changes with the active perspective, so staff can add members, assign RACI, or set capacity without returning to Structure.

• Department People now resolves each member’s profile name first, then their account display name, and finally their @username; a generic placeholder is no longer shown when a usable account identity exists.

• Department People now provides a separate Edit member action. It updates the member’s department assignment, planning role, effective dates, weekly capacity, and allocation; Manage access remains dedicated to dashboard permissions.

• Department edit now accepts multiple accountable leads. EPS preserves the ordered lead list while using its first person as the primary lead in older compatible views.

• Meeting participant choices now use the resolved department member name or account display name, rather than falling back to the member’s planning role.

• Meeting tabs now use their own correctly labelled registers: upcoming and past meetings, agenda items, notes and minutes, and decisions/actions. Each non-meeting record opens a matching contextual detail view and follow-up controls.

• The operator recording a meeting decision is always available as a voter in its For, Against, and Abstain fields, including when they do not hold a department membership; all other voters must remain active department members.

Impact

• Event planners can clear routine work, upload and submit evidence, and record routine review decisions faster, while existing project permissions, version checks, audit records, file-classification controls, and review controls remain in effect.

Validation

• Astro diagnostics completed with zero errors; existing repository warnings remain unchanged.

Repository: partners.furries.ph

Status: Implemented; validated locally

What’s Changed

• The dashboard navigation is now expanded whenever a desktop page loads.
• It only collapses after clicking outside the sidebar, rather than restoring a previous collapsed state.

Impact

• Partner operators see the full global navigation immediately when opening the dashboard.

Validation

• Astro diagnostics completed with 0 errors and 0 warnings.

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

Status: Preview; locally validated

What’s Changed

• Registration sign-in credentials now remain in secure cookies; browser storage keeps only non-sensitive session metadata.
• Registration, email-action, profile-return, and payment handoff screens now treat organizer and link data as inert, validated input instead of executable markup or unrestricted destinations.
• Return paths are rechecked after URL normalization, every catalog size is escaped in registration and review markup, and feedback safety links are created only from HTTPS destinations.
• Ticket and shop-claim QR codes are generated locally in the browser, so registration references and transaction claim details are no longer sent to a third-party QR service.
• Platform roles now enforce a strict management hierarchy, and sensitive membership, credential, finance, policy, and destructive operations require a recent MFA step-up.
• Accounts that have not completed required MFA receive only the minimum setup state; partner, event, and profile data stay unavailable until the stronger session is established.
• Attendee directory results are permission-scoped and no longer expose email addresses or internal account IDs.
• Partner database connections now require verified TLS. Image uploads are capped at 10 MiB, checked for safe raster dimensions, and limited to 20 per authenticated user per hour.
• Contact submissions now use an atomic per-client limit, and feedback CSV exports neutralize spreadsheet formulas.
• Cookie-authenticated API mutations now reject untrusted origins. Adding a second TOTP or passkey factor, removing a verified factor, changing partner control-plane state, and replacing member permission grants require fresh strong authentication.
• Public feedback submissions are byte-bounded and atomically throttled before parsing. Image-upload attempts reserve quota before buffering or base64 scanning, and planning multipart uploads are rejected at the Worker boundary above 26 MiB.
• Asset webhook destinations must match an exact operator allowlist; IP literals, explicit ports, unlisted hosts, and unsafe resolved addresses fail closed.
• Browser handoff of project-wide Sanity Editor credentials has been removed. This temporary FPH-admin-only restriction is superseded by the scoped partner Studio access described above; the legacy project-wide robot tokens should still be revoked.
• Registration runtime dependencies were updated, including Astro 7, with no known production dependency advisories remaining in either affected repository.

Impact

• Attendees and partner teams receive stronger protection against credential theft, phishing redirects, stored script injection, account takeover, privilege escalation, data enumeration, third-party identifier disclosure, upload abuse, mail flooding, and malicious spreadsheet cells.
• Partner database integrations using plaintext, self-signed, or otherwise untrusted TLS certificates must move to a publicly trusted certificate chain before this API version is deployed.
• The Partner API deployment must include the configured CONTACT_RATE_LIMITER Durable Object migration; the checked-in Worker configuration applies it during deployment.
• Operators must configure AMS_WEBHOOK_ALLOWED_HOSTS with exact trusted receiver hostnames or AMS webhook delivery remains disabled.
• Partner CMS authoring now depends on deploying the tenant-scoped robot broker described above. Before rollout, review npm run cms:revoke-legacy-tokens; during rollout, run npm run cms:revoke-legacy-tokens -- --confirm with the Sanity management environment configured.

Validation

• Rego security certification covered nine attack-path regressions, local QR certification passed, production dependency audit reported 0 advisories, Astro diagnostics completed with 0 errors and 0 warnings, and the 114-page production build passed.
• Partner API certification covered the authorization, CSRF, factor lifecycle, CMS credential boundary, bounded-body, rate-limit, multipart, and webhook-destination findings. TypeScript type-check passed, production dependency audit reported 0 advisories, and the Worker deployment dry-run accepted the Durable Object binding and migration.
• The dashboard CMS boundary certification and 145-page production build passed. The CMS workspace passed TypeScript, ESLint, production build, and native-auth boundary checks without restoring browser-visible Sanity credentials. One unrelated Event Planning diagnostic remains outside this security change.