Compare commits

37 Commits

Author SHA1 Message Date
bilalgursen
37baeb9172 fix: drizzle/ ve db-goc.mjs'i docker build context'ine al
All checks were successful
Deploy / deploy (push) Successful in 9m37s
.dockerignore drizzle/'ı ve scripts/* ile db-goc.mjs'i dışlıyordu;
runner katmanındaki COPY'ler 'not found' ile build'i kırıyordu.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-07 01:13:45 +03:00
bilalgursen
45775c8c3f feat: prod app.db şemasını açılışta drizzle migration'larıyla eşitle
Some checks failed
Deploy / deploy (push) Failing after 13s
Volume'deki app.db yalnızca ilk kurulumda seed'den kopyalanıyordu; sonraki
deploy'larda şemaya eklenen kolonlar (son örnek: kredi_bitti_at,
kredi_hatirlatma_gonderildi_at) prod'a hiç ulaşmıyor ve 'no such column'
hatalarıyla kırılıyordu.

- drizzle-kit generate ile baseline migration üretildi (drizzle/0000_baslangic)
- scripts/db-goc.mjs: entrypoint'te server'dan önce koşan migration runner;
  drizzle migrator protokolünü birebir taklit eder (__drizzle_migrations,
  sha256, created_at=journal.when) ama yalnızca @libsql/client'a dayanır —
  drizzle-orm standalone imajda bundle'landığından paket olarak çözülemiyor
- Benimseme: migration kaydı olmayan mevcut volume'lerde baseline additive
  uzlaştırılır (IF NOT EXISTS + snapshot'tan eksik kolon ALTER'ları) ve
  damgalanır; sonraki migration'lar normal akışla uygulanır
- sema-guvence.ts kaldırıldı: elle DDL aynalama yerini migration'lara bıraktı
- Yeni akış: şema değişikliğinde pnpm db:generate ile migration commit'lenir

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-07 01:05:42 +03:00
bilalgursen
18d5b42136 AI katmanını OpenRouter tek kapısına geçir ve rapor üretimini hızlandır
All checks were successful
Deploy / deploy (push) Successful in 9m30s
- Tüm AI akışı OpenRouter üzerinden (openai SDK, varsayılan model
  deepseek/deepseek-v4-flash, OPENROUTER_MODEL ile değiştirilebilir);
  Anthropic/Gemini/lokal sağlayıcı seçimi ve SDK'ları kaldırıldı.
- Rapor: aday havuzu dilim başına 20 (60 program, ~8k token prompt);
  AI şeması sabit uzunluklu üç liste (hayal 5 / dengeli 13 / garanti 6 —
  dağılım şema düzeyinde zorlanır), sıra + dilim + riskNotu + trendOzeti
  gerçek sıra geçmişinden deterministik üretilir; 184 sn → ~12 sn.
- Sohbet: akış ortası zaman aşımı artık sessizce yutulmaz (kesik cevap
  tam cevap gibi kaydedilmiyordu, kredi iadesi çalışmıyordu); istemci
  hata anında durumu sunucudan senkronlar, boş balon bırakmaz.
- aiHataMesaji, openai SDK'nın .name'i "Error" kalan abort/timeout
  hatalarını da yakalar; meraklisina şeması yeni akışla senkronlandı.
- CI: OPENROUTER_API_KEY / OPENROUTER_MODEL secret'ları; eski AI
  secret'ları kaldırıldı. next.config serverExternalPackages sadeleşti.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-07 00:37:54 +03:00
bilalgursen
4c618781f6 Docker build'ini optimize et: OOM kökü çözümü + bellek sınırlı builder
All checks were successful
Deploy / deploy (push) Successful in 7m33s
Prod VPS'te next build sırasında makineyi kilitleyen OOM'un çözümü:

- serverExternalPackages'a @google/genai, @anthropic-ai/sdk, resend eklendi;
  Turbopack artık genai'nin protobufjs/google-auth-library/ws zincirini
  derlemiyor (c2aba25 sonrası OOM'un tetiği buydu).
- Docker build'inde (BUILD_KAYNAK_KISITLI=1) bellek kısıtları: Turbopack 1.5G
  hedefi, statik üretim tek worker × 4 sayfa, prerender source map kapalı.
- Dockerfile: runner'a tam node_modules kopyası kaldırıldı (imaj ~1.9G→966M),
  pnpm store + .next/cache BuildKit cache mount'ları, açık COPY listesi,
  V8 heap sınırı.
- scripts/standalone-linkleri-onar.sh: Turbopack ESM external'ların kök
  node_modules symlink'ini nft trace'ine yazmıyor; eksik linkler build sonrası
  tamamlanmazsa runtime MODULE_NOT_FOUND ile düşer.
- ci.yaml: build bellek sınırlı buildx docker-container builder'da (2200m,
  max-parallelism 1; BuildKit --memory bayrağını yok sayıyor), deploy
  up -d --no-build ile ayrıldı, temizlik if: always() ile her koşuda.
- compose: app'e mem_limit 1g + oom_score_adj -600.
- Kullanılmayan simple-icons ve @react-pdf/renderer kaldırıldı; npm artığı
  package-lock.json silindi.

Doğrulama: imaj 2 CPU/2GiB VM'de sıfırdan build edildi, konteynerde ana
sayfa/universite 200 ve üç ESM external import OK.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-06 17:20:17 +03:00
bilalgursen
e62c6f07df Update package.json scripts, enhance layout with new components, and improve API error handling
Some checks failed
Deploy / deploy (push) Failing after 1h28m6s
- Added new scripts for database operations and temporary production in package.json.
- Integrated KaydetBannerLazy component into the layout for improved user notifications.
- Enhanced API error handling in the soru route to mark credit exhaustion.
- Updated the IletisimPage for better button styling and user experience.
- Refactored ListemPage to streamline user flow and improve session handling.
- Removed unused ListePaneli component to clean up the codebase.
2026-08-06 02:27:42 +03:00
bilalgursen
488845ae1f Add design documentation for CTA drawer and UX improvements
- Introduced a new document detailing the design principles behind the funnel CTA drawer, emphasizing user flow and context retention.
- Added a UX/CRO corrections document outlining critical findings from a recent audit, including payment flow adjustments, button transparency, and pricing clarity.
- Created a gamification document to outline user engagement strategies and the program evaluation model for the Kolay Tercih feature.
- Developed a vision document for TercihAI, detailing the product's positioning, revenue model, and MVP scope, aimed at providing AI-assisted preference guidance for students.
2026-08-06 02:27:34 +03:00
bilalgursen
9ea006ec22 Superpowers ve prd-development plugin'lerini proje scope'una al
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-06 01:19:56 +03:00
bilalgursen
a5c2bcbc4d Enhance error handling and user experience in AI-related features
Some checks failed
Deploy / deploy (push) Failing after 38m47s
- Introduced a mechanism to save partially generated responses in case of errors, ensuring users do not lose their input.
- Updated the RevizyonKutusu component to utilize a persistent request ID for retrying failed requests without double charging credits.
- Improved the Sayfalama component to support client-side pagination without changing the URL, enhancing user navigation.
- Added a timeout for AI generation requests to ensure credits are refunded in case of prolonged processing.
- Refactored various components for better clarity and responsiveness, including updates to the BolumProgramListesi and ListePaneli components.
2026-08-03 14:12:06 +03:00
bilalgursen
c2aba25814 Update dependencies, enhance AI integration, and improve email content
Some checks failed
Deploy / deploy (push) Failing after 1h35m43s
- Added @google/genai dependency for enhanced AI capabilities.
- Updated CI workflow to include new environment variables for AI integration.
- Refactored AI client to support multiple providers and improved key management.
- Enhanced email templates for better user engagement and clarity.
- Updated error handling in AI-related functions to provide clearer feedback.
- Made various improvements to the application structure and code clarity.
2026-08-02 21:37:25 +03:00
bilalgursen
2278d2a218 Update app.db, enhance Home component with social proof feature, and improve error handling in auth module
All checks were successful
Deploy / deploy (push) Successful in 22m12s
- Updated app.db to reflect recent changes.
- Added a Suspense-wrapped SosyalKanitBandi component in the Home page for improved user engagement.
- Refactored the sendMagicLinkEmail function in auth.ts to handle errors more effectively, ensuring users receive appropriate feedback on email sending issues.
- Removed the Rybbit live visitor widget from the site footer for a cleaner design.
2026-08-02 21:10:43 +03:00
bilalgursen
0b92f999bc Integrate Rybbit analytics and enhance user tracking features
All checks were successful
Deploy / deploy (push) Successful in 16m7s
- Added Rybbit analytics configuration in .mcp.json for improved data collection.
- Updated layout.tsx to conditionally load the Rybbit analytics script in production.
- Enhanced user interaction tracking in various components, including GirisForm, RevizyonKutusu, and SatinAlForm, by logging specific events.
- Updated privacy policy page to reflect new data handling practices and added a section on service providers and data transfer.
- Improved user navigation and experience by integrating Rybbit's live visitor widget in the site footer.
2026-08-02 19:29:42 +03:00
bilalgursen
cc9686147e Add Rybbit analytics script and enhance pricing section with new features
All checks were successful
Deploy / deploy (push) Successful in 14m22s
- Integrated Rybbit analytics script in layout.tsx for improved tracking.
- Updated pricing section in page.tsx to include detailed package features and pricing information.
- Refined button interactions and added icons for better user engagement.
- Adjusted return URL handling in odeme/sonuc/page.tsx to preserve order information.
- Enhanced satin-al-form.tsx to include visual indicators for payment redirection.
2026-08-02 18:49:17 +03:00
bilalgursen
bd613adb8a Enhance content clarity and structure across multiple guidance articles by updating descriptions and adding flowcharts for better understanding. Key changes include refining explanations in sections about scholarship programs, placement processes, and preference lists, along with the introduction of mermaid diagrams to visually represent complex information. This update aims to improve user navigation and comprehension of the educational pathways and requirements.
All checks were successful
Deploy / deploy (push) Successful in 9m44s
2026-08-02 05:04:38 +03:00
bilalgursen
205743f3b1 Update terminology from "AI" to "Yapay Zeka" across multiple components for consistency and clarity. Adjusted button labels, error messages, and comments to reflect the new terminology, enhancing user understanding and maintaining uniformity throughout the application.
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-08-02 04:57:15 +03:00
bilalgursen
a8bd13ef43 Refactor KatalogArama, SiteHeader, and UserNav components for improved layout and responsiveness. Adjusted flex properties and aria-labels for better accessibility and visual clarity across screen sizes. Enhanced styling to ensure consistent presentation of elements in mobile and desktop views.
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-08-02 04:53:38 +03:00
bilalgursen
647a44e46a Update SiteHeader component to improve accessibility and visual clarity. Added aria-label for the logo link and adjusted text visibility for better responsiveness on mobile devices. Enhanced styling for the brand name to ensure consistent presentation across screen sizes.
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-08-02 04:51:18 +03:00
bilalgursen
6495369c56 Enhance KatalogArama component by adding PUAN_TURU_ETIKET for improved user feedback. Updated button aria-labels and display elements to include score type, ensuring better clarity and consistency in the UI. Adjusted styles for better responsiveness and visual alignment.
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-08-02 04:48:44 +03:00
bilalgursen
b4effc8545 Refactor UI components for consistency and clarity across the application
All checks were successful
Deploy / deploy (push) Successful in 18m31s
- Updated AGENTS.md with new guidelines for UI consistency, including badge and modal styles.
- Refactored layout.tsx to improve the placement of the progressive blur effect.
- Enhanced NotFound component text for better user guidance.
- Replaced HeroFocusButton with HeroBaslik and KapanisCta in the Home component for improved clarity.
- Added SiteFooter to multiple pages for consistent footer display.
- Removed ListemSekmeleri component and adjusted ListemPage to streamline functionality.
- Updated various components to ensure consistent styling and user experience.
2026-08-02 04:28:27 +03:00
bilalgursen
6bd210075f Rehbere mermaid şema desteği ve 4 yeni tercih dönemi yazısı ekle
Markdown'daki \`\`\`mermaid çitleri artık yazıyı parçalara bölüyor ve şemalar
üründeki ortak el çizimi bileşeniyle (ElCizimiSema) çiziliyor; çitte "%% aria:"
satırı zorunlu, "%% altyazi:" figcaption veriyor. Tercih dönemi aramalarına
dayanan dört yeni yazı: merkezi yerleştirme algoritması, OBP hesabı, üniversite
kayıt rehberi ve yerleşememe/istenmeyen bölüm karar ağacı — her biri risk renk
dilinde birer şemayla.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-02 04:25:58 +03:00
bilalgursen
716f7bb3fb Add "detay" script to package.json and enhance ListemSekmeleri component functionality
All checks were successful
Deploy / deploy (push) Successful in 16m29s
- Introduced a new "detay" script in package.json for additional processing.
- Refactored ListemSekmeleri component to improve tab functionality and state management.
- Updated UI elements for better user interaction and clarity, including renaming "Seçtiklerim" to "Kendi Listem" for consistency across the application.
- Made adjustments to related components for improved integration and user experience.
2026-08-01 21:58:28 +03:00
bilalgursen
f27f3ffaac Enhance university-related components by adding logo support and improving search functionality. Introduced a new "logolar" script in package.json, updated KatalogArama to include rehber results, and integrated UniLogo component across various pages for better visual representation. Refactored UniversiteIcerik and TercihHaritasi to display logos conditionally, enhancing user experience. Additionally, made adjustments to styles and layout for improved responsiveness and clarity.
All checks were successful
Deploy / deploy (push) Successful in 16m24s
2026-08-01 20:17:48 +03:00
bilalgursen
ff66480227 Refactor font loading functions to implement caching for improved performance. The loadSiteOgFonts and loadRehberOgFonts functions now utilize promises to prevent redundant loading, enhancing efficiency. Additionally, minor adjustments were made to ensure consistent font data structure and style definitions.
All checks were successful
Deploy / deploy (push) Successful in 7m1s
2026-08-01 18:58:27 +03:00
bilalgursen
b3dd36fa72 Update component configurations and styles: add new registry for @magicui in components.json, remove unused opengraph image files, and enhance opengraph-image.tsx with new font loading and styling adjustments. Refactor button sizes and styles in various components for improved responsiveness and visual consistency. Overall, these changes aim to streamline the application and enhance user experience.
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-08-01 18:54:43 +03:00
bilalgursen
55eb32b22a Enhance layout and functionality by integrating TercihProfiliKapisiLazy component into layout.tsx, improving user experience with a new section in the RootLayout. Update BolumlerPage and ListemPage for better structure and readability, including adjustments to headings and content organization. Refactor UniversiteIcerik to utilize UniversiteProgramTablosu for displaying program data, and streamline UniversiteKonumHaritasi for improved rendering. Update ManuelListe components for clearer user instructions and enhanced interaction. Overall, these changes aim to improve visual clarity and user engagement across the application.
All checks were successful
Deploy / deploy (push) Successful in 7m25s
2026-08-01 17:58:38 +03:00
bilalgursen
8cf0c3267d Update routing in next.config.ts to redirect "/tercih-robotu" to the hero form, add simple-icons dependency in package.json, and enhance database indexing for improved query performance. Remove unused SVG files and update metadata across various pages for better SEO and clarity.
All checks were successful
Deploy / deploy (push) Successful in 14m14s
2026-08-01 17:28:38 +03:00
bilalgursen
569b9e5da2 Enhance application performance and user experience by enabling component caching in next.config.ts, optimizing database queries in various pages, and implementing lazy loading for heavy components. Updated styles for smoother transitions and improved visual clarity in multiple components, including globals.css and landing sections.
All checks were successful
Deploy / deploy (push) Successful in 2m30s
2026-08-01 14:00:22 +03:00
bilalgursen
acb3b9d557 Update layout and styling across multiple components for improved responsiveness and visual clarity. Adjusted print styles in YazdirPage and layout.tsx, added an image to the footer, and ensured proper formatting in globals.css. Updated app.db to reflect recent changes.
All checks were successful
Deploy / deploy (push) Successful in 2m51s
2026-07-30 13:35:04 +03:00
bilalgursen
1583d424fd Remove outdated badge from Home component to streamline content and improve visual clarity.
All checks were successful
Deploy / deploy (push) Successful in 3m8s
2026-07-30 13:16:44 +03:00
bilalgursen
60e81e266d Enhance SiteHeader component layout by adjusting positioning of navigation and header elements for improved visual alignment and responsiveness.
All checks were successful
Deploy / deploy (push) Successful in 2m52s
2026-07-30 13:07:32 +03:00
bilalgursen
736a6fabf0 Update favicon and enhance SiteHeader component with logo image for improved branding
All checks were successful
Deploy / deploy (push) Successful in 3m10s
2026-07-30 13:00:36 +03:00
bilalgursen
65d630d754 Add @number-flow/react dependency and integrate SiteTopBanner component into layout
All checks were successful
Deploy / deploy (push) Successful in 11m11s
2026-07-30 12:24:37 +03:00
bilalgursen
e74710a20a Update TurkeyPixelMap width in Parallax component for improved responsiveness on medium screens
All checks were successful
Deploy / deploy (push) Successful in 2m59s
2026-07-30 09:14:36 +03:00
bilalgursen
9139977cd6 Update Parallax component style formatting and enhance pixel heat function readability. Update app.db to reflect recent changes.
All checks were successful
Deploy / deploy (push) Successful in 2m56s
2026-07-30 04:22:46 +03:00
bilalgursen
a1b2c4b069 Refactor page components to include PagePixelDivider for improved visual separation across multiple pages. Updated layout in Home, Giris, Gizlilik, Iletisim, Kosullar, Listem, Odeme Sonuc, Paket, and Sonuc pages to enhance user experience and maintain consistency.
All checks were successful
Deploy / deploy (push) Successful in 2m47s
2026-07-30 04:15:49 +03:00
bilalgursen
36008bb72a Remove unused ConsoleAsr and PagePixelLayer components from layout.tsx to streamline the codebase and improve performance.
All checks were successful
Deploy / deploy (push) Successful in 2m40s
2026-07-30 03:56:48 +03:00
bilalgursen
2c542e7756 Update padding in Parallax component for improved layout consistency
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-07-30 03:54:31 +03:00
bilalgursen
dc6d894a37 Refactor code structure for improved readability and maintainability
All checks were successful
Deploy / deploy (push) Successful in 10m26s
2026-07-30 03:17:12 +03:00
489 changed files with 20440 additions and 16159 deletions

View File

@@ -0,0 +1,197 @@
# The Picker
The picker's appearance is **not a design decision** — it is this spec. Copy the markup, CSS, and wiring below verbatim; the only values that change per run are the variant names and count. It stays identical across every project so it always reads as harness chrome, never as part of the design being judged. Do not restyle it with the project's tokens, fonts, or colors.
It is a floating dark pill, bottom-center. Dark glass works on top of any page — light or dark — which is why it is not theme-aware.
## Markup
The sliding highlight span first, one button per variant, a hairline divider, then the replay button (only when at least one variant has motion to re-trigger):
```html
<nav class="proto-picker" aria-label="Prototype variants">
<span class="proto-picker-highlight" aria-hidden="true"></span>
<button class="proto-picker-item" data-active aria-current="true">Quiet</button>
<button class="proto-picker-item">Editorial</button>
<button class="proto-picker-item">Playful</button>
<span class="proto-picker-divider" aria-hidden="true"></span>
<button class="proto-picker-item proto-picker-replay" aria-label="Replay animation (R)"></button>
</nav>
```
In a framework, keep the class names and structure; only the rendering syntax changes.
## Styles
```css
.proto-picker {
position: fixed;
bottom: 24px;
left: 50%;
transform: translateX(-50%);
z-index: 2147483647;
display: flex;
align-items: center;
gap: 2px;
padding: 4px;
border-radius: 999px;
background: rgba(10, 10, 10, 0.82);
-webkit-backdrop-filter: blur(12px) saturate(1.4);
backdrop-filter: blur(12px) saturate(1.4);
box-shadow:
0 0 0 1px rgba(255, 255, 255, 0.08) inset,
0 8px 24px rgba(0, 0, 0, 0.24),
0 2px 6px rgba(0, 0, 0, 0.12);
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
font-size: 13px;
line-height: 1;
-webkit-font-smoothing: antialiased;
user-select: none;
-webkit-user-select: none;
}
.proto-picker-highlight {
position: absolute;
top: 4px;
left: 0;
height: 28px;
border-radius: 999px;
background: rgba(255, 255, 255, 0.12);
will-change: transform;
}
/* The slide is enabled only after first paint (data-ready), so load doesn't animate. */
.proto-picker[data-ready] .proto-picker-highlight {
transition:
transform 250ms cubic-bezier(0.23, 1, 0.32, 1),
width 250ms cubic-bezier(0.23, 1, 0.32, 1);
}
@media (prefers-reduced-motion: reduce) {
.proto-picker[data-ready] .proto-picker-highlight { transition: none; }
}
.proto-picker-item {
position: relative; /* sits above the highlight */
display: flex;
align-items: center;
height: 28px;
padding: 0 12px;
border: 0;
border-radius: 999px;
background: transparent;
color: rgba(255, 255, 255, 0.55);
font: inherit;
cursor: pointer;
transition: color 150ms ease-out;
}
.proto-picker-item:hover {
color: rgba(255, 255, 255, 0.85);
}
.proto-picker-item:active {
transform: scale(0.97);
}
.proto-picker-item:focus-visible {
outline: 2px solid rgba(255, 255, 255, 0.4);
outline-offset: 2px;
}
.proto-picker-item[data-active] {
color: #fff;
}
.proto-picker-divider {
width: 1px;
height: 16px;
margin: 0 4px;
background: rgba(255, 255, 255, 0.12);
}
.proto-picker-replay {
padding: 0 10px;
font-size: 14px;
}
.proto-picker[data-position="top"] {
bottom: auto;
top: 24px;
}
```
## Rules
- **Verbatim.** These values are the spec. No project fonts, no brand colors, no theme switching, no extra shadows or borders.
- **The highlight slides; the variant swap stays instant.** The active pill animates between buttons (250ms, strong ease-out) as spatial feedback on the picker itself — but the variant being previewed still switches with no transition. The `width` transition is a deliberate exception to the transform/opacity rule: the element is 28px tall, absolutely positioned, and has no layout dependents, so the paint cost is negligible.
- **One allowed modification:** if a variant occupies the bottom-center of the screen (a toast stack, a bottom sheet, a dock), set `data-position="top"` so the picker never covers the work. Nothing else about it may move or change.
- **Replay is conditional.** Render the replay button and its divider only when at least one variant has an entrance or state animation worth re-triggering; a static comparison gets a shorter pill.
## Behavior contract
The contract is fixed regardless of how the harness renders:
- Number keys `1N` and `←`/`→` switch variants; `R` replays. Ignore key events when focus is in an input, textarea, select, or contenteditable, or when a modifier is held.
- Clicking an item switches to it; exactly one item carries `data-active` and `aria-current="true"` at all times, and the highlight slides to it.
- Selection persists across reload via a URL param (`?v=2`), falling back to variant 1. The highlight takes its initial position without animating (`data-ready` is added after first paint).
- Switching re-mounts the variant (so entrance animations re-run); the replay key re-mounts without switching.
## Reference wiring
Verbatim for the standalone-HTML branch; in a framework, keep the same behavior but express it idiomatically (state instead of `innerHTML`, a keyed re-mount instead of `requestAnimationFrame`, refs + a layout effect for the highlight measurement).
```js
// `variants` is an array of render functions, one per variant, in picker order.
const stage = document.getElementById('stage');
const picker = document.querySelector('.proto-picker');
const highlight = picker.querySelector('.proto-picker-highlight');
const items = [...picker.querySelectorAll('.proto-picker-item:not(.proto-picker-replay)')];
const replay = picker.querySelector('.proto-picker-replay');
let current = 0;
function moveHighlight() {
const el = items[current];
highlight.style.width = el.offsetWidth + 'px';
highlight.style.transform = `translateX(${el.offsetLeft}px)`;
}
function mount(i) {
stage.innerHTML = '';
// Clear first, render next frame, so entrance animations re-run.
requestAnimationFrame(() => { stage.innerHTML = variants[i](); });
}
function setActive(i) {
if (i < 0 || i >= variants.length) return;
current = i;
items.forEach((el, j) => {
el.toggleAttribute('data-active', j === i);
if (j === i) el.setAttribute('aria-current', 'true');
else el.removeAttribute('aria-current');
});
moveHighlight();
const url = new URL(location);
url.searchParams.set('v', i + 1);
history.replaceState(null, '', url);
mount(i);
}
items.forEach((el, i) => el.addEventListener('click', () => setActive(i)));
replay?.addEventListener('click', () => mount(current));
window.addEventListener('resize', moveHighlight);
document.addEventListener('keydown', (e) => {
if (/^(INPUT|TEXTAREA|SELECT)$/.test(e.target.tagName) || e.target.isContentEditable) return;
if (e.metaKey || e.ctrlKey || e.altKey) return;
const num = parseInt(e.key, 10);
if (num >= 1 && num <= variants.length) setActive(num - 1);
else if (e.key === 'ArrowRight') setActive((current + 1) % variants.length);
else if (e.key === 'ArrowLeft') setActive((current - 1 + variants.length) % variants.length);
else if (e.key === 'r' || e.key === 'R') mount(current);
});
setActive((parseInt(new URLSearchParams(location.search).get('v'), 10) || 1) - 1);
// Enable the slide only after first paint, so load doesn't animate.
requestAnimationFrame(() => requestAnimationFrame(() => picker.setAttribute('data-ready', '')));
```

View File

@@ -0,0 +1,90 @@
---
name: prototype
description: Build multiple genuinely different versions of a UI piece you describe, rendered behind a visual picker so you can flip through them live and promote the one that feels right. Only runs when explicitly invoked; it does not trigger on its own.
disable-model-invocation: true
---
# Prototyping Variants
A divergence skill. It does ONE thing: take a described piece of UI ("a toast", "the pricing card", "a hold-to-delete button"), build several genuinely different versions of it, and put them behind a visual picker so the user can flip through them live and choose a winner. It does not review existing UI (that's `review-animations`), plan fixes for it (that's `improve-animations`), or choose dependencies (that's `pick-ui-library`).
## Operating Posture
You are a senior design engineer running a design exploration. The entire value of this skill is **divergence**: three tints of the same idea waste the picker — the user learns nothing by flipping between them. Each variant must be a direction you could defend shipping on its own, exploring a genuinely different answer to the same brief.
Divergence is not an excuse to drop the craft bar. Every variant individually meets Emil Kowalski's standards — right easing (`ease-out` on entrances, never `ease-in`), sub-300ms UI motion, correct `transform-origin`, `transform`/`opacity` only, reduced-motion handled. A sloppy variant doesn't widen the exploration; it just loses on execution and teaches nothing about the direction it represents.
## Hard Rules
1. **Never touch production code during exploration.** Everything lives in an isolated prototype surface (see Phase 4). Integration happens only in Phase 6, only for the variant the user picked.
2. **Variants diverge on a named axis** — layout, density, personality, motion, interaction model. Before building, you must be able to state each variant's axis in a phrase. Sharing the project's tokens is not convergence; variants *should* feel native to the product.
3. **Every variant fully works.** Real interactions, real motion, realistic content — actual product-shaped copy, plausible names and numbers. No lorem ipsum, no dead buttons, no "imagine this part".
4. **The picker is chrome, not a contestant.** Its exact markup, styles, and behavior are specified in [PICKER.md](PICKER.md) — copy them verbatim. Its look is not a design decision and never adapts to the project.
5. **Clean up after the choice.** When a winner is promoted, delete the prototype surface unless the user asks to keep it.
## Workflow
### Phase 1 — Scope
One thing per run. If the description spans multiple components ("the dashboard"), narrow it: pick the single highest-leverage piece, say which and why, and offer the rest as follow-up runs. Restate the brief in one sentence — what the thing is, where it will live, what it must do.
### Phase 2 — Recon
Before designing anything, map the ground the variants must stand on:
- **Stack**: framework, styling system (Tailwind, CSS modules, vanilla), motion library if any.
- **Tokens**: colors, radii, spacing, fonts, easing/duration variables. Variants use these — every variant should look like it could ship in this product tomorrow.
- **Personality**: playful consumer app or crisp dashboard? This bounds how far the boldest variant may go.
- **Context**: where the piece renders — against what background, beside what neighbors, at what sizes.
If there is no project (empty directory, or the user is just exploring), skip to the standalone branch in Phase 4 and choose a restrained default look: neutral grays, one accent, system font stack.
### Phase 3 — Choose directions
Default **3 variants**; up to 5 when the user asks or the design space is genuinely wide. More than 5 dilutes the comparison.
Before writing any code, list the set: a name and an axis for each. Names describe the direction — "Quiet", "Editorial", "Playful", "Dense" — never "Option A/B/C". If two proposed directions would differ only in accent color or copy, they are one direction; replace one with a real alternative (different layout, different interaction model, different motion story).
**Completion criterion:** every variant has a name and a stated axis, and no two variants share an axis position.
### Phase 4 — Build the picker harness
Two branches, by what exists:
- **In a project with a dev server** — an isolated route or page (`/prototypes/<slug>`, or the framework's equivalent), one file per variant plus a small harness file. Nothing imports from the prototype surface into production code.
- **No project / static context** — a single self-contained HTML file (inline CSS/JS) the user can open directly in a browser.
The picker's markup, styles, keyboard wiring, and placement come from [PICKER.md](PICKER.md), verbatim — load it now and build exactly that. Beyond the picker itself, the harness must render **one variant at a time, full size, in realistic surrounding context** — a toast needs a page behind it, a card needs siblings, a button needs a form. Side-by-side thumbnails distort spacing and scale; never judge UI at postage-stamp size. Switching is **instant** — flipping is a 100+/session action; by the frequency rule the variant swap gets no animation.
### Phase 5 — Verify and hand off
Run the harness. Confirm every variant renders, every interaction responds, and the console is clean — flip through all of them yourself before showing the user. If browser tooling is available, screenshot each variant.
Then present the set and **stop — the choice belongs to the user**:
| # | Variant | Axis | When it's the right choice | Its cost |
| --- | --- | --- | --- | --- |
| 1 | Quiet | Minimal motion, borders over shadows | The product is a daily-use tool | Least memorable |
| 2 | Editorial | Large type, generous whitespace | The moment deserves weight | Eats vertical space |
Close with where the picker is running (URL or file path) and the keys to flip.
**Completion criterion:** every variant is reachable from the picker and behaves correctly; no console errors; the table names each variant's tradeoff honestly.
### Phase 6 — Promote on selection
When the user picks: integrate that variant where it belongs, following the project's existing conventions (file layout, naming, token usage), then delete the prototype surface per Hard Rule 5. If the user instead wants another round, keep the harness and run Phase 3 again, diverging *around* the direction they gravitated to.
## Invocation Variants
| Invocation | Behavior |
| --- | --- |
| `<description>` | Full workflow: scope → recon → 3 variants → picker → wait for choice |
| `<description> x5` | Same, with that many variants (capped at 5) |
| `riff <variant>` | New round: keep the harness, generate a fresh set diverging around the named variant's direction |
| `keep <variant>` | Promote that variant into the codebase and delete the prototype surface |
| `keep <variant>, leave the picker` | Promote, but keep the prototype surface around |
## Tone
Sell each variant honestly — one line on when it wins, one on what it costs. Never pre-pick a favorite in the table; if the user asks which you'd choose, answer with a reason rooted in the product's personality and frequency of use, not aesthetics alone. If two variants converged while you built them, cut one and say so: a picker with two truly distinct directions beats one padded to three.

View File

@@ -12,6 +12,12 @@
"runtimeExecutable": "npm", "runtimeExecutable": "npm",
"runtimeArgs": ["run", "dev", "--", "-p", "3100"], "runtimeArgs": ["run", "dev", "--", "-p", "3100"],
"port": 3100 "port": 3100
},
{
"name": "prod-3100",
"runtimeExecutable": "pnpm",
"runtimeArgs": ["start", "-p", "3100"],
"port": 3100
} }
] ]
} }

20
.claude/settings.json Normal file
View File

@@ -0,0 +1,20 @@
{
"enabledPlugins": {
"superpowers@superpowers-marketplace": true,
"prd-development@pm-skills": true
},
"extraKnownMarketplaces": {
"superpowers-marketplace": {
"source": {
"source": "github",
"repo": "obra/superpowers-marketplace"
}
},
"pm-skills": {
"source": {
"source": "github",
"repo": "deanpeters/Product-Manager-Skills"
}
}
}
}

View File

@@ -0,0 +1,7 @@
---
name: grill-me
description: A relentless interview to sharpen a plan or design.
disable-model-invocation: true
---
Run a `/grilling` session.

View File

@@ -0,0 +1,22 @@
---
name: grilling
description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
---
Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled — the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Each question should be formatted like so:
```
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
```
Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The _decisions_ are the user's — put each to them and wait.
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

1
.claude/skills/prototype Symbolic link
View File

@@ -0,0 +1 @@
../../.agents/skills/prototype

View File

@@ -1,13 +1,27 @@
node_modules node_modules
.next .next
.git .git
.gitea
.agents .agents
.claude .claude
.mcp.json .mcp.json
# Yalnızca kök dizindeki .md dosyaları (path ayracını geçmez);
# content/rehber/*.md build için gerekli, etkilenmez.
*.md *.md
.env* .env*
!.env.example !.env.example
drizzle/ docs/
# scripts/ build'de kullanılmaz; istisnalar: entrypoint + standalone link
# onarımı + açılış migration runner'ı (drizzle/ da onun için imaja girer)
scripts/*
!scripts/docker-entrypoint.sh
!scripts/standalone-linkleri-onar.sh
!scripts/db-goc.mjs
package-lock.json
skills-lock.json
components.json
eslint.config.mjs
drizzle.config.ts
data/ data/
!data/app.db !data/app.db
!data/yokatlas.db !data/yokatlas.db

View File

@@ -26,10 +26,54 @@ jobs:
IYZICO_API_KEY=${{ secrets.IYZICO_API_KEY }} IYZICO_API_KEY=${{ secrets.IYZICO_API_KEY }}
IYZICO_SECRET_KEY=${{ secrets.IYZICO_SECRET_KEY }} IYZICO_SECRET_KEY=${{ secrets.IYZICO_SECRET_KEY }}
IYZICO_BASE_URL=${{ secrets.IYZICO_BASE_URL }} IYZICO_BASE_URL=${{ secrets.IYZICO_BASE_URL }}
ANTHROPIC_API_KEY=${{ secrets.ANTHROPIC_API_KEY }} OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }}
OPENROUTER_MODEL=${{ secrets.OPENROUTER_MODEL }}
EOF EOF
- name: Build & deploy # BuildKit'te "docker build --memory" YOK SAYILIR (moby/buildkit#1362);
# gerçek sınır ancak buildkitd'yi kendi cgroup'u olan bir container'da
# (buildx docker-container driver) koşturarak konur. Böylece build OOM
# olursa yalnızca builder container'ı ölür — uygulama + Gitea ayakta kalır
# ve adım 35-90 dk sessiz kilitlenme yerine hızlı, görünür hata verir.
#
# Sınırlar container İLK oluşturulduğunda donar; değerleri değiştirmek için
# önce: docker buildx rm sinirli && docker rm -f buildx_buildkit_sinirli0
- name: Sınırlı builder hazırla
run: | run: |
docker compose -p kolaytercih up -d --build --remove-orphans cat > buildkitd.toml <<'EOF'
docker image prune -f [worker.oci]
enabled = true
max-parallelism = 1
EOF
# Act container'ı her koşuda sıfırdan geldiği için client kaydı hep
# yeniden oluşturulur; host'taki buildx_buildkit_sinirli0 container'ı
# (ve build cache'i) varsa bootstrap'ta aynen yeniden kullanılır.
docker buildx create --name sinirli \
--driver docker-container \
--driver-opt memory=2200m \
--driver-opt memory-swap=4200m \
--driver-opt cpu-quota=150000 \
--buildkitd-config ./buildkitd.toml \
2>/dev/null || true
docker buildx inspect sinirli --bootstrap >/dev/null
- name: Build (sınırlı builder)
run: |
docker compose -p kolaytercih build --builder sinirli
# docker-container driver'da imajın daemon'a --load ile düştüğünü doğrula;
# düşmediyse aynı cache'ten yeniden build edip elle yükle.
docker image inspect kolaytercih-app >/dev/null 2>&1 || \
docker buildx build --builder sinirli --load -t kolaytercih-app .
- name: Deploy
run: docker compose -p kolaytercih up -d --no-build --remove-orphans
- name: Temizlik (başarısız build'de de çalışır)
if: always()
run: |
docker image prune -f || true
# sinirli builder'ın cache'ini 4 GB'ta tut (flag adı buildx sürümüne göre değişti)
docker buildx prune --builder sinirli -f --max-used-space 4gb 2>/dev/null || \
docker buildx prune --builder sinirli -f --keep-storage 4gb || true
# eski varsayılan-builder cache artıkları
docker builder prune -f --filter "until=72h" || true

View File

@@ -1,5 +1,9 @@
{ {
"mcpServers": { "mcpServers": {
"rybbit": {
"type": "http",
"url": "https://rybbit.kolaytercih.com/api/mcp"
},
"shadcn": { "shadcn": {
"command": "npx", "command": "npx",
"args": [ "args": [

View File

@@ -3,7 +3,27 @@
This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in `node_modules/next/dist/docs/` before writing any code. Heed deprecation notices. This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in `node_modules/next/dist/docs/` before writing any code. Heed deprecation notices.
# Tarayıcı açma
UI değişikliklerini tarayıcıda/preview'da doğrulamaya çalışma; kullanıcı kendisi kontrol ediyor. Dev sunucusu veya browser paneli açma — sadece kod değişikliğini yap ve ne değiştiğini raporla.
# Push öncesi build zorunlu # Push öncesi build zorunlu
Push emri geldiğinde önce lokalde `pnpm build` başarıyla geçmeli; geçmeden asla push etme. Kritik detay: çalışma ağacı kirliyken build, commit'lenmemiş dosyaları da gördüğü için CI'da kırılacak bir commit'i yakalayamayabilir. Bu yüzden build'i **push edilecek commit'in kendisi** üzerinde doğrula (ör. geçici `git worktree add <dir> HEAD` + `node_modules` symlink'i ile). Ayrıca kısmi commit atarken değişikliğin bağımlılık kapanışını kontrol et — bir dosyanın kullandığı prop/export başka bir commit'lenmemiş dosyadan geliyorsa onları da aynı commit'e dahil et. Push emri geldiğinde önce lokalde `pnpm build` başarıyla geçmeli; geçmeden asla push etme. Kritik detay: çalışma ağacı kirliyken build, commit'lenmemiş dosyaları da gördüğü için CI'da kırılacak bir commit'i yakalayamayabilir. Bu yüzden build'i **push edilecek commit'in kendisi** üzerinde doğrula (ör. geçici `git worktree add <dir> HEAD` + `node_modules` symlink'i ile). Ayrıca kısmi commit atarken değişikliğin bağımlılık kapanışını kontrol et — bir dosyanın kullandığı prop/export başka bir commit'lenmemiş dosyadan geliyorsa onları da aynı commit'e dahil et.
# Badge/eyebrow rozetleri: tek kaynak SectionEyebrow
Site genelindeki tüm badge/rozet/eyebrow elemanları ana sayfadaki section başlıklarının üstünde duran rozetle birebir aynı olmalı. Kanonik bileşen `src/components/pixel-decor.tsx` içindeki `SectionEyebrow`dur (piksel imzalı `PixelMark` ikonu + `rounded-full border border-slate-200 bg-white px-3.5 py-1.5 text-xs font-semibold uppercase tracking-[0.12em] text-primary`). Yeni bir badge/eyebrow gerektiğinde `SectionEyebrow` kullan (`className` prop'u kenar boşluğu için var); `@/components/ui/badge`'deki `Badge` ile ya da elle yazılmış pill span'lerle yeni badge tasarlama. İnteraktif chip/buton pill'leri (filtre çipleri, nav butonları) bu kuralın dışındadır.
# UI tutarlılığı: ortak elemanlar tek kaynaktan
Modallar arası ortak elemanlar (kapatma çarpısı, başlık düzeni vb.) görsel olarak birebir aynı olmalı. Kapatma çarpısının kanonik stili `src/components/ui/dialog.tsx` içindeki `DialogContent` varsayılan butonudur (yuvarlak, `size-9`, `border border-slate-200`, `size-4` X ikonu, hover'da `bg-slate-100`, `active:scale-[0.96]`). Yeni bir modal eklerken bu varsayılanı kullan; özel yerleşim gerekiyorsa (ör. katalog-arama'da input satırının içindeki buton) `showCloseButton={false}` ver ama **aynı class setini** kopyala — farklı boyut/renk/varyantta yeni bir çarpı tasarlama. Aynı prensip diğer tekrarlanan UI parçaları için de geçerli: bir eleman iki yerde görünüyorsa stilini tek kaynaktan al veya birebir eşleştir.
# CTA butonlarında ikon: yıldız yok, sağ ok metnin sonunda
Funnel CTA butonlarında ("Listemi oluştur", "Tercihlerimi belirle", giriş/ödeme CTA'ları vb.) `Sparkles` (yıldız) ikonu kullanılmaz. Kanonik desen: buton metni önce gelir, sonunda `<ArrowRight className="size-4" aria-hidden />` durur. Yeni bir CTA butonu eklerken bu deseni uygula; metnin başına ikon koyma. Dekoratif `Sparkles` kullanımları (boş durum başlık ikonları, bilgi satırları) bu kuralın dışındadır — kural yalnızca aksiyon butonları/CTA linkleri içindir.
# Meraklısına'daki mermaid şeması mimariyle senkron kalmalı
`/meraklisina` sayfasındaki sihirbaz akış şeması (`src/app/meraklisina/huni-semasi.tsx` içindeki `SEMA` sabiti) ürünün gerçek davranışının belgesidir, dekor değildir. Sihirbaz/listeleme mimarisinde davranış değiştiren her değişiklikte bu şema da aynı PR/commit içinde güncellenmeli: sihirbaz adımlarının sayısı-sırası-içeriği (alan → il → devlet/vakıf), aday havuzu kuralları, 24'lük liste iskeleti (hayal/dengeli/garanti dağılımı), havuz 24'ün altına düşünce filtre gevşetme sırası ve yapay zekânın havuz-dışına-çıkamama kuralı. Şemayı güncellerken çevresindeki unsurları da eşitle: bölümdeki anlatım metni (`src/app/meraklisina/page.tsx`, 4. bölüm), kabın `aria-label`'ı ve figcaption. Şema öğrenci diliyle kalmalı (SQL/prompt/teknik detay yok) ve ürünün risk renk dilini korumalı — kırmızı/sarı/yeşil her zaman metin etiketiyle birlikte, renk tek başına anlam taşımaz.
<!-- END:nextjs-agent-rules --> <!-- END:nextjs-agent-rules -->

View File

@@ -1,6 +1,8 @@
FROM node:20-alpine AS base # syntax=docker/dockerfile:1
# pnpm kurulumu FROM node:20-alpine AS base
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable && corepack prepare pnpm@10.8.1 --activate RUN corepack enable && corepack prepare pnpm@10.8.1 --activate
# ── Bağımlılık katmanı ── # ── Bağımlılık katmanı ──
@@ -9,17 +11,36 @@ WORKDIR /app
# better-sqlite3 Alpine'de kaynaktan derleniyor (musl için prebuilt yok) # better-sqlite3 Alpine'de kaynaktan derleniyor (musl için prebuilt yok)
RUN apk add --no-cache python3 make g++ RUN apk add --no-cache python3 make g++
COPY package.json pnpm-lock.yaml ./ COPY package.json pnpm-lock.yaml ./
RUN pnpm install --frozen-lockfile # pnpm store cache mount'ta yaşar: lockfile değişse bile inen paketler yeniden inmez
RUN --mount=type=cache,id=pnpm,target=/pnpm/store \
pnpm install --frozen-lockfile
# ── Derleme katmanı ── # ── Derleme katmanı ──
FROM base AS builder FROM base AS builder
WORKDIR /app WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules COPY --from=deps /app/node_modules ./node_modules
COPY . . # Build girdileri açık listelenir: docs/, scripts/, CI dosyası değişiklikleri
# bu katmanı invalide edemez. next build'in okuduğu her şey burada:
# content/ (rehber.ts), data/ (db.ts prerender), public/ (opengraph-image).
COPY package.json next.config.ts tsconfig.json postcss.config.mjs ./
COPY scripts/standalone-linkleri-onar.sh ./scripts/
COPY public ./public
COPY data ./data
COPY content ./content
COPY src ./src
ENV NEXT_TELEMETRY_DISABLED=1 ENV NEXT_TELEMETRY_DISABLED=1
# data/ .dockerignore'da; libsql build sırasında file:./data/app.db açabilsin diye boş dizin gerekli # V8 heap sınırı ana süreç + statik üretim worker'larına miras kalır.
RUN mkdir -p data && pnpm build # Turbopack'ın Rust tarafı bu sınırın dışında; onun hedefi next.config.ts'te
# turbopackMemoryLimit ile verilir (BUILD_KAYNAK_KISITLI bloğu).
ENV NODE_OPTIONS="--max-old-space-size=1536"
ENV BUILD_KAYNAK_KISITLI=1
RUN --mount=type=cache,id=next-cache,target=/app/.next/cache \
pnpm build
# Turbopack, ESM external'ların (@google/genai vb.) kök node_modules symlink'ini
# nft trace'ine yazmıyor; eksik linkler tamamlanmazsa runtime MODULE_NOT_FOUND
# ile düşer. Ayrıntı script'in başındaki açıklamada.
RUN sh scripts/standalone-linkleri-onar.sh .next/standalone
# ── Çalıştırma katmanı ── # ── Çalıştırma katmanı ──
FROM node:20-alpine AS runner FROM node:20-alpine AS runner
@@ -31,14 +52,21 @@ ENV NEXT_TELEMETRY_DISABLED=1
RUN addgroup --system --gid 1001 nodejs && \ RUN addgroup --system --gid 1001 nodejs && \
adduser --system --uid 1001 nextjs adduser --system --uid 1001 nextjs
# Bağımlılıklar # standalone çıktı, file-tracing ile seçilmiş kendi minimal node_modules'unu
COPY --from=deps /app/node_modules ./node_modules # içerir (serverExternalPackages dahil) — tam node_modules kopyalanmaz.
COPY --from=builder /app/.next/standalone ./ COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public COPY --from=builder /app/public ./public
# Trace, data/yokatlas.db'yi de standalone'a koyuyor; runtime'da /app/data
# volume'ü bunu gölgelediği için imajdan atılır (~22M).
RUN rm -rf /app/data
# Seed veritabanları: entrypoint açılışta bunları /app/data volume'üne kopyalar # Seed veritabanları: entrypoint açılışta bunları /app/data volume'üne kopyalar
COPY data/ ./seed/ COPY data/ ./seed/
# Migration'lar: entrypoint açılışta db-goc.mjs ile volume'deki app.db'ye uygular
COPY drizzle ./drizzle
COPY scripts/db-goc.mjs ./scripts/db-goc.mjs
COPY scripts/docker-entrypoint.sh ./docker-entrypoint.sh COPY scripts/docker-entrypoint.sh ./docker-entrypoint.sh
# SQLite veri dizini # SQLite veri dizini

View File

@@ -22,6 +22,7 @@
"hooks": "@/hooks" "hooks": "@/hooks"
}, },
"registries": { "registries": {
"@skiper-ui": "https://skiper-ui.com/registry/{name}.json" "@skiper-ui": "https://skiper-ui.com/registry/{name}.json",
"@magicui": "https://magicui.design/r/{name}"
} }
} }

View File

@@ -0,0 +1,65 @@
---
baslik: Bölüm mü, Üniversite mi, Şehir mi? Üçünü Nasıl Dengelersin?
aciklama: İyi üniversitede kötü bölüm mü, sıradan üniversitede istediğin bölüm mü? Tercih döneminin en çok sorulan sorusu — karar sırası tek şemada.
tarih: 2026-08-03
---
Tercih döneminde herkesin bir cümlesi var: "Bölüm her şeydir", "Hayır, üniversite markası her şeydir", "Asıl şehir önemli". Üçü de eksik. Bu üç başlığın **hangi durumda hangisinin öne geçtiği** belli bir sıraya oturur ve bu sıra herkes için aynı değildir.
## Karar sırası
```mermaid
%% aria: Bölüm üniversite şehir dengesi şeması. İlk soru mesleğin diplomaya bağlı olup olmadığıdır. Tıp, diş hekimliği, eczacılık, hukuk, öğretmenlik gibi diploma kilidi olan alanlarda bölüm her şeyin önündedir; sonra şehir, en son üniversite adı gelir. Diploma kilidi yoksa ikinci soru bölümün ne kadar net olduğudur. Bölüm netse üniversitenin o bölümdeki kadrosu ve akreditasyonu belirleyicidir. Bölüm net değilse geniş kampüs, çift anadal ve yatay geçiş imkânı olan üniversite öne geçer. Her üç yolda da şehir maliyeti ve barınma son filtredir; bütçe tutmuyorsa satır listeye girmez.
%% altyazi: Sıralama herkes için aynı değil — önce mesleğin diplomaya bağlı olup olmadığına bak.
flowchart TD
A{"Hedeflediğin meslek<br/>belirli bir diplomaya<br/>bağlı mı?"}
A -- "evet: tıp, diş, eczacılık,<br/>hukuk, öğretmenlik..." --> B("Önce BÖLÜM<br/>sonra şehir<br/>en son üniversite adı")
A -- "hayır: mühendislik,<br/>işletme, sosyal bilimler..." --> C{"Bölümün<br/>kafanda net mi?"}
C -- "net" --> D("Önce o bölümün KADROSU<br/>ve akreditasyonu<br/>sonra şehir")
C -- "net değil" --> E("Önce GENİŞ ÜNİVERSİTE:<br/>çift anadal, yatay geçiş,<br/>bölüm çeşitliliği")
B --> F{"Şehir ve barınma<br/>maliyeti 4 yıl boyunca<br/>karşılanabilir mi?"}
D --> F
E --> F
F -- "evet" --> G("Satır listeye girer")
F -- "hayır" --> H("Satırı yazma:<br/>yerleşirsen kayıt<br/>yaptıramazsın")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class B,D,G garanti
class C,E,F uyari
class H hayal
```
## 1) Bölümün diploma kilidi var mı?
Bazı meslekleri **yalnızca o diplomayla** yapabilirsin. [Tıp](/bolum/tip), [Diş Hekimliği](/bolum/dis-hekimligi), [Eczacılık](/bolum/eczacilik), [Hukuk](/bolum/hukuk), [Hemşirelik](/bolum/hemsirelik), [Fizyoterapi ve Rehabilitasyon](/bolum/fizyoterapi-ve-rehabilitasyon), öğretmenlik programları böyledir. Bu alanlarda tartışma biter: **bölüm birinci sıradadır.** Sıralaman iki programa da yetiyorsa aralarında üniversiteye göre seçersin, ama "iyi üniversitede başka bölüm" bu grupta bir alternatif değildir — çünkü diploma mesleğin kapısıdır.
Diploma kilidi olmayan alanlarda ise mezuniyet sonrası yollar çatallanır. [İşletme](/bolum/isletme), [İktisat](/bolum/iktisat), [Sosyoloji](/bolum/sosyoloji), [Uluslararası İlişkiler](/bolum/uluslararasi-iliskiler) mezunlarının gittiği yer büyük ölçüde stajlar, ikinci diller ve üniversitenin ağıyla belirlenir. Burada üniversitenin ağırlığı gerçekten artar.
## 2) Üniversiteyi "marka" olarak değil, "o bölümdeki hâli" olarak oku
Bir üniversite bir bölümünde çok güçlü, diğerinde vasat olabilir. Marka ismi yerine şunlara bak:
- **Bölümün öğretim üyesi sayısı ve unvan dağılımı.** Üniversitenin bölüm sayfasındaki akademik kadro listesi bunu doğrudan gösterir. Beş kişilik kadroyla yürüyen bir mühendislik bölümüyle otuz kişilik kadro aynı şey değildir.
- **Akreditasyon.** Mühendislikte MÜDEK, eğitim fakültelerinde EPDAD gibi program akreditasyonları, o bölümün belirli bir eğitim standardını sağladığının dışarıdan onayıdır. Üniversitenin bölüm sayfasında yazar.
- **Ders katalogu.** Neredeyse her üniversitenin Bologna/ders kataloğu sayfası vardır; dört yıl boyunca hangi dersleri alacağını orada satır satır okuyabilirsin. Aynı adlı iki bölümün müfredatı şaşırtıcı derecede farklı olabilir.
- **Taban sıralamanın söyledikleri.** Bir programın tabanı, piyasanın o programa biçtiği değerin toplamıdır. İki üniversite arasında kararsızsan tabanlar sana toplumun ortalama kanaatini söyler — ama bunu tek başına değil, yukarıdaki üç maddeyle birlikte oku. [Taban sıralamalar yıldan yıla nasıl değişir](/rehber/taban-siralamalar-nasil-degisir) yazısı bu okumanın sınırlarını anlatıyor.
## 3) Şehir bir "tercih kriteri" değil, bir "geçerlilik filtresi"
Şehri en sona bıraktık ama en zayıf kriter olduğu için değil — **eleyici** olduğu için. Şehir şu üç şeyi belirler:
1. **Toplam maliyet.** Kira, yurt, ulaşım ve yemek dört yıla vurulduğunda okulun kendisinden büyük bir kalem olur. [Yurt, burs ve yıllık maliyet](/rehber/yurt-burs-ve-yillik-maliyet) yazısında bunu satır satır hesaplıyoruz.
2. **Staj ve yarı zamanlı iş erişimi.** Mühendislik, [Mimarlık](/bolum/mimarlik), medya, [Gazetecilik](/bolum/gazetecilik) gibi alanlarda sektörün fiziksel olarak bulunduğu şehir, öğrencilik yıllarında ciddi bir avantajdır.
3. **Dört yıl orada yaşayacak olman.** İklimi, eve uzaklığı, sosyal hayatı sana uymayan bir şehirde okulu bırakma ihtimali gerçek bir risktir.
Şehri "istediğim şehirde okumak istiyorum" diye en başa koyarsan, listeni gereksiz yere daraltırsın. En sona koyarsan da bütçeyi patlatırsın. Doğru yeri **filtre**: bölüm ve üniversite sıralamanı yaptıktan sonra, karşılayamayacağın şehirdeki satırları listeden çıkar.
## Sık düşülen üç tuzak
- **"Puanım boşa gitmesin" tuzağı.** Sıralaman yetiyor diye istemediğin bir bölümü listenin üstüne yazmak, en pahalı hatadır: ÖSYM seni yerleşebildiğin **en üst** tercihe koyar, o satır tutarsa aşağıdaki gerçek tercihlerin hiç okunmaz. [Merkezi yerleştirme nasıl çalışır](/rehber/merkezi-yerlestirme-nasil-calisir) yazısı bu mekanizmayı anlatıyor.
- **"Sonra yatay geçerim" tuzağı.** Yatay geçiş gerçek bir yoldur ama garanti değildir — koşulları ve kontenjanı vardır. Planını üstüne kurma; [yatay geçiş, ÇAP ve yandal](/rehber/yatay-gecis-cap-yandal) yazısı gerçekçi sınırları çiziyor.
- **"Üniversitenin adı beni taşır" tuzağı.** Köklü bir üniversitenin zayıf bir bölümünde dört yıl geçirmek, mezuniyette beklediğin kapıyı açmayabilir. Marka değil, **o bölümün o üniversitedeki hâli** taşır.
Sıralamana hangi bölümüniversiteşehir kombinasyonlarının düştüğünü tek ekranda görmek için [tercih robotuna](/tercih-robotu) sıralamanı gir; şehir ve devlet/vakıf filtreleriyle üç ekseni ayrı ayrı deneyebilirsin.

View File

@@ -0,0 +1,73 @@
---
baslik: Bir Bölümün İş İmkânını Nasıl Araştırırsın? (Duyduklarına Değil, Kaynağa Bakma Rehberi)
aciklama: Bu bölüm iş bulur mu sorusunun cevabı forumda değil. Bir bölümün mezuniyet sonrasını beş adımda kendin araştırma yöntemi — tek şemada.
tarih: 2026-07-28
---
"Bu bölüm iş bulur mu?" tercih döneminin en çok sorulan, en kötü cevaplanan sorusu. Forumlarda gördüğün cevaplar birkaç kişinin kendi hikâyesidir; akrabaların söyledikleri on yıl öncesinin piyasasıdır. İyi haber şu: bu soruyu **kendin araştırabilirsin** ve gereken kaynakların hepsi açık. Bu yazı yöntemi veriyor — hangi bölüm olursa olsun işleyen bir yöntem.
## Beş adımlı araştırma
```mermaid
%% aria: Bölüm araştırma yöntemi şeması, beş adım. Birinci adım mesleğin kapısının nasıl açıldığını anlamaktır: diploma tek başına yetiyor mu, üstüne bir sınav mı gerekiyor, yoksa serbest bir alan mı. İkinci adım o kapının darlığını ölçmektir: sınav varsa kaç kişi giriyor kaç kişi geçiyor, kontenjan ne kadar. Üçüncü adım bölümün müfredatını okumaktır: üniversitenin ders kataloğunda dört yıl boyunca alacağın dersler satır satır yazar. Dördüncü adım arz tarafına bakmaktır: bu bölümden Türkiye genelinde yılda kaç kişi mezun oluyor ve kontenjan artıyor mu azalıyor mu. Beşinci adım gerçek insanlarla konuşmaktır: mezunların gittiği yerleri incelemek ve iki üç mezunla konuşmak. Bu beş adımın sonunda karar duyduklarına değil kaynağa dayanır.
%% altyazi: Sıra önemli: önce mesleğin kapısı, en son insan hikâyeleri.
flowchart TD
A1("1. Kapı nasıl açılıyor?<br/>diploma tek başına mı,<br/>üstüne sınav mı,<br/>serbest alan mı") --> A2("2. Kapı ne kadar dar?<br/>kaç kişi giriyor,<br/>kaç kişi geçiyor")
A2 --> A3("3. Müfredatı oku<br/>üniversitenin ders katalogu<br/>4 yılda ne öğreneceksin")
A3 --> A4("4. Arz tarafı<br/>yılda kaç mezun veriliyor,<br/>kontenjan artıyor mu")
A4 --> A5("5. İnsanla konuş<br/>mezunlar nereye gitmiş,<br/>2-3 kişiyle görüş")
A5 --> S{"Beş adımın sonunda"}
S -- "cevaplar tutarlı" --> K("Karar kaynağa dayanıyor")
S -- "hâlâ belirsiz" --> B("Belirsizlik gerçek:<br/>listeye alternatif de koy")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
class K garanti
class S,B uyari
```
## Adım 1: Mesleğin kapısı nasıl açılıyor?
Bölümler mezuniyet sonrasıısından üçe ayrılır ve bu ayrım her şeyden önemlidir:
- **Diploma doğrudan yetki verir.** [Tıp](/bolum/tip), [Diş Hekimliği](/bolum/dis-hekimligi), [Eczacılık](/bolum/eczacilik), [Hemşirelik](/bolum/hemsirelik), [Veteriner](/bolum/veteriner), [Fizyoterapi ve Rehabilitasyon](/bolum/fizyoterapi-ve-rehabilitasyon) gibi. Mesleği yapmak için diploma gereklidir; uzmanlaşma veya kamuda çalışma için ayrıca sınav olabilir.
- **Diplomanın üstüne bir kapı sınavı var.** [Hukuk](/bolum/hukuk) mezunu için staj ve baro süreci, öğretmenlik programları için atama sınavı, kamuda çalışmak isteyen [Kamu Yönetimi](/bolum/kamu-yonetimi) veya [İktisat](/bolum/iktisat) mezunu için merkezi sınavlar gibi. Burada kritik soru bölümün kendisi değil, **o kapının genişliğidir.**
- **Kapı serbest, ölçü senin portföyün.** [Bilgisayar Mühendisliği](/bolum/bilgisayar-muhendisligi), [Yazılım Mühendisliği](/bolum/yazilim-muhendisligi), [İşletme](/bolum/isletme), [Radyo, Televizyon ve Sinema](/bolum/radyo-televizyon-ve-sinema) gibi alanlarda diploma bir başlangıçtır; işveren staja, projeye, portföye bakar.
Bu üç grubun "iş imkânı" sorusuna cevabı bambaşkadır. İkinci gruptaki bir bölümü değerlendirirken bölümün kalitesine değil, **atama/geçiş oranlarına** bakman gerekir.
## Adım 2: Kapı ne kadar dar?
Sınavla açılan bir kapı varsa sayıları ara: o alanda yılda kaç kişi sınava giriyor, kaç kişi geçiyor, kaç kadro açılıyor? Bu veriler ilgili kurumun (bakanlık, meslek odası, sınavı yapan kurum) kendi duyurularında yayımlanır ve genelde yıllara göre karşılaştırılabilir.
Burada dikkat: **rakamı bul, yorumu sonra yap.** "Atama yok" ile "geçen yıl şu kadar kadro açıldı, şu kadar mezun vardı" arasında dağlar kadar fark var. İkincisi karar verilebilir bir bilgidir.
## Adım 3: Müfredatı gerçekten oku
Neredeyse her üniversitenin ders kataloğu (Bologna bilgi paketi) açıktır. Bölüm sayfasından "ders planı" veya "müfredat" bağlantısını bul ve **sekiz yarıyılın dersini de oku.** Bu on beş dakika, bölüm hakkında forumlarda geçireceğin on saatten fazlasını anlatır.
Bakman gerekenler:
- Derslerin ağırlığı beklentine uyuyor mu? Adı aynı olan iki bölümden biri ağırlıklı matematik, diğeri ağırlıklı tasarım olabilir.
- Zorunlu staj var mı, kaç gün?
- Seçmeli ders havuzu ne kadar geniş? Geniş havuz, alan içinde yön değiştirme imkânı demektir.
- Bölümün akreditasyonu var mı? Mühendislikte MÜDEK, eğitimde EPDAD gibi program akreditasyonları üniversitenin bölüm sayfasında ilan edilir.
## Adım 4: Arz tarafına bak
Bir alanın doygunluğunu anlamanın en sade yolu: **Türkiye genelinde o bölümden yılda kaç kişi mezun oluyor?** Kontenjan tarafı bunun iyi bir göstergesidir — aynı bölümün kaç üniversitede açık olduğuna ve toplam kontenjanına bakabilirsin. Kontenjanı hızla artan bir bölümde, bugünün mezun sayısıyla dört yıl sonrakinin aynı olmayacağını hesaba kat.
Tabanların yıllar içindeki seyri de bu tabloyu okur: bir bölümün tabanı birkaç yıl üst üste gevşiyorsa, talep tarafında bir şey değişiyor demektir. [Taban sıralamalar yıldan yıla ne kadar değişir](/rehber/taban-siralamalar-nasil-degisir) yazısı bu okumanın nasıl yapılacağını ve sınırlarını anlatıyor.
## Adım 5: İnsanla konuş — ama doğru soruyu sorarak
En son adım bu, çünkü ilk dördü olmadan sorduğun sorular yüzeysel kalır. İki kaynak:
- **Mezunların gittiği yerler.** Meslek ağlarında üniversite + bölüm araması yapıp mezunların bugün ne iş yaptığına bakmak, tek tek hikâyelerden çok daha sağlıklı bir dağılım verir.
- **İki-üç mezunla konuşmak.** "Memnun musun?" diye sorma; şunları sor: *İlk işini nasıl buldun? Okuduğun derslerden hangisi işine yaradı? Bugün yeniden seçsen ne değiştirirdin?* Bu üç soru, on dakikada gerçek bilgi verir.
## Cevap belirsiz kaldıysa ne yapmalı?
Bazı alanlarda dört yıl sonrası dürüstçe belirsizdir — ve bu, o bölümü kötü yapmaz. Belirsizlikle baş etmenin tercih listesindeki karşılığı şu: **listeye alternatif de koy.** İstediğin bölümü üst bloğa yaz, ama alt bloğa da seni memnun edecek ikinci ve üçüncü seçenekleri diz. [Tercih listesi nasıl yapılır](/rehber/tercih-listesi-nasil-yapilir) yazısındaki hayaldengeligaranti dağılımı tam olarak bu belirsizliği yönetmek için var.
Bir de bölümlerin kendi sayfalarına bak: [bölüm kataloğunda](/bolumler) her bölümün hangi üniversitelerde açık olduğunu, taban sıralamalarını ve program sayısını görebilir, araştırmanın dördüncü adımını dakikalar içinde tamamlayabilirsin. Sıralamana hangi bölümlerin düştüğünü görmek içinse [tercih robotuna](/tercih-robotu) sıralamanı gir.

View File

@@ -0,0 +1,53 @@
---
baslik: Devlet mi Vakıf mı? Burslu ve İndirimli Programlar Nasıl Okunur?
aciklama: Aynı bölümün beş farklı fiyat etiketi var — burslu, indirimli, ücretli... Vakıf tablosunu doğru okumanın rehberi, tek şemada.
tarih: 2026-07-19
---
Tercih tablolarında aynı bölümün adı beş kez geçebilir: *Psikoloji (Burslu)*, *Psikoloji (%50 İndirimli)*, *Psikoloji (%25 İndirimli)*, *Psikoloji (Ücretli)*, *Psikoloji (İngilizce)*. Bunlar ayrı programlardır: ayrı kontenjan, ayrı taban, ayrı fiyat. Bu yazı tabloyu doğru okumayı ve devlet-vakıf kararını sağlıklı vermeyi anlatıyor.
## Varyantlar ne anlama geliyor?
```mermaid
%% aria: Vakıf program varyantları şeması: aynı bölüm adı altında burslu yüzde yüz, yüzde elli veya yirmi beş indirimli ve ücretli programlar ayrı kontenjan ve ayrı tabanla listelenir. Burslu genelde en sıkı tabana sahiptir ve devletlerle yarışır; indirimli orta bütçe ister; ücretli en geniş tabanlıdır ama aile bütçesine uymuyorsa yazılmamalıdır. İngilizce veya UOLP etiketi burs bilgisi değil öğretim dili bilgisidir.
%% altyazi: Aynı bölüm adı beş kez geçebilir — her satır ayrı program, ayrı fiyat, ayrı tabandır.
flowchart TD
B("Aynı bölüm adı<br/>tabloda birkaç kez geçer") --> V{"Hangi etiket?"}
V -- "%100 burslu" --> BU("Ücret yok<br/>taban genelde en sıkı,<br/>devletlerle yarışır")
V -- "%50 / %25 indirimli" --> IN("Kısmi ücret<br/>toplam maliyeti baştan hesapla")
V -- "ücretli" --> UC("Tam ücret<br/>taban genelde en geniş")
V -- "İngilizce / UOLP" --> DI("Burs değil, dil bilgisi<br/>hazırlık yılı ekleyebilir")
UC --> K{"Bütçe gerçekten uygun<br/>ve okulu istiyor musun?"}
K -- "evet" --> YAZ("Listeye yaz")
K -- "hayır" --> YAZMA("Yazma:<br/>yerleşirsen ek hakkın yanar")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class BU,YAZ garanti
class IN,DI uyari
class YAZMA hayal
```
- **Burslu (%100):** Öğrenim ücreti yok. Vakıfların vitrini olduğu için tabanı çoğu zaman aynı üniversitenin ücretli programından *yüz binlerce sıra* daha iyidir; köklü devletlerle yarışır.
- **%50 / %25 indirimli:** Ücretin o oranı düşülür. Kalan tutar yıllara ve okula göre ciddi bir bütçedir; 4-6 yıllık toplam maliyeti baştan hesapla.
- **Ücretli:** Tam ücret. Tabanlar genelde en geniştir.
- **İngilizce / UOLP:** Öğretim dili veya ortak program bilgisidir; burs bilgisi değildir. Hazırlık yılı ekleyebilir.
Kritik uyarı: **bursun sürme koşullarını** üniversitenin kendi yönetmeliğinden kontrol et. Çoğu vakıfta giriş bursu süresizdir ama bazı okullarda not ortalaması şartı vardır.
## Devlet-vakıf kararında gerçek kriterler
**Bütçe dışında** şunlara bak:
1. **Kadro ve bölümün kurumsallığı.** Bölümün öğretim üyesi sayısı, araştırma çıktısı, akreditasyonu (MÜDEK, PSİKOLOG odaklı akreditasyonlar vb.) devlet-vakıf etiketinden daha belirleyicidir.
2. **Şehir ve yaşam maliyeti.** Devlet okulu + büyükşehir kirası, bazen vakıf burslusu + yurt kombinasyonundan pahalıya gelir. Toplam maliyeti karşılaştır.
3. **Tabanın söylediği.** Bir vakıf burslusunun tabanı köklü devletlerle aynıysa, piyasa o programa devlet muadili değer biçiyor demektir. [İşletme](/bolum/isletme) veya [Psikoloji](/bolum/psikoloji) tablolarını aç; Tür kolonunda devlet/vakıf ayrımını, satır altlarında burs varyantlarını yan yana görüp kendi sıralamanla kıyaslayabilirsin.
## Listede nasıl konumlanır?
- Burslu vakıf programları taban olarak "hayal/dengeli" bölgene düşüyorsa devlet alternatifleriyle **aynı blokta, istek sırana göre** diz — ayrı kefeye koyma.
- İndirimli programlarda aileyle net bütçe konuşmasını *listeyi vermeden önce* yap; yerleştikten sonra "ödeyemeyiz" durumu bir yıl kaybettirir.
- Ücretli programı yalnızca bütçe gerçekten uygunsa ve o okulu gerçekten istiyorsan yaz — "garanti olsun" diye yazılan ücretli program, kayıt yaptırmayacaksan [ölü tercihten](/rehber/olu-tercih-nedir) beterdir: yerleşirsen ek tercih hakkın da yanar.
Sıralamana hangi devlet ve vakıf programlarının düştüğünü tek ekranda görmek için [tercih robotuna](/tercih-robotu) sıralamanı gir; devlet/vakıf filtresiyle iki evreni ayrı ayrı da tarayabilirsin.

View File

@@ -0,0 +1,55 @@
---
baslik: Ek Yerleştirme Nedir? 2026 Ek Tercih Rehberi
aciklama: İlk yerleştirmede boşta kaldıysan oyun bitmedi — kimlerin başvurabileceği ve ikinci şansı doğru kullanmanın yolu tek şemada.
tarih: 2026-07-22
---
Merkezi yerleştirme sonuçlarııklandığında bir programa yerleşememiş olmak yılın sonu değildir. Üniversiteler kayıt dönemini kapattığında binlerce kontenjan boş kalır ve ÖSYM bu boş kontenjanlar için **ek yerleştirme** (ek tercih) süreci açar.
## Ek yerleştirme ne zaman?
Kayıtlar tamamlandıktan sonra, genellikle **Eylül ayı içinde**. ÖSYM önce boş kontenjanları içeren Ek Yerleştirme Kılavuzu'nu yayımlar, ardından birkaç günlük tercih penceresi açılır. Kesin tarihler her yıl ÖSYM duyurusuyla netleşir — tercih takviminin tamamı için [YKS 2026 tercih takvimi](/rehber/yks-tercih-takvimi-2026) yazısına bak.
## Kimler başvurabilir?
```mermaid
%% aria: Ek yerleştirme başvuru şeması: ilk yerleştirmede hiçbir programa yerleşemediysen veya hiç tercih yapmadıysan ek yerleştirmeye başvurabilirsin; Eylül'de kılavuz yayımlanınca yeni bir 24 tercihlik liste kurarsın. İlk turda herhangi bir programa yerleştiysen — kayıt yaptırmasan bile — ek yerleştirme kapısı kapalıdır.
%% altyazi: Kritik kural: yerleşmiş sayılmak ek kapıyı kapatır; kayıt yaptırmamak bu durumu değiştirmez.
flowchart TD
S{"İlk yerleştirmede<br/>ne oldu?"}
S -- "hiçbir programa yerleşemedin<br/>ya da hiç tercih yapmadın" --> A("Ek yerleştirme hakkın var:<br/>Eylülde yeni 24 tercih")
A --> L("Kılavuzdaki boş kontenjanlardan<br/>gerçekçi bir liste kur")
S -- "bir programa yerleştin<br/>kayıt yaptırmasan bile" --> K("Kapı kapalı:<br/>ek yerleştirmeye giremezsin")
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class A,L garanti
class K hayal
```
Kurallar nettir ve en kritik olanı şudur:
- **İlk yerleştirmede herhangi bir programa yerleşen aday, kayıt yaptırmasa bile ek yerleştirmeye başvuramaz.** "Yerleştim ama gitmeyeceğim, ek tercihte daha iyisini denerim" diye bir yol yoktur.
- Ek yerleştirme yalnızca ilk yerleştirmede **hiçbir programa yerleşememiş** adaylara açıktır.
- İlk dönemde hiç tercih yapmamış adaylar da ek yerleştirmeye katılabilir.
Bu kural, ilk listenin sonuna "kayıt yaptırmayacağım ama boşta da kalmayayım" mantığıyla program yazmanın neden tehlikeli olduğunu gösterir: oraya yerleşirsen ek tercih hakkın yanar. Bu tuzağın detayı [tercih listesi rehberinde](/rehber/tercih-listesi-nasil-yapilir).
## Ek yerleştirmede taban nasıl işler?
Ek yerleştirmede bir programa başvurabilmek için o programın **ilk yerleştirmedeki taban puanına eşit veya daha yüksek** puana sahip olman gerekir (ilk yerleştirmede hiç dolmayan programlarda bu şart esner). Yani ek tercih "tabanlar sıfırlanır, herkes her yere yazılır" demek değildir.
## Boş kontenjanlar nereden çıkar?
- İlk yerleştirmede hiç dolmayan programlar (çoğunlukla vakıf ücretli ve bazı önlisans programları),
- Yerleşip kayıt yaptırmayan adaylardan boşalan yerler.
Boş kontenjan listesi ağırlıklı olarak vakıf üniversiteleri, ücretli/indirimli varyantlar ve önlisans programlarından oluşur; ama her yıl devlet üniversitelerinden de şaşırtıcı fırsatlar çıkar. Hangi bölümlerde kontenjanların geniş olduğuna dair fikir edinmek için [tüm bölümlerin taban puanları](/bolumler) sayfasındaki kontenjan kolonlarına göz at.
## Ek tercih stratejisi
1. **Kılavuzu bekleme, hazırlığını şimdi yap.** Sıralamana uygun program evrenini [tercih robotuyla](/tercih-robotu) önceden çıkar; kılavuz yayımlanınca sadece kesişimi almak kalır.
2. **İlk yerleştirme mantığıyla kurma.** Ek yerleştirmede tek liste hakkın var ve pencere kısa; dengeli-garanti ağırlıklı, gerçekçi bir liste kur.
3. **Kayıt yaptırmayacağın programı yine yazma.** Aynı kural burada da geçerli — ek yerleştirmeden sonra üçüncü bir şans yok.
Ek yerleştirme, ilk turda şanssızlık yaşayanlar için gerçek bir ikinci şanstır; panik turu değil. Veriyle ve soğukkanlı kurulmuş bir ek liste, aceleyle yazılmış ilk listeden daha iyi sonuç verebilir.

View File

@@ -0,0 +1,65 @@
---
baslik: Hazırlık Sınıfı ve Öğretim Dili — (İngilizce), (%30 İngilizce) Ne Demek?
aciklama: Program adının yanındaki dil etiketi ne anlatıyor, hazırlık zorunlu mu, atlanabilir mi, bir yıl uzar mı? Dil kararının tamamı tek şemada.
tarih: 2026-07-31
---
Tercih tablosunda aynı bölümü üç farklı etiketle görürsün: *Bilgisayar Mühendisliği*, *Bilgisayar Mühendisliği (İngilizce)*, *Bilgisayar Mühendisliği (%30 İngilizce)*. Bu etiket **öğretim dilini** anlatır; burs ya da kalite bilgisi değildir. Ama okuma sürene, hazırlık yılına ve mezuniyetteki dil seviyene doğrudan etki eder — yani listede yerini bilerek belirlemen gerekir.
## Etiketten hazırlığa: karar akışı
```mermaid
%% aria: Öğretim dili ve hazırlık sınıfı akış şeması. Program adının yanındaki etiket önce okunur. Tamamen İngilizce programlarda derslerin tamamı İngilizcedir ve hazırlık sınıfı genellikle zorunludur. Yüzde otuz İngilizce programlarda derslerin bir kısmı İngilizcedir ve hazırlık üniversiteye göre zorunlu veya isteğe bağlı olabilir. Türkçe programlarda hazırlık genelde isteğe bağlıdır. Hazırlık zorunluysa yıl başında yapılan yeterlik yani muafiyet sınavına girilir. Sınav geçilirse doğrudan birinci sınıftan başlanır. Geçilemezse bir yıl hazırlık okunur ve bu yıl normal öğrenim süresine dahil değildir. Hazırlık sonunda yine başarısız olunursa üniversitenin yönetmeliğine göre ek süre veya Türkçe eşdeğer programa geçiş gündeme gelir; bu koşullar okuldan okula değiştiği için kılavuzdan ve üniversitenin yönetmeliğinden doğrulanmalıdır.
%% altyazi: Dil etiketi süreyi değiştirir: hazırlık yılı normal öğrenim süresine dahil değildir.
flowchart TD
E{"Program adının<br/>yanındaki etiket"}
E -- "İngilizce" --> I("Dersler tamamen İngilizce<br/>hazırlık genelde ZORUNLU")
E -- "%30 İngilizce" --> O("Derslerin bir kısmı İngilizce<br/>hazırlık okula göre değişir")
E -- "etiket yok" --> T("Türkçe program<br/>hazırlık genelde İSTEĞE BAĞLI")
I --> M{"Yıl başındaki yeterlik<br/>muafiyet sınavı"}
O --> M
M -- "geçtin" --> B("Doğrudan 1. sınıf<br/>süre uzamaz")
M -- "geçemedin" --> H("1 yıl hazırlık<br/>normal süreye dahil DEĞİL")
H --> S{"Hazırlık sonu<br/>başarı"}
S -- "başardın" --> B
S -- "başaramadın" --> U("Üniversitenin yönetmeliğine göre:<br/>ek süre veya Türkçe<br/>eşdeğer programa geçiş")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class B,T garanti
class M,S,H,O uyari
class U hayal
```
## Etiketler ne anlatıyor?
- **(İngilizce):** Programdaki derslerin tamamına yakını İngilizce işlenir. Bu programlarda hazırlık sınıfı çoğunlukla zorunludur; yeterlik sınavını geçemezsen bir yıl hazırlık okursun.
- **(%30 İngilizce):** Derslerin belirli bir bölümü İngilizce, geri kalanı Türkçedir. Hazırlığın zorunlu mu isteğe bağlı mı olduğu üniversiteden üniversiteye değişir — bunu ÖSYM kılavuzundaki program koşullarından ve üniversitenin kendi yönetmeliğinden doğrulaman gerekir.
- **Etiketsiz program:** Türkçe öğretim yapılır. Çoğu üniversitede isteğe bağlı hazırlık imkânı yine de vardır.
- **UOLP / ortak program:** Yurt dışındaki bir üniversiteyle yürütülen ortak programdır. Dil etiketinden ayrı bir şeydir; kendi koşulları, kendi ücretlendirmesi ve genelde yurt dışında geçirilecek dönemleri vardır. Kılavuzdaki açıklama maddelerini satır satır okumadan bu satırları listeye yazma.
Kritik nokta: **etiket bir kalite göstergesi değildir.** Aynı üniversitenin Türkçe ve İngilizce programı arasındaki taban farkı, çoğu zaman eğitim kalitesi farkını değil, adayların dil tercihini yansıtır.
## Hazırlık yılı süreyi uzatır mı?
Hazırlık sınıfı **normal öğrenim süresine dahil değildir.** Yani dört yıllık bir lisans programında hazırlık okursan toplam beş yıl kampüste olursun, ama azami öğrenim süren dört yıl üzerinden işlemeye hazırlıktan sonra başlar. Pratik sonuç: hazırlık, mezuniyetini bir yıl öteler.
Bu bir yıl kayıp mı? Cevap tamamen sana bağlı:
- **Dilin zaten iyiyse** yeterlik sınavını geçip doğrudan birinci sınıftan başlarsın; hiçbir şey uzamaz. Bu sınav yıl başında yapılır ve girmek ücretsizdir — kaybedecek bir şeyin yok.
- **Dilin zayıfsa ve hedefin dilin ağır bastığı bir alansa** ([Bilgisayar Mühendisliği](/bolum/bilgisayar-muhendisligi), [Yazılım Mühendisliği](/bolum/yazilim-muhendisligi), [Uluslararası İlişkiler](/bolum/uluslararasi-iliskiler), [Endüstri Mühendisliği](/bolum/endustri-muhendisligi)) hazırlık yılı büyük ihtimalle hayatındaki en verimli yatırımlardan biridir. Bu alanlarda kaynakların, dokümantasyonun ve iş ilanlarının çoğu İngilizcedir.
- **Dilin zayıfsa ve alanın ağırlıklı olarak Türkçe yürüyorsa** ([Hukuk](/bolum/hukuk), [Sınıf Öğretmenliği](/bolum/sinif-ogretmenligi), [Türkçe Öğretmenliği](/bolum/turkce-ogretmenligi), sağlık meslek programlarının çoğu) hazırlığı zorunlu kılan bir programı sırf etiket için tercih etmenin getirisi sınırlıdır.
## Hazırlıkta başarısız olursam?
Bu, tercih öncesinde en az konuşulan ama en çok korkulan konu. Genel çerçeve şu: hazırlık sonunda yeterlik sağlanamazsa üniversitenin yönetmeliği devreye girer. Bazı üniversiteler ek süre veya yaz okulu tanır; bazılarında ise Türkçe eşdeğer bir programa geçiş imkânı gündeme gelir. **Bu koşullar okuldan okula ciddi biçimde değişir** — tercih etmeyi düşündüğün üniversitenin "Yabancı Diller Yüksekokulu" veya "Hazırlık Sınıfı Yönetmeliği" sayfasınııp okumak on dakika sürer ve seni yıllarca ilgilendirir.
## Listede nasıl konumlanır?
- İngilizce ve Türkçe programı **ayrı satır** olarak düşün: ayrı kontenjan, ayrı taban, ayrı program kodu.
- İkisini de istiyorsan ikisini de yaz; hangisini daha çok istiyorsan üste koy. Aralarındaki taban farkı sıralamana bağlı olarak ikisini de erişilebilir kılabilir.
- İngilizce programı **yalnızca hazırlık yılını göze alıyorsan** yaz. "Nasıl olsa muafiyet sınavını geçerim" varsayımıyla yazıp geçemezsen, yine de o yılı okursun.
- %30 İngilizce programlarda hazırlığın zorunlu olup olmadığını **program bazında** kontrol et; aynı üniversitenin iki bölümünde bile farklı olabilir.
Sıralamanla hangi dil varyantlarının açık olduğunu yan yana görmek için [tercih robotuna](/tercih-robotu) sıralamanı gir; aynı bölümün Türkçe ve İngilizce satırlarını tek listede karşılaştırabilirsin.

View File

@@ -0,0 +1,58 @@
---
baslik: Kaç Sıralama ile Hangi Bölüme Girebilirim? (2025 Verileriyle)
aciklama: 10 binden 1 milyona — sıralama bandına göre hangi bölümlerin gerçekçi olduğunun haritası ve nasıl okunacağı tek şemada.
tarih: 2026-07-23
---
"Sıralamam X, nereyi kazanırım?" tercih döneminin en çok sorulan sorusu. Aşağıdaki bantlar 2025 YKS yerleştirme verilerine (YÖK Atlas) dayanır ve **kabaca bir harita** çizer — kesin sınır değildir; aynı bölümün tabanı üniversiteye, şehre ve burs durumuna göre çok geniş bir aralığa yayılır.
```mermaid
%% aria: Sıralama bandı okuma şeması: önce kendi puan türünün sıralama bandını bulursun; bant sana hangi bölümlere bakmaya değer olduğunu söyler ama hangi üniversitede tutacağını söylemez. Sonra bölüm sayfasındaki tabloya inip kendi sıralamanın düştüğü programları görürsün; en hızlı yol tercih robotuna sıralamanı girip hayal, dengeli ve garanti dilimlerini tek bakışta almaktır. Bant pusuladır, garanti değildir.
%% altyazi: Bant "nereye bakayım" der; kesin satırı bölüm tablosu ve tercih robotu söyler.
flowchart TD
B("Sıralama bandını bul<br/>SAY, EA, sözel veya dil") --> N("Bant sana hangi bölümlere<br/>bakmaya değer olduğunu söyler")
N --> T{"Nasıl netleşir?"}
T -- "bölüm tablosuna in" --> TAB("Aynı bölümde tabanlar<br/>üniversiteye göre çok açılır")
T -- "tercih robotuna gir" --> R("Hayal / dengeli / garanti<br/>dilimleri saniyede çıkar")
TAB --> K("Bandına düşen satırları<br/>istek sırana göre diz")
R --> K
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
class N,TAB uyari
class R,K garanti
```
## Sayısal (SAY) için kaba harita
| Sıralama bandı | Gerçekçi seçenekler |
| --- | --- |
| İlk 5 bin | Köklü devletlerde [Tıp](/bolum/tip), [Bilgisayar Mühendisliği](/bolum/bilgisayar-muhendisligi), [Elektrik-Elektronik Mühendisliği](/bolum/elektrik-elektronik-muhendisligi) |
| 5-25 bin | Devlet tıp (yeni fakülteler), [Diş Hekimliği](/bolum/dis-hekimligi), iyi devletlerde mühendislikler |
| 25-75 bin | [Eczacılık](/bolum/eczacilik), devlet mühendislikleri, [Mimarlık](/bolum/mimarlik) |
| 75-200 bin | Sağlık bilimleri ([Fizyoterapi ve Rehabilitasyon](/bolum/fizyoterapi-ve-rehabilitasyon), [Hemşirelik](/bolum/hemsirelik)), Anadolu devletlerinde mühendislik |
| 200-500 bin | Fen bilimleri, ziraat, daha geniş kapatan mühendislikler, vakıf burslu seçenekleri |
| 500 bin+ | Açıköğretim dışı seçenekler daralır; önlisans (TYT) tarafı güçlü alternatif olur |
## Eşit Ağırlık (EA) için kaba harita
| Sıralama bandı | Gerçekçi seçenekler |
| --- | --- |
| İlk 10 bin | Köklü devletlerde [Hukuk](/bolum/hukuk), [Psikoloji](/bolum/psikoloji) |
| 10-50 bin | Devlet hukuk (geniş kapatanlar), [İşletme](/bolum/isletme) / [İktisat](/bolum/iktisat) (iyi devletler), Psikoloji |
| 50-150 bin | Anadolu devletlerinde İİBF bölümleri, [Rehberlik ve Psikolojik Danışmanlık](/bolum/rehberlik-ve-psikolojik-danismanlik) |
| 150-400 bin | Vakıf burslu/indirimli seçenekler, sosyal hizmet, kamu yönetimi |
Sözel ve Dil tarafında bantlar daha da geniştir; öğretmenlikler için ayrıca **başarı sıralaması şartı** devreye girer — detayı [Baraj ve başarı sıralaması şartları](/rehber/siralama-sartlari-2026) yazısında.
## Bu tabloyu nasıl kullanmalısın?
1. **Bandını bul, ama banda güvenme.** Bant sana "hangi bölümlere bakmaya değer" der; hangi üniversitede tutacağını söylemez. Aynı bölüm içinde tabanlar 10 kat oynayabilir.
2. **Bölüm sayfasının tablosuna in.** Örneğin [Psikoloji taban puanları](/bolum/psikoloji) sayfasında 380'e yakın programın tek tek tabanını görürsün — senin sıralaman listenin neresine düşüyorsa gerçekçi bölgen orasıdır.
3. **Kendi sıralamanla tara.** [Tercih robotuna](/tercih-robotu) sıralamanı gir; robot 23.000+ programın içinden senin bandına düşenleri hayal/dengeli/garanti dilimleriyle ayırıp önüne koyar. Tablo ezberlemekten hızlıdır.
## Unutma
- Sıralaman **puan türüne özeldir**; SAY sıralaman ile EA sıralaman farklıdır, her listeyi kendi türünün sıralamasıyla kur.
- Burslu/indirimli/İngilizce varyantların tabanları aynı bölümde bile çok farklıdır.
- 2026 tabanları bu yılın yerleştirmesiyle netleşir; buradaki veriler pusula, garanti değil.

View File

@@ -0,0 +1,50 @@
---
baslik: Merkezi Yerleştirme Nasıl Çalışır? ÖSYM Seni Nasıl Yerleştirir?
aciklama: "Üst sıraya yazarsam şansımı yakar mıyım?" korkusunun cevabı sistemin kendisinde. ÖSYM'nin yerleştirme mantığı, tek şemada ve öğrenci diliyle.
tarih: 2026-07-26
---
Tercih döneminin en çok aranan sorularından biri şu: *"Tercihler nasıl değerlendiriliyor? Üst sıraya iddialı bir bölüm yazarsam alttaki şansımı kaybeder miyim?"* Kısa cevap: **hayır, kaybetmezsin.** Nedenini anlamak için ÖSYM'nin yerleştirme mantığını bir kez görmek yeter — sistem sandığından çok daha basit çalışır.
## Sistem tek cümlede
ÖSYM önce **adayları** puana göre sıralar, sonra sıra sana gelince **senin listeni** yukarıdan aşağı okur ve boş kontenjan bulduğu ilk satıra seni yerleştirir. Hepsi bu.
```mermaid
%% aria: Merkezi yerleştirme akış şeması: ÖSYM tüm adayları puana göre sıralar ve sıra puanı yüksekten düşüğe ilerler; sıra sana gelince tercih listen birinci satırdan başlayarak kontrol edilir, boş kontenjan bulunan ilk programa yerleşirsin ve alttaki satırlara hiç bakılmaz; 24 satırın hiçbirinde yer yoksa boşta kalırsın ama ek yerleştirme hakkın devam eder.
%% altyazi: Sistem listene her zaman yukarıdan aşağı bakar; bir satıra yerleştiğin an alttaki satırlar devre dışı kalır.
flowchart TD
P("ÖSYM tüm adayları puana göre sıralar<br/>sıra, puanı yüksekten düşüğe ilerler") --> S("Sıra sana geldi:<br/>listen 1. satırdan okunmaya başlar")
S --> T1{"1. tercihinde boş<br/>kontenjan var mı?"}
T1 -- "evet" --> Y("Yerleştin<br/>alttaki satırlara hiç bakılmaz")
T1 -- "hayır" --> T2{"2. tercihinde<br/>boş yer var mı?"}
T2 -- "evet" --> Y
T2 -- "hayır" --> D("aynı soru 24. satıra<br/>kadar tekrarlanır")
D --> B{"24 satırın hiçbirinde<br/>yer kalmadı mı?"}
B -- "boşta kaldın" --> E("Üzülme, bitmedi:<br/>ek yerleştirme hakkın saklı")
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
class Y garanti
class E uyari
```
## Bu mantıktan çıkan üç altın kural
**1) Üst sıradaki "hayal" tercihi alttakilere zarar veremez.** Sistem 1. tercihinde yer bulamazsa hiç duraksamadan 2.'ye geçer. Hayal bölümünü en üste yazmanın tek "maliyeti" bir satırdır; alttaki dengeli ve garanti tercihlerinin ihtimali kılını bile kıpırdatmaz. Bu yüzden listenin başı gönlüne göre, sonu aklına göre kurulur — dilim mantığının tamamı [tercih listesi rehberinde](/rehber/tercih-listesi-nasil-yapilir) var.
**2) Yerleştiğin satırın altı yok hükmündedir.** 3. tercihine yerleştiysen 4-24 arası hiç okunmaz. Bu yüzden listeyi *yerleşme ihtimaline göre değil, istek sırana göre* dizmelisin: en çok istediğin hep daha üstte durmalı. "Daha çok istediğim bölüm alttaydı, keşke" cümlesinin telafisi yoktur.
**3) Taban sıralaması yerleştirme bittikten sonra oluşur.** Bir programın tabanı, o programa **yerleşen son kişinin** sıralamasıdır. Yani tabanlar önceden ilan edilen bir eşik değil, o yılın adaylarının tercih davranışının sonucudur — bu yüzden yıldan yıla oynar. Detayı [tabanlar nasıl değişir](/rehber/taban-siralamalar-nasil-degisir) yazısında.
## Peki neden hâlâ "ölü tercih" diye bir şey var?
Sistemin yukarıdan aşağı okuması, sıralamanın çok üstünde kapatan bir programı listenin *sonuna* yazmayı anlamsızlaştırır: o satıra sıra geldiyse zaten üstteki 20 satırda yer bulamamışsındır; tabanı senden çok iyi olan o program sana hiç açılmayacaktır. Bu satırlar listede yer kaplayan boş kurşunlardır — tanımı ve temizleme yöntemi için [ölü tercih nedir](/rehber/olu-tercih-nedir) yazısına bak.
## Pratik sonuç
- Listenin başına puanın "yetmeyecek gibi" duran ama çok istediğin programları çekinmeden yaz.
- Ortayı sıralamana yakın programlarla doldur, sona gerçekten razı olacağın garantileri koy.
- Sıralamanla hangi dilime neyin girdiğini görmek için [tercih robotuna](/tercih-robotu) sıralamanı girmen yeterli.
Sistemi bilen aday, listeyi korkuyla değil stratejiyle kurar. Korku listesi hep aşağı yığılır; strateji listesi yukarıdan kazanır.

View File

@@ -0,0 +1,47 @@
---
baslik: OBP Nedir, Nasıl Hesaplanır? Diploma Notu Kaç Puan Getirir?
aciklama: Ortaöğretim başarı puanının hesabı, yerleştirme puanına gerçek katkısı ve "geçen yıl yerleştiysen çarpan yarıya düşer" kuralı — sayılarla ve tek şemada.
tarih: 2026-07-27
---
Tercih döneminde en çok aranan hesap sorusu: *"Diploma notum yerleştirme puanıma kaç puan ekler?"* Cevap net bir formüle dayanır ve iki dakikada öğrenilir. Ama formülün ucunda, tercih stratejini doğrudan etkileyen bir kural saklı: **geçen yıl bir programa yerleşenlerin katkısı yarıya düşer.**
## Hesap üç adımda
Lise diploma notun 50-100 arasındadır. ÖSYM bunu 5 ile çarpar ve **OBP** (Ortaöğretim Başarı Puanı) 250-500 arasında bir değere dönüşür. Yerleştirme puanına eklenen katkı ise OBP'nin 0,12 ile çarpımıdır:
```mermaid
%% aria: OBP hesap şeması: 50 ile 100 arasındaki diploma notu 5 ile çarpılarak 250 ile 500 arasında OBP değerine dönüşür; OBP 0,12 ile çarpılarak 30 ile 60 puan arasında bir katkı üretir ve ham YKS puanına eklenerek yerleştirme puanını oluşturur; geçen yıl merkezi yerleştirmeyle bir programa yerleştiysen çarpan 0,06'ya düşer ve katkı 15 ile 30 puan arasına iner.
%% altyazi: Katkı aralığı 30-60 puandır; iki aday arasındaki gerçek fark ise çoğu zaman birkaç puandır çünkü herkes en az 30 alır.
flowchart TD
D("Diploma notun<br/>50 ile 100 arası") -- "5 ile çarpılır" --> O("OBP<br/>250 ile 500 arası")
O -- "0,12 ile çarpılır" --> K("Yerleştirme puanına katkı<br/>30 ile 60 puan arası")
K --> P("Ham YKS puanın + katkı<br/>= yerleştirme puanın")
O -. "geçen yıl bir programa yerleştiysen<br/>çarpan 0,06 olur" .-> Z("Katkı yarıya düşer<br/>15 ile 30 puan arası")
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class P garanti
class Z hayal
```
## Sayının doğru okuması: 60 değil, fark önemli
"60 puana kadar katkı" kulağa devasa gelir ama herkes **en az 30** alır (diploma notu 50 bile olsa). Yani seninle rakibin arasındaki gerçek OBP farkı en fazla 30 puandır ve diploma notları yakınsa bu fark birkaç puana iner. Diploma notu 85 olan bir aday 51 puan katkı alır; 95 olan 57 alır — arada sadece 6 puan vardır. OBP kimseyi tek başına bölüm atlatmaz; **eşit puan bölgesinde sıralamayı birkaç bin kaydırır.** Sıralamanın puandan neden daha önemli olduğu ayrı bir yazının konusu: [taban puan mı, sıralama mı?](/rehber/taban-puan-mi-siralama-mi)
## Kritik kural: çarpan neden yarıya düşer?
Geçen yıl merkezi yerleştirmeyle bir programa **yerleştirildiysen** — kayıt yaptırmamış olsan bile — bu yıl OBP çarpanın 0,12 yerine **0,06** uygulanır (kontenjansız açıköğretim programları bu kuralın dışındadır). Yani "bir yere yerleşeyim de garantim olsun, seneye yine denerim" planının görünmez bir bedeli vardır: gelecek yılki puanından 15-30 puan peşinen gider.
Bunun tercih listene çevirisi şudur: **yerleşsen bile gitmeyeceğin programı listene yazma.** Bu kuralın diğer bedelleriyle birlikte tamamı [tercih listesi rehberinde](/rehber/tercih-listesi-nasil-yapilir) anlatılıyor.
## Okul birincilerine ayrı kapı
Okul birincileri için üniversitelerde **ayrı bir kontenjan** ayrılır (2026'da yaklaşık 17 bin 862 kişilik). Okul birincisi, hem genel kontenjandan hem de okul birincisi kontenjanından değerlendirilir — hangisinden yerleşirse o geçerli olur. Ayrıca 2026'da şehit ve gazi yakınları ile 34 yaş üstü kadın adaylar için de özel kontenjanlar var; sonuç belgende bu kontenjanlardan birine hakkın görünüyorsa tercih ekranında ayrıca işaretlemeyi unutma.
## Özet
- OBP = diploma notu × 5; katkı = OBP × 0,12 → **30-60 puan arası.**
- Herkes en az 30 aldığı için gerçek rekabet farkı küçüktür; asıl belirleyici sınav performansın ve sıralamandır.
- Geçen yıl yerleştiysen çarpan yarıya düşer — istemediğin programı listeye yazmanın en somut cezası budur.
- Sıralamanla nereye uzanabildiğini görmek için [tercih robotunu](/tercih-robotu) kullanabilirsin.

View File

@@ -0,0 +1,48 @@
---
baslik: Ölü Tercih Nedir, Nasıl Anlaşılır? (Ve Nasıl Kaçınılır)
aciklama: Listende hiç işe yaramayan satırlar olabilir. Ölü tercihin iki biçimi ve temizleme yolu — tek şemada.
tarih: 2026-07-24
---
Ölü tercih, **hiçbir senaryoda seni yerleştirmeyecek satır** demektir. Listende durur, yer kaplar ama hiç işe yaramaz. 24 tercih hakkın varken bunun 5-6'sını ölü satırlara harcamak, tercih dönemi hatalarının en sessizidir — kimse fark etmez, ta ki sonuçlar açıklanana kadar.
## Ölü tercihin iki biçimi
```mermaid
%% aria: Ölü tercih tanı şeması: her satır için sorulan soru, bu programa yerleşmenin gerçekçi olup olmadığıdır. Tabanı senden çok daha iyi olan bir program listenin sonundaysa ölü tercihtir — yeri listenin başındaki hayal bölgesidir. Aynı programın kopyası veya üstteki satırdan daha sıkı tabanlı bir program alta yazılmışsa yine ölüdür. Sağlıklı listede tabanlar yukarıdan aşağı giderek gevşer.
%% altyazi: Hayal tercihinin yeri listenin başıdır; sona saklanan iddialı satır ölü tercihe dönüşür.
flowchart TD
S{"Bu satıra yerleşmem<br/>gerçekçi mi?"}
S -- "tabanı çok sıkı<br/>ve listenin sonunda" --> O1("Ölü tercih:<br/>yeri baştaki hayal bölgesiydi")
S -- "üsttekiyle aynı program<br/>ya da ondan daha sıkı" --> O2("Ölü tercih:<br/>sıra hatası, satırı taşı veya sil")
S -- "tabanlar yukarıdan aşağı<br/>giderek gevşiyor" --> T("Sağlıklı satır:<br/>merdiven düzgün iner")
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
class O1,O2 hayal
class T garanti
```
**1) Sıralaması yetmeyecek programı listenin sonuna yazmak.**
ÖSYM yerleştirme sistemi listeni yukarıdan aşağı okur ve seni *yerleşebildiğin en üst tercihe* koyar. Diyelim sıralaman 200 bin ve 15. sıraya tabanı 40 bin kapatan bir program yazdın. O programa yerleşebilmen için üstteki 14 tercihin de tutmaması VE tabanın 40 binden 200 bine gevşemesi gerekir — pratikte imkânsız. O satır ölüdür. Hayal tercihi meşrudur ama yeri listenin **başıdır**, sonu değil.
**2) Zaten üstte yazdığın programın kopyasını alta yazmak.**
Aynı programın ikinci yazımı sistemde hiçbir şey değiştirmez. Benzer şekilde, tabanı üstteki tercihten belirgin şekilde daha iyi olan bir programı alta koymak da ölüdür: üstteki tutmadıysa alttaki hiç tutmaz.
## Nasıl anlarsın?
Her satır için şu soruyu sor: **"Bu programa yerleşmem için üstümdeki tercihlerin hepsinin tutmaması VE bu programın tabanının benim sıralamama gelmesi gerçekçi mi?"**
Pratik kontrol yöntemi:
- Satırın taban sıralamasına son 4 yıl üzerinden bak (tek yıl yanıltır).
- Tabanı, senin sıralamandan iyiyse → o satır ancak listenin *üst bloğunda* (hayal) anlamlıdır.
- Tabanı üstündeki satırdan da iyiyse → sıra hatası var; satırları taban gevşekliğine göre yeniden diz.
[Tercih robotuna](/tercih-robotu) sıralamanı girdiğinde programlar hayal/dengeli/garanti dilimleriyle etiketlenir; bir programın senin sıralamana göre hangi bölgede olduğunu tek bakışta görürsün. Popüler bölümlerde tabanların ne kadar geniş bir aralığa yayıldığını görmek için [Psikoloji](/bolum/psikoloji) veya [Hukuk](/bolum/hukuk) tablolarına bak — aynı bölümün tabanı üniversiteye göre yüz binlerce sıra oynayabilir; yani bölüm ölü değildir, *yanlış üniversite-satır eşleşmesi* ölüdür.
## Ölü tercihten temizlenmiş liste nasıl görünür?
Yukarıdan aşağı **tabanlar giderek gevşer**. İlk satırlar "tutarsa harika", orta blok "büyük ihtimal buradayım", son satırlar "kesin tutar ve severek giderim" der. Grafiğe döksen düzgün bir merdiven görürsün; ölü tercihli listelerde merdivenin ortasında yukarı fırlayan basamaklar olur.
Son bir uyarı: ölü tercihi temizleyeyim derken listenin başındaki hayal tercihlerini de kesme. Üst sıradaki iddialı tercih ölü değildir — bedava piyango biletidir. Ölü olan, o iddialı tercihi listenin *sonuna* saklamaktır.

View File

@@ -0,0 +1,48 @@
---
baslik: TYT ile Önlisans Tercihi — Önlisans mı, Lisans mı?
aciklama: 2 yıllıklar "yedek plan" değil, başlı başına bir rota. Önlisans mı lisans mı kararını tek şemada netleştir.
tarih: 2026-07-17
---
AYT'si istediği gibi gitmeyen ya da hedefi zaten uygulamalı bir meslek olan aday için önlisans (2 yıllık) programlar güçlü bir rotadır. Türkiye'deki yükseköğretim kontenjanının büyük bölümü TYT puan türüyle öğrenci alan önlisans programlarındadır — yani seçenek evreni geniştir.
## Önlisans ne zaman doğru tercih?
```mermaid
%% aria: Önlisans mı lisans mı karar şeması: hedef meslek lisans diploması şart koşuyorsa lisans yoluna bakarsın. Sıralaman gitmekten mutlu olacağın bir lisansa yetiyorsa o yolu seçersin. Hedef meslek uygulamalıysa, TYT güçlü AYT zayıfsa ve DGS köprüsü planlıyorsan ya da bir yıl daha sınav istemiyorsan önlisans rotası güçlenir. İstemediğin lisansa sırf kazanmış olmak için gitmek de gereksiz yere önlisansa razı olmak da hatadır.
%% altyazi: Doğru rota hedef mesleğe ve sıralama bandına göre değişir; ikisi de aynı 24'lük listede yan yana yazılabilir.
flowchart TD
S{"Hedefin ve sıralaman<br/>nereye işaret ediyor?"}
S -- "meslek lisans diploması ister<br/>ya da sıralaman mutlu olacağın lisansa yeter" --> L("Lisans rotası:<br/>kendi puan türünün sıralamasıyla kur")
S -- "uygulamalı meslek, DGS köprüsü<br/>ya da bir yıl daha sınav istemiyorsun" --> O("Önlisans rotası:<br/>TYT sıralamasıyla kur")
L --> UYARI("İstemediğin lisansa<br/>sırf kazanmış olmak için gitme")
O --> DGS("DGS planın varsa önce hedef lisansı,<br/>sonra ona köprü önlisansı seç")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
class L,O garanti
class UYARI,DGS uyari
```
- **Hedef meslek uygulamalıysa.** [Bilgisayar Programcılığı](/bolum/bilgisayar-programciligi), [Anestezi](/bolum/anestezi), [İlk ve Acil Yardım](/bolum/ilk-ve-acil-yardim) gibi programlar 2 yılda alana özgü istihdama bağlanır.
- **Lisansa köprü olarak.** DGS (Dikey Geçiş Sınavı) ile önlisans mezunları ilgili lisans bölümlerine geçebilir. "TYT'm iyi, AYT'm zayıf" profili için 2+ yıl planı — önlisans + DGS — düşük sıralamayla doğrudan zayıf bir lisansa gitmekten daha iyi sonuç verebilir.
- **Bir yıl daha sınav istemiyorsan.** Tekrar hazırlanmak yerine alanda ilerlemek isteyene zaman kazandırır.
## Lisans lehine düşünmen gereken durumlar
- Hedef meslek lisans diploması şart koşuyorsa (mühendislik, hukuk, tıp, öğretmenlik...).
- Sıralaman, gitmekten mutlu olacağın bir lisans programına yetiyorsa — sırf "üniversite kazandı" demek için istemediğin lisansa gitmek de, gereksiz yere önlisansa razı olmak da hatadır. Bandını görmek için [kaç sıralama ile hangi bölüme girebilirim](/rehber/kac-siralama-ile-hangi-bolume-girebilirim) rehberine bak.
## TYT tablosunu doğru okumak
Önlisans tercihinde üç ayrıntı belirleyicidir:
1. **Sıralama TYT sıralamasıdır.** SAY/EA sıralamanla önlisans tablosu okuma; sonuç belgende TYT satırı ayrı yazar.
2. **Aynı programın tabanı okula göre uçurum yapar.** Büyükşehirdeki köklü bir MYO'nun programı ile küçük ilçe MYO'sunun aynı adlı programı arasında yüz binlerce sıra fark olabilir — [Bilgisayar Programcılığı tablosunda](/bolum/bilgisayar-programciligi) bunu net görürsün (395 program!).
3. **DGS planın varsa bölüm adına dikkat.** DGS'de hangi önlisanstan hangi lisansa geçilebildiği tablolarla sınırlıdır; hedef lisansı önce belirle, ona köprü olan önlisansı sonra seç.
## Tercih listesi taktiği
24 tercih hakkı lisans ve önlisansta **ortaktır** — aynı listeye ikisini de yazabilirsin. Ama farklı puan türlerinin sıralamaları karışacağı için düzeni şöyle kur: önce gitmeye razı olduğun lisans programları (kendi türünün sıralamasıyla), sonra önlisans bloğu (TYT sıralamasıyla). Her iki blokta da [ölü tercih](/rehber/olu-tercih-nedir) kuralları aynen geçerli.
TYT sıralamanı [tercih robotuna](/tercih-robotu) girip türü "TYT" seçersen önlisans evrenini hayal/dengeli/garanti dilimleriyle görürsün; lisans sıralamanla da ayrı bir tarama yapıp iki listeyi yan yana koyman en sağlıklısı.

View File

@@ -0,0 +1,72 @@
---
baslik: Özel Koşullu Programlar — Sağlık Raporu, Mülakat, Boy-Kilo ve Özel Yetenek
aciklama: Bazı programlara sadece sıralaman yetmez. Kılavuzdaki koşul maddeleri, sağlık raporu isteyen bölümler ve özel yetenek sınavı — tek şemada.
tarih: 2026-08-02
---
Tercih tablosunda bazı program satırlarının yanında küçük madde numaraları görürsün. Bunlar süs değil: o programa yerleşmek için **sıralamanın dışında** sağlanması gereken koşulları anlatır. Sağlık kurulu raporu, boy-kilo ölçüsü, mülakat, güvenlik soruşturması, belirli bir lise türünden mezuniyet... Bu koşulu sağlayamayan bir aday yerleşse bile kaydı yapılmaz. Bu yazı, o satırları tercih etmeden önce nasıl okuyacağını anlatıyor.
## Bir programın önündeki üç kapı
```mermaid
%% aria: Özel koşullu programlar şeması. Bir programa yerleşmenin önünde üç ayrı kapı olabilir. Birinci kapı sıralamadır: taban sıralaması ve varsa başarı sıralaması barajı. İkinci kapı kılavuzdaki koşul maddeleridir: sağlık kurulu raporu, boy ve kilo ölçüsü, mülakat, güvenlik soruşturması, belirli bir lise türünden mezun olma veya yaş sınırı gibi. Üçüncü kapı özel yetenek sınavıdır ve bu programlar merkezi yerleştirmeye dahil değildir; konservatuvar, spor bilimleri ve güzel sanatlar programlarına üniversitenin kendi düzenlediği sınavla girilir, tercih listesine yazılmaz. Bir programı listeye yazmadan önce koşul maddelerinin okunması ve sağlanamayan koşul varsa satırın yazılmaması gerekir; koşul sağlanmazsa yerleşme iptal edilir ve o yıl kaybedilir.
%% altyazi: Sıralaman yetse bile koşul sağlanmıyorsa kayıt yapılmaz — madde numaralarını tercihten önce oku.
flowchart TD
P("Programa yerleşmek") --> K1{"1. Kapı: sıralama<br/>taban ve varsa<br/>başarı sıralaması barajı"}
K1 -- "yetmiyor" --> R1("Satır hayal bloğunda<br/>ya da hiç yazılmaz")
K1 -- "yetiyor" --> K2{"2. Kapı: kılavuzdaki<br/>koşul maddeleri"}
K2 -- "sağlık raporu, boy-kilo,<br/>mülakat, lise türü..." --> D{"Koşulu<br/>sağlıyor musun?"}
D -- "evet, belgeli" --> Y("Satır listeye yazılabilir")
D -- "emin değilim" --> A("Önce belgeyi/ölçüyü doğrula<br/>sonra yaz")
D -- "hayır" --> H("Yazma:<br/>yerleşsen de kayıt yapılmaz,<br/>yıl kaybedilir")
K2 -- "koşul yok" --> Y
P --> K3("3. Kapı: özel yetenek<br/>konservatuvar, spor bilimleri,<br/>güzel sanatlar<br/>merkezi yerleştirmeye dahil DEĞİL")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class Y garanti
class K1,K2,D,A,K3 uyari
class H,R1 hayal
```
## Kapı 1: Sıralama ve barajlar
Bazı bölümlere yerleşmek için taban sıralamasını geçmek yetmez; ayrıca **başarı sıralaması barajını** da geçmen gerekir. Tıp, diş hekimliği, eczacılık, hukuk, mimarlık, mühendislik ve öğretmenlik programlarında bu barajlar uygulanır ve barajın altındaki adaylar o programı **tercih edemez**. Güncel eşikler [baraj ve başarı sıralaması şartları](/rehber/siralama-sartlari-2026) yazısında.
## Kapı 2: Kılavuzdaki koşul maddeleri
ÖSYM kılavuzunda her program satırının yanındaki numaralar, kılavuzun **"Koşullar ve Açıklamalar"** bölümündeki maddelere karşılık gelir. En sık karşılaşılanlar:
- **Sağlık kurulu raporu.** Bazı programlar, tam teşekküllü bir hastaneden alınacak sağlık kurulu raporu ister; raporda "bu programda öğrenim görmesinde sakınca yoktur" ifadesi aranır. Denizcilik, pilotaj, itfaiyecilik, bazı sağlık ve teknik programlar bu grupta olabilir. Renk körlüğü, işitme, denge gibi belirli sağlık koşullarını kapsayan maddeler de vardır.
- **Boy ve kilo ölçüsü.** [Pilotaj](/bolum/pilotaj) ve bazı güvenlik/denizcilik programlarında belirli boy ve kilo aralıkları aranır.
- **Mülakat / güvenlik soruşturması.** Bazı programlarda merkezi yerleştirmenin ardından ek bir değerlendirme aşaması vardır.
- **Belirli lise türünden mezuniyet.** Bazı önlisans programları yalnızca ilgili meslek lisesi mezunlarına, bazıları ise sınavsız/ek kontenjanla açıktır.
- **Yaş sınırı.** Özellikle havacılık ve güvenlik alanındaki programlarda üst yaş sınırı bulunabilir.
- **Yatılılık, üniforma, staj zorunluluğu.** Öğrencilik hayatını doğrudan etkileyen ama tercih anında atlanan maddelerdir.
- **Ücretli/ikinci öğretim, uzaktan öğretim bilgisi.** Programın işleyişini değiştirir; koşul maddesinde belirtilir.
**Nasıl kontrol edilir?** Listeye yazmayı düşündüğün her program için: kılavuzda satırın yanındaki madde numaralarını not al, kılavuzun koşullar bölümünden o maddeleri **tek tek oku**. Bu iş program başına iki dakika sürer ve tercih döneminde yapılabilecek en yüksek getirili iştir.
Kritik uyarı: koşulu sağlamadığın hâlde yerleştiysen **kaydın yapılmaz ve yerleşme hakkın iptal edilir.** Bu durumda o yılki [ek yerleştirme](/rehber/ek-yerlestirme-2026) süreci dışında elinde bir şey kalmaz.
## Kapı 3: Özel yetenek sınavıyla öğrenci alan programlar
Konservatuvarlar, spor bilimleri fakülteleri ve güzel sanatlar programlarının önemli bir kısmı **merkezi yerleştirmeye dahil değildir.** Yani bu programlar tercih listene yazılmaz; üniversitelerin kendi düzenlediği özel yetenek sınavlarına ayrı ayrı başvurursun.
İşleyişi:
- Genellikle belirli bir **TYT puanı** şartı aranır; bu eşik üniversiteden üniversiteye ve programdan programa değişir.
- Başvuru takvimini, sınav içeriğini ve değerlendirme formülünü **her üniversite kendi ilan eder.** Aynı hafta içinde birkaç okulun sınavına girmek mümkündür ama takvimler çakışabilir.
- Yerleştirme, üniversitenin kendi hesapladığı yerleştirme puanına göre yapılır; bu puanda TYT puanı, özel yetenek sınavı sonucu ve bazen orta öğretim başarı puanı birlikte kullanılır.
Pratik sonuç: özel yetenek hedefliyorsan **iki paralel süreç** yürütürsün — bir yandan merkezi tercih listeni hazırlarsın, bir yandan özel yetenek sınavı başvurularını takip edersin. Bu ikisi birbirini engellemez.
## Listeye nasıl yansıtılır?
- Koşulunu **belgeyle doğruladığın** özel koşullu programları normal satır gibi, istek sırana göre diz.
- Koşulundan emin olmadığın bir programı listeye yazmadan önce doğrula: sağlık raporu gerektiren bir programda "büyük ihtimalle uygun çıkarım" varsayımıyla ilerlemek risklidir.
- Koşulunu sağlamadığın programı hiç yazma. Bu satır, [ölü tercihten](/rehber/olu-tercih-nedir) daha kötüdür: ölü tercih sadece yer kaplar, koşulu sağlanmayan tercih ise yerleşirsen yılını götürür.
- Özel yetenek programlarını merkezi listene yazmaya çalışma; ayrı süreçtir.
Kılavuz koşullarını okuduktan sonra sıralamana hangi programların gerçekten açık olduğunu görmek için [tercih robotuna](/tercih-robotu) sıralamanı gir; listeyi kurarken [tercih listesi nasıl yapılır](/rehber/tercih-listesi-nasil-yapilir) yazısındaki hayaldengeligaranti dağılımını temel al.

View File

@@ -0,0 +1,58 @@
---
baslik: Baraj ve Başarı Sıralaması Şartları 2026 (Tıp, Hukuk, Mühendislik, Öğretmenlik...)
aciklama: Bazı bölümleri istemek yetmez — YÖK'ün başarı sıralaması şartı ile taban farkı tek şemada; hangi bölümde hangi eşik var, tabloda.
tarih: 2026-07-18
---
Bazı bölümler için puanın ve sıralaman "yetiyor" görünse bile, YÖK'ün belirlediği **başarı sıralaması şartını** sağlamıyorsan o bölümü tercih bile edemezsin. Bu şart taban sıralamasından farklıdır: taban, yerleşen son kişinin sıralamasıdır ve her yıl piyasada oluşur; **sıralama şartı** ise merkezî bir üst eşiktir — geçemeyen listeye yazamaz.
```mermaid
%% aria: Sıralama şartı ile taban ayrımı şeması: önce hedef bölümün YÖK başarı sıralaması şartını geçip geçmediğine bakarsın. Şartı geçemiyorsan o bölümü listeye hiç yazamazsın ve alternatif rotaya yönelirsin. Şartı geçiyorsan bu yalnızca kapıyı açar; yerleşmek için hâlâ o programın o yılki taban sıralamasına bakman gerekir. Şartı geçmek yerleşmeyi garanti etmez.
%% altyazi: Şart kapıyı açar veya kapatır; taban ise kapıdan girip giremeyeceğini söyler.
flowchart TD
H("Hedef bölümün<br/>sıralama şartı var mı?") --> S{"Şartı geçiyor musun?"}
S -- "hayır" --> K("Listeye yazamazsın:<br/>alternatif rotaya yönel")
S -- "evet" --> A("Kapıık — ama bu yerleşmek değil")
A --> T("Gözünü tabana çevir:<br/>kendi sıralamanın düştüğü bandı bul")
T --> L("Gerçekçi satırları<br/>hayal / dengeli / garanti diz")
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
class K hayal
class A,T uyari
class L garanti
```
## 2026'da sıralama şartı olan başlıca bölümler
| Bölüm | Puan türü | Sıralama şartı |
| --- | --- | --- |
| [Tıp](/bolum/tip) | SAY | İlk 50 bin |
| [Hukuk](/bolum/hukuk) | EA | İlk 100 bin |
| [Diş Hekimliği](/bolum/dis-hekimligi) | SAY | İlk 80 bin |
| [Eczacılık](/bolum/eczacilik) | SAY | İlk 100 bin |
| Mühendislik programları (ör. [Bilgisayar Mühendisliği](/bolum/bilgisayar-muhendisligi)) | SAY | İlk 300 bin |
| [Mimarlık](/bolum/mimarlik) | SAY | İlk 250 bin |
| Öğretmenlik programları (ör. [İlköğretim Matematik Öğretmenliği](/bolum/ilkogretim-matematik-ogretmenligi)) | İlgili tür | İlk 300 bin |
Şartlar kılavuzla kesinleşir; tercih vermeden önce mutlaka ÖSYM kılavuzunun güncel maddesinden doğrula. (Eşikler son yıllarda sabit seyrediyor ama nihai söz her yıl kılavuzundur.)
## Sıralama şartı ile taban sıralaması karışmasın
İki örnekle netleşir:
- Sıralaman SAY 45 bin olsun. Tıp için şartı (ilk 50 bin) **geçiyorsun** — tercih edebilirsin. Ama köklü devlet tıp fakültelerinin tabanı ilk 5-15 bin bandında kapanır; senin gerçekçi tıp evrenin tabanı 45 bine yakın olan fakültelerdir. Şartı geçmek yerleşmeyi garanti etmez.
- Sıralaman EA 130 bin olsun. Hukuk şartı ilk 100 bin olduğundan hukuk programlarını **hiç tercih edemezsin** — tabanı 130 binden geniş bir hukuk fakültesi olsa bile. Bu durumda enerjini şartı olmayan komşu bölümlere ([Kamu Yönetimi](/bolum/kamu-yonetimi), [Sosyal Hizmet](/bolum/sosyal-hizmet) vb.) yönlendirmek daha akıllıca.
## Baraj puanları
Sıralama şartından ayrı olarak tercih yapabilmek için puan türünde **baraj puanını** aşmış olman gerekir (TYT ve ilgili yerleştirme puanı barajları). Sonuç belgende puanın hesaplandıysa bu barajı geçmişsin demektir; ayrıca dert etme.
## Ne yapmalı?
1. Hedef bölümünün şartı var mı, kılavuzdan işaretle.
2. Şartı geçiyorsan gözünü tabana çevir: bölüm sayfasındaki tabloda ([örnek: Tıp](/bolum/tip)) kendi sıralamanın düştüğü bandı bul.
3. Şartı geçemiyorsan o bölümü listeden çıkar ve alternatif rotayı kur — [tercih robotu](/tercih-robotu) sıralamana uygun programları zaten şartlara göre süzülmüş tablolar üzerinden gösterir.
Sıralama şartı acımasız görünür ama işlevi nettir: hem kontenjan enflasyonunu hem de "nasılsa yazayım" kalabalığını engeller. Senin işin, şartı geçtiğin bölümlerde tabanı doğru okumak.

View File

@@ -0,0 +1,48 @@
---
baslik: Taban Puan mı, Başarı Sıralaması mı? Tercihte Hangisine Bakılır?
aciklama: İki sayı da sonuç belgende yazıyor ama tercih listeni sadece biriyle kurmalısın. Neden sıralamanın kazandığı tek şemada.
tarih: 2026-07-21
---
Kısa cevap: **başarı sıralamasına bakılır.** Taban puan, tabelada büyük yazan ama seni yanıltan sayıdır. Nedenini iki dakikada anlatalım.
```mermaid
%% aria: Puan ile sıralama karşılaştırma şeması: aynı puan yıldan yıla farklı sıralamalara denk gelebilir çünkü sınav zorluğu puanı şişirir veya söndürür — bu yüzden puana bakarak liste kurmak yanıltır. Başarı sıralaması seni o yılın adaylarıyla kıyaslar ve yıllar arasında karşılaştırılabilir kalır; tercih listesi her zaman kendi puan türünün sıralamasıyla kurulur.
%% altyazi: Puan her yıl kayar; sıralama aynı cetvelde kalır. Listeyi sıralama kolonuna göre kur.
flowchart TD
P("Sonuç belgende iki sayı var:<br/>puan ve başarı sıralaması") --> S{"Hangisiyle<br/>liste kuracaksın?"}
S -- "puana bakarsan" --> Y("Yanıltır:<br/>450 puan bir yıl 30 bin,<br/>ertesi yıl 60 bin olabilir")
S -- "sıralamaya bakarsan" --> G("Güvenilir:<br/>seni o yılın herkesıyla kıyaslar,<br/>yıllar arası karşılaştırılır")
G --> L("Listeni kendi puan türünün<br/>sıralamasıyla kur")
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
class Y hayal
class G,L garanti
```
## Puan neden yanıltır?
YKS puanı, sınavın o yılki zorluğuna ve aday kitlesinin performansına göre şekillenir. Sınav kolay geçtiyse herkesin puanı şişer; zor geçtiyse söner. 450 puan bir yıl ilk 30 bine, ertesi yıl ilk 60 bine denk gelebilir. Yani "geçen yıl bu bölüm 450 ile kapatmış, benim puanım 455, güvendeyim" cümlesi hatalıdır — iki farklı yılın puanları aynı cetvelle ölçülmez.
## Sıralama neden güvenilir?
Başarı sıralaması, seni o yıl sınava giren herkesle kıyaslar: "SAY'da 85.000'incisin" bilgisi yıldan yıla **karşılaştırılabilir** kalır. Bir programın geçen yılki taban *sıralaması* 90 bin ise, bu yıl 85 bininci aday için o program "dengeli" bölgededir — sınav kolay muydu zor muydu fark etmez, çünkü herkes aynı gemide.
ÖSYM sonuç belgende her puan türü için ayrı sıralama yazar. Tercih listeni hangi türden kuruyorsan **o türün sıralamasını** kullan; SAY sıralamanla EA listesi kurmak elma-armut kıyasıdır.
## Peki taban puan ne işe yarar?
- Aynı yıl içinde iki programı kabaca kıyaslamaya,
- Ek yerleştirmede başvuru eşiği olarak (ek tercihte ilk yerleştirme taban puanı şart koşulur — detay [ek yerleştirme rehberinde](/rehber/ek-yerlestirme-2026)),
- Bir de haber sitelerine manşet olmaya.
Liste kurarken açtığın her tabloda gözün **sıralama kolonunda** olmalı. Örneğin [Bilgisayar Mühendisliği taban puanları](/bolum/bilgisayar-muhendisligi) sayfasında programlar taban sıralamasına göre dizilir; puan kolonu yalnızca bağlam içindir. Aynısı [Hukuk](/bolum/hukuk) ve tüm diğer bölüm sayfaları için geçerli.
## Uygulamada üç kural
1. **Listeyi sıralamayla kur.** Her satırın son 3-4 yıllık taban sıralaması trendine bak; tek yıl yanıltır ([neden yanılttığını burada gösterdik](/rehber/taban-siralamalar-nasil-degisir)).
2. **Puan haberlerine kapılma.** "X bölümü 500 puanla öğrenci aldı" manşeti sana hiçbir şey söylemez; o yılın 500 puanı kaçıncı sıraysa bilgi odur.
3. **Sıralamanı doğru yerden oku.** ÖSYM sonuç belgesindeki, kendi puan türünün "başarı sırası" satırı. OBP eklenmiş/eklenmemiş karışıklığına dikkat — tercihte kullanılan, yerleştirme puanına ait sıralamadır.
Sıralamanı biliyorsan gerisi mekanik: [tercih robotuna](/tercih-robotu) gir, sıralamana uygun programları hayal/dengeli/garanti dilimleriyle gör, listeni veriyle kur.

View File

@@ -0,0 +1,57 @@
---
baslik: Taban Sıralamalar Yıldan Yıla Ne Kadar Değişir?
aciklama: "Geçen yıl 90 bin kapatmış, ben 85 binim, garanti" demeden önce oku — tabanları oynatan mekanizmalar ve trend okuma yolu tek şemada.
tarih: 2026-07-16
---
Tercih listeni geçen yılın tabanlarıyla kuruyorsun ama yerleşmeni **bu yılın** tabanları belirleyecek. Aradaki fark bazen birkaç bin, bazen yüz binlerce sıra. Bu yazı tabanları neyin oynattığını ve trendi nasıl okuyacağını anlatıyor.
## Tabanı oynatan mekanizmalar
```mermaid
%% aria: Taban trendi okuma şeması: tek yılın tabanı fotoğraftır, dört yılın tabanı filmdir. Dört yıl üst üste dar banttaysa istikrarlı referanstır. Her yıl sıkılaşıyorsa geçen yılın tabanına güvenme ve pay bırak. Bir sıkı bir gevşek testere dişi sürü etkisidir, ortalamayı al. Bazı yıllar veri boşsa belirsizlik yüksektir; o programı dengeli değil hayal bölgesine koy.
%% altyazi: Tek yıla bakan, testere dişinin tepesinden ya da dibinden ölçüm alır — en az 3-4 yıla bak.
flowchart TD
F("Tek yılın tabanı = fotoğraf<br/>dört yılın tabanı = film") --> T{"Film ne diyor?"}
T -- "dört yıl dar bantta" --> I("İstikrarlı:<br/>güvenilir referans")
T -- "her yıl sıkılaşıyor" --> S("Tek yönlü trend:<br/>pay bırak, geçen yıla güvenme")
T -- "bir sıkı bir gevşek" --> TE("Testere dişi:<br/>ortalamayı al, uca değil")
T -- "bazı yıllar veri yok" --> B("Belirsiz:<br/>dengeli değil, hayal bölgesine koy")
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class I garanti
class S,TE uyari
class B hayal
```
**1) Kontenjan değişimi.** En mekanik etki: bir program kontenjanını 60'tan 90'a çıkarırsa taban gevşer; 90'dan 60'a inerse sıkılaşır. Bölüm sayfalarındaki kontenjan kolonunu yıllar arasında kıyaslamak bu yüzden önemli.
**2) Aday davranışı (sürü etkisi).** "Geçen yıl çok kapattı" diye herkes bir programdan kaçarsa taban gevşer; "gevşedi" diye ertesi yıl herkes geri dönerse tekrar sıkılaşır. Tabanlar bu yüzden testere dişi gibi salınabilir — tek yıla bakan, testere dişinin tepesinden ya da dibinden ölçüm alır.
**3) Yeni açılan programlar.** Bir şehirde yeni fakülte açılınca hem kendi tabanı belirsiz olur hem çevresindeki programların tabanını seyreltir.
**4) Şartlar ve politika değişiklikleri.** Başarı sıralaması şartının gelmesi/eşiğin değişmesi, burs oranlarının değişmesi, öğretim dilinin değişmesi tabanı sıçratır. ([Şartların güncel listesi burada.](/rehber/siralama-sartlari-2026))
**5) Ekonomi ve istihdam algısı.** Mezun istihdamına dair haber akışı bile birkaç yıl içinde bir bölümün talebini görünür şekilde değiştirir — son yıllarda kimi mühendisliklerde ve sağlık programlarında bunun örnekleri yaşandı.
## Trend nasıl okunur?
Tek yılın tabanı **fotoğraf**, dört yılın tabanı **film**dir. Film izle:
- **İstikrarlı taban** (dört yıl üst üste dar bantta): güvenilir referans. Sıralaman tabana yakınsa "dengeli", belirgin gerisindeyse "garanti" davranabilirsin.
- **Tek yönlü trend** (her yıl sıkılaşıyor): geçen yılın tabanına güvenme; bu yıl daha da sıkılaşacağını varsayıp payla yaklaş. Popüler bölümlerde sık görülür — [Psikoloji](/bolum/psikoloji) ve [Bilgisayar Mühendisliği](/bolum/bilgisayar-muhendisligi) tablolarında 2024-2025 kolonlarını yan yana koyup bak.
- **Testere dişi** (bir sıkı bir gevşek): sürü etkisi işliyor demektir; ortalamayı referans al, uç yıla değil.
- **Veri boşluğu** (bazı yıllar "—"): yeni ya da o yıl dolmamış program; belirsizlik yüksek, listende dengeli değil garanti bölgesine koyma, hayal bölgesine koy.
Bölüm sayfalarımızdaki tablolarda 2025 sıralamasının yanında 2024 kolonu ve değişim yönü işareti (▲/▼) tam bu iş için var.
## Listeye nasıl yansıtılır?
1. Her satır için son 4 yılın tabanına bak; tek yıl asla yeterli değil.
2. Sıkılaşma trendindeki programları bir kademe yukarı say ("dengeli" sandığın aslında "hayal" olabilir).
3. Gevşeme trendindeki programlara erken sevinme; sürü geri dönebilir.
4. Belirsizliği [dengeli bir listeyle](/rehber/tercih-listesi-nasil-yapilir) yönet: trend ne yaparsa yapsın, hayal/dengeli/garanti dağılımı düzgün kurulmuş bir liste boşta bırakmaz.
[Tercih robotu](/tercih-robotu) bu analizi senin yerine yapar: sıralamanı girdiğinde programları yalnızca son tabana göre değil, çok yıllı veriyle dilimleyerek gösterir.

View File

@@ -0,0 +1,57 @@
---
baslik: YKS Tercih Listesi Nasıl Yapılır? (2026 Rehberi)
aciklama: 24 tercihlik listeyi dilim dilim kurmanın adım adım yöntemi — hayal, dengeli ve garanti bölgeleri tek şemada.
tarih: 2026-07-25
---
Tercih listesi kurmanın tek doğru yolu yok; ama boşta bırakan yanlış yolları belli. Bu rehber, ÖSYM'nin tanıdığı 24 tercih hakkını **hayal / dengeli / garanti** mantığıyla nasıl dağıtacağını anlatıyor.
## Önce ölçüyü düzelt: puan değil, sıralama
Tercihin tek sağlam ölçüsü **başarı sıralamandır**. Puanlar her yıl sınavın zorluğuna göre kayar; aynı puan bir yıl 80 bininci, ertesi yıl 120 bininci sıraya denk gelebilir. ÖSYM sonuç belgende her puan türü için ayrı sıralaman yazar — listeyi o satıra göre kur. Bu konunun detayı için [Taban puan mı, başarı sıralaması mı?](/rehber/taban-puan-mi-siralama-mi) yazısına bak.
## Listenin üç bölgesi
```mermaid
%% aria: Tercih listesi dilim şeması: 24 satırlık liste yukarıdan aşağı üç bölgeye ayrılır. İlk 4-8 satır hayal tercihleri — tabanı senden daha iyi kapatan ama çok istediğin programlar; tutmazsa alttakilere zarar vermez. Orta 8-12 satır dengeli tercihler — sıralamana yakın programlar, yerleşme ihtimalinin en yüksek olduğu bölge. Son 4-6 satır garanti tercihler — tabanı belirgin geniş programlar; buraya yalnızca gerçekten kayıt yaptıracağın programları yazarsın.
%% altyazi: Üstte hayal (kırmızı), ortada dengeli (sarı), altta garanti (yeşil) — her satır istek sırana göre dizilir, yerleşme ihtimaline göre değil.
flowchart TD
L("24 tercihlik listen<br/>yukarıdan aşağı okunur") --> H("Hayal · ilk 4-8 satır<br/>çok istediğin, tabanı daha sıkı programlar")
H --> D("Dengeli · orta 8-12 satır<br/>sıralamana yakın programlar")
D --> G("Garanti · son 4-6 satır<br/>gerçekten razı olacağın programlar")
H -. "tutmazsa sıradakine geçer<br/>alttakilere zarar vermez" .-> D
G --> K{"Kayıt yaptırır mısın?"}
K -- "evet, severek giderim" --> OK("Listeye yaz")
K -- "hayır" --> YAZMA("Yazma:<br/>yerleşirsen ek hakkın yanar")
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
class H hayal
class D uyari
class G,OK garanti
class YAZMA hayal
```
**1) Hayal tercihleri (ilk 4-8 sıra).** Taban sıralaması seninkinden *daha iyi* kapatan ama çok istediğin programlar. "Sıralamam yetmez, boşa gider" korkusu yersizdir: bir programı üst sıraya yazmak, alttaki tercihlere yerleşme ihtimalini **azaltmaz**. ÖSYM sistemi yukarıdan aşağı bakar; hayal tutmazsa sıradakine geçer. Tabanlar her yıl oynar — geçen yıl 5 bin kapatmış bir bölüm bu yıl 8 bine gevşeyebilir.
**2) Dengeli tercihler (orta blok, 8-12 sıra).** Taban sıralaması senin sıralamana yakın programlar. Listenin kalbi burasıdır; yerleşme ihtimalinin en yüksek olduğu bölge. Aynı bölümün farklı şehirlerdeki/üniversitelerdeki versiyonlarını sıralama sırasıyla diz.
**3) Garanti tercihleri (son 4-6 sıra).** Taban sıralaması seninkinden belirgin şekilde geniş programlar. Buradaki altın kural: **yerleşsen kayıt yaptırmayacağın hiçbir programı yazma.** Garanti dilimi "razı olacağın en makul seçenek" demektir, "ne olursa olsun bir yere gireyim" demek değil. Kayıt yaptırmayacağın bir yere yerleşirsen hem bir yılın gider hem de ek yerleştirmeye başvuramazsın.
## Sık yapılan hatalar
- **Tek yıla bakmak.** 2025 tabanı tek başına yanıltır; en az son 3-4 yılın trendine bak. Tabanların yıldan yıla nasıl oynadığını [Taban sıralamalar yıldan yıla ne kadar değişir?](/rehber/taban-siralamalar-nasil-degisir) yazısında verilerle gösterdik.
- **24'ü doldurmak için doldurmak.** Okumayacağın bölümü listeye eklemek hata; 16 gerçekçi tercih, 24 gelişigüzel tercihten iyidir.
- **"Ölü tercih" yazmak.** Tabanı senin sıralamandan çok daha iyi olan bir programı listenin *sonlarına* yazmak o satırı çöpe atar — üstteki tercihlerinden birine yerleşmişsen oraya sıra zaten gelmez. Detay: [Ölü tercih nedir?](/rehber/olu-tercih-nedir)
- **Sadece bölüme ya da sadece şehre kilitlenmek.** "Ne olursa olsun [Tıp](/bolum/tip)" diyorsan 24 tercihi de tıp yazabilirsin; ama "mühendislik olsun da hangisi olursa olsun" diyorsan [Bilgisayar Mühendisliği](/bolum/bilgisayar-muhendisligi), [Elektrik-Elektronik Mühendisliği](/bolum/elektrik-elektronik-muhendisligi) gibi yakın bölümleri karışık ve sıralama sırasıyla dizmek daha akıllıca.
## Pratik akış
1. Sıralamanı ve puan türünü not et.
2. Sıralamana uygun program evrenini çıkar — [tercih robotuna](/tercih-robotu) sıralamanı girerek hayal/dengeli/garanti dilimlerini saniyede görebilirsin.
3. İstemediklerini ele, kalanları *istek sırana* göre diz (yerleşme ihtimaline göre değil).
4. Son kontrol: listenin başı hayal mi, ortası dengeli mi, sonu gerçekten garanti mi? Sonunda kayıt yaptırmayacağın program var mı?
5. ÖSYM AİS'e girerken listeyi bir kez daha kod kod doğrula.
Listeyi kurarken her satırın "neden burada" sorusuna cevabı olmalı. Cevabı yoksa o satır ya yanlış yerde ya da listede fazla.

View File

@@ -0,0 +1,59 @@
---
baslik: Üniversite Kaydı Nasıl Yapılır? 2026 e-Kayıt ve Belge Rehberi
aciklama: Yerleştin, tebrikler — şimdi kaydını kaçırma. e-Devlet'ten 5 dakikada e-kayıt, şahsen kayıtta istenen belgeler ve "kayıt yaptırmazsam ne olur" sorusunun net cevabı.
tarih: 2026-07-28
---
Yerleştirme sonuçlarııklandıktan sonra en çok aranan soru değişir: "nereye yerleştim"in yerini **"kayıt nasıl yapılır, son gün ne zaman?"** alır. 2026'da kayıtlar **24-28 Ağustos** tarihleri arasında; e-Devlet üzerinden elektronik kayıt ise **24-26 Ağustos** günlerinde yapılabiliyor. Takvimin tamamı için [2026 tercih takvimi](/rehber/yks-tercih-takvimi-2026) yazısına bakabilirsin.
## Önce e-kayıt dene: belge yok, yol yok, sıra yok
Üniversitelerin büyük bölümü e-Devlet üzerinden **e-kayıt** kabul ediyor. e-Devlet'e girip *"Üniversite E-Kayıt"* hizmetini açtığında yerleştiğin program listeleniyorsa birkaç onayla kaydın tamamlanır — diploma, fotoğraf, şehirlerarası yolculuk gerekmez. Kayıt belgeni yine e-Devlet'ten barkodlu indirebilirsin.
```mermaid
%% aria: Üniversite kayıt akış şeması: bir programa yerleştikten sonra kayıt yaptırmaya karar verirsen önce e-Devlet'te e-kayıt seçeneğini kontrol edersin; açıksa 24-26 Ağustos arasında belgesiz ve sırasız e-kayıt yaparsın, kapalıysa 24-28 Ağustos arasında belgelerinle üniversiteye giderek şahsen kayıt olursun; iki yol da kaydını tamamlar. Kayıt yaptırmazsan bu yılki hakkın yanar, yerleştiğin için ek yerleştirmeye giremezsin ve gelecek yıl OBP katkın yarıya düşer.
%% altyazi: e-kayıt penceresi şahsen kayıttan iki gün önce kapanır; önce e-kaydı dene, olmuyorsa belgelerle yola çık.
flowchart TD
S("Sonuçlar açıklandı:<br/>bir programa yerleştin") --> K{"Kayıt yaptıracak mısın?"}
K -- "evet" --> E{"e-Devlet'te e-kayıt<br/>seçeneğin açık mı?"}
E -- "evet" --> E1("24-26 Ağustos: e-kayıt<br/>belge yok, sıra yok, 5 dakika")
E -- "hayır" --> E2("24-28 Ağustos: üniversitede şahsen kayıt<br/>belgelerini yanına al")
E1 --> T("Kaydın tamam,<br/>artık öğrencisin")
E2 --> T
K -- "hayır" --> R("Bu yılki hakkın yanar:<br/>ek yerleştirmeye giremezsin,<br/>gelecek yıl OBP katkın yarıya düşer")
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class T garanti
class R hayal
```
## Şahsen kayıtta istenen belgeler
Üniversiteler kendi listesini yayımlar; standart çekirdek şudur:
- **Lise diploması** (aslı) ya da yeni mezunlar için mezuniyet belgesi
- **ÖSYS yerleştirme sonuç belgesi** (internet çıktısı yeterli)
- Nüfus cüzdanı / T.C. kimlik kartı ve fotokopisi
- Vesikalık fotoğraf (genelde 4-6 adet)
- Bazı programlar için ek koşul belgeleri: sağlık raporu, boy-kilo şartı, mülakat sonucu gibi — bunlar kılavuzda programın yanındaki koşul numaralarında yazar
İkinci öğretim ya da vakıf programına yerleştiysen ilk taksit/öğrenim ücreti dekontu da istenir. Gitmeden önce üniversitenin kayıt sayfasını mutlaka aç; eksik belge, kayıt döneminin en klasik zaman kaybıdır.
## "Kayıt yaptırmazsam ne olur?"
Bu sorunun cevabı üç maddedir ve üçü de önemlidir:
1. **Bu yılki hakkın yanar.** Yerleştiğin programa sonradan "vazgeçtim, geleyim" diyemezsin.
2. **Ek yerleştirmeye giremezsin.** Kayıt yaptırmasan bile *yerleştirilmiş* sayılırsın ve [ek yerleştirme](/rehber/ek-yerlestirme-2026) kapısı sana kapanır.
3. **Gelecek yıl OBP çarpanın yarıya düşer.** Seneye tekrar sınava girersen diploma notu katkın 0,12 yerine 0,06 ile hesaplanır — [OBP yazısında](/rehber/obp-nedir-nasil-hesaplanir) sayılarla anlattık.
Bu üç maddenin tek bir tercih dersi var: **kayıt yaptırmayacağın programı listene hiç yazma.** Liste kurarken bu süzgeci nasıl uygulayacağın [tercih listesi rehberinde](/rehber/tercih-listesi-nasil-yapilir).
## Kayıt sonrası küçük ama önemli işler
- Ders kaydı / oryantasyon tarihlerini üniversitenin öğrenci işleri sayfasından not al; kayıt olmak çoğu üniversitede ders seçimini otomatik yapmaz.
- Yurt başvurusu (KYK) ayrı bir takvimle yürür — kayıt haftasını beklemeden başvuru dönemini takip et.
- Öğrenci belgeni e-Devlet'ten alabilirsin; indirim ve burs başvurularının çoğu bunu ister.
Yerleşmek maratonun bitişi, kayıt ise ipi göğüslemek. Son güne bırakma — e-kayıt penceresi, şahsen kayıttan **iki gün önce** kapanıyor.

View File

@@ -0,0 +1,60 @@
---
baslik: Veliler İçin Tercih Rehberi — Nerede Yardım Etmeli, Nerede Geri Durmalı?
aciklama: Tercih listesini kim doldurmalı, veli hangi konuda gerçekten faydalı olur? Görev dağılımı ve o meşhur anlaşmazlık — tek şemada.
tarih: 2026-08-02
---
Tercih dönemi evde iki farklı endişenin çarpıştığı iki haftadır. Öğrenci "istediğim bölümü okuyamayacağım" diye endişelenir; veli "yanlış karar verip yıllarını kaybedecek" diye. İkisi de haklı bir yerden bakıyor, ama aynı işi yapmaya çalıştıklarında liste bozulur. Bu yazı, **hangi işin kimde olduğunu** ayırıyor.
## Görev dağılımı
```mermaid
%% aria: Veli ve öğrenci görev dağılımı şeması. Tercih sürecindeki işler üçe ayrılır. Öğrencinin kararı: hangi bölümü okumak istediği, listenin sırası ve hayal tercihleri. Velinin gerçek katkısı: bütçe gerçeği, barınma ve yurt araştırması, şehir güvenliği ve ulaşım, ailedeki ve çevredeki meslek sahipleriyle görüşme ayarlamak. Ortak karar: bütçenin tutmadığı satırların listeden çıkarılması ve nihai listenin birlikte gözden geçirilmesi. Veliye düşmeyen iş: listeyi öğrencinin yerine doldurmak veya sıralamayı değiştirmek, çünkü dört yıl okulu okuyacak olan öğrencidir.
%% altyazi: Bölüm kararı öğrencinin, bütçe ve barınma gerçeği velinin; liste ikisinin birlikte okuduğu son metin.
flowchart TD
T("Tercih süreci") --> O("ÖĞRENCİDE:<br/>hangi bölüm,<br/>listenin sırası,<br/>hayal tercihleri")
T --> V("VELİDE:<br/>bütçe gerçeği,<br/>yurt ve barınma,<br/>şehir ve ulaşım,<br/>meslek sahibiyle görüşme")
T --> Y("VELİYE DÜŞMEYEN:<br/>listeyi doldurmak,<br/>sıralamayı değiştirmek")
O --> B{"Bütçe bu satırı<br/>4 yıl taşır mı?"}
V --> B
B -- "evet" --> L("Satır listede kalır")
B -- "hayır" --> C("Birlikte konuşulur,<br/>satır çıkarılır<br/>veya burslu eşdeğeri aranır")
Y --> R("Sonuç: öğrenci sahiplenmez,<br/>ilk zorlukta okul bırakılır")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class O,V,L garanti
class B,C uyari
class Y,R hayal
```
## Velinin gerçekten fark yarattığı dört alan
Bölüm seçiminde ısrar etmek yerine, bu dört başlıkta veli katkısı doğrudan işe yarar:
1. **Bütçe gerçeğini net söylemek.** "Bakarız, hallederiz" en riskli cümledir. Vakıf üniversitelerinde indirimli programların dört-altı yıllık toplam maliyetini, devlet üniversitelerinde ise şehrin kira ve yaşam giderini **listeyi vermeden önce**ıkça konuşun. Yerleştikten sonra ortaya çıkan "ödeyemeyiz" durumu bir yıl kaybettirir. [Devlet mi vakıf mı](/rehber/devlet-mi-vakif-mi) yazısı burs varyantlarının nasıl okunacağını anlatıyor.
2. **Barınmayı önceden araştırmak.** Yurt kapasitesi, öğrenci evi kiraları ve kampüsün şehir merkezine uzaklığı velinin rahat araştırabileceği, öğrencinin ise tercih telaşında atladığı konulardır. [Yurt, burs ve yıllık maliyet](/rehber/yurt-burs-ve-yillik-maliyet) yazısındaki kalemleri şehir şehir doldurmak iyi bir veli işidir.
3. **Doğru insanla konuşturmak.** "Bence doktor ol" demek yerine, çevrenizdeki bir hekimle, mühendisle, öğretmenle yarım saatlik bir görüşme ayarlamak on kat etkilidir. Öğrenci mesleği sizden değil, o mesleği yapan birinden duysun.
4. **Süreci takip etmek.** Tercih işlemi tarihleri, kayıt belgeleri, e-Devlet adımları — bunlar sıkıcı ama kritik. [Tercih takvimi](/rehber/yks-tercih-takvimi-2026) ve [kayıt rehberi](/rehber/universite-kayit-rehberi-2026) yazılarındaki tarihleri takvime işlemek tam bir veli görevidir.
## Listeyi neden öğrenci doldurmalı?
Çünkü dört yıl o sıraları okuyacak olan o. Bunun ötesinde pratik bir sebep de var: **ÖSYM seni yerleşebildiğin en üst tercihe koyar.** Yani listenin sırası bir istek beyanıdır, taktik değil. Öğrenci gerçekten istediği sırayı yazmazsa, sistem ona istemediği bir yeri verir ve bu tamamen kendi listesinden kaynaklanır. [Merkezi yerleştirme nasıl çalışır](/rehber/merkezi-yerlestirme-nasil-calisir) yazısı bu mantığı adım adım gösteriyor.
Velinin listeyi "düzeltmesi" genelde şuraya varır: üst sıralara ailenin prestijli bulduğu bölümler girer, öğrencinin gerçek isteği aşağı iner. Sıralama tutarsa öğrenci sahiplenmediği bir bölümde başlar; ilk dönem sonunda devamsızlık, sonraki yıl ise ya yeniden sınav ya da okulu bırakma gelir. Kazanılan bir şey yoktur.
## Anlaşmazlık çıktığında: üç adımlı yol
Öğrenci bir bölümü çok istiyor, siz riskli buluyorsunuz. Tartışmak yerine:
- **Adım 1 — İddiaları yazıya dökün.** "Bu bölüm iş bulamaz" ya da "bu bölüm harika" cümlelerinin ikisi de kanıtsız. İkiniz de iddianızı somut bir kaynağa dayandırın: ders katalogu, akreditasyon, mezunların gittiği yerler. [Bir bölümün iş imkânını nasıl araştırırsın](/rehber/bolumun-is-imkanini-nasil-arastirirsin) yazısı bunun yöntemini veriyor.
- **Adım 2 — Listede ikisine de yer açın.** 24 satırlık liste tam da bunun için var. Öğrencinin çok istediği bölüm üst bloğa, sizin daha güvenli bulduğunuz alternatifler alt bloğa girebilir. İkisi çatışmaz, sıralanır. [Tercih listesi nasıl yapılır](/rehber/tercih-listesi-nasil-yapilir) yazısındaki hayaldengeligaranti dağılımı bu pazarlığın zeminidir.
- **Adım 3 — Kararı öğrenciye bırakın, gerekçenizi bir kez söyleyin.** Bir kez. Tekrar etmek ikna etmez, sadece kararı duygusallaştırır.
## Son iki hatırlatma
- **Kendi dönemini referans almayın.** Yirmi yıl önce güçlü olan bir bölüm bugün öyle olmayabilir, tersi de doğru. Tabanlar ve müfredatlar değişti; karar bugünün verisiyle verilmeli.
- **Boş satır bırakmayın, ama zorla da doldurmayın.** Kayıt yaptırmayacağınız bir programı "garanti olsun" diye yazmak, [ölü tercihten](/rehber/olu-tercih-nedir) daha kötüdür: yerleşirseniz ek yerleştirme hakkı da yanar.
Öğrencinizin sıralamasıyla hangi bölümlerin ve şehirlerin gerçekten masada olduğunu birlikte görmek için [tercih robotuna](/tercih-robotu) sıralamayı girip listeyi ekranda yan yana inceleyebilirsiniz.

View File

@@ -0,0 +1,79 @@
---
baslik: İstemediğim Bölüme Yerleşirsem? Yatay Geçiş, ÇAP ve Yandal Gerçekte Nasıl İşler?
aciklama: Sonra yatay geçerim cümlesinin arkasında ne var? Üniversiteye başladıktan sonraki dört yol ve gerçek koşulları — tek şemada.
tarih: 2026-07-30
---
Tercih döneminde en çok kurulan cümlelerden biri: "Şimdilik buraya yazayım, sonra yatay geçerim." Bu cümle tamamen yanlış değil — üniversiteye başladıktan sonra gerçekten birkaç çıkış yolu var. Ama her birinin koşulu, takvimi ve kontenjanı var. Bu yazı, o yolları **planlanabilir** hâle getiriyor: hangisi neye bağlı, hangisi ne zaman açılıyor.
## Başladıktan sonraki dört yol
```mermaid
%% aria: Üniversiteye başladıktan sonraki geçiş yolları şeması. Kayıtlı olduğun bölümden memnun değilsen dört yol vardır. Birincisi merkezi yerleştirme puanıyla yatay geçiş, kısaca Ek Madde 1: kayıt olduğun yıldaki YKS puanın hedef programın aynı yıldaki taban puanına eşit veya ondan yüksekse başvurabilirsin, not ortalaması şartı aranmaz ve bu haktan yalnızca bir kez yararlanılır. İkincisi not ortalamasıyla yatay geçiş: genellikle lisansta üçüncü ve beşinci yarıyıl başında, eşdeğer programlara, kontenjan dahilinde yapılır ve not ortalaması şartı vardır. Üçüncüsü çift anadal ve yandal: mevcut bölümü bırakmadan ikinci bir programın derslerini almaktır, not ortalaması ve sınıf başarı sırası şartı aranır. Dördüncüsü yeniden sınava girmektir; bu her zaman açık olan yoldur ama bir yıl maliyeti vardır. Hiçbir yolun garanti olmadığı için tercih listesi bu yollara güvenilerek kurulmamalıdır.
%% altyazi: Dört yol da gerçek, hiçbiri garanti değil — liste bu yolların üstüne kurulmaz.
flowchart TD
A("Bölümden memnun değilim") --> Y1{"Kayıt yılındaki YKS puanın<br/>hedef programın o yılki<br/>tabanına yetiyor mu?"}
Y1 -- "evet" --> E1("Ek Madde 1<br/>merkezi puanla yatay geçiş<br/>not şartı yok, 1 kez")
Y1 -- "hayır" --> Y2{"Not ortalaman<br/>yüksek mi?"}
Y2 -- "evet, bölümü bırakacağım" --> E2("Not ortalamasıyla yatay geçiş<br/>3. ve 5. yarıyıl<br/>kontenjan sınırlı")
Y2 -- "evet, bölümü bırakmayacağım" --> E3("Çift anadal / yandal<br/>ikinci diploma veya sertifika")
Y2 -- "hayır" --> E4("Yeniden YKS<br/>her zaman açık,<br/>1 yıl maliyeti var")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class E1,E3 garanti
class Y1,Y2,E2 uyari
class E4 hayal
```
## 1) Merkezi yerleştirme puanıyla yatay geçiş (Ek Madde 1)
En çok merak edilen ve en yanlış bilinen yol. Mantığı basit: **kayıt olduğun yıldaki YKS puanın**, geçmek istediğin programın **aynı yıldaki taban puanına** eşit ya da ondan yüksekse başvurabilirsin.
Bilmen gereken çerçeve:
- **Not ortalaması şartı aranmaz.** Değerlendirmede yalnızca yerleştiğin yıldaki merkezi yerleştirme puanların dikkate alınır.
- **Puan türü tutmalı.** Hedef programın puan türünde bir puanın olmalı ve o puan hedefin tabanını geçmeli.
- **Bu haktan bir kez yararlanılır.**
- **Her üniversite kendi duyurusunu yayımlar.** Başvuru takvimi, istenen belgeler ve varsa ek koşullar okulun öğrenci işleri sayfasında ilan edilir. "Ek Madde 1" veya "merkezi yerleştirme puanıyla yatay geçiş" başlığıyla ararsın.
Pratik sonuç: bu yol, **puanı yettiği hâlde listeyi yanlış kurduğu için aşağı bir programa düşenler** için gerçek bir ikinci şanstır. Puanı zaten yetmeyenler için bir şey değiştirmez. Yani "sonra yatay geçerim" cümlesi, ancak puanın hedefe zaten yetiyorsa anlamlıdır — ki o durumda en baştan doğru listeyi kurmak çok daha kolaydı. [Tercih listesi nasıl yapılır](/rehber/tercih-listesi-nasil-yapilir) yazısı bu hatayı baştan önlemek için var.
## 2) Not ortalamasıyla yatay geçiş
Klasik yatay geçiş. Genel çerçevesi şöyle: lisans programlarında **üçüncü ve beşinci yarıyıl** başında, önlisansta ise ikinci ve üçüncü yarıyılda, **eşdeğer programlar** arasında, **kontenjan dahilinde** yapılır. Not ortalaması şartı vardır ve başvurular genel not ortalamasına göre sıralanır.
Kritik farklar:
- **Kurum içi geçiş genelde daha kolaydır.** Üniversiteden memnunsan ama bölümden değilsen, aynı okul içinde geçiş şartları çoğunlukla daha esnektir.
- **Kontenjan azdır.** Popüler programlara yatay geçiş kontenjanı bazen tek hanelidir; başvuranlar arasında en yüksek ortalamalar kazanır.
- **Ders intibakı sürprizli olabilir.** Geçtiğin bölümdeki derslerin hangilerinden muaf sayılacağına ilgili fakültenin muafiyet ve intibak komisyonu karar verir. Muaf sayılmayan dersler mezuniyetini uzatabilir.
- **Hazırlık sınıfı yarıyıl sayılmaz.** Hazırlıkta yatay geçiş yapılmaz; en az bir yarıyıl lisans eğitimi tamamlaman gerekir. [Hazırlık sınıfı ve öğretim dili](/rehber/hazirlik-sinifi-ve-ogretim-dili) yazısında hazırlığın süreye etkisi anlatılıyor.
## 3) Çift anadal (ÇAP) ve yandal
Bunlar "kaçış" değil, **ekleme** yollarıdır: mevcut bölümünü bırakmadan ikinci bir programın derslerini alırsın.
- **Çift anadal:** İki ayrı diplomayla mezun olursun. Genellikle belirli bir genel not ortalaması ve kendi sınıfında belirli bir başarı dilimi şartı aranır; iki programın toplam ders yükü ciddi bir tempodur.
- **Yandal:** Diploma değil, sertifika alırsın. Şartları çift anadaldan hafiftir, ders yükü daha azdır.
Eşik değerler ve hangi bölümler arasııldığı **üniversitenin kendi yönetmeliğinde** yazar ve okuldan okula değişir. Kararı verirken şuna bak: [İşletme](/bolum/isletme) okuyup [Bilgisayar Mühendisliği](/bolum/bilgisayar-muhendisligi) ÇAP'ı yapmak gibi kombinasyonlar ancak o üniversitede açıksa mümkündür. Tercih aşamasında merak ediyorsan üniversitenin "çift anadal programları" listesine bak — bu, geniş üniversitelerin sessiz avantajıdır.
## 4) Yeniden sınava girmek
Her zaman açık olan yol. Ama şu üç şeyi baştan bil:
- Bir yıl maliyeti vardır ve bu yıl geri gelmez.
- Bir yükseköğretim programına kayıtlıysan, ertesi yıl yerleştiğinde eski kaydın silinir; ayrıca kayıtlı olmanın OBP ve bazı programların koşullarıısından sonuçlarını [tercih takvimi](/rehber/yks-tercih-takvimi-2026) ve kılavuz üzerinden kontrol etmelisin.
- Sıralamanın ikinci yılda otomatik olarak yükseleceği garantisi yoktur.
[Yerleşemedim ya da istemediğim bölüme yerleştim](/rehber/yerlesemedim-ne-yapmaliyim) yazısı bu kararı bütün seçenekleriyle birlikte ele alıyor.
## Peki liste kurulurken bu yollar nasıl hesaba katılır?
Tek cümleyle: **hesaba katılmaz.** Listeyi, "buraya yerleşirsem burada okurum" varsayımıyla kur. Yatay geçiş, ÇAP ve yeniden sınav, listeyi gevşetmek için değil, iş ters giderse elinde kalan yollar için vardır.
Somut kural: kayıt yaptırmayacağın bir programı "nasıl olsa geçerim" diye listeye yazma — bu tam olarak [ölü tercih](/rehber/olu-tercih-nedir) mantığındaki hatadır ve yerleşirsen ek yerleştirme hakkın da yanar.
Sıralamanın gerçekten nereye yettiğini görüp listeyi baştan doğru kurmak için [tercih robotuna](/tercih-robotu) sıralamanı gir; hayal, dengeli ve garanti bloklarını tek ekranda görürsün.

View File

@@ -0,0 +1,55 @@
---
baslik: Yerleşemedim ya da İstemediğim Bölüme Yerleştim — Şimdi Ne Olacak?
aciklama: Sonuç ekranı istediğin gibi çıkmadıysa önünde hâlâ üç yol var: ek yerleştirme, yatay geçiş ve yeniden deneme. Hangi durumda hangisi mantıklı, tek şemada.
tarih: 2026-08-01
---
Sonuçlar açıklandığında iki tür hayal kırıklığı yaşanır: hiçbir tercihe yerleşememek ya da listenin sonlarındaki "keşke yazmasaydım" satırına yerleşmek. İkisi de yolun sonu değil — ama ikisinin kuralları **birbirinden çok farklı** ve yanlış hamle, doğru kapıyı kapatabiliyor.
## Önce durumunu netleştir
```mermaid
%% aria: Yerleşememe durumunda karar şeması: sonuç ekranında hiçbir tercihe yerleşemediysen ek yerleştirmeye başvurabilirsin ve boş kontenjanlar için yeni bir 24 tercihlik liste yaparsın; istemediğin bir programa yerleştiysen iki yol vardır: kayıt yaptırırsan birinci sınıfta merkezi yerleştirme puanınla yatay geçiş kapısını araştırabilirsin, kayıt yaptırmazsan yerleşmiş sayıldığın için ek yerleştirmeye giremezsin ve kalan tek yol gelecek yıl yeniden sınava girmektir.
%% altyazi: Kritik ayrım: "yerleşemedim" ek yerleştirme kapısını açar; "yerleştim ama gitmedim" o kapıyı kapatır.
flowchart TD
S{"Sonuç ekranında<br/>ne yazıyor?"}
S -- "hiçbir tercihe yerleşemedin" --> E("Ek yerleştirme hakkın var:<br/>boş kontenjanlar için yeni bir liste")
E --> E2("Eylülde ÖSYM kılavuzu yayımlar,<br/>yeniden 24 tercih yaparsın")
S -- "istemediğin bir programa yerleştin" --> K{"Kayıt yaptıracak mısın?"}
K -- "evet" --> Y("Kayıt ol; 1. sınıfta merkezi puanla<br/>yatay geçiş kapısını araştır")
K -- "hayır" --> R("Yerleşmiş sayılırsın:<br/>ek yerleştirmeye giremezsin,<br/>kalan yol gelecek yıl yeniden YKS")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class E,E2 uyari
class Y garanti
class R hayal
```
## Yol 1: Ek yerleştirme — boşta kalanların ikinci şansı
İlk yerleştirmede **hiçbir programa yerleşemediysen** ek yerleştirmeye başvurabilirsin. Kayıt dönemi bitince boş kalan ve kayıt yaptırılmadığı için boşalan kontenjanlar ÖSYM'nin ek kılavuzunda ilan edilir; yeniden en fazla 24 tercih yaparsın. Tabanlar ilk yerleştirmeye göre genelde gevşer ama en çok istenen programlar ek yerleştirmeye nadiren kalır. Kimin başvurabileceği, takvimi ve stratejisiyle tüm detaylar [ek yerleştirme rehberinde](/rehber/ek-yerlestirme-2026).
Kritik kural bir kez daha: bir programa **yerleştirildiysen** — kayıt yaptırmamış olsan bile — ek yerleştirme sana kapalıdır. "İstemediğim yere yerleştim, kayıt olmayayım, ek tercihte daha iyisini yazarım" planı **çalışmaz.**
## Yol 2: Kayıt ol + yatay geçişi araştır
İstemediğin programa yerleştiysen çoğu durumda en az riskli hamle **kayıt olmaktır.** Çünkü kayıtlı öğrenciye açık bir kapı var: **merkezi yerleştirme puanıyla (Ek Madde-1) yatay geçiş.** Mantığı şu:
- YKS'de aldığın puan, yerleştiğin yıl için geçerliliğini korur.
- Puanın, geçmek istediğin programın **senin yerleştiğin yıldaki** taban puanına eşit ya da ondan yüksekse başvurabilirsin.
- Başvuru, yerleştiğin yıl içinde değil, öğrenimin başladıktan sonraki dönemlerde (üniversitelerin ilan ettiği kontenjan ve takvimle) yapılır ve bu hak **bir kez** kullanılır.
Yani "puanım aslında X bölümüne yetiyordu ama listeme yazmamıştım" durumundaysan, bir dönem/yıl sonra o bölüme sınavsız geçme ihtimalin var. Kontenjanlar sınırlı ve üniversiteden üniversiteye değişir; hedef üniversitenin yatay geçiş sayfasını şimdiden takibe al.
## Yol 3: Yeniden denemek — bedelini bilerek
Gelecek yıl tekrar sınava girmek meşru bir plan; ama iki bedelini baştan bil:
1. **OBP çarpanı:** bir programa yerleştirildiysen (kayıt yaptırmasan bile) gelecek yıl diploma notu katkın yarıya düşer — hesabı [OBP yazısında](/rehber/obp-nedir-nasil-hesaplanir).
2. **Tabanlar sabit durmaz:** bu yıl "az farkla kaçırdığın" bölümün tabanı seneye aynı yerde olmayabilir — [tabanlar nasıl değişir](/rehber/taban-siralamalar-nasil-degisir) yazısı bu oynaklığı verilerle gösteriyor.
## Bir dahaki listeye ders
Bu durumların neredeyse tamamı, liste kurulurken önlenebilir: sonuna gerçekten razı olacağın garantiler koymak, kayıt yaptırmayacağın satırı hiç yazmamak ve [ölü tercihleri](/rehber/olu-tercih-nedir) temizlemek. Ek yerleştirme listesi kuracaksan da aynı disiplin geçerli — sıralamana göre gerçekçi seçenekleri [tercih robotunda](/tercih-robotu) saniyeler içinde görebilirsin.

View File

@@ -0,0 +1,53 @@
---
baslik: YKS 2026 Tercih Takvimi ve Süreç Adımları
aciklama: Sonuçların açıklanmasından ek yerleştirmeye — 2026 tercih döneminin tüm aşamaları tek şemada ve tek sayfada.
tarih: 2026-07-20
---
Tercih dönemi kısa ve her adımı tarihli bir süreçtir. 2026'nın akışı şöyle işliyor (kesin tarihler için tek resmî kaynak ÖSYM duyurularıdır; buradaki çerçeve genel akışı gösterir):
## Sürecin aşamaları
```mermaid
%% aria: 2026 tercih dönemi akış şeması: önce YKS sonuçlarııklanır ve başarı sıralaman netleşir; ardından tercih kılavuzu ve kontenjanlar yayımlanır; Temmuz sonu ile Ağustos başı arasında en fazla 24 tercih girilir; yerleştirme sonuçları Ağustos'ta açıklanır; kayıt dönemi Ağustos sonu ile Eylül başı arasındadır; boş kontenjanlar için ek yerleştirme Eylül'de açılır ama yalnızca ilk turda hiçbir programa yerleşemeyenler başvurabilir.
%% altyazi: Altı aşama sıralı ilerler; kesin tarihler her yıl ÖSYM duyurusuyla netleşir.
flowchart TD
R("1 · YKS sonuçları<br/>başarı sıralaman netleşir") --> K("2 · Kılavuz ve kontenjanlar<br/>yayımlanır")
K --> T("3 · Tercih dönemi<br/>en fazla 24 tercih, ~2 hafta")
T --> Y("4 · Yerleştirme sonuçları<br/>Ağustos")
Y --> Kayit("5 · Kayıt dönemi<br/>e-Devlet veya üniversite")
Kayit --> E("6 · Ek yerleştirme · Eylül<br/>yalnızca boşta kalanlar başvurur")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
class T uyari
class Kayit,E garanti
```
**1) YKS sonuçlarının açıklanması (Temmuz ortası-sonu).**
ÖSYM sonuç belgende puanların ve her puan türü için **başarı sıralaman** yazar. Tercihte kullanacağın sayı budur — puan değil ([neden olduğunu burada anlattık](/rehber/taban-puan-mi-siralama-mi)).
**2) Tercih kılavuzunun ve kontenjanların yayımlanması.**
ÖSYM Yükseköğretim Programları ve Kontenjanları Kılavuzu'nu yayımlar; YÖK Atlas verileri güncellenir. Hangi programın kaç kişi alacağı ve geçen yılların tabanları netleşir.
**3) Tercih dönemi (Temmuz sonu — Ağustos başı, ~2 hafta).**
2026'da tercihler 29 Temmuz - 10 Ağustos arasında alındı. Tercihler ÖSYM AİS (Aday İşlemleri Sistemi) üzerinden girilir; en fazla **24 tercih** hakkın vardır. Liste kurma yöntemi için [tercih listesi rehberine](/rehber/tercih-listesi-nasil-yapilir) bak; sıralamana uygun programları görmek için [tercih robotunu](/tercih-robotu) kullan.
**4) Yerleştirme sonuçlarının açıklanması (Ağustos).**
Tercih döneminin kapanmasından yaklaşık 2-3 hafta sonra. Sonuçla birlikte her programın o yılki gerçek taban puanı ve sıralaması da netleşir.
**5) Kayıt dönemi (Ağustos sonu — Eylül başı).**
Yerleştiğin programa e-Devlet üzerinden veya üniversiteye giderek kayıt yaptırırsın. Kayıt süresini kaçırmak hakkın yanması demektir — tarihleri takvimine işaretle.
**6) Ek yerleştirme (Eylül).**
Boş kalan kontenjanlar için ikinci tur. Kritik kural: ilk yerleştirmede bir programa yerleşen, **kayıt yaptırmasa bile** ek tercihe başvuramaz. Detaylar [ek yerleştirme rehberinde](/rehber/ek-yerlestirme-2026).
## Tercih haftası için pratik plan
- **1. gün:** Sıralamanı doğrula, puan türünü netleştir.
- **2-3. gün:** Program evrenini çıkar. [Bölüm taban puanları](/bolumler) tablolarında ilgilendiğin bölümlerin son yıllardaki tabanlarını incele; [Psikoloji](/bolum/psikoloji) gibi geniş bölümlerde aralığın ne kadar açıldığını görmek ufuk açar.
- **4-5. gün:** Taslak listeyi kur: üstte hayal, ortada dengeli, altta gerçekten gideceğin garanti.
- **6. gün:** Ölü tercih taraması yap ([nasıl yapılır](/rehber/olu-tercih-nedir)), aile onayını al, üniversitelerin özel şartlarını (kılavuz dipnotlarını) oku.
- **Son gün değil, son günden önce:** AİS'e gir, listeyi kod kod işle, onayla, çıktısını sakla. Sistem son saatlerde yoğunluktan yavaşlar — son güne bırakma.
Tercih dönemi stresli görünür ama takvimi bilen için sadece sıralı bir yapılacaklar listesidir. Adımları sırayla yürü, kararlarını veriyle ver.

View File

@@ -0,0 +1,72 @@
---
baslik: Yurt, Burs ve Yıllık Maliyet — Tercih Listesinin Görünmeyen Kolonu
aciklama: Tercih tablosunda maliyet kolonu yok, ama listeyi asıl eleyen o. Barınma, burs ve dört yıllık toplam hesabı — tek şemada.
tarih: 2026-07-29
---
Tercih tablosunda kontenjan var, taban var, tür var — ama **maliyet kolonu yok.** Oysa her yıl binlerce öğrenci yerleştiği yere maliyet yüzünden kayıt yaptıramıyor ya da ikinci dönem şehir değiştirmek zorunda kalıyor. Bu yazı o eksik kolonu doldurmak için: barınma, burs ve dört yıllık gerçek hesap.
## Bir satırın gerçek maliyeti
```mermaid
%% aria: Tercih satırının gerçek maliyeti şeması. Bir programın yıllık maliyeti üç kalemden oluşur. Birincisi öğrenim ücreti: devlet üniversitesi birinci öğretimde normal sürede ücret yoktur, ikinci öğretimde ve süre aşımında katkı payı çıkar; vakıf üniversitesinde burslu programlarda ücret yok, indirimli ve ücretli programlarda ücret vardır. İkincisi barınma: aile yanında kalınıyorsa maliyet en düşüktür, devlet yurdunda orta, özel yurt veya öğrenci evinde en yüksektir. Üçüncüsü yaşam giderleri: yemek, ulaşım, kırtasiye ve şehre gidiş gelişler. Bu üç kalemin toplamı yıllık maliyettir ve öğrenim süresiyle çarpılır. Çıkan sayı ailenin karşılayabileceği tutarın üstündeyse satır listeye yazılmaz veya burslu eşdeğeri aranır. Altındaysa satır listede kalır.
%% altyazi: Ücret kaleminin sıfır olması maliyetin sıfır olduğu anlamına gelmiyor — asıl fark barınmada.
flowchart TD
P("Bir tercih satırı") --> U("1. Öğrenim ücreti<br/>devlet 1. öğretim: yok<br/>vakıf burslu: yok<br/>indirimli / ücretli: var")
P --> B("2. Barınma<br/>aile yanı en düşük<br/>devlet yurdu orta<br/>özel yurt / ev en yüksek")
P --> Y("3. Yaşam<br/>yemek, ulaşım,<br/>kırtasiye, şehir arası yol")
U --> T("Yıllık toplam<br/>x öğrenim süresi")
B --> T
Y --> T
T --> K{"Aile bütçesi<br/>bu tutarı taşır mı?"}
K -- "evet" --> L("Satır listede kalır")
K -- "sınırda" --> S("Burslu / yurdu güçlü<br/>eşdeğerini de listeye ekle")
K -- "hayır" --> C("Satırı yazma:<br/>yerleşirsen kayıt<br/>yaptıramazsın")
classDef uyari fill:#fef3c7,stroke:#f59e0b,color:#92400e
classDef garanti fill:#d1fae5,stroke:#10b981,color:#065f46
classDef hayal fill:#fee2e2,stroke:#ef4444,color:#991b1b
class L garanti
class K,S,T uyari
class C hayal
```
## Kalem 1: Öğrenim ücreti
- **Devlet üniversitesi, birinci öğretim:** Normal öğrenim süresi içinde öğrenim ücreti alınmaz. Süreyi aşarsan veya ikinci öğretimde okursan katkı payı/öğrenim ücreti gündeme gelir. Uzaktan öğretim programlarının kendi ücretlendirmesi vardır.
- **Vakıf üniversitesi:** Aynı bölümün burslu, %50 indirimli, %25 indirimli ve ücretli varyantları **ayrı programlardır**; ayrı kontenjan, ayrı taban, ayrı fiyat. Burslu programda öğrenim ücreti yoktur. [Devlet mi vakıf mı](/rehber/devlet-mi-vakif-mi) yazısı bu tabloyu okumayı anlatıyor.
- **Bursun sürme koşulu:** Vakıf burslarının çoğu giriş bursudur ve süresizdir, ama bazı okullarda not ortalaması şartı vardır. Üniversitenin **burs yönergesini** tercih etmeden önce oku — bu tek belge dört yıllık planını değiştirebilir.
- **Hazırlık yılı:** Hazırlık okuyacaksan bu yılın ücret ve barınma maliyetini de hesaba kat. [Hazırlık sınıfı ve öğretim dili](/rehber/hazirlik-sinifi-ve-ogretim-dili) yazısı hangi programlarda hazırlığın zorunlu olduğunu anlatıyor.
## Kalem 2: Barınma — asıl fark burada
Devlet üniversitesi + büyükşehir kirası, bazen vakıf burslusu + yurt kombinasyonundan pahalıya gelir. İki satırı karşılaştırırken ücrete değil, **toplam yıllık çıkışa** bak.
Barınma seçenekleri ve tercih aşamasında bakman gerekenler:
- **Devlet yurdu (KYK):** Başvurular yerleştirme sonuçlarııklandıktan sonra e-Devlet üzerinden alınır; burs ve öğrenim kredisi başvuruları ise ayrı bir takvimde açılır. Tarihler her yıl Gençlik ve Spor Bakanlığı tarafından duyurulur, sabit değildir — sonuç açıklandığında resmî duyuruyu takip et. **Yerleştirilme garanti değildir**, öncelik kriterleri vardır.
- **Üniversitenin kendi yurdu:** Özellikle vakıf üniversitelerinde kampüs içi yurt kapasitesi ve fiyatı okulun sitesinde yazar. Kapasite küçükse birinci sınıfta yer bulmak zorlaşır.
- **Özel yurt / öğrenci evi:** En pahalı ve en değişken kalem. Aynı şehirde kampüse yürüme mesafesindeki fiyatla, 40 dakika uzaktaki fiyat arasında ciddi fark olur.
- **Aile yanı:** Kendi şehrindeki bir üniversiteyi tercih etmenin ekonomik ağırlığı budur. Bu seçenek elindeyse, listedeki diğer satırların "prim"ini bunun üstüne koyarak düşün: bu program, yılda şu kadar ek maliyeti hak ediyor mu?
Pratik bir kontrol: **kampüsün şehir merkezine uzaklığı**. Şehir dışı kampüslerde kira ucuz ama ulaşım ve zaman maliyeti yüksektir; merkezdeki kampüslerde tam tersi.
## Kalem 3: Yaşam giderleri
Yemek, ulaşım, kırtasiye ve — sık unutulan — **eve gidiş geliş**. Memleketine ayda bir gidecek bir öğrenci için otobüs/uçak parası yılda ciddi bir kalem olur. Şehir seçerken ulaşım hattının varlığına da bak.
## Dört yıllık toplamı çıkarmanın en hızlı yolu
Listeye ciddi olarak yazacağın her satır için üç sayı yaz: **yıllık öğrenim ücreti + yıllık barınma + yıllık yaşam.** Toplamı öğrenim süresiyle (hazırlık varsa +1 yıl) çarp. [Tıp](/bolum/tip) gibi altı yıllık programlarda bu çarpan tek başına belirleyici olabilir.
Sonuç üç kutudan birine düşer:
- **Rahat taşınıyor:** Satır listede kalır.
- **Sınırda:** Satırı listede tut ama aynı bölümün burslu ya da yurdu güçlü bir eşdeğerini de listeye ekle. Böylece iki senaryoya da hazırlıklı olursun.
- **Taşımıyor:** Satırı yazma. "Yerleşirsem bir çaresine bakarız" en pahalı cümledir: yerleştiğin an [ek yerleştirme](/rehber/ek-yerlestirme-2026) hakkın da yanar ve elinde kayıt yaptıramayacağın bir program kalır.
## Bu konuşmayı listeyi vermeden önce yap
Maliyet konuşması tercih listesinin **girdisidir**, sonucu değil. Sonuçlar açıklandıktan sonra yapılan "biz bunu ödeyemeyiz" konuşması bir yıl kaybettirir. [Veliler için tercih rehberi](/rehber/veliler-icin-tercih-rehberi) yazısında bu konuşmanın nasıl yapılacağı ve görev dağılımı var.
Sıralamana düşen programları devlet/vakıf ve şehir filtreleriyle daraltıp maliyet senaryolarını yan yana görmek için [tercih robotuna](/tercih-robotu) sıralamanı girebilirsin.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View File

@@ -3,6 +3,11 @@ services:
build: . build: .
container_name: kolaytercih container_name: kolaytercih
restart: unless-stopped restart: unless-stopped
# Host'u korur: uygulama bu sınırın üstüne çıkamaz. OOM anında kernel'ın
# önce build süreçlerini (skor 0) öldürmesi için negatif oom_score_adj.
mem_limit: 1g
mem_reservation: 256m
oom_score_adj: -600
volumes: volumes:
- app-data:/app/data - app-data:/app/data
env_file: env_file:

View File

@@ -0,0 +1,106 @@
# CTA çekmecesi tasarım algısı — "Sıralamanla nereye yerleşirsin? Saniyede gör."
Bu doküman, programatik SEO sayfalarındaki funnel CTA'sının (`src/components/cta-sira-form.tsx`)
alttan açılan çekmece (drawer) tasarımının arkasındaki algıyı ve kuralları belgeler.
Yeni bir funnel giriş noktası eklerken ya da bu bileşeni değiştirirken buradaki
ilkelere uy.
## 1. Temel algı: vaadi verdiğin yerde tahsil et
Eski davranış adayı ana sayfaya (`/`) gönderiyordu: "Saniyede gör" vaadi verip
saniyeler süren bir sayfa geçişi ve bağlam kaybı yaşatıyordu. Yeni algı şu:
- **Kart vaat eder** — SEO sayfasının içinde duran kart (`bg-primary/5`,
`border-primary/20`) merak uyandırır: "Sıralamanla nereye yerleşirsin?"
- **Çekmece tahsil eder** — CTA butonu sayfadan koparmadan alttan bir çekmece
açar; sıralama girişi, sihirbaz adımları ve tamamlama hepsi aynı bağlamda akar.
- **Ödül `/sonuc`'ta** — seçimler tamamlanınca profil yazılır, çekmece kapanır
ve aday doğrudan sonuç sayfasına gider. Sayfa geçişi yalnızca ödül anında olur.
Akış: **kart (vaat) → çekmece (sıralama) → sihirbaz (kişiselleştirme) → /sonuc (ödül)**.
Profilli adayda çekmece hiç devreye girmez: kayıtlı sıralamayla doğrudan
`/sonuc` linki gösterilir — sıralamasını girmiş adaya bir daha girmesini
söylemeyiz.
## 2. Neden çekmece, modal değil?
- Çekmece **sayfanın üstüne değil, altına eklenir** algısı verir: aday hâlâ
okuduğu üniversite/bölüm sayfasının üzerindedir, içerik kaybolmaz (overlay
hafif: `bg-black/10` + blur).
- Alttan gelen yüzey mobilde başparmak menzilinde; hedef kitle (YKS adayı)
ırlıkla mobilde.
- Swipe-to-dismiss (tutamaktan) ve overlay/Escape ile kaçış ucuz: "bir bakayım"
maliyeti düşük tutulur. `handleOnly` kullanılır ki form/sihirbaz içindeki
kaydırmalar çekmeceyi yanlışlıkla kapatmasın.
- Desktop'ta çekmece tam genişliğe yayılmaz: `sm:max-w-2xl` ile ortalanır,
`sm:border-x + sm:shadow-2xl` ile sayfadan yükselen bir panel gibi durur
(liste çekmecesiyle aynı reçete).
## 3. Görsel dil: yeni hiçbir şey icat etme
Çekmecedeki her parça sitede zaten var olan kanonik kaynaktan gelir:
| Parça | Kaynak / kural |
| --- | --- |
| Eyebrow rozeti ("Saniyede gör") | `SectionEyebrow` (`pixel-decor.tsx`) — elle pill yazılmaz |
| Kapatma çarpısı | `dialog.tsx`'teki kanonik set: `size-9`, `rounded-full`, `border-slate-200`, `size-4` X, hover `bg-slate-100`, `active:scale-[0.96]` |
| CTA butonları | Metin önce, sonda `ArrowRight` (`size-4`); yıldız/Sparkles yok; `bg-orange-500 → hover:bg-orange-600` |
| Puan türü çipleri | Hero formundaki radiogroup çipleriyle birebir aynı class seti |
| Sıralama girişi | Profil kapısındaki desen: sola `Trophy` ikonu, `h-12`, `pl-11` |
| Kanıt üçlüsü | Arama funnel kartıyla aynı üçlü: 24 tercihlik plan / Risk analizi / YÖK Atlas verisi (`ListChecks`, `ChartNoAxesCombined`, `Database`) |
| Başlık/kopya tipografisi | `font-heading` bold başlık, `text-slate-600` gövde, `text-slate-900` vurgu |
Algı hedefi: çekmece açıldığında aday "yeni bir yere geldim" değil, "aynı ürünün
bir katmanı kalktı" hissetmeli. Bu yüzden çekmeceye özgü hiçbir yeni renk,
rozet, buton varyantı tasarlanmaz.
## 4. İçerik tonu
- Öğrenci diliyle, ikinci tekil: "Sıralamanı yaz", "bu sayfadan ayrılmadan gör".
- Sürtünme kaldıran güvence her zaman görünür: **"Ücretsiz, üyelik gerekmez."**
- Kanıt üçlüsü süs değil, ürün vaadinin özetidir; metin etiketleri ikonsuz da
anlamlı olmalı (renk/ikon tek başına anlam taşımaz — ürünün risk renk dili
kuralıyla aynı ilke).
- Buton etiketleri eylemin sonucunu söyler: "Programları gör" (girdi adımı),
"Ücretsiz tablonu gör" / "Yapay Zeka listemi kur (3 kredi)" (sihirbaz sonu, girişe göre).
## 5. Davranış ve teknik algı
- **Statik kalır:** Kart RSC sayfalarında prerender edilir; oturum bilgisi
mount'ta değil, facet isteğiyle **paralel** çözülür (hero formundaki desen) —
landing başına gereksiz auth turu atılmaz.
- **Preload:** CTA butonuna `pointerenter`/`focus` ve sıralama inputuna `focus`
geldiğinde `preloadSihirbazAdimlar()` çalışır; sihirbaz açıldığında chunk
çoktan inmiştir. "Saniyede gör" vaadi teknik olarak da tutulur.
- **İki adım, tek yüzey:** çekmece içinde `sira → sihirbaz` adımları vardır;
erişilebilir ad sabittir (sr-only `DrawerTitle`/`DrawerDescription`), görünür
başlıklar adıma göre değişir.
- **Kapanış = sıfırlama, ama nazikçe:** çekmece kapanınca adım ve facet'ler
sıfırlanır; adayın yazdığı sıralama ve puan türü **korunur** (tekrar açarsa
baştan yazmasın).
- **Tamamlanınca:** `tercihProfiliYaz` → çekmece kapanır → `sonucHref` ile
`/sonuc` (girişliye `sihirbaz: "1"`, girişsize `hazir: "1"`). Giriş duvarı
sihirbazın hemen arkasında değildir; değer önce gösterilir.
- **Lenis:** çekmece içeriği ve kaydırma kabı `data-lenis-prevent` taşır;
sayfadaki smooth-scroll çekmece içi kaydırmayı ezmez.
## 6. Erişilebilirlik
- Sıralama alanı: `inputMode="numeric"`, binlik ayraçlı biçimleme
(85000 → 85.000), hata durumunda `aria-invalid` + `aria-describedby` +
`role="alert"`.
- Puan türü seçimi `role="radiogroup"` / `role="radio"` + `aria-checked`.
- Kapatma yolları: çarpı butonu, overlay, Escape, tutamaktan swipe.
- `prefers-reduced-motion` vaul/motion tarafında zaten sadeleşir; çekmeceye
özel ek animasyon eklenmedi.
## 7. Bu deseni ne zaman kullan / kullanma
**Kullan:** İçerik sayfasında duran ve adaydan tek kritik girdi (sıralama)
isteyen her funnel girişi. Adayın okuduğu bağlam değerliyse (bölüm, üniversite,
rehber) çekmece doğru araçtır.
**Kullanma:** Zaten modal/dialog içinde olan akışlar (arama modalındaki funnel
kartı gibi — modal üstüne çekmece açılmaz, oradaki kart mevcut kapı/dialog
akışını kullanır) ve profilli kısayollar (doğrudan link yeterli).

239
docs/urun/gamification.md Normal file
View File

@@ -0,0 +1,239 @@
# Kolay Tercih — Gamification ve Listeye Ekleme Kurgusu
> Durum: Ürün kararı
> Son güncelleme: 1 Ağustos 2026
## Ana fikir
Kolay Tercih'te bütün deneyim kullanıcının başarı sıralaması üzerine inşa
edilir. Amaç kullanıcıya yalnızca erişebileceği programları göstermek değil;
seçtiği programların sıralamasına, ilgi alanlarına ve önceliklerine ne kadar
uyduğunu açıklayarak tercihine ışık tutmaktır.
Gamification; puan, rozet veya yapay rekabet üzerinden değil, kullanıcının
belirsiz bir fikirden gerekçeli ve dengeli bir tercih listesine ilerlemesi
üzerinden çalışır.
## Değişmez ürün kuralları
1. Başarı sıralaması bütün hesaplamaların başlangıç noktasıdır.
2. Listeye yalnızca tekil bir program eklenir. Üniversitenin veya bölümün tamamı
listeye eklenmez.
3. Program satırlarında erişilebilir bir `+` düğmesi bulunur.
4. Kullanıcı sihirbazı doldurmadan ilk programı listesine ekleyemez.
5. Sihirbaz tamamlandıktan sonra `+` ile seçilen program doğrudan listeye
eklenir; uyumsuz programlar engellenmez.
6. Sistem kullanıcının yerine karar vermez. Çelişkileri görünür kılar, nedenini
ıklar ve son kararı kullanıcıya bırakır.
7. “Garanti kazanırsın” gibi kesinlik bildiren ifadeler kullanılmaz. Risk ve
uyum değerlendirmeleri geçmiş YÖK Atlas verilerine dayalı rehberliktir.
## Kullanıcı yolculuğu
### 1. Sıralamayı öğren
Kullanıcı başarı sıralamasını ve puan türünü girer. Sistem buna göre program
havuzunu, hayal/dengeli/güvenli aralıklarını ve kullanılabilir sihirbaz
seçeneklerini oluşturur.
### 2. Niyetini öğren
Kullanıcı ilk kez bir programdaki `+` düğmesine bastığında sihirbaz seçimleri
yoksa program hemen eklenmez. Tıklanan program “bekleyen program” olarak
korunur ve kısa sihirbaz açılır.
Sihirbaz en az şu bilgileri toplar:
- İlgi alanları
- Tercih edilen şehirler
- Devlet/vakıf tercihi
- Kariyer ve yaşam öncelikleri
Sihirbaz giriş mesajı:
> Önce seni biraz tanıyalım
>
> Sadece sıralamana uyan bir liste değil, ne istediğine de uyan bir tercih
> listesi kurmak istiyoruz. Birkaç kısa seçim yap; eklediğin programların sana
> ne kadar uyduğunu birlikte değerlendirelim.
Kısa alternatif:
> Tercihine ışık tutabilmemiz için önce ne istediğini öğrenelim.
Birincil eylem:
> Tercihlerimi belirle
İkincil eylem:
> Vazgeç
Sihirbaz zorunludur; “şimdilik atla ve ekle” seçeneği bulunmaz.
### 3. İlk programı ekle
Sihirbaz başarıyla tamamlandığında kullanıcının daha önce `+` ile seçtiği
bekleyen program otomatik olarak listeye eklenir. Kullanıcı aynı programı
yeniden bulmak veya tekrar `+` düğmesine basmak zorunda kalmaz.
Başarı bildirimi:
> Program listene eklendi. Sıralamana ve tercihlerine göre değerlendirdik.
### 4. Listeyi bilinçli biçimde geliştir
Sihirbaz tamamlandıktan sonraki `+` tıklamaları programı doğrudan ekler.
Sistem ekleme öncesinde onay modalı göstermez ve uyumsuz seçimleri engellemez.
Her programın değerlendirmesi listede görünür.
## Program değerlendirme modeli
Her eklenen program iki ayrı eksende değerlendirilir:
### Yerleşme riski
Kullanıcının başarı sıralaması ile programın güncel ve geçmiş taban
sıralamaları karşılaştırılır.
Örnek durumlar:
- Hayal
- Dengeli
- Daha güvenli
- Veri yetersiz
“Garanti” yerine mümkün olduğunda “daha güvenli” ifadesi tercih edilir.
### Tercih uyumu
Program, sihirbaz seçimleriyle karşılaştırılır. Uyum tek bir kapalı puan olarak
verilmek yerine anlaşılır gerekçelerle açıklanır.
Örnek olumlu sinyaller:
- İlgi alanlarınla uyumlu
- Tercih ettiğin şehirlerden birinde
- Devlet/vakıf tercihine uyuyor
- Kariyer önceliklerinle örtüşüyor
Örnek çelişki sinyalleri:
- Seçtiğin ilgi alanlarının dışında görünüyor
- Tercih ettiğin şehirlerin dışında
- Üniversite türü tercihinle uyuşmuyor
- Belirttiğin önceliklerle zayıf eşleşiyor
Dil yargılayıcı olmamalıdır. “Sana uygun değil” yerine “seçimlerinle
karşılaştırdığımızda şu noktada ayrışıyor” denir.
## Liste ekranı
Liste yalnızca seçilen programları depolayan bir favoriler alanı değildir.
Kullanıcının tercih stratejisini görünür kılan karar merkezidir.
Her satırda en az şu bilgiler bulunur:
- Program ve üniversite
- Güncel taban sıralaması
- Kullanıcının sıralamasına göre risk durumu
- Tercihlerle uyumlu noktalar
- Varsa çelişki veya dikkat notu
- Listeden çıkarma eylemi
Örnek uyumlu satır mesajı:
> İlgi alanın ve devlet üniversitesi tercihinle uyumlu. Sıralama açısından
> dengeli aralıkta.
Örnek çelişkili satır mesajı:
> Bu program listende kalabilir; ancak seçtiğin ilgi alanlarının ve tercih
> ettiğin şehirlerin dışında görünüyor.
Örnek risk mesajı:
> Geçen yılın taban sıralaması senin sıralamandan daha yukarıda. Hayal
> tercihlerinden biri olarak değerlendirebilirsin.
Birden fazla çelişki varsa sistem hepsini aynı anda bağırmaz. En önemli bir veya
iki gerekçe satırda gösterilir; ayrıntılar açılır alanda sunulur.
## İlerleme hissi
Deneyimin oyunlaştırma döngüsü şöyledir:
1. **Keşfet:** Sıralamana göre programları incele.
2. **Seç:** `+` ile ilgini çeken programı listene al.
3. **Anla:** Sistem risk ve tercih uyumunu açıklar.
4. **Dengele:** Hayal, dengeli ve daha güvenli dağılımını geliştir.
5. **Tamamla:** Gerekçeli 24 tercihlik listeye ulaş.
İlerleme göstergeleri:
- `3 / 24 tercih`
- Hayal / dengeli / daha güvenli dağılımı
- Tercihlerle güçlü uyum gösteren program sayısı
- Dikkat edilmesi gereken seçim sayısı
- Listenin eksik kalan tarafına yönelik tek ve uygulanabilir öneri
Örnek yönlendirmeler:
> Listen dengeli tercihlerde güçleniyor. Birkaç daha güvenli seçenek eklemek
> riski dağıtabilir.
> Seçtiklerinin çoğu aynı şehirde. Şehir konusunda esneksen alternatiflerini
> genişletebilirsin.
> 24 tercihe ulaştın. Şimdi dağılımı ve dikkat notlarını birlikte gözden geçir.
## `+` düğmesinin durumları
- **Varsayılan:** “Listeme ekle”
- **Sihirbaz gerekli:** Tıklama sihirbaz ön bilgilendirmesini açar
- **Ekleniyor:** Düğme geçici olarak devre dışı kalır
- **Eklendi:** `+` yerine onay işareti gösterilir, erişilebilir etiketi
“Listende” olur
- **Liste dolu:** Düğme devre dışıdır ve “Listen 24 tercihe ulaştı” açıklaması
sunulur
- **Hata:** Seçim kaybolmaz; kullanıcıya yeniden deneme eylemi verilir
İkon düğmesinin dokunma alanı en az 44×44 piksel olmalı ve yalnızca ikona bağlı
anlam bırakılmamalıdır. Görsel etiket veya erişilebilir ad bulunmalıdır.
## Sihirbaz seçimlerini değiştirme
Kullanıcı sihirbaz yanıtlarını daha sonra değiştirebilir. Değişiklik mevcut
programları listeden otomatik olarak çıkarmaz. Bütün satırların uyum
değerlendirmesi yeni yanıtlara göre yeniden hesaplanır ve değişen yorumlar
görünür biçimde güncellenir.
Örnek bildirim:
> Tercihlerin güncellendi. Listendeki programları yeni seçimlerine göre yeniden
> değerlendirdik; hiçbir programı silmedik.
## Kaçınılacak kalıplar
- Kullanıcıyı sihirbazı doldurmadığı için suçlayan dil
- Uyumsuz bir programın eklenmesini engellemek
- Sadece renk ile uyum veya risk anlatmak
- Kesin yerleşme vaadi vermek
- Her `+` tıklamasında modal veya onay adımı göstermek
- Rozet, puan ve seri gibi kararın ciddiyetini oyunlaştıran ödüller
- Kullanıcının sihirbazdan önce tıkladığı programı unutmak
- İlgi alanı uyumunu yerleşme ihtimaliyle aynı şeymiş gibi sunmak
## Başarı ölçütleri
- Sıralama sonucundan ilk `+` tıklamasına geçiş
- İlk `+` sonrasında sihirbaz tamamlama oranı
- Sihirbazdan sonra bekleyen programın başarıyla eklenme oranı
- Kullanıcı başına eklenen program sayısı
- 24 tercihe ulaşan kullanıcı oranı
- Uyarı görüldükten sonra programı koruma/çıkarma davranışı
- Sihirbaz tercihlerini güncelleme oranı
- Liste dağılımının zaman içinde daha dengeli hâle gelmesi
Bu metrikler kullanıcıyı daha çok tıklamaya zorlamak için değil, daha bilinçli
bir tercih listesi kurup kuramadığını anlamak için kullanılmalıdır.

View File

@@ -0,0 +1,189 @@
# Kapı 1 Güçlendirme PRD — Ücretsiz Değerden Ücretli Akışa
> Durum: Taslak v1 · Sahip: Bilal · Tarih: 6 Ağustos 2026
> Gösterim: 🔶 Varsayım (makul ama doğrulanmamış) · 🔵 Açık soru (keşif gerekiyor)
## 1. Yönetici Özeti
Sıralamasını girip `/sonuc`'u gören anonim YKS öğrencisine, giriş yapmadan önce ürünün asıl farklılaştırıcı değerini (yapay zekâ gerekçeli tercih satırı) tattıran ve harcadığı emeği (manuel liste + sihirbaz profili) "kaydet, kaybetme" gerekçesiyle girişe bağlayan bir deneyim kuruyoruz. Amaç **Kapı 1 dönüşümünü (sıra girişi → giriş)** artırmak; kapı ölçümleri ve kredi-bitti e-posta dönüşüyle döngüyü kapatmak. Fiyat ve kredi kurgusu (299 TL paket, 5 deneme kredisi, 3 kredi/liste) bu PRD'de sabittir.
## 2. Problem Tanımı
### Problemi kim yaşıyor?
Sıralamasını girip ücretsiz tabloyu gören ama giriş yapmayan anonim öğrenciler (ve ödemeyi çoğu zaman onaylayan velileri).
### Problem ne?
1. **Ürünün asıl değeri kapıdan önce görünmüyor.** Anonim kullanıcı `/sonuc`'ta yalnızca ham YÖK tablosunu görüyor; "yapay zekâ gerekçeli liste"nin nasıl bir şey olduğunu giriş yapıp 3 kredi harcayana kadar hiç tatmıyor. `?hazir=1` panelinin ikna gücü tamamen metne dayanıyor (`src/app/sonuc/sihirbaz-cagri-karti.tsx:262-292`).
2. **Kullanıcı emeği uçucu.** Manuel 24'lük liste ve sihirbaz profili yalnızca localStorage'da (`src/components/manuel-liste/store.ts:16`, `src/lib/sihirbaz.ts:36`); cihaz/tarayıcı değişince kayboluyor ve "listeni kaydet" doğal giriş gerekçesi olarak kullanılmıyor.
3. **Kapılarda ölçüm yok.** `hazir=1` panel gösterimi, paywall/kilit satır görüntülenmesi ve kredi bitişi için event yok (`src/lib/analitik.ts:14-25`'teki union'da karşılıkları yok). Hangi kapıda ne kadar döküldüğü bilinmiyor.
4. **Kredisi biten kullanıcı çıkmaz sokakta.** 5 deneme kredisi tam 1 liste + 2 soruya yetiyor; sonrasında ödeme yoksa kullanıcıyı geri çağıran hiçbir mekanizma yok.
### Neden acı verici?
- **Kullanıcı:** Tercih dönemi kısa ve stresli; değer görmeden hesap açmak ekstra sürtünme. Emeğinin kaybolması güveni zedeliyor.
- **İş:** Kapı 1 funnel'ın en kalabalık geçişi — burada kaybedilen her kullanıcı, alttaki ödeme dönüşümüne hiç ulaşmıyor. Ölçüm olmadığı için iyileştirme de doğrulanamıyor.
### Kanıt
- Kod: maskeleme sunucuda, anonim tarafta hiç AI çıktısı yok (`src/lib/rapor-maske.ts`); liste/profil client-only; event listesi eksik.
- 🔶 Kapı 1 dönüşümünün düşük olduğu varsayımdır — baseline yok. (Bu, ölçüm iş paketinin kendisini gerekçelendiriyor: İP-A önce baseline kurar.)
- 🔵 Rybbit'te mevcut `sira_girildi``giris_denendi` oranına bakılarak kaba bir baseline bugün çıkarılabilir mi?
## 3. Hedef Kullanıcılar ve Personalar
### Birincil: Sıralı Öğrenci
- YKS sonucu açıklanmış, elinde sıralaması var; tercih penceresi ~2 hafta.
- Mobil ağırlıklı, hızlı ve güven veren bir cevap arıyor; hesap açmaya karşı sürtünme eşiği yüksek.
- Davranış: sıralamasını girer, tabloyu karıştırır, birkaç program ekler, sekmesini kapatır — geri gelmesi garantili değil.
### İkincil: Veli
- Ödemenin fiili onaycısı; "danışman 2.00010.000 TL, bu 299 TL" karşılaştırmasına duyarlı.
- Çocuğunun kurduğu listeyi görmek ve güvenilirlik sinyali (gerekçe, risk notu) ister.
## 4. Stratejik Bağlam
- **İş hedefi:** Tek seferlik 299 TL'lik ürünün geliri doğrudan Kapı 1 hacmiyle çarpılır; funnel'ın en üst geçişini iyileştirmek alttaki her adıma bileşik etki yapar.
- **Neden şimdi:** Ürün sezonluk — yoğunluk tercih döneminde. Sezon öncesi funnel'ın oturması gerekiyor; sezon içinde büyük değişiklik riskli.
- **Rekabet:** İnsan danışmanlar (2.00010.000 TL) ve ücretsiz robotlar. Farklılaştırıcı, gerekçeli + risk analizli liste; bu değer şu an kapının arkasında saklı.
## 5. Çözüm Özeti — 4 İş Paketi
> Sıralama bilinçli: önce ölç (A), sonra değeri göster (B), emeği bağla (C), teaser'ı parlat (D).
### İP-A · Kapı ölçümü (temel)
Funnel'ın üç kapısına gösterim/sonuç event'leri eklenir; Kapı 1 baseline'ı kurulur.
- Yeni event'ler (`OlayAdi` union'ına): `hazir_panel_goruntulendi`, `giris_cta_tiklandi` (prop: `kaynak`), `kilit_goruntulendi` (paywall satırı/kartı viewport'a girince), `kredi_bitti` (KREDI hatası panelinde).
- Gösterim event'leri viewport-temelli ve oturum başına 1 kez; `siraKovasi` dışında ham veri gönderilmez (mevcut gizlilik deseni korunur).
### İP-B · Girişsiz yapay zekâ tadımlığı
Anonim kullanıcı `/sonuc`'ta, kendi sıra kovası + alan tercihine uyan **1 örnek tercih satırını gerçek ürün formatında** (gerekçe + risk notu + trend özeti) görür; hemen altında "24 satırın tamamı için giriş yap — 5 deneme kredin hazır" CTA'sı durur.
- **Maliyet/istismar tasarımı:** Tadımlık canlı AI çağrısıyla değil, **önceden üretilmiş havuzdan** servis edilir (sıra kovası × alan kombinasyonları için batch üretim; `src/lib/rapor-havuzu.ts` altyapısıyla ilişkisi 🔵 incelenecek). Anonim istek başına LLM maliyeti sıfır, prompt-injection yüzeyi yok.
- Tadımlık satır, gerçek rapor bileşeniyle (`rapor-listesi.tsx` satır formatı) birebir aynı görünür — "demo" değil "ürünün kendisi" hissi.
- 🔶 Tek satır yeterli tatma sağlar; 2+ satır ücretsiz değeri fazla büyütüp Kapı 1'i zayıflatabilir (guardrail metriğiyle izlenecek).
- 🔵 Tadımlık satırın programı nasıl seçilecek? (Kullanıcının manuel listesindeki ilk program mı, kovadaki en popüler program mı?)
### İP-C · Liste kaydetme = giriş gerekçesi
Manuel liste ve sihirbaz profili girişte sunucuya taşınır; anonim kullanıcıya emeği büyüdükçe "listen yalnızca bu tarayıcıda — kaydet" tetikleyicileri gösterilir.
- Şema: `savedLists` (userId unique, items JSON, profil JSON) — mevcut `reports` deseniyle aynı upsert yaklaşımı.
- Girişte merge: localStorage listesi sunucudakiyle birleşir (çakışmada localStorage kazanır, 24 sınırı korunur 🔶).
- Tetikleyiciler: liste 3+ programa ulaştığında bir kez gösterilen yumuşak banner; "Seçimlerim" panelinde kalıcı satır. Agresif exit-intent popup **yok**.
- Giriş sonrası dönen kullanıcı listesini her cihazda bulur — ürün "kaydettiğin yer" kimliği kazanır.
### İP-D · Teaser zenginleştirme (ikincil metrik: ödeme dönüşümü)
Maskeli rapor deneyiminde kilidin "ne sakladığı" daha somutlaştırılır:
- `uyarilar` tamamen boşaltılmak yerine **1 uyarıık, kalanı "N uyarı daha kilitli"** göstergesi (`src/lib/rapor-maske.ts:41` değişir; maskeleme sunucuda kalır).
- Kilit satırı (`rapor-listesi.tsx:331-337`) satır sayısı + kişiye özel içerik iması taşır ("21 satırda senin sıralamana özel gerekçe ve risk notu hazır").
-ık satır sayısı `ACIK_SATIR = 3` sabit kalır 🔶 (değiştirme kararı ölçüm sonrası ayrı deney).
### Kullanıcı akışı (hedef durum)
```
sıra girildi → /sonuc: ham tablo + TADIMLIK AI SATIRI (B)
→ manuel liste büyüdükçe "kaydet" tetikleyicisi (C)
→ sihirbaz biter → hazir=1 paneli [ölçülüyor] (A)
→ giriş (5 kredi) → liste üretimi → maskeli rapor (zengin teaser, D)
→ ödeme 299 TL
↳ kredi bitti [ölçülüyor] → 48 saat sonra hatırlatma e-postası (A)
```
## 6. Başarı Metrikleri
### Birincil
**Kapı 1 dönüşümü:** `sira_girildi` (tekil oturum) → başarılı giriş oranı.
- Mevcut: bilinmiyor → İP-A ilk 2 hafta baseline kurar.
- 🔶 Hedef: baseline'a göre **göreli +%30** (baseline netleşince revize edilir).
### İkincil
- `hazir_panel_goruntulendi``giris_cta_tiklandi` tıklama oranı.
- Giriş → `liste_olusturuldu` aktivasyon oranı.
- `kilit_goruntulendi``odeme_baslatildi` (İP-D'nin metriği).
- Kredi-bitti e-postası → geri dönüş oturumu oranı.
### Korkuluk (guardrail)
- **Ödeme dönüşümü düşmemeli:** tadımlık, ücretsiz katmanı "yeterli" hissettirip paketi kanibalize etmemeli.
- **AI maliyeti artmamalı:** tadımlık batch-üretim; anonim trafik LLM'e istek atmaz.
- `/sonuc` LCP/performans gerilemez; ham tablo "her zaman ücretsiz" vaadi korunur.
## 7. Kullanıcı Hikâyeleri ve Gereksinimler
### Epik hipotezi
Anonim kullanıcıya gerçek ürün formatında bir yapay zekâ tadımlığı gösterip emeğini kaydetme gerekçesiyle girişe bağlarsak, Kapı 1 dönüşümü artar; çünkü kullanıcı bugün ne alacağını görmeden ve emeğini korumak için hiçbir neden olmadan hesap açmaya itiliyor. Başarıyı `sira_girildi → giriş` oranıyla ölçeceğiz.
### Hikâyeler
**A1 — Kapı event'leri.** Ürün sahibi olarak funnel'ın her kapısında gösterim ve sonuç sayısını görmek istiyorum.
- [ ] `hazir_panel_goruntulendi`, `giris_cta_tiklandi(kaynak)`, `kilit_goruntulendi(yer)`, `kredi_bitti` event'leri `OlayAdi` union'ına eklendi ve ilgili bileşenlerde ateşleniyor.
- [ ] Gösterim event'leri IntersectionObserver ile, oturum başına en fazla 1 kez.
- [ ] Ham sıra gönderilmiyor; `siraKovasi` deseni korunuyor.
**A2 — Kredi-bitti dönüş e-postası.** Kredisi biten kullanıcı olarak, listemin beni beklediğini hatırlatan bir e-posta almak istiyorum.
- [ ] `kredi_bitti` durumuna düşen kullanıcıya 48 saat sonra tek seferlik e-posta (Resend, `eposta.ts` şablon dili).
- [ ] E-posta `/listem`'e deep-link verir; ödeme baskısı ikinci planda, "3 açık satırın hazır" birinci planda.
- [ ] 🔵 Gönderim zamanlaması için altyapı: cron/queue mu, giriş anında lazy-check mi?
- [ ] 🔵 KVKK: işlemsel hatırlatma mı pazarlama izni gerektiren ileti mi — hukuki sınıflandırma netleşecek.
**B1 — Tadımlık satır.** Anonim kullanıcı olarak, sıralamama uygun bir programın yapay zekâ gerekçesini giriş yapmadan görmek istiyorum.
- [ ] `/sonuc`'ta, sıra kovası + (varsa) sihirbaz alan tercihine uyan 1 tadımlık satır gerçek rapor satırı formatında render edilir.
- [ ] İçerik önceden üretilmiş havuzdan gelir; anonim istek LLM'e gitmez.
- [ ] Satırın altında giriş CTA'sı: metin sonunda `ArrowRight`, `Sparkles` yok (CTA kuralı).
- [ ] Havuzda uygun içerik yoksa bileşen hiç render edilmez (boş/generic tadımlık gösterilmez).
- [ ] 🔵 Havuz üretim kapsamı: kova × alan kombinasyon sayısı ve tazeleme sıklığı.
**C1 — Liste sunucuya taşınır.** Giriş yapan kullanıcı olarak, anonimken kurduğum listeyi hesabımda bulmak istiyorum.
- [ ] Girişte localStorage listesi + sihirbaz profili sunucuya merge edilir (çakışmada client kazanır, 24 sınırıılmaz).
- [ ] Farklı cihazdan girişte liste sunucudan yüklenir; localStorage ile iki yönlü senkron kuralı belgelenir.
- [ ] Merge idempotent — çift giriş çift kayıt üretmez.
**C2 — Kaydet tetikleyicisi.** Anonim kullanıcı olarak, listem büyüdüğünde kaybolabileceğini öğrenmek istiyorum.
- [ ] Liste 3. programa ulaştığında bir kez yumuşak banner: "Listen yalnızca bu tarayıcıda — giriş yap, kaydet."
- [ ] "Seçimlerim" panelinde kalıcı "listeni kaydet" satırı.
- [ ] Banner kapatılabilir; kapatma oturumda kalıcı. Exit-intent popup yok.
**D1 — Zengin teaser.** Maskeli raporu gören kullanıcı olarak, kilidin arkasında ne olduğunu somut görmek istiyorum.
- [ ] `uyarilar`dan 1 tanesi açık, kalanı "N uyarı daha kilitli" sayacıyla gösterilir; maskeleme sunucuda kalır.
- [ ] Kilit satırı kişiselleştirilmiş metin taşır (kalan satır sayısı + "senin sıralamana özel").
- [ ] `?acildi=1` unblur akışı bozulmaz.
### Kısıtlar
- Maskeleme ve tadımlık seçimi **her zaman sunucuda** — kilitli gerçek içerik client'a asla inmez.
- Badge/eyebrow, kapatma çarpısı ve CTA ok deseni proje kurallarına uyar (`AGENTS.md`).
- Sihirbaz/liste mimarisinde davranış değişirse `/meraklisina` şeması aynı commit'te güncellenir (`src/app/meraklisina/huni-semasi.tsx`).
## 8. Kapsam Dışı
- Fiyat, paket yapısı, kredi miktarları (sabit — kullanıcı kararı).
- Abonelik, ara paket, referral programı.
- Canlı AI tadımlığı (anonim kullanıcıya gerçek zamanlı LLM çağrısı).
- Exit-intent popup ve agresif e-posta dizileri.
- `ACIK_SATIR` sayısını değiştirme (ölçüm sonrası ayrı deney).
- Mobil uygulama, push notification.
## 9. Bağımlılıklar ve Riskler
### Bağımlılıklar
- **E-posta:** Resend + `eposta.ts` şablonları hazır; yalnızca yeni şablon + tetikleme mekanizması gerekir.
- **Tadımlık havuzu:** `rapor-havuzu.ts` mevcut altyapısının kapsamı incelenecek 🔵; batch üretim script'i gerekebilir.
- **Şema değişikliği:** `savedLists` tablosu (drizzle migration).
- **`/meraklisina` şema senkronu:** İP-B ve İP-C davranış değiştiriyor → şema + anlatım metni aynı PR'da güncellenir.
### Riskler
- **Kanibalizasyon:** Tadımlık + zengin teaser ücretsiz deneyimi "yeterli" hissettirebilir. → Korkuluk metriği; tadımlık 1 satırda sabit başlar.
- **Baseline'sız iterasyon:** A'dan önce B/C/D'ye başlanırsa etki ölçülemez. → İP-A her zaman önce gider; B/C/D en az 2 hafta baseline'dan sonra açılır 🔶.
- **Merge karmaşası (C1):** İki cihazda farklı listeler → sessiz veri kaybı algısı. → Çakışma kuralı basit ve tek yönlü tutulur, edge case'ler kabul kriterlerinde.
- **Sezon zamanlaması:** Yoğun dönemde funnel değişikliği riskli. → Sezon öncesi yayın; sezon içi yalnızca metin/ölçüm ayarı.
- **KVKK/e-posta:** Hatırlatma e-postasının hukuki sınıfı belirsiz 🔵 → netleşene dek A2 yalnızca işlemsel dille yazılır.
## 10. Açık Sorular
1. 🔵 Rybbit'teki mevcut event'lerden bugün kaba bir Kapı 1 baseline'ı çıkarılabilir mi (`sira_girildi` vs `giris_denendi` tekil oranı)?
2. 🔵 Tadımlık satırın program seçimi: manuel listedeki ilk program mı, kova için önceden seçilmiş popüler program mı?
3. 🔵 `rapor-havuzu.ts` bugün ne yapıyor; tadımlık havuzu onun üstüne mi kurulur?
4. 🔵 Kredi-bitti e-postası için zamanlama altyapısı (cron vs lazy-check) ve KVKK sınıfı.
5. 🔵 `savedLists` mi yoksa mevcut `reports.params` üzerinde genişletme mi — şema kararı.
6. 🔶 +%30 göreli hedef baseline sonrası revize edilecek.
---
## Öz Değerlendirme (şablon gereği)
- **En güçlü bölüm:** Problem tanımı — kod referanslarıyla somut.
- **En zayıf bölüm:** Başarı metrikleri — baseline yok; hedefler İP-A tamamlanana dek varsayımsal.
- **Önce doğrulanacak varsayımlar:** (1) Kapı 1 dönüşümünün gerçekten düşük olduğu, (2) tek satır tadımlığın kanibalize etmeden ikna ettiği.
- **Önerilen ilk adım:** İP-A'yı uygula (küçük, risksiz, 1-2 gün) + Rybbit'ten retrospektif baseline denemesi; 2 hafta veriyle B/C önceliği netleştir.

131
drizzle/0000_baslangic.sql Normal file
View File

@@ -0,0 +1,131 @@
CREATE TABLE `account` (
`id` text PRIMARY KEY NOT NULL,
`account_id` text NOT NULL,
`provider_id` text NOT NULL,
`user_id` text NOT NULL,
`access_token` text,
`refresh_token` text,
`id_token` text,
`access_token_expires_at` integer,
`refresh_token_expires_at` integer,
`scope` text,
`password` text,
`created_at` integer NOT NULL,
`updated_at` integer NOT NULL,
FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) ON UPDATE no action ON DELETE cascade
);
--> statement-breakpoint
CREATE TABLE `chat_messages` (
`id` text PRIMARY KEY NOT NULL,
`user_id` text NOT NULL,
`role` text NOT NULL,
`content` text NOT NULL,
`client_message_id` text,
`created_at` integer NOT NULL,
FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) ON UPDATE no action ON DELETE no action
);
--> statement-breakpoint
CREATE UNIQUE INDEX `chat_messages_client_message_id_unique` ON `chat_messages` (`client_message_id`);--> statement-breakpoint
CREATE INDEX `chat_user_created` ON `chat_messages` (`user_id`,`created_at`);--> statement-breakpoint
CREATE TABLE `credit_ledger` (
`id` text PRIMARY KEY NOT NULL,
`user_id` text NOT NULL,
`delta` integer NOT NULL,
`reason` text NOT NULL,
`ref_id` text,
`created_at` integer NOT NULL,
FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) ON UPDATE no action ON DELETE no action
);
--> statement-breakpoint
CREATE UNIQUE INDEX `ledger_reason_ref` ON `credit_ledger` (`reason`,`ref_id`);--> statement-breakpoint
CREATE INDEX `ledger_user` ON `credit_ledger` (`user_id`);--> statement-breakpoint
CREATE TABLE `orders` (
`id` text PRIMARY KEY NOT NULL,
`user_id` text NOT NULL,
`product` text NOT NULL,
`amount_kurus` integer NOT NULL,
`credits` integer NOT NULL,
`status` text DEFAULT 'pending' NOT NULL,
`iyzico_token` text,
`iyzico_payment_id` text,
`created_at` integer NOT NULL,
`paid_at` integer,
FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) ON UPDATE no action ON DELETE no action
);
--> statement-breakpoint
CREATE INDEX `orders_user` ON `orders` (`user_id`);--> statement-breakpoint
CREATE TABLE `reports` (
`id` text PRIMARY KEY NOT NULL,
`user_id` text NOT NULL,
`params` text NOT NULL,
`result` text,
`revision_count` integer DEFAULT 0 NOT NULL,
`created_at` integer NOT NULL,
`updated_at` integer NOT NULL,
FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) ON UPDATE no action ON DELETE no action
);
--> statement-breakpoint
CREATE UNIQUE INDEX `reports_user_id_unique` ON `reports` (`user_id`);--> statement-breakpoint
CREATE TABLE `saved_lists` (
`id` text PRIMARY KEY NOT NULL,
`user_id` text NOT NULL,
`items` text NOT NULL,
`profil` text,
`created_at` integer NOT NULL,
`updated_at` integer NOT NULL,
FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) ON UPDATE no action ON DELETE no action
);
--> statement-breakpoint
CREATE UNIQUE INDEX `saved_lists_user_id_unique` ON `saved_lists` (`user_id`);--> statement-breakpoint
CREATE TABLE `session` (
`id` text PRIMARY KEY NOT NULL,
`expires_at` integer NOT NULL,
`token` text NOT NULL,
`ip_address` text,
`user_agent` text,
`user_id` text NOT NULL,
`created_at` integer NOT NULL,
`updated_at` integer NOT NULL,
FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) ON UPDATE no action ON DELETE cascade
);
--> statement-breakpoint
CREATE UNIQUE INDEX `session_token_unique` ON `session` (`token`);--> statement-breakpoint
CREATE TABLE `tadimlik_havuzu` (
`id` text PRIMARY KEY NOT NULL,
`kova_slug` text NOT NULL,
`tur` text NOT NULL,
`kategori_slug` text NOT NULL,
`program_id` text NOT NULL,
`dilim` text NOT NULL,
`gerekce` text NOT NULL,
`risk_notu` text NOT NULL,
`trend_ozeti` text NOT NULL,
`program` text NOT NULL,
`ornek_sira` integer NOT NULL,
`uretim_at` integer NOT NULL
);
--> statement-breakpoint
CREATE UNIQUE INDEX `tadimlik_anahtar` ON `tadimlik_havuzu` (`kova_slug`,`tur`,`kategori_slug`);--> statement-breakpoint
CREATE TABLE `user` (
`id` text PRIMARY KEY NOT NULL,
`name` text NOT NULL,
`email` text NOT NULL,
`email_verified` integer DEFAULT false NOT NULL,
`image` text,
`credit_balance` integer DEFAULT 0 NOT NULL,
`has_paket` integer DEFAULT false NOT NULL,
`kredi_bitti_at` integer,
`kredi_hatirlatma_gonderildi_at` integer,
`created_at` integer NOT NULL,
`updated_at` integer NOT NULL
);
--> statement-breakpoint
CREATE UNIQUE INDEX `user_email_unique` ON `user` (`email`);--> statement-breakpoint
CREATE TABLE `verification` (
`id` text PRIMARY KEY NOT NULL,
`identifier` text NOT NULL,
`value` text NOT NULL,
`expires_at` integer NOT NULL,
`created_at` integer,
`updated_at` integer
);

View File

@@ -0,0 +1,898 @@
{
"version": "6",
"dialect": "sqlite",
"id": "a802fded-01d5-4d17-8b6f-fca5dfc2920d",
"prevId": "00000000-0000-0000-0000-000000000000",
"tables": {
"account": {
"name": "account",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"account_id": {
"name": "account_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"provider_id": {
"name": "provider_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"user_id": {
"name": "user_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"access_token": {
"name": "access_token",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"refresh_token": {
"name": "refresh_token",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"id_token": {
"name": "id_token",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"access_token_expires_at": {
"name": "access_token_expires_at",
"type": "integer",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"refresh_token_expires_at": {
"name": "refresh_token_expires_at",
"type": "integer",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"scope": {
"name": "scope",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"password": {
"name": "password",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"updated_at": {
"name": "updated_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
}
},
"indexes": {},
"foreignKeys": {
"account_user_id_user_id_fk": {
"name": "account_user_id_user_id_fk",
"tableFrom": "account",
"tableTo": "user",
"columnsFrom": [
"user_id"
],
"columnsTo": [
"id"
],
"onDelete": "cascade",
"onUpdate": "no action"
}
},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"chat_messages": {
"name": "chat_messages",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"user_id": {
"name": "user_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"role": {
"name": "role",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"content": {
"name": "content",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"client_message_id": {
"name": "client_message_id",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
}
},
"indexes": {
"chat_messages_client_message_id_unique": {
"name": "chat_messages_client_message_id_unique",
"columns": [
"client_message_id"
],
"isUnique": true
},
"chat_user_created": {
"name": "chat_user_created",
"columns": [
"user_id",
"created_at"
],
"isUnique": false
}
},
"foreignKeys": {
"chat_messages_user_id_user_id_fk": {
"name": "chat_messages_user_id_user_id_fk",
"tableFrom": "chat_messages",
"tableTo": "user",
"columnsFrom": [
"user_id"
],
"columnsTo": [
"id"
],
"onDelete": "no action",
"onUpdate": "no action"
}
},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"credit_ledger": {
"name": "credit_ledger",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"user_id": {
"name": "user_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"delta": {
"name": "delta",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"reason": {
"name": "reason",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"ref_id": {
"name": "ref_id",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
}
},
"indexes": {
"ledger_reason_ref": {
"name": "ledger_reason_ref",
"columns": [
"reason",
"ref_id"
],
"isUnique": true
},
"ledger_user": {
"name": "ledger_user",
"columns": [
"user_id"
],
"isUnique": false
}
},
"foreignKeys": {
"credit_ledger_user_id_user_id_fk": {
"name": "credit_ledger_user_id_user_id_fk",
"tableFrom": "credit_ledger",
"tableTo": "user",
"columnsFrom": [
"user_id"
],
"columnsTo": [
"id"
],
"onDelete": "no action",
"onUpdate": "no action"
}
},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"orders": {
"name": "orders",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"user_id": {
"name": "user_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"product": {
"name": "product",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"amount_kurus": {
"name": "amount_kurus",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"credits": {
"name": "credits",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"status": {
"name": "status",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false,
"default": "'pending'"
},
"iyzico_token": {
"name": "iyzico_token",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"iyzico_payment_id": {
"name": "iyzico_payment_id",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"paid_at": {
"name": "paid_at",
"type": "integer",
"primaryKey": false,
"notNull": false,
"autoincrement": false
}
},
"indexes": {
"orders_user": {
"name": "orders_user",
"columns": [
"user_id"
],
"isUnique": false
}
},
"foreignKeys": {
"orders_user_id_user_id_fk": {
"name": "orders_user_id_user_id_fk",
"tableFrom": "orders",
"tableTo": "user",
"columnsFrom": [
"user_id"
],
"columnsTo": [
"id"
],
"onDelete": "no action",
"onUpdate": "no action"
}
},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"reports": {
"name": "reports",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"user_id": {
"name": "user_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"params": {
"name": "params",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"result": {
"name": "result",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"revision_count": {
"name": "revision_count",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false,
"default": 0
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"updated_at": {
"name": "updated_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
}
},
"indexes": {
"reports_user_id_unique": {
"name": "reports_user_id_unique",
"columns": [
"user_id"
],
"isUnique": true
}
},
"foreignKeys": {
"reports_user_id_user_id_fk": {
"name": "reports_user_id_user_id_fk",
"tableFrom": "reports",
"tableTo": "user",
"columnsFrom": [
"user_id"
],
"columnsTo": [
"id"
],
"onDelete": "no action",
"onUpdate": "no action"
}
},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"saved_lists": {
"name": "saved_lists",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"user_id": {
"name": "user_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"items": {
"name": "items",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"profil": {
"name": "profil",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"updated_at": {
"name": "updated_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
}
},
"indexes": {
"saved_lists_user_id_unique": {
"name": "saved_lists_user_id_unique",
"columns": [
"user_id"
],
"isUnique": true
}
},
"foreignKeys": {
"saved_lists_user_id_user_id_fk": {
"name": "saved_lists_user_id_user_id_fk",
"tableFrom": "saved_lists",
"tableTo": "user",
"columnsFrom": [
"user_id"
],
"columnsTo": [
"id"
],
"onDelete": "no action",
"onUpdate": "no action"
}
},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"session": {
"name": "session",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"expires_at": {
"name": "expires_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"token": {
"name": "token",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"ip_address": {
"name": "ip_address",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"user_agent": {
"name": "user_agent",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"user_id": {
"name": "user_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"updated_at": {
"name": "updated_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
}
},
"indexes": {
"session_token_unique": {
"name": "session_token_unique",
"columns": [
"token"
],
"isUnique": true
}
},
"foreignKeys": {
"session_user_id_user_id_fk": {
"name": "session_user_id_user_id_fk",
"tableFrom": "session",
"tableTo": "user",
"columnsFrom": [
"user_id"
],
"columnsTo": [
"id"
],
"onDelete": "cascade",
"onUpdate": "no action"
}
},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"tadimlik_havuzu": {
"name": "tadimlik_havuzu",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"kova_slug": {
"name": "kova_slug",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"tur": {
"name": "tur",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"kategori_slug": {
"name": "kategori_slug",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"program_id": {
"name": "program_id",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"dilim": {
"name": "dilim",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"gerekce": {
"name": "gerekce",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"risk_notu": {
"name": "risk_notu",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"trend_ozeti": {
"name": "trend_ozeti",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"program": {
"name": "program",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"ornek_sira": {
"name": "ornek_sira",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"uretim_at": {
"name": "uretim_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
}
},
"indexes": {
"tadimlik_anahtar": {
"name": "tadimlik_anahtar",
"columns": [
"kova_slug",
"tur",
"kategori_slug"
],
"isUnique": true
}
},
"foreignKeys": {},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"user": {
"name": "user",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"name": {
"name": "name",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"email": {
"name": "email",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"email_verified": {
"name": "email_verified",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false,
"default": false
},
"image": {
"name": "image",
"type": "text",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"credit_balance": {
"name": "credit_balance",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false,
"default": 0
},
"has_paket": {
"name": "has_paket",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false,
"default": false
},
"kredi_bitti_at": {
"name": "kredi_bitti_at",
"type": "integer",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"kredi_hatirlatma_gonderildi_at": {
"name": "kredi_hatirlatma_gonderildi_at",
"type": "integer",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"updated_at": {
"name": "updated_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
}
},
"indexes": {
"user_email_unique": {
"name": "user_email_unique",
"columns": [
"email"
],
"isUnique": true
}
},
"foreignKeys": {},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
},
"verification": {
"name": "verification",
"columns": {
"id": {
"name": "id",
"type": "text",
"primaryKey": true,
"notNull": true,
"autoincrement": false
},
"identifier": {
"name": "identifier",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"value": {
"name": "value",
"type": "text",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"expires_at": {
"name": "expires_at",
"type": "integer",
"primaryKey": false,
"notNull": true,
"autoincrement": false
},
"created_at": {
"name": "created_at",
"type": "integer",
"primaryKey": false,
"notNull": false,
"autoincrement": false
},
"updated_at": {
"name": "updated_at",
"type": "integer",
"primaryKey": false,
"notNull": false,
"autoincrement": false
}
},
"indexes": {},
"foreignKeys": {},
"compositePrimaryKeys": {},
"uniqueConstraints": {},
"checkConstraints": {}
}
},
"views": {},
"enums": {},
"_meta": {
"schemas": {},
"tables": {},
"columns": {}
},
"internal": {
"indexes": {}
}
}

View File

@@ -0,0 +1,13 @@
{
"version": "7",
"dialect": "sqlite",
"entries": [
{
"idx": 0,
"version": "6",
"when": 1786053613118,
"tag": "0000_baslangic",
"breakpoints": true
}
]
}

View File

@@ -1,13 +1,50 @@
import type { NextConfig } from "next"; import type { NextConfig } from "next";
// Dockerfile builder katmanı BUILD_KAYNAK_KISITLI=1 verir: imaj build'i prod
// VPS'te çalışan uygulamayla aynı makinede koştuğu için bellek/paralellik kısılır.
// Lokal build ve dev bu kısıtlardan etkilenmez.
const kaynakKisitli = process.env.BUILD_KAYNAK_KISITLI === "1";
const nextConfig: NextConfig = { const nextConfig: NextConfig = {
// PPR: statik kabuk anında servis edilir, dinamik parçalar (UserNav vb.)
// Suspense sınırlarının içinde akar. Bkz. docs/cacheComponents.md.
cacheComponents: true,
output: "standalone", output: "standalone",
serverExternalPackages: ["better-sqlite3", "iyzipay", "@libsql/client"], // Server-only paketler bundle dışında tutulur: Turbopack bunları derlemez
// (build belleği ciddi düşer), runtime'da native require ile yüklenir ve
// standalone trace'i imaja kopyalar. (Tarihçe: @google/genai'nin sürüklediği
// bağımlılık zinciri VPS'te build OOM'unu tetiklemişti; AI katmanı artık
// yalnızca openai paketiyle OpenRouter'a gidiyor.)
serverExternalPackages: [
"better-sqlite3",
"iyzipay",
"@libsql/client",
"openai",
"resend",
],
...(kaynakKisitli
? {
// cacheComponents açıkken prerender fazında source map üretimi varsayılan
// açık; 1900+ statik sayfada ciddi bellek maliyeti var.
enablePrerenderSourceMaps: false,
experimental: {
// Turbopack'ın Rust tarafı NODE_OPTIONS heap sınırını görmez; bellek
// hedefi byte cinsinden ayrıca verilir (1.5 GB).
turbopackMemoryLimit: 1_610_612_736,
// Statik üretim: varsayılan 4 worker × 8 eşzamanlı sayfa yerine tek
// worker × 4 sayfa. Her worker ayrı bir Node süreci/heap'idir.
cpus: 1,
staticGenerationMaxConcurrency: 4,
},
}
: {}),
async redirects() { async redirects() {
// Eski akış /sonuc modalına taşındı. /rapor/yazdir korunur (tam eşleşme). // Eski akış /sonuc modalına taşındı. /rapor/yazdir korunur (tam eşleşme).
return [ return [
{ source: "/rapor", destination: "/sonuc", permanent: false }, { source: "/rapor", destination: "/sonuc", permanent: false },
{ source: "/sohbet", destination: "/listem", permanent: false }, { source: "/sohbet", destination: "/listem", permanent: false },
// Ayrı robot sayfası kaldırıldı; rehber içi linkler hero formuna düşer.
{ source: "/tercih-robotu", destination: "/#hero-form", permanent: true },
]; ];
}, },
}; };

12500
package-lock.json generated

File diff suppressed because it is too large Load Diff

View File

@@ -8,23 +8,32 @@
"start": "next start", "start": "next start",
"lint": "eslint", "lint": "eslint",
"ingest": "tsx scripts/ingest.ts", "ingest": "tsx scripts/ingest.ts",
"refresh": "tsx scripts/refresh.ts" "refresh": "tsx scripts/refresh.ts",
"detay": "tsx scripts/detay.ts",
"logolar": "tsx scripts/logo-indir.ts",
"db:push": "drizzle-kit push",
"db:generate": "drizzle-kit generate",
"db:migrate": "node scripts/db-goc.mjs",
"tadimlik": "tsx scripts/tadimlik-uret.ts"
}, },
"dependencies": { "dependencies": {
"@anthropic-ai/sdk": "^0.112.4", "@cds/city": "^1.1.0",
"@libsql/client": "^0.17.4", "@libsql/client": "^0.17.4",
"@react-pdf/renderer": "^4.5.1", "@number-flow/react": "^0.6.2",
"better-auth": "^1.6.23", "better-auth": "^1.6.23",
"better-sqlite3": "^12.11.1", "better-sqlite3": "^12.11.1",
"class-variance-authority": "^0.7.1", "class-variance-authority": "^0.7.1",
"clsx": "^2.1.1", "clsx": "^2.1.1",
"drizzle-orm": "^0.45.2", "drizzle-orm": "^0.45.2",
"iyzipay": "^2.0.69", "iyzipay": "^2.0.69",
"lenis": "^1.3.25",
"lucide-react": "^1.25.0", "lucide-react": "^1.25.0",
"marked": "^18.0.7", "marked": "^18.0.7",
"mermaid": "^11.16.0",
"motion": "^12.42.2", "motion": "^12.42.2",
"next": "16.2.10", "next": "16.2.10",
"next-themes": "^0.4.6", "next-themes": "^0.4.6",
"openai": "^7.4.0",
"radix-ui": "^1.6.3", "radix-ui": "^1.6.3",
"react": "19.2.4", "react": "19.2.4",
"react-dom": "19.2.4", "react-dom": "19.2.4",
@@ -39,6 +48,7 @@
"turkey-map-react": "^2.0.5", "turkey-map-react": "^2.0.5",
"tw-animate-css": "^1.4.0", "tw-animate-css": "^1.4.0",
"use-stick-to-bottom": "^1.1.6", "use-stick-to-bottom": "^1.1.6",
"vaul": "^1.1.2",
"zod": "^4.4.3" "zod": "^4.4.3"
}, },
"devDependencies": { "devDependencies": {

1326
pnpm-lock.yaml generated

File diff suppressed because it is too large Load Diff

View File

@@ -1 +0,0 @@
<svg fill="none" viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg"><path d="M14.5 13.5V5.41a1 1 0 0 0-.3-.7L9.8.29A1 1 0 0 0 9.08 0H1.5v13.5A2.5 2.5 0 0 0 4 16h8a2.5 2.5 0 0 0 2.5-2.5m-1.5 0v-7H8v-5H3v12a1 1 0 0 0 1 1h8a1 1 0 0 0 1-1M9.5 5V2.12L12.38 5zM5.13 5h-.62v1.25h2.12V5zm-.62 3h7.12v1.25H4.5zm.62 3h-.62v1.25h7.12V11z" clip-rule="evenodd" fill="#666" fill-rule="evenodd"/></svg>

Before

Width:  |  Height:  |  Size: 391 B

View File

@@ -1 +0,0 @@
<svg fill="none" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><g clip-path="url(#a)"><path fill-rule="evenodd" clip-rule="evenodd" d="M10.27 14.1a6.5 6.5 0 0 0 3.67-3.45q-1.24.21-2.7.34-.31 1.83-.97 3.1M8 16A8 8 0 1 0 8 0a8 8 0 0 0 0 16m.48-1.52a7 7 0 0 1-.96 0H7.5a4 4 0 0 1-.84-1.32q-.38-.89-.63-2.08a40 40 0 0 0 3.92 0q-.25 1.2-.63 2.08a4 4 0 0 1-.84 1.31zm2.94-4.76q1.66-.15 2.95-.43a7 7 0 0 0 0-2.58q-1.3-.27-2.95-.43a18 18 0 0 1 0 3.44m-1.27-3.54a17 17 0 0 1 0 3.64 39 39 0 0 1-4.3 0 17 17 0 0 1 0-3.64 39 39 0 0 1 4.3 0m1.1-1.17q1.45.13 2.69.34a6.5 6.5 0 0 0-3.67-3.44q.65 1.26.98 3.1M8.48 1.5l.01.02q.41.37.84 1.31.38.89.63 2.08a40 40 0 0 0-3.92 0q.25-1.2.63-2.08a4 4 0 0 1 .85-1.32 7 7 0 0 1 .96 0m-2.75.4a6.5 6.5 0 0 0-3.67 3.44 29 29 0 0 1 2.7-.34q.31-1.83.97-3.1M4.58 6.28q-1.66.16-2.95.43a7 7 0 0 0 0 2.58q1.3.27 2.95.43a18 18 0 0 1 0-3.44m.17 4.71q-1.45-.12-2.69-.34a6.5 6.5 0 0 0 3.67 3.44q-.65-1.27-.98-3.1" fill="#666"/></g><defs><clipPath id="a"><path fill="#fff" d="M0 0h16v16H0z"/></clipPath></defs></svg>

Before

Width:  |  Height:  |  Size: 1.0 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.0 KiB

View File

@@ -0,0 +1,6 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 180 180" role="img" aria-labelledby="title">
<title id="title">KolayTercih</title>
<rect x="27" y="56" width="57" height="57" rx="13" fill="#3b82f6"/>
<rect x="91" y="29" width="56" height="56" rx="13" fill="#fdc7a7"/>
<rect x="91" y="95" width="56" height="56" rx="13" fill="#ff5a00"/>
</svg>

After

Width:  |  Height:  |  Size: 355 B

View File

@@ -1 +0,0 @@
<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 394 80"><path fill="#000" d="M262 0h68.5v12.7h-27.2v66.6h-13.6V12.7H262V0ZM149 0v12.7H94v20.4h44.3v12.6H94v21h55v12.6H80.5V0h68.7zm34.3 0h-17.8l63.8 79.4h17.9l-32-39.7 32-39.6h-17.9l-23 28.6-23-28.6zm18.3 56.7-9-11-27.1 33.7h17.8l18.3-22.7z"/><path fill="#000" d="M81 79.3 17 0H0v79.3h13.6V17l50.2 62.3H81Zm252.6-.4c-1 0-1.8-.4-2.5-1s-1.1-1.6-1.1-2.6.3-1.8 1-2.5 1.6-1 2.6-1 1.8.3 2.5 1a3.4 3.4 0 0 1 .6 4.3 3.7 3.7 0 0 1-3 1.8zm23.2-33.5h6v23.3c0 2.1-.4 4-1.3 5.5a9.1 9.1 0 0 1-3.8 3.5c-1.6.8-3.5 1.3-5.7 1.3-2 0-3.7-.4-5.3-1s-2.8-1.8-3.7-3.2c-.9-1.3-1.4-3-1.4-5h6c.1.8.3 1.6.7 2.2s1 1.2 1.6 1.5c.7.4 1.5.5 2.4.5 1 0 1.8-.2 2.4-.6a4 4 0 0 0 1.6-1.8c.3-.8.5-1.8.5-3V45.5zm30.9 9.1a4.4 4.4 0 0 0-2-3.3 7.5 7.5 0 0 0-4.3-1.1c-1.3 0-2.4.2-3.3.5-.9.4-1.6 1-2 1.6a3.5 3.5 0 0 0-.3 4c.3.5.7.9 1.3 1.2l1.8 1 2 .5 3.2.8c1.3.3 2.5.7 3.7 1.2a13 13 0 0 1 3.2 1.8 8.1 8.1 0 0 1 3 6.5c0 2-.5 3.7-1.5 5.1a10 10 0 0 1-4.4 3.5c-1.8.8-4.1 1.2-6.8 1.2-2.6 0-4.9-.4-6.8-1.2-2-.8-3.4-2-4.5-3.5a10 10 0 0 1-1.7-5.6h6a5 5 0 0 0 3.5 4.6c1 .4 2.2.6 3.4.6 1.3 0 2.5-.2 3.5-.6 1-.4 1.8-1 2.4-1.7a4 4 0 0 0 .8-2.4c0-.9-.2-1.6-.7-2.2a11 11 0 0 0-2.1-1.4l-3.2-1-3.8-1c-2.8-.7-5-1.7-6.6-3.2a7.2 7.2 0 0 1-2.4-5.7 8 8 0 0 1 1.7-5 10 10 0 0 1 4.3-3.5c2-.8 4-1.2 6.4-1.2 2.3 0 4.4.4 6.2 1.2 1.8.8 3.2 2 4.3 3.4 1 1.4 1.5 3 1.5 5h-5.8z"/></svg>

Before

Width:  |  Height:  |  Size: 1.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.6 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 130 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.6 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

Some files were not shown because too many files have changed in this diff Show More