Finding feature implementation

use-cases/task-manager/javascript/documentation.md

@@ -0,0 +1,146 @@
+# Exercise 1 Code Understanding
+
+## Language Used
+The code I have chosen is **JavaScript**.
+
+# Code Breakdown
+
+## Codebase
+
+There are 4 javascript files it appears.
+There seems to be an attempt at a backend by using module.export and the require key word and file paths but no official frameworks.
+
+## Initial Understanding
+### Organization
+- It appears app.js is the main file.
+- cli.js seems to convert the project into a usable command line interface by creating a program constant and using the commander library to create a command line interface.
+- models.js seems to be handeling the task management of the project
+- storage.js seems to be running where and how the project data is stored. It can also edit the stored data.
+
+### Frameworks and technologies
+- module exports
+- CLI tools/commander library
+- Task manager class
+- Engine uuidv4
+- File pathing
+
+### Main Components
+- CLI Tools
+- File pathing
+
+## Project Structure
+### Using Prompt
+*** My Prompt ***
+I'm a junior developer who just joined this project. I've read the README but still need help understanding the project structure and technology stack
+Here's my current understanding of the project:
+
+## Codebase
+
+There are 4 javascript files it appears.
+There seems to be an attempt at a backend by using module.export and the require key word and file paths but no official frameworks.
+
+## Initial Understanding
+### Organization
+- It appears app.js is the main file.
+- cli.js seems to convert the project into a usable command line interface by creating a program constant and using the commander library to create a command line interface.
+- models.js seems to be handeling the task management of the project
+- storage.js seems to be running where and how the project data is stored. It can also edit the stored data.
+
+### Frameworks and technologies
+- module exports
+- CLI tools/commander library
+- Task manager class
+- Engine uuidv4
+- File pathing
+
+### Main Components
+- CLI Tools
+- File pathing
+Project structure
+task-manager
+     --Java
+     --Javascript
+        --app.js
+        --cli.js
+        --models.js
+        --storage.js
+    --python
+We are only focussing on the JavaScript folder
+Configuration Files:
+None
+Could you:
+1. Validate my understanding and correct any misconceptions
+2. Identify additional key technologies, frameworks, and libraries used
+3. Explain what each main folder likely contains and its purpose
+4. Point out where the application entry points are located
+5. Suggest 3-5 specific questions I should ask my team to deepen my understanding
+After your explanation, could you suggest a small exploration exercise I could do to verify my understanding of the project structure?
+
+*** Claude Response ***
+1. Validating Your Understanding
+Your instincts are largely correct, with a few refinements:
+What you got right:
+
+app.js as the main entry point is a standard Node.js convention — good call.
+cli.js using Commander to expose a CLI is accurate. Commander is a well-established library for parsing command-line arguments and defining commands/flags.
+storage.js handling data persistence (read/write) is a sensible separation of concerns.
+models.js containing a Task management class is a classic MVC-style "model" layer.
+
+Misconceptions to correct:
+
+"An attempt at a backend" — module.exports and require are not signs of an incomplete or attempted backend. They are simply Node.js's built-in CommonJS module system, the standard way to split code across files in Node.js. This is intentional and complete, not a workaround.
+"No official frameworks" — this is likely a deliberate architectural choice. Many CLI tools are built as lightweight Node.js apps without Express or similar, because they don't serve HTTP traffic. The absence of a framework isn't a gap; it's appropriate for the tool's purpose.
+"Engine uuidv4" — UUIDv4 is not an engine. It's a small utility library for generating universally unique IDs (e.g. giving each task a unique identifier like f47ac10b-58cc...). Think of it as a helper, not a runtime.
+
+
+2. Key Technologies & Libraries
+Based on your description, here's the fuller picture:
+TechnologyRoleNode.jsThe JavaScript runtime — what actually executes the codeCommonJS (require/module.exports)Node's module system for splitting code across filesCommander.jsParses CLI arguments, defines commands and flagsuuid / uuidv4Generates unique IDs for each taskNode fs moduleAlmost certainly used in storage.js for reading/writing files to diskJSONLikely the storage format (a flat .json file acting as a simple database)
+
+3. What Each File Likely Does
+task-manager/
+└── Javascript/
+    ├── app.js       → Wires everything together. Imports the CLI and kicks off execution.
+    ├── cli.js       → Defines user-facing commands (e.g. `add`, `list`, `delete`).
+    │                  Uses Commander to parse what the user types in the terminal.
+    ├── models.js    → The Task class/object. Defines what a task looks like (id, title,
+    │                  status, etc.) and methods to operate on tasks.
+    └── storage.js   → Reads from and writes to a file on disk. Handles all persistence
+                       so the other files don't need to know *how* data is saved.
+The Java and Python folders likely contain parallel implementations of the same task manager — a common pattern for learning projects or polyglot codebases demonstrating the same app in multiple languages.
+
+4. Entry Points
+There are likely two entry points depending on how the app is used:
+
+app.js — the primary Node.js entry point, probably run via node app.js or referenced in a package.json "main" field.
+cli.js — may also be executable directly (e.g. node cli.js add "Buy milk"), or it's imported by app.js which delegates to it immediately.
+
+Check for a package.json — if it exists, the "bin" or "main" field will tell you the definitive entry point, and "scripts" will show you how the team actually runs it.
+
+5. Questions to Ask Your Team
+
+"Is there a package.json, and what does the scripts section look like?" — This reveals how the app is built, run, and tested, and whether there are dependencies you haven't seen yet.
+"Where is task data actually stored — a local JSON file, or something else?" — Understanding the storage target clarifies storage.js's full role.
+"Is this CLI tool meant to be installed globally (npm install -g) or run locally?" — This affects how users interact with it and how Commander is configured.
+"Are the Java and Python folders feature-equivalent to the JavaScript version, or are they experiments/stubs?" — Knowing this tells you whether cross-language consistency matters.
+"Are there any plans to add tests?" — Junior-friendly question that reveals team practices and gives you a contribution opportunity.
+
+
+Exploration Exercise
+Try this structured trace-through — no code changes, just reading:
+
+Start at app.js — identify every require() call. Draw a simple arrow diagram of what it imports.
+Open cli.js — find each .command() call in Commander. List the commands the app exposes (e.g. add, list, complete).
+Open models.js — find the class definition. List its properties (what fields does a Task have?) and its methods.
+Open storage.js — find where it reads and writes. What filename or path does it use? What format is the data?
+Try running it — if Node.js is installed, run node app.js or node cli.js --help and see if the Commander help output matches the commands you found in step 2.
+
+## Findings 
+### Misconceptions to correct:
+1. "An attempt at a backend" — module.exports and require are not signs of an incomplete or attempted backend. They are simply Node.js's built-in CommonJS module system, the standard way to split code across files in Node.js. This is intentional and complete, not a workaround.
+2. Engine uuidv4" — UUIDv4 is not an engine. It's a small utility library for generating universally unique IDs (e.g. giving each task a unique identifier like f47ac10b-58cc...). 
+### Final Resault
+1. My understanding of the project structure is mostly correct, with some refinements regarding the use of CommonJS modules and the role of uuidv4.
+2. Key technologies include Node.js, CommonJS modules, Commander.js for CLI parsing, uuid
+3. Each file has a clear purpose: app.js is the main entry point, cli.js defines the CLI commands, models.js defines the Task class, and storage.js handles data persistence.
+4. The main entry point is likely app.js, but cli.js may also be directly executable

use-cases/task-manager/javascript/newFeature.md

@@ -0,0 +1,118 @@
+# Exercise 2
+Add task: Export to CSV
+## Initial Search
+No similar feature was found to convert a file to export
+
+## Hypothesis
+I think the best place to use this feature would be in cli.js as it deals with the terminal mostly so it easily accessable to this applications and future implements. The terminal also has easy access to fiels so the conversion to csv would be easier to implement in this file.
+
+**no files need adjustment**
+
+### Search Terms
+- "export to csv"
+- "convert to csv"
+- "exports"
+- "csv"
+
+## Feature Location Prompt
+
+### Prompt Used
+I need to work on adding a task: Convert to CSV in this codebase, but I'm not sure where the code for this feature lives.
+
+My approach so far:
+- I've searched for keywords like "export to csv", "convert to csv", "exports", "csv"
+- I looked in cli.js which seemed relevant
+Can you help me:
+1. Evaluate my search approach and suggest improvements
+2. Identify which files and directories most likely contain the implementation for this feature
+3. Suggest specific search terms or patterns that would be more effective
+4. Explain what parts of the feature might be located in different areas of the codebase
+5. Recommend a step-by-step investigation process to understand the complete feature flow
+
+Also, what questions could I ask myself as I'm exploring the code to ensure I'm on the right track? What specific patterns should I look for to confirm I've found all the relevant parts?
+
+After your guidance, could you give me a small challenge to test my understanding of how to navigate this feature's code?
+
+### Prompt Response
+Comprehensive Navigation Guide for the CSV Feature
+1. Evaluation of Your Search Approach ✓
+What You Did Well:
+
+Searched for direct keywords ("export to csv", "convert to csv")
+Looked at cli.js (correct instinct—UI layer often reveals exposed features)
+What Could Be Improved:
+
+Your search was feature-focused rather than architecture-focused—CSV export doesn't exist yet
+Better approach: First understand the code structure, then search strategically
+You correctly hypothesized cli.js but didn't yet map where the CSV conversion logic belongs
+2. Files & Directories Most Likely to Contain CSV Logic
+File	Role	Expected Changes
+cli.js	Command-line interface	Add export or export-csv command
+storage.js	Persistence/file I/O	Add exportToCSV() method (follows existing pattern)
+app.js	Business logic	Optional: add exportTasks() method
+models.js	Data definitions	No changes needed (already has Task structure)
+3. Better Search Terms & Patterns
+Instead of searching for "csv", try these sequences:
+
+4. How the Feature Flows Across the Codebase
+5. Step-by-Step Investigation Process
+Phase 1: Understand Data Structure
+
+Read models.js → What fields does a Task have?
+Read storage.js → How are tasks stored/retrieved? (Look for getAllTasks())
+Trace: Where does task data originate and how is it accessed?
+Phase 2: Identify Integration Points
+4. Read cli.js → How are existing commands structured? (Look for program.command() patterns)
+5. Compare: What do list, create, delete commands do?
+6. Pattern Match: Find similar file-writing operations if any exist
+
+Phase 3: Locate Persistence Patterns
+7. In storage.js, find the save() method → This is the model for CSV export
+8. Question: Does save() use fs.writeFileSync()? Yes → Use same approach
+
+Phase 4: Determine Ownership
+9. Is CSV logic belongs in storage.js (file I/O) or app.js (business logic)?
+10. Check: Does app.js expose an getAllTasks() or similar public method?
+
+6. Questions to Ask While Exploring
+Ask yourself these during code exploration:
+
+"Who calls this function?" → Trace backwards to see dependencies
+"What data does this return?" → Understand the shape of data flowing through
+"Where is file I/O happening?" → Look for fs. operations
+"What's the pattern for similar features?" → Compare with list, stats, delete commands
+"Which layer handles each responsibility?" → CLI? Business Logic? Storage?
+"Is there a public API I should use?" → Via TaskManager or TaskStorage?
+"What error cases exist?" → File permissions, invalid paths?
+7. Patterns to Confirm You've Found Everything
+✓ You've found it all when you can answer:
+
+Data Source: "I can get all tasks via this.storage.getAllTasks()"
+Transformation: "I can convert task objects to CSV using headers + rows"
+Output: "I can write to file using fs.writeFileSync() like the save() method does"
+Integration: "I can add a new CLI command in cli.js like the stats command"
+End-to-End: "User runs export-tasks --output file.csv → triggers handler → converts tasks → writes file"
+8. Your Challenge 🎯
+Task: Without looking at any code, answer these:
+
+Data Flow: Where would you retrieve the task data for CSV export—from TaskStorage.getAllTasks() or from TaskManager.listTasks()? Why?
+File Writing: Which method in storage.js shows you the exact pattern for writing files? Find it and identify the 2-3 lines you'd need to adapt.
+CLI Integration: In cli.js, find one existing command and describe what happens in its .action() callback.
+Ownership: Should the CSV formatting logic live in storage.js or a new separate file like formatters.js? Justify your answer.
+Completeness Check: What would need to change in app.js to support taskManager.exportToCSV(filename)?
+Try these now: Read just storage.js carefully and answer questions 1-2. Then read just one command in cli.js and answer question 3. Post your answers and I'll validate your understanding!
+
+## Findings
+### Where to implement the feature
+1. CLI Layer (cli.js) — Add a new command (e.g. export-tasks) that users can run from the terminal.
+2. Storage Layer (storage.js) — Implement the actual logic to convert tasks to CSV format and write to a file. This keeps file I/O concerns separate from business logic.
+3. Optional: Business Logic Layer (app.js) — If you want to keep CLI thin, you could add an exportTasks() method here that orchestrates the retrieval and formatting, but it's not strictly necessary.
+### Related components to be affected
+- cli.js — for the new command and its handler
+- storage.js — for the CSV conversion and file writing logic
+### Plan to implement export feature
+1. In cli.js, define a new command (e.g. `export-tasks`) using Commander.
+2. In the command's action handler, call a new method in storage.js (e.g. `exportToCSV(filename)`) that you will implement.
+3. In storage.js, implement `exportToCSV(filename)`:
+4. Retrieve all tasks (e.g. via `getAllTasks()`)
+5. Convert tasks to CSV format (create headers, iterate over tasks to create rows)