Public sample. This report was generated from 21 public repositories belonging to aniketqw. Private repositories are excluded by construction — see scripts/check_sample.py, which fails the build if a private repository name appears here.

Resume report — aniketqw

Built from 21 repositories. 102 claims verified, 3 need measurement, 6 rejected.

Security findings in your repositories

These were found while reading your repositories. Fix these first.

• [high] pehenava-backend/pehnava-ai-frontend/.env.local — An .env file is committed. These normally hold live credentials.

Role comparison

Best fit: data_scientist (spread across roles: 26.79 points).

Resume — ai_llm_agent_engineer (34.06/100)

AI / LLM Agent Engineer – Agentic LLM Systems with Evaluation and Guardrails

Designed and implemented agentic LLM systems using LangChain ReAct and MongoDB, integrating static and dynamic web scraping, PDF extraction, and tool‑calling workflows. Built AI‑powered natural language search for GitHub repositories, delivering analytics and export capabilities. Developed robust data ingestion pipelines and structured output handling for LLM applications.

Projects

• Implemented a LangChain ReAct Agent with Ollama and MongoDB to orchestrate tool‑calling workflows.
• Built a static web scraper using requests and BeautifulSoup to provide structured data for LLM inputs.
• Developed a dynamic web scraper with Playwright for real‑time data extraction.
• Created a PDF extractor converting PDFs to text via pypdf, pymupdf, and OCR for LLM ingestion.
• Implemented MongoDB helpers for inserting and searching documents to support LLM retrieval.
• Designed an AI‑powered natural language search for GitHub repositories, supporting URL‑based and natural language modes.
• Delivered detailed analytics including stats, contributors, language breakdown, commits, and issues for repositories.
• Enabled export of analysis results as JSON or CSV for downstream processing.

Skills

• LangChain
• Ollama
• MongoDB
• requests
• BeautifulSoup
• Playwright
• pypdf
• pymupdf
• OCR
• Docker Compose
• Node.js
• Express
• Multer

Resume — ml_engineer (25.88/100)

Machine Learning Engineer – Model Training, Evaluation, and Deployment

Implemented and maintained machine learning pipelines for natural language and web‑scraping tasks, leveraging LangChain, Ollama, and MongoDB. Built data extraction utilities and web scrapers using requests, BeautifulSoup, Playwright, and OCR libraries. Developed backend services for file handling and AI‑powered repository analysis with Docker Compose.

Projects

• Implemented a LangChain ReAct Agent with Ollama and MongoDB to orchestrate tool calls for AI tasks.
• Built a static web scraper using requests and BeautifulSoup for data extraction.
• Developed a dynamic web scraper with Playwright for interactive content retrieval.
• Created a PDF extractor converting PDFs to text via pypdf, pymupdf, and OCR.
• Provided MongoDB helpers for inserting and searching documents in the agent workflow.
• Constructed a minimalist file upload system with Node.js and Express, offering web interface, file listing, and download capabilities.
• Built a Docker Compose‑based backend and frontend for the local lending application.
• Developed an AI‑powered natural language search for GitHub repositories, supporting URL and natural language queries, and delivering analytics in JSON or CSV.

Skills

• LangChain
• Ollama
• MongoDB
• requests
• BeautifulSoup
• Playwright
• pypdf
• pymupdf
• OCR
• Node.js
• Express
• Docker Compose

Resume — backend_platform_engineer (32.25/100)

Backend / Platform Engineer – Service & Infrastructure Builder

Engineered and maintained backend services and infrastructure, focusing on API design, containerization, and data persistence. Delivered microservices with Docker, managed data with MongoDB and PostgreSQL, and implemented robust logging and monitoring solutions.

Projects

• Implemented a multi-threaded C pipeline for AoA protection, parsing UART frames and validating sensor data using median filtering and outlier rejection.
• Designed and executed a finite‑state machine driven by CSV‑defined thresholds to classify flight states and control elevator deflection for AoA mitigation.
• Built a minimalist file upload system with Node.js and Express, providing a web interface for uploading, listing, and downloading files, with configurable size limits via Multer.
• Developed a dynamic web scraper using Playwright and a static scraper with requests and BeautifulSoup, integrating PDF extraction via pypdf, pymupdf, and OCR.
• Created an AI-powered natural language search for GitHub repositories, delivering analytics and exportable results in JSON or CSV formats.
• Integrated MongoDB helpers for inserting and searching documents in an agent-based system using LangChain ReAct Agent with Ollama.
• Started and built backend and frontend services with Docker Compose, enabling consistent local development environments.

Skills

• C
• Node.js
• Express
• Python
• Playwright
• BeautifulSoup
• requests
• pypdf
• pymupdf
• OCR
• MongoDB
• Docker Compose
• Docker
• GitHub
• JSON
• CSV

Resume — data_scientist (52.67/100)

Data Scientist – Turning Data into Measured Answers

Built and deployed data pipelines that extract, transform, and analyze information from web sources and code repositories. Delivered AI‑powered search and analytics tools that provide actionable insights in JSON and CSV formats.

Projects

• Implemented a dynamic web scraper using Playwright to collect structured data for downstream analysis.
• Developed a PDF extractor converting documents to text via pypdf, pymupdf, and OCR for data ingestion.
• Created MongoDB helper functions to insert and search documents, enabling efficient data retrieval.
• Built an AI‑powered natural language search engine for GitHub repositories, delivering detailed analytics such as contributor stats, language breakdown, commits, and issues.
• Exported analysis results as JSON or CSV, facilitating integration with downstream data science workflows.

Skills

• Python
• Playwright
• BeautifulSoup
• requests
• pypdf
• pymupdf
• OCR
• MongoDB
• LangChain
• Ollama
• Jupyter
• pandas
• numpy
• SQL
• data visualization
• regression
• classification
• clustering
• hypothesis testing
• A/B testing
• experiment design

Resume — balanced (38.42/100)

Software Engineer – Generalist across services, data, and ML

Implemented multi‑threaded C pipelines for AoA protection, built web‑scraping utilities in Python, and developed a Node.js file upload server. Designed and deployed Docker‑based services, integrated MongoDB helpers, and engineered AI‑powered GitHub repository analytics.

Projects

• Implemented a multi‑threaded C pipeline for AoA protection
• Parsed UART frames and validated sensor data using median filtering and outlier rejection
• Estimated AoA with weighted fusion and a Kalman filter
• Ran a finite‑state machine driven by CSV‑defined thresholds to classify flight states
• Controlled elevator deflection to mitigate excessive AoA in protection mode
• Logged state transitions and sensor faults to fault_log.csv
• Used LangChain ReAct Agent with Ollama and MongoDB
• Provided a static web scraper using requests and BeautifulSoup
• Provided a dynamic web scraper using Playwright
• Provided a PDF extractor converting PDFs to text via pypdf, pymupdf, and OCR
• Included MongoDB helpers for inserting and searching documents
• Built a minimalist file upload system with Node.js and Express for FreeBSD
• Provided a simple web‑based file upload interface
• Stored uploaded files with original filenames
• Listed uploaded files with size and upload date
• Enabled direct file download from the interface
• Configured default maximum upload size of 10 MB via Multer limits
• Started and built backend with Docker Compose
• Started and built frontend with Docker Compose
• Provided AI‑powered natural language search for GitHub repositories
• Supported URL‑based and natural language search modes
• Delivered detailed analytics including stats, contributors, language breakdown, commits, and issues
• Allowed exporting analysis results as JSON or CSV

Skills

• C
• Python
• Node.js
• Express
• JavaScript
• Docker Compose
• MongoDB
• LangChain
• Ollama
• requests
• BeautifulSoup
• Playwright
• pypdf
• pymupdf
• OCR
• Multer
• GitHub API

Improvement plan

5 steps, ~40 hours, +16.9 ATS points if all are completed.

1. Add Data Science Notebook to AiAgentDemo

12h · +7.23 ATS · role: data_scientist · repo: AiAgentDemo

• Gap: Cannot evidence statistics, visualisation, dataset, notebook, correlation, feature, matplotlib, seaborn, metric, r
• Evidence found: AiAgentDemo (Python web‑scraping and PDF extraction)
• Action: Create a Jupyter notebook (notebook.ipynb) in the AiAgentDemo repository that loads a public dataset (e.g., UCI Wine), performs descriptive statistics, computes correlation matrix, engineers at least two new features, visualises distributions and relationships with matplotlib and seaborn, and records a simple model’s evaluation metric (e.g., accuracy).
• Done when: notebook.ipynb committed to AiAgentDemo with executed cells, plots saved as PNG, and a markdown summary of statistics and metrics.

2. Create R Analysis Demo Repository

10h · +3.95 ATS · role: data_scientist · new work

• Gap: Missing evidence of R language and related visualisation (ggplot2) for keyword ‘r’
• Evidence found: none
• Action: Initialize a new repository named r-analysis-demo, add an R script (analysis.R) that loads the same dataset, performs summary statistics, computes correlations, creates at least two ggplot2 visualisations, and saves plots as PNG files.
• Done when: analysis.R, summary.txt, and plot PNG files committed to r-analysis-demo.

3. Update AiAgentDemo README with Data Science Section

4h · +2.63 ATS · role: data_scientist · repo: AiAgentDemo

• Gap: Resume sections lack explicit data‑science artefacts
• Evidence found: AiAgentDemo (existing README with web‑scraping description)
• Action: Edit the README.md to add a “Data Science Projects” section linking to notebook.ipynb, features.py, evaluate_model.py and summarising the statistical and visualisation work.
• Done when: README.md updated and pushed, showing the new section with hyperlinks.

4. Add Model Metric Reporting Script

6h · +1.97 ATS · role: data_scientist · repo: AiAgentDemo

• Gap: No demonstrated metric calculation or reporting
• Evidence found: AiAgentDemo (existing Python utilities)
• Action: Create a script (evaluate_model.py) that trains a simple classifier/regressor on the same dataset, computes relevant metrics (e.g., RMSE, F1‑score), and writes a JSON report (metrics.json).
• Done when: evaluate_model.py and generated metrics.json committed to the repo.

5. Implement Feature‑Engineering Module

8h · +1.1 ATS · role: data_scientist · repo: AiAgentDemo

• Gap: Missing evidence of feature creation and statistical processing
• Evidence found: AiAgentDemo (Python code base)
• Action: Add a Python module (features.py) that defines functions for cleaning, scaling, and generating new features from a DataFrame; include unit tests (test_features.py) covering at least three cases.
• Done when: features.py and test_features.py committed, with 100% test pass shown in CI badge or local run output.

Measure these

Each of these is plausible but unproven. The agent refused to put a number on it; run the command and the number becomes claimable.

• chronosModelImprovement — The distance‑aware model does not win the majority of series, losing 745 out of 1484.
• why: contains number(s) absent from the evidence: 745
• measure this and record the command and result
• tender_search_app — Enables users to add and refine keywords to improve search accuracy.
• why: asserts an effect without a measured quantity
• run the evaluation set and record the metric
• sandbox-agent — The agent graph is lazily loaded to improve startup performance.
• why: asserts an effect without a measured quantity
• measure this and record the command and result

Refused claims

The model proposed these; the evidence did not support them. They are listed so you can see what was filtered, not hidden.

• locallend — The backend is implemented in Java using Spring Boot.
  every supporting quote is absent from the evidence
• locallend — The frontend is written in TypeScript with React.
  every supporting quote is absent from the evidence
• locallend — The repository includes image upload functionality.
  every supporting quote is absent from the evidence
• locallend — The repository implements CRUD operations for items.
  every supporting quote is absent from the evidence
• AiTerminal — The project uses the tcell library for terminal UI.
  supporting quote is real but does not mention anything in the claim
• AiTerminal — The repository does not include a CI configuration.
  supporting quote is real but does not mention anything in the claim

Evidence index

AOA_Controller_ty

AoA Controller is a multi-threaded C pipeline that protects aircraft from excessive angle‑of‑attack by parsing UART frames, validating sensor data, estimating AoA, and driving elevator commands, warnings, and fault logging.

• Implements a multi-threaded C pipeline for AoA protection.
• README.md: "Angle-of-Attack (AoA) protection system for embedded flight control, implemented as a multi-threaded C pipeline."
• Parses UART frames and validates sensor data using median filtering and outlier rejection.
• README.md: "UART_FrameParser │ sem_post(frame_ready_sem) ▼ SensorValidator ← median filter, outlier rejection, confidence score"
• Estimates AoA with weighted fusion and a Kalman filter.
• README.md: "AoA_Estimator ← weighted fusion + Kalman filter"
• Runs a finite‑state machine driven by CSV‑defined thresholds to classify flight states.
• README.md: "FlightControlFSM ← CSV thresholds → NORMAL / WARNING / PROTECTION"
• Controls elevator deflection to mitigate excessive AoA in protection mode.
• README.md: "ElevatorCmdManager ← corrective deflection in PROTECTION mode"
• Logs state transitions and sensor faults to fault_log.csv.
• README.md: "FaultLogger ← logs state transitions + sensor faults"

AiAgentDemo

A small demo showing a LangChain ReAct agent that orchestrates static, dynamic, and PDF scraping tools and stores results in MongoDB.

• Uses LangChain ReAct Agent with Ollama and MongoDB.
• README.md: "built with LangChain, Ollama, and MongoDB."
• Provides a static web scraper using requests and BeautifulSoup.
• README.md: "static scraper (requests+BS)"
• Provides a dynamic web scraper using Playwright.
• README.md: "dynamic scraper (Playwright)"
• Provides a PDF extractor that converts PDFs to text via pypdf, pymupdf, and OCR.
• README.md: "PDF extractor (pypdf→OCR)"
• Includes MongoDB helpers for inserting and searching documents.
• README.md: "MongoDB tools (save / search)"
• The agent only decides which tool to call, delegating work to the underlying functions.
• README.md: "The agent is a decision layer. It does not scrape, parse, or store data."

file-upload-server

A minimalist file upload server built with Node.js and Express for FreeBSD.

• The project is a minimalist file upload system built with Node.js and Express for FreeBSD.
• README.md: "A minimalist file upload system built with Node.js and Express for FreeBSD systems."
• It provides a simple web-based file upload interface.
• README.md: "Simple web-based file upload interface"
• Uploaded files are stored with their original filenames.
• README.md: "Original filename preservation"
• The server lists uploaded files with their size and upload date.
• README.md: "File listing with size and upload date"
• Users can download files directly from the interface.
• README.md: "Direct file download capability"
• The default maximum upload size is 10 MB, configurable via the Multer limits.
• README.md: "Default maximum file size is 10MB."

locallend

LocalLend is a full‑stack web application that lets users list, browse, and book items, built with a Java Spring Boot backend and a TypeScript React frontend.

• The backend is started and built with Docker Compose.
• README.md: "start and build the backend using docker compose up --build -d (from the locallend directory)"
• The frontend is started and built with Docker Compose.
• README.md: "start and build the frontend using docker compose up --build -d (from the locallend-frontend directory)"

GithubRepoAnalyzer

GitHubRepoAnalyzer is a React application that analyzes GitHub repositories using AI-powered natural language search and provides comprehensive analytics.

• Provides AI‑powered natural language search for GitHub repositories.
• README.md: "A comprehensive React application for analyzing GitHub repositories with AI-powered natural language search capabilities."
• Supports both URL-based and natural language search modes.
• README.md: "Dual Search Modes - URL Search: Direct repository analysis via GitHub URLs - Natural Language Search: AI-powered repository discovery using plain English descri"
• Delivers detailed analytics including stats, contributors, language breakdown, commits, and issues.
• README.md: "Comprehensive Analytics - Repository statistics and metadata - Contributor analysis with activity metrics - Programming language breakdown with visual charts - "
• Allows exporting analysis results as JSON or CSV.
• README.md: "Export Functionality: Download analysis results in JSON/CSV formats"
• Fully containerized with Docker for easy deployment.
• README.md: "Docker Container (Production Ready)"
• Manages GitHub API rate limits with public and private modes.
• README.md: "Public API Mode: 60 requests per hour (no authentication required) - Private API Mode: 5,000 requests per hour (requires GitHub personal access token)"

spring-gemini-chat

Spring Gemini Chat is a reactive Spring Boot application that provides real‑time chat powered by Google Gemini AI.

• Built with Spring WebFlux for high-performance, non-blocking operations
• README.md: "Built with Spring WebFlux for high-performance, non-blocking operations"
• Powered by Google's latest Gemini AI model
• README.md: "Powered by Google's latest Gemini AI model"
• Instant responses with typing indicators
• README.md: "Instant responses with typing indicators"
• Clean, responsive web interface
• README.md: "Clean, responsive web interface"
• Built-in health checks and status indicators
• README.md: "Built-in health checks and status indicators"
• Support for contextual conversations
• README.md: "Support for contextual conversations"

next-express-ejs-crud

A starter that runs a Next.js frontend and an Express + EJS backend side‑by‑side to demonstrate CRUD operations.

• Provides a backend that serves both EJS‑rendered pages and a JSON API.
• README.md: "Backend: Express + EJS (server-rendered pages at http://localhost:4000) and a JSON API under /api."
• Runs a Next.js frontend that consumes the Express JSON API.
• README.md: "Frontend: Next.js (at http://localhost:3000) that calls the API."
• Rewrites /api/* requests in Next.js to the Express API on port 4000.
• README.md: "next.config.js rewrites /api/* to http://localhost:4000/api/* in development/production."
• Wraps fetch in the frontend to use an absolute URL that works during server‑side rendering.
• README.md: "web/lib/api.js wraps fetch. On the server it uses an absolute URL based on NEXT_ORIGIN so SSR fetches hit Next first and are rewritten to the API."
• Provides a Dockerfile that builds and runs both the Next.js and Express apps in a single container.
• README.md: "This repo includes a single Dockerfile that builds both apps and runs them in one container (ports 3000 for Next, 4000 for Express)."
• Implements a JSON API with CRUD routes for posts.
• README.md: "API Routes (JSON) - GET /api/posts — list all posts"

nextjs-express-crud-hf

A full‑stack Next.js and Express CRUD application ready for Hugging Face deployment.

• Provides a full‑stack CRUD application with server‑side rendering.
• README.md: "Full-stack CRUD app with SSR, ready for Hugging Face deployment."
• Combines Next.js for the front‑end and Express for the API.
• README.md: "Next.js + Express CRUD Application"
• Includes a GitHub Actions workflow that deploys the app to Hugging Face.
• README.md: "Deploy to Hugging Face: - Add HF_TOKEN to GitHub secrets - Update HF_REPO_ID in workflow - Push to GitHub"
• Uses Docker as the SDK for containerized deployment.
• README.md: "docker"
• Configures the application to run on port 7860.
• README.md: "app_port: 7860"
• Runs the front‑end on localhost port 3000.
• README.md: "Visit http://localhost:3000"

AOA_Controller_ty_1

A real‑time angle of attack monitoring and elevator control system for aircraft, with ESP32 firmware and PC‑based simulation tools.

• Provides real‑time AOA monitoring and elevator control on ESP32.
• README.md: "Real-time angle of attack monitoring and elevator control system for aircraft, with ESP32 firmware and PC-based simulation tools."
• Simulates all four flight phases using CSV test data.
• README.md: "Process flight test data from CSV file. Simulates all 4 flight phases (TAKEOFF, CLIMB, CRUISE, LANDING) with realistic FSM state transitions and elevator comman"
• Implements a 10°/sec slew‑rate limit on elevator deflection.
• README.md: "Slew-rate limited elevator (10°/sec max)"
• Handles missing sensor readings by treating 0.00 values as absent.
• README.md: "Handles missing sensor data (0.00 values)"
• Provides an interactive UART simulator for real‑time debugging.
• README.md: "Interactive UART Simulator (simulator.c) ... Real-time interactive testing with manual AOA message input."
• Builds without requiring a local ESP‑IDF installation.
• README.md: "No ESP-IDF dependencies (uses mock headers)"

chronosModelImprovement

Chronos Model Improvement implements a distance‑aware enhancement to the Chronos time series forecasting model.

• Provides a distance‑aware variant of the Chronos forecasting model.
• README.md: "This repository contains improvements to the Chronos time series forecasting model."
• Adds a distance‑aware enhancement to the Chronos model.
• README.md: "Distance-aware enhancement for Chronos model."
• Benchmark shows the distance‑aware model has a higher MAE (1315.20) than the original (1309.50).
• README.md: "MAE | 1315.20 | 1309.50 | Original"
• Benchmark shows the distance‑aware model has a higher RMSE (1593.91) than the original (1584.71).
• README.md: "RMSE | 1593.91 | 1584.71 | Original"
• The distance‑aware model wins 739 out of 1484 series, a win rate of 49.8%.
• README.md: "Win Rate: Distance-Aware wins 739/1484 series (49.8%)"

websocket_mcqs1

A MERN‑stack application that lets users create multiple‑choice questions and play against each other with real‑time score updates.

• The repository implements a real‑time MCQ battle.
• README.md: "Realtime MCQs battle"
• The application is built with the MERN stack.
• README.md: "It is written in Javascript using MERN stack"
• Installation requires running npm install.
• README.md: "npm install"
• The server is started with node server.js.
• README.md: "node server.js"
• Scores are observed in real time by all participants.
• README.md: "observe their score in realtime"
• Users can create MCQs and play against each other.
• README.md: "create MCQs and play against each other"

aniketqw.github.io

Aniket Saxena’s personal portfolio site and admin dashboard built with a custom design system.

• Implemented a custom design system for the portfolio.
• README.md: "A design system distilled from the personal portfolio of Aniket Saxena — AI Engineer & Full-Stack Developer"
• Built both a public portfolio site and a private admin dashboard.
• README.md: "Two surfaces are represented: the public Portfolio site and the private Admin (repo manager) tool."
• Styled the admin dashboard with distinct typography and color accents.
• README.md: "Admin uses Title Case with lowercase helper copy and ALL-CAPS 10–12px uppercase labels with 1–3px letter-spacing."
• Implemented a Python script to fetch and filter GitHub repositories.
• README.md: "Add fetch_repos.py to retrieve and filter GitHub repos"
• Added a dynamic projects section that loads data from GitHub.
• README.md: "Add projects section with dynamic project loading"
• Documented design tokens and UI kits for reuse across the site.
• README.md: "Add design system assets and documentation - colors, typography, components, and UI kits"

pehenava-backend

Pehenava Backend is a Node.js/Express application that connects to MongoDB to provide API services for the Pehenava project.

• The repository implements a Node.js/Express backend that integrates with MongoDB.
• README.md: "A Node.js/Express backend application with MongoDB integration for the Pehenava project."
• It supports a local setup where dependencies are installed via npm.
• README.md: "When running without Docker, all dependencies will be installed locally on your machine."
• It also supports a Dockerized deployment that containers all dependencies.
• README.md: "When running with Docker, all dependencies are containerized - nothing is installed on your local machine except Docker itself."
• The README provides a Docker command to run a MongoDB container for the backend.
• README.md: "docker run -d \ --name pehenava-mongo \ -p 27017:27017 \ mongo:latest"
• Docker Compose is recommended to manage both the application and MongoDB containers together.
• README.md: "docker-compose up -d"
• The application starts an Express server listening on port 3000.
• README.md: "Server running on port 3000"

AiTerminal

AiTerminal is a Go-based terminal AI application that runs via go run terminal.go.

• The application is started by running go run terminal.go.
• readme.md: "go run terminal.go"
• The project uses the gin web framework.
• go.mod: ""github.com/gin-gonic/gin""
• The project uses gorilla/websocket for real‑time communication.
• go.mod: ""github.com/gorilla/websocket""
• The repository does not contain a test suite.
• signals: ""has_test_suite": false"

tender_search_app

A web‑based tool that lets users search and filter Indian tenders using a Gradio interface.

• Provides search functionality across multiple Indian tender sources.
• README.md: "Search for tenders across multiple sources."
• Allows filtering of search results by recency and relevance.
• README.md: "Filter tenders based on recency and relevance."
• Implements a user‑friendly interface using Gradio.
• README.md: "User-friendly interface built with Gradio."
• Builds the application stack with Python, Gradio, Langchain, BeautifulSoup, Requests, and Pandas.
• README.md: "Technologies Used - Python - Gradio - Langchain - BeautifulSoup - Requests - Pandas"
• Runs the application via a Python script that starts the Gradio server.
• README.md: "Run the application: python main.py"

Rule-BasedCustomKafkaPartitioner

A Java 21 demo that implements a custom Kafka partitioner routing messages based on key rules.

• Implements a custom Kafka partitioner that routes messages based on key rules.
• README.md: "This project demonstrates a custom Kafka partitioner that routes messages based on rules: USA keys go to the last partition, others are hashed across the rema"
• The partitioner sends keys equal to "USA" to the last partition and hashes other keys to the remaining partitions.
• README.md: "Custom partitioner logic: USA → last partition; others → hash % (numPartitions - 1)."
• A producer demo sends sample messages with keys including "USA" to the topic "orders".
• README.md: "The producer sends sample messages with keys INDIA, GERMANY, USA, FRANCE, USA to topic orders."
• Producer output shows "USA" messages are routed to partition 3, the last partition.
• README.md: "Sent key=INDIA value=Order-1 → partition=1 Sent key=GERMANY value=Order-2 → partition=1 Sent key=FRANCE value=Order-4 → partition=2 Sent key=USA value=Order-3 →"
• The demo topic is created with four partitions, enabling the rule‑based routing.
• README.md: "Topic orders is auto‑created with 4 partitions by default."
• Kafka is run locally using Docker Compose for a single‑node setup.
• README.md: "docker-compose.yml for a single‑node Kafka setup."

sandbox-agent

sandbox-agent is a Python-based LangGraph agent framework that supports an educative tool, lazy loading, and web search integration.

• Credentials for the educative tool are stored in an environment variable.
• commits/6d8d1e9879: "Move EDUCATIVE_COOKIES_B64 from source code to environment variable"
• An educative feature allows users to ask questions about a course using a cookie.
• commits/f7281212c5: "added educative feature just we can just give cookie and ask question about the course"
• A dummy stub container is provided for local tool execution, with a clear error message when run in LangGraph Studio.
• commits/1a0c192bc9: "added dummy stub container working but some other error NotImplementedError('Tool execution is not available in LangGraph Studio. Please run the agent locally ("
• The repository includes a tavily web search tool for external data retrieval.
• commits/5d6794c559: "updating added tavily web search"
• An explicit NotImplementedError informs users that tool execution requires running the agent locally.
• commits/1a0c192bc9: "NotImplementedError('Tool execution is not available in LangGraph Studio. Please run the agent locally (python harness.py) to execute tools.')"

websocket_chatroom

A simple realtime chatroom implemented with WebSocket.

• Built a simple chatroom with realtime communication using WebSocket.
• README.md: "Simple chatroom with realtime communication implemented using websocket"
• Implemented broadcasting of messages to multiple clients.
• commit:3538e568ad: "Broadcast to multiple clients"
• Server sends messages back to the client and the client receives them.
• commit:9fb75c6f01: "Send message back to client from server and receiving it on client side"
• Client can send a message to the server via WebSocket.
• commit:e60c00c599: "send a message from client to server send() (index.html)"
• Server responds to the connection event when a client connects.
• commit:d4c0cf540f: "on connection respond to connection event on server side"
• The repository includes an automated test suite.
• signals: ""has_test_suite": true"

chat-starter-code

A simple WebSocket-based chat application built with Node.js.

• The project is a WebSocket‑based chat application.
• README.md: "# WebSockets-ws Chat Application"
• The application is started with npm install followed by node server.js.
• README.md: "To run this application, first open up a terminal. Then, run the command below: sh npm install node server.js"
• The application is deployed and accessible at https://chat-starter-code.onrender.com/.
• README.md: "https://chat-starter-code.onrender.com/"

Run cost

• Groq: 11359 tokens across 3 calls
• Cache hit rate: 100%
• Wall clock: 2779s

Run trace

A complete record of one pipeline run, written so the output can be audited rather than trusted. Every claim the verifier rejected is listed below with its reason — that section is the most informative part of this file.

• Command: python scripts/build_sample.py --username aniketqw
• Account: aniketqw (public repositories only)
• Python: 3.11.15 on Darwin
• Models: small/mid openai/gpt-oss-20b, big openai/gpt-oss-120b
• Free-tier ceiling: 8,000 tokens/min, 1,000 requests/day (per model)

Stages

Headline numbers

• 102/111 claims verified (92%); 3 need measurement; 6 rejected outright.
• 5 resumes built from verified claims only.
• Groq: 11,359 tokens across 3 node(s).
• Cache hit rate: 100% — an unchanged repo costs nothing on a re-run.
• Wall clock: 2779s, most of it waiting on the 8,000 tokens/minute limit.

Repository selection

Scored by Jev (a typed decision model), not by Groq — this costs fractions of a cent and leaves the scarce Groq budget for text.

Claim verdicts

Verification is plain Python, not a prompt. Every number in a claim must appear in that repository's evidence bundle; every quote must be present and relevant to the claim it supports.

Rejected (6)

These were proposed by the model and thrown out. They never reach a resume.

• locallend — The backend is implemented in Java using Spring Boot.
• every supporting quote is absent from the evidence
• locallend — The frontend is written in TypeScript with React.
• every supporting quote is absent from the evidence
• locallend — The repository includes image upload functionality.
• every supporting quote is absent from the evidence
• locallend — The repository implements CRUD operations for items.
• every supporting quote is absent from the evidence
• AiTerminal — The project uses the tcell library for terminal UI.
• supporting quote is real but does not mention anything in the claim
• AiTerminal — The repository does not include a CI configuration.
• supporting quote is real but does not mention anything in the claim

Needs measurement (3)

Plausible but unproven. The agent refused to attach a number it could not find, and emitted a measurement task instead.

• chronosModelImprovement — The distance‑aware model does not win the majority of series, losing 745 out of 1484.
• contains number(s) absent from the evidence: 745 → measure this and record the command and result
• tender_search_app — Enables users to add and refine keywords to improve search accuracy.
• asserts an effect without a measured quantity → run the evaluation set and record the metric
• sandbox-agent — The agent graph is lazily loaded to improve startup performance.
• asserts an effect without a measured quantity → measure this and record the command and result

Resume scores

Deterministic 100-point ATS rubric, no model involved.

Bullets dropped during resume writing

None. Every generated bullet traced back to a verified claim.

Improvement plan

5 steps, ~40 hours, +16.9 ATS points. The gain figure comes from the same rubric that produced the score, not from the model.

Security findings in the scanned repositories

• [high] pehenava-backend/pehnava-ai-frontend/.env.local — An .env file is committed. These normally hold live credentials.

Measured quality

Notes

• Private repositories are excluded before any fetch, so no private content enters this pipeline at all.
• Summaries are cached by (repo, head SHA, prompt version, model); the cache hit rate above shows how much of this run was free.

How to reproduce

pip install -e ".[dev]"
cp .env.sample .env   # add GROQ_API_KEY, TYPESAFE_API_KEY, GITHUB_PERSONAL_ACCESS_TOKEN
rba doctor
python scripts/build_sample.py --username aniketqw

Summaries are cached by (repo, head SHA, prompt version, model), so a second run over unchanged repositories spends no tokens at all.

How it works

list_repos        official GitHub MCP server, read-only toolset
select_repos      Jev scores every repo for "is this claimable"; no Groq tokens
fetch_facts       deterministic: README, tree, commits, tests, CI, dependencies
safety_scan       flags .env / tokens / cookies committed in the repositories
summarize_repo    strict JSON, one repo per call, rate limited
verify_claims     CODE, not a prompt: unsupported claims are dropped
score_roles       deterministic 100-point ATS rubric
build_resumes     bullets drawn only from verified claims
plan_improvements evidence-linked steps with hours and ATS gain

Why claims survive or die

verify_claims is plain Python. Every digit in a generated claim must appear in that repository's evidence bundle, and every supporting quote must be both present and relevant to the claim it backs. A claim that fails is not softened — it is dropped, and reappears as a measurement task.

The clearest example from a real run: the model wrote "losing 745 out of 1484", having computed 1484 − 739 itself. The evidence contains 739 and 1484 but never 745, so the claim was refused.

Measured quality

Claim faithfulness — the text that actually reaches a resume — and number precision both measure 1.00. Whole-summary faithfulness is 0.83, and that gap is reported rather than averaged away: the descriptive problem and approach fields are framing, are not run through verify_claims, and can contain fair-sounding inference.

Reproducibility, measured

Two independent runs over the same repositories, both at temperature: 0:

That split is the design working as intended, not an accident: the half that decides what may be said is deterministic Python, so it cannot drift. The half that decides how to say it is a language model, and Groq's gpt-oss models are not reproducible even at temperature 0.

The practical consequence is worth stating plainly: treat a single ATS score as indicative, not precise. What is stable is which claims are allowed through — and that is the property the project actually promises.

Operating inside a free tier

The binding constraint is 8,000 tokens per minute, not the request rate. One evidence-linked repository summary costs about 2,074 tokens, so the ceiling is roughly four per minute. Responses are cached by (repo, head SHA, prompt version, model), so an unchanged repository costs nothing on a re-run.