DEV Community: Ayush Aryan

GhostTrace: Giving Terminal Logs a Story Without Losing the Evidence

Ayush Aryan — Thu, 29 Oct 2026 03:00:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 4 — Ghost in the Machine.

A log file records what a system did. But when events stretch across many lines, warnings, errors, and restarts can be difficult to understand. GhostTrace turns terminal output and application logs into a structured event timeline and an AI-generated narrative, while keeping the source evidence available for inspection.

The project responds to the “Ghost in the Machine” theme by treating a system’s history as something worth remembering. A failed process or forgotten service is not literally a ghost, but its trace can help us understand what happened. The narrative gives that history a human-readable form.

What I Built

GhostTrace is a browser-based log analysis and storytelling application. Users can provide input in three ways:

Paste terminal output or log text.
Upload a .txt, .log, .json, or .csv file.
Select one of the built-in fictional scenarios.

The app parses the supplied text, calculates deterministic summary metrics, identifies selected patterns, and displays a timeline beside an AI-generated narrative. Users can choose the narrative mode, story length, and an optional tone accent.

GhostTrace has four narrative modes:

Haunted Chronicle — atmospheric horror inspired by system events.
Digital Séance — a fictional machine recounts its history in first person.
Forensic Detective — an evidence-first technical investigation.
Lost Memory — a reflective story about developer work and digital traces.

The modes change how the story is told; they do not change the parser’s extracted events. Readers can open an event reference in the Evidence Inspector to see its source line, line number, timestamp when available, classification, severity, and recognized signals.

GhostTrace is an exploratory tool for reading logs. It does not execute commands, connect to a user’s shell, or monitor terminal activity.

Demo

GhostTrace does not currently have a public hosted deployment. The code and local setup instructions are available here:

GitHub repository: ayusharyan4269-bit/GhostTrace
Setup guide: Run GhostTrace locally on Windows
Browser test checklist: docs/SMOKE_TEST.md

To try it on Windows:

Install Python, Node.js, and Ollama.
Download the default model by running ollama pull qwen2.5:3b.
Follow the backend and frontend dependency setup in the repository README.
Run .\dev.ps1 from the project folder.
Open http://localhost:5173 in your browser.
Choose a built-in scenario, select a narrative mode, and click Analyze & Summon Story.

No account or login is required. If Ollama is unavailable, GhostTrace can still parse the log and display deterministic analysis, but it cannot generate the AI narrative.

Code

GhostTrace is available on GitHub under the MIT License.

The repository contains the React frontend, FastAPI backend, log parser, event analysis services, Ollama integration, SQLite session storage, automated tests, GitHub Actions CI, and setup and architecture documentation.

How I Built It

The frontend uses React, TypeScript, Vite, and Tailwind CSS. The backend uses Python, FastAPI, and Pydantic. Ollama provides the model runtime, with Qwen 2.5 3B as the default open-weight model. SQLite stores saved analysis sessions when a user explicitly chooses to save one.

The analysis pipeline separates deterministic processing from AI-generated storytelling:

Analysis workflow

Choose input: Paste logs, upload a supported file, or select a built-in scenario.
Review possible secrets: GhostTrace detects common credential patterns and shows a redacted preview when it finds a possible secret.
Parse the log: The backend extracts structured events and source references from the input.
Analyze events: Deterministic application code calculates summary metrics and checks for selected patterns.
Generate the narrative: The configured Ollama model receives selected evidence and the chosen narrative mode and length.
Inspect the result: Read the story and timeline, then open event references to review their source lines.
Save or export: Save the narrative and summary locally, or export a Markdown report.

1. Input review

Users choose what to submit by pasting text, uploading a file, or selecting a built-in scenario. The uploader accepts .txt, .log, .json, and .csv files up to 2 MB. GhostTrace also enforces a maximum log-content length.

Before analysis, GhostTrace checks for common credential patterns such as API keys, tokens, passwords, private keys, and authorization values. If it detects a possible secret, the interface shows a redacted preview for review.

This is best-effort pattern matching. It can miss custom or unusual credentials, so users should inspect the preview and avoid submitting real secrets.

2. Deterministic log parsing

The backend parses plain text, JSON, newline-delimited JSON, and CSV input into structured events. Depending on the input, an event can contain a line reference, timestamp, event type, severity, normalized summary, and recognized indicators.

For plain-text logs, explicit matching rules look for signals such as errors, warnings, process starts and stops, restarts, non-zero exits, permission failures, missing files, network failures, and selected HTTP error codes.

The parser creates the event list; the language model does not. Parsed events provide the data used by the timeline and evidence inspector.

3. Event analysis

The event analyzer calculates summary values from parsed events, including event, error, warning, and command counts, along with a time range when timestamps are available. It checks for selected patterns, including repeated errors, process restart sequences, abrupt terminations, memory faults, HTTP server errors, missing resources, and permission-denied events.

These findings come from deterministic rules. They help organize a trace, but they do not prove the root cause of an incident.

4. Narrative generation

The backend sends the configured Ollama model a summary, selected event anchors, and the requested narrative mode and length. For large logs, the narrative engine selects a bounded group of events, prioritizing high-signal events while maintaining coverage across the sequence.

The model is asked to return structured narrative data, including a title, narrative, key events, creative interpretations, uncertainties, and a closing line. The backend validates the response and matches evidence shown in the inspector to events produced by the parser.

This does not make every sentence in the AI-generated narrative correct. Readers should check technical claims against the original log lines.

5. Saving and exporting

Analysis results are not automatically added to the saved-session database. A user must choose Save Session. A saved session contains its narrative and summary fields; raw input logs are not intended to be stored in that session workflow.

Users can also export a report as Markdown. Because it may contain details from the analysis, it should be reviewed before sharing.

Why Does Open Innovation Matter?

GhostTrace uses an open-weight model through Ollama instead of requiring a closed, hosted AI API. Ollama is configured to use 127.0.0.1 by default, so inference can happen on the user’s machine. After installing dependencies and downloading the model, the local setup can run without an internet connection.

This matters for log analysis because logs can reveal internal paths, service names, system behavior, or accidental credentials. Local inference gives users more control over where their data is processed. GhostTrace does not configure a hosted AI fallback.

The model is configurable: users can select another model available to their Ollama server. This gives them a choice of model and runtime instead of tying the application to one hosted provider. Local inference has trade-offs: performance depends on the user’s hardware, and models differ in quality and response time.

If someone changes the Ollama URL to a remote server, analyzed content is sent there after recognized secrets are redacted. Users should trust that server before sending it sensitive logs. Redaction can miss secrets, and local inference does not make a model’s conclusions automatically correct.

Privacy and Safety Choices

GhostTrace treats submitted logs as data to inspect, not commands to run. It does not execute terminal commands or monitor a user’s shell.

The narrative engine treats log content as untrusted historical text and instructs the model not to follow instructions embedded in logs. These prompt guardrails reduce risk, but cannot guarantee that every malicious instruction will be ignored.

The responsibilities are kept distinct:

Application code parses events and calculates summary metrics.
The AI model writes the narrative and creative interpretations.
The Evidence Inspector shows the source line behind a parsed event.
The user reviews possible secret redactions and checks technical claims.
SQLite stores a session only after the user chooses to save it.

Testing and Continuous Integration

The project includes backend tests for parsing, event analysis, model-client behavior, secret redaction, sessions, and security-related behavior. Frontend tests cover important interface and utility behavior.

GitHub Actions runs the backend test suite, frontend tests, and frontend production build on pushes and pull requests. Passing CI helps catch code and build problems, but it does not replace testing the app in a browser with Ollama and a local model.

The browser smoke-test checklist covers scenario selection, narrative controls, evidence inspection, redaction preview, session saving, Markdown export, and behavior when Ollama is unavailable.

The Spirit of It

The idea became concrete while testing a log line containing a fake API key. GhostTrace showed a redacted preview before analysis. Afterward, I could open the event and inspect the corresponding source line.

That interaction captured the balance I wanted: the log can become a story, but the story should leave a trail back to the trace that inspired it. A process can become a ghost in the narrative; the Evidence Inspector lets the reader see what the machine actually recorded.

hf26challenge

LazyFlow AI: Turn Messy Notes into Actionable Tasks with Local AI

Ayush Aryan — Fri, 23 Oct 2026 19:00:43 +0000

LazyFlow AI: Turn Messy Notes into Actionable Tasks with Local AI

Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady

This project is my submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

1. Introduction

Information overload is a common problem in everyday productivity. We collect meeting notes, personal reminders, project ideas, deadlines, and to-do lists throughout the day. However, turning these unstructured notes into actionable tasks often requires additional time and effort.

LazyFlow AI is a productivity assistant designed to simplify this process by transforming unstructured notes into concise summaries and organized tasks using local AI inference.

Instead of manually reviewing every note and extracting individual action items, users can submit their notes to the application and let the AI identify relevant information and potential tasks.

The objective is straightforward: reduce the friction between recording information and acting on it.

The project combines a modern web interface, a lightweight backend, local data storage, and an open-weight language model to create a practical AI-powered productivity workflow.

2. What I Built

LazyFlow AI provides a workflow for processing notes, generating summaries, extracting tasks, and managing the resulting items.

The application focuses on making AI useful for a simple, everyday problem rather than building a complicated productivity platform.

Key Features

Smart Inbox

The Smart Inbox is the starting point of the workflow. Users can submit unstructured notes containing reminders, deadlines, project updates, and other information.

The application processes the input and presents the resulting information in a more organized format.

AI-Powered Summarization

The application generates concise summaries to help users understand the main points of their notes without having to review the entire text repeatedly.

This is particularly useful when notes contain multiple topics or a mixture of background information and actionable items.

Automatic Task Extraction

LazyFlow AI identifies potential tasks from submitted notes and converts them into individual items that can be reviewed in the application.

For example, a note about preparing a presentation, fixing a software bug, and updating a project README can be transformed into separate tasks.

Priority Classification

The application assigns priority levels to extracted tasks to help users distinguish between different levels of urgency and importance.

Priority classification is an area of ongoing improvement, particularly when distinguishing genuinely urgent tasks from routine activities.

Task Management

Extracted tasks can be reviewed through the Task Manager. This provides a more structured view of work identified from the original notes.

Local AI Inference

LazyFlow AI uses Ollama to run an open-weight language model locally. This reduces dependence on paid, hosted inference APIs for the model-processing workflow.

3. Demo

LazyFlow AI currently runs locally on my machine. The screenshots included in this article demonstrate the application's interface and note-processing workflow.

How the Application Works

Step 1: Submit Notes

The user enters unstructured notes containing reminders, project requirements, deadlines, or other relevant information.

Step 2: Generate a Summary

The backend processes the submitted text using the locally running language model. The generated response summarizes the important information.

Step 3: Extract Actionable Tasks

The AI identifies potential action items from the notes. Tasks can include project work, follow-ups, personal reminders, and other activities that require attention.

Step 4: Review Priorities and Deadlines

The application presents extracted tasks with their available priority and deadline information. Users can review the results and identify anything that needs correction.

Step 5: Manage Tasks

The extracted items can be reviewed in the Task Manager, providing a structured way to work with information that originally appeared in unstructured notes.

The screenshots below show the running application's interface and task-processing results.

The project currently runs locally and does not have a publicly deployed live demo.

4. Technology Stack

LazyFlow AI combines frontend technologies, backend services, local storage, and local AI inference.

Technology	Purpose
React	Building the user interface
TypeScript	Adding static type checking to frontend development
Vite	Frontend development and build tooling
Python	Backend application logic
FastAPI	Providing backend API endpoints
SQLite	Storing application data
Ollama	Running the language model locally
Qwen2.5 3B	Open-weight language model used for inference

This stack provides a relatively lightweight development environment while keeping the application modular.

The frontend handles user interaction and displays generated results. The backend coordinates application logic and communicates with the local model. SQLite provides local data storage, while Ollama makes the language model available to the backend.

5. How I Built It

One of my main goals was to build a useful AI application without making every model interaction dependent on a paid, closed-source API.

Local Model Integration

The application uses Ollama to run Qwen2.5 3B locally.

When a user submits notes, the backend sends the relevant text to the local model and processes its response to generate a summary and identify potential tasks.

The generated results are then returned to the application for display and further task management.

This architecture allows the model-processing workflow to operate locally without requiring a hosted model inference service, provided the application is configured to keep the relevant processing and data storage on the local machine.

Backend and API

The backend is implemented in Python using FastAPI.

It connects the frontend workflow to the underlying processing logic and local model. Keeping this logic in a separate backend helps maintain a clear boundary between the user interface and the AI-processing workflow.

During development, I also worked on handling slower local model responses. Local inference can take longer depending on the model, hardware, and input size, so allowing sufficient time for model responses is important for a reliable user experience.

Frontend and Data Storage

The frontend uses React and TypeScript, with Vite supporting the development and build workflow.

SQLite provides lightweight data storage without requiring a separate database server. This is appropriate for a locally running application and keeps the initial setup relatively simple.

Testing and Reliability

The backend test suite and frontend TypeScript checks have been run during development.

I have also been testing the Smart Inbox with different types of notes to evaluate task extraction, deadline handling, and priority classification.

These tests have helped identify areas where the model can produce useful results but still requires refinement. In particular, priority classification needs to distinguish routine activities from genuinely urgent work more consistently.

6. Why Open Innovation Matters

Open innovation makes AI development more accessible by allowing developers to experiment with open-weight models and open-source technologies.

Building an AI application should not necessarily require a paid API subscription or a dependency on a single hosted provider.

Open-weight models provide developers with opportunities to explore model behavior, experiment with prompts, customize their applications, and learn about practical AI integration.

Greater Control Over the AI Workflow

Running a model locally gives developers more control over how inference is performed and which components their application depends on.

For a productivity tool that processes personal notes, this can be particularly valuable. When model inference and data storage are configured to remain local, note content does not need to be sent to a hosted model provider.

Local processing does not automatically guarantee that every part of an application is private, so the complete data flow still needs to be considered.

Lower Barriers to Experimentation

Open-weight models make it easier for developers to explore AI applications without building their entire workflow around paid inference services.

Although local inference has hardware and performance requirements, it provides an accessible way to learn about model integration and build practical applications.

Collaboration and Transparency

Open-source projects allow other developers to inspect implementations, understand architectural decisions, report problems, and propose improvements.

This creates opportunities for collaborative development and helps others learn from real implementations rather than only theoretical examples.

LazyFlow AI is a small example of how open-source software and open-weight models can be combined to address an everyday productivity problem.

7. Challenges and Lessons Learned

Developing LazyFlow AI has highlighted several practical challenges involved in building applications around local language models.

Handling Slower Responses

Local models can take noticeable time to generate responses, depending on the hardware, input length, and model configuration.

This makes request timeouts and error handling important parts of the backend implementation.

Extracting Tasks Reliably

Notes are rarely written in a consistent format. A single paragraph may contain urgent deadlines, routine reminders, background information, and tasks that have no explicit deadline.

The model must distinguish between these different types of information to produce useful results.

Assigning Appropriate Priorities

A task being actionable does not automatically make it urgent. For example, a routine shopping reminder should not necessarily receive the same priority as a critical project deadline.

This distinction requires careful prompt design and testing with varied examples.

These challenges have reinforced the importance of testing AI applications with realistic inputs instead of assuming that a model's first response will always be correct.

8. Current Limitations and Future Improvements

LazyFlow AI is an ongoing project, and there are several areas I want to improve.

Planned improvements include:

More reliable priority classification: Better distinguish urgent tasks from routine activities.
Improved deadline handling: Handle explicit dates and relative expressions more consistently.
Better handling of ambiguous notes: Reduce incorrect or incomplete task extraction.
Improved task editing: Make it easier to review and correct AI-generated results.
Expanded test coverage: Test more note formats and edge cases.
Interface improvements: Continue refining usability and accessibility.
Broader evaluation: Test the application with a wider variety of realistic notes.

I have not yet conducted a formal productivity study or measured time savings, so I cannot provide a verified numerical improvement.

The immediate goal is to make the existing workflow more reliable before expanding its scope.

9. The Slow and Steady Approach

The idea behind this project aligns with the principle of making incremental improvements rather than attempting to build everything at once.

I started with a focused problem: turning unstructured notes into summaries and actionable tasks.

From there, development has involved connecting the frontend and backend, integrating local inference, testing the generated results, and identifying areas that need improvement.

Each iteration helps reveal practical limitations that are difficult to identify by considering the architecture alone.

For me, this is an important part of building with AI: a working prototype is only the beginning. Reliability, testing, and user experience are what make an application more useful over time.

10. Source Code and Contributions

The project source code is available on GitHub:

Repository:
https://github.com/ayusharyan4269-bit/lazyflow-ai

Developers interested in local AI, productivity tools, or open-source application development are welcome to explore the project and share feedback.

Potential contribution areas include:

Improving task extraction and classification.
Adding tests for difficult input cases.
Refining the local inference workflow.
Improving the user interface.
Enhancing documentation and setup instructions.

Feedback and suggestions are welcome, especially ideas that can make the application more reliable and useful.

Conclusion

LazyFlow AI explores how local AI can help transform unstructured notes into organized summaries and actionable tasks.

By combining React, FastAPI, SQLite, Ollama, and an open-weight language model, the project demonstrates a practical approach to building a locally running AI-powered productivity tool.

There is still work to do, particularly around classification accuracy and real-world testing. Those limitations provide a clear direction for future development.

The goal is not to build the largest possible AI application, but to build a useful one and improve it consistently.

Thank you for taking the time to explore LazyFlow AI.

Hacktoberfest #OpenSource #AI #Ollama #Qwen

My Hacktoberfest 2026 Journey: Getting Started with Open Source

Ayush Aryan — Tue, 13 Oct 2026 20:03:59 +0000

My Hacktoberfest 2026 Journey: Getting Started with Open Source

Hey everyone!

I'm a Computer Science undergraduate at IIIT Lucknow, and I've been spending time learning programming, solving DSA problems, and building projects.

Now, I want to take the next step by contributing to open source.

Hacktoberfest feels like a good opportunity to explore real-world projects, understand how developers collaborate, and learn how software is built beyond personal projects and tutorials.

What I Want to Learn

Here are a few things I want to focus on during this journey:

Exploring open-source repositories and understanding their codebases.
Finding issues where I can make meaningful contributions.
Improving my Git and GitHub workflow, especially branches and pull requests.
Learning how to read existing code and debug unfamiliar projects.
Connecting with developers and learning from their experiences.

Technologies I'm Interested In

My current interests include:

C++ and Data Structures & Algorithms
React and Next.js
Web Development
Web3 and Blockchain Development
AI-powered applications

I'm happy to explore projects outside these areas if they offer an opportunity to learn something new.

Looking for Recommendations

Since I'm getting more involved in open source, I'd appreciate recommendations for repositories that welcome new contributors.

I'd love to hear about your experiences and learn from the community.

My goal is to make genuine contributions, improve my development skills, and become more comfortable working on collaborative projects.

Looking forward to seeing what I can learn along the way.

hacktoberfest #opensource #beginners

DEV Community: Ayush Aryan

GhostTrace: Giving Terminal Logs a Story Without Losing the Evidence

What I Built

Demo

Code

How I Built It

Analysis workflow

1. Input review

2. Deterministic log parsing

3. Event analysis

4. Narrative generation

5. Saving and exporting

Why Does Open Innovation Matter?

Privacy and Safety Choices

Testing and Continuous Integration

The Spirit of It

Related Reading

hf26challenge

LazyFlow AI: Turn Messy Notes into Actionable Tasks with Local AI

LazyFlow AI: Turn Messy Notes into Actionable Tasks with Local AI

1. Introduction

2. What I Built

Key Features

3. Demo

How the Application Works

4. Technology Stack

5. How I Built It

Local Model Integration

Backend and API

Frontend and Data Storage

Testing and Reliability

6. Why Open Innovation Matters

Greater Control Over the AI Workflow

Lower Barriers to Experimentation

Collaboration and Transparency

7. Challenges and Lessons Learned

Handling Slower Responses

Extracting Tasks Reliably

Assigning Appropriate Priorities

8. Current Limitations and Future Improvements

9. The Slow and Steady Approach

10. Source Code and Contributions

Conclusion

Hacktoberfest #OpenSource #AI #Ollama #Qwen

My Hacktoberfest 2026 Journey: Getting Started with Open Source

My Hacktoberfest 2026 Journey: Getting Started with Open Source

What I Want to Learn

Technologies I'm Interested In

Looking for Recommendations

hacktoberfest #opensource #beginners