diff --git a/AGENT_INSTRUCTIONS.md b/AGENT_INSTRUCTIONS.md
new file mode 100644
index 0000000..0ae3c58
--- /dev/null
+++ b/AGENT_INSTRUCTIONS.md
@@ -0,0 +1,421 @@
+# Agent Instructions for cb341.dev Portfolio
+
+This file contains project-specific guidelines for AI agents working on this Astro portfolio site.
+
+## Project Overview
+
+- **Site**: https://cb341.dev
+- **Framework**: Astro 4.x (static site generation)
+- **Developer**: Dani Bengl - Full-Stack Developer
+- **License**: CC-BY-4.0
+- **Package Manager**: npm (package-lock.json present)
+- **Dev Server**: `localhost:4321`
+
+## Core Principles
+
+### Priorities (in order of importance)
+1. **Consistency** - Match existing patterns and conventions throughout the codebase
+2. **Performance** - Optimize for speed, minimal bundle size, fast load times
+3. **Accessibility (a11y)** - ARIA labels, semantic HTML, keyboard navigation
+4. **SEO** - Meta tags, structured data, semantic markup
+5. **Developer Experience** - Readable, maintainable, clear patterns
+
+### Philosophy
+- Keep it minimal and fast
+- Static-first, avoid client-side JavaScript
+- Semantic HTML over divs and classes
+- Let it fail fast - minimal error handling except at system boundaries
+- No unnecessary abstractions or over-engineering
+
+## File & Component Naming Conventions
+
+**Follow existing patterns:**
+- Components: `PascalCase.astro` (e.g., `BlogPostCard.astro`, `NavLink.astro`)
+- Layouts: `PascalCase.astro` (e.g., `BaseLayout.astro`)
+- Pages: `kebab-case.astro` or `[...slug].astro` for dynamic routes
+- Utilities: `camelCase.ts` (e.g., `dateHelpers.ts`)
+- Directories: `lowercase` (e.g., `components/`, `layouts/`, `pages/`)
+
+## Code Structure
+
+### Directory Organization
+```
+src/
+├── assets/        # Static assets (images, etc.)
+│   └── blog/      # Blog post images (WebP format)
+├── components/    # Reusable Astro components
+├── content/       # Content collections
+├── data/          # Data files
+├── layouts/       # Layout components
+├── pages/         # Routes (file-based routing)
+└── utils/         # Utility functions
+```
+
+## Styling Guidelines
+
+### When to Add Styles
+- **Only add CSS when explicitly requested**
+- Don't add styling to components unless the user asks for it
+- Rely on semantic HTML and existing styles when possible
+
+### How to Add Styles (when requested)
+- **ONLY** use scoped `<style>` tags within `.astro` components
+- **NEVER** create separate CSS files (`.css`, `.scss`, etc.)
+- **NEVER** use inline styles (style attribute)
+- **NEVER** use CSS frameworks (Tailwind, Bootstrap, etc.)
+- **NEVER** use CSS-in-JS libraries
+- Scoped styles are automatically handled by Astro
+
+### Example Pattern (when adding styles)
+```astro
+<article>
+  <h3><a href="/blog/post">Title</a></h3>
+</article>
+
+<style>
+  article:has(a:focus) {
+    outline: 2px solid blue;
+  }
+
+  a:focus {
+    outline: 0;
+  }
+</style>
+```
+
+## JavaScript Guidelines
+
+### Rules
+- **Minimize or avoid client-side JavaScript entirely**
+- Prefer static generation over client-side interactivity
+- **NEVER** add complex state management libraries
+- If JavaScript is absolutely necessary, keep it minimal and vanilla
+- Leverage Astro's server-side rendering capabilities
+
+## HTML & Accessibility
+
+### Semantic HTML
+- **Always** use proper HTML5 semantic elements
+- Prefer `<article>`, `<section>`, `<nav>`, `<header>`, `<footer>`, `<main>`, `<aside>` over generic `<div>`
+- Use `<time>` for dates with proper `datetime` attribute
+- Use `<em>` and `<strong>` over `<i>` and `<b>`
+
+### Accessibility Requirements
+- **Always** include `aria-label` on links and interactive elements
+- Ensure keyboard navigation works properly
+- Use proper heading hierarchy (h1, h2, h3)
+- Include `:focus` styles for keyboard users (when adding styles)
+- Test that all interactive elements are keyboard accessible
+
+### Example
+```astro
+<a
+  href={`/blog/${post.slug}`}
+  aria-label={`Read blog post: ${post.data.title}`}
+>
+  {post.data.title}
+</a>
+```
+
+## SEO Requirements
+
+### Structured Data
+- Include JSON-LD structured data in layouts
+- Use Schema.org types: `BlogPosting`, `WebPage`, `Person`
+- Include author information, dates, keywords
+
+### Meta Tags
+- Set proper `title` (format: `{Page Title} | {Site Title}`)
+- Include `description` meta tags
+- Add Open Graph tags for social sharing
+- Include canonical URLs
+
+### Example Pattern (from BaseLayout.astro)
+```javascript
+const structuredData = {
+  "@context": "https://schema.org",
+  "@type": type === "article" ? "BlogPosting" : "WebPage",
+  headline: title || defaultTitle,
+  description: pageDescription,
+  url: currentUrl,
+  author: {
+    "@type": "Person",
+    name: "Dani Bengl",
+    url: siteUrl,
+  },
+};
+```
+
+## Image Handling
+
+### Image Compression Guidelines
+- **Format**: Always use WebP for blog images and assets
+- **Quality**: Default to 85% quality (adjustable via `-q` flag)
+- **Tool**: Use `./scripts/img-to-webp.sh` or `npm run img-to-webp`
+- **Location**: Blog images go in `src/assets/blog/`
+- **Accepted inputs**: PNG, JPG, JPEG, GIF
+
+### Image Processing
+- **Preferred tool**: `cwebp` (install via `brew install webp`)
+- **Fallback**: `sips` (macOS built-in, limited quality control)
+- **Astro**: Uses `sharp` service for image optimization
+
+### When to Convert
+1. Before adding new images to the repository
+2. When image file sizes are >100KB
+3. For all blog post assets
+4. Convert existing images if making related changes
+
+### After Adding Images
+- **Always generate and examine a Lighthouse report** (see Performance Optimization section)
+- Verify images don't cause layout shifts or performance degradation
+- Check that alt text and accessibility attributes are present
+- Ensure images are properly sized and optimized
+
+### Usage Example
+```bash
+# Convert with default settings (85% quality)
+./scripts/img-to-webp.sh image.png
+
+# Convert with custom quality
+./scripts/img-to-webp.sh -q 90 image.jpg
+
+# Convert to specific location
+./scripts/img-to-webp.sh screenshot.png src/assets/blog/post-name.webp
+```
+
+## Build Configuration
+
+### Compression Settings (astro.config.mjs)
+- **CSS**: Enabled
+- **HTML**: Enabled (collapse whitespace, remove comments, preserve attribute quotes)
+- **JavaScript**: Enabled
+- **SVG**: Enabled
+- **Images**: Disabled (handled separately via WebP conversion)
+
+### Build Options
+- **Output**: Static site (`output: 'static'`)
+- **CSS**: No code splitting (`cssCodeSplit: false`)
+- **Stylesheets**: Auto-inline (`inlineStylesheets: 'auto'`)
+- **Chunks**: No manual chunks (keep it simple)
+
+### Markdown/MDX
+- **Syntax Highlighting**: Disabled in config (custom solution in use)
+- **Plugins**: Custom configuration (`extendPlugins: false`)
+
+## Development Workflow
+
+### Available Commands
+- `npm run dev` - Start development server at localhost:4321
+- `npm run build` - Type check and build (must pass before deployment)
+- `npm run preview` - Preview production build
+- `npm run fastcheck` - Quick type checking with auto-fix
+- `npm run fastcheck:check` - Quick type checking without fixes
+- `npm run img-to-webp` - Convert images to WebP format
+
+### Before Committing
+1. Run `npm run fastcheck:check` to verify types
+2. Run `npm run build` to ensure production build succeeds
+3. Test in browser at `localhost:4321` if UI changes were made
+4. Verify images are optimized (WebP format, reasonable file sizes)
+5. **When adding images or new features**: Generate and examine Lighthouse reports
+   - Run `npm run preview` after building
+   - Generate Lighthouse report for affected pages
+   - Review Performance, Accessibility, Best Practices, and SEO scores
+   - Address any regressions or new issues before committing
+
+### Git Workflow
+- **Main branch**: `main` (use for PRs)
+- Always run `npm run build` before committing significant changes
+- Use conventional commit messages
+- Keep commits focused and atomic
+
+## Code Quality
+
+### TypeScript
+- TypeScript is enabled - ensure proper typing
+- Run `astro check` before building
+- Use `./bin/fastcheck` for quick validation during development
+
+### Formatting
+- Prettier is configured (`.prettierrc.mjs`)
+- Let Prettier handle formatting automatically
+- Don't manually format code
+
+### Documentation
+- **Minimal comments** - only for complex logic
+- Prefer self-documenting code with clear naming
+- Don't add JSDoc unless the function is genuinely complex
+- Code should speak for itself
+
+## Dependencies
+
+### Policy
+- **Keep dependencies minimal** - avoid adding new packages unless absolutely necessary
+- Check `package.json` before suggesting new packages
+- Prefer built-in solutions over external libraries
+- Use npm for package management (not yarn or pnpm)
+
+### Current Stack
+- Astro core + official integrations (@astrojs/*)
+- TypeScript
+- Prettier
+- markdown-it, rehype/remark plugins
+- sanitize-html
+- astro-compress
+
+## Design & UI Patterns
+
+### Style
+- **Minimalist design** - clean, simple layouts with whitespace
+- **No animations or heavy effects** - keep it lightweight and fast
+- **Mobile-first responsive** - works on all screen sizes
+- Follow patterns in existing components
+
+### Visual Hierarchy
+- Use semantic headings for structure
+- Let typography and spacing create hierarchy
+- Avoid unnecessary decorative elements
+- Focus on content readability
+
+## Performance Optimization
+
+### Guidelines
+- Prefer static generation over client-side rendering
+- Keep bundle sizes minimal (no manual chunks configured)
+- Use WebP images to reduce page weight
+- Leverage Astro's built-in optimizations
+- Images processed through sharp service
+- No unnecessary JavaScript in the browser
+
+### Lighthouse Performance Testing
+
+**REQUIRED when adding images or new features:**
+
+1. **Build and preview the site**:
+   ```bash
+   npm run build
+   npm run preview
+   ```
+
+2. **Generate Lighthouse report**:
+   - Open Chrome DevTools (F12)
+   - Navigate to the Lighthouse tab
+   - Select categories: Performance, Accessibility, Best Practices, SEO
+   - Run report for affected pages
+
+3. **Review and address issues**:
+   - **Performance**: Should maintain high scores (aim for 90+)
+   - **Accessibility**: Must be 100 (critical requirement)
+   - **Best Practices**: Address any new warnings
+   - **SEO**: Maintain optimal scores
+
+4. **Common issues to watch for**:
+   - Image sizes and formats (ensure WebP is used)
+   - Missing alt text or aria-labels
+   - Cumulative Layout Shift (CLS) from images
+   - Largest Contentful Paint (LCP) degradation
+   - Missing meta descriptions or structured data
+
+5. **Report findings**:
+   - Share Lighthouse scores in commit messages or PR descriptions
+   - Document any performance trade-offs made
+   - Flag any issues that need addressing
+
+## Error Handling
+
+- **Minimal error handling** - let it fail fast
+- Only validate at system boundaries (user input, external APIs)
+- Trust internal code and framework guarantees
+- Don't add error handling for scenarios that can't happen
+- Focus on preventing errors through good design
+
+## Testing
+
+- No automated test suite (static site)
+- Manual testing workflow:
+  1. Verify the build passes (`npm run build`)
+  2. Test in browser (`npm run dev`)
+  3. Check type safety (`npm run fastcheck:check`)
+- Focus on ensuring builds succeed without errors
+
+## File Creation Guidelines
+
+- **PREFER** editing existing files over creating new ones
+- **NEVER** create documentation files unless explicitly requested
+- **NEVER** create separate CSS files
+- **NEVER** create new configuration files without discussion
+- Keep the codebase minimal and focused
+
+## Common Patterns to Follow
+
+### Component Structure
+```astro
+---
+// Imports and props at the top
+import { formatDate } from "../utils/dateHelpers";
+const { post } = Astro.props;
+---
+
+<!-- Semantic HTML with accessibility -->
+<article>
+  <h3>
+    <a
+      href={`/blog/${post.slug}`}
+      aria-label={`Read blog post: ${post.data.title}`}
+    >
+      {post.data.title}
+    </a>
+  </h3>
+
+  <div class="meta">
+    <em>
+      Published on <time datetime={post.data.publishedAt.toISOString()}>
+        {formatDate(post.data.publishedAt)}
+      </time>
+    </em>
+  </div>
+
+  <p>{post.data.description}</p>
+</article>
+
+<!-- Only add styles if explicitly requested -->
+<style>
+  /* Scoped styles go here */
+</style>
+```
+
+### Layout Structure
+- Include proper meta tags and structured data
+- Set up SEO-friendly titles and descriptions
+- Include accessibility features
+- Keep layouts clean and focused
+
+## What NOT to Do
+
+### Never:
+- Add CSS frameworks (Tailwind, Bootstrap, etc.)
+- Create separate CSS files
+- Use inline styles (style attribute)
+- Add client-side JavaScript libraries
+- Add complex state management
+- Use CSS-in-JS solutions
+- Add animations or heavy visual effects
+- Create unnecessary abstractions
+- Add dependencies without strong justification
+- Use divs when semantic elements exist
+- Skip accessibility attributes
+- Forget structured data for blog posts
+- Create documentation files unprompted
+- Add CSS styling unless explicitly requested
+
+## Summary
+
+This is a **minimal, fast, accessible, SEO-optimized static portfolio site**. When in doubt:
+1. Check existing code for patterns
+2. Keep it simple and semantic
+3. Prioritize performance and accessibility
+4. Avoid adding complexity
+5. Let the code speak for itself
+6. Only add styling when requested
+7. **Always run Lighthouse reports when adding images or new features**
diff --git a/src/assets/projects/8-bit-cpu/cpu_adder_invertor_circuit.webp b/src/assets/projects/8-bit-cpu/cpu_adder_invertor_circuit.webp
new file mode 100644
index 0000000..6109ae7
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/cpu_adder_invertor_circuit.webp differ
diff --git a/src/assets/projects/8-bit-cpu/cpu_alu_boolean.webp b/src/assets/projects/8-bit-cpu/cpu_alu_boolean.webp
new file mode 100644
index 0000000..7792478
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/cpu_alu_boolean.webp differ
diff --git a/src/assets/projects/8-bit-cpu/cpu_architecture_overview.webp b/src/assets/projects/8-bit-cpu/cpu_architecture_overview.webp
new file mode 100644
index 0000000..00d3e8c
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/cpu_architecture_overview.webp differ
diff --git a/src/assets/projects/8-bit-cpu/cpu_opcode_logic_unit.webp b/src/assets/projects/8-bit-cpu/cpu_opcode_logic_unit.webp
new file mode 100644
index 0000000..7adc90d
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/cpu_opcode_logic_unit.webp differ
diff --git a/src/assets/projects/8-bit-cpu/cpu_program_counter.webp b/src/assets/projects/8-bit-cpu/cpu_program_counter.webp
new file mode 100644
index 0000000..5dc6434
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/cpu_program_counter.webp differ
diff --git a/src/assets/projects/8-bit-cpu/cpu_register_closeup.webp b/src/assets/projects/8-bit-cpu/cpu_register_closeup.webp
new file mode 100644
index 0000000..6cb8b4e
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/cpu_register_closeup.webp differ
diff --git a/src/assets/projects/8-bit-cpu/ram_close_up_memory_cells.webp b/src/assets/projects/8-bit-cpu/ram_close_up_memory_cells.webp
new file mode 100644
index 0000000..9b25263
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/ram_close_up_memory_cells.webp differ
diff --git a/src/assets/projects/8-bit-cpu/ram_overview.webp b/src/assets/projects/8-bit-cpu/ram_overview.webp
new file mode 100644
index 0000000..ff7001c
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/ram_overview.webp differ
diff --git a/src/assets/projects/8-bit-cpu/ram_row_col_switching_logic.webp b/src/assets/projects/8-bit-cpu/ram_row_col_switching_logic.webp
new file mode 100644
index 0000000..289cce8
Binary files /dev/null and b/src/assets/projects/8-bit-cpu/ram_row_col_switching_logic.webp differ
diff --git a/src/assets/projects/rsmc/chat.webp b/src/assets/projects/rsmc/chat.webp
new file mode 100644
index 0000000..2afdf75
Binary files /dev/null and b/src/assets/projects/rsmc/chat.webp differ
diff --git a/src/assets/projects/rsmc/grass_closeup.webp b/src/assets/projects/rsmc/grass_closeup.webp
new file mode 100644
index 0000000..bfc0732
Binary files /dev/null and b/src/assets/projects/rsmc/grass_closeup.webp differ
diff --git a/src/assets/projects/rsmc/perlin_layers.webp b/src/assets/projects/rsmc/perlin_layers.webp
new file mode 100644
index 0000000..9ef53b1
Binary files /dev/null and b/src/assets/projects/rsmc/perlin_layers.webp differ
diff --git a/src/assets/projects/rsmc/trees.webp b/src/assets/projects/rsmc/trees.webp
new file mode 100644
index 0000000..0ba17ea
Binary files /dev/null and b/src/assets/projects/rsmc/trees.webp differ
diff --git a/src/assets/projects/ts-mc.webp b/src/assets/projects/ts-mc.webp
deleted file mode 100644
index 4c56c1d..0000000
Binary files a/src/assets/projects/ts-mc.webp and /dev/null differ
diff --git a/src/components/Footer.astro b/src/components/Footer.astro
index 092e9aa..456d78e 100644
--- a/src/components/Footer.astro
+++ b/src/components/Footer.astro
@@ -11,7 +11,8 @@ const currentYear = new Date().getFullYear();
           href="https://creativecommons.org/licenses/by/4.0/"
           target="_blank"
           rel="noopener noreferrer">CC BY 4.0</a
-        >.</small>
+        >.
+      </small>
     </p>
 
     <a
diff --git a/src/content/projects/8bit-cpu.md b/src/content/projects/8bit-cpu.md
new file mode 100644
index 0000000..26727c1
--- /dev/null
+++ b/src/content/projects/8bit-cpu.md
@@ -0,0 +1,93 @@
+---
+name: "8bit-cpu"
+description: "A minimal abstraction 8Bit CPU and 64 Byte RAM built entirely from single bit logic gates to understand computer architecture from first principles."
+tags:
+  [
+    "cpu",
+    "ram",
+    "logic-gates",
+    "computer-architecture",
+    "education",
+    "hardware",
+  ]
+---
+
+# Minimal Abstraction 8Bit CPU
+
+This project was sparked by the university courses INCO Information Theory and Encodings and GED Basics of Electrical and Digital Technology. They triggered a strong interest in low level systems and computer architecture.
+
+A friend recommended the game [Turing Complete](https://store.steampowered.com/app/1444480/Turing_Complete/), which acts as an educational CPU design environment. Instead of providing explicit instructions, it forces you to derive solutions from truth tables and first principles. Concepts like opcodes, instruction decoding and control logic are introduced gradually and implicitly.
+
+The game encourages the use of custom components. For example, once a half adder is built, it can be abstracted and reused instead of manually placing the same logic gates again. While this is practical, I deliberately avoided most abstraction.
+
+My goal was to design a CPU where all inner workings are visible at once. The emulator does not support inlining components, so every single bit level component was placed and wired manually. This took several dozen hours.
+
+The result is a fully functional 8Bit CPU architecture called OVERTURE within TC. It is a predecessor to the more advanced LEG which mainly differs in the size of the instructions.
+
+Emulation performance is predictably poor, as the game cannot apply meaningful shortcuts, but the design fulfills the original goal of maximum transparency.
+
+Because everything is built from single bit components, the design could theoretically be translated into real hardware or even implemented in Minecraft redstone.
+
+## Architecture Highlights
+
+- 8Bit registers built from individual latches
+- Custom opcode decoding and control logic
+- Boolean and arithmetic ALU operations
+- Dedicated program counter and instruction flow control
+- Fully manual wiring without higher level abstraction
+
+## Architecture Images
+
+### Register Close Up
+
+![8Bit register built from individual latches](../../assets/projects/8-bit-cpu/cpu_register_closeup.webp)
+
+### Architecture Overview
+
+![Complete OVERTURE CPU architecture showing all components](../../assets/projects/8-bit-cpu/cpu_architecture_overview.webp)
+
+### Adder and Inverter Circuit
+
+![Custom adder and inverter logic circuits](../../assets/projects/8-bit-cpu/cpu_adder_invertor_circuit.webp)
+
+### Opcode and Logic Unit
+
+![Opcode decoding and control logic unit](../../assets/projects/8-bit-cpu/cpu_opcode_logic_unit.webp)
+
+### ALU Boolean Operations
+
+![Arithmetic Logic Unit performing boolean operations](../../assets/projects/8-bit-cpu/cpu_alu_boolean.webp)
+
+### Program Counter
+
+![Program counter and instruction flow control](../../assets/projects/8-bit-cpu/cpu_program_counter.webp)
+
+## 64 Byte RAM Module
+
+I like having many tabs open. Was wondering how RAM works internally. I like to learn by doing so I built a naive (emulated) hardware implementation of a 64 byte RAM module.
+
+This RAM project was built in the same spirit as the CPU - understanding computer fundamentals by building them from first principles using single bit logic gates.
+
+The result is a functional 64 byte RAM module constructed entirely from basic logic components, demonstrating the core concepts of memory addressing, data storage, and retrieval at the hardware level.
+
+More info on [Reddit](https://www.reddit.com/r/TuringComplete/comments/1mvqjvt/64bytes_of_ram_made_of_1bit_logic_gates/).
+
+### RAM Architecture Highlights
+
+- Memory addressing and decoding
+- Data storage using latches
+- Read and write operations
+- Built entirely from single bit logic gates
+- Row and column selection logic for efficient addressing
+
+### RAM Overview
+
+![Complete 64 byte RAM module showing all components](../../assets/projects/8-bit-cpu/ram_overview.webp)
+
+### Memory Cells Close Up
+
+![Individual memory cells built from latches](../../assets/projects/8-bit-cpu/ram_close_up_memory_cells.webp)
+
+### Row and Column Switching Logic
+
+![Address decoding and row/column selection logic](../../assets/projects/8-bit-cpu/ram_row_col_switching_logic.webp)
diff --git a/src/content/projects/dotfiles.md b/src/content/projects/dotfiles.md
new file mode 100644
index 0000000..afbcaa9
--- /dev/null
+++ b/src/content/projects/dotfiles.md
@@ -0,0 +1,65 @@
+---
+name: "dotfiles"
+description: "I use Neovim btw. My personal configuration files for arch/nvim/git/tmux/zj/ghostty and more."
+tags: ["neovim", "dotfiles", "linux", "terminal", "productivity", "arch"]
+---
+
+# Dotfiles
+
+I use Neovim btw. I love writing code and I love tools. I want to dictate how stuff behaves so I have my own config for arch/nvim/git/tmux/zj/ghostty etc.
+
+These dotfiles represent my development environment carefully crafted over time to maximize productivity and match my workflow preferences. Every tool is configured to work seamlessly together.
+
+Repository: [https://github.com/cb341/dotfiles](https://github.com/cb341/dotfiles)
+
+## Current State
+
+The repository has two branches:
+
+- **stable**: The default branch that I don't update that often. This is set as "main" so my small changes I sync don't affect my contributions count on GitHub.
+- **main**: The real branch you are looking for. A bit messy at the moment, might clean up once I have time to dig into dotfiles again.
+
+## Philosophy
+
+As I wrote in [my editor journey](/blog/editor-journey):
+
+> "Neovim is not just a text editor. It is **FAST**, the fastest editing experience I have had. It is incredibly feature rich, yet keyboard oriented for efficient, sophisticated workflows."
+
+After bouncing between Atom, VSCode, JetBrains, NVChad, and even trying Cursor for AI features, I finally landed on **LazyVim**, the sweet spot between a pre-configured distro and the flexibility to customize without maintaining everything myself.
+
+I genuinely enjoy Neovim as a hobby. The community is fantastic, it is intuitive to use once you get the hang of it, and there is no big tech corp jargon or anyone pushing AI down my throat. Building software is about writing text, and Neovim integrates incredibly well with my terminal setup: zellij, autojump, ripgrep, lazygit. Everything works together seamlessly.
+
+This is the way.
+
+## Neovim Configuration
+
+I used to maintain my own nvim config from scratch, a bare-knuckle setup that prioritized raw performance above all else. No animations, no bloat, just pure speed. But maintaining it became a chore, especially managing language servers.
+
+LazyVim takes care of the boilerplate while letting me keep what matters: reduced animations, classic vim plugins (oil for file exploration, surround), no markdown rendering, and performance improvements. I also kept some unorthodox things like multicursor because they make me faster.
+
+The goal is still the same as my old config: if it doesn't make editing faster and more efficient, it doesn't make the cut. Short keybindings, minimal overhead, maximum speed.
+
+## Operating System
+
+I switched from **NixOS** to **Arch Linux** because Arch is easier to use and better documented. The Arch Wiki is genuinely one of the best resources for Linux configuration.
+
+When I do use Arch, I run **Hyprland** as my window manager. It's pretty dope, although I don't really get to use it that often.
+
+That said, my main machine is a **MacBook** I received working for Renuo, and I am pretty happy with it despite not having a fancy window manager. It has zsh and that's all I need. Neovim go brr.
+
+## What's Included
+
+- **LazyVim**: My Neovim distribution with custom configurations, LSP, treesitter, and carefully selected plugins
+- **Zellij**: Modern terminal workspace manager for efficient session management
+- **Ripgrep**: Fast search tool integrated into my workflow
+- **Lazygit**: Terminal UI for git commands
+- **Autojump**: Smart directory navigation
+- **Arch Linux**: System configuration and setup scripts (also works on macOS)
+- **Zsh**: Shell configuration with oh-my-zsh and custom aliases
+- **Git**: Custom aliases and workflow optimizations
+- **Ghostty**: Terminal emulator configuration
+- And many more tools configured to work in harmony
+
+## Learn More
+
+For the full story of how I ended up here, including my thoughts on AI coding assistants and why I chose LazyVim, check out my [editor journey blog post](/blog/editor-journey).
diff --git a/src/content/projects/rsmc.md b/src/content/projects/rsmc.md
new file mode 100644
index 0000000..0fc60b4
--- /dev/null
+++ b/src/content/projects/rsmc.md
@@ -0,0 +1,80 @@
+---
+name: "rsmc"
+description: "A multi threaded multiplayer voxel engine written in Rust. Evolution of my TypeScript Minecraft clones into a performant, multiplayer-focused implementation."
+tags:
+  [
+    "rust",
+    "voxel",
+    "multiplayer",
+    "client-server",
+    "graphics",
+    "networking",
+    "typescript",
+    "wasm",
+    "threejs",
+    "glsl",
+  ]
+---
+
+# RSMC
+
+RSMC is a multi threaded, blazingly fast, multiplayer voxel engine with a strict Client Server architecture. It is primarily a learning project to properly understand the Rust Programming language, its ecosystem and its constraints.
+
+## Project Evolution
+
+This is probably the project I spent most of my free time on. There have been many iterations:
+
+- **[Minecraft Clone](https://github.com/cb341/minecraft-clone)**: Simple infinite terrain, hacky, chaotic code written in JavaScript
+- **[TS-MC](https://github.com/cb341/ts-mc)**: A rewrite of Minecraft Clone in TypeScript, better code structure, functional hotbar, water, sand physics, hacky collisions
+- **[TSMC2](https://github.com/cb341/tsmc2)**: A more sophisticated codebase in TypeScript, multithreading with Webworkers, custom shaders with GLSL, better defined workflow with Pull Requests, attempt at integrating rust with WASM to improve terrain generation performance
+- **[RSMC](https://github.com/cb341/rsmc)**: A Minecraft clone written entirely in Rust, with focus on Multiplayer and performance
+
+I once heard that beginner projects in Rust include writing a calculator, a browser, or an operating system. So as a first project I decided to build a multi threaded voxel engine.
+
+The code should be taken with a grain of salt. Apart from Advent of Code, this is my first Rust project. An LLM would almost certainly write cleaner code, but generating solutions is not how I learn. I like my _old fashioned_ paperback copy of [the Rust programming language](https://nostarch.com/rust-programming-language-3rd-edition).
+
+The project is heavily developed through pull requests. Most features are documented there with sequence diagrams, screencasts and design notes. If you are interested in the technical details, feel free to dig through the PR history.
+
+Make sure to check out [the blog post](/blog/exploring-rust) for more details about the rust project.
+
+Repository: [https://github.com/cb341/rsmc](https://github.com/cb341/rsmc)
+
+## Features
+
+### Terrain Generation
+
+Perlin based 3D noise terrain generation using a density function with layered noise for mountains, caves, and varied landscapes.
+
+![Perlin noise layers used for 3D terrain generation showing density function visualization](../../assets/projects/rsmc/perlin_layers.webp)
+
+### World Features
+
+- Simple cave generation
+- Terrain modification placing and removing blocks
+- Tree generation with procedural placement
+- Basic collision handling
+
+![Procedurally generated trees scattered across the terrain](../../assets/projects/rsmc/trees.webp)
+
+### Rendering & Graphics
+
+- Custom occlusion based geometry builder
+- Efficient chunk meshing with face culling
+- Multithreaded terrain generation and meshing pipeline inspired by learnings from Zurich School of Engineering
+
+![Close-up of voxel geometry showing custom occlusion and rendering](../../assets/projects/rsmc/grass_closeup.webp)
+
+### Networking & Multiplayer
+
+- Hybrid UDP / TCP client server communication
+- Custom serialization and chunk compression
+- In game chat with graphical user interface
+- Extensive debug and visualization feature flags
+
+![In-game chat interface showing multiplayer communication](../../assets/projects/rsmc/chat.webp)
+
+## Development
+
+The project is built with a focus on learning Rust's ownership system, concurrency patterns, and performance optimization. Early development included building the network layer with Renet for client-server communication.
+
+![Early stage of development in RSMC. Renet visualiser for simultaneous client/server connections.](../../assets/blog/rsmc-early-development.webp)
diff --git a/src/content/projects/tsmc2.md b/src/content/projects/tsmc2.md
deleted file mode 100644
index c957025..0000000
--- a/src/content/projects/tsmc2.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-name: "tsmc2"
-description: "Second iteration of the TypeScript Minecraft clone, not to be confused with the Taiwan Semiconductor Manufacturing Company"
-tags: ["typescript", "wasm", "threejs", "glsl", "rust"]
-heroImage: "/src/assets/projects/ts-mc.webp"
----
-
-# TSMC2
-
-This is probably the project I spent most of my free time on. There have been many iterations:
-
-1. [Minecraft Clone](https://github.com/cb341/minecraft-clone): Simple infinite terrain, hacky, chaotic code written in JavaScript
-2. [TS-MC](https://github.com/cb341/ts-mc): A rewrite of Minecraft Clone in TypeScript, better code structure, functional hotbar, water, sand physics, hacky collisions
-3. [TSMC2](https://github.com/cb341/tsmc2): A more sophisticated codebase in TypeScript, multithreading with Webworkers, custom shaders with GLSL, better defined workflow with Pull Requests, attempt at integrating rust with WASM to improve terrain generation performance.
-4. [RSMC](https://github.com/cb341/rsmc): A Minecraft clone written entirely in Rust, in a very early stage with focus on Multiplayer and performance.
-
-Make sure to check out [the blog post](/blog/exploring-rust) for more details about the rust project.
-Also feel free to checkout the pull requests for mind-maps, documentation and demo showcases.
diff --git a/src/layouts/BaseLayout.astro b/src/layouts/BaseLayout.astro
index 24ee2ad..1bcb8d5 100644
--- a/src/layouts/BaseLayout.astro
+++ b/src/layouts/BaseLayout.astro
@@ -188,9 +188,9 @@ const structuredData = {
 
     <header role="banner">
       <h1>
-        <center
-          ><NavLink href="/" aria-label="CB341.DEV - Home">CB341.DEV</NavLink
-          ></center>
+        <center>
+          <NavLink href="/" aria-label="CB341.DEV - Home">CB341.DEV</NavLink>
+        </center>
       </h1>
       <nav role="navigation" aria-label="Main navigation">
         <center>