The Python exam consists in the following:

• Lab activity - maximum of 5 points based on your lab interaction
• Lab test (week 8) - on the paper - 40 pct
• Project (from week 9 to week 14) - 30 pct
• Course - 25 pct

The final grade for this exam is computed by applying Gauss curve formula on the final score (number of points) obtained by each student. The percentages proposed by ECTS ("top 10%, next 25%, next 30%, next 25%, lowest 10%") are used to transfer grades from one system to another and are based on the normalized distribution. The reality shows that the distribution of the scores obtained by the students following the evaluation does not always respect the normal Gauss distribution. For example, there are cases when 70-80% (or even more) of the scores received by the students are within the range [45-60]. Obviously, in these cases, one can not apply the same Gauss distribution as they will result in canceling the difference between someone with 80 points and someone with 60 points. For this reason, the ECTS percentages are only supported as a starting point in establishing the final grades; if the scores distribution is different than the normal one, the percentages will be adjusted accordingly.

Minimum requirements to pass this exam:

• 30 points cumulated from all lab and course

Courses

1. Introduction

   • Administrative
   • Python History
   • Variable
   • Basic Types
   • Numerical Operations
   • String types
   • Statemens (if, while, for)
   • Functions
   • Link: Course 1

2. Sequances

   • Lists
   • Touples
   • Link: Course 2

3. Key based containers

   • Sets
   • Dictionaries
   • Link: Course 3

4. Classes-1

   • Constructors
   • Data members
   • Methods
   • Link: Course 4

5. Classes-2

   • Inheritance
   • Special methods
   • Context manager
   • Link: Course 5

6. Exceptions

   • Exceptions
   • OS Module
   • sys Module
   • Link: Course 6

Project Rules

Grading:

• Projects of type C:
  • 10 Points
    • Full Functionality
    • Git Support
    • Git Phases Updates
    • Presented until week 11
  • 5 points
    • Full Functionality
    • Git Support
    • Git Phases Updates
    • Presented in week 12
• Projects of type B:
  • 20 Points
    • Full Functionality
    • Git Support
    • Git Phases Updates
    • Presented until week 12
  • 15 points
    • Full Functionality
    • Git Support
    • Git Phases Updates
    • Presented in week 13
• Projects of type A:
  • 30 points
    • Full Functionality
    • Git Support
    • Git Phases Updates
    • PEP documentation
    • Presented until week 13
  • 25 points
    • Full Functionality
    • Git Support
    • Git Phases Updates
    • PEP documentation
    • Presented until week 14

Glossary:

Full Functionality = Means that every requirement described for the project has to be addressed in its implementation

Git Support = The project has to be uploaded to a GIT account (github) that is shared with the teaching assistant

Git Phases Updates = Every phase has to be committed to Git in a separate commit (with a clear name) and should be functional.

PEP Documentation = The entire project has to be documented according to PEP specifications.

Final observations:

Please share your Github project with your teaching assistant starting from week 9. Furthermore, announce your teaching assistant that you are ready to present a project with 1-2 days before the presentation. We will only grade if the previous described conditions are achieved (e.g. if you chose a project of type A you can only receive either 30 or 25 points - a partial project will NOT BE GRADED). Please keep this in mind when you are choosing the project category. We encourage you to try to present before the final moment when your type of project can be presented. If during a presentation, we find problems with a project and there is still time until the last moment your project can be presented, you will be able to re-present again (as long as we respect the final week when that project can be presented). Projects can only be presented to YOUR teaching assistant Before the presentation we will ask you to identify yourself (using the camera and an identity act). During the presentation the camera has to be ON. The grades that you received are not FINAL. In Week 14 - 15 we will check for plagiarism among the submitted project. If this case, the final grade for the lab exam will be adjusted accordingly.

Projects of type A

Advanced RSync

This project consists of creating an advanced continuous synchronization script that keeps two locations (FTP, ZIP, or local folders) fully synchronized in real-time, handling file creation, modification, and deletion while maintaining logs and resolving conflicts based on file timestamps.

Phase 1: Location Parsing and Connection Setup

In this phase, the script needs to understand the format of the two locations provided as input and establish access to them. The locations can be of three types:

1. FTP – A remote folder accessed via FTP protocol. The format is: ftp:<username>:<password>@<host>/<path> Example: ftp:my_user:1234@127.0.0.1/folder

   • The script should parse the username, password, host, and path.
   • Establish an FTP connection to read/write files.

2. ZIP – A local ZIP archive. The format is: zip:<full_path_to_zip> Example: zip:C:\abc\d.zip

   • The script should be able to read and write files inside the ZIP archive.
   • Any changes (creation, modification, deletion) should be mirrored inside the ZIP.

3. Folder – A local folder in the file system. The format is: folder:<full_path_to_folder> Example: folder:C:\aaa

   • The script should monitor the folder for changes and copy files as needed.

During this phase, the script will:

• Parse the input strings to determine the type of each location.
• Extract relevant parameters (credentials for FTP, paths for ZIP or folder).
• Test the connection or access to ensure the location is available.

Functional Output: Script can correctly interpret input locations and establish connections/access to both locations, ready for synchronization.

Phase 2: Initial Synchronization

Perform initial synchronization based on existing files in both locations.

• If a file exists only in one location, copy it to the other location
• If a file exists in both locations but differs, copy the newest version based on modification timestamp
• Ensure conflicts are resolved deterministically

Functional Output: Both locations contain the same set of files with the newest versions present in both

Phase 3: Continuous Monitoring and File Creation Handling

Monitor both locations in real-time to detect newly created files.

• Detect file creation in either location
• Copy the new file to the other location
• Support recursive directories if applicable

Functional Output: New files in one location appear automatically in the other location

Phase 4: File Deletion Handling

Detect file deletions in either location and propagate deletions to maintain sync.

• Monitor for deleted files in each location
• Delete corresponding files in the other location
• Ensure that no extra files remain in either location

Functional Output: Files deleted in one location are removed from the other location in near real-time

Phase 5: File Modification Handling

Detect file modifications and ensure updated versions are propagated.

• Monitor timestamps or checksums to detect changes
• Copy the updated file to the other location, overwriting the old version
• Handle concurrent modifications safely

Functional Output: Modified files in one location are updated in the other location automatically

Phase 6: Logging and Error Handling

Implement logging for all synchronization events and handle errors robustly.

• Log file creations, deletions, and modifications with timestamps
• Log connection errors, file access errors, and retry attempts
• Provide a summary report of synchronization status

Functional Output: Clear logs showing all synchronization operations and errors for validation purposes

1.Chess

Phase 1. Core Board & Piece Engine

Implement the foundational chess board, pieces, and movement logic ensuring internal consistency and rule correctness.

• Represent an 8×8 board with piece objects.
• Implement basic legal moves for all pieces.
• Validate move boundaries and collisions.
• Provide ASCII rendering for debugging.

Functional result : A fully functional internal board where each piece can execute all basic legal moves without turn rules, checks, or captures. The state updates correctly and can be inspected programmatically or via console rendering.

Phase 2. Game State Manager (Turns, Captures, Check Detection)

Build the core of the game state, handling turns, captures, and checks.

• Enforce alternate turns.
• Implement capture rules.
• Detect check conditions.
• Track history of moves.

Functional result : A turn-based playable engine allowing two players to move pieces legally, capture opponents, and trigger correct check detection. The game state consistently updates move history and enforces turn legality.

Phase 3. Advanced Rules (Checkmate, Stalemate, Special Moves)

Add full chess rule support, including endgame conditions and special moves.

• Implement checkmate and stalemate logic.
• Add castling, en passant, pawn promotion.
• Validate special-move legality precisely.

Functional result : A complete rules engine correctly determining match endings and enabling all official chess mechanics, including castling, en passant, and promotions, ensuring any illegal special move is rejected.

Phase 4. Graphical Interface (Tkinter or Pygame)

Create an interactive visual chessboard.

• Render board and pieces graphically.
• Allow mouse-based selection and movement.
• Highlight legal moves.
• Display captures and turn indicator.

Functional result : A fully interactive GUI where players can click pieces, view valid moves, and complete turns visually. Moves update the board in real time, keeping consistent with the engine.

Phase 5. AI Opponent (Minimax + Heuristics)

Implement a challenging computer opponent using search algorithms.

• Add minimax with alpha-beta pruning.
• Create a position evaluation function.
• Configure difficulty levels based on depth.

Functional result : A playable human-vs-AI mode where the computer generates legal, strategic moves using minimax evaluation. Difficulty levels adjust depth, creating distinct play experiences.

Phase 6. Persistence, PGN Support & Analysis Tools

Add advanced features for game storage, loading, and analysis.

• Save/load games in PGN-like format.
• Provide move navigation and replay.
• Implement position evaluation visualizations (text-based).

Functional result : A system capable of saving and loading matches, replaying previous moves, and offering simple analysis indicators. Players can resume games and inspect historical positions reliably.

Messenger

This project consists of developing a graphical client-server application that allows two clients to communicate securely, with unique IDs, message logging, support for emojis and image transmission, and end-to-end encryption.

Phase 1: Client-Server Architecture Setup

Set up the basic client-server structure to allow multiple clients to connect and communicate through a central server.

• Implement a server that can accept multiple client connections simultaneously
• Assign a unique ID to each connected client
• Ensure proper connection and disconnection handling

Functional Output: Server running and multiple clients can connect, each receiving a unique ID

Phase 2: Text Message Transmission

Enable clients to send and receive text messages to/from a specific client ID.

• Send messages via the server as a relay
• Display incoming messages in the client GUI in real-time
• Ensure messages are delivered to the correct recipient ID

Functional Output: Clients can send and receive text messages in real-time

Phase 3: Message Logging and History

Store all sent and received messages in a file for each client to allow tracking message history.

• Save messages in a structured format including sender ID, receiver ID, timestamp, and message content
• Load message history when a client reconnects
• Allow viewing the conversation history for a specific client ID

Functional Output: Persistent log files per client with complete message history

Phase 4: Graphical User Interface

Develop a GUI for clients to interact with messages and manage conversations.

• Display conversation threads with proper formatting for sender and receiver
• Include input fields for composing messages and selecting recipient IDs
• Provide an interface to view message history per client

Functional Output: A functional client GUI where users can send, receive, and view messages easily

Phase 5: Encryption and Security

Implement end-to-end encryption for all messages to ensure secure communication.

• Encrypt messages before sending and decrypt upon receiving
• Manage encryption keys securely on client-side
• Ensure that only the intended recipient can read the messages

Functional Output: Secure encrypted messaging between clients with proper decryption on delivery

Phase 6: Multimedia Support

Extend the application to support emojis and image transmission.

• Enable sending and displaying emojis in messages
• Implement image sending and receiving, saving images alongside messages
• Ensure multimedia messages are properly encrypted and logged

Functional Output: Clients can send and receive emojis and images securely, with all content logged in message history files

Meeting scheduler

This project consists of developing a graphical application for managing meetings using a PostgreSQL database, allowing users to add persons, schedule and view meetings, and import/export meetings in a standard calendar format, with full input validation and error handling.

Phase 1: Database Setup and Connection

Set up the PostgreSQL database and connect the application.

• Create tables for Persons and Meetings
• Establish a secure database connection
• Handle connection errors

Functional Output: The application can connect to the database and access the required tables

Phase 2: Adding Persons

Allow adding new persons through the GUI.

• Validate input and prevent duplicates
• Insert new records into the Persons table
• Provide success/error feedback

Functional Output: New persons can be added and confirmed in the GUI

Phase 3: Scheduling Meetings

Enable scheduling meetings with start/end times and participants.

• Validate times and participant list
• Insert meeting records with participant mapping
• Handle conflicts and errors

Functional Output: Meetings are stored in the database with all participants

Phase 4: Displaying Meetings

Display meetings within a selected time interval.

• Query meetings from the database
• Show results in a readable format in the GUI
• Handle empty results

Functional Output: Meetings for the selected interval are displayed accurately

Phase 5: Export/Import Calendar

Allow export/import of meetings to/from a standard calendar format.

• Export selected meetings to iCal/ICS
• Import meetings from a calendar file with validation
• Provide success/error feedback

Functional Output: Meetings can be exported to and imported from a calendar file correctly

Phase 6: Input Validation and Error Handling

Validate inputs and handle exceptions gracefully.

• Check names, dates, and participant lists
• Display clear error messages
• Ensure the application keeps running

Functional Output: Invalid inputs and exceptions are caught with user feedback

Minesweeper

This project consists of developing a graphical application that simulates the classic Minesweeper game, allowing users to customize the board size, number of mines, and set a time limit for completing the game.

Phase 1: Board Setup and Customization

Create the Minesweeper board with configurable dimensions and mine placement.

• Allow users to set board size (rows and columns)
• Allow users to set the number of mines
• Randomly place mines on the board without overlaps

Functional Output: A Minesweeper board is generated according to user settings, ready for gameplay

Phase 2: Graphical User Interface

Develop the GUI for interacting with the Minesweeper board.

• Display the board as a grid of clickable cells
• Provide visual feedback for revealed cells, flagged cells, and mines
• Include input fields or sliders to set board parameters and start a new game

Functional Output: A functional GUI showing the Minesweeper board and controls for gameplay

Phase 3: Cell Interaction and Game Logic

Implement cell revealing, flagging, and mine detection logic.

• Left-click reveals a cell and shows the number of adjacent mines
• Right-click flags a cell as a suspected mine
• Reveal adjacent empty cells automatically when a cell with 0 neighboring mines is clicked

Functional Output: Clicking and flagging cells works correctly according to Minesweeper rules

Phase 4: Win/Loss Detection

Implement the logic to detect game completion.

• Detect a win when all non-mine cells are revealed
• Detect a loss when a mine is clicked
• Display appropriate messages or animations for win/loss

Functional Output: The game correctly identifies wins and losses with visual feedback

Phase 5: Timer and Time Limit

Add a countdown timer to limit gameplay duration.

• Allow users to set a time limit in seconds before starting the game
• Display the remaining time in the GUI
• End the game automatically when time runs out

Functional Output: The timer counts down correctly and enforces the time limit

Phase 6: Game Reset and Replay

Enable restarting or replaying the game without restarting the application.

• Provide a “New Game” button that resets the board and timer
• Retain user-configured settings for convenience
• Clear previous game data before starting a new game

Functional Output: Users can restart the game with new or existing settings without restarting the application

Diff Update

This project consists of developing an application that generates binary updates between different versions of a file, allowing reconstruction of the latest version from any previous version using encoded insert, delete, and change operations.

Phase 1: Input Parsing and Validation

Parse the command-line inputs and validate file existence and formats.

• Accept commands create and update with appropriate file arguments
• Verify that all input files exist and are accessible
• Handle invalid commands or missing arguments gracefully

Functional Output: The application correctly identifies the operation mode and validates input files

Phase 2: Generating Differences Between Versions

Create a list of operations (insert, delete, change) to transform older versions into the latest version.

• Compare the latest version with each previous version byte-by-byte
• Generate operations required to convert each old version to the latest
• Optimize operations to minimize file size

Functional Output: A complete set of differences (operations) is prepared for all previous versions

Phase 3: Encoding Differences into a Binary File

Encode the generated operations into a compact binary format.

• Write insert, delete, and change operations into a single .diff file
• Ensure the binary file contains enough information to reconstruct the latest version
• Handle large files efficiently

Functional Output: A binary .diff file is created containing all necessary update information

Phase 4: Applying Updates to Previous Versions

Implement functionality to reconstruct the latest version from an old version using the .diff file.

• Read the .diff file and interpret operations sequentially
• Apply insert, delete, and change operations to the input old version
• Create a new file representing the latest version

Functional Output: The latest version is correctly reconstructed from any previous version using the .diff file

Phase 5: Error Handling and Integrity Verification

Ensure reliable updates and handle errors during generation or application of diffs.

• Validate .diff file integrity before applying updates
• Catch file access errors, invalid operations, and mismatched versions
• Provide meaningful error messages to the user

Functional Output: The application handles errors gracefully and prevents corrupted updates

Phase 6: Command-Line Interface and Automation

Provide a user-friendly CLI for both creating diffs and updating files.

• Support create mode to generate .diff files
• Support update mode to reconstruct the latest file from a previous version
• Print progress or summary messages during operations

Functional Output: Users can efficiently create and apply binary updates via the command-line interface

Custom (Un)Packer

This project consists of building a command-line tool that creates and manipulates a custom, non-compressed archive format. It must support create_archive, list_content, full_unpack, unpack, logging, and strict validation.

Phase 1: Format design, CLI parsing and validation

Design archive layout and implement basic CLI with strict input checks.

• Define header + index structure
• Validate commands/paths
• Provide clear help/errors

Functional Output: CLI accepts valid commands and recognizes a consistent archive format.

Phase 2: Archive creation (create_archive)

Implement archive writing with metadata, deterministic order, and checksum.

• Walk directories/files
• Write header, index, file data
• Compute checksums

Functional Output: A correct archive is generated from files or folders.

Phase 3: Listing contents (list_content)

Read archive index and display file info without extraction.

• Parse header/index only
• Print filenames + sizes
• Detect malformed archives

Functional Output: Accurate content list with sizes is displayed.

Phase 4: Full extraction (full_unpack)

Extract all files safely with metadata restoration.

• Recreate folders/files
• Validate checksums
• Handle overwrite rules

Functional Output: Entire archive extracted correctly into destination folder.

Phase 5: Selective extraction (unpack)

Extract only specific files with logging and robust error handling.

• Select entries by name
• Write logs (success/errors)
• Handle missing files cleanly

Functional Output: Requested files extracted; logs generated.

Phase 6: Testing, logging and CLI refinement

Finalize tests, logging, and usability improvements.

• Add unit/integration tests
• Add verbose/debug logs
• Improve messages and usage

Functional Output: Stable, test-validated CLI with clear logs and reliable behavior.

BingeWatch

This project consists of developing a command-line tool that stores and tracks favorite TV series in a local database, monitors new episodes, checks YouTube for related trailers/uploads, and notifies the user based on preferences and scores.

Phase 1: Database Design and Command Parsing

Implement persistent storage and basic command parsing.

• Create DB schema (name, IMDB link, last episode, last watch date, score, snooze flag)
• Implement commands: add, delete, update score, snooze/unsnooze
• Validate inputs and log errors

Functional Output: Valid commands update the database successfully.

Phase 2: IMDB Episode Fetching Logic

Retrieve episode lists from IMDB without external libraries beyond urllib/html.parser.

• Fetch IMDB HTML
• Extract episode numbers and dates
• Detect new episodes vs. last watched

Functional Output: Tool identifies which episodes are new for each series.

Phase 3: Episode Ranking and Filtering by Score

Filter and sort new episodes based on user-defined scores.

• Assign priority by score
• Exclude snoozed series
• Sort new episodes descending by score

Functional Output: List of new episodes ordered by relevance.

Phase 4: YouTube Trailer & Upload Discovery

Search YouTube pages (HTML only) for trailers or uploads related to specific episodes.

• Build search queries
• Parse HTML results
• Extract video titles/URLs

Functional Output: Episode-specific trailer/upload list is generated.

Phase 5: Notifications and Change Detection

Track previously found videos and notify on new uploads.

• Compare new vs previous YouTube results
• Generate notifications for new items
• Log findings and timestamp them

Functional Output: User receives notifications only for newly discovered videos.

Phase 6: Full Listing, Logging, and CLI Refinement

Finalize listing output and improve logs/UX.

• Implement list to show all new episodes (excluding snoozed)
• Add detailed logs for operations
• Polish CLI messages and error handling

Functional Output: The tool lists all new episodes, applies filters, logs operations, and behaves reliably.

SongStorage

This project consists of developing a command-line tool that manages a storage folder of audio files and a metadata database, supporting add/delete/edit operations, searching, playlist archiving (“savelists”), and audio playback.

Phase 1: Storage Structure, DB Schema & CLI Validation

Set up Storage folder, persistent DB, and input validation.

• Create DB schema (filename, artist, title, release date, tags, format)
• Validate paths, audio types, and command syntax
• Produce clear errors/logs

Functional Output: CLI accepts valid commands and updates the DB/Storage structure accordingly.

Phase 2: Add & Delete Song Operations

Implement safe file import and removal with metadata handling.

• Copy audio file into Storage
• Insert metadata + generated ID in DB
• Delete file + DB entry by ID

Functional Output: Songs are added/removed consistently in both Storage and DB.

Phase 3: Metadata Modification

Implement selective metadata editing.

• Update only specified fields
• Validate formats (dates, tags)
• Log operations and errors

Functional Output: Metadata for a song is updated accurately by ID.

Phase 4: Search Engine & Criteria System

Implement flexible search logic based on multiple filters.

• Support field=condition pairs (artist=…, format=…, tags contain …)
• Allow combining rules with AND
• Return matching song metadata

Functional Output: Search returns correct matches for given criteria.

Phase 5: Savelist Creation (Archive Builder)

Create an archive containing songs matching search criteria.

• Evaluate search rules
• Collect matching files
• Build custom archive (no compression required) with metadata index

Functional Output: A valid savelist archive is produced containing selected songs.

Phase 6: Playback Support, Logging & CLI Refinement

Add optional audio playback and finalize logging/UX.

• Use 3rd-party library to play song by ID
• Add detailed logs for all commands
• Improve help, outputs, and error messages

Functional Output: Songs can be played; all operations are logged; user interacts with a polished CLI.

FindMissingBytes

This project consists of developing a high-performance parallel tool that reconstructs a file from a truncated archive, using an expected hash to detect the correct reconstruction. The tool must brute-repair missing tail bytes, unpack the archive, and validate the recovered file.

Phase 1: Archive Format Study & CLI Validation

Define assumptions about the archive structure and implement strict CLI parsing.

• Validate truncated archive path, filename, expected hash
• Optional command to truncate an archive for testing
• Provide clear errors/logs

Functional Output: Inputs are validated and archive structure assumptions are documented.

Phase 2: Truncation Simulation (Optional Input Generator)

Implement controlled archive truncation to produce test samples.

• Remove last x bytes from a valid archive
• Save truncated version + metadata (x, original hash)
• Log generation details

Functional Output: Tool can generate truncated archives for testing.

Phase 3: Parallel Tail Reconstruction Engine

Implement the core parallelized algorithm attempting to rebuild missing bytes.

• Estimate missing byte count
• Spawn threads/processes to brute-fill missing tail ranges
• Stream candidate completions to decompressor/unpacker

Functional Output: Multiple candidates are tested in parallel for archive validity.

Phase 4: Partial Unpack & Integrity Checking

Unpack only the target file from each candidate archive.

• Perform quick structural validation
• Attempt file extraction
• Compute hash incrementally
• Abort early on mismatches

Functional Output: Incorrect candidates are rejected fast; valid data reaches hash check.

Phase 5: Correct Match Detection Using Hash

Confirm the reconstruction using the expected hash.

• Compare extracted file hash with expected one
• On match, stop all workers
• Save successful reconstruction

Functional Output: The exact file is recovered and verified by hash.

Phase 6: Output Delivery, Logging & Cleanup

Deliver the recovered file and finalize UX.

• Write recovered file to output
• Terminate workers cleanly
• Log timings, attempts, failures
• Provide summary of parallel search

Functional Output: A cleanly extracted, hash-verified file is returned with complete logs.

WorkerPool

This project consists of developing a distributed system composed of a master scheduler and multiple workers. The master enqueues the top sites per country (Semrush), and workers download pages in parallel using a shared message queue.

Phase 1: Queue Setup, CLI Parsing & System Layout

Define architecture and communication through Redis/RabbitMQ.

• Validate queue configuration
• Define JSON message format (link, disk path)
• Prepare folder structure and logging

Functional Output: System correctly connects to the queue and accepts enqueue/dequeue operations.

Phase 2: Master Crawler for Semrush Country Pages

Implement the master that schedules downloads.

• Fetch Semrush country listing pages (HTML parsing only)
• Extract top 20 links per country
• Generate storage paths

Functional Output: Master gathers URLs and prepares enqueue-ready tasks.

Phase 3: Task Enqueueing by Master

Push download jobs into the queue.

• Serialize messages as JSON
• Push jobs reliably with retry logic
• Log enqueue successes/failures

Functional Output: Queue contains all download tasks with correct metadata.

Phase 4: Worker Implementation for Page Downloads

Implement workers that pull tasks and download content.

• Consume tasks from queue
• Download HTML content with error handling
• Save page to specified disk location

Functional Output: Workers download and persist pages to the correct folders.

Phase 5: Parallelism, Scaling & Failure Recovery

Ensure distributed operation and robust behavior.

• Support multiple worker instances
• Retry failed downloads
• Detect malformed messages or network issues

Functional Output: System handles parallel load, retries failures, and avoids message loss.

Phase 6: Logging, Monitoring & System Polishing

Refine logs, observability, and final output behavior.

• Master and workers produce structured logs
• Summaries of processed tasks
• Optional monitoring dashboard or counters

Functional Output: Full logging available; system runs stably and produces all downloaded files.

Checkers

Phase 1. Core Board & Piece Engine

Implement the foundational checkers board, pieces, and movement logic.

• Represent an 8×8 board with dark/light squares.
• Implement basic diagonal movement.
• Restrict moves to valid squares.
• Provide ASCII rendering for debugging.

Functional result: A functional internal board where pieces can move diagonally on valid squares. The system correctly updates piece positions and allows simple non-capturing moves for both players.

Phase 2. Game State Manager (Turns, Captures, Forced Captures)

Build the core game rules for capturing and turn control.

• Enforce alternating turns.
• Implement simple captures.
• Enforce mandatory captures.
• Track move history.

Functional result: A turn-based engine enabling legal moves, captures, and mandatory-jump enforcement. The game state updates consistently, only allowing a player to finish a turn after completing required captures.

Phase 3. Promotion, Multiple Jumps & King Rules

Implement advanced checkers mechanics for full rule compliance.

• Promote pieces to kings.
• Allow kings bidirectional movement.
• Implement multi-jump chains.
• Validate all advanced move sequences.

Functional result: A complete rules engine handling full promotions and multi-jump sequences. Kings move in both directions, and the system ensures all chained captures follow official rules.

Phase 4. Graphical Interface (Tkinter or Pygame)

Build an interactive visual board to play checkers.

• Render the board and pieces graphically.
• Allow mouse-based moves.
• Highlight legal moves and jumps.
• Display captures and turn indicator.

Functional result: A GUI where players select pieces, see valid moves, and make turns visually. The board updates in real time and reflects all rules, including mandatory captures and promotions.

Phase 5. AI Opponent (Minimax + Heuristics)

Implement an intelligent computer opponent with strategic play.

• Use minimax with alpha-beta pruning.
• Design evaluation heuristics (mobility, kings, captures).
• Add difficulty levels by search depth.

Functional result: A human-vs-AI mode where the computer produces legal, strategic moves. The AI responds based on configurable difficulty levels, using heuristics and pruning for efficient decision-making.

Phase 6. Persistence, Notation Support & Replay Tools

Add saving, loading, and analysis functionalities.

• Save/load games in a custom notation format.
• Implement move replay and navigation.
• Provide basic textual position evaluation.

Functional result: A system that stores full matches, reloads them, and replays moves one by one. Players can inspect past positions and continue previous games with full state consistency.

EncryptedDatabase

Phase 1: Database and storage layout design

Design the storage location for encrypted files and metadata schema in the database.

• Define file path structure
• Define metadata fields (filename, encryption method, key ID, etc.)
• Validate database connectivity

Functional Output: Database schema created and file storage path structured, ready for file insertion.

Phase 2: Asymmetric key generation and management

Implement key pair generation and secure storage for encryption and decryption.

• Generate public/private key pairs
• Store private keys securely
• Map keys to file metadata

Functional Output: Key pairs generated and associated with file entries in a secure and testable way.

Phase 3: File encryption and addition to database

Encrypt user-selected files and add entries to the database.

• Read file content
• Encrypt with asymmetric encryption using public key
• Store encrypted file and metadata in database

Functional Output: Files are encrypted, saved on disk, and registered in the database with correct metadata.

Phase 4: File retrieval and decryption

Implement reading and decryption of files from the database.

• Fetch encrypted file path and metadata
• Decrypt using associated private key
• Output original file content to user

Functional Output: User can retrieve and decrypt any stored file successfully.

Phase 5: File deletion and metadata cleanup

Add functionality to remove files and corresponding metadata.

• Delete encrypted file from disk
• Remove entry from database
• Ensure no residual data remains

Functional Output: Files and metadata are securely deleted with integrity checks.

Phase 6: Testing, error handling, and CLI interface

Add robust CLI, error handling, logging, and unit tests.

• Handle missing files, corrupted metadata, or key issues
• Implement clear CLI commands for add, read, delete
• Add logs and automated tests

Functional Output: Stable, test-validated CLI tool with encrypted file management and reliable error handling.

Redis GUI Client

Phase 1: RESP Protocol Implementation

Implement the Redis Serialization Protocol (RESP) for communication with a Redis server.

• Parse and serialize RESP message types (Simple Strings, Errors, Integers, Bulk Strings, Arrays)
• Validate message format and error handling

Functional Output: RESP messages can be sent and received correctly without using external libraries.

Phase 2: Connection Management and Command Execution

Implement connection handling to a local Redis server and basic command sending/receiving.

• Establish TCP socket connection
• Send commands following RESP format
• Receive and parse responses

Functional Output: Client can execute basic Redis commands and receive correct responses.

Phase 3: CRUD for Strings and Lists

Implement GUI support for basic operations on Strings and Lists.

• Create, read, update, delete elements
• Display contents in the GUI
• Handle edge cases (non-existent keys, empty lists)

Functional Output: Users can perform all CRUD operations on Strings and Lists via GUI.

Phase 4: CRUD for Sets and Hashes

Extend GUI to support Sets and Hashes operations.

• Add, remove, retrieve members/fields
• Display current state of Sets and Hashes
• Validate input types and errors

Functional Output: Users can manage Sets and Hashes entirely through the GUI with correct RESP handling.

Phase 5: CRUD for Sorted Sets and Additional Features

Implement operations for Sorted Sets and enhance GUI usability.

• Add elements with scores, retrieve range, remove elements
• Update GUI layout and sorting
• Error handling for score conflicts or invalid ranges

Functional Output: Full CRUD operations for Sorted Sets with live GUI updates.

Phase 6: Testing, Logging, and GUI Refinement

Add comprehensive tests, logging, and polish GUI design.

• Unit/integration tests for RESP and CRUD
• Verbose logging of commands and responses
• Improve GUI responsiveness and error messages

Functional Output: Stable, fully tested Redis GUI client with proper logs and smooth user experience.

GUI Resource Monitor

Phase 1: Resource Data Collection

Implement real-time monitoring of system resources.

• Collect CPU, memory, disk, and network usage periodically
• Store timestamps and usage data in memory

Functional Output: Application captures live system metrics at regular intervals.

Phase 2: GUI Design and Real-Time Display

Create GUI to display live resource usage with graphs and statistics.

• Use tkinter or equivalent for layout
• Update graphs dynamically without freezing UI

Functional Output: Users can view live CPU, memory, disk, and network usage in real-time.

Phase 3: Data Storage and Historical Logging

Persist resource metrics to a local database or file for history tracking.

• Store timestamped data efficiently
• Handle large data sets without UI lag

Functional Output: Historical resource data is recorded and retrievable for analysis.

Phase 4: Historical Data Visualization

Enable user to select time intervals to visualize past resource usage.

• Display graphs/statistics for selected intervals
• Support zooming, scrolling, and filtering

Functional Output: Users can explore historical resource usage accurately for any interval.

Phase 5: Exporting Graphs and Reports

Allow users to export graphs as JPEG or PDF files.

• Implement saving of current and historical graphs
• Include labels, legends, and timestamps

Functional Output: Graphs and reports can be exported in standard formats with accurate data.

Phase 6: Testing, Performance Optimization, and Refinement

Add tests, optimize performance, and improve UI/UX.

• Unit/integration tests for data collection, storage, and display
• Optimize refresh rate and memory usage
• Refine GUI layout, error handling, and responsiveness

Functional Output: Stable, efficient, and user-friendly resource monitor with complete test coverage.

HTTP Packet Sniffer

Phase 1: Raw Packet Capture

Set up low-level packet capture using Python sockets.

• Capture all incoming and outgoing TCP packets
• Ensure packets are captured in real-time without loss

Functional Output: Application successfully captures raw TCP packets from the network interface.

Phase 2: HTTP Packet Identification

Filter captured packets to identify HTTP traffic.

• Decode packet headers using struct/ctypes
• Separate HTTP requests from other traffic

Functional Output: Only HTTP request packets are displayed and processed.

Phase 3: Real-Time Display of Requests

Display HTTP requests in a structured format in the console.

• Show method, URL, source/destination IP, and timestamp
• Ensure readability and clarity

Functional Output: Users can view real-time HTTP requests with clear fields.

Phase 4: Request Filtering

Implement filters for captured HTTP requests.

• Filter by method type (GET, POST, DELETE, etc.)
• Filter by source or destination IP addresses

Functional Output: Users can view only the requests matching the selected filters.

Phase 5: Detailed Request Inspection

Allow users to inspect individual HTTP requests for details.

• Display headers, request mode, payload, and other metadata
• Provide structured console output

Functional Output: Users can view full details of any selected HTTP request.

Phase 6: Testing, Performance, and Robustness

Add testing and optimize performance for high-volume traffic.

• Ensure no packet loss or crashes under load
• Validate filter accuracy and inspection correctness

Functional Output: Stable, high-performance sniffer with reliable filtering and detailed request inspection.

Mancala/Oware

Phase 1: Board model, pit representation and rule engine

Implement dynamic pit setup, stone distribution and capture rules.

• Initialize pits and stores
• Validate legal moves
• Apply capture mechanics

Functional Output: Logical board with rule-compliant moves and correct stone capture behavior.

Phase 2: GUI foundation and interactive board rendering

Create visual board, pits, stones and interactive elements for player selection.

• Render pits/stores
• Animate stone movements
• Highlight selectable pits

Functional Output: Fully interactive board reflecting the current game state and player actions.

Phase 3: Human-vs-Human gameplay flow

Integrate GUI and engine to support alternating turns between two players.

• Enforce turn order
• Update board state
• Detect game-end conditions

Functional Output: Two-player matches progress correctly with full rule enforcement and end-of-game detection.

Phase 4: Random AI opponent integration

Add CPU player executing random legal moves while respecting game rules.

• Generate legal moves
• Execute CPU turn
• Update GUI and board

Functional Output: CPU can take valid turns, interact with GUI and follow all rules.

Phase 5: Score tracking, game statistics and session management

Implement scoring logic, cumulative statistics, and optionally save/load sessions.

• Track player scores
• Maintain match history
• Save and restore game state

Functional Output: Scores update correctly, statistics are recorded, and sessions can be persisted.

Phase 6: Advanced features, undo/redo, settings and polish

Add undo/redo functionality, difficulty settings for AI, and UI/UX enhancements.

• Implement undo/redo stack
• Configure AI difficulty
• Refine visual effects and messages

Functional Output: Polished, stable application with enhanced usability and configurable AI behavior.

Go

Phase 1: Board model, stone placement and rule engine

Implement variable-size grid, stone placement, captures, and legality checks.

• Initialize grid and coordinates
• Validate moves
• Detect captures and ko rule

Functional Output: Logical board enforcing Go rules with correct stone placement and captures.

Phase 2: Minimal GUI foundation and board rendering

Create simple visual grid with stones, highlighting playable positions and last move.

• Draw intersections
• Display stones by player
• Highlight valid placements

Functional Output: Interactive board reflecting legal moves and current game state.

Phase 3: Human-vs-Human gameplay flow

Integrate GUI and engine for full alternating turns between two players.

• Enforce turn order
• Update board and captures
• Detect game-end conditions

Functional Output: Two-player matches progress correctly with rule enforcement and end-of-game detection.

Phase 4: Random AI opponent integration

Add CPU player making legal random moves while respecting Go rules.

• Generate legal moves
• Execute CPU turn
• Update GUI and board state

Functional Output: AI completes valid turns interacting correctly with human moves and game interface.

Phase 5: Score tracking, territory evaluation, and game statistics

Implement scoring, simple territory calculation, and optional game session tracking.

• Count captured stones
• Evaluate territories
• Record game history

Functional Output: Scores update correctly, capturing is tracked, and match statistics are recorded.

Phase 6: Advanced features, undo/redo, settings and polish

Add undo/redo functionality, board size selection, visual improvements, and session persistence.

• Implement undo/redo stack
• Allow board configuration
• Refine UI and display messages

Functional Output: Polished, stable application with configurable board, undo support, and persistent sessions.

Snake

Phase 1: Board model, snake, food, and obstacles

Implement dynamic board from JSON, snake movement rules, food spawning, and obstacle handling.

• Parse JSON for size/obstacles
• Initialize snake and food
• Enforce movement and collision rules

Functional Output: Board initializes correctly with snake, food, and obstacles respecting all rules.

Phase 2: Minimal GUI rendering and animation

Create visual representation of board, snake, food, and obstacles with smooth movement updates.

• Draw grid, snake, food, obstacles
• Animate snake movement
• Highlight collisions

Functional Output: Interactive board showing snake, obstacles, and food with correct movement animations.

Phase 3: Single game session mechanics and scoring

Implement a full game round with score tracking and end-of-game detection.

• Update score on food consumption
• Detect collisions/end of round
• Display current score

Functional Output: Game round completes correctly with score updates and collision detection.

Phase 4: Multi-round session and session flow

Allow multiple consecutive games in a session with option to continue or end.

• Track session rounds
• Display session menu between rounds
• Carry over high score

Functional Output: Players can continue or terminate session with cumulative scoring across rounds.

Phase 5: High score persistence and JSON integration

Implement persistent high score tracking and apply obstacle/board configurations from JSON.

• Load/save high score
• Apply JSON board configurations
• Validate consistency

Functional Output: High score updates and persists; board layouts match JSON specifications.

Phase 6: Undo, settings, polish, and final UI enhancements

Add undo for last move (optional), speed/settings adjustments, and visual/audio polish.

• Implement undo stack
• Allow speed or size adjustments
• Refine animations and messages

Functional Output: Polished, configurable game supporting session management, high scores, and smooth visual feedback.

Solitaire

Phase 1: Card model, deck shuffling and rule engine

Implement standard deck, shuffling, dealing into tableau, foundation, and stock piles with move legality.

• Initialize 52-card deck
• Deal cards to tableau
• Validate legal moves

Functional Output: Complete logical board enforcing Solitaire rules with correct initial layout and move checks.

Phase 2: Minimal GUI foundation and card rendering

Create visual representation for tableau, foundations, stock, and waste piles.

• Render cards face up/down
• Highlight selectable/movable cards
• Animate card movements

Functional Output: Interactive board reflecting legal moves and current card states.

Phase 3: Move execution and game state updates

Implement card movement between tableau, foundations, stock, and waste with rule enforcement.

• Execute moves with validation
• Update piles dynamically
• Detect win/loss conditions

Functional Output: Player moves apply correctly and game state updates with proper end-of-game detection.

Phase 4: Stock cycling, undo functionality, and multiple draw options

Add stock pile cycling (single/double draw), and undo/redo moves.

• Implement stock draw rules
• Track move history for undo/redo
• Apply multiple draw options

Functional Output: Stock behaves correctly, and players can undo/redo moves reliably.

Phase 5: Scoring, timing, and session management

Implement scoring system, game timer, and support for multiple rounds in a session.

• Track moves and points
• Display timer
• Allow restarting new rounds

Functional Output: Scores and timers update correctly; multiple rounds can be played in a session.

Phase 6: Polish, visual enhancements, settings, and persistence

Add visual improvements, configurable settings (draw count, deck order), and session persistence.

• Improve animations/UI
• Save/load sessions and high scores
• Allow configuration adjustments

Functional Output: Polished, stable application with configurable options, persistent scores, and enhanced visual feedback.

States of the World

Phase 1: Web crawling and data extraction

Build a crawler to scrape country information from Wikipedia and normalize data fields.

• Access country pages
• Extract name, capital, population, density, area, neighbors, language, timezone, political system
• Clean and validate data

Functional Output: Structured dataset containing all required country information with consistent formatting.

Phase 2: Database schema design and population

Design relational schema and populate database with extracted country data.

• Create tables with constraints
• Map extracted fields
• Insert all country records

Functional Output: Fully populated database reflecting all countries and their attributes.

Phase 3: Basic API setup and routing

Implement REST API with GET routes for core queries.

• Setup framework (e.g., Flask/FastAPI)
• Implement /top-10-population and /top-10-density
• Return JSON responses

Functional Output: API responds with accurate top 10 lists for population and density.

Phase 4: Advanced query routes and filtering

Add routes for flexible queries (by timezone, language, political system, neighbors).

• Parse query parameters
• Filter database records
• Return structured JSON

Functional Output: API supports multiple query filters and returns correct country lists.

Phase 5: API optimization and error handling

Ensure efficient queries, proper indexing, and robust error responses.

• Add database indexes
• Handle missing or invalid routes
• Provide clear error messages

Functional Output: Fast, reliable API with stable performance and informative error handling.

Phase 6: Testing, logging, and documentation

Implement unit/integration tests, request logging, and API documentation.

• Add automated tests for crawler, database, and API
• Log all requests and errors
• Provide usage documentation

Functional Output: Fully tested, documented API with logs and reliable, predictable behavior.

Browser Total Commander

Phase 1: Backend setup and filesystem abstraction

Implement Python backend to access, read, and modify local filesystem safely.

• Expose basic directory listing and metadata
• Validate paths to prevent unsafe operations
• Provide API endpoints for file/folder operations

Functional Output: Backend can list directories, read metadata, and safely expose filesystem through API.

Phase 2: Web interface foundation with dual panels

Create minimal web interface showing two panels with folder contents, sizes, and creation dates.

• Render panels dynamically
• Display file/folder details
• Allow panel-based folder navigation

Functional Output: Two interactive panels show folder contents and allow navigation independently.

Phase 3: File and folder operations (copy, delete, move, rename)

Implement core operations between panels with selection support.

• Support multi-selection
• Apply operations across panels
• Update panels in real-time

Functional Output: Files/folders can be copied, moved, renamed, or deleted correctly between panels.

Phase 4: Creation and editing of files/folders

Add ability to create new folders/files and edit text files directly.

• Create empty files and folders
• Edit text files in browser
• Save changes to filesystem

Functional Output: Users can create and edit files/folders with immediate updates in panels.

Phase 5: Navigation, state management, and session persistence

Maintain current directories, navigation history, and selection state across operations.

• Track panel states
• Implement back/forward navigation
• Preserve selections between operations

Functional Output: Panel navigation and selection state persist reliably while performing operations.

Phase 6: Testing, logging, security, and UI polish

Add input validation, logging, error handling, and visual enhancements.

• Log all operations
• Handle invalid paths/permissions
• Improve interface responsiveness

Functional Output: Stable, secure web-based file manager with polished UI and robust backend behavior.

Browser RegEdit

Phase 1: Backend registry abstraction and storage

Implement Python backend to mimic Windows Registry with key/value structure and types.

• Support string, DWORD, multi-string, and binary values
• Store keys/values in structured format
• Validate operations to avoid inconsistent states

Functional Output: Backend correctly stores registry-like keys and values with type safety and hierarchical structure.

Phase 2: Web interface with dual-panel layout

Create minimal web UI with left tree panel and right key/value list panel.

• Left panel displays key hierarchy
• Right panel shows values and metadata
• Allow navigation through keys

Functional Output: Interactive dual-panel interface reflecting hierarchical structure and key/value details.

Phase 3: Create, edit, and delete keys and values

Implement creation, deletion, and modification of registry keys and values.

• Add new keys and values
• Edit string values
• Delete keys/values safely

Functional Output: Users can perform CRUD operations on keys and values with immediate UI update.

Phase 4: Rename keys and values

Enable renaming of keys and registry values while maintaining hierarchy.

• Rename selected keys
• Rename value names in right panel
• Preserve structure consistency

Functional Output: Renamed keys and values reflect immediately in UI without breaking hierarchy.

Phase 5: Recursive search and filtering

Implement search for string values and optionally recursive within a key.

• Search by value name or content
• Highlight search results
• Support recursive traversal

Functional Output: Users can search for values with matches highlighted, optionally searching nested keys.

Phase 6: Testing, logging, security, and UI polish

Add validation, logging, error handling, and interface improvements.

• Log all operations
• Handle invalid or conflicting edits
• Refine tree/list interactions and responsiveness

Functional Output: Stable, secure, fully tested web-based registry editor with polished, responsive dual-panel interface.

Mahjong

Phase 1: Board model, tile set logic and rule groundwork

Implement full Mahjong tile model, grid layout system and basic rule engine.

• Build tile classes + identifiers
• Generate full shuffled set
• Encode adjacency/removal rules

Functional Output: A fully generated logical board with rule-validated removable tiles.

Phase 2: GUI foundation and interactive board rendering

Create the visual interface and map the tile model to clickable UI elements.

• Draw layered tiles with depth
• Highlight valid moves
• Handle selection states

Functional Output: A functional GUI showing the board with interactive tile selection.

Phase 3: Tile removal mechanics and game progression

Integrate logic + GUI to support full turn cycles and remove matched tiles.

• Detect legal matching pairs
• Animate removals
• Update board state

Functional Output: Tiles can be matched and removed correctly, updating the GUI and logic.

Phase 4: Game states, scoring, timers and win/loss conditions

Implement scoring, hints, timers and end-state detection for complete gameplay flow.

• Track score combos
• Provide hint logic
• Detect no-move/empty board

Functional Output: Game rounds progress with scoring, hints and consistent win/loss evaluation.

Phase 5: Save/load system, settings and persistent profiles

Add persistence for progress, user preferences and resume functionality.

• Store board snapshots
• Save settings/profile
• Load saved sessions

Functional Output: Game state can be saved, restored and configured across sessions.

Phase 6: Advanced features, solver module and polish

Implement auto-solver, undo/redo, animations and full stability testing.

• Build solver to find optimal paths
• Add undo stack
• Refine animations/UI

Functional Output: A polished, stable Mahjong app with solver, undo/redo and smooth interactions.

Backgammon

Phase 1: Board model, dice logic and rule foundation

Implement full board representation, checker distribution, dice rolling and basic movement rules.

• Represent points, bar, bear-off
• Validate legal moves
• Generate dice outcomes

Functional Output: A complete logical board with rule-checked movable pieces.

Phase 2: GUI foundation and interactive board rendering

Create an interface that correctly visualizes the board, checkers, dice and selectable moves.

• Render points + stacked pieces
• Display dice results
• Highlight legal moves

Functional Output: A functional GUI where pieces and legal moves appear interactively.

Phase 3: Human move execution and turn system

Link GUI actions to validated movement logic, including turn changes and multi-step moves.

• Drag/click to move
• Enforce all movement rules
• Update states across turns

Functional Output: Players can complete full turns with accurate rule enforcement.

Phase 4: AI opponent with random but valid decisions

Add a CPU player performing rule-compliant moves based on random selection among legal options.

• Generate legal AI moves
• Pick randomly
• Execute correctly

Functional Output: AI performs full valid turns without breaking game constraints.

Phase 5: Game flow, scoring, matches and persistence

Implement match structure, win detection, doubling cube logic (optional) and save/load support.

• Track game/match results
• Detect win states
• Store+restore sessions

Functional Output: Games and matches progress with persistent states and correct win evaluation.

Phase 6: Advanced features, undo/redo, hints and polish

Add usability and robustness enhancements, animations and extended logic checks.

• Provide legal move hints
• Implement undo/redo
• Refine visuals/feedback

Functional Output: A stable, polished backgammon app supporting hints, undo and smooth interactions.

Catan

Phase 1: Board generation, tiles, numbers and resource model

Build hex-grid map, resource tiles, number tokens and probability logic.

• Generate randomized valid layout
• Represent resources, ports
• Assign number tokens

Functional Output: A complete logical board with all tiles, resources and numbers correctly placed.

Phase 2: GUI foundation and interactive map rendering

Create full visual board, clickable hexes, nodes and edges.

• Render hex tiles
• Highlight buildable spots
• Display resources/numbers

Functional Output: A functional GUI showing the map with interactive selection areas.

Phase 3: Player setup, resource distribution and turn structure

Implement player initialization, dice rolling, resource collection and turn phases.

• Manage players/hands
• Generate dice results
• Distribute resources

Functional Output: Players receive correct resources each turn and complete full phase cycles.

Phase 4: Building, roads, settlements, cities and rule enforcement

Integrate construction logic with GUI, including placement restrictions and adjacency rules.

• Validate building locations
• Track longest road
• Update resource costs

Functional Output: Players can legally build and upgrade structures with correct rule checks.

Phase 5: Trading, robber mechanics and development cards

Add full trading, robber movement and development card system.

• Implement bank/player trades
• Enforce robber placement
• Execute card effects

Functional Output: Trading flows correctly, robber actions work, and card effects execute reliably.

Phase 6: Victory points, AI opponent, saving and polish

Add scoring logic, an AI with simple heuristics, persistence and UI improvements.

• Track victory points
• Implement basic AI
• Save/load sessions

Functional Output: Matches progress to victory with functioning AI, persistent states and smooth interface.

SVG-to-PNG Renderer

Phase 1: XML parsing, DOM normalization and attribute extraction

Implement robust SVG parsing and internal object model.

• Parse XML structure
• Normalize coordinates/units
• Extract shared attributes

Functional Output: Parsed SVG converted into a validated internal scene graph.

Phase 2: Rendering engine architecture and raster buffer setup

Design pixel buffer, coordinate system, color handling and drawing primitives.

• Allocate raster buffer
• Implement transforms
• Manage stroke/fill logic

Functional Output: Engine capable of drawing simple primitives onto a raw pixel buffer.

Phase 3: Rectangle, Circle and Ellipse rendering

Add full geometric rasterization for basic shapes with fill + stroke.

• Implement rectangle raster
• Implement circle/ellipse raster
• Respect opacity, stroke width

Functional Output: All three shapes correctly rendered to PNG with accurate geometry.

Phase 4: Line and Polyline rendering

Implement consistent line drawing with joins, caps and polyline sequencing.

• Add line rasterization
• Add polyline vertex iteration
• Handle stroke styles

Functional Output: Lines and polylines rendered with correct thickness and vertex connectivity.

Phase 5: Path parsing and rendering

Support complex Bézier curves, arcs and path commands.

• Parse all path commands
• Approximate curves
• Render filled/stroked paths

Functional Output: Arbitrary paths drawn correctly, including curves and closed regions.

Phase 6: Advanced features, PNG export and validation toolkit

Add transformations, clipping, layered rendering and export pipeline.

• Apply transforms per element
• Implement clipping regions
• Encode PNG file

Functional Output: Complete SVG scenes rendered to correct PNG output with full tested pipeline.

Connect Four

Phase 1: Board model, rule engine and configuration system

Implement dynamic board sizing, gravity-based placement and win detection.

• Generate variable-size grid
• Validate moves
• Detect horizontal/vertical/diagonal wins

Functional Output: Fully functioning logic engine with configurable dimensions and correct win evaluation.

Phase 2: GUI foundation and interactive board rendering

Build clickable visual grid, piece placement feedback and configuration dialog.

• Render dynamic grid
• Animate piece drops
• Provide setup options

Functional Output: Game board displayed interactively with correct visual responses to user actions.

Phase 3: Human-vs-Human gameplay flow

Integrate engine + GUI to support full turn cycles and legal piece placement between two players.

• Enforce turn order
• Block illegal columns
• Update game state

Functional Output: Two-player matches run correctly with alternating turns and win detection.

Phase 4: Basic AI (weak level) and AI integration

Add a CPU player selecting random legal moves and integrate it into turn structure.

• Generate legal moves
• Pick randomly
• Execute reliably

Functional Output: Weak AI completes full turns and interacts correctly with human input and GUI.

Phase 5: Intermediate and advanced AI (heuristics + minimax)

Implement heuristic evaluation, depth-limited minimax and pruning for strong play.

• Build heuristic scoring
• Implement minimax
• Add alpha-beta pruning

Functional Output: Medium and advanced AI levels play with progressively stronger, optimized strategies.

Phase 6: Game settings, persistence, undo/redo and polish

Add saving, loading, undo stack, statistics and UI refinements.

• Store sessions/results
• Implement undo/redo
• Add visual/UX improvements

Functional Output: Configurable, persistent, polished app supporting all AI levels and enhanced usability features.

TrapTheMouse

Phase 1: Board generation, obstacle placement and rule engine

Implement hex-grid logic, random obstacle generation and movement rules for both sides.

• Generate hex board
• Place obstacles
• Validate legal moves

Functional Output: Fully initialized board with correct movement and obstacle rules.

Phase 2: GUI foundation and interactive board rendering

Create a visual representation of the grid, obstacles and mouse/player positions.

• Render hex cells
• Highlight selectable cells
• Display movement previews

Functional Output: Fully interactive board that reflects real-time selections and states.

Phase 3: Human-vs-Human gameplay loop

Integrate movement logic and GUI to support full alternating turns between two players.

• Enforce turns
• Prevent illegal moves
• Track win/loss states

Functional Output: Two-player matches run consistently with proper rule enforcement and end-state detection.

Phase 4: Basic AI (weak level) and AI integration

Add CPU logic based on random or greedy legal moves and integrate into turn flow.

• Generate legal CPU options
• Pick simple moves
• Execute correctly

Functional Output: Weak AI completes turns, interacts with GUI and respects movement constraints.

Phase 5: Intermediate and advanced AI (pathfinding + heuristics)

Implement BFS/A*, heuristic evaluation and escape-prevention strategies for strong AI levels.

• Compute optimal paths
• Evaluate trap potential
• Select best-ranked moves

Functional Output: Medium and advanced AI choose increasingly strategic moves that meaningfully challenge the player.

Phase 6: Game configuration, persistence, undo/redo and polish

Add difficulty selection, board-size presets, session saving, undo stack and UI refinements.

• Store/load sessions
• Support undo/redo
• Improve visuals

Functional Output: A configurable, polished, persistent application with multiple AI levels and enhanced usability.

BubbleBuster

Phase 1: Board model, bubble generation and collision rules

Implement grid logic, bubble colors, adjacency detection and popping rules.

• Create grid model
• Generate bubble layouts
• Detect connected groups

Functional Output: Fully validated board where bubble groups and pop conditions are correctly identified.

Phase 2: GUI foundation and interactive rendering

Build visual grid, bubble sprites, animations and user interaction zones.

• Render colored bubbles
• Highlight hovered cells
• Animate pops

Functional Output: Interactive GUI accurately reflecting the board and responding to user actions.

Phase 3: Bubble popping mechanics and gravity/shift logic

Integrate pop logic, apply gravity and horizontal shifts for floating clusters.

• Remove connected groups
• Drop upper bubbles
• Handle floating detachments

Functional Output: Board updates correctly after each pop with consistent gravity and cluster behavior.

Phase 4: Level system, scoring and progression

Implement level loading, difficulty escalation and point system.

• Load predefined/random levels
• Track scores
• Increase difficulty

Functional Output: Players progress through levels with proper scoring, difficulty scaling and state transitions.

Phase 5: Advanced mechanics (special bubbles, blockers, power-ups)

Add enhanced gameplay items affecting popping or board structure.

• Implement blockers
• Add power-ups
• Integrate rule exceptions

Functional Output: Special elements behave correctly, influencing gameplay and testing advanced logic paths.

Phase 6: Persistence, undo/redo, settings and polish

Add saving, loading, game statistics, settings and visual refinements.

• Store sessions
• Implement undo/redo
• Improve animations/UI

Functional Output: Polished, persistent application with configurable features and stable gameplay.

Projects of type B

1. Grep

Phase 1 — Basic Regex Search in a Single File

Implement core regex search functionality over a single file. Handle standard input/output and basic error cases (missing file, invalid regex).

• Read the file line by line
• Compile and apply regular expression
• Print matching lines with line numbers
• Handle file not found and invalid regex exceptions

Functional result: running grep.py "regex" file.txt displays all lines from file.txt that match the expression.

Phase 2 — Recursive Folder Search & Ignore Case

Extend functionality to search within all files in a folder recursively and to optionally ignore case sensitivity.

• Implement recursive directory traversal
• Process all text files found
• Add -ignoreCase option (compile regex with re.IGNORECASE)
• Display file name before each matching result

Functional result: running grep.py "test" C:\MyFolder -ignoreCase lists all files and lines (case-insensitive) matching the pattern.

Phase 3 — NOT and COUNT Options

Introduce advanced filtering and counting capabilities. Allow users to exclude matches or count their occurrences.

• Implement -not option (show lines/files not matching the regex)
• Implement -count option (show match count per file)
• Combine with previous options (case-insensitive, recursive)

Functional result: running grep.py "pattern" folder -ignoreCase -count -not correctly counts and reports non-matching files or lines.

Phase 4 — Argument Parsing, Robustness & Reporting

Finalize the utility by improving usability, modularity, and reporting. Add CLI argument parsing, formatted output, and proper documentation.

• Use argparse for command-line options
• Support multiple files/folders as input
• Add colored or formatted console output
• Log errors and performance metrics
• Write README and usage examples

Functional result: running various command combinations yields consistent, user-friendly results with clear error handling and documentation.

Sudoku

Phase 1 — Sudoku Core Data & Validation

Implement the immutable puzzle backbone with strict rule checks. Keep logic UI-agnostic and testable. Provide safe setters that reject illegal digits and preserve givens. Establish clear errors and predicates for row/column/subgrid validity.

• 9×9 grid structure with None for empties
• Row/column/3×3 subgrid validators
• Safe set_cell(row, col, digit) enforcing constraints
• Immutable “givens” tracking
• Unit tests for validators and setters

Functional result: invalid placements are rejected; valid placements succeed; validators return expected booleans on curated test cases.

Phase 2 — Puzzle Loading, Givens & Solved Check

Add puzzle I/O and state predicates. Load predefined puzzles (embedded list/CSV), mark givens read-only, and detect solved state. Include consistency checks that verify the puzzle’s starting legality before play.

• Loader for puzzles (string/CSV → grid)
• Givens detection and protection
• is_solved() verifying full, valid grid
• Start-state consistency validator
• Tests for loader, givens, solved predicate

Functional result: loading a sample puzzle locks givens; a known solved grid returns True on is_solved(); illegal start states raise clear errors.

Phase 3 — Minimal Tkinter GUI & Interaction

Render the board and enable basic play without helpers. Support cell selection, digit entry (1–9), backspace to clear, and live conflict highlighting. Keep rendering responsive and decoupled from core logic.

• Tkinter window with 9×9 drawing
• Mouse selection + keyboard input (1–9, clear)
• Highlight row/column/subgrid conflicts
• Read-only givens styling
• Graceful error messages on invalid input

Functional result: user selects cells, types digits, conflicts highlight immediately, and givens cannot be edited.

Phase 4 — Countdown & End Conditions

Add a visible countdown timer controlling game end. Show modal dialogs when time expires or the puzzle is solved. Allow quick restart of the current puzzle; no extra helpers or analytics.

• Countdown display (mm:ss), one-second ticks
• Start/pause/stop tied to game state
• Win detection → “You won” dialog
• Timeout → “Time’s up” dialog
• Restart current puzzle action

Functional result: timer decreases; solving triggers win dialog; zero time triggers timeout dialog; restart resets grid and timer.

Memo

Phase 1 — Data model & SQLite

Define minimal schema and data access for text notes and checklist notes. Keep logic simple, UI-agnostic, and deterministic.

• Tables: notes, checklist_items
• CRUD functions
• Foreign keys for checklist items
• Simple input validation (non-empty titles)

Functional result: database initializes and basic create/read/update/delete work for both note types across app restarts.

Phase 2 — Minimal GUI: text notes

Create a Tkinter window with a notes list and an editor pane for plain text notes.

• List of notes (titles)
• New note, select note
• Text editor area
• Save action to SQLite

Functional result: user can create a text note, edit its content, save it, close the app, reopen, and see the note persisted.

Phase 3 — Checklist notes GUI

Add checklist editing UI: add/remove items and toggle checked state.

• Note type: checklist
• Add item, remove item
• Toggle checked/unchecked
• Persist items order and state

Functional result: user can create a checklist note, manage items, save, close, reopen, and find the checklist exactly as last saved.

Phase 4 — Finish & robustness

Stabilize flows and error handling without expanding scope.

• Basic exception handling
• Delete note + cascade items
• UI refresh after DB operations
• Minimal field validation

Functional result: common errors show clear messages; saves don’t corrupt data; simple delete works for notes and their items, with UI reflecting changes immediately.

Partition Statistics

Phase 1 — Traversal & Raw Metrics

• Parse CLI: analize_partition.py <drive_letter> (e.g., D)
• Recursively walk through all directories and files on the specified partition
• Count total directories and total files
• Record file extensions (case-insensitive), using <no-ext> for files without extensions
• Accumulate totals per extension: number of files and combined size in bytes

Functional result: Running the script on a test folder prints total directories/files and a raw list of file extensions with their respective counts and sizes.

Phase 2 — Data Aggregation & Proportions

• Convert tallies into relative proportions for both file count and total size
• Sort results by descending frequency and by descending total size
• Combine minor categories into an Other bucket for readability
• Format output with rounded percentages (two decimals)

Functional result: Console output clearly shows each file type’s percentage of total count and total size, with an additional Other category if many small file types exist.

Phase 3 — Chart Generation

• Generate visual charts (using Matplotlib or a similar library)for easier interpretation:

  • Pie chart for file type distribution by count
  • Pie chart for file type distribution by total size
  • Bar chart for top-N file types by count
  • Bar chart for top-N file types by size

• Include titles, legends, and percentage/value labels

• Display charts interactively and save them as PNGs in a charts/ folder and

Functional result: The program produces four correctly labeled charts (and PNG files) showing file-type distribution and relative proportions based on the analyzed data.

Phase 4 — Error Handling & Validation

• Validate command-line arguments and drive existence before scanning
• Gracefully handle permission errors (skip restricted paths)
• Manage long paths and unreadable directories without interruption
• Handle non-UTF8 filenames by falling back to safe encodings

Functional result: The program runs smoothly even with missing permissions, long paths, or encoding issues, skipping problematic files while completing the analysis and generating valid output.

Password Manager

Phase 1 — Vault basics & crypto setup

• Create a single vault file pwmanager.db (SQLite) with a single table: website, username, encrypted_password, created_at, updated_at.
• Derive an encryption key from <master_password> using a secure KDF with a stored random salt.
• Encrypt/decrypt the password field using an authenticated cipher (e.g., AES-GCM or equivalent).

Functional result: First run creates the vault; adding one sample entry and reading it back (with the same master) returns the original plaintext password.

Phase 2 — CLI & core operations

• Parse: pwmanager.py <master_password> -add <website> <username> <password>, -get <website>, -remove <website>, -list.
• -add inserts or updates the site entry; -get prints username + decrypted password; -remove deletes the site; -list prints website + username only.
• Update created_at on first insert and updated_at on changes.

Functional result: Running the four sample commands creates an entry, retrieves it in plaintext, lists sites without passwords, and removes the entry exactly as specified.

Phase 3 — Master verification & data consistency

• On startup, verify the master password by attempting a controlled decryption (e.g., a canary/known record); abort if it fails.
• Enforce one entry per website (unique constraint) so -add behaves as upsert.
• Keep timestamps consistent and store data as UTF-8.

Functional result: Supplying a wrong master cleanly stops any operation; re-adding an existing site updates its password and timestamp while preserving a single row per site.

Phase 4 — Light UX & Error handling

• Default vault location is the current directory; create it on first use.
• Display simple, readable console messages for each operation.
• Minimal error handling: show a concise usage hint on bad/missing args and a clear message on failed decryption (wrong master/corrupt entry).

Functional result: Typical mistakes (missing args or wrong master) produce short, clear messages without corrupting the vault; valid commands complete and persist correctly.

Battleships

Phase 1 — Core model & rules

Implement a UI-agnostic Battleships model with a fixed-size ship per player. Validate placement, record shots, and detect hits/misses/sunk. Keep turn-neutral logic and simple helpers for board state inspection.

• Grid representation and coordinates
• Single fixed-length ship placement validation
• Track shots; prevent duplicate targeting
• Hit/miss and “sunk” detection helpers

Functional result: A tiny script can place ships for both players, apply shots, and correctly report hit/miss/sunk without any GUI.

Phase 2 — GUI scaffolding & ship placement

Create a Tkinter window with two concealed boards (Player A/B). Guide sequential ship placement with click-and-drag or click+orientation. Provide a simple “Hide screen / Next player” prompt between players to preserve secrecy.

• Tkinter window with two 10×10 grids
• Interactive fixed-length ship placement
• Orientation toggle (horizontal/vertical)
• “Next player” screen to conceal boards

Functional result: Users can place their ships in turn; grids render correctly, placements respect bounds/overlap rules, and boards stay hidden between players.

Phase 3 — Turn-based firing & feedback

Enable alternating turns to fire at the opponent’s grid via mouse clicks. Show immediate visual feedback for hit/miss, disallow firing the same cell twice, and update a concise status area indicating whose turn it is.

• Turn manager (A↔B)
• Click-to-fire on opponent grid
• Mark and lock fired cells (hit/miss)
• Status label for current turn

Functional result: Players alternate firing; hits and misses are marked reliably; duplicate shots are blocked; turn indicator updates correctly.

Phase 4 — Win condition & minimal polish

Stop the game when a ship is fully sunk and show a winner dialog with options to restart or quit.

• Sunk detection triggers end-of-game dialog
• Restart current match (clear boards/state)
• Minimal input validation and safe UI updates

Functional result: Sinking the opponent’s ship ends the match with a clear winner message; pressing restart resets the boards and allows a fresh game.

Currency Converter

Phase 1 — Rate source & normalization

• Fetch daily official FX from BNR (RSS/XML) and parse safely
• Normalize to an internal map {currency: RON_per_unit} and store the fetch timestamp
• Persist a tiny local cache (e.g., JSON) to reuse the latest successful rates

Functional result: After one fetch, rates exist locally (including RON) with a timestamp; re-running can load from cache if no network.

Phase 2 — Conversion engine

• Implement the conversion function using RON as the pivot
• Support all currencies published by BNR plus RON; round outputs to 4 decimals
• Guard against missing currencies and zero/negative amounts

Functional result: Given an amount and two currencies, the function returns a correct numeric result using the latest rates.

Phase 3 — GUI (Tkinter)

• Main window with: amount entry, “From” and “To” dropdowns, “Convert” button, result label
• Include a “Refresh rates” button; Display “Last update: ”
• Keep UI responsive while fetching

Functional result: User selects amount/currencies, clicks Convert, and sees an accurate result; Refresh updates rates and the timestamp without freezing the UI.

Phase 4 — Auto-update & minimal errors

• Auto-fetch on startup and once/day (or on app open if cache is older than 24h)
• Minimal errors only: if network fails, fall back to cached rates with a clear banner; reject non-numeric amounts politely

Functional result: With internet, the app auto-updates and converts; offline, it uses cached rates and still converts, warning the user about stale data.

GUI News Feed

Phase 1 — Source adapters & fetching

• Implement 4+ adapters (e.g., Reddit, BBC RSS, Google News RSS, Hacker News)
• Query by topic, request with timeouts, and parse RSS/JSON
• Normalize common fields like title, source, url or published_at
• Create a simple CLI to test adapters

Functional result: A test run fetches N recent items per source for a topic and prints normalized entries with correct fields.

Phase 2 — Merge, sort & de-dup

• Merge adapter results into one list
• De-duplicate by canonicalized URL/title fingerprint
• Sort the results (most recent first)
• Optional tiny in-memory cache (TTL) to avoid refetch storms

Functional result: A single merged feed shows unique, newest-first items that match the topic across all sources.

Phase 3 — GUI browsing (Tkinter)

• Topic entry + “Refresh” button
• Paginated (or scrollable) list of headlines with source and time
• Detail pane with summary and “Open in browser” action
• Non-blocking fetch (thread/async) with a busy indicator

Functional result: User searches a topic; the UI refreshes without freezing and displays clickable, de-duplicated articles from all sources.

Phase 4 — Auto-refresh & minimal errors

• Optional auto-refresh interval (e.g., 5–15 min) with “Last update” status
• Brief error banner on fetch failure; keep last good results

Functional result: The app periodically refreshes when enabled, shows the last update time, and gracefully warns on failures while remaining usable.

Razboi

Phase 1 — Core deck, rules & round logic

• Standard 52-card deck, shuffle, split evenly (Player vs CPU)
• Battle loop: each side draws top card; higher rank wins the stack
• “War” tie resolution (3 face-down + 1 face-up; configurable if short)
• Score = total cards owned; model is UI-agnostic

Functional result: A small script can simulate rounds, including wars, transferring won stacks and updating both piles until one player owns all cards or decks are exhausted.

Phase 2 — Minimal GUI: layout & basic play

• Tkinter window: two card placeholders (Player/CPU), “Play” button, score labels
• On click: draw, reveal both cards, update scores/stack owner
• Disable button while resolving a round; simple text render for cards (e.g., “K♠”)
• Deck counts displayed per player

Functional result: Clicking “Play” reveals two cards side by side, awards the stack to the winner, updates scores and deck counters, and keeps the interface responsive.

Phase 3 — War visualization & round flow

• When tie: stepwise war sequence (face-down placeholders, then face-up reveal)
• Brief timed transitions or a “Next” button to advance steps
• Accumulate the pot correctly across chained wars
• End-of-game detection (one player out of cards)

Functional result: Ties trigger a visible war sequence; the pot grows and is awarded properly; chained wars resolve correctly; the UI indicates when the game ends.

Phase 4 — Finish: restart & light safeguards

• “Restart” resets decks, scores, and UI; new shuffle each time
• Minimal safeguards: prevent double-click during animations; handle short decks in war by using whatever cards remain

Functional result: Users can restart a fresh match; clicking during resolution is safely ignored; edge cases (insufficient cards during war) are handled without crashes.

Game of 2048

Phase 1 — Core grid, rules & scoring

• 4×4 board, slide/merge logic (left/right/up/down)
• Spawn logic (A new 2 or 4 with configurable odds, e.g. 80% chance of spawning a 2, 20% chance of spawning a 4)
• Deterministic update order; single-move application
• Score tracking; win (tile 2048) and lose detection

Functional result: A small script runs a playable loop in the console: moves apply correctly, tiles spawn, score updates, and win/lose states are detected.

Phase 2 — Opponent types & CLI

• CLI: 2048.py <opponent_type> via argparse
• Opponent interface: choose_spawn(board) -> (row, col ,val)
• Implement random and adversarial (choose worst legal spawn)

  • Random opponent: picks an empty cell at random and places a tile (2 or 4) using the spawn logic (like the normal 2048 game)

  • Adversarial opponent: tries to make the game harder; chooses the empty cell that will create the worst possible situation for the player

• Optional --seed for reproducible behavior; validate type

Functional result: Running with random or adversarial changes difficulty; invalid types fall back to random; repeated runs with the same seed behave identically.

Phase 3 — GUI (Tkinter) gameplay

• Window with 4×4 grid, colored tiles, score label
• Keyboard input (arrows/WASD) driving moves
• After each move: spawn via selected opponent, update UI
• End-of-game modal when 2048 reached or no moves left

Functional result: Launching 2048.py random opens a responsive board where keys move tiles, score updates live, and a clear dialog appears on win/lose.

Phase 4 — Minimal UX polish

• “New Game” button (reseed + clear board/score)
• Simple animation timing (after) for slide/merge feel
• Lightweight guardrails: ignore input during animation; cap FPS

Functional result: Players can restart instantly; moves feel smooth without jank; rapid key presses don’t break state, and overall play remains stable.

Tic Tac Toe

Phase 1 — Core board & rules

• 3×3 board model with players X and O, current-turn tracking
• Move application with legality checks (empty cell only)
• Win/draw detection (rows, columns, diagonals)
• Text rendering helper for multi-line board display

Functional result: A small script can play in the console by applying legal moves, printing the board, and correctly reporting win or draw.

Phase 2 — GUI (Tkinter) interaction

• Window with a 3×3 clickable grid; highlight current player
• Click-to-place for the human; ignore clicks on occupied cells
• Status bar: turn info, end-of-game message
• “Play again” button that resets the board

Functional result: User clicks a square to place their symbol, the board updates live, and an end message appears on win/draw with a working reset.

Phase 3 — AI engines & difficulties

• AI “random”: choose uniformly among empty cells
• AI “best”: optimal move via minimax (or equivalent), with simple tie-breaks
• Difficulty selector:
  1. always random
  2. alternate random & best
  3. always best

Functional result: Selecting each difficulty changes AI behavior as specified; best-play AI never loses, alternating mode visibly switches strength every AI turn.

Phase 4 — Match flow & scoring

• Track cumulative score across rounds: wins for X, wins for O, draws
• After each game: show winner/draw and ask to play again
• Scoreboard visible and updated after every match

Functional result: Finishing a game updates the running score and prompts for a new round; repeated matches correctly accumulate and display totals.

Process Manager

Phase 1 — Process listing (view)

• Implement process.py view to enumerate all running processes
• Display: PID, name, executable path (best-effort), command line
• Cross-platform via psutil (fallbacks if some fields missing)
• Tabular console output with wide-column truncation

Functional result: Running process.py view prints a table of all processes with PID, Name, Path (and cmdline where available).

Phase 2 — Start/Stop

• process.py run <path> [args…] starts a new process (non-blocking) and prints its PID
• process.py kill <PID> terminates the target process (use graceful terminate, then kill if needed)
• Return exit codes reflecting success/failure
• Optional working directory parameter (e.g., --cwd)

Functional result: A program can be launched and its new PID shown; kill stops the specified PID and reports success.

Phase 3 — Suspend/Resume

• process.py suspend <PID> pauses the process (psutil suspend or POSIX SIGSTOP)
• process.py resume <PID> resumes the process (psutil resume or POSIX SIGCONT)
• Validate that the target PID exists and is not already in the requested state
• Print short confirmations

Functional result: Suspending a PID halts it; resuming continues it; repeated commands are ignored with a brief notice.

Phase 4 — Live metrics & CLI

• Extend view to include CPU% and memory usage (RSS/MB); compute CPU% with a short sampling window
• Sorting options: --sort cpu|mem|pid and --desc
• Minimal errors only: concise message for “PID not found” or “insufficient permission”
• Implement argparse subcommands (including a helpful -h)

Functional result: process.py view --sort cpu --desc shows processes ordered by current CPU%; invalid PIDs yield a short, clear message while valid operations succeed.

Movie Ranker

Phase 1 — Server & local database

• Create a server with /search?title, /search?actor, /movie/<id> endpoints
• Create a SQLite database storing movies, actors, ratings, trailers, reviews
• Aggregates the ratings from various sources to 0–5 and 0–100 scales

Functional result: Running the server and calling /search?title=Inception returns a normalized JSON movie object with aggregated scores (both 0–5 and 0–100) or empty arrays if not yet known (stored in the database).

Phase 2 — External fetch & caching

• Create adapters (at least 3) for IMDb, RottenTomatoes, TMDB, YouTube or other similar platforms
• If the title is not stored: fetch data, normalize, and save to DB
• Fetch short review snippets + links where available

Functional result: Unknown titles trigger live fetch, store, and return combined ratings, trailers, and reviews.

Phase 3 — Client GUI (Tkinter)

• Search by title or actor
• Display results list, rating details, trailers, and reviews
• Open trailer links in browser

Functional result: The user searches by title or actor, sees a list of results, selects one, and the UI shows scores from multiple sites, trailers, and reviews; links open correctly.

Phase 4 — Refresh & minimal errors

• “Refresh data” button to re-fetch from external sources
• Minimal errors only: brief banner if an external source fails; partial results still displayed

Functional result: Selecting a movie and pressing Refresh re-pulls external data and updates aggregated scores.

Generate structure

Create a Python command-line tool that reads a JSON description of a directory and file hierarchy and creates that structure on disk. Each key in the JSON corresponds to a directory or file name: if the value is another dictionary, it’s treated as a subdirectory; if it’s a string, it becomes the file’s content. The tool supports validation, dry-run previews, overwrite policies, and atomic file creation.

Phase 1 — CLI & JSON loading

• Command: create_structure.py <root_folder_path> <structure_json_file_path>
• Read JSON (UTF-8) into an in-memory dict
• Create <root_folder_path> if missing

Functional result: Script loads the dictionary and ensures the root folder exists.

Phase 2 — Structure validation

• Accept only dict→directory, string→file-content
• Disallow path separators and empty names in keys
• Reject unsupported types with a concise error

Functional result: Valid structures pass; invalid ones stop with a short, clear message.

Phase 3 — Recursive creation

• Depth-first create directories
• For file entries, write content (UTF-8)
• Overwrite only files that correspond to file keys

Functional result: The filesystem mirrors the JSON: directories and files are created with expected contents.

Phase 4 — Dry-run, conflict policy

• --dry-run previews planned actions without touching disk
• --mode {fail,skip,overwrite} defines behavior for existing paths
  • fail – stops immediately if a file or folder already exists, ensuring nothing is overwritten.
  • skip – leaves existing files or folders untouched and continues creating the rest of the structure.
  • overwrite – replaces existing files with new content (eventually using atomic writes for safety).

Functional result: Users can preview changes; re-runs behave predictably per mode; file updates are atomic, avoiding partial writes.

GUI Fact of The Day

Phase 1 — Source adapters & normalization

• Implement ≥4 adapters (e.g., domain-specific RSS/JSON sites)
• Query by user-defined domain (astronomy, biology, etc.)
• Normalize common fields, such as title, description, url, image_url, published_at, source
• Add short request timeouts

Functional result: A test run fetches recent items for chosen domains from ≥4 sources and prints normalized entries.

Phase 2 — Aggregation & interval fetch

• Merge results per domain; remove duplicates (URL/title key)
• Sort newest-first; cap items per domain
• Interval scheduler (e.g., every 15 min) triggers background fetch
• Keep a small in-memory cache to avoid rapid refetch

Functional result: On a timer, new items are aggregated, de-duplicated, and ready for display without blocking the app.

Phase 3 — GUI (Tkinter) feed viewer

• Domain selector, interval control (15/30/60), “Refresh now”
• Scrollable list of cards: title, source, time, description, optional image
• Click to open article in browser
• Non-blocking data fetch in background

Functional result: User selects domains and sees clickable, up-to-date cards with titles, descriptions, and images where available.

Phase 4 — Auto-refresh UX & Error handling

• Auto-update feeds at the chosen interval
• Display the “Last update” time
• Brief banner on fetch failure; keep last good results
• Lightweight preferences (domains, interval) saved to a small config

Functional result: Feeds update on schedule, the timestamp reflects updates, errors show briefly while prior results remain visible across restarts.

Scrabble

Phase 1 — Dictionary & Core Model

• CLI: scrabble.py <dictionary_path> loads a word list into memory
• Board model (15×15), rack (7 tiles), tile bag with letter counts and scores
• Draw tiles to racks; basic placement grid (no scoring yet)

Functional result: The game starts with a populated tile bag, two 7-tile racks, and a blank 15×15 board using the provided dictionary.

Phase 2 — Placement Rules & Scoring

• Validate moves: contiguous line, board connectivity, dictionary check for all formed words
• Premium squares (DL/TL/DW/TW - Double Letter, Triple Letter, Double Word, Triple Word) and first-move center rule
• Compute and return move score; refill rack after valid move

Functional result: Legal placements are accepted and scored correctly (including premiums); illegal moves are rejected with a brief message.

Phase 3 — GUI Play Surface (Tkinter)

• Render board with premiums, player rack, and a minimal controls bar (Place, Recall, Submit, Pass, Swap)
• Mouse: click-to-select tile from rack, then board cell; Recall returns tiles to rack
• Score panel showing per-player totals and last move score

Functional result: A user can place tiles from the rack onto the board, submit a move, see the score update, and tiles refill visually.

Phase 4 — Turn Flow & Endgame

• Two local players alternating turns (Pass, Swap consume a turn)
• End when tile bag is empty and a rack is emptied, or after two consecutive passes
• Final tally (subtract remaining rack points), winner dialog, “Play again” resets state

Functional result: A full match runs to completion with correct turn alternation and endgame scoring; the winner is announced and a new game can be started.

Expense Tracker

A desktop app to record expenses, group them by category (e.g., groceries, transport, utilities), and visualize monthly totals with charts. Data persists locally so users can review past months and export their records.

Phase 1 — Data model & persistence

• SQLite schema: expenses and categories
• CRUD functions for expenses
• Simple validation (positive amount, valid date/category)

Functional result: The database initializes; adding/listing/updating/deleting sample expenses works and persists across app restarts.

Phase 2 — GUI (Tkinter)

• Window with expense form (date, amount, category, note)
• Table view of expenses with pagination/scroll
• Filters: by month and category
• Edit/delete selected expense; running totals for filtered view

Functional result: User can add/edit/delete expenses and see a filtered, running monthly total in the table.

Phase 3 — Reports & charts

• Monthly summary: total and per-category breakdown
• Charts: pie (share by category) and bar (amount by category)
• Click category to highlight corresponding rows in the table

Functional result: Selecting a month shows accurate totals and renders pie/bar charts reflecting the filtered data.

Phase 4 — Export & Error handling

• Export current filtered data to CSV (filename with month stamp)
• Error handling: concise messages for invalid input or failed export

Functional result: Users export the month’s expenses to CSV format

Guess the Number

A simple client-server game where the server generates a random number between 0 and 500, and the client tries to guess it. After each guess, the server sends feedback. Each execution represents a full game session containing multiple rounds. The best score (fewest guesses needed to find the number) is shown at the end of the session.

Phase 1 — Game logic & communication protocol

• The server and client communicate through a text-based protocol (line-oriented).

  • Client → Server messages:

    • START → begins a new round (server generates a new random number in [0, 500])
    • GUESS <number> → the player’s attempt to guess the secret number

  • Server → Client responses:

    • TOO_LOW → the guessed number is smaller than the secret number
    • TOO_HIGH → the guessed number is larger than the secret number
    • CORRECT <attempts> <best> → the number was guessed; includes current attempts and best score in this session

• Game model: each round tracks the secret number, current number of guesses, and session-best (minimum attempts across rounds).

• Input validation: guesses must be integers between 0 and 500; invalid inputs receive a short ERROR Invalid input response.

Functional result: The logic module can simulate a complete guessing game locally, producing correct feedback messages (TOO_LOW, TOO_HIGH, CORRECT) and tracking the best score across multiple rounds.

Phase 2 — Server implementation

• server.py listens on a TCP socket.

• On client connection: start a new session and wait for START commands.

• For each round:

  • Generate a random secret number.
  • Handle GUESS messages and respond with appropriate feedback.
  • When the player guesses correctly, update and return the best score so far.

• Support multiple sequential rounds in the same session.

Functional result: A connected client can play multiple rounds in one session; the server correctly responds with feedback and maintains the best score.

Phase 3 — Client interaction (CLI)

• client.py connects to the server, sends START, and then repeatedly prompts the user for a number.

• Sends GUESS <number> for each attempt and displays the server’s responses in a user-friendly way:

  • “The number is higher/lower”
  • “Correct! You found it in X attempts. Best: Y attempts.”

• After each correct guess, ask: “Play again? (y/n)” and send START or close connection accordingly.

Functional result: The client provides an interactive command-line experience, letting the player guess numbers, get instant feedback, and choose to play multiple rounds.

Phase 4 — Session summary & Error handling

• When the client quits, the server sends a final message summarizing the session: "Your best score this session: N attempts"
• The server handles invalid commands or out-of-range guesses gracefully with short messages instead of disconnecting.

Functional result: The client displays the final session summary; invalid inputs trigger short warnings.

CLI Karnaugh Minimization

Phase 1 — CLI & Input Parsing

• Implement a command-line interface allowing the user to:

  • Provide a boolean function as a string (sigma(...) / sigma(...)+sigma*(...))
  • Or provide a file containing multiple functions

• Parse the input string(s) and validate syntax:

  • Correct sigma notation
  • Allow for 3–4 variables only

• Display errors clearly if the input is invalid.

Functional result: user can run the program via CLI and provide functions directly or via file. Input validation and errors are clear and informative.

Phase 2 — Truth Table Generation

• Convert parsed functions into a truth table.

• Present the truth table nicely formatted in the console:

  • Columns aligned
  • Coloured output for 0/1 distinction

• Save the truth table to a .txt or .csv file if requested.

Functional result: user sees a visually clear truth table and optionally saves it for reference.

Phase 3 — Karnaugh Map Minimization

• Convert the truth table to a Karnaugh map.
• Perform minimization to produce the simplest boolean expression.
• Derive both FND (DNF) and FNC (CNF) forms.
• Present the minimized forms clearly in the CLI output, highlighting the key terms.

Functional result: the program outputs a readable, concise minimized expression with both CNF/DNF forms.

Phase 4 — Robustness & Enhancements

• Handle multiple functions in a single run.
• Gracefully detect and report conflicting or impossible minterms.
• Allow optional CLI flags for output style: text-only, colored, save to file, etc.

Functional result: users can process multiple functions, see properly formatted truth tables and minimized expressions, and interact easily via CLI.

jGrep

A command-line utility for searching and filtering JSON files, with optional dot-separated path queries.

Phase 1 — Basic JSON Key/Value Search

Implement core functionality: search for specific keys or values in a single JSON file.

• Load a JSON file and validate its structure
• Search for a key or value, printing matching entries with full path (e.g., user.name)
• Handle invalid JSON, missing file, or key not found errors

Functional result: jgrep.py "name" file.json prints all keys or values matching "name" along with their JSON path.

Phase 2 — Recursive Search & Multiple Files

Extend to handle multiple JSON files and folders.

• Traverse directories recursively
• Process .json files only
• Support searching across multiple files
• Optional case-insensitive matching (-ignoreCase)

Functional result: jgrep.py "admin" ./configs -ignoreCase lists all matches across JSON files in the folder tree.

Phase 3 — JSONPath-Style Queries & Filtering

Add lightweight JSONPath-style dot-separated querying and simple filtering.

• Support dot-separated paths for nested access (e.g., user.address.city)
• Allow numeric array indexing (orders.items.0.name)
• Keep it simple — no wildcards, slicing, or complex expressions
• Combine with recursive search and ignore-case options

Functional result: jgrep.py "orders.items.0.product" data/ finds the first product in every order, recursively.

Phase 4 — Counting, Excluding & CLI Polishing

Finalize the tool with filtering options, formatted output, and robust CLI.

• Implement -not option to show non-matching entries
• Implement -count option to count matches per file
• Use argparse to support multiple files/folders and query types
• Format output for clarity (e.g., JSON path + value)
• Add README with usage examples and basic error logging

Functional result: jgrep.py "user.role" ./configs -ignoreCase -count -not counts non-admin roles and reports them clearly.

GitHub Manager

Phase 1 — Repository Initialization

• Implement git_manager.py <repo_url> <local_dir> to clone a repository if it does not exist locally
• Verify the repository exists and is accessible in the given directory
• Ensure that the repository can be opened and basic Git commands work

Functional result: Running the script with a new repository URL clones it locally; existing repository is detected and used.

Phase 2 — File Monitoring

• Detect new or modified files in the local repository compared to the last commit
• List all files that need to be committed or pushed
• Handle basic file types (text and binary) for change detection

Functional result: Running the monitoring phase prints a list of local changes ready for commit.

Phase 3 — Automated Sync

• Pull latest changes from the remote repository at configurable intervals (e.g., every X hours)
• Commit and push local changes automatically if there are updates
• Maintain repository in sync without manual Git commands

Functional result: Local repository updates and pushes automatically; remote changes are pulled successfully.

Phase 4 — Conflict Resolution

• Detect merge conflicts when pushing changes to remote
• Automatically resolve conflicts by keeping local changes and discarding conflicting remote changes
• Print short confirmations for each resolved file

Functional result: Conflicted files are automatically resolved; push completes without errors while preserving local edits.

Web Page Change Tracker

Phase 1 — Add, Remove, and Store Pages

• Implement a command-line interface or a graphical interface to add, delete, and modify tracked web pages
• Store pages in a local database (e.g., SQLite) with URL and last snapshot
• Validate URLs before saving

Functional result: User can manage a list of pages to track; database correctly stores added, deleted, and modified entries.

Phase 2 — Page Retrieval & Snapshot

• Fetch HTML content of each tracked page
• Save initial snapshot in the database
• Handle basic errors (network failures, invalid URLs)

Functional result: Program downloads and stores snapshots of all tracked pages; failed URLs are reported clearly.

Phase 3 — Change Detection

• Compare current page snapshot with the last saved version
• Detect changes recursively in the HTML content (e.g., new text, removed elements)
• Mark which parts of the page have been modified

Functional result: Program identifies when a page has changed and records differences; no false positives for unchanged pages.

Phase 4 — Notifications & Reporting

• Send email notifications to the user when a page has changed
• Include summary of changes in the message

Functional result: User receives email alerts when tracked pages are modified; console or log output lists the detected changes.

GUI FTP Manager

Phase 1 — Connect & Session Management

• Implement GUI login to FTP servers (host, username, password)
• Allow saving credentials as sessions for later reuse
• Validate connection and show success/failure

Functional result: User can connect to an FTP server via GUI and save sessions for future use.

Phase 2 — File Listing & Navigation

• Display files and directories of the connected FTP server in a GUI tree or list
• Support navigating directories and refreshing file view
• Handle empty folders and errors gracefully

Functional result: User can see and navigate the remote directory structure in the GUI.

Phase 3 — File Operations (CRUD)

• Implement upload, download, rename, delete operations
• Update GUI view after operations
• Provide simple progress or status notifications

Functional result: User can manipulate files on the FTP server through the GUI; changes are reflected immediately.

Phase 4 — Error Handling & Persistence

• Handle connection drops, permission errors, invalid paths, and failed operations
• Persist session credentials securely (local encrypted storage or config file)
• Provide concise user feedback for errors or successes

Functional result: Application handles common errors gracefully; saved sessions can reconnect without re-entering credentials.

GUI Kanban Board

Phase 1 — Data model & SQLite

Define minimal schema and data access for tasks in a Kanban board. Keep logic simple, UI-agnostic, and deterministic.

• Table(s) for tasks
• CRUD functions for tasks.
• Simple input validation (non-empty titles).

Functional result: database initializes; tasks can be created, read, updated, deleted; persistence works across app restarts.

Phase 2 — Minimal GUI: task list

• Tkinter window with three columns: "To Do," "In Progress," "Done."
• Add task with title/description and assign to To Do.
• Display tasks in corresponding columns.

Functional result: user can add tasks, see them in columns, close/reopen app, and tasks persist.

Phase 3 — Task management & movement

• Select a task to edit title/description.
• Delete tasks.
• Move tasks between columns via buttons (Move to To Do, Move to In Progress, etc.) or optionally via drag-and-drop.

Functional result: user can edit, delete, and move tasks; GUI updates correctly; all changes persist in SQLite.

Phase 4 — Advanced Features & Usability Enhancements

• Implement filtering of tasks by title or description within a board.
• Implement sorting of tasks by creation date or priority.
• Handle database errors, invalid inputs, and missing boards gracefully.

Functional result: user can filter/search and sort through tasks; all actions persist and errors are clearly reported.

Network Mapper

Phase 1 — Data parsing & IP handling

• Parse a CIDR input (e.g., 192.168.0.0/24) into individual IP addresses.
• Validate input format and ensure only valid IPv4 addresses are accepted.
• Provide a simple function to iterate over IPs in the subnet.

Functional result: user can input a CIDR, and the program generates a list of valid IP addresses for scanning.

Phase 2 — Basic connectivity scanning

• Implement a function to check whether an IP is online (e.g., via a ping or socket attempt).
• Limit checks to a predefined set of common ports or user-specified ports.
• Handle timeouts gracefully to avoid long delays.

Functional result: program identifies which IPs are online and which ports respond, without crashing on unreachable hosts.

Phase 3 — Command-line interface & output formatting

• Accept input from command line: network_mapper.py 192.168.0.0/24 [port1, port2, ...].

• Display results in a readable format, e.g.:

  192.168.0.1:80 (HTTP)
             :443 (HTTPS)
  192.168.0.105:445 (SMB)
  

• Map common ports to service names where possible.

Functional result: user runs the program and receives a clean, readable summary of online hosts and their open ports.

Phase 4 — Robustness & polish

• Handle invalid inputs (bad CIDR, invalid port numbers).
• Implement basic exception handling for network errors.
• Ensure program exits cleanly if interrupted.
• Allow sorting of output by IP or by port, for clarity.
• Make the CLI easy to interact with and visually pleasant, using coloured text output.
• Allow saving the identified IP:port pairs to a .txt file.

Functional result: program is stable, handles edge cases gracefully, and consistently produces correct results for valid inputs.

RESTler (GUI API Client)

Phase 1 — Core request handling

• Implement functions to make HTTP requests with different methods (GET, POST, PUT, DELETE).
• Accept user-defined URL, headers, and payload.
• Handle errors: invalid URLs, timeouts, network failures.

Functional result: user can run requests programmatically, and the function returns the response (status code + body) reliably.

Phase 2 — Minimal GUI

• Tkinter window with input fields for: URL, method, headers, payload.
• Submit button triggers the HTTP request and displays the response.
• Display response status code and body in a scrollable text area.

Functional result: user can enter request parameters, click “Send,” and see the response displayed clearly.

Phase 3 — History feature

• Track all requests made during the session: method, URL, headers, payload, and response.
• Allow user to select a previous request to re-send or view its response.
• Save history to a local file for persistence across sessions.

Functional result: user can view past requests, replay them, and retain history after closing/reopening the app.

Phase 4 — Robustness & polish

• Validate input fields (e.g., URL format, proper JSON payload).
• Handle edge cases (empty headers, large payloads).
• Ensure GUI updates smoothly after each request.

Functional result: program runs reliably; GUI remains responsive; user sees meaningful messages for errors; history updates correctly; input validation prevents crashes.

sitemap.xml Generator

Phase 1 — Core crawling logic

• Implement a function that starts from a given webpage (root URL) and explores other pages linked from it, up to a certain depth (how many links away from the start page you go).
• Keep track of pages already visited so the program doesn’t check the same page twice.
• Check that each URL is valid and handle errors (like missing pages or connection problems) without the program crashing.

Functional result: given a starting webpage and a depth limit, the program produces a list of unique webpages it found within the site, ignoring broken links or repeated pages.

Phase 2 — Domain-limited crawl & metadata

• Restrict crawling to the same domain as the root URL.

• For each page, collect/estimate metadata required for sitemap.xml:

  • loc (the page URL)
  • lastmod (from HTTP Last-Modified header, if available -- if not, use date of crawling)
  • changefreq (estimated using above Last-Modified header; daily if modified under 1 day before, weekly if under 1 week, etc.)
  • priority (calculated based on depth; the deeper the page, the lower the priority)

• Handle errors like timeouts, redirects, and 404 pages.

Functional result: program outputs a structured list of URLs with all required metadata for a valid sitemap, ignoring external domains.

Phase 3 — Sitemap XML generation

• Convert the crawled pages into a valid sitemap.xml format (as per the Sitemaps XML format), using the collected metadata.
• Ensure the XML validates against the standard sitemap schema.
• Write the XML to a file.

Functional result: running the program produces a valid sitemap.xml file with all crawled pages and their metadata.

Phase 4 — Robustness & logging

• Handle network exceptions, invalid URLs, and write permission errors gracefully.
• Ensure crawl queue does not duplicate URLs.
• Log progress to the console or a log file: number of pages crawled, current URL, and any skipped or failed URLs.
• Ensure sitemap generation completes reliably even if some pages fail.

Functional result: sitemap generation completes without crashing, all URLs are processed correctly up to the maximum depth, priority values correspond to depth, and progress is clearly logged during execution.

Flashcard Quiz App

Phase 1 — Database & Core Logic

• Add a basic SQLite schema:

  • decks table
  • cards table including a foreign key to decks and columns like times_correct, times_wrong

• Implement CRUD for decks and cards.

• Input validation: non-empty question and answer fields.

Functional result: database initializes; decks and cards can be created, read, updated, deleted; statistics fields are initialized to zero; changes persist across restarts.

Phase 2 — Minimal GUI: Deck & Card Management

• GUI window showing list of decks.
• Selecting a deck shows its cards in a list.
• Add, edit, delete decks and cards via GUI.

Functional result: user can manage decks and cards entirely through the interface; all changes persist in the database.

Phase 3 — Quiz Mode with Feedback

• Start a quiz on a selected deck.
• Show one question at a time; user can attempt an answer or reveal it.
• After showing the answer, let the user mark whether they answered correctly or incorrectly, and update statistics in the database.
• Display statistics (times_correct, times_wrong) for that card.
• Navigate to the next/previous card smoothly.

Functional result: user can quiz themselves, see immediate feedback after answering, and statistics update correctly in the database.

Phase 4 — Robustness & Usability Enhancements

• Validate inputs and prevent empty fields.
• Keyboard shortcuts for showing answer and moving to next card.
• Handle database and GUI errors gracefully with clear messages.
• GUI is up-to-date after CRUD or quiz actions.

Functional result: app is stable, intuitive, and responsive; statistics display correctly after each card; all changes persist; sorting/navigation works reliably.

mdPages (Static Site Generator from Markdown)

Phase 1 — Core Markdown to HTML Conversion

• Implement a parser that converts some basic Markdown syntax to HTML:
  • Headings (#, ##, ###)
  • Bold, italic, links, lists
  • Paragraphs and line breaks
• Support processing a single file or a folder of .md files
• Validate input paths and handle missing files gracefully

Functional result: given a markdown file or folder, the program generates corresponding HTML files in an output folder, preserving folder structure.

Phase 2 — CLI and Folder Processing

• Create a command-line interface for your tool:

  • Specify input folder and output folder
  • Option to overwrite existing HTML files or skip them

• Process multiple .md files recursively (in the case of nested folders)

• Maintain relative folder structure in output

Functional result: user can run the program on a folder of markdown files, and the folder structure + HTML files are correctly generated.

Phase 3 — Serve Site Locally

Add a simple HTTP server to serve generated HTML:

• Option to choose port in the CLI
• Serve HTML files with relative links correctly
• Refresh automatically if the server restarts
• Generate an index.html for folders, listing all contained pages

Functional result: user can run the generator and start a local server, then open a browser to view the generated site.

Phase 4 — Robustness & Minor Enhancements

• Include a CSS file, imported by all the generated HTML files, and add some styling.
• Handle common errors (missing files, invalid markdown) gracefully
• Support extra markdown features (inline code, blockquotes)
• Clear console messages/logging for processed files

Functional result: program reliably converts files, preserves folder structure, serves HTML locally, and handles errors cleanly.

Discord Trivia Bot

Phase 1 — Core Bot & Basic Quiz Logic

• Implement a Discord bot connected via the Discord API.
• Users can start a personal quiz session with a command.
• Bot asks a single question from a predefined set (stored in memory or JSON).
• Users submit answers via a command.
• Check correctness and reply immediately.

Functional result: each user can start a quiz session, answer a question, and get immediate feedback on correctness.

Phase 2 — Database Integration

• Set up a SQLite (or other) database to store:

  • Users
  • Scores
  • Questions answered

• Track per-user statistics:

  • Number of correct/incorrect answers
  • Total quizzes taken

• Ensure multiple users’ sessions don’t interfere.

Functional result: user progress and scores persist across bot restarts; multiple users can answer simultaneously without conflicts.

Phase 3 — Quiz Management & Command Enhancements

• Add more commands for the following functionalities:

  • get next question in the user’s session
  • show personal stats
  • leaderboard: display top users globally

• Implement question selection:

  • Random question from pool
  • Avoid repeating questions already answered by the user

Functional result: users can progress through a personalized quiz, see scores, and view leaderboards.

Phase 4 — Robustness & Extra Features

• Handle invalid commands gracefully.
• Add question categories and allow users to pick a category.
• Implement per-user session timeout if inactive.
• Log errors and quiz sessions for debugging.

Functional result: bot runs reliably with multiple concurrent users, tracks stats per user, handles errors, and supports multiple categories.

Discord Weather Bot

Phase 1 — Core Weather Queries

• Implement a Python Discord bot.
• Slash commands for basic weather info:
  • /weather city:<city> → shows current weather
  • /forecast city:<city> → shows short-term forecast (next 3 days)
• Use a public weather API (OpenWeatherMap, WeatherAPI, etc.)
• Handle invalid city names or API errors gracefully

Functional result: Users can type /weather London and receive a nicely formatted embed with the current weather.

Phase 2 — User Preferences & Database Integration

• Store per-user default settings in a database (SQLite/PostgreSQL):
  • Default city
  • Units (metric/imperial)
• Slash commands for preferences:
  • /setcity city:<city> → set default city
  • /setunits unit:<metric|imperial> → set preferred units
• If a command is issued without a city, the bot uses the user’s default city

Functional result: Users can personalize the bot and get weather info without typing the city every time.

Phase 3 — Enhanced Features & Info Types

• Additional slash commands:
  • /air city:<city> → shows air quality index
  • /alerts city:<city> → severe weather alerts
  • /time city:<city> → current local time
• Include error handling and user-friendly messages for unknown cities or API issues

Functional result: Bot provides richer information about the queried cities.

Phase 4 — Advanced Usability & Logging

• Log per-user command history in the database:
  • Track which cities were queried and when
  • Optional command: /history → shows user’s query history
• Daily weather notifications:
  • /subscribe → subscribe to daily updates for default city
  • /unsubscribe → remove subscription

Functional result: Bot is robust, logs activity, and supports subscriptions.

BigBrother

BigBrother monitors a folder for newly appearing text files and scans them for suspicious keywords loaded from a separate threat-list file. It must handle very large files (tens of gigabytes) without loading them fully into memory and must react if the keyword list changes while running.

Phase 1 — Keyword Loading & Single-File Scanner

Implement the core scanning logic.

• Read keyword list from a file (one keyword per line).
• Validate the keyword file (non-empty, no invalid entries).
• Implement a streaming search for suspicious words inside a single file, reading in chunks.
• When a match is found, extract ±100 characters of surrounding context.
• Print alerts to console or write them to an output file.

Functional Result: Running bigbrother.py <keywords.txt> <file.txt> scans the file and prints all matches with context.

Phase 2 — Folder Monitoring Loop

Extend the tool to automatically process new incoming files.

• Monitor a target folder for new files (polling every X seconds).
• Detect previously unseen files and scan them using Phase 1 logic.
• Handle large files and partially written files safely.
• Log all operations (file scanned, no matches, errors).

Functional Result: Starting BigBrother on a folder causes it to continuously watch for new files and scan each one when it appears.

Phase 3 — Hot-Reload Threat Keywords

Add support for updating the keyword list without restarting the program.

• Detect changes to the keyword file.
• Reload keywords dynamically in-memory.
• Use the updated keyword list for future scans.
• Validate new keyword file contents and log errors.

Functional Result: Modifying keywords.txt while BigBrother is running immediately updates the internal keyword list.

Phase 4 — Robustness, Alert Formatting, and Cleanup

Improve usability, safety, and output clarity.

• Add structured alert formatting (timestamp, file name, location, context).
• Colored terminal output for matches.
• Configurable output mode: console, log file, or both.
• Graceful error handling: permission errors, missing folders, corrupted files.
• Write a final README and usage instructions.

Functional Result: BigBrother runs for long periods without errors, provides polished output, and handles real-world issues like errors, file changes, and keyword updates.

Regression Visualization

Phase 1: Data Input and Validation

• Implement user input for x and y coordinates via console or CSV file import.
• Validate numeric inputs and ensure the number of x and y values match.
• Handle missing or malformed data gracefully with informative error messages.

Functional Result: Program stores valid points from both CLI and file, rejecting invalid inputs without crashing.

Phase 2: Regression Coefficient Calculation and Statistics

• Compute coefficients for linear regression ((y = mx + b)) using least squares.
• Compute coefficients for logarithmic regression ((y = a \cdot \ln(x) + b)) using transformed inputs.
• Calculate additional statistics for both regression types: R², residuals, and standard error.
• Handle edge cases such as x ≤ 0 for logarithmic regression or insufficient data points.

Functional Result: Program outputs correct coefficients and statistics for both linear and logarithmic regression.

Phase 3: Equation Display and Reporting

• Display regression equations in a readable format, rounded to 3 decimals:

  • Linear: y = mx + b
  • Logarithmic: y = a*ln(x) + b

• Allow optional generation of a text or CSV report containing all equations, coefficients, and statistics.

• Ensure proper formatting and clarity for both types.

Functional Result: Users can view and save formatted equations and statistics for both regression types.

Phase 4: GUI and Interactive Plotting

• Build a GUI using Tkinter or PyQt:

  • Input fields for manual data entry and buttons for CSV import/export.
  • Buttons to select regression type (linear or logarithmic).
  • Plot original points and the regression line using matplotlib.
  • Include dynamic features like zooming and changing the line colors.

• Ensure proper labels, titles, and legends on plots.

Functional Result: Users can interactively select regression type, see the fitted line over the data points, and verify calculations visually.

Projects of type C

Remove Duplicates

Phase 1 - Duplicate detection module

Identify duplicate files in a given folder by computing file hashes and grouping identical ones.

• Input: path to a folder
• Compute checksums for all files
• Group files with identical content
• Print groups of duplicates

Functional result: A script that correctly lists duplicate file groups.

Phase 2 - User-driven duplicate cleanup module

Extend the script to interactively ask the user which duplicates to delete and perform safe deletions.

• Prompt user for each duplicate group
• Allow selection of files to delete
• Delete chosen files with error handling

Functional result: A script that lists duplicates and deletes selected files based on user input.

Wiki-Page-Info

Phase 1 - Basic Wikipedia page fetcher

Build a module that retrieves a Wikipedia page by title and extracts its summary and main sections.

• Input a page title
• Fetch page content via API
• Parse summary + section headers

Functional result: Script returns structured page info.

Phase 2 - Enhanced detail extraction and export

Extend the tool to extract links, infobox data, and allow exporting results to JSON.

• Extract internal/external links
• Parse infobox fields
• Save full structured data as JSON

Functional result: Script outputs enriched page data and exports it.

Hangman

Phase 1 - Core Hangman game engine

Implement a console Hangman game with word selection, masked display, and letter-guess logic.

• Load random word
• Show hidden word state
• Process guesses with attempts limit

Functional result: Fully playable basic Hangman in console.

2. Enhanced gameplay and word management Add difficulty levels, scoring, word lists from file, and simple ASCII visuals for hangman stages.

• Load words by difficulty
• Track score across rounds
• Display hangman ASCII states

Functional result: More complex multi-round Hangman with visuals and scoring.

Data Analysis

Phase 1 - Single-column statistics module

Implement functions to compute mean, median, standard deviation, min, max, and quartiles for a numeric column from a CSV file.

• Load CSV
• Validate numeric data
• Compute all metrics

Functional result: Script outputs correct descriptive statistics for one column.

Phase 2 - Two-column relationship analysis module

Extend the tool to calculate covariance and correlation between all two numeric columns and present results in a structured report.

• Validate two columns
• Compute covariance
• Compute correlation coefficient

Functional result: Script generates accurate pairwise analysis and a clear summary report.

Useful Datasets

• Obesity or CVD risk
• Hotel reservations
• Home loans
• Airlines delay
• Job placement
• Superstore marketing

Password Generator

Phase 1 - Basic password generator

Create a module to generate random passwords of specified length using letters and digits.

• Input desired password length
• Generate password using letters and digits
• Display password to user

Functional result: Script produces secure random passwords of requested length.

Phase 2 - Advanced password customization

Enhance generator to include special characters, enforce complexity rules, and optionally save passwords to a file or clipboard

• Include uppercase, lowercase, digits, symbols
• Ensure minimum complexity requirements
• Save generated passwords to a file or clipboard

Functional result: Script generates customizable secure passwords and optionally exports them.

Remove Old Files

Phase 1 - File age detection module

Develop a script to identify files older than a specified number of days in a given folder.

• Input folder path and age threshold
• Check file creation/modification dates
• List old files

Functional result: Script outputs correct list of files older than the specified age.

Phase 2 - File removal and reporting module

Extend the script to allow user confirmation and safe deletion of old files, with logging of removed files.

• Prompt user for each file or batch deletion
• Delete selected files safely
• Log deleted files to a report

Functional result: Script deletes chosen old files and generates a deletion report.

To Do List

Phase 1 - Basic To-Do List with GUI

Create a simple graphical interface to add, view, and remove tasks using Tkinter or PySimpleGUI.

• Input tasks via text field
• Display tasks in a listbox
• Buttons to add and remove tasks

Functional result: GUI allows adding, viewing, and deleting tasks interactively.

Phase 2 - Persistent and enhanced GUI To-Do List

Extend the GUI to save/load tasks from a file, mark tasks as completed, and optionally filter by status.

• Save/load tasks to/from a file
• Mark tasks as done with a checkbox or visual cue
• Filter or sort tasks by status

Functional result: GUI persists tasks across sessions and supports task completion and filtering.

Common Phrases

Two phrases are considered the same, if they have the same wording order. Multiple phrases are separated by ., ;, ? and !.

E.g.: Hello, this is Maria. is considered the same as Hello ... this is Maria but not the same as Hello. This is Maria?

Phase 1 - Basic common phrases comparison

Create a script that reads multiple text files and identifies phrases that appear in more than one file.

• Input multiple text files
• Extract phrases or n-grams
• Compare and list common phrases

Functional result: Script outputs a correct list of repeated phrases across files.

Phase 2 - GUI and enhanced analysis

Add a simple GUI to select files, display common phrases, and optionally highlight frequency or export results.

• File selection via GUI
• Display common phrases with counts
• Export results to CSV or text

Functional result: GUI shows common phrases interactively and allows saving the analysis.

OwnRM

Phase 1 - Basic file removal tool

Create a Python script that mimics the rm command to delete files from a specified directory.

• Input file or folder path
• Validate existence
• Delete file safely

Functional result: Script deletes specified files and handles errors correctly.

Phase 2 - Enhanced removal with options

Extend the script to support recursive deletion, dry-run mode, and logging of deleted files.

• Support folder recursion
• Implement dry-run to preview deletions
• Log removed files to a report

Functional result: Script can delete files/folders safely with previews and logs.

Folder to JSON

Phase 1 - Basic folder structure to JSON

Create a script that reads a folder and generates a JSON representation of its directory tree.

• Input folder path
• Traverse subfolders and files
• Generate nested JSON structure

Functional result: Script outputs JSON accurately representing folder hierarchy.

Phase 2 - Enhanced folder metadata export

Extend the script to include file metadata (size, creation/modification date) and optionally save the JSON to a file.

• Collect file size and timestamps
• Include metadata in JSON
• Save JSON to specified file

Functional result: Script produces detailed JSON with metadata and writes it to disk.

Stock Buster

Phase 1 - Basic stock price analysis

Create a Python script that fetches historical stock data and calculates basic metrics like daily changes and simple moving averages.

• Input stock ticker and date range
• Fetch historical prices
• Compute daily changes and moving averages

Functional result: Script outputs correct basic statistics for the selected stock.

Phase 2 - Enhanced analysis and reporting

Extend the tool to calculate volatility, percentage changes, and generate a summary report with optional CSV export.

• Compute daily/weekly volatility and returns
• Identify highest and lowest prices
• Export summary to CSV

Functional result: Script produces detailed stock analysis and generates a report file.

OwnFind

Phase 1 - Basic directory traversal

Implement a Python script that walks through directories and lists all files and folders based on a starting path.

• Accept root path
• Recursively list files and folders
• Display full paths

Functional result: Script correctly outputs all discovered paths.

Phase 2 - Filtering and matching

Extend the tool to support simple filters such as name matching, file-type selection, and size constraints.

• Match names using substrings
• Filter by extensions
• Filter by minimum/maximum size

Functional result: Script outputs only items matching the chosen filters.

OwnWc

Phase 1 - Basic counting

Implement a Python script that mimics minimal wc behavior using sys.argv for inputs.

• Read file paths only from command-line arguments
• Count lines, words, and characters per file
• Display counts in a simple formatted output

Functional result: Script prints correct line/word/character counts for each provided file.

Phase 2 - Extended flags and aggregated output

Add optional flags to refine output and support totals.

• Implement flags: -l (lines), -w (words), -c (chars)
• Show only counts requested by flags
• Add total aggregation when multiple files are given

Functional result: Script outputs filtered counts and a correct totals line when multiple files are processed.

OwnUniq

Phase 1 - Basic argument handling and line grouping

Implement a Python script that reads command-line arguments and groups consecutive identical strings, mimicking minimal uniq behavior.

• Read inputs exclusively from sys.argv[1:]
• Group consecutive duplicate arguments
• Print one representative per group

Functional result: Script outputs collapsed consecutive duplicates exactly in the order received.

Phase 2 - Extended uniq-style options

Add simple flags to control output formatting and filtering, similar to common uniq options.

• Add -c to show counts before each grouped line
• Add -d to print only duplicated groups
• Ensure flags can be combined

Functional result: Script correctly applies flags and prints filtered or counted groups based on selected options.

File Scanner

Phase 1 – File discovery and safe access checking

Build a Python script that walks through user-accessible directories, checks permissions before opening files, and lists only the paths that can be safely read.

• Recursively explore directories
• Check read permissions before access
• Collect readable file paths

Functional result: Script outputs a correct list of safely accessible files.

Phase 2 – Keyword search and line extraction

Extend the script to scan readable files for target keywords and print each matching line while handling errors gracefully.

• Open each readable file securely
• Search for keywords like “secret”, “password”, “info”
• Print lines containing matches

Functional result: Script outputs all detected lines containing specified keywords.

URLWatch

A Python monitoring script that continuously checks website availability based on entries from sites.txt.
Each line in the file follows the format: URL IMPORTANCE, where IMPORTANCE ∈ {INFO, WARNING, CRITICAL}.
Output uses colors: green for reachable sites, blue/yellow/red for unreachable INFO/WARNING/CRITICAL, and white for any other messages.

Phase 1 – File parsing and basic site checking

Implement a Python script that loads sites.txt, parses URL–IMPORTANCE pairs, and checks accessibility in a loop with colored status output.

• Parse file and validate entries
• Ping URLs periodically
• Display color-coded availability

Functional result: Script correctly reads inputs and shows live colored status for all sites.

Phase 2 – Filtering and configurable intervals

Add support for command-line options to filter by IMPORTANCE level and set the check interval, applying both to the continuous monitoring loop.

• Add CLI arguments for interval
• Add CLI filtering by IMPORTANCE
• Apply settings to monitoring logic

Functional result: Script monitors only selected categories at the chosen interval.

System Info Reporter

Phase 1 - Core hardware information

Create a Python script that retrieves basic hardware details such as CPU, RAM, motherboard, and disk size using available libraries.

• Fetch CPU model and temperature
• Get total RAM size
• Identify motherboard model
• List total disk size and available volumes

Functional result: Script prints CPU, RAM, motherboard, and disk information accurately.

Phase 2 - Extended system details

Extend the script to include GPU info, system uptime, and BIOS/UEFI version, providing a complete system summary.

• Fetch GPU model, temperature, and driver version
• Get system uptime
• Retrieve BIOS/UEFI version

Functional result: Script outputs full system summary including GPU, uptime, and BIOS/UEFI details.

Product Price Crawler

Phase 1 - Basic product price retrieval

Develop a Python script that takes a list of products, searches compari.ro, and collects price information.

• Input list of product names
• Fetch product listings from compari.ro
• Extract product name, lowest price, highest price, and number of offers

Functional result: Script outputs accurate price information for each product in a structured format.

Phase 2 - JSON export and structured storage

Enhance the script to save the collected product data in a JSON file for easy use and further processing.

• Convert collected product data into JSON format
• Save JSON to a file with proper structure
• Ensure all products have complete information recorded

Functional result: Script generates a JSON file containing all products with their price data and offer counts.

Recipe Crawler

Phase 1 - Recipe scraping and ingredient extraction

Create a Python script that fetches ingredients from specified recipes on Jamila Cuisine and compiles them into a structured list.

• Input recipe names as parameters
• Generate recipe URLs and fetch HTML content
• Extract ingredients for each recipe and create individual lists

Functional result: Script outputs ingredient lists for given recipes in a readable format.

Phase 2 - Shopping list consolidation and JSON storage

Extend the script to merge ingredient lists into a single shopping list, summing quantities for repeated items, and save it in a JSON file.

• Check for existing JSON file and load it
• Consolidate ingredients across recipes, updating quantities
• Save or update the shopping list JSON file

Functional result: Script produces a consolidated shopping list in JSON that updates correctly on subsequent runs.

Text Analyzer

Phase 1 - Basic text statistics

Create a Python script that reads a text file and computes the number of words and sentences, as well as identifies unique phone numbers and CNPs.

• Input a text file
• Count total words and sentences
• Detect unique phone numbers (starting with 07) and CNPs

Functional result: Script displays correct word and sentence counts and lists unique phone numbers and CNPs found.

Phase 2 - Letter frequency analysis

Extend the script to compute case-insensitive letter statistics and the percentage of each letter relative to the total letters in the text.

• Count occurrences of each letter (ignore case)
• Calculate the percentage of each letter in total letters
• Display the results alongside previously computed statistics

Functional result: Script outputs a frequency table of letters with counts and percentages, together with word, sentence, phone, and CNP statistics.

Caesar File Encryptor

Phase 1 - File encryption and decryption

Develop a Python script that encrypts or decrypts a single file using a numeric key and the ASCII Caesar cipher.

• Input file path and numeric key
• Encrypt or decrypt file content using ASCII letters
• Save output to a new file

Functional result: Script successfully encrypts or decrypts a given file with the specified key.

Phase 2 - Recursive folder processing

Extend the script to handle all files in a folder recursively, applying the Caesar cipher to each file.

• Input folder path and numeric key
• Traverse folder and subfolders recursively
• Encrypt or decrypt all files and save results

Functional result: Script processes entire folder structure, encrypting or decrypting each file correctly.

Note: The user must be able to choose between file encryption / decryption for a single file or for a folder. Read about Caesar cipher here.

CLI Flappy Bird

Phase 1 - Basic game mechanics

Create a Python script that simulates Flappy Bird in the command line with a 32x32 character grid and random obstacle generation.

• Display 32x32 character grid
• Generate random obstacles
• Control bird movement using space key

Functional result: Bird moves through the level, obstacles appear, and collisions end the game correctly.

Phase 2 - Scoring and leaderboard

Extend the game to allow username input after a round and maintain a top 3 high score list.

• Prompt user for username at game over
• Calculate and save score
• Keep top 3 high scores persistently

Functional result: Game records scores, updates leaderboard, and displays top 3 scores at the end of each round.

GUI Timer

Phase 1 - Timer setup and countdown

Create a Python GUI application that allows the user to set hours, minutes, and seconds, and start a countdown.

• Input fields for hours, minutes, and seconds
• Start, pause, and reset buttons
• Display remaining time dynamically

Functional result: Timer counts down accurately based on user input and can be paused or reset.

Phase 2 - Notifications on completion

Extend the timer to notify the user visually and with a sound when the countdown reaches zero.

• Display a pop-up or message when time is up
• Play an audible alert
• Ensure notifications trigger reliably at countdown completion

Functional result: User receives both visual and audio alerts when the timer ends.

CIDR Utility

Phase 1 - CIDR to IP range conversion

Create a Python script that receives a CIDR subnet and outputs the corresponding IP range in a human-readable format.

• Input a CIDR subnet (e.g., 172.16.0.0/12)
• Calculate the first and last IP addresses in the range
• Display the range in readable format

Functional result: Script outputs correct start and end IP addresses for any valid CIDR subnet.

Phase 2 - IP membership verification

Extend the script to optionally check if a specific IP belongs to the given CIDR range.

• Accept an IP address as a second argument
• Verify whether the IP is within the subnet range
• Output True or False accordingly

Functional result: Script correctly indicates whether a given IP belongs to the specified CIDR range.

CLI Book Reader

Phase 1 - Text formatting and pagination

Create a Python script that reads a text file and formats it into pages with a fixed number of lines and characters per line, avoiding splitting words across lines.

• Read a text file
• Format text into lines and pages with character and line limits
• Display a single page at a time

Functional result: Script correctly formats the text into readable pages without splitting words.

Phase 2 - Page navigation

Extend the script to allow navigation between pages using keyboard input.

• Move forward and backward through pages using left/right keys
• Display updated page content on navigation
• Handle edge cases at first and last pages

Functional result: User can navigate the entire book page by page, with proper rendering of all lines and words.

DiscordRandom

Phase 1 – Core bot and basic random features

Implement a Python Discord bot with essential randomization tools responding to user commands.

• Connect bot using Discord API
• Randomize a given list
• Dice rolling, random number, random string
• Pick random choices

Functional result: Bot answers commands correctly with randomized outputs for lists, dice, numbers, strings, and selections.

Phase 2 – Extended features and admin seed control

Add advanced random tools and admin-only seed configuration for reproducible results.

• Admins set/reset seed
• Random winner picker
• Multiple random selections
• Basic error handling and command feedback

Functional result: Bot supports reproducible randomness via admin seed, extended commands work reliably with clear user responses.

InstantGrader

Phase 1 – JSON loading and basic evaluation

Implement reading the JSON file, evaluating each mathematical expression, and comparing results with correct answers.

• Load JSON structure
• Evaluate expressions safely
• Compare with correct answer
• Assign points per problem

Functional result: Script computes each student’s total score based on evaluated answers and correctness.

Phase 2 – Statistics and pass evaluation

Add aggregation of results, statistics generation, and pass/fail counting.

• Calculate grade distribution
• Compute average and highest score
• Count passed students
• Display formatted summary

Functional result: Script outputs individual scores, global statistics, and total number of passing students.

JSON example:

{
    "Ion Popescu" : {
        "problema-1" : {
            "rezolvare": "1 + 2",
            "raspuns-corect": "3",
            "punctaj": 10
        },
        "problema-2" : {
            "rezolvare": "(2 + 3) * (1.3 + 3.7)",
            "raspuns-corect": "25",
            "punctaj": 20
        }
    },
    "Ileana Constantinescu" : {
        "problema-1" : {
            "rezolvare": "1 - 2",
            "raspuns-corect": "3",
            "punctaj": 10
        },
        "problema-2" : {
            "rezolvare": "10 - 100",
            "raspuns-corect": "25",
            "punctaj": 20
        }
    }
}

DiscordQR

Phase 1 – Core bot and QR generation

Create a basic Discord bot that listens for a command containing a URL and generates a QR code image.

• Connect bot through Discord API
• Parse URL from command
• Generate QR image
• Send image back to channel

Functional result: Bot responds to a URL command by producing and sending a valid QR code image.

Phase 2 – Validation and improved interaction

Add simple input validation, error feedback, and optional QR code version customization.

• Check URL format
• Return clear error messages
• Allow differnt QR code styles
• Handle missing or invalid arguments

Functional result: Bot reliably validates input, handles errors gracefully, and delivers customizable QR outputs.

SpookyNotif

Phase 1 – JSON parsing and random notifications

Implement a Python script that reads prompts from a JSON file and sends system notifications at random intervals.

• Load JSON file with prompt-tags entries
• Select a random prompt
• Send a system notification
• Repeat at random intervals

Functional result: Script displays notifications with random prompts continuously until manually stopped.

Phase 2 – Tag filtering and error handling

Add command-line tag filtering and ensure the script handles missing or incompatible prompts gracefully.

• Accept tags via command-line arguments
• Filter prompts by specified tags
• Exit if no compatible prompt exists
• Maintain continuous notifications until user intervention

Functional result: Script only sends relevant notifications based on tags and handles empty results without crashing.

XArt

Phase 1 – Pixel analysis and selection

Create a Python script that loads an image, counts pixel frequencies, and selects the top X most frequent colors based on command-line input.

• Load image from command line
• Count frequency of each pixel color
• Select top X colors
• Display selected colors or store for later use

Functional result: Script identifies and outputs the X most frequent pixel colors from the given image.

Phase 2 – Random artwork generation

Use the selected top X colors to generate a new image with random lines, shapes, and zones.

• Create a blank canvas
• Draw random lines, shapes, and areas using only the selected colors
• Save the generated image
• Ensure visual randomness while restricted to top X colors

Functional result: Script produces a new random artwork image using only the top X colors from the original photo.