Devlog 5

What did I make?

I built a web app that turns any natural language goal into a structured, actionable to-do list. Powered by Groq AI using the openai/gpt-oss-20b model, typing a goal breaks it down into specific tasks with dynamic priorities (high, medium, low), time estimates, and dependencies. It features interactive task cards, live progress tracking, priority statistics, and robust localStorage persistence. The app runs 100% client-side, deployed directly on GitHub Pages.

What was challenging?

Ensuring the AI produced specific tasks rather than generic placeholders, and enforcing strict JSON output parsing without markdown clutter. Refactoring the architecture to a direct browser-level API model while adhering strictly to a zero-HTML-in-JS policy using native DOM manipulation. Also handling edge cases like state restoration on reload and managing Git tracking (.DS_Store).

What am I proud of?

The AI adapts dynamically-generating tailored, high-quality plans for everything from C++ systems programming to personal projects. The codebase is clean, modular, and resilient, with full interactive features like progress bars and checkbox persistence working seamlessly together.

What should people know?

Link: https://osnacc.github.io/AI-To-Do/

Just open the live link, type any goal, click “Generate Plan”, check off tasks, and reload the page to test full state persistence! No backend server or local setup required.

Devlog 2 - BLACK STAR: ANOMALY PROTOCOL

I continued working on my Unity game, BLACK STAR: ANOMALY PROTOCOL.

I added more visual effects and sounds to the terminal. I want the terminal to feel like a real computer system from a sci-fi game.

Now I am working on making the terminal more than just a menu. The player will use commands to investigate a space anomaly, solve a small security puzzle, and complete a mission.

The most challenging part is making the commands work together and keeping the game simple but interesting.

I am trying to focus on one complete mission instead of adding too many features. I also want the game to look good and have clear feedback when the player does something.

In the next update, I want to finish the mission, test the game, and prepare a playable version.

What I made: A sci-fi terminal interface with visual effects and sound, plus a terminal-based mission.

What I learned: How to improve the terminal experience and connect player commands to game events.

Video: A short demonstration of the terminal effects, sounds, and gameplay.

Devlog 2 - BLACK STAR: ANOMALY PROTOCOL

I continued working on my Unity game, BLACK STAR: ANOMALY PROTOCOL.

I added more visual effects and sounds to the terminal. I want the terminal to feel like a real computer system from a sci-fi game.

Now I am working on making the terminal more than just a menu. The player will use commands to investigate a space anomaly, solve a small security puzzle, and complete a mission.

The most challenging part is making the commands work together and keeping the game simple but interesting.

I am trying to focus on one complete mission instead of adding too many features. I also want the game to look good and have clear feedback when the player does something.

In the next update, I want to finish the mission, test the game, and prepare a playable version.

What I made: A sci-fi terminal interface with visual effects and sound, plus a terminal-based mission.

What I learned: How to improve the terminal experience and connect player commands to game events.

Video: A short demonstration of the terminal effects, sounds, and gameplay.

AeroNex - Devlog #4

What I did

I finished the main part of AeroNex. I worked on the booking system, ticket prices, login, registration, and terminal design.

I also fixed many bugs in my code. I changed the price system and started to put code in different files. This make the project more easy to understand.

What I learned

I learned more about C programming, bitwise operations, functions, arrays, and fixing bugs.

I also learned that program can look good, but the code inside can still have many problems. I need to check both the design and the logic.

Future plans

For now, I consider AeroNex finished. But I have more ideas for the future.

I want to add more features and use some new libraries. I also want to make different systems as separate projects, and later maybe connect them together.

This project helped me to learn more about C and prepare for my next projects. I will continue to improve my skills and make more things in the future.

AeroNex - Devlog #4

What I did

I finished the main part of AeroNex. I worked on the booking system, ticket prices, login, registration, and terminal design.

I also fixed many bugs in my code. I changed the price system and started to put code in different files. This make the project more easy to understand.

What I learned

I learned more about C programming, bitwise operations, functions, arrays, and fixing bugs.

I also learned that program can look good, but the code inside can still have many problems. I need to check both the design and the logic.

Future plans

For now, I consider AeroNex finished. But I have more ideas for the future.

I want to add more features and use some new libraries. I also want to make different systems as separate projects, and later maybe connect them together.

This project helped me to learn more about C and prepare for my next projects. I will continue to improve my skills and make more things in the future.

AeroNex - Devlog #3

What I did

This update I worked more on AeroNex. I did the price system. I also started to move code into many files.

In Devlog #2 I showed the terminal boxes. The program looked nice. But inside the booking logic was broken. So this time I fixed the real code.

Old price system (problem in v1)

In old version, when user booked a ticket, I saved the choice like this. I added numbers into one char:

accounts[index].accountsBooked[accounts[index].currentBooking] += 1;  // France
accounts[index].accountsBooked[accounts[index].currentBooking] += 8;  // Business
accounts[index].accountsBooked[accounts[index].currentBooking] += 32; // Today

My idea was to save each option in different bit of the byte. It looked smart. But it was broken:

• char only holds up to 255, so it overflows very fast
• I never moved currentBooking, so every booking overwrote same slot
• to read the number back into real ticket was almost impossible

New price system

This update I fixed it. I use the bit idea correctly now. Every choice has its own bits:

• Destination - bits 0 to 2
• Class - bits 3 to 4
• Time - bits 5 to 7

Bits do not overlap. So I can build the code with |:

unsigned char code = destination | (class << 3) | (time << 5);

And read it back with & and »:

unsigned char dest  =  code        & 0x07;
unsigned char klass = (code >> 3)  & 0x03;
unsigned char when  = (code >> 5)  & 0x07;

Then price is just three lookups added together:

int count_price(unsigned char code)
{
    return basePrice[dest] + classPrice[klass] + timePrice[when];
}

One byte for booking. One int for price. No overflow. No collisions. Easy to read.

Split into files

I also started to move code into different files:

• one file for checks (login, name, password, phone)
• one file for printing menus and boxes
• one file for booking logic
• one file for saving data
• main.c stays small and simple

Now main.c reads like a story: register, login, book, save.

Fixing bugs

While I refactored I found many bugs from v1:

• in checkLogin one condition could never be true (login[0] < 97 && login[0] > 123)
• dead branches in checkName that never ran
• the currentBooking counter that never moved
• time loop in booking() that never exited (I wrote flag = 0 but I need flag1 = 0)
• one segmentation fault. Program crashed when I read string after loop.

Fixing these bugs helped me understand C much better.

What I will do next

Next update I want to:

• finish the file split with a good Makefile
• save bookings to disk so they stay after program closes
• make terminal boxes cleaner
• add real ticket printing with new price

Project is still not finished. But the new bit price system fixed the core of booking logic.

AeroNex - Devlog #3

What I did

This update I worked more on AeroNex. I did the price system. I also started to move code into many files.

In Devlog #2 I showed the terminal boxes. The program looked nice. But inside the booking logic was broken. So this time I fixed the real code.

Old price system (problem in v1)

In old version, when user booked a ticket, I saved the choice like this. I added numbers into one char:

accounts[index].accountsBooked[accounts[index].currentBooking] += 1;  // France
accounts[index].accountsBooked[accounts[index].currentBooking] += 8;  // Business
accounts[index].accountsBooked[accounts[index].currentBooking] += 32; // Today

My idea was to save each option in different bit of the byte. It looked smart. But it was broken:

• char only holds up to 255, so it overflows very fast
• I never moved currentBooking, so every booking overwrote same slot
• to read the number back into real ticket was almost impossible

New price system

This update I fixed it. I use the bit idea correctly now. Every choice has its own bits:

• Destination - bits 0 to 2
• Class - bits 3 to 4
• Time - bits 5 to 7

Bits do not overlap. So I can build the code with |:

unsigned char code = destination | (class << 3) | (time << 5);

And read it back with & and »:

unsigned char dest  =  code        & 0x07;
unsigned char klass = (code >> 3)  & 0x03;
unsigned char when  = (code >> 5)  & 0x07;

Then price is just three lookups added together:

int count_price(unsigned char code)
{
    return basePrice[dest] + classPrice[klass] + timePrice[when];
}

One byte for booking. One int for price. No overflow. No collisions. Easy to read.

Split into files

I also started to move code into different files:

• one file for checks (login, name, password, phone)
• one file for printing menus and boxes
• one file for booking logic
• one file for saving data
• main.c stays small and simple

Now main.c reads like a story: register, login, book, save.

Fixing bugs

While I refactored I found many bugs from v1:

• in checkLogin one condition could never be true (login[0] < 97 && login[0] > 123)
• dead branches in checkName that never ran
• the currentBooking counter that never moved
• time loop in booking() that never exited (I wrote flag = 0 but I need flag1 = 0)
• one segmentation fault. Program crashed when I read string after loop.

Fixing these bugs helped me understand C much better.

What I will do next

Next update I want to:

• finish the file split with a good Makefile
• save bookings to disk so they stay after program closes
• make terminal boxes cleaner
• add real ticket printing with new price

Project is still not finished. But the new bit price system fixed the core of booking logic.

Teach Terminal

A browser-based game that teaches Linux terminal commands through interactive lessons and missions.

Today

Today I finished writing all 25 lessons and fixed several issues with the lesson system.

The lessons are organized into 5 sections - Introduction, Navigation, Files, Text & Redirection, and Permissions - plus a final congratulations lesson. Each practice lesson has multiple steps, so instead of a single command to type, the user might create a file, change its permissions, and verify with ls -l. The window tracks progress with markers like [x], [>], and [ ] so it is clear where the user is.

I also fixed bugs I found while testing the flow:

• The lesson window didn’t reset the filesystem between practices. If you completed mkdir projects once, replaying the lesson would fail because the folder already existed. Now the filesystem resets to a clean state at the start of every practice lesson.
• Sudo commands weren’t detected by the practice check. The checker only saw the inner command (chown root file.txt), not the full sudo chown root file.txt. Fixed by passing the full command through.
• Lesson 25 no longer has a practice - it just says “Congratulations! You finished Teach Terminal.” with a short message about what the user learned.

Completed

• index.html - Start menu with Start and Settings buttons
• settings.html - Settings page with three themes (Ubuntu, Hacker, Kali)
• login.html - Login page with username, machine name, and password validation
• mode.html - Mode selection: Free Exploration or Guided Path
• lessons.html - Course overview with sections and lesson cards
• main.html - Interactive terminal interface
• style.css - Main styling, animated gradients, glassmorphism UI, theme colors
• login.css - Login page styling with themed backgrounds
• settings.js - Saves the selected theme using localStorage
• theme.js - Loads the saved theme and applies it automatically
• login.js - Form validation and redirect to mode page
• filesystem.js - Fake Linux filesystem with files, folders, permissions, owners, groups, sizes, and modification times
• terminal.js - Terminal input handling, prompt display, line management, colored output, sudo flow
• command.js - Command recognition and execution
• lessons-data.js - All 25 lessons organized into 5 sections
• lesson.js - Renders the lessons page timeline
• lesson-window.js - Runs the lesson window inside the terminal

Current Commands

pwd, ls, cd, mkdir, touch, echo, cat, rm, cp, mv, chmod, chown, sudo, clear, help, history

With flags for most commands, redirection (>, >>, <, 2>), Tab autocomplete, arrow-key history, !! and !n expansion, and per-command help.

Goal

My goal is to create a realistic Linux terminal that teaches beginners how to use common commands through interactive lessons instead of just reading documentation.

Next Steps

• Add grep, head, tail
• Add pipes (|) and shell operators (&&, ||, ;)
• Wildcards and brace expansion

Try It

Live Demo

Teach Terminal

A browser-based game that teaches Linux terminal commands through interactive lessons and missions.

Today

Today I finished writing all 25 lessons and fixed several issues with the lesson system.

The lessons are organized into 5 sections - Introduction, Navigation, Files, Text & Redirection, and Permissions - plus a final congratulations lesson. Each practice lesson has multiple steps, so instead of a single command to type, the user might create a file, change its permissions, and verify with ls -l. The window tracks progress with markers like [x], [>], and [ ] so it is clear where the user is.

I also fixed bugs I found while testing the flow:

• The lesson window didn’t reset the filesystem between practices. If you completed mkdir projects once, replaying the lesson would fail because the folder already existed. Now the filesystem resets to a clean state at the start of every practice lesson.
• Sudo commands weren’t detected by the practice check. The checker only saw the inner command (chown root file.txt), not the full sudo chown root file.txt. Fixed by passing the full command through.
• Lesson 25 no longer has a practice - it just says “Congratulations! You finished Teach Terminal.” with a short message about what the user learned.

Completed

• index.html - Start menu with Start and Settings buttons
• settings.html - Settings page with three themes (Ubuntu, Hacker, Kali)
• login.html - Login page with username, machine name, and password validation
• mode.html - Mode selection: Free Exploration or Guided Path
• lessons.html - Course overview with sections and lesson cards
• main.html - Interactive terminal interface
• style.css - Main styling, animated gradients, glassmorphism UI, theme colors
• login.css - Login page styling with themed backgrounds
• settings.js - Saves the selected theme using localStorage
• theme.js - Loads the saved theme and applies it automatically
• login.js - Form validation and redirect to mode page
• filesystem.js - Fake Linux filesystem with files, folders, permissions, owners, groups, sizes, and modification times
• terminal.js - Terminal input handling, prompt display, line management, colored output, sudo flow
• command.js - Command recognition and execution
• lessons-data.js - All 25 lessons organized into 5 sections
• lesson.js - Renders the lessons page timeline
• lesson-window.js - Runs the lesson window inside the terminal

Current Commands

pwd, ls, cd, mkdir, touch, echo, cat, rm, cp, mv, chmod, chown, sudo, clear, help, history

With flags for most commands, redirection (>, >>, <, 2>), Tab autocomplete, arrow-key history, !! and !n expansion, and per-command help.

Goal

My goal is to create a realistic Linux terminal that teaches beginners how to use common commands through interactive lessons instead of just reading documentation.

Next Steps

• Add grep, head, tail
• Add pipes (|) and shell operators (&&, ||, ;)
• Wildcards and brace expansion

Try It

Live Demo

Teach Terminal

A browser-based game that teaches Linux terminal commands through interactive lessons and missions.

Today

Today I built the lesson window - the floating panel that runs inside the terminal during lessons. This is the piece that connects the lessons page to the terminal itself.

When a user picks a lesson from the overview, the terminal opens with ?lesson=N in the URL. The lesson window reads that number, finds the lesson in the data file, and appears in the top-right corner of the screen.

The window has three states:

Lecture - shows the lesson text explaining the concept. The user reads and clicks “Start Practice” (or “Complete” for intro lessons).

Practice - the window changes visually. Its border and title switch to an amber color, and a “PRACTICE:” prefix appears in the title. This makes it obvious that it’s time to do something, not just read. The user types the command in the terminal below.

Success - when the expected command is typed, the window shows the success message and a “Next Lesson” button appears. Clicking it swaps the window content to the next lesson without reloading the page.

The window is also draggable by its title bar. The user can move it anywhere, minimize it with -, or close it with × (which returns to the lessons page). Pressing Escape hides and shows the window.

I also added replay support. If a lesson is already complete, the user can open it again, read the lecture, and try the practice a second time. The window still shows the success message, but the lesson status stays DONE - it does not re-mark anything.

Some issues I hit:

• The intro lessons blocked the “Next Lesson” button because they were being re-completed in a loop. I fixed this by tracking a showingSuccess variable that tells the code whether we’re on the success screen or the lecture.
• The practice mode class wasn’t being added because the flow checked lessonComplete before checking whether we were in the practice phase. I reordered the checks so practice renders correctly even for replayed lessons.

Completed

• index.html - Start menu with Start and Settings buttons
• settings.html - Settings page with three themes (Ubuntu, Hacker, Kali)
• login.html - Login page with username, machine name, and password validation
• mode.html - Mode selection: Free Exploration or Guided Path
• lessons.html - Course overview with sections and lesson cards
• main.html - Interactive terminal interface
• style.css - Main styling, animated gradients, glassmorphism UI, theme colors
• login.css - Login page styling with themed backgrounds
• settings.js - Saves the selected theme using localStorage
• theme.js - Loads the saved theme and applies it automatically
• login.js - Form validation and redirect to mode page
• filesystem.js - Fake Linux filesystem with files, folders, permissions, owners, groups, sizes, and modification times
• terminal.js - Terminal input handling, prompt display, line management, colored output
• command.js - Command recognition and execution
• lessons-data.js - All 25 lessons organized into 6 sections
• lesson.js - Renders the lessons page timeline
• lesson-window.js - Runs the lesson window inside the terminal

Current Commands

pwd, ls, cd, mkdir, touch, echo, cat, rm, cp, mv, clear, help, history

With flags for most commands, redirection (>, >>, <, 2>), Tab autocomplete, arrow-key history, !! and !n expansion, and per-command help.

Goal

My goal is to create a realistic Linux terminal that teaches beginners how to use common commands through interactive lessons instead of just reading documentation.

Next Steps

• Build chmod, chown, sudo for the Permissions section
• Write lesson content for lessons 21-24
• Build the Final Mission with a timer and game-style objectives

Try It

Live Demo

Teach Terminal

A browser-based game that teaches Linux terminal commands through interactive lessons and missions.

Today

Today I built the lesson window - the floating panel that runs inside the terminal during lessons. This is the piece that connects the lessons page to the terminal itself.

When a user picks a lesson from the overview, the terminal opens with ?lesson=N in the URL. The lesson window reads that number, finds the lesson in the data file, and appears in the top-right corner of the screen.

The window has three states:

Lecture - shows the lesson text explaining the concept. The user reads and clicks “Start Practice” (or “Complete” for intro lessons).

Practice - the window changes visually. Its border and title switch to an amber color, and a “PRACTICE:” prefix appears in the title. This makes it obvious that it’s time to do something, not just read. The user types the command in the terminal below.

Success - when the expected command is typed, the window shows the success message and a “Next Lesson” button appears. Clicking it swaps the window content to the next lesson without reloading the page.

The window is also draggable by its title bar. The user can move it anywhere, minimize it with -, or close it with × (which returns to the lessons page). Pressing Escape hides and shows the window.

I also added replay support. If a lesson is already complete, the user can open it again, read the lecture, and try the practice a second time. The window still shows the success message, but the lesson status stays DONE - it does not re-mark anything.

Some issues I hit:

• The intro lessons blocked the “Next Lesson” button because they were being re-completed in a loop. I fixed this by tracking a showingSuccess variable that tells the code whether we’re on the success screen or the lecture.
• The practice mode class wasn’t being added because the flow checked lessonComplete before checking whether we were in the practice phase. I reordered the checks so practice renders correctly even for replayed lessons.

Completed

• index.html - Start menu with Start and Settings buttons
• settings.html - Settings page with three themes (Ubuntu, Hacker, Kali)
• login.html - Login page with username, machine name, and password validation
• mode.html - Mode selection: Free Exploration or Guided Path
• lessons.html - Course overview with sections and lesson cards
• main.html - Interactive terminal interface
• style.css - Main styling, animated gradients, glassmorphism UI, theme colors
• login.css - Login page styling with themed backgrounds
• settings.js - Saves the selected theme using localStorage
• theme.js - Loads the saved theme and applies it automatically
• login.js - Form validation and redirect to mode page
• filesystem.js - Fake Linux filesystem with files, folders, permissions, owners, groups, sizes, and modification times
• terminal.js - Terminal input handling, prompt display, line management, colored output
• command.js - Command recognition and execution
• lessons-data.js - All 25 lessons organized into 6 sections
• lesson.js - Renders the lessons page timeline
• lesson-window.js - Runs the lesson window inside the terminal

Current Commands

pwd, ls, cd, mkdir, touch, echo, cat, rm, cp, mv, clear, help, history

With flags for most commands, redirection (>, >>, <, 2>), Tab autocomplete, arrow-key history, !! and !n expansion, and per-command help.

Goal

My goal is to create a realistic Linux terminal that teaches beginners how to use common commands through interactive lessons instead of just reading documentation.

Next Steps

• Build chmod, chown, sudo for the Permissions section
• Write lesson content for lessons 21-24
• Build the Final Mission with a timer and game-style objectives

Try It

Live Demo

Teach Terminal

A browser-based game that teaches Linux terminal commands through interactive lessons and missions.

Today

Today I built the lessons system. This is the biggest step so far - the part that turns the terminal into a real teaching tool.

The lessons system has three parts:

The lessons overview page (lessons.html) shows all lessons organized into sections:

• Introduction
• Navigation
• Files
• Text & Redirection
• Permissions
• Final Mission

Each lesson appears as a card with a status: START (unlocked), DONE (completed), or LOCK (not yet unlocked). Intro lessons are always open so users can read them or skip. Navigation lessons unlock one at a time. Later sections unlock when the previous section is finished.

The lessons data file (lessons-data.js) stores all lesson content in one place. Each lesson has a lecture that explains the concept and a practice task with an expected command.

The lesson engine (lesson-window.js) will run inside main.html. It opens a floating window with the current lesson, shows the lecture, then the practice. When the user types the correct command, the lesson completes and unlocks the next one.

I also built the mode selection page (mode.html). After login, the user picks between two paths:

• Free Exploration : opens the terminal with no lessons
• Guided Path : opens the lessons overview

Progress saves to localStorage so completed lessons stay completed.

Some issues I hit:

• The unlock logic had a bug where Intro lessons blocked Navigation. I fixed it by skipping intro sections in the unlock check.
• CSS conflicts between .lesson-subtitle (used inside lesson cards) and .lessons-subtitle (used on the page). I renamed them to avoid mixing styles.
• The lessons page inherited overflow: hidden from the body, so it could not scroll. I added a body.lessons-page override.

Completed

• index.html - Start menu with Start and Settings buttons
• settings.html - Settings page with three themes (Ubuntu, Hacker, Kali)
• login.html - Login page with username, machine name, and password validation
• mode.html - Mode selection: Free Exploration or Guided Path
• lessons.html - Course overview with sections and lesson cards
• main.html - Interactive terminal interface
• style.css - Main styling, animated gradients, glassmorphism UI, theme colors
• login.css - Login page styling with themed backgrounds
• settings.js - Saves the selected theme using localStorage
• theme.js - Loads the saved theme and applies it automatically
• login.js - Form validation and redirect to mode page
• filesystem.js - Fake Linux filesystem with files, folders, permissions, owners, groups, sizes, and modification times
• terminal.js - Terminal input handling, prompt display, line management, colored output
• commands.js - Command recognition and execution
• lessons-data.js - All 25 lessons organized into 6 sections
• lesson.js - Renders the lessons page timeline

Current Commands

pwd, ls, cd, mkdir, touch, echo, cat, rm, cp, mv, clear, help, history

With flags for most commands, redirection (>, >>, <, 2>), Tab autocomplete, arrow-key history, !! and !n expansion, and per-command help.

Goal

My goal is to create a realistic Linux terminal that teaches beginners how to use common commands through interactive lessons instead of just reading documentation.

Next Steps

• Build the lesson window inside main.html (lecture, practice, success phases)
• Make the window draggable and minimizable with an Escape key toggle
• Build the Final Mission with game-style objectives
• Add remaining commands (grep, head, tail, chmod, chown)

Try It

Live Demo

Teach Terminal

A browser-based game that teaches Linux terminal commands through interactive lessons and missions.

Today

Today I built the lessons system. This is the biggest step so far - the part that turns the terminal into a real teaching tool.

The lessons system has three parts:

The lessons overview page (lessons.html) shows all lessons organized into sections:

• Introduction
• Navigation
• Files
• Text & Redirection
• Permissions
• Final Mission

Each lesson appears as a card with a status: START (unlocked), DONE (completed), or LOCK (not yet unlocked). Intro lessons are always open so users can read them or skip. Navigation lessons unlock one at a time. Later sections unlock when the previous section is finished.

The lessons data file (lessons-data.js) stores all lesson content in one place. Each lesson has a lecture that explains the concept and a practice task with an expected command.

The lesson engine (lesson-window.js) will run inside main.html. It opens a floating window with the current lesson, shows the lecture, then the practice. When the user types the correct command, the lesson completes and unlocks the next one.

I also built the mode selection page (mode.html). After login, the user picks between two paths:

• Free Exploration : opens the terminal with no lessons
• Guided Path : opens the lessons overview

Progress saves to localStorage so completed lessons stay completed.

Some issues I hit:

• The unlock logic had a bug where Intro lessons blocked Navigation. I fixed it by skipping intro sections in the unlock check.
• CSS conflicts between .lesson-subtitle (used inside lesson cards) and .lessons-subtitle (used on the page). I renamed them to avoid mixing styles.
• The lessons page inherited overflow: hidden from the body, so it could not scroll. I added a body.lessons-page override.

Completed

• index.html - Start menu with Start and Settings buttons
• settings.html - Settings page with three themes (Ubuntu, Hacker, Kali)
• login.html - Login page with username, machine name, and password validation
• mode.html - Mode selection: Free Exploration or Guided Path
• lessons.html - Course overview with sections and lesson cards
• main.html - Interactive terminal interface
• style.css - Main styling, animated gradients, glassmorphism UI, theme colors
• login.css - Login page styling with themed backgrounds
• settings.js - Saves the selected theme using localStorage
• theme.js - Loads the saved theme and applies it automatically
• login.js - Form validation and redirect to mode page
• filesystem.js - Fake Linux filesystem with files, folders, permissions, owners, groups, sizes, and modification times
• terminal.js - Terminal input handling, prompt display, line management, colored output
• commands.js - Command recognition and execution
• lessons-data.js - All 25 lessons organized into 6 sections
• lesson.js - Renders the lessons page timeline

Current Commands

pwd, ls, cd, mkdir, touch, echo, cat, rm, cp, mv, clear, help, history

With flags for most commands, redirection (>, >>, <, 2>), Tab autocomplete, arrow-key history, !! and !n expansion, and per-command help.

Goal

My goal is to create a realistic Linux terminal that teaches beginners how to use common commands through interactive lessons instead of just reading documentation.

Next Steps

• Build the lesson window inside main.html (lecture, practice, success phases)
• Make the window draggable and minimizable with an Escape key toggle
• Build the Final Mission with game-style objectives
• Add remaining commands (grep, head, tail, chmod, chown)

Try It

Live Demo

Teach Terminal

A browser-based game that teaches Linux terminal commands through interactive lessons and missions.

Today

Today I added redirection to the terminal. Commands can now read from files and write to them instead of only printing to the screen.

The terminal now supports:

• > - write output to a file (overwrites)
• >> - append output to a file
• < - read input from a file
• 2> - redirect error output to a file

I also connected < to cat so it can read from a file through stdin.

To make this work, I had to refactor how commands run. The old processCommand returned output directly. I renamed it to executeCommand and wrote a new processCommand wrapper above it that parses redirection operators before the command runs, then decides where the output goes.

The refactor was harder than expected. I hit several bugs - a typo in stderrMatch, a missing $ anchor in a regex, and a duplicate if block that used the wrong variable. I also had to fix catResults and lineNumber which I deleted during the refactor without realizing.

Completed

• index.html - Start menu with Start and Settings buttons
• settings.html - Settings page with three themes (Ubuntu, Hacker, Kali)
• login.html - Login page with username, machine name, and password validation
• main.html - Interactive terminal interface
• style.css - Main styling, animated gradients, glassmorphism UI, and theme colors
• login.css - Login page styling with themed backgrounds
• settings.js - Saves the selected theme using localStorage
• theme.js - Loads the saved theme and applies it automatically
• login.js - Form validation and redirect to terminal
• filesystem.js - Fake Linux filesystem with files, folders, permissions, owners, groups, sizes, and modification times
• terminal.js - Terminal input handling, prompt display, line management, colored output
• commands.js - Command recognition and execution

Current Commands

pwd, ls, cd, mkdir, touch, echo, cat, rm, cp, mv, clear, help

With flags for most commands, redirection (>, >>, <, 2>), and per-command help.

Goal

My goal is to create a realistic Linux terminal that teaches beginners how to use common commands through interactive lessons instead of just reading documentation.

Next Steps

• Command history (up/down arrow keys)
• Tab autocomplete
• history command, !!, !n
• Add grep, head, tail
• Add chmod, chown
• Wildcards, brace expansion, &&, ||
• Build the lesson system (lectures + practice missions)

Try It

Live Demo

Teach Terminal

A browser-based game that teaches Linux terminal commands through interactive lessons and missions.

Today

Today I added redirection to the terminal. Commands can now read from files and write to them instead of only printing to the screen.

The terminal now supports:

• > - write output to a file (overwrites)
• >> - append output to a file
• < - read input from a file
• 2> - redirect error output to a file

I also connected < to cat so it can read from a file through stdin.

To make this work, I had to refactor how commands run. The old processCommand returned output directly. I renamed it to executeCommand and wrote a new processCommand wrapper above it that parses redirection operators before the command runs, then decides where the output goes.

The refactor was harder than expected. I hit several bugs - a typo in stderrMatch, a missing $ anchor in a regex, and a duplicate if block that used the wrong variable. I also had to fix catResults and lineNumber which I deleted during the refactor without realizing.

Completed

• index.html - Start menu with Start and Settings buttons
• settings.html - Settings page with three themes (Ubuntu, Hacker, Kali)
• login.html - Login page with username, machine name, and password validation
• main.html - Interactive terminal interface
• style.css - Main styling, animated gradients, glassmorphism UI, and theme colors
• login.css - Login page styling with themed backgrounds
• settings.js - Saves the selected theme using localStorage
• theme.js - Loads the saved theme and applies it automatically
• login.js - Form validation and redirect to terminal
• filesystem.js - Fake Linux filesystem with files, folders, permissions, owners, groups, sizes, and modification times
• terminal.js - Terminal input handling, prompt display, line management, colored output
• commands.js - Command recognition and execution

Current Commands

pwd, ls, cd, mkdir, touch, echo, cat, rm, cp, mv, clear, help

With flags for most commands, redirection (>, >>, <, 2>), and per-command help.

Goal

My goal is to create a realistic Linux terminal that teaches beginners how to use common commands through interactive lessons instead of just reading documentation.

Next Steps

• Command history (up/down arrow keys)
• Tab autocomplete
• history command, !!, !n
• Add grep, head, tail
• Add chmod, chown
• Wildcards, brace expansion, &&, ||
• Build the lesson system (lectures + practice missions)

Try It

Live Demo

Devlog 3

Turn any goal written in natural language into a structured, actionable to-do list. Powered by OpenAI.

Progress Done

It’s the 7th hour into the project, and the app is now fully deployed and working end-to-end in the browser. A user opens the GitHub Pages link, types any goal, and the frontend sends a request to a live backend on Render, which calls gpt-4o-mini and returns structured task cards rendered on the page. I have connected OpenAI with Structured Outputs, added validation, loading and error states, interactive checkboxes, and deployed the backend with CORS configured for GitHub Pages.

Features Added/Worked on

• Connected OpenAI gpt-4o-mini with Structured Outputs (JSON Schema)
• Created openai.js as an isolated module for the model call
• Added POST /api/generate with validation (non-empty string, max 500 chars)
• Added error mapping for 401, 429 and generic failures
• System prompt tuned to produce specific, actionable tasks with priorities, time estimates, and dependencies
• Rendered task cards with priority-colored left border, priority badge and estimated time
• Added interactive checkboxes with completed state (dimmed + strikethrough)
• Added live character counter for the textarea
• Added loading spinner and error box
• Deployed backend to Render (Free tier) with OPENAI_API_KEY as an environment variable
• Added CORS middleware allowing requests from GitHub Pages and localhost
• Configured frontend to switch API base URL between localhost and Render

What new I learnt

• I learnt how Structured Outputs work in the OpenAI API (strict schema, additionalProperties)
• I learnt why API keys must live in .env on the server and never in frontend code
• I learnt that fetch does not throw on HTTP 4xx/5xx - you have to check response.ok manually
• I learnt how try / catch / finally works for cleaning up UI state on errors
• I learnt BEM-style class naming for state variants (taskCard–done)
• I learnt building DOM with createElement + appendChild instead of innerHTML (safer, no XSS)
• I learnt how CORS works and why browsers block cross-origin requests by default
• I learnt how to deploy a Node.js backend to Render and connect it to a static frontend on GitHub Pages

Try It

Live Demo - fully working, backend on Render

• First Generate can be until 1 minute wait please until server will wake up ;)

AI To Do List

Turn any goal written in natural language into a structured, actionable to-do list. Powered by OpenAI.

What works now

• Frontend UI: gradient header, glassmorphism goal card, textarea, “Generate Plan” button
• Live character counter (updates on every keystroke)
• Loading spinner while waiting for the backend
• Error box for empty input, auto-clears on retry
• Backend: Express server serving /docs and exposing GET /api/health
• POST /api/generate - validates the goal (non-empty, max 500 chars) and returns a hardcoded JSON plan with three tasks
• GitHub Pages previews the static UI

No AI yet - the endpoint exists so the data shape and client flow can be tested first.

What’s next

• Connect OpenAI gpt-4o-mini with Structured Outputs (JSON Schema)
• Replace the fake response in /api/generate with a real model call
• Replace the frontend placeholder with a real fetch() to the backend
• Render task cards: title, description, priority, time, dependencies
• Checkbox + progress bar + total time
• Priority statistics
• Save plan to localStorage
• Polish, mobile pass, deploy

Stack

• Frontend: HTML, CSS, vanilla JS
• Backend: Node.js, Express 5
• AI: OpenAI gpt-4o-mini, Structured Outputs (planned)
• Persistence: localStorage (planned)
• Preview: GitHub Pages (/docs)

Try It

Live Demo - UI only, backend not connected yet

AI To Do List

Turn any goal written in natural language into a structured, actionable to-do list. Powered by OpenAI.

Progress

• Project restructured into a single directory layout
• Frontend UI finished: gradient header, glassmorphism card with textarea, static character counter, “Generate Plan” button, hidden loading/error/dashboard sections
• server.js - Express server, serves /docs, exposes GET /api/health
• package.json - scripts start / dev, deps: express, dotenv, openai
• .env.example - template for PORT and OPENAI_API_KEY
• .gitignore - protects .env and node_modules/
• docs/style.css - dark theme, gradients, glass cards, responsive
• GitHub Pages previews the UI from docs/

No AI yet - that comes next.

Goal

Remove the “where do I start?” problem. A user types any goal - “build a portfolio website”, “prepare for a C++ exam”, “organize a birthday party” - and gets back a concrete, ordered list of tasks with priorities, time estimates, and dependencies.

The AI must not just rephrase the goal. It must decompose it into specific, actionable steps.

Stack

• Frontend: HTML, CSS, vanilla JS
• Backend: Node.js, Express 5
• AI: OpenAI gpt-4o-mini, Structured Outputs
• Persistence: localStorage (planned)
• Preview: GitHub Pages (/docs)

Try It

Live Demo - UI only, backend not connected yet