Diese Anwendung teilt sich Netz, Datenbankcluster, öffentlichen Eingang und Backup mit anderen Projekten. Wer dort etwas ändert, ändert es für alle, und dem eigenen Repo sieht man es nicht an. Die Regel steht vollständig in christianmanivong/infrastructure; hier nur der Verweis, damit sie dort gelesen wird, wo gearbeitet wird. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.9 KiB
CLAUDE.md — netork-website
This is the official marketing website for netOrk, a self-hosted Network Orchestration Platform. The goal is a fast, visually striking single-page (or multi-page) site that communicates what netOrk does, who it is for, and how to get started.
Project Purpose
Potential users land here and need to answer three questions in under 10 seconds:
- What is this?
- Is it for me?
- How do I try it?
Everything on the site should serve those three questions.
Infrastruktur ändert man woanders — und vorher
Diese Anwendung läuft auf einer Infrastruktur, die sie sich mit anderen Projekten teilt:
Netz, Datenbankcluster, öffentlicher Eingang und Backup gehören keinem Projekt allein.
Dokumentiert ist sie in git.netork.io/christianmanivong/infrastructure, und dort
steht in CLAUDE.md auch die verbindliche Regel.
Kurz: erst dort dokumentieren, ausdrücklich genehmigen lassen, dann ändern. Nicht umgekehrt, und „ja mach mal" zu einer früheren Frage deckt die nächste Änderung nicht mit ab.
Betroffen ist alles, was über dieses Repo hinausreicht — Hosts, Netze, Firewall-Regeln,
der Patroni-Cluster samt pg_hba und DCS-Parametern, pgBackRest, BunkerWeb-Hosts, DNS,
CI-Runner, alles, was eine Anwendung auf den geteilten Datenbankcluster umzieht.
Nicht betroffen: Anwendungscode, Abhängigkeiten und Migrationen innerhalb der eigenen
Datenbank.
Der Grund für die Reihenfolge ist nicht Bürokratie. Die meisten Zwischenfälle dort waren nicht falsche Werte, sondern richtige Werte in der falschen Reihenfolge — und das fällt beim Aufschreiben auf, nicht beim Tippen. Im Zweifel dorthin.
Content & Design Source of Truth
All product content (features, copy, page structure) is in docs/:
| File | Purpose |
|---|---|
docs/PRODUCT.md |
Product description, target audience, value propositions, feature list |
docs/DESIGN.md |
Visual identity — exact Tailwind colors, typography, component patterns |
docs/PAGES.md |
Page-by-page content plan with section headings and copy drafts |
Read these files before writing any code or copy. They are the source of truth. The design file in particular defines exact class names — use them.
Tech Stack
Mirror the netOrk UI exactly so the design language carries over:
| Layer | Choice |
|---|---|
| Framework | React 18 + TypeScript |
| Build | Vite |
| Styling | Tailwind CSS v3 |
| Routing | React Router v6 (or static if single page) |
| Icons | Heroicons (inline SVG, same as netOrk UI) |
| Animation | Tailwind transitions only — no GSAP, Framer, etc. |
No external component libraries. Build everything from Tailwind primitives,
exactly as netOrk's ui/src/components/ui.tsx does.
Design Rules (summary — full detail in docs/DESIGN.md)
- Dark theme only. Background
bg-slate-950. Cardsbg-slate-900. - Accent color:
sky-500/sky-600for CTAs, links, highlights. - No light mode toggle. Ever.
- Font stack: system default (Tailwind sans). No Google Fonts.
- All interactive elements use
transition-colors— no layout shifts. - Screenshots/mockups of the actual app use a
border border-slate-700 rounded-xl overflow-hiddenwrapper to frame them against the dark background.
File Naming
netork-website/
├── CLAUDE.md ← this file
├── docs/
│ ├── PRODUCT.md
│ ├── DESIGN.md
│ └── PAGES.md
├── public/
│ └── screenshots/ ← actual app screenshots go here
├── src/
│ ├── components/
│ ├── pages/
│ └── main.tsx
├── index.html
├── package.json
└── tailwind.config.js
Tone of Voice
- Direct and technical — audience is engineers, not executives.
- No marketing fluff ("revolutionize", "empower", "seamless").
- Show, don't tell — a screenshot or code block beats three sentences of prose.
- German is fine for internal docs; the website copy is in English.