🧬 LifeSim CLI — Devlog

📅 Project Overview

LifeSim CLI is a terminal-based life simulation game written in Rust.
The player starts at age 0 and makes yearly decisions that affect their stats, shaping their life until death or old age.

The project was built as a lightweight BitLife-inspired simulator using only a command-line interface.

🧠 Core Idea

The goal was to simulate a simplified human life using:

• Age progression system
• Player stats (Health, Happiness, Money)
• Choice-based decision system
• Random life events
• Win/lose conditions

⚙️ Features Implemented

👶 Life System

• Player starts at age 0
• Age increases every game loop iteration
• Life stages evolve over time

📊 Stats System

• Health
• Happiness
• Money

Each decision affects stats differently.

🎮 Player Choices

• Study
• Work
• Party
• Gym
• Do nothing

Each option changes stats and simulates real-life tradeoffs.

🎲 Random Events System

Each year, a random event may occur:

• 💸 Finding money
• 🤒 Getting sick
• (Planned) more life events like accidents or promotions

💀 Game Over Conditions

The game ends if:

• Health reaches 0
• Happiness reaches 0
• Age reaches 100

⏪ Age Regression (Planned / Experimental Feature)

A rare event where the player’s age can decrease due to a “timeline glitch,” adding unpredictability to gameplay.

🛠 Technical Stack

• Rust 🦀
• std::io for input handling
• rand crate for randomness

🧱 Architecture

The game is structured as a single-loop CLI application:

1. Display stats
2. Prompt user input
3. Apply action effects
4. Trigger random events
5. Update age
6. Check win/lose conditions
7. Repeat

🧪 What I Learned

• Handling user input in Rust
• Using loops for game logic
• Managing mutable state safely
• Working with randomness (rand crate)
• Building a full interactive program using only CLI

🚀 Future Improvements

• 🧑‍🎓 Education system (school → university)
• 💼 Career progression system
• 🏠 Asset system (buying items, housing)
• ❤️ Relationships system
• 🔄 Fully working age regression mechanic
• 💾 Save/load game state
• 🎨 Improved CLI UI (boxed layout, colors)

📸 Demo

(Insert screenshot or GIF of gameplay here)

📜 Status

Project is currently in early development but fully playable with core mechanics implemented.car

🧠 Devlog — Server-side AI Proxy (Cloudflare Workers)

Today I worked on building a lightweight server-side proxy using Cloudflare Workers to handle AI requests securely and bypass client-side limitations like CORS and API exposure.

⚙️ What I built

• A Cloudflare Worker that forwards requests to an AI API

• Supports two routes:

  • / → text generation (chat completions)
  • /image → image generation

• Added proper CORS handling so it can be called from browsers

• Implemented a helper function to safely validate upstream responses (safeJson)

🧩 Key features

• Unified endpoint for both text + image generation
• Automatic handling of invalid JSON responses from upstream
• Clean separation of routes based on URL path
• Simple and fast deployment via Workers

🚧 Challenges

• Handling CORS preflight requests (OPTIONS)
• Making sure upstream responses are always valid JSON
• Figuring out how Cloudflare Workers handle environment variables vs local development

🔑 Temporary decision

For now, I’m using a hardcoded API key to speed up development and testing.

I plan to migrate this to environment variables / secrets later for better security.

🚀 Next steps

• Move API key into Cloudflare secrets (env.HACKAI_KEY)
• Add rate limiting to prevent abuse
• Implement basic authentication to restrict usage
• Improve error handling and logging
• Possibly cache responses to reduce API usage

💭 Reflection

This was a good step into understanding how edge functions work. Cloudflare Workers feel super fast and lightweight compared to traditional backends, and it’s cool being able to deploy an API globally with almost no setup.

Status: Working ✅
Deployment: Live on Workers
Security: Needs improvement ⚠️

I added a loading screen and did some config

Updated the readme

🧪 DEVLOG — “Cooked: From CORS Hell to Actual Food Crimes”

Date: 27 Jan 2026
Project: Cooked 🍳
Status: WORKING (text + image)

What I built

I built a cursed AI cooking app that generates fake, unhinged dishes and AI images of them. The frontend is pure HTML/CSS/JS, and the backend is a Cloudflare Worker that proxies HackAI requests.

The main problem

Calling HackAI directly from the browser caused:

TypeError: Failed to fetch

CORS blocks

API key exposure

Image endpoints completely refusing to work

Basically: browser security vs my ambitions 💀

The fix (big brain moment)

I moved ALL AI calls server-side using a Cloudflare Worker:

Frontend → Worker (safe, CORS-free)

Worker → HackAI (API key hidden)

Text uses /chat/completions

Images use /images/generations

The Worker:

Handles CORS preflight (OPTIONS)

Injects the API key securely

Normalizes responses to valid JSON (even when HackAI fails)

Exposes two routes:

/ → text generation

/image → image generation (base64 PNG)

Final architecture
Browser (index.html + script.js)
↓
Cloudflare Worker (API proxy)
↓
HackAI (Qwen + Gemini Image)

Result

✅ No CORS errors

✅ No API key in frontend

✅ Text + image generation works

✅ App runs over localhost or deployed static hosting

✅ Feels illegal but is actually correct

Lessons learned

Browsers hate secrets (fair)

Image gen ≠ chat completions

Workers are mandatory for real AI apps

“Failed to fetch” usually means “you forgot CORS”

Overall: cooked, but successfully 🍳🔥

🍳 Cooked — Devlog (Extension Phase)

I originally built Cooked as a browser extension. The idea was simple: click the extension, press COOK, and instantly get a cursed AI-generated recipe. No tabs, no setup, just chaos.

The extension used Manifest V3 with a popup UI (popup.html, popup.css, popup.js). The design was intentionally minimal and terminal-styled: black background, green text, and a element to display AI output. Buttons included COOK and MAKE IT WORSE, and API keys were stored using chrome.storage.local.

Functionally, everything worked. The AI calls succeeded, state was preserved, and the logic was solid.

The real problems came from the popup UI constraints. Chrome extension popups have fixed size limits and do not scale well with dynamic content. Long AI responses were often cut off or cramped, even with scrolling enabled. Styling became a constant fight, requiring hard-coded widths, heights, and overflow hacks just to keep things readable.

Debugging was also slower than expected. Every small change required reloading the extension, reopening the popup, and re-testing. Missing a required permission (like “storage”) caused silent failures that were hard to track down.

Eventually, it became clear that the extension format wasn’t suited for long, expressive AI output. The core value of Cooked is the content itself, and the popup container was limiting that experience.

This phase wasn’t a failure—it clarified the constraints of extension UIs and led to a better architectural decision later.