Do SikiandClaude Sonnet 5
d2f960207e
CI Pipeline with Test Management / 🧪 Run Tests & Generate Reports (push) Canceled after 0s
Test Reporting & Gherkin Analysis / 🧪 Run Tests & Generate Reports (push) Canceled after 0s
CI Pipeline with Test Management / 🐳 Docker Integration Tests (push) Canceled after 0s
CI Pipeline with Test Management / 🏗️ Build Docker Image (push) Canceled after 0s
CI Pipeline with Test Management / 📊 Generate Test Summary (push) Canceled after 0s
Test Reporting & Gherkin Analysis / 📊 Analyze Test Coverage (push) Canceled after 0s
Test Reporting & Gherkin Analysis / 🔄 Sync with Linear (push) Canceled after 0s
Test Reporting & Gherkin Analysis / ⚡ Performance Monitoring (push) Canceled after 0s
/api/contact used to write straight to a raw, Payload-external MongoDB
collection (contact_submissions, via proto/src/lib/mongodb.ts's
getCollection) — the client had no way to see incoming messages except
by reading the database directly. Rate limiting, length caps, email
validation, and spam-keyword filtering all stay on the route exactly
as before; only the persistence target changed.
New: src/collections/ContactSubmissions.ts (name, email, subject,
message, gdprConsent checkbox, status select defaulting to "new").
Deliberately no custom `access` block — Payload's default
(authenticated-only for every REST operation) is exactly right here:
the client reads submissions in the admin, nobody can read or write
them through the public REST API, and the route's own write uses the
Local API (payload.create), which runs with overrideAccess: true by
default and so isn't blocked by that same rule. No versions/drafts
(a submission is a fact, not editable content) and no field-level
length/format validation duplicated in the collection, matching the
ticket's explicit scope: those checks live on the route.
route.ts: replaced getCollection()/insertOne() with
getPayload({config}).create({ collection: 'contact-submissions', ... }).
Removed the now-unused getCollection() helper from lib/mongodb.ts
(checkMongoConnection/getDb stay, used by /api/health) and its test.
Test gotcha worth documenting: next/jest's SWC transform rewrites the
`@payload-config` tsconfig-path alias to a real relative specifier at
transform time, so `jest.mock('@payload-config', ...)` never actually
intercepts what route.ts requires — it silently falls through to the
real payload.config.ts (mongooseAdapter, live Mongo needed). Fixed by
mocking the resolved relative path instead
(`jest.mock('../../../payload.config', ...)`); documented inline in
route.unit.test.ts for whoever hits this next (MITHOME-96 will need
the same trick for other Payload-backed routes/collections).
Verified live end-to-end, not just the test suite: submitted the real
contact form on /hu/kapcsolat, got the success message, found the
submission in /admin/collections/contact-submissions with all fields
correct (including gdprConsent checked and status "Új"/New), then
deleted the test record. Zero console errors in a fresh tab. Gate:
tsc, lint, unit tests (50 passed — one fewer than before, the removed
getCollection test), production build all green.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mozdIT Bt. Website - Next.js Application
Modern Next.js 15 website for mozdIT Bt. - Hungarian IT services company.
🚀 Quick Start
# Install dependencies
npm install
# Development server (with Turbopack)
npm run dev
# Production build
npm run build
# Run tests
npm test
Open http://localhost:3000 to view the site.
📁 Project Structure
src/
├── app/ # Next.js App Router
│ ├── page.tsx # Homepage
│ ├── rolunk/ # About page
│ ├── szolgaltatasok/ # Services page
│ ├── kapcsolat/ # Contact page
│ ├── api/ # API routes
│ └── globals.css # Design system & styles
├── components/ # React components
│ ├── Header.tsx # Navigation header
│ ├── Footer.tsx # Site footer
│ └── ThemeProvider.tsx # Dark mode provider
├── content/ # JSON content management
│ ├── types.ts # Content type definitions
│ ├── index.ts # Content loader
│ ├── common.json # Shared texts
│ └── pages/ # Page-specific content
├── config/ # Site configuration
├── lib/ # Utilities
└── types/ # TypeScript definitions
🎨 Design System
The project uses a comprehensive design system defined in globals.css:
CSS Variables
- Brand colors (
--color-primary-*) - Semantic colors (
--color-background,--color-foreground) - Shadows, transitions, border radius
Dark Mode
- Automatic system preference detection
- Manual toggle via ThemeProvider
- Uses
data-theme="dark"attribute
Animations
animate-fade-in-up- Fade in with upward motionanimate-float- Floating effectanimate-pulse-slow- Slow pulsinghover-lift,hover-scale,hover-glow- Hover effects
Utility Classes
.card- Card component styling.btn,.btn-primary,.btn-secondary- Button styles.icon-container- Icon wrapper styling
📝 Content Management
All page content is managed through JSON files in src/content/:
import { content, getPageContent } from '@/content'
// Access specific page content
const aboutContent = content.pages.about
// Or use the helper function
const servicesContent = getPageContent('services')
Content Files
| File | Description |
|---|---|
common.json |
Shared texts (buttons, labels, validation) |
pages/home.json |
Homepage CTA section |
pages/about.json |
About page (hero, story, mission, team, CTA) |
pages/services.json |
Services (hero, details, support, CTA) |
pages/contact.json |
Contact (form labels, FAQ, info) |
🧪 Testing
# Unit tests
npm test
# Watch mode
npm run test:watch
# Coverage report
npm run test:coverage
# All test suites
npm run test:all
🐳 Docker Development
For full-stack development with MongoDB and monitoring:
# From project root
docker-compose -f docker-compose.dev.yml up -d
Services:
- Website: http://localhost:3000
- MongoDB UI: http://localhost:8081
- Grafana: http://localhost:3001