Prod Release 21 Aug

Production Release Notes, 2026-08-21

Scope: production-branch deployments across Genesis Technologies LLC repos for today’s migration window, Friday 2026-08-21, roughly 06:26 to 06:51 UTC (12:11 to 12:36 NPT). Four repos migrated.

Production was last on the 2026-08-17 morning release. Today’s cut promotes two staging cuts at once: the 2026-08-17 afternoon cut and the 2026-08-19 cut. Stage had been sitting two cuts ahead of prod since Wednesday, so everything that accumulated on stage and staging across both windows lands in production together.

Dominant theme is EVO-4520, social metrics integrity, spanning genesis-web and artistevolve-fe. It is the single largest change in this cut by an order of magnitude, it replaces two monolithic daily crons with eight staggered ones, and it carries a five-script repair migration sequence that is still unrun on both stage and prod. Second theme is the single dashboard shell refactor in artistevolve-fe, a structural change touching every logged-in route. Also in this cut: the unified overdue-task definition, archived status for subscription invites and promos, Firebase credentials finally reaching the runtime, and the Arti clarify-first fix for vague task requests.

Repo	Role	Release	Prod merge	Previous prod
genesis-web	Web / API	4.20.0	stage to main (#1037)	4.19.0 (2026-08-17)
artistevolve-fe	FE / App	4.13.1	stage to main (#740)	4.13.0 (2026-08-17)
artist-admin	Admin API (BE)	1.14.0	stage to main (#117)	1.13.0 (2026-08-17)
genesis-train	Agent / ML	no semver	staging to main (#184)	#180 (2026-08-17)

Repos not in this production cut.

fe-artistevolve-admin: main still on 1.15.0 from the 08-17 release. stage is unchanged, develop is ahead at 1.15.1-dev.2 and has not been cut to stage.

genesis-aws-services: prod still on #109 from 08-17. staging tip is still the 08-17 prod sync-back.

ArtistEvolve (mobile): main last moved 2026-07-31. Active work sits on develop, no stage or prod track.

ae-infra: last commit 2026-07-23, no release track.

Dormant as tracked in prior cuts: genesis-ui, genesis-admin, g-ui, cm-scout.

Version bumps. genesis-web takes the minor it had been carrying on the release-candidate line, 4.19.0 to 4.20.0. artistevolve-fe takes a patch, 4.13.0 to 4.13.1, since every PR in it is a fix. artist-admin takes a minor, 1.13.0 to 1.14.0. genesis-train has no semver and promotes by merge.

Action required

packages/server/scripts/migrations/EVO-4520_SOCIAL_MIGRATIONS_RUNBOOK.md on main still reads “executed on dev 2026-08-17. Stage and prod pending.” The code shipped to production today. The repairs did not.

Nothing in the branch requires a migration to deploy. All six scripts repair history, and the code is forward-compatible by construction: accountScopeFilter matches openId OR null, so legacy unlabelled rows stay visible. The consequence of not running them is that the historical damage stays visible in production, not that the deploy breaks.

Run from packages/server. Dry run is the default and writes nothing:

bash

MONGO_URL="<connection string>" ./scripts/migrations/run-social-migrations.sh stage

Then execute (the runner asks you to type the environment name back):

bash

MONGO_URL="<connection string>" ./scripts/migrations/run-social-migrations.sh stage --execute

Run order is automatic: 1, 4, 6, 3, 5.

#	Script	Effect	Scope measured on prod 2026-08-17
1	`2026-08-17-null-tiktok-seed-deltas.js`	Deletes day-one lifetime totals stored as daily deltas	60 rows
4	`2026-08-17-delete-impossible-engagement-rates.js`	Deletes rows above 100 percent	1,534 rows
6	`2026-08-17-clear-unexplained-negative-deltas.js`	Deletes negatives no gauge movement explains	13 rows
3	`2026-08-17-backfill-metricpoint-openid.js`	Writes `meta.openId` onto legacy rows	70,945 rows
5	`2026-08-17-restore-wrongly-deleted-posts.js`	Mutates posts still live on the platform	4,308 candidates

2026-08-16-repair-tiktok-partial-scope.js (migration 2) is deliberately not in the sequence. Production measured 0 rows. Run it separately only if partial-scope TikTok records appear later.

Three things need a human, not just a green run:

Check the database name on the first line of output. Every script connects with dbName = MONGO_DB, or test if unset. It does not use the database in the MONGO_URL path. A wrong name means 0 rows against an empty database, which looks exactly like a clean no-op. Each script prints host=... db=... before doing anything.
Migration 3 is a gate. The runner pauses after it. Read the unlabelled remain lines. Do not drop null from accountScopeFilter until those counts are 0. Reversing that order blanks analytics for the majority of users, which is an outage, not a cleanup. A non-zero count is not automatically a failure: the script skips any (user, platform) pair it cannot resolve unambiguously and names it. Those need a decision, not a re-run.
Migration 5 skips on purpose. It makes live TikTok and Instagram API calls, is rate limited in practice, and restores only on positive proof the media is live. Anything inconclusive (rate limit, expired token, 5xx, incomplete listing) leaves the whole user untouched. On the stage dry run, 26 of 73 users were skipped for incomplete listings. That is the guard working. Consider running per user with RESTORE_USER_ID=<userId>.

Rollback. Every migration writes a rollback file to packages/server/migration-backups/ before touching anything. That directory is gitignored and holds real user ObjectIds, so keep the files locally. They are the only copy of what a destructive run removed. Filenames are timestamped but, apart from migration 5, do not name the environment, so note which run produced which file.

Log the run in the release log tracker and tick the rows in the runbook.

2. Brand Hub backfill, carried over from the 08-17 release and still unrun

packages/server/scripts/MIGRATIONS.md on main still records the EVO-4364 Brand Hub seed backfill as Dev only (2026-08-11, processed=22 seeded=22). Staging and Production rows are both still unchecked, four days after the feature reached production. Any user who completed Buzz before Brand Hub shipped still has no brand documents in prod.

bash

FORCE_PRODUCTION=true EXECUTE_MIGRATION=true NODE_ENV=prod node scripts/migrations/2026-08-10-backfill-brand-hub.js

Idempotent, safe to re-run, dry run is the default. Confirm the staging run happens first, then fill in both rows.

3. Firebase service account must be present in the production environment

genesis-web’s deploy pipeline now pulls firebase-service-account.json from s3://genesis-backend-resources/env-variables/ and copies it into the container at conf/firebase-service-account.json. Two things have to be true in prod or push notifications stay silently dead while the deploy and health check both pass:

The object exists at that S3 path and is a valid service account. The workflow validates this with jq and fails the deploy if not, so a missing object is loud.
.env.prod in S3 contains FIREBASE_SERVICE_ACCOUNT_PATH = conf/firebase-service-account.json, or the _BASE64 variant. The workflow only warns on this one, it does not fail. Check the prod deploy log for the warning line and for the Service account valid from S3 line with the resolved project_id.

One shared S3 object serves all three environments, all pointing at the same genesis-evolve Firebase project.

4. Repository hygiene on genesis-web, cleanup PR needed

Commit eeb522a7 swept 33 unrelated local files onto develop, then stage, and they are now on main. Nothing is broken by them, but they should not be sitting in the production branch.

24 migration backup JSON files, at repo root and in packages/server/. Four of them, backup-google-users-isverified-*.json, contain 84 real user records as _id plus email pairs, including internal and external addresses. .gitignore covers migration-backups/ only, so files written to the repo root and to packages/server/ were never caught.
PR_DESCRIPTION.md, a stale local scratch file describing EVO-4247 (mobile Google sign-in), unrelated to the change it rode in on.
8 documentation files: the Buzz Score doc set (docs/buzz-score-technical-documentation.md, docs/architecture/buzz-score-*.md, docs/proposals/buzz-score-*.md) and docs/INSTAGRAM_API_V20_TO_V25_MIGRATION.md. Legitimate documents, but not meant to land in that PR.

Recommended: one cleanup PR that deletes the 24 backup files and PR_DESCRIPTION.md, extends .gitignore to backup-*.json at any depth, and keeps or intentionally re-lands the docs. Since the backups carry user emails, treat the deletion as a normal removal on develop, and decide separately whether history rewriting is warranted given the repo is private.

genesis-web, 4.20.0 (Web / API, new since 4.19.0)

Minor release. Promoted stage to main (#1037), carrying both the 08-17 and the 08-19 staging cuts. 153 files changed, roughly 23,900 insertions against 7,500 deletions.

Features

[EVO-4517] Notifications: GET /notifications now returns unreadCount alongside the notification list, so clients no longer have to count client side. Additive change to the response shape, existing consumers are unaffected. Swagger documented for the list and mark-as-read endpoints. (#1032)

Changes

[EVO-4520] Social: Split social crons, scope metrics by account, add per-post history. The single largest change in this cut, covering four related problems. (#1029)

Root cause it fixes. TikTokDailyScheduler (3,092 lines) and InstagramDailyScheduler (3,689 lines) each ran four unrelated concerns inside one try-block per user, once a day at 21:15 UTC, and could not distinguish “the API failed” from “the data is zero”. The failure was written into the database as fact. Observed on stage: 511 TikTok posts across 7 users wiped in a 3 minute window on 2026-08-10, 378 Instagram posts across 14 users on 2026-07-08, and negative values such as Views: -2530 on analytics cards. One /v2/video/list/ failure also corrupted account metrics, because they shared the try-block.

Data integrity.

Fail-closed deletion detection. fetchTikTokVideosWithMetrics now reports whether the video list is complete. A non-OK response or hitting the page cap returns complete: false and deletion detection is skipped for that run. Stale post state is recoverable, mass-deleted post state is not.
Two-way door. A video present in the live list restores its post from deleted_on_platform back to published. Previously only the no-videoId-match path could restore, so posts matched by videoId kept receiving fresh metrics forever while staying invisible to top-content queries.
Negative delta rejection. :AllTime counters are cumulative and cannot decrease, so a drop means bad input. Both the delta and the collapsed gauge are dropped and the prior gauge retained, letting the next good reading produce the correct difference. Applies to the day-over-day and gap paths.
Account sums are published from complete lists only, so a partial list is never written as an account total.
Instagram existence check is now tri-state. verifyMediaExists returns null when it cannot determine existence. Only Meta error code 100 classified PERMANENT counts as deleted. Rate limits, expired tokens and 5xx no longer read as “post is gone”.
Summed event metrics are floored at zero on read, and gauge classification is corrected (TikTok Engagement Rate and Total* are gauges, plus the Instagram engagement rate calculation).

Cron split. Two monolithic daily schedulers become eight staggered, tiered crons:

Cron	Schedule (UTC)	Cadence
`tiktok-metrics`	`10 /6 * *`	6h
`instagram-metrics`	`20 /6 * *`	6h
`tiktok-posts-sync`	`40 /3 * *`	3h
`instagram-posts-sync`	`50 /6 * *`	6h
`tiktok-posts-reconcile`	`15 21 * * *`	daily, destructive
`instagram-posts-reconcile`	`35 21 * * *`	daily, destructive
`tiktok-engagement-notify`	`0 22 * * *`	daily
`instagram-engagement-notify`	`20 22 * * *`	daily

There is still exactly one implementation of executeJob per platform. Subclasses only select concerns via runsConcern(), so this is a structural move with no duplicated collection logic, and constructing a scheduler without options keeps the original all-concerns behaviour.

Instagram post-sync is 6h rather than 3h because measured stage load is 119 linked users times roughly 26 API calls, about 3,094 calls and roughly 52 minutes per run. TikTok is about ten times cheaper at 304 calls. Reconcile runs after the last sync of the day, notify runs last. Sub-daily runs do not create extra data points: normalizeDate() floors to UTC midnight and bulkUpsertPoints is delete-then-insert on (user, platform, metric, date), so a 6h cadence overwrites the same day’s point four times and daily granularity is preserved. Delta recomputation is idempotent, verified with a 31 day replay harness.

Per-account scoping. Writes always stamped meta.openId, but no read path passed it, so every analytics query matched all accounts a user had ever connected. Reproduced on dev: a previous TikTok account had 11 followers, the new one 2, and /analytics/latest returned 11, a number belonging to neither. resolveActiveOpenId() now resolves the connected account from socials.userDetails.openId, the same field both schedulers write from, and is threaded through getTimeSeries, getLatestMetrics, getDemographics, getAvailableMetrics, the four analytics controllers, the TikTok and Instagram overview and chart helpers, the weekly digest getWeekInTrends, the smart rollup, and Instagram badge eligibility. New shared helper utils/socialAccountScope.js. Backward compatible by construction: accountScopeFilter matches openId OR null, so legacy rows stay visible and a user with no linked account reads unscoped exactly as before. This is what migration 3 backfills.

Spotify is deliberately unscoped. All 56,710 Spotify metric points are unlabelled because Chartmetric and Songstats use app-level keys, so there is no per-user account to switch between.

Per-post history. New PostMetricPoint timeseries model, with the granularity fixed so it is actually stored as a timeseries. TikTok no longer writes fabricated zeros into per-post history.

TikTok partial scope. TikTok rejects the entire /v2/user/info/ request with 401 scope_not_authorized if any requested field falls outside granted scopes, so a user who declined user.info.stats also lost display_name. Fixed forward in tiktokService.js, and the overview response now carries insightsAvailable and metricsUnavailableReason, which is what the artistevolve-fe reconnect banner keys off. Connect now records declined scopes into missingPermissions instead of only pulling re-granted ones.

Also in this PR: 26 extracted modules under services/cron/social/, three consolidated design docs, the five repair migrations plus the gated runner, and a batch of extraction regressions caught in review.

Fixes

[EVO-4329] Insights: Align task counts with the tasks page by excluding tasks in archived projects. Adds a shared getArchivedProjectIds helper and applies the same filter across taskService, carouselInsightsService and OverdueTaskScheduler, so the carousel, the tasks page and the overdue cron all agree. (#1030)
[EVO-4370] Tasks: Unify the overdue definition so notifications match the Tasks page. (#1034)

Five surfaces each carried their own inline notion of “overdue” and “done”, which drifted. The visible symptom was an empty Overdue bucket on the Tasks page that still triggered an overdue notification.

New canonical module packages/server/helpers/taskState.js supplies one set of predicates: dayBounds(), openTaskFilter(), overdueFilter(), todayFilter(), upcomingFilter() and buildScopedTaskQuery(). Day boundaries resolve through CalendarSettings.ianaTimeZone, so a task’s bucket is computed in the user’s calendar timezone rather than UTC. A task counts as open unless completed === true or status === 'COMPLETED'. Due date reads from dueDate, with endDate kept in sync by the Task pre-save hook.

Rewired onto the shared predicates: the OverdueTaskScheduler cron, taskService bucket grouping, carouselInsightsService, the weekly digest getOverdueTasks and getUpcomingTasks aggregators, and the notification controller test endpoints. Net effect is a large deletion of duplicated date logic, 473 lines added against 386 removed across 8 files, with a new 164-line test file covering the predicates.

Infrastructure

[EVO-000] Deploy: Firebase Admin credentials delivered through S3 and baked into the image. (eeb522a7, 5aa290d4)

The service account JSON is gitignored (*firebase-service-account*.json), so it was never in the checkout and the multi-device push work shipped in 4.19.0 (EVO-4433) had no credentials at runtime. getFirebaseApp() returns null when the key is absent, which only logs a warning and skips push, so both the deploy and the health check passed with FCM effectively off. This is the first production cut where push can actually work.
- .github/workflows/deploy.yml downloads firebase-service-account.json from s3://genesis-backend-resources/env-variables/ next to the existing env-file fetch, validates it with jq on type === "service_account", private_key and client_email, and fails the deploy rather than deferring the failure to runtime. It logs the resolved project_id and client_email, and warns when the env file has no FIREBASE_SERVICE_ACCOUNT_PATH or FIREBASE_SERVICE_ACCOUNT_BASE64.
- Dockerfile copies the file to ./conf/firebase-service-account.json, where FIREBASE_SERVICE_ACCOUNT_PATH resolves relative to the process working directory.
- Dockerfile.pr copies it optionally via a trailing glob, because ae-infra’s PR-preview workflow fetches only .env.dev and a preview must still build without Firebase credentials.
See action-required item 4 regarding the 33 unrelated files that rode in on the same commit.

artistevolve-fe, 4.13.1 (FE / App, new since 4.13.0)

Patch release. Four PRs, all fixes, no features. Promoted stage to main (#740), carrying both the 08-17 and the 08-19 staging cuts. 39 files changed.

Fixes

[EVO-4311, EVO-4315] Layout: Stop the full app remount when leaving Content Studio and Idea Center. (#737)

Navigating out of /content-publish/* or /ideation blanked the viewport and rebuilt the sidebar, top nav, chat button, user profile and timezone sync from scratch. It looked like a browser reload but was a React layout-tree remount: app/ held three sibling shells ((dashboard), content-publish, and ideation with no layout at all) that shared nothing but the root layout, so React tore one down and mounted the other on any cross-boundary navigation. Dashboard to Calendar to Tasks stayed smooth precisely because those routes all lived under one shell.

The three shells collapse into a single persistent app/(dashboard)/layout.tsx with a chrome-mode switch: default renders sidebar plus top nav, notification defers to the nested notification-center layout, and fullbleed renders children only, for Idea Center, which keeps its own sidebar and Konva canvas. 18 files move into the route group as tracked renames, app/content-publish/layout.tsx is deleted, and no public URLs change, since route groups are stripped from output paths. Per-family <main> classes, overflow variants and React key semantics are all reproduced exactly so nothing newly remounts.

Two fixes surfaced by the restructure ride along:
- SubscriptionGuard no longer blanks on remount. useSubscriptionEnabled({ refreshOnMount: true }) started isMountRefreshPending at true on every fresh mount and then re-raised it in the mount effect, so the guard returned a full-screen loader until GET /feature-flags/evaluate round-tripped. The guard now uses a resolved-once latch mirroring the one RouteGuard already had, held in the new lib/utils/subscriptionGate.ts and reset at all five queryClient.clear() session boundaries in lib/hooks/mutations/useAuthMutations.ts. Resetting at session teardown rather than on unmount matters: logout is a soft navigation, so module state survives while the React Query caches do not, and a stale latch would let gated content render before the plan had loaded.
- Secondary sidebar collapse state. The persistent shell exposed two latent defects in SidebarNav, both showing up as a collapsed side panel when entering Content Studio or Project/Tasks from Home or Idea Center. The sync effect never ran on mount because its ref was seeded with the current value, and the expand branch checked userHasToggledSidebar while the collapse branch did not, turning a single manual toggle into a permanent one-way ratchet. Remounts used to mask both by re-deriving state. Manual toggles still persist within a section.
Also documented: docs/Single-Dashboard-Shell-Refactor.md (new) and an addendum to docs/Nextjs-RSC-Txt-Navigation-Fix.md. Both record an nginx .txt guard that was prototyped and then reverted, since a 404 and a 200 serving index.html hit the same doMpaNavigation() branch in Next’s fetch-server-response.js, so it prevented no reloads.
[EVO-4520] Social: Show the reconnect banner when the TikTok analytics scope is declined. TikTok lets users decline “Read your profile engagement statistics” (user.info.stats) while still connecting successfully, after which every account tile renders “–”, indistinguishable from a broken integration with no way to fix it. The banner and its hook already existed but AnalyticsSection gated them on selectedPlatform === 'instagram', discarding the backend’s permission_denied. Now gated on Instagram or TikTok, Spotify stays excluded since it has no per-user consent screen. Banner copy is platform aware, so each platform names its own scope, affected metrics and button label. handleReconnectInstagram becomes a platform-aware handleReconnect: Instagram builds its OAuth URL client side, TikTok gets its URL from the backend and needs the full PKCE flow (patch redirect_uri=undefined, stash tiktok_code_verifier in sessionStorage, append the challenge). Adds an isReconnecting flag so the button reads “Redirecting…” rather than looking inert. Paired with genesis-web #1029, which supplies insightsAvailable and metricsUnavailableReason. Both are in this cut. (#732)
[EVO-4472] Auth: Redeem the invite code on Google sign-in for existing users. The backend attaches a forwarded ?inviteCode= only on brand-new Google signups, so returning users took the existing-user branch and the code was silently discarded, then cleared from sessionStorage. Email login already worked because the login mutation leaves the pending code in place for AuthSessionHandler to redeem via /invite/apply, but Google never reaches that handler since /auth/google/callback is auth excluded and redirects straight to a non-auth route. The callback now redeems explicitly, after tokens are stored and before the code is cleared. New users are unaffected, the backend rejects a second redeem of the same invite by the same user, and failures are swallowed so the subscription picker still retries via its ?inviteCode= fallback. Also widens the AuthSessionHandler capture to all auth entry paths, since /auth redirects to /auth/login without preserving the query string and invite links pointed at bare /auth lost the code before login could read it. Follow-up to #727 in the 08-15 cut. (#733)
[EVO-4383] Analytics: Use hasEnoughData for the metric dialog empty state, so a metric with no measurements reads as such rather than as a failed fetch. Also carries [EVO-4328] follower growth label spacing and [EVO-4275] badge name label on the task completion and followers gained carousel cards. (#735)

artist-admin, 1.14.0 (Admin API / BE, new since 1.13.0)

Minor release. One feature. Promoted stage to main (#117). 15 files changed.

Features

[EVO-4314] Subscriptions: Add an archived status to subscription invites and promos, a third lifecycle state alongside active and inactive. Codes that expire or exhaust their redeem limit are archived automatically, and admins can archive one by hand. Archived codes behave like inactive and can no longer be redeemed. (#112)
- genesis-web gates redemption on isActive alone and knows nothing about status, so every non-active status also forces isActive: false. That invariant is what makes archiving effective with no Client BE change required.
- Shared CodeStatus enum (active / inactive / archived) plus status and archivedAt on both schemas, indexed on {status, createdAt}.
- Shared archive sweep that counts redemptions live via $lookup rather than trusting the stored redeemCount, which drifts because only the Client BE’s subscription.created webhook increments it. Runs on a daily UTC cron and on every read, so the admin table never shows a stale active row.
- Backfills status on documents written before the field existed, without which a status filter would match zero legacy rows.
- status filtering on both paginated list endpoints. The legacy isActive flag still works and is ignored when status is also sent.
- Archive and unarchive endpoints for both resources, plus bulk archive by campaign for invites. Unarchive restores to inactive, never straight to active, so the next sweep does not immediately re-archive it.
- Rejects reactivating an archived code via a bare isActive: true, and skips archived invites during a campaign-wide activate, so a stale client cannot put a spent code back into circulation.
- Includes two follow-up fixes found after the original commit:
  - In an aggregation $expr a missing field resolves to undefined, and BSON sorts undefined below every date, so $lt: ['$validUntil', now] returned true for documents with no validUntil key at all and the guarding $ne: ['$validUntil', null] did too. A capped code with zero redemptions and no validUntil was therefore archived on the first sweep, permanently blocking redemptions that should have gone through. Both operands are now normalised with $ifNull, verified across a 9-case matrix.
  - PATCH with an explicit status skipped the archived guard entirely, so PATCH {"status":"active"} silently resurrected an archived code, contradicting the Swagger text saying unarchive is the only way back. Both services now reject moving an archived code out of archived while still allowing the idempotent no-op. Separately, assertPromoExistsIfProvided read promo.status without sweeping first, so an expired or fully-redeemed promo stayed linkable to brand new invites until its own endpoint or the midnight cron happened to touch it.
- Swagger updated with the new statuses, filters and failure modes.

genesis-train, production (Agent / ML, new since the 2026-08-17 `main` merge #180)

Staging to main promotion (#184), no semver. One fix. 6 files changed.

Fixes

[EVO-4496] Chat: Skip the confirm chip when the generate_tasks intent is CLARIFY. (#181)

A vague ask such as “make some tasks” interrupted with a confirmation chip before intent classification ran, then emitted an empty task_proposal once the user hit Confirm, leaving Arti announcing suggestions that did not exist.

generate_tasks_request_is_underspecified() in task_create_router.py now pre-checks the request for a topic marker, project referent or “remind me to” phrasing. Underspecified requests classify first: a new prepare_generate_tasks_intent graph node stamps the intent, and route_after_generate_tasks_prepare sends CLARIFY back to the agent with an instruction to ask what the tasks are for, with no chip shown and no false claim that tasks were created. Specified asks such as “create tasks for my album” skip the pre-check entirely, so the chip stays instant for them.

A separate guard covers the empty-result case: when the tool returns zero task cards, the prompt note now tells the model not to say suggestions are ready to review. 160 lines of new unit tests across test_chat_tools.py and test_task_create_router.py.

Cross-cutting notes (post-deploy verification)

Social metrics integrity (EVO-4520), the headline of this cut, spanning genesis-web (#1029) and artistevolve-fe (#732), with five database migrations attached and unrun. Treat this as the main verification target and give it the bulk of the window.
- Crons. Confirm all eight new crons register in prod and that the two old daily schedulers no longer run. Check the staggered offsets fire as scheduled, that no run overlaps its own next tick (particularly instagram-posts-sync, roughly 52 minutes on stage load and prod is larger), and that a full 24h cycle completes without a job being skipped by overlap protection.
- Fail-closed behaviour. The point of this change is that a failed API call writes nothing. Verify that a /v2/video/list/ failure results in no posts flipping to deleted_on_platform and no account total written from a partial list. Watch for any repeat of the 08-10 pattern, a burst of deletions inside a few minutes.
- Restore path. Confirm a post currently marked deleted_on_platform whose video is live comes back to published and reappears in top-content queries.
- Deltas and gauges. No negative values on any analytics card. Confirm Engagement Rate above 100 percent is gone once migration 4 runs, and that null-valued Engagement Rate rows are unchanged, since those mean “no measurement”, not zero. If that null count drops, something is wrong.
- Per-account scoping. For a user with more than one linked account on a platform, confirm analytics, the social overview, the weekly digest, the smart rollup and Instagram badge eligibility all read the active account only. The weekly digest one matters most: a wrong follower trend there leaves the product in an email.
- Per-post history. Confirm postmetricpoints is created as a timeseries collection in prod and that TikTok is not writing zero rows for posts it has no data for.
- Migrations. See action-required item 1. Dry run first, read the db= line, then execute. Migration 3 is a gate. Expect migration 5 to skip a meaningful share of users. Keep the rollback files.
TikTok partial-scope reconnect (EVO-4520), genesis-web (#1029, insightsAvailable and metricsUnavailableReason on the overview) and artistevolve-fe (#732, the banner). Both halves are in this cut, so the banner is live rather than inert. Verify with a TikTok account that declined user.info.stats: the banner appears rather than tiles rendering “–”, the copy names TikTok’s own scope and metrics rather than Instagram’s toggle, the button reads “Redirecting…” during the round trip, and the PKCE reconnect completes so tiktok_code_verifier survives to the callback. Confirm Instagram’s existing banner still behaves and that Spotify never shows one.
App shell navigation (EVO-4311, EVO-4315), artistevolve-fe only (#737). A structural refactor touching every logged-in route, so it deserves the widest sweep after EVO-4520. Navigate in both directions between Home, Calendar, Tasks, Buzz Factory, Social, Settings, Notification Center, every Content Studio route and Idea Center, and confirm no blank frame or full-screen loader appears on any transition. Confirm all URLs are unchanged and that a hard refresh on a deep content-publish or ideation URL still resolves. Confirm the secondary side panel is expanded when entering Content Studio or Project/Tasks from Home or from Idea Center, and that a manual collapse still sticks within a section. Then log out and log back in within the same tab and confirm the subscription gate still blocks correctly rather than flashing gated content. Content Studio pages lay out as a flex column, so watch for reflow there specifically.
Overdue tasks (EVO-4370), genesis-web only (#1034). Set a user’s calendar timezone well away from UTC, place tasks either side of their local midnight, and confirm the Tasks page grouping, the carousel cards, the weekly digest and the overdue notification cron all agree on which bucket each task falls in. The specific regression to reproduce: an empty Overdue bucket on the Tasks page must not send an overdue notification. Check the completed-task edge too, both completed: true and status: COMPLETED must read as done everywhere.
Firebase credentials and push (EVO-000 in this cut, plus EVO-4433 from 4.19.0), genesis-web only. This is the first production cut where push can actually work, so treat it as a fresh feature test rather than a regression check. Watch the prod deploy log for the Service account valid from S3 line and the resolved project_id, and specifically look for the FIREBASE_SERVICE_ACCOUNT_PATH warning, which does not fail the build. Then exercise the push test endpoint against a user with more than one registered device and confirm delivery to all of them, that preferences are respected, and that tokens are cleaned up on soft delete.
Insights task counts (EVO-4329), genesis-web only (#1030). Verify the carousel task count, the tasks page and the overdue task cron all agree for a user with archived projects, and that filtering to a specific project still includes its tasks whether or not the project is archived.
Notifications unread count (EVO-4517), genesis-web only (#1032), no FE consumer in this cut. Verify unreadCount on GET /notifications matches the actual unread total, updates after mark-as-read, and that the additive response shape breaks nothing on the current app build.
Google sign-in invite redemption (EVO-4472), artistevolve-fe only (#733). Verify an existing user opening a cohort invite link and signing in with Google lands with the invite redeemed and does not end up at catalog price. Check the bare /auth entry path preserves the code through the redirect to /auth/login. Confirm a brand-new Google signup is unaffected and that the double-redeem rejection is silent rather than surfacing an error.
Archived invite and promo codes (EVO-4314), artist-admin only (#112). Verify an expired code and a redeem-limit-exhausted code both archive on the daily sweep and on read, that an archived code cannot be redeemed on the client side (this depends on the isActive: false invariant, so test the actual redemption, not just the admin table), that unarchive lands on inactive rather than active, and that the status filter returns legacy rows correctly after the backfill. Two specific re-checks: a code with no validUntil at all must not be archived by the sweep, and PATCH {"status":"active"} on an archived code must return 400.
Vague task requests (EVO-4496), genesis-train only (#181). Ask Arti “make some tasks” with no context and confirm it asks what the tasks are for, with no confirmation chip and no claim that tasks were created. Then ask “create tasks for my album release” and confirm the chip appears immediately and the flow completes as before. Also try “remind me to call the label” and “add this to my tasks” following an earlier message, both should be treated as specified and skip the pre-check.
Brand Hub (EVO-4361, EVO-4364), shipped in the 08-17 production cut and still without its backfill. Not new code today, but the outstanding item rides into this window. See action-required item 2.

Production Release Notes, 2026-08-21

Action required

1. EVO-4520 social repair migrations, still pending on stage and prod

2. Brand Hub backfill, carried over from the 08-17 release and still unrun

3. Firebase service account must be present in the production environment

4. Repository hygiene on genesis-web, cleanup PR needed

genesis-web, 4.20.0 (Web / API, new since 4.19.0)

Features

Changes

Fixes

Infrastructure

artistevolve-fe, 4.13.1 (FE / App, new since 4.13.0)

Fixes

artist-admin, 1.14.0 (Admin API / BE, new since 1.13.0)

Features

genesis-train, production (Agent / ML, new since the 2026-08-17 main merge #180)

Fixes

Cross-cutting notes (post-deploy verification)

genesis-train, production (Agent / ML, new since the 2026-08-17 `main` merge #180)