Cline rules

1# Liant Portfolio - Project Guidelines
2 
3> **Compatibility Note:** This guideline file is designed to be tool-agnostic and readable by any AI coding assistant (Cline, Copilot, future tools). It supplements the existing [.github/copilot-instructions.md](../.github/copilot-instructions.md) with additional conventions and preferences not covered there.
4 
5## Brief overview
6 
7- **Project:** A data-driven, single-page portfolio website for Brilliant Fikri (Liant), built with React 18 + Vite + Tailwind CSS + SCSS.
8- **Nature:** Pure frontend — no backend, no database. All content lives in `src/portfolio.jsx` as a single configuration file.
9- **Deployment:** Static site deployed to GitHub Pages (`gh-pages` branch) via GitHub Actions from `master` branch.
10- **Domain:** [brilliantfikri.com](https://brilliantfikri.com)
11 
12## Site language policy
13 
14- **Primary language for all user-facing content is English.** The portfolio targets an international/professional audience.
15- **Pending revision:** `pricingSection` in `src/portfolio.jsx` is currently in Bahasa Indonesia and must be translated to English. This includes all `title`, `description`, `desc`, `longDesc`, `features`, `notIncluded`, `workflow` fields, and the WhatsApp checkout message template in `src/containers/pricing/Pricing.jsx` (`handleCheckout` function).
16- Comments in code may use either English or Bahasa Indonesia — both are acceptable.
17- Communication with the developer (AI or human) may use Bahasa Indonesia.
18 
19## Communication style
20 
21- **Concise and direct.** Avoid filler words and conversational fluff in code comments, commit messages, and documentation.
22- Code comments should explain the "why," not the "what" — the code itself should be self-documenting for what it does.
23- **SCSS comments** use `/* */` block style for section headers (see existing pattern in `variables.scss`).
24- **JSX comments:** `//` for inline, `/* */` for multi-line explanations.
25 
26## Styling conventions
27 
28- **Tailwind CSS is the primary styling approach** for all new components and sections. Use utility classes directly in JSX (reference `src/containers/pricing/Pricing.jsx` as the canonical example).
29- **SCSS is reserved for reusable custom components** that need encapsulated, complex styles not easily expressed with Tailwind utilities. When creating a new reusable component in `src/components/`, co-locate a `.scss` file in the same folder.
30- **Design tokens:** Always reference CSS custom properties for theme-switchable values:
31  - `var(--bg-body)`, `var(--bg-card)`, `var(--text-primary)`, `var(--text-secondary)`, `var(--btn-primary-bg)`, `var(--border-light)`
32  - These are defined in `src/variables.scss` for both `.light-mode` and `.dark-mode`.
33  - For Tailwind, use arbitrary value syntax when needed: `bg-[var(--bg-card)]`, `text-[var(--text-primary)]`, `border-[var(--border-light)]`.
34- **SCSS variables** (prefixed with `$`) are for non-theme values only (e.g., `$brand-gold`, `$buttonHover`, static colors). Do not use SCSS variables for colors that should respond to dark/light mode.
35- **Never hardcode colors** in component JSX or SCSS that should respect the theme. Always go through CSS custom properties.
36- **Brand color:** Gold `#a1902e` (`$brand-gold`). This is the primary accent across buttons, links, and highlights.
37- **IMPORTANT:** The brand-gold in `tailwind.config.js` must match `$brand-gold` in `variables.scss`. Currently both use `#a1902e`. If one changes, update the other.
38 
39## Input and form handling
40 
41- **This project has no backend.** There is no server to POST form data to.
42- All "contact" or "checkout" interactions must use **direct action links:**
43  - **WhatsApp:** `https://wa.me/6281331487753?text=...` with a pre-formatted, URL-encoded message.
44  - **Email:** `mailto:briliantfikri@gmail.com` with optional `?subject=...&body=...` parameters.
45- Do NOT create `<form>` elements with submit handlers — there is nothing to handle submissions.
46- Do NOT add any form validation libraries or backend integration code.
47 
48## State management
49 
50- **Context API** is the established pattern for global state (see `src/contexts/StyleContext.js` for theme).
51- **Local state** (`useState` / `useReducer`) is sufficient for component-specific state.
52- **Custom hooks** in `src/hooks/` for reusable state logic (e.g., `useLocalStorage` for persistence).
53- Do NOT introduce Redux, Zustand, or other external state management libraries — they are unnecessary for this project's complexity level.
54 
55## Commit message conventions
56 
57Use structured, prefixed commit messages. The format is: `<type>: <brief description>`
58 
59| Prefix      | Use when                                                         |
60| ----------- | ---------------------------------------------------------------- |
61| `feat:`     | Adding a new section, component, or feature                      |
62| `fix:`      | Fixing a bug, broken style, or incorrect behavior                |
63| `refactor:` | Restructuring code without changing functionality                |
64| `style:`    | CSS/SCSS/Tailwind adjustments only (no logic changes)            |
65| `docs:`     | Updating README, comments, or documentation files                |
66| `chore:`    | Dependency updates, config changes, build tweaks                 |
67| `content:`  | Updating portfolio data in `portfolio.jsx` (text, images, links) |
68 
69Examples:
70 
71- `feat: add pricing calculator with WhatsApp checkout`
72- `fix: dark mode card background not applying on mobile`
73- `content: translate pricing section to English`
74- `chore: update framer-motion to v12`
75 
76## Library and dependency policy
77 
78- **No hard restrictions** on library usage, but exercise caution:
79  - Avoid packages with known security vulnerabilities or a history of unmaintained releases with CVEs.
80  - Prefer well-maintained, widely-adopted libraries with active GitHub repositories and recent releases.
81  - Before adding a new dependency, ask: "Can this be done with what we already have?" The project already includes React 18, Framer Motion, Lottie React, FontAwesome, and react-icons — which cover most UI needs.
82- **Do not add backend frameworks, ORMs, or database drivers** — this is a static frontend only.
83 
84## Section visibility control
85 
86- Every major section in `src/portfolio.jsx` has a `display: true/false` flag.
87- Containers in `src/containers/` must check this flag and return `null` when `display` is false.
88- The header navigation in `src/components/header/Header.jsx` should also check these flags to show/hide nav links accordingly.
89- When adding a new section, follow the pattern: config object → container with display check → registration in `Main.jsx` → optional nav link.
90 
91## Build and deployment notes
92 
93- **Dev server:** `npm run start` → Vite on port 3000, auto-opens browser.
94- **Production build:** `npm run build` → outputs to `build/` directory.
95- **Deployment:** GitHub Actions workflow (`.github/workflows/deploy.yml`) triggers on push to `master`, builds, and deploys to `gh-pages` branch. Also runs weekly on Monday 12:00 UTC.
96- **CI variable:** `CI=false` is set in the workflow to prevent treating warnings as errors during build.
97- **Node version:** 18.x (locked in CI workflow).
98 
99## Reusable component structure
100 
101When creating a new reusable component in `src/components/`:
102 
103```
104src/components/MyComponent/
105├── MyComponent.jsx     # Component logic
106└── MyComponent.scss    # Styles (only if Tailwind is insufficient)
107```
108 
109- Component file uses PascalCase matching the folder name.
110- Accept `className` prop to allow parent styling overrides.
111- Use `export default function ComponentName(...)` pattern (consistent with existing codebase).
112 
113## Accessibility baseline
114 
115- Use semantic HTML elements (`<section>`, `<nav>`, `<button>`, `<h1>`-`<h6>`).
116- Ensure header navigation links correspond to section `id` attributes for anchor-based scrolling.
117- Images should include meaningful `alt` text.
118- Interactive elements must be keyboard-accessible (buttons, not divs with onClick).
119 
120## Internationalization note
121 
122- The website currently supports a single language (English, with some Indonesian pending revision).
123- No i18n framework is in use. If multi-language support is added in the future, use the `feat_lang` add-on structure already defined in `pricingSection.featuresList` as a starting point (ID/EN, 2 languages).
124