diff --git a/docs/index.md b/docs/index.md
index 3c2f131..67eedd5 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,142 +1,142 @@
+# Gthulhu
+
+
+
+## Keep critical workloads fast when CPUs get busy
+
+Gthulhu is a cloud-native runtime scheduling platform built with eBPF and Linux `sched_ext`. It protects latency- and throughput-sensitive Linux tasks inside Kubernetes workloads when CPU contention would otherwise slow them down.
+
+
+
+
+
+
+free5GC / 5G user plane
+
+### 97.66% lower average latency
+
+**88.98 ms → 2.079 ms** average UE ping latency under CPU stress.
+
+Maximum latency also fell from **130.95 ms → 8.45 ms**.
+
+[Read the published free5GC case study →](https://free5gc.org/blog/20251126/20251126/)
+
+
+
+vLLM / GPU inference
+
+### ~3.2× decode throughput
+
+**~6.7 t/s → ~21.3 t/s** on `tg128` under CPU pressure with Gthulhu + tiered scheduling policy.
+
+*Reproducible community benchmark currently under upstream vLLM blog review.*
+
+[Review the benchmark and methodology →](https://github.com/vllm-project/vllm-project.github.io/pull/300)
+
+
+
-| Workload | Baseline | With Gthulhu | Result |
-|---|---:|---:|---:|
-| free5GC / GTP data path — average UE ping latency | **88.98 ms** | **2.079 ms** | **97.66% lower** |
-| free5GC / GTP data path — maximum UE ping latency | **130.95 ms** | **8.45 ms** | **93.55% lower** |
-| vLLM Qwen2.5-0.5B decode (`tg128`) under CPU pressure | **~6.7 t/s** | **~21.3 t/s** with tiered policy | **~3.2× throughput** |
+**1. Observe**
+Use eBPF to see which tasks are waiting, running, migrating, and competing for CPU.
-The free5GC numbers are published in the free5GC community blog. The vLLM result comes from a reproducible community benchmark currently proposed to the vLLM project blog; treat it as an experiment under upstream review rather than a project-wide guarantee.
+**2. Target**
+Resolve Kubernetes workload intent down to the Linux process or thread that actually matters.
-[Read the free5GC case study](https://free5gc.org/blog/20251126/20251126/){: .md-button .md-button--primary }
-[vLLM benchmark PR](https://github.com/vllm-project/vllm-project.github.io/pull/300){: .md-button }
-[Get Started](k8s.md){: .md-button }
+**3. Control**
+Use `sched_ext` to apply bounded runtime scheduling policy and protect critical execution paths.
-> **DRA chooses what and where; Gthulhu controls how it actually runs.**
+
-## Why this matters
+> **DRA chooses what and where. Gthulhu controls how it actually runs.**
-A workload can already own a GPU, NIC, CPU set, or Kubernetes placement and still miss its latency or throughput target because its host-side Linux tasks are delayed by CPU contention.
+## Built for workload-aware runtime scheduling
-Gthulhu focuses on that execution gap:
+
-```text
-Kubernetes admission / placement / allocation
- │
- ▼
- Gthulhu runtime plane
- │
- Pod / cgroup / TGID / TID resolution
- │
- ▼
- sched_ext + eBPF
- │
- ▼
- latency / throughput / jitter / SLO
-```
+- :material-eye-outline:{ .lg .middle } **Scheduling observability**
-## Proven use cases
+ ---
-### 5G user-plane latency
+ Pod-level scheduling metrics with eBPF, plus Prometheus and Grafana integration.
-The free5GC community published a GTP-driven scheduling experiment that combines `gtp5g-tracer`, a userspace operator, and Gthulhu. Under the same CPU stress, average UE ping latency dropped from **88.98 ms to 2.079 ms**, while maximum latency dropped from **130.95 ms to 8.45 ms**.
+- :material-tune-variant:{ .lg .middle } **Fine-grained control**
-[Read: Implementing GTP-driven Automatic Scheduling Optimization with eBPF-based Scheduler](https://free5gc.org/blog/20251126/20251126/)
+ ---
-A separate earlier free5GC case study also documents using Gthulhu to reduce RTT by combining application/domain knowledge with custom `sched_ext` policy.
+ Apply scheduling intent to specific workloads, processes, or non-leader worker threads with TID-aware matching.
-[Read: Improving Network Performance with Custom eBPF-based Schedulers](https://free5gc.org/blog/20250726/index.en/)
+- :material-server-network:{ .lg .middle } **Cloud-native operation**
-### vLLM inference under CPU pressure
+ ---
-A reproducible DGX Spark / GB10 experiment uses MicroK8s, vLLM, `stress-ng`, and Gthulhu to isolate the effect of CPU scheduling on GPU inference. In the submitted benchmark, decode throughput under CPU pressure is around **6–7 t/s** with the default scheduler and reaches roughly **21 t/s** on `tg128` with Gthulhu plus tiered policies targeting GPU-related work and vLLM's `EngineCore` thread.
+ Manager + per-node Decision Makers distribute scheduling intent across Kubernetes nodes.
-This result is linked here as an **upstream-reviewing community benchmark**, not as a generalized performance guarantee.
+- :material-chart-line:{ .lg .middle } **SLO-oriented automation**
-[Review the benchmark and methodology in vLLM blog PR #300](https://github.com/vllm-project/vllm-project.github.io/pull/300)
+ ---
-## What Gthulhu provides today
+ Feed scheduler signals into Prometheus, Grafana, and KEDA to support runtime-aware operations and scaling.
-- **Pod-level scheduling observability** with eBPF.
-- **Prometheus / Grafana / KEDA integration** for scheduler-aware operations and scaling.
-- **Distributed scheduling intent** through a Manager and per-node Decision Makers.
-- **Custom CPU scheduling** on Linux 6.12+ with `sched_ext`.
-- **TID-aware node-policy matching** so non-leader worker threads can be targeted directly.
-- **Explicit priority semantics** across user-space and kernel scheduler modes.
+
-[How It Works](how-it-works.md){: .md-button }
-[Claim2Core Roadmap](claim2core.md){: .md-button }
+[See how Gthulhu works](how-it-works.md){: .md-button }
-## Claim2Core: from allocation to delivered performance
+## Where Gthulhu is going: Claim2Core
-The next architecture step is to connect actual Kubernetes allocation to runtime task scheduling:
+Today, Gthulhu can observe and control Linux task scheduling at runtime. The next step is to connect that control directly to Kubernetes' **actual resource allocation**.
```text
Kueue / Workload API
- │ admission / quota
- ▼
+ ↓
kube-scheduler / DRA
- │ Node + device + topology allocation
- ▼
+ ↓ ResourceClaim + topology
Gthulhu Runtime Plane
- │ ResourceClaim → Pod/cgroup → TGID/TID
- ▼
+ ↓ Pod / cgroup / TGID / TID
sched_ext + eBPF
- │ runtime policy + verification
- ▼
+ ↓
Delivered workload SLO
```
-The critical correctness rule is:
+The principle is simple:
-- `ResourceSlice` is **inventory**.
-- `ResourceClaim.status.allocation` is the workload's **actual allocation**.
+- `ResourceSlice` tells us what resources exist.
+- `ResourceClaim.status.allocation` tells us what the workload actually received.
+- Gthulhu turns that allocation into a verifiable runtime execution policy **without crossing the CPU/resource boundaries Kubernetes already established**.
-Gthulhu should not reimplement kube-scheduler, DRA, or Kueue. It should consume their decisions and control Linux CPU execution **inside** the resource envelope established by Kubernetes/cgroups.
+[Explore the Claim2Core roadmap](claim2core.md){: .md-button }
+[Follow roadmap issue #141](https://github.com/Gthulhu/Gthulhu/issues/141){: .md-button }
-Read [Claim2Core](claim2core.md) for the implementation phases and safety boundaries.
+## Start with a real workload
-## Architecture at a glance
+
-```text
-User / Web UI / CRD
- │
- ▼
-Manager API ───────▶ MongoDB / Kubernetes API
- │
- ▼
-Decision Maker DaemonSet
- │
- ├── eBPF scheduling metrics collector ──▶ Prometheus / Grafana / KEDA
- │
- └── task resolution / scheduling intent
- │
- ▼
- Gthulhu daemon
- │
- ▼
- sched_ext / BPF
- │
- ▼
- Linux scheduler
-```
+### See what CPU scheduling is doing to your workload
+
+Deploy Gthulhu on Kubernetes, inspect scheduler behavior, then apply policy only where the data shows it matters.
-## Get involved
+[Deploy Gthulhu](k8s.md){: .md-button .md-button--primary }
+[Read the free5GC case study](https://free5gc.org/blog/20251126/20251126/){: .md-button }
+[Contribute](contributing.md){: .md-button }
-- [Deploy Gthulhu with Kubernetes](k8s.md)
-- [Understand the architecture and scheduler semantics](how-it-works.md)
-- [Read the Claim2Core roadmap](claim2core.md)
-- [Contribute](contributing.md)
-- [GitHub repository](https://github.com/Gthulhu/Gthulhu)
-- [Roadmap issue #141](https://github.com/Gthulhu/Gthulhu/issues/141)
+
diff --git a/docs/index.zh.md b/docs/index.zh.md
index 3562a05..3d7c0f0 100644
--- a/docs/index.zh.md
+++ b/docs/index.zh.md
@@ -1,142 +1,142 @@
+# Gthulhu
+
+
+
+## CPU 忙起來時，讓關鍵工作負載仍然跑得快
+
+Gthulhu 是一個以 eBPF 與 Linux `sched_ext` 建構的 cloud-native runtime scheduling 平台。當 CPU contention 開始拖慢 Kubernetes workload 時，Gthulhu 會保護真正影響 latency 與 throughput 的 Linux tasks。
+
+
+
+
+
+
+free5GC / 5G User Plane
+
+### 平均 latency 降低 97.66%
+
+CPU stress 下，UE 平均 ping latency **88.98 ms → 2.079 ms**。
+
+最大 latency 也從 **130.95 ms → 8.45 ms**。
+
+[閱讀 free5GC 已發表 Case Study →](https://free5gc.org/blog/20251126/20251126/)
+
+
+
+vLLM / GPU Inference
+
+### Decode throughput 約提升 3.2×
+
+CPU pressure 下，`tg128` 從 **~6.7 t/s → ~21.3 t/s**，使用 Gthulhu + tiered scheduling policy。
+
+*此為可重現的 community benchmark，目前仍在 vLLM upstream blog review 中。*
+
+[查看 benchmark 與實驗方法 →](https://github.com/vllm-project/vllm-project.github.io/pull/300)
+
+
+
-| Workload | Baseline | 使用 Gthulhu | 結果 |
-|---|---:|---:|---:|
-| free5GC / GTP data path — UE 平均 ping latency | **88.98 ms** | **2.079 ms** | **降低 97.66%** |
-| free5GC / GTP data path — UE 最大 ping latency | **130.95 ms** | **8.45 ms** | **降低 93.55%** |
-| vLLM Qwen2.5-0.5B decode (`tg128`) under CPU pressure | **~6.7 t/s** | **~21.3 t/s**（tiered policy） | **約 3.2× throughput** |
+**1. Observe — 看見問題**
+用 eBPF 看清楚哪些 tasks 在等待、執行、migration，以及誰正在競爭 CPU。
-free5GC 數據已發表於 free5GC 社群部落格。vLLM 數據來自可重現的 community benchmark，目前正在 vLLM 官方 blog PR 審核中，因此應視為 upstream-reviewing experiment，而不是適用所有環境的效能保證。
+**2. Target — 找到真正重要的 task**
+把 Kubernetes workload intent 解析到實際影響服務的 Linux process / thread。
-[閱讀 free5GC Case Study](https://free5gc.org/blog/20251126/20251126/){: .md-button .md-button--primary }
-[vLLM Benchmark PR](https://github.com/vllm-project/vllm-project.github.io/pull/300){: .md-button }
-[開始使用](k8s.md){: .md-button }
+**3. Control — 精準控制**
+利用 `sched_ext` 套用有邊界的 runtime scheduling policy，保護關鍵 execution path。
-> **DRA chooses what and where; Gthulhu controls how it actually runs.**
+
-## 為什麼這件事重要
+> **DRA chooses what and where. Gthulhu controls how it actually runs.**
-Workload 即使已經取得 GPU、NIC、CPU set 或 Kubernetes placement，也可能因 host-side Linux tasks 在 CPU contention 下被延遲，而無法達成 latency / throughput SLO。
+## 為 workload-aware runtime scheduling 而設計
-Gthulhu 專注於這個 execution gap：
+
-```text
-Kubernetes admission / placement / allocation
- │
- ▼
- Gthulhu runtime plane
- │
- Pod / cgroup / TGID / TID resolution
- │
- ▼
- sched_ext + eBPF
- │
- ▼
- latency / throughput / jitter / SLO
-```
+- :material-eye-outline:{ .lg .middle } **Scheduling Observability**
-## 已驗證的使用案例
+ ---
-### 5G User Plane latency
+ 使用 eBPF 提供 Pod-level scheduling metrics，並整合 Prometheus 與 Grafana。
-free5GC 社群已發表 GTP-driven scheduling 實驗，將 `gtp5g-tracer`、userspace operator 與 Gthulhu 串起來。在相同 CPU stress 下，UE 平均 ping latency 從 **88.98 ms 降到 2.079 ms**，最大 latency 從 **130.95 ms 降到 8.45 ms**。
+- :material-tune-variant:{ .lg .middle } **Fine-grained Control**
-[閱讀：Implementing GTP-driven Automatic Scheduling Optimization with eBPF-based Scheduler](https://free5gc.org/blog/20251126/20251126/)
+ ---
-另一篇較早的 free5GC case study 也展示如何利用 network-domain knowledge 搭配 Gthulhu 的 `sched_ext` policy 降低 RTT。
+ 對特定 workload、process，甚至非 leader worker thread 套用 scheduling intent；支援 TID-aware matching。
-[閱讀：利用 Custom eBPF-based Schedulers 改善網路效能](https://free5gc.org/blog/20250726/)
+- :material-server-network:{ .lg .middle } **Cloud-native Operation**
-### vLLM 在 CPU pressure 下的 inference
+ ---
-另一個可重現實驗使用 DGX Spark / GB10、MicroK8s、vLLM、`stress-ng` 與 Gthulhu，刻意隔離 CPU scheduling 對 GPU inference 的影響。在目前提交給 vLLM blog 的 benchmark 中，default scheduler 在 CPU pressure 下 decode throughput 約為 **6–7 t/s**；使用 Gthulhu 並對 GPU-related work 與 vLLM `EngineCore` 套用 tiered policy 後，`tg128` 約可達 **21 t/s**。
+ 透過 Manager 與每節點 Decision Maker，把 scheduling intent 分散到 Kubernetes nodes。
-這裡將它標示為 **upstream 審核中的 community benchmark**，而不是廣泛化的 performance guarantee。
+- :material-chart-line:{ .lg .middle } **SLO-oriented Automation**
-[查看 vLLM blog PR #300 的 benchmark 與方法](https://github.com/vllm-project/vllm-project.github.io/pull/300)
+ ---
-## Gthulhu 目前已具備的能力
+ 將 scheduler signals 接到 Prometheus、Grafana 與 KEDA，支援 runtime-aware operations 與 scaling。
-- **Pod 層級 scheduling observability**：使用 eBPF 收集 scheduler signals。
-- **Prometheus / Grafana / KEDA 整合**：支援 scheduler-aware operations 與 scaling。
-- **分散式 scheduling intent**：Manager 搭配每節點 Decision Maker。
-- **自訂 CPU scheduling**：Linux 6.12+ 可使用 `sched_ext`。
-- **TID-aware node policy matching**：可以直接命中非 leader worker thread。
-- **明確的 priority semantics**：user-space 與 kernel mode 都有清楚的 boosting 行為。
+
-[了解運作原理](how-it-works.md){: .md-button }
-[Claim2Core Roadmap](claim2core.md){: .md-button }
+[了解 Gthulhu 如何運作](how-it-works.md){: .md-button }
-## Claim2Core：從 allocation 到 delivered performance
+## 下一步：Claim2Core
-下一個架構階段，是把 Kubernetes 的實際 allocation 接到 runtime task scheduling：
+目前 Gthulhu 已能在 runtime 觀測與控制 Linux task scheduling。下一步，是把這個能力直接接到 Kubernetes **實際分配的資源**。
```text
Kueue / Workload API
- │ admission / quota
- ▼
+ ↓
kube-scheduler / DRA
- │ Node + device + topology allocation
- ▼
+ ↓ ResourceClaim + topology
Gthulhu Runtime Plane
- │ ResourceClaim → Pod/cgroup → TGID/TID
- ▼
+ ↓ Pod / cgroup / TGID / TID
sched_ext + eBPF
- │ runtime policy + verification
- ▼
+ ↓
Delivered workload SLO
```
-最重要的 correctness 原則是：
+核心原則很簡單：
-- `ResourceSlice` 是 **inventory**。
-- `ResourceClaim.status.allocation` 才是 workload 的 **actual allocation**。
+- `ResourceSlice` 告訴我們有哪些資源。
+- `ResourceClaim.status.allocation` 告訴我們 workload 實際拿到了什麼。
+- Gthulhu 把 allocation 轉成可驗證的 runtime execution policy，並且**不突破 Kubernetes 已建立的 CPU / resource boundary**。
-Gthulhu 不重新實作 kube-scheduler、DRA 或 Kueue，而是在 Kubernetes/cgroup 建立的 resource envelope 內，控制 workload 真正取得 CPU service 的方式。
+[查看 Claim2Core Roadmap](claim2core.md){: .md-button }
+[追蹤 Roadmap Issue #141](https://github.com/Gthulhu/Gthulhu/issues/141){: .md-button }
-完整 implementation phases 與安全邊界請看 [Claim2Core](claim2core.md)。
+## 從真實 workload 開始
-## 架構一覽
+
-```text
-User / Web UI / CRD
- │
- ▼
-Manager API ───────▶ MongoDB / Kubernetes API
- │
- ▼
-Decision Maker DaemonSet
- │
- ├── eBPF scheduling metrics collector ──▶ Prometheus / Grafana / KEDA
- │
- └── task resolution / scheduling intent
- │
- ▼
- Gthulhu daemon
- │
- ▼
- sched_ext / BPF
- │
- ▼
- Linux scheduler
-```
+### 先看 CPU scheduling 到底怎麼影響你的服務
+
+在 Kubernetes 部署 Gthulhu、觀察 scheduler behavior，再只對數據證明有影響的 execution path 套用 policy。
-## 參與 Gthulhu
+[部署 Gthulhu](k8s.md){: .md-button .md-button--primary }
+[閱讀 free5GC Case Study](https://free5gc.org/blog/20251126/20251126/){: .md-button }
+[參與貢獻](contributing.md){: .md-button }
-- [在 Kubernetes 部署 Gthulhu](k8s.md)
-- [理解系統架構與 scheduler semantics](how-it-works.md)
-- [閱讀 Claim2Core roadmap](claim2core.md)
-- [參與貢獻](contributing.md)
-- [GitHub repository](https://github.com/Gthulhu/Gthulhu)
-- [Roadmap issue #141](https://github.com/Gthulhu/Gthulhu/issues/141)
+
diff --git a/docs/stylesheets/extra.css b/docs/stylesheets/extra.css
index 1305686..668e16b 100644
--- a/docs/stylesheets/extra.css
+++ b/docs/stylesheets/extra.css
@@ -5,12 +5,11 @@
:root {
--md-typeset-a-color: #2563EB !important;
--md-primary-fg-color: #3B82F6;
- --md-primary-fg-color--light: #60A5FA; /* 偏亮的主色，用於 hover 等狀態 */
- --md-primary-fg-color--dark: #2563EB; /* 偏暗的主色，用於陰影或深色邊界 */
- --md-accent-fg-color: #3B82F6; /* 強調色一併設為相同色調（可依需求調整） */
+ --md-primary-fg-color--light: #60A5FA;
+ --md-primary-fg-color--dark: #2563EB;
+ --md-accent-fg-color: #3B82F6;
}
-/* 深色模式也同步主題色，避免切換配色時恢復預設藍色 */
[data-md-color-scheme="slate"] {
--md-typeset-a-color: #60A5FA !important;
--md-primary-fg-color: #3B82F6;
@@ -19,7 +18,6 @@
--md-accent-fg-color: #60A5FA;
}
-/* 全站基礎字體設定 */
body,
.md-typeset {
font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif !important;
@@ -27,14 +25,12 @@ body,
line-height: 1.7 !important;
}
-/* 內文段落 */
.md-typeset p {
font-family: 'Inter', sans-serif !important;
font-size: 0.95rem !important;
line-height: 1.7 !important;
}
-/* 標題字體 - 使用 Orbitron 保持科技感 */
.md-typeset h1 {
font-family: 'Orbitron', sans-serif !important;
font-weight: 700 !important;
@@ -56,7 +52,6 @@ body,
letter-spacing: 0.3px !important;
}
-/* 程式碼區塊使用等寬字體 */
.md-typeset code,
.md-typeset pre,
.md-typeset kbd,
@@ -64,79 +59,55 @@ body,
font-family: 'JetBrains Mono', 'Consolas', monospace !important;
}
-/* 行內程式碼 */
.md-typeset code {
font-size: 0.85em !important;
padding: 0.1em 0.4em !important;
}
-/* 列表文字 */
.md-typeset ul,
.md-typeset ol,
-.md-typeset li {
+.md-typeset li,
+.md-typeset blockquote,
+.md-typeset table,
+.md-typeset .admonition {
font-family: 'Inter', sans-serif !important;
}
-/* 引用區塊 */
.md-typeset blockquote {
- font-family: 'Inter', sans-serif !important;
font-style: italic !important;
}
-/* 表格 */
.md-typeset table {
- font-family: 'Inter', sans-serif !important;
font-size: 0.9rem !important;
}
-/* Admonition (提示框) */
.md-typeset .admonition-title,
.md-typeset summary {
font-family: 'Orbitron', sans-serif !important;
font-weight: 600 !important;
}
-.md-typeset .admonition {
- font-family: 'Inter', sans-serif !important;
-}
-
-/* 調整 logo 大小 */
.md-header__button.md-logo img,
-.md-header__button.md-logo svg {
- height: 3rem !important;
- width: auto !important;
-}
-
+.md-header__button.md-logo svg,
.md-logo img,
.md-logo svg {
height: 3rem !important;
width: auto !important;
}
-/* 導航列背景色 */
-.md-header {
- background-color: #1E293B !important;
-}
-
-.md-tabs {
- background-color: #1E293B !important;
-}
-
-.md-nav__source {
+.md-header,
+.md-tabs,
+.md-nav__source,
+.md-nav--primary .md-nav__title {
background-color: #1E293B !important;
}
-.md-nav__item .md-nav__link--active, .md-nav__item .md-nav__link--active code,
-.md-nav__item--active>.md-nav__link {
+.md-nav__item .md-nav__link--active,
+.md-nav__item .md-nav__link--active code,
+.md-nav__item--active > .md-nav__link {
color: #3B82F6 !important;
}
-/* 主要導覽（側邊/抽屜）背景，確保與主題色一致 */
-.md-nav--primary .md-nav__title {
- background-color: #1E293B !important;
-}
-
-/* 導航列字體 - 使用 Orbitron 科技感字體 */
.md-header__title,
.md-header__topic {
font-family: 'Orbitron', 'JetBrains Mono', monospace !important;
@@ -150,14 +121,131 @@ body,
letter-spacing: 0.3px !important;
}
-/* 導航選單項目 */
.md-nav__link {
font-family: 'Inter', sans-serif !important;
font-weight: 500 !important;
}
-/* 側邊欄標題 */
.md-nav__title {
font-family: 'Orbitron', sans-serif !important;
font-weight: 600 !important;
}
+
+/* Homepage marketing layout */
+.gth-hero {
+ margin: 0.5rem 0 1.5rem;
+ padding: 2.2rem 2.4rem;
+ border: 1px solid rgba(59, 130, 246, 0.22);
+ border-radius: 1rem;
+ background: linear-gradient(135deg, rgba(59, 130, 246, 0.12), rgba(15, 23, 42, 0.02));
+}
+
+.gth-hero h2 {
+ margin-top: 0;
+ margin-bottom: 0.7rem;
+ font-size: clamp(1.75rem, 4vw, 2.65rem);
+ line-height: 1.18;
+ max-width: 18ch;
+}
+
+.gth-hero p {
+ max-width: 760px;
+ font-size: 1.05rem !important;
+}
+
+.gth-hero-actions {
+ display: flex;
+ flex-wrap: wrap;
+ gap: 0.65rem;
+ margin-top: 1.15rem;
+}
+
+.gth-proof-grid {
+ display: grid;
+ grid-template-columns: repeat(2, minmax(0, 1fr));
+ gap: 1rem;
+ margin: 1.5rem 0 1rem;
+}
+
+.gth-proof-card {
+ padding: 1.35rem 1.45rem;
+ border: 1px solid rgba(148, 163, 184, 0.28);
+ border-radius: 0.9rem;
+ background: var(--md-default-bg-color);
+ box-shadow: 0 8px 28px rgba(15, 23, 42, 0.05);
+}
+
+.gth-proof-card h3 {
+ margin-top: 0.35rem;
+ margin-bottom: 0.55rem;
+ font-size: 1.25rem;
+ line-height: 1.3;
+}
+
+.gth-proof-eyebrow {
+ display: inline-block;
+ font-size: 0.72rem;
+ font-weight: 700;
+ letter-spacing: 0.08em;
+ text-transform: uppercase;
+ color: var(--md-primary-fg-color);
+}
+
+.gth-trust-row {
+ display: flex;
+ align-items: center;
+ flex-wrap: wrap;
+ gap: 0.55rem;
+ margin: 1.2rem 0 2.4rem;
+ opacity: 0.92;
+}
+
+.gth-trust-row img {
+ max-height: 28px;
+}
+
+.gth-flow {
+ display: grid;
+ grid-template-columns: repeat(3, minmax(0, 1fr));
+ gap: 1rem;
+ margin: 1.3rem 0 1.6rem;
+}
+
+.gth-flow > p {
+ margin: 0 !important;
+ padding: 1rem 1.1rem;
+ border-left: 3px solid var(--md-primary-fg-color);
+ background: rgba(59, 130, 246, 0.06);
+}
+
+.gth-cta {
+ margin: 1.2rem 0 2rem;
+ padding: 1.5rem 1.7rem;
+ border-radius: 0.9rem;
+ background: rgba(59, 130, 246, 0.08);
+}
+
+.gth-cta h3 {
+ margin-top: 0;
+}
+
+[data-md-color-scheme="slate"] .gth-hero,
+[data-md-color-scheme="slate"] .gth-flow > p,
+[data-md-color-scheme="slate"] .gth-cta {
+ background-color: rgba(59, 130, 246, 0.08);
+}
+
+@media screen and (max-width: 760px) {
+ .gth-hero {
+ padding: 1.45rem 1.25rem;
+ }
+
+ .gth-proof-grid,
+ .gth-flow {
+ grid-template-columns: 1fr;
+ }
+
+ .gth-trust-row {
+ margin-bottom: 1.8rem;
+ }
+}
+