Graphify audit resolutions — alby-studio

Context

Follow-up analysis on the 3 actionable items surfaced by graphify-audit-2026-05-21. For each god-node, applies the deletion test from external/improve-codebase-architecture skill and assigns a verdict: leave-as-is / refactor-low-priority / refactor-with-scope.

Item 1 — cn() god-utility (88 edges) → LEAVE AS-IS

Source

// src/lib/utils.ts L4
import { clsx, type ClassValue } from "clsx"
import { twMerge } from "tailwind-merge"

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

Deletion test

If deleted, complexity moves into 88 places where every component manually composes twMerge(clsx(...)). Worse, not better.

Verdict

This is the canonical shadcn convention — moving off cn() means migrating off shadcn entirely. The 88 edges aren't a code smell; they're the expected shape of a design-system-driven UI.

Action

None. Awareness only: this is the largest blast radius for any future class-merging or design-system migration.

Item 2 — getVendorBySlug() (21 edges) → REFACTOR LOW PRIORITY

Source

// src/lib/services/storefront.service.ts L3
export async function getVendorBySlug(slug: string) {
  return prisma.vendorProfile.findUnique({
    where: { storeSlug: slug },
    include: { storeTheme: true },
  });
}

All 21 call sites

Plus ~10 more identical-pattern imports — all in the [slug] route tree.

Deletion test

If deleted, complexity moves into 21 places that each call prisma.vendorProfile.findUnique({ where, include }). Complexity stays the same (per file: same 3 lines of Prisma), but knowledge centralization is lost — 21 places to update if the include needs to change.

→ deepening worthwhile, but the current function IS the deepening.

Verdict

Function is correctly placed. The 21 callsites are a feature, not a bug — clear domain boundary (storefront → vendor lookup).

Lower-priority improvements (optional)

Action

• [ ] Add the VendorWithTheme typed interface (15 min) — call this Phase 4 polish not a priority blocker
• [ ] Defer middleware refactor + Redis cache until friendly-beta data shows perf characteristics

Item 3 — authOptions (30 edges) → DOCUMENTED MIGRATION SCOPE

Source

// src/lib/auth.ts L8
export const authOptions: NextAuthOptions = {
  adapter: PrismaAdapter(prisma),
  session: { strategy: "jwt", maxAge: 30 * 24 * 60 * 60 },
  providers: [CredentialsProvider({...}), GoogleProvider({...})],
  // ...
}

Call site breakdown

Affected file categories

• 13 onboarding routes (/api/onboarding/*)
• 12 vendor routes (/api/vendor/*)
• 1 NextAuth catch-all (/api/auth/[...nextauth]/route.ts)
• ~4 store/storefront routes

Migration scope: alby-studio → Aspire Hub OIDC SSO

Pre-conditions:

• Aspire Hub OIDC IdP is LIVE (confirmed per aspire-hub)
• smart-dashboard already migrated as the SSO pilot (2026-05-12, per MEMORY.md)
• alby-studio merchants are NOT Aspire Hub users (different audience — merchants vs staff). So this migration applies to admin/staff routes only, NOT to vendor login.

Implication: TWO auth surfaces, not one

This is a critical finding for the migration plan:

• Vendor / merchant login → STAYS on NextAuth + CredentialsProvider (these users aren't in Aspire Hub)
• Admin / staff console (the deferred /admin UI from _STATUS.md) → SHOULD use Aspire Hub OIDC from day 1, not NextAuth

So the 29 getServerSession(authOptions) calls in /api/onboarding/* and /api/vendor/* correctly belong to the merchant auth surface and don't need migration. Only the future /api/admin/* routes (currently non-existent) should adopt the Hub OIDC pattern.

Verdict

No migration scope for existing routes. The 30-edge blast radius is a non-issue — it correctly serves the merchant audience. The migration concern was misplaced.

Action

• [ ] When /admin UI is built (currently in _STATUS.md post-launch deferred list), wire it to Aspire Hub OIDC via the staff-portal helpers, NOT via the existing authOptions.
• [ ] Add a comment to src/lib/auth.ts noting: "This is the MERCHANT auth surface (NextAuth + Credentials/Google). Admin/staff routes use Aspire Hub OIDC — see aspire-hub."

Combined action list (from this audit)

Open production-gating items (from _STATUS.md, not this audit)

Related

• graphify-audit-2026-05-21 — the audit that surfaced these items
• aspire-hub — OIDC IdP target for future /admin routes
• external/improve-codebase-architecture skill — the deletion test methodology used here

🔗 Relationships