🔺 Needs your review (1)
Large sprawling PR (146 files, ~2400 lines changed) touching almost every marketing/content page and shared component (hero sections, cases pages, homepage, footer, nav) for mobile UI fixes. No backend, auth, payments, or schema changes are involved, but the sheer breadth means a CSS/layout regression or a broken import (e.g. PullQuote component usage across dozens of files) could visually break many public-facing pages simultaneously.
- <item>146 files changed across nearly all onze-cases pages, homepage, diensten, footer, nav, and shared UI components — very wide surface area</item> <item>Repeated structural changes (hero markup, spacing, new PullQuote component, image markup) applied consistently across many pages, increasing risk of a systemic layout bug affecting the whole site</item> <item>Includes a new client-side search/filter behavior (FilterWrapper using useSearchParams) which changes interactive behavior, not just styling</item> <item>Purely front-end/UI/content changes — no auth, database, payments, infra, or security-sensitive code touched, which caps this below 'high'</item> <item>Given the scale and cross-cutting nature of the diff, visual regressions could be broad even if each individual change is low-risk, warranting careful review rather than auto-approval</item> </reasons>
Large mechanical mobile-responsiveness PR touching mostly Tailwind classes, hero section layout, and refactoring inline quote blocks into a shared PullQuote component. The diff is very large but repetitive/low-risk in nature (styling adjustments, spacing, hero restructuring). I spotted a couple of correctness concerns worth a second look, but nothing that clearly breaks functionality; flagging as warnings rather than blocking issues, with one moderate one around the mainImage duplicate-check heuristic potentially hiding legitimate images.
✅ Auto-merged (4)
Adds a new static blog/case page, a cover image asset, and a new entry in the cases data array. This is purely additive content for a marketing/blog section with no changes to existing logic, APIs, auth, or infrastructure.
- New file only (page.tsx) with no modification to existing components' behavior
- New static image asset added
- Only addition to cases.ts array (new object appended), no existing entries changed
- No touches to auth, payments, database, infra, or public API contracts
- Content is isolated to a single non-critical marketing/blog page
Mostly a static content/blog page addition with no logic risk. A couple of minor correctness issues worth noting but nothing blocking.
This PR adds a new, self-contained marketing landing page (prompt engineering training) with its own components and static data, plus minor CTA link additions on two existing marketing pages. It's new/isolated frontend content with no auth, payments, schema, infra, or shared-core logic changes, and the new page is explicitly noindexed pending marketing approval.
- All new files are scoped to a single new route and its dedicated components/data under ai-trainingen/prompt-engineering
- Changes to existing files (AiOplossingenTraining.tsx, AiTrainingenCTA.tsx) are small, additive UI link insertions, not behavior changes to critical logic
- No touches to auth, payments, database/migrations, infra/deployment config, or public API contracts
- New page is marked robots: noindex/nofollow, limiting external exposure while under review
- Large line count (1236 added) is mostly repetitive presentational JSX/data content, not complex logic
- Failure mode is limited to a single marketing page rendering incorrectly, not core app functionality
Mostly straightforward content/marketing page addition with new components and data files. No major logic bugs found; a few minor issues worth flagging (hardcoded contact info duplicated inline, `robots: { index: false }` on a real, linked-to page, and a stat-animation edge case), but nothing blocking.
This PR only swaps the default OG/share image asset used in site metadata, adding a new image file and updating a single default path constant. It affects social share previews but no business logic, auth, data, or infra.
- Change confined to a single default image path in metadata.ts
- New file is a static image asset, not code
- No changes to logic, APIs, schemas, or security-sensitive areas
- Minimal diff size (1 line changed)
Simple, low-risk change swapping the default OG/share image. The new asset is added and referenced correctly. Minor note: the filename contains parentheses and spaces-like special characters, which is generally fine in URLs but worth confirming it's properly encoded when used in meta tags; otherwise no issues found.
Adds a new, isolated marketing landing page (Prompt Engineering training) with its own components and static data files, plus minor CTA link additions on two existing marketing pages. No changes to auth, payments, DB, infra, or shared business logic; new page is explicitly noindexed while under review.
- Purely additive: new route, new components, new static content data, no deletions of existing logic (only 9 lines removed, replaced with equivalent+extra markup)
- Confined to a single Next.js app's marketing/content pages (apps/qualogy-web), no shared libraries, APIs, or infra touched
- New page is flagged with robots noindex, indicating it's a low-stakes concept page under marketing review
- Changes to existing components (AiOplossingenTraining, AiTrainingenCTA) are small, additive UI links (new CTA button/section), not altering existing behavior
- No auth, billing, migrations, secrets, or public API contracts affected
- Large line count is mostly repetitive presentational JSX and data objects, not complex logic
Overall this is a well-structured, low-risk content/landing-page addition. Data-driven components follow existing conventions, locale typing is consistent, and the new page correctly sets noindex robots for a page under review. A few minor issues worth a human glance, none blocking.
🗄️ Closed elsewhere (merged/declined outside this tool) (5)
This PR refactors job/vacancy filtering logic for the careers page (werken-bij), introducing a shared taxonomy normalization module used by both the ATS job pipeline and the Salesforce sync route, and deletes an unused duplicate filter component. It affects how interim/ATS vacancies are categorized and displayed/filterable on a public marketing page, but does not touch auth, payments, DB schema, or infra.
- Business logic change affecting job listing normalization and filtering behavior on a public-facing careers page
- Touches a Salesforce sync API route that writes to the database (data normalization for department/city/experience_level), a moderate-sized behavior change to synced data
- Large diff (226 additions, 536 deletions) mostly due to deleting a redundant component (VacanciesWithFilters.tsx) and consolidating logic into vacancy-taxonomy.ts
- No changes to authentication, payments, schema/migrations, secrets, or infra config, limiting worst-case impact to incorrect job filtering/display rather than security or data-loss issues
- Changes are confined to a single feature area (careers/vacancies) within one app, reducing cross-system blast radius
Solid refactor: extracts duplicated normalization logic into a shared vacancy-taxonomy module, applies it consistently across ATS jobs, Salesforce sync, and the werken-bij page, removes a dead/duplicate component, and improves filter counts to reflect cross-filter narrowing. No blocking issues found; a few minor points worth a look.
This PR adds a new Content-Security-Policy and other security headers globally via next.config.ts, and changes the rate-limiter API contract (limiter.check now returns an object with .success instead of a boolean) across all public-facing form/API routes (contact, apply, meeting, quote, coffee-call, ATS). If the CSP is too strict or misconfigured, it can silently break scripts, styles, images, or third-party integrations (GTM, Cookiebot, Turnstile, Supabase, Vercel Analytics) site-wide. If the rate-limiter contract change is inconsistent anywhere, requests could be incorrectly blocked or rate limiting could silently no-op, affecting all public lead-gen/application endpoints.
- Adds global security headers (CSP, HSTS, X-Frame-Options, Permissions-Policy) in next.config.ts affecting every route/page site-wide
- Changes the rate-limiter's public contract (boolean -> {success}) and updates call sites across 6+ public API routes (contact, apply/ats, apply/hardcoded, meeting, coffee-call, quote) - security-relevant logic touching abuse/spam protection
- CSP misconfiguration is a classic source of silent breakage for scripts/analytics/embeds (GTM, Cookiebot, Turnstile, YouTube, Supabase) that is easy to miss in review/testing
- Adds new third-party dependency (@vercel/speed-insights) and lockfile changes across the monorepo
- Touches multiple independent public-facing API routes simultaneously, increasing scope of potential regression
- New logging utility (logEvent) replacing console.error across routes - low risk itself but part of a broad, cross-cutting change
- Large number of files changed (27) spanning config, API routes, new package module, and binary asset updates, increasing chance of an overlooked interaction
Overall a solid, low-risk hardening PR: adds structured logging via a shared logger, CSP/security headers, and Vercel Speed Insights. One notable inconsistency in apply/ats/route.ts where the rate limiter API usage differs from all sibling routes — worth confirming createRateLimiter's actual return type before merge. A few other minor points below.
This PR only updates hardcoded href links (and matching e2e test) pointing to external SQL source files on marketing/blog case-study pages, switching from GitHub to Bitbucket URLs. No application logic, routing, or shared components are touched.
- Change is confined to static content (external link URLs) in isolated marketing pages under onze-cases", "No business logic, auth, data, or infra changes", "Includes a new e2e test verifying the links, reducing risk of typos", "Diff is small and mechanical, repeated across similar files"]}
Straightforward link migration from GitHub to Bitbucket, consistently applied across pages and backed by a new e2e test verifying rendered hrefs. Only issue found is a minor inconsistency in repo-name casing ('oracledatabase23c' vs 'OracleDatabase23c') in two files, which is unlikely to break functionality but worth confirming intentional."
Pure cleanup PR: removes unused imports/variables, simplifies two Image components to use `fill` instead of fixed width/height (same visual output), and deletes an empty temp file. No business logic, routing, or data changes.
- Only touches marketing website pages (qualogy-caribbean-web) and a leftover temp text file", "Changes are unused import removals, unused variable removals, and minor JSX restructuring with no behavioral impact", "Image component change to `fill` layout is a well-established Next.js pattern equivalent to explicit width/height with object-cover", "No changes to auth, payments, database, infra, or public API contracts", "Small, self-contained diff (47 lines added/removed) confined to presentational code</reasons>
Mostly a safe cleanup PR (removing unused imports/variables and a stray temp file), but there's one behavior-changing edit worth flagging: the two Image components switched from fixed width/height to `fill` inside a wrapper div. This is a reasonable pattern but should be verified for regressions (e.g., missing `object-cover`/aspect issues, or loss of intrinsic sizing hints for LCP). Everything else (unused `ArrowRight`/`idx`/`FadeUp`/`PRIVACY_EMAIL` removal, deleted temp file) looks like straightforward, low-risk hygiene cleanup.
This PR shows no actual file changes or diff content, suggesting it adds a Google Tag Manager container snippet to two specific modals (Meeting and Coffee Call). If implemented as described, impact would be limited to those UI components and analytics tracking, not core business logic.
- No diff content or changed files were provided, making it impossible to verify actual scope
- Title suggests a narrow, isolated change to two specific modal components
- GTM container additions are typically analytics/tracking snippets with low functional risk
- Does not appear to touch auth, payments, database, or infrastructure
- However, empty diff is unusual and warrants human verification before merging
The diff is empty (no files changed), so there is nothing to review. Cannot verify that the GTM-NN3W3TC8 container was actually added to the Meeting and Coffee Call modals. Please confirm the correct branch/commit is pushed before merging.
No inline comments.