# Project export: GenPHD: Decision Intelligence for AI Engineers

This document was generated by HackStack to give an AI agent context about a hackathon project. Sections are labeled with their provenance; content marked as truncated was cut to keep this document small.

## Project metadata

- Hackathon: OpenAI Build Week
- Tagline: Turn conflicting AI advice into an evidence-backed next build action — then learn from what happens when you act on it.
- Devpost: https://devpost.com/software/genphd-decision-intelligence-for-ai-engineers
- GitHub: https://github.com/ankitpt2005/GenPHD
- Demo: https://genphd.onrender.com/
- Video: https://www.youtube.com/embed/dT062xRrfZo?enablejsapi=1&hl=en_US&rel=0&start=&version=3&wmode=transparent
- Team: 2 GitHub contributor(s) — ankitpt2005 (26 commits), rachandeep Kaur (2 commits)

## Devpost submission (written by the team)

### Inspiration

Every AI engineer has lost hours asking the same question in five different tabs — ChatGPT says use agents, a tutorial says use a framework, the docs say something else entirely. The problem was never a lack of answers. It was a lack of a system that remembers your project, weighs evidence over opinion, and turns a decision into an actual next step. That's why we built GenPHD — the decision intelligence layer for AI engineers.

### What it does

GenPHD turns conflicting AI advice into an evidence-backed next build action, then learns from what happens when you act on it. The core loop: You describe your goal, active project, stack, time budget, and current blocker. GenPHD builds a concise roadmap with your next three milestones. When you're stuck, you ask a real decision question — e.g. "Should I use LangGraph for this two-day RAG project?" GenPHD returns a Decision Brief: source-backed evidence, tradeoffs, a recommendation, an explicit confidence level, a counterfactual ("choose the alternative if…"), and one next action. That action becomes a Build Mission with a target outcome and acceptance criteria. Once you complete it, GenPHD records the outcome, updates your skill evidence, and adjusts your roadmap. It is not a generic chatbot, a course platform, or a multi-agent dashboard. It's a closed decision loop — evidence in, action out, learning compounding over time.

### How we built it

Frontend/App: Next.js (App Router, TypeScript strict mode), Tailwind CSS, shadcn/ui, Lucide icons Backend: Supabase (PostgreSQL, Auth, Row Level Security, Storage), typed server routes, Zod schema validation at every boundary AI workflow: OpenAI as the primary reasoning layer, orchestrated as a controlled pipeline — Context Builder → Evidence Retriever → Parallel Deliberation → Claim Adjudicator → Action Composer → Reflection Evaluator — not an unconstrained autonomous agent Architecture: Deliberate modular monolith for the MVP; services split only when there's a measured reason (e.g. sandboxed code evaluation) Design system: A monochrome, restraint-first UI (Apple-level calm, Linear-level density discipline) — no gradients, no gamification, one primary action per screen Source grounding: Curated, versioned source corpus with visible URLs and dates, tiered by trust (official docs > maintainer repos > practitioner articles > unsourced social content)

### Challenges we ran into

Designing a Decision Brief structure that's genuinely useful rather than "AI says X" — we had to force every recommendation to expose uncertainty and a counterfactual, not just a confident-sounding answer. Resisting the urge to build a flashy multi-agent dashboard. The real value was in a disciplined, inspectable workflow, not agent theatre. Keeping memory transparent and user-controlled (visible, editable, deletable) while still making the roadmap feel adaptive and smart. Scoping the MVP tightly — cutting gamification, social feeds, and admin dashboards that would have diluted the core loop.

### Accomplishments we're proud of

A working end-to-end loop: onboarding → Decision Brief → Build Mission → reflection → updated roadmap. A Decision Brief that always shows its evidence, its confidence, and what would change the recommendation — instead of presenting model output as ground truth. A design system that stays calm and legible under real product complexity, with zero dashboard clutter.

### What we learned

Model consensus isn't trust — evidence quality, recency, and fit to the user's actual constraints are what make a recommendation defensible. Building a product around a loop (decide → act → reflect → improve) creates far more lasting value than another single-turn chat interface.

### What's next

for GenPHD Repository-aware evidence retrieval tied directly to a user's codebase Secure sandboxed code evaluation for Build Missions Source freshness alerts when a past decision's evidence changes Shared/team decision records for bootcamps and engineering teams Portfolio-ready, source-backed skill evidence

## README (from the GitHub repository)

# GenPHD

### Decision intelligence for AI engineers

**GenPHD turns a scattered technical question into one evidence-backed next move — then remembers what the project learned.**

[Open the live product](https://genphd.onrender.com) · [See the product requirements](docs/01-product-requirements.md) · [Read the architecture](docs/03-system-design.md)

---

## Why GenPHD

AI engineers rarely lack advice. They lack a reliable way to decide **what to trust, what to build next, and what evidence to carry forward**.

GenPHD is not another chat window or a generic dashboard. It is a private workspace that connects:

1. **Project context** — outcome, stack, constraints, time, and blocker.
2. **Decision intelligence** — an evidence-aware brief with trade-offs, conflicts, and a bounded next action.
3. **Deliberate practice** — a roadmap, build mission, and coding challenge that turn advice into proof of capability.
4. **Learning memory** — a traceable record that improves the next decision instead of rewarding streaks.

> **One question → one trusted recommendation → one buildable mission → durable learning evidence.**

## Product loop

| Step | What the engineer does | What GenPHD delivers |
| --- | --- | --- |
| 1. Frame the work | Describe the project, stack, available time, and current blocker. | A private project context. |
| 2. Diagnose the gap | Take a short adaptive baseline across six GenAI competencies. | A skill-gap vector and prerequisite-aware roadmap. |
| 3. Ask a decision | Ask a real question such as *“Should I use pgvector or Pinecone for this RAG project?”* | A Decision Brief with evidence, trade-offs, conflicts, confidence, and a next move. |
| 4. Compare perspectives | Request consensus for higher-stakes choices. | Multi-model agreements, disagreements, and one reconciled next step. |
| 5. Build proof | Complete a focused mission or practical coding challenge. | Recorded completion and competency evidence. |
| 6. Continue with context | Return to the dashboard, roadmap, or memory. | A workspace that remembers what changed and why. |

## What makes it different

| Capability | GenPHD approach |
| --- | --- |
| Decision support | Structured briefs, not unbounded chatbot replies. Every recommendation exposes its evidence and trade-off. |
| Personalization | Roadmaps are shaped by project constraints and diagnostic gaps, not a fixed course sequence. |
| Multi-model consensus | Configured models are fanned out and reconciled into agreements, conflicts, and a trusted next step. |
| Skill evidence | Progress is tied to missions and practical work, not engagement metrics or streaks. |
| Memory | Project context, decisions, and evidence remain visible and scoped to the active workspace. |
| Safe fallback | AI flows degrade from multi-model → single model → deterministic guidance when a provider is unavailable. |

## Architecture

```mermaid
flowchart LR
    U[AI engineer] --> W[Next.js workspace]
    W --> A[Secure API layer]

    A --> P[Project context]
    A --> D[Decision engine]
    A --> G[Diagnostic + roadmap engine]
    A --> C[Coding challenge grader]

    D --> M[Consensus reconciler]
    M --> AI[OpenAI / OpenRouter / Groq]
    D --> AI
    C --> AI

    A --> S[(Supabase Postgres)]
    S --> R[RLS-scoped projects, decisions, missions, memory]

    U --> T[Cloudflare Turnstile]
    T --> A
    U --> AU[Supabase Auth]
    AU --> A
```

### Trust boundary

- **Supabase Auth** verifies sessions on the server; workspace routes are not available before authentication.
- **Row Level Security** scopes projects, decisions, roadmaps, missions, diagnostic runs, and memory to the signed-in user.
- **Cloudflare Turnstile** protects sign-up and sign-in; its secret stays in Supabase Auth, never in this repository.
- **Provider keys are server-only.** The browser never receives OpenAI, OpenRouter, or Groq credentials.
- **AI output is schema-validated** before being shown or persisted. Invalid provider responses fall back safely.

## GPT-5.6 integration

GenPHD uses a server-only, OpenAI-compatible provider boundary rather than calling a model from the browser.

- When `OPENAI_API_KEY` is configured, Decision Brief generation can use **GPT-5.6** through `OPENAI_MODEL` (the project default is `gpt-5.6-sol`).
- GPT-5.6 receives the project question and bounded project context, then returns a **strict JSON Decision Brief**: recommendation, summary, confidence reason, trade-off, counterfactual, sources, conflicts, and a next action.
- The response is parsed with Zod before it reaches the UI or database. A malformed or unavailable response falls through the configured provider order, then to deterministic guidance so the workspace remains usable.
- The dedicated consensus action fans a question out to multiple configured models, reconciles agreements and conflicts, and returns one trusted next step. It is user-triggered rather than silently run, so model cost stays explicit.
- The same server-side provider pattern supports content drafting and optional correctness-aware challenge grading. Provider keys never enter the client bundle.

Set `OPENAI_API_KEY` and optionally `OPENAI_MODEL` in `.env.local` or Render to enable GPT-5.6. See [`lib/decision/provider.ts`](lib/decision/provider.ts) for the typed fallback chain.

## Key product and engineering decisions

| Decision | Why it matters |
| --- | --- |
| Structured Decision Briefs instead of chat | Engineers need visible evidence, trade-offs, conflicts, and a next action—not a stream of untraceable answers. |
| One active project context | Keeps every recommendation grounded in current constraints and prevents a generic “AI advisor” experience. |
| Diagnostic-led roadmap | Skills are inferred from evidence and prerequisite gaps, rather than forcing every user through the same curriculum. |
| Explicit multi-model consensus | Higher-stakes questions can surface agreement and disagreement without charging for fan-out on every routine request. |
| Supabase RLS + server-verified sessions | Private project intelligence is user-scoped at the database and API layers. |
| Provider validation and deterministic fallback | The product continues to provide a coherent, safe response when a model or provider is unavailable. |
| Next.js monolith for the hackathon | Keeps deployment, auth, data access, and iteration fast without pretending microservices are necessary at this stage. |

## How Codex accelerated the build

Codex was used as an implementation partner throughout the project, while product and security choices remained deliberate human decisions.

- It translated the PRD, UI blueprint, and system design into the Next.js workspace structure, typed contracts, and API routes.
- It accelerated UI iteration across the landing experience, protected authentication flow, dashboard, navigation, and responsive states.
- It helped implement and verify typed provider fallbacks, multi-model consensus, diagnostic scoring, roadmap generation, coding challenge grading, and Supabase persistence boundaries.
- It supported production readiness work: resolving merge conflicts, keeping the Docker deployment compact, running TypeScript/tests/production builds, and checking authentication and security flows.
- Human review directed the core product identity: evidence over noise, project-scoped memory, explicit consent for model fan-out, and a calm non-dashboard-template interface.

## Judge test plan

The full product can be tested with your own project. No proprietary dataset is required.

### Sample project input

Use this during onboarding for a representative end-to-end evaluation:

| Field | Sample value |
| --- | --- |
| Project name | `DocuQuery` |
| Outcome | A source-grounded document assistant that makes retrieval quality visible. |
| Stack | `Python`, `FastAPI`, `pgvector` |
| Time available | `6 hours this week` |
| Current blocker | Deciding which evaluation work proves retrieval is reliable enough to ship. |

### Manual pr

[README truncated for size]

## Detected evidence (automated analysis)

Indexed codebase: 122 recognized source files, 563 KB.
- CSS (language) — detected in the code
- Next.js (technology) — detected in the code
- React (technology) — detected in the code
- SQL (language) — detected in the code
- Supabase (technology) — detected in the code
- TypeScript (language) — detected in the code
- OpenAI (technology) — claimed on Devpost, not found in the code
- PostgreSQL (technology) — claimed on Devpost, not found in the code
- Tailwind CSS (technology) — claimed on Devpost, not found in the code
- AI coding agent: Claude Code — evidence: config files committed to the repository

## Codebase structure (from repository index)

### Files (120 of 133)

```
.agents/README.md
.agents/registry.ts
.claude/settings.json
.dockerignore
.env.example
.github/workflows/ci.yml
.gitignore
app/about/page.tsx
app/api/auth/exit-demo/route.ts
app/api/challenges/grade/route.ts
app/api/challenges/route.ts
app/api/consensus/route.ts
app/api/content/route.ts
app/api/decisions/route.ts
app/api/diagnostic/route.ts
app/api/health/route.ts
app/api/memory/route.ts
app/api/missions/complete/route.ts
app/api/onboarding/route.ts
app/api/projects/active/route.ts
app/api/roadmap/route.ts
app/auth/callback/route.ts
app/challenges/[id]/page.tsx
app/challenges/page.tsx
app/consensus/[id]/page.tsx
app/consensus/page.tsx
app/contact/page.tsx
app/dashboard/page.tsx
app/demo/route.ts
app/diagnostic/page.tsx
app/feedback/page.tsx
app/globals.css
app/layout.tsx
app/legal/page.tsx
app/login/page.tsx
app/memory/page.tsx
app/not-found.tsx
app/notifications/page.tsx
app/onboarding/page.tsx
app/page.tsx
app/privacy/page.tsx
app/profile/page.tsx
app/projects/[id]/page.tsx
app/projects/page.tsx
app/roadmap/page.tsx
app/services/page.tsx
app/settings/page.tsx
app/signup/page.tsx
app/terms/page.tsx
app/timeline/page.tsx
CLAUDE.md
components/auth/sign-in-form.tsx
components/auth/sign-out-button.tsx
components/auth/turnstile.tsx
components/brand-logo.tsx
components/custom-cursor.tsx
components/genphd-app.tsx
components/landing-page.tsx
components/magnetic-element.tsx
components/marketing-pages.tsx
components/mouse-glow.tsx
components/onboarding-flow.tsx
components/secondary-pages.tsx
components/smooth-scroll.tsx
Dockerfile
docs/01-product-requirements.md
docs/02-design-system-ux-bible.md
docs/03-system-design.md
docs/04-engineering-specification.md
docs/05-hackathon-bible.md
docs/06-ui-blueprint.md
docs/07-codex-build-prompt.md
eslint.config.mjs
lib/ai/chat.ts
lib/api/route-error.ts
lib/auth/routes.ts
lib/challenges/bank.ts
lib/challenges/grader.ts
lib/challenges/types.ts
lib/competencies.ts
lib/consensus/provider.ts
lib/consensus/types.ts
lib/content/writer.ts
lib/decision/brief.ts
lib/decision/provider.ts
lib/decision/types.ts
lib/diagnostic/baseline.ts
lib/diagnostic/open-grader.ts
lib/diagnostic/questions.ts
lib/diagnostic/scoring.ts
lib/missions/complete.ts
lib/roadmap/generate.ts
lib/roadmap/personalize.ts
lib/roadmap/provider.ts
lib/runtime/public-config.client.ts
lib/supabase/browser.ts
lib/supabase/config.ts
lib/supabase/proxy.ts
lib/supabase/server.ts
lib/workspace/context.ts
lib/workspace/contracts.ts
lib/workspace/onboarding.ts
lib/workspace/repository.ts
LICENSE
next-env.d.ts
next.config.ts
package.json
proxy.ts
README.md
render.yaml
scratch_marketing.css
supabase/.gitignore
supabase/config.toml
supabase/migrations/0001_genphd_core.sql
supabase/migrations/0002_decision_brief_persistence.sql
supabase/migrations/0003_diagnostic_and_roadmap_dag.sql
supabase/migrations/0004_multi_model_consensus.sql
supabase/migrations/0005_coding_challenges.sql
supabase/migrations/0006_diagnostic_runs.sql
supabase/seed.sql
[13 more files omitted for size]
```

### Dependencies

- package.json: @emnapi/core@^1.11.2, @emnapi/runtime@^1.11.2, @studio-freight/react-lenis@^0.0.47, @supabase/ssr@^0.12.3, @supabase/supabase-js@^2.110.7, @types/node@latest, @types/react@latest, @types/react-dom@latest, eslint@latest, eslint-config-next@latest, framer-motion@^12.42.2, lucide-react@latest, next@latest, react@latest, react-dom@latest, typescript@latest, vitest@^4.1.10, zod@^4.4.3

### Recent commits (newest first)

- feat(auth): add guest demo path to bypass onboarding friction safely
- Fix build import path for LandingPage and enhance resilience
- fix(marketing): resolve eslint errors and warnings in marketing-pages
- feat(marketing): add video backgrounds, mascot element, and visual assets
- feat(missions): embed interactive hands-on coding challenge into build mission view
- fix(dashboard): remove top margin space above header topbar and sidebar
- fix(auth): remove mandatory diagnostic step so onboarding routes straight to dashboard
- fix(auth): open dashboard directly on login and signup without onboarding redirection
- fix(auth): require onboarding for uninitialized accounts and clear browser cache on sign-out
- fix(render): resolve git merge conflict markers and build errors
- fix(app): remove coding challenge section and update build mission navigation
- docs: add hackathon evaluation guidance
- docs: redesign judge-facing project readme
- feat: align signup with secure auth experience
- feat: redesign secure login experience
- fix: separate workspace header from sidebar
- fix: resolve committed merge conflicts
- feat: add GenPHD brand logo
- feat: personalize roadmap from diagnostic
- feat: add explicit multi-model consensus

## Key source files (fetched from GitHub, selected and truncated for size)

### CLAUDE.md

```markdown
# GenPHD — Build Status & Feature Tracker

> Living document. Updated as features land. "Vision" = the product brief:
> an AI learning companion (diagnostic → roadmap → challenges → streak/review),
> reframed around **multi-model consensus** ("ChatGPT, Claude, and Gemini disagree —
> we show where they agree/conflict and give one trusted next step, and remember it").

## Legend
✅ Done & verified · 🟡 Partial / in progress · ⬜ Not started

---

## Pillar status

### ✅ 1. Diagnostic assessment → skill-gap vector
Adaptive placement test across the 6 GenAI competencies (prompting, embeddings, vector DBs,
retrieval, agent frameworks, evals), producing a quantified skill-gap vector.
- Question bank (server-side keys): `lib/diagnostic/questions.ts`
- Deterministic ceiling scoring + LLM open-response grading: `lib/diagnostic/scoring.ts`, `lib/diagnostic/open-grader.ts`
- API: `GET/POST /api/diagnostic` (`app/api/diagnostic/route.ts`)
- UI: adaptive quiz + gap-vector summary (`components/onboarding-flow.tsx` → `DiagnosticFlow`)
- Persistence: `diagnostic_runs` + per-competency `skill_evidence` (`lib/workspace/repository.ts`, migration `0003`)

### ✅ 2. Personalized roadmap DAG
Gap-driven DAG of milestones in prerequisite order, ending at a shippable capstone artifact.
- Deterministic generator + DAG state logic: `lib/roadmap/generate.ts`
- LLM generation with validation + fallback: `lib/roadmap/provider.ts`
- Rendered with locked/now/next/later + capstone: `components/genphd-app.tsx` → `Roadmap`
- Persistence: roadmap columns on `build_missions` (`depends_on`, `sort_order`, `kind`), migration `0003`

### ✅ 3. Multi-model consensus (the differentiator)
Ask once, fan out to 3 models, show agreement/conflict, give one trusted next step, remember it.
- [x] `lib/consensus/types.ts` — ConsensusReport schema
- [x] `lib/consensus/provider.ts` — parallel fan-out to named models + analysis pass + graceful degrade (multi-model → single-model → deterministic)
- [x] `lib/ai/chat.ts` — `runOpenRouterModel` per-named-model helper (fan-out via OpenRouter)
- [x] `POST /api/consensus` + persistence (`consensus jsonb` on `decisions`, migration `0004`)
- [x] Consensus view: model panels + agreements + conflicts + one trusted next step (`components/genphd-app.tsx` → `Consensus`)
- [x] Remembered across sessions (persisted in `decisions.consensus`; surfaced via `GET /api/decisions`) and within-session via `genphd-consensus` sessionStorage
- Models configurable via `GENPHD_CONSENSUS_MODELS` (default GPT/Claude/Gemini); requires `OPENROUTER_API_KEY` for the live multi-model path, otherwise deterministic single-panel fallback.

### ⬜ 4. Streak + adaptive review
Daily streak, streak freezes, spaced repetition on missed concepts, "knowledge is N weeks stale" flag.
- [ ] Schema: `streaks`, `review_items` (spaced-repetition schedule), staleness metadata on `skill_evidence`
- [ ] Streak logic (increment, freeze, break) + daily nudge surface
- [ ] Spaced-repetition scheduler seeded fro
[truncated — 2207 more characters]
```

### docs/07-codex-build-prompt.md

```markdown
# GenPHD Build Prompt for Codex

Copy this prompt into a fresh implementation task before building the product.

---

You are implementing **GenPHD**, the decision intelligence layer for AI engineers.

Before changing code, read these documents completely and treat them as the source of truth, in this order:

1. `docs/01-product-requirements.md`
2. `docs/02-design-system-ux-bible.md`
3. `docs/03-system-design.md`
4. `docs/04-engineering-specification.md`
5. `docs/05-hackathon-bible.md`
6. `docs/06-ui-blueprint.md`

## Product objective

Build the smallest compelling Decision Loop:

```text
Onboarding -> Decision Brief -> Build Mission -> Reflection -> Updated roadmap
```

GenPHD is not an AI tutor, generic chatbot, analytics dashboard, or multi-agent theatre. The product helps an AI builder make an evidence-backed technical decision, take the next action, and learn from the outcome.

## Non-negotiable product rules

- Every substantial recommendation must show evidence, uncertainty, and one clear next action.
- Model agreement is not truth. Evidence quality, recency, user constraints, and conflict analysis determine confidence.
- Memory is visible, user-controlled, scoped, and never silently profiles the user.
- Source freshness is a background concern; do not build a freshness dashboard.
- Use the modular-monolith MVP architecture unless an approved requirement justifies a service split.
- Do not add features outside the documents without first flagging the conflict and asking for direction.

## Non-negotiable design rules

- Implement the UI Blueprint exactly. Never invent an extra screen, dashboard widget, chart, card, badge, gradient, or navigation item.
- Use the monochrome Design Bible tokens. No blue or purple gradients, neon, glassmorphism, gamification, or SaaS-template layouts.
- Every page answers one question and has one clear primary action.
- Use whitespace and hierarchy before cards. Do not wrap every section in a card.
- Build loading, empty, error, success, keyboard, focus, and responsive states along with each surface.
- Do not expose an agent-control dashboard. Show simple user-readable workflow status only.

## Engineering rules

- Use Next.js, TypeScript strict mode, Tailwind, shadcn/ui primitives, Supabase, Zod, and typed server-side AI calls as defined in the Engineering Specification.
- Keep secrets and provider calls server-side.
- Use Row Level Security and authorization checks for all user data.
- Use structured AI output validated by Zod; never render unvalidated model JSON.
- Use server components by default and avoid global state libraries unless justified.
- Implement routes, schemas, database migrations, tests, and error handling alongside features.
- Use FastAPI or LangGraph only when the specified implementation phase requires it.

## Build sequence

1. Create the app shell, typography, color tokens, navigation, and responsive foundation.
2. Implement authentication and the onboarding flow.
3. Implement the proje
[truncated — 839 more characters]
```

### package.json

```
{
  "name": "genphd",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "start:standalone": "node .next/standalone/server.js",
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run"
  },
  "dependencies": {
    "@studio-freight/react-lenis": "^0.0.47",
    "@supabase/ssr": "^0.12.3",
    "@supabase/supabase-js": "^2.110.7",
    "framer-motion": "^12.42.2",
    "lucide-react": "latest",
    "next": "latest",
    "react": "latest",
    "react-dom": "latest",
    "zod": "^4.4.3"
  },
  "devDependencies": {
    "@emnapi/core": "^1.11.2",
    "@emnapi/runtime": "^1.11.2",
    "@types/node": "latest",
    "@types/react": "latest",
    "@types/react-dom": "latest",
    "eslint": "latest",
    "eslint-config-next": "latest",
    "typescript": "latest",
    "vitest": "^4.1.10"
  }
}

```

### Dockerfile

```
FROM node:22-alpine AS base

RUN apk add --no-cache libc6-compat
WORKDIR /app
ENV NEXT_TELEMETRY_DISABLED=1

FROM base AS dependencies

COPY package.json package-lock.json ./
RUN npm ci

FROM base AS builder

ARG NEXT_PUBLIC_SUPABASE_URL
ARG NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY
ARG NEXT_PUBLIC_TURNSTILE_SITE_KEY
ARG NEXT_PUBLIC_SITE_URL

ENV NEXT_PUBLIC_SUPABASE_URL=$NEXT_PUBLIC_SUPABASE_URL
ENV NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=$NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY
ENV NEXT_PUBLIC_TURNSTILE_SITE_KEY=$NEXT_PUBLIC_TURNSTILE_SITE_KEY
ENV NEXT_PUBLIC_SITE_URL=$NEXT_PUBLIC_SITE_URL

COPY --from=dependencies /app/node_modules ./node_modules
COPY . .

RUN npm run build

FROM node:22-alpine AS runner

RUN apk add --no-cache libc6-compat \
  && addgroup --system --gid 1001 nodejs \
  && adduser --system --uid 1001 nextjs

WORKDIR /app
ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1
ENV HOSTNAME=0.0.0.0
ENV PORT=10000

COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 10000

CMD ["node", "server.js"]

```

### app/page.tsx

```typescript
import { MarketingLandingPage } from "../components/marketing-pages";

export default function Home() {
  return <MarketingLandingPage />;
}


```

### app/layout.tsx

```typescript
import type { Metadata } from "next";
import { getPublicRuntimeConfig } from "../lib/supabase/config";
import "./globals.css";

// Render public configuration at request time. Render supplies these values at
// container runtime, rather than while the Docker image is built.
export const dynamic = "force-dynamic";

export const metadata: Metadata = {
  title: "GenPHD — Decision intelligence for AI engineers",
  description: "Turn conflicting AI advice into an evidence-backed next build action.",
};

export default function RootLayout({ children }: Readonly<{ children: React.ReactNode }>) {
  const publicConfig = getPublicRuntimeConfig();

  return (
    <html lang="en">
      <body
        data-genphd-supabase-publishable-key={publicConfig.supabasePublishableKey}
        data-genphd-supabase-url={publicConfig.supabaseUrl}
        data-genphd-turnstile-site-key={publicConfig.turnstileSiteKey}
      >
        {children}
      </body>
    </html>
  );
}

```

### app/about/page.tsx

```typescript
import { AboutPage } from "../../components/marketing-pages";

export default function AboutRoute() {
  return <AboutPage />;
}

```

### app/terms/page.tsx

```typescript
import { TermsPage } from "../../components/secondary-pages";

export default function TermsRoute() {
  return <TermsPage />;
}

```

### app/privacy/page.tsx

```typescript
import { PrivacyPage } from "../../components/secondary-pages";

export default function PrivacyRoute() {
  return <PrivacyPage />;
}

```

### app/profile/page.tsx

```typescript
import { ProfilePage } from "../../components/secondary-pages";

export default function ProfileRoute() {
  return <ProfilePage />;
}

```

[110 more indexed source files omitted to keep this export small. The full file list is in the Codebase structure section above.]